I found exactly the same issue.
Restarted the hub, binding, OH, - no change…
That must be the case for me as well.
I just upgraded yesterday (no choice) because I needed to change my Harmony config…
What about this error (warning) which some of us is experience at start up. As far as I remeber this started with the M6 og M7 build. It´s still there in M8 and well as the new stable release.
2018-12-12 22:23:46.084 [WARN ] [e.jetty.util.thread.ThreadPoolBudget] - Low configured threads: (max=8 - required=1)=7 < warnAt=8 for QueuedThreadPool[ServletModel-18]@356cb0{STARTING,8<=0<=8,i=0,q=0}[ReservedThreadExecutor@ee83f5{s=0/1,p=0}]
It’s been there for some time before M6. You probably didn’t let the OH upgrade process change your cfg files.
I probably didn´t, cause I dont recall never be given the option!
Question is then - how to fix this?
I wonder if this could be related. I just discovered last night I have some serious problems with Grafana rendering png´s. After upgrading to M8 and now 2.4 release, it takes aprox one minute to render one picture. (with openhab 2.3 it took only a few seconds). Rendering more than one picture at the same time (same sitemap), ends with an timeout. (grafana error - “Signal: killed”).
Reading the thread I linked to would have led you to
and
Unlikely.
Running Grafana is memory intensive so if you run on a SBC like a RPi you’re more likely to be out of memory.
Sorry, you´re right, I didn´t. Just did… Thank you, I have something to look at tonight…
Hmm, so what you say is, that the Rpi 3B is no longer suitable for openhab 2.4 due to be using more memory?
I know thats not what you specificly said, I just twisted it because this problem appeared after upgrading openHab from 2.3 to 2.4. So it could seem like this is the reason. Grafana has not changed, it´s still the same version.
Any restart results in actual memory usage to change. And mem is so tight on any RPi that if you run OH PLUS (probably) InfluxDB PLUS Grafana any small change might be that little drop that makes the barrel overflow.
I’d remove it from there and run on another computer instead.
But we’re off-topic now.
About the harmonyhub communication error:
This is harmony hub firmware 206. Logitech have removed access on port 522, so the binding will no longer work at all.
Not an OH issue.
I have hacked together an MQTT interface to the websockets server on harmony port 8088, this replaces the harmonyhub binding functionality, by using mqtt items.
The harmonyhub binding would have to be rewritten to use the websockets interface in order to restore functionality.
1 Like
Alternative:
Interesting, looks like Logitech bowed to pressure.
I can’t see this developer version lasting though. I’ll probably stick with my hacked websockets version for now, it’s working well.
I have the same problem with ThingAction. But if I remove ThingAction. I get the same error for the getThinfstatus expression. Could you please poste your code line with the ThingAction part.
Thanks a lot!
Before:
var status = ThingAction.getThingStatusInfo("zwave:device:uzb:node26").getStatus()
After:
var status = getThingStatusInfo("zwave:device:uzb:node26").getStatus()
Thank you!
FYI: I’ve just did a 2.5.0.M1 build, which is available in the usual places - unfortunately, I don’t have a change log available for it, but all changes since 2.4 that have been merged until yesterday are included.
6 Likes
Thanks.
FWIW, can you (@benjy ?) please re-affirm what’s the current repo.
I used to have
#deb https://dl.bintray.com/openhab/apt-repo2 testing main
which was the latest to find mentioned in this thread, too.
But I had to change to the same as for the snapshots in order to get to see the M1 build, i.e.
deb http://openhab.jfrog.io/openhab/openhab-linuxpkg testing main
Is thath correct ?
You can see that the apt package is available here: https://bintray.com/openhab/apt-repo2/openhab2
But due to quota constraints, we might move it in the future to artifactory, but that’s not yet the case.
I can’t get the latest milestone, apt tells me that all packages are up to date. I have this in my /etc/apt/sources.list.d/openhab2.list:
deb https://dl.bintray.com/openhab/apt-repo2 testing main
I used this to get the 2.4 milestones, but now I get nothing. I also tried updating to milestone through openhabian-config, but no dice…
All builds are put into Artifactory before being distributed to Bintray, so while the Artifactory repo will work, the Bintray repo will be faster and more stable.
Mind, there’s a problem I need to look at where Bintray isn’t allowing the download of packages automatically. I’ve just fixed this for the new M1 build.
1 Like