openHAB Milestone builds


I don’t know the root cause, but I was getting an error just now on my Pi when I tried to upgrade.

E: The repository ' testing Release' is no longer signed.

If it helps anyone, I cleared the error by clearing the apt cache and regenerating it.

sudo apt-get clean
sudo mv /var/lib/apt/lists /tmp
sudo mkdir -p /var/lib/apt/lists/partial
sudo apt-get clean
sudo apt-get update

I now get a warning, but at least I could update openHAB.

W: The repository ‘ testing Release’ is not signed.


This might be related to the fact that I had to remove some older versions (such as 2.3.0.RC1) from the apt repo to make some space for the 2.4 release. @Benjy I assume that might have broken the signature of the repo - how to bring it back? Will it automatically be properly signed again upon the next milestone publication?

The warning shouldn’t appear anymore, the repos have been re-signed.


for me the Harmony binding stopped to work after update today.
have deleted the binding and things + fresh install and discover but no success :frowning:
Status: OFFLINE - COMMUNICATION_ERROR Could not connect: Failed communicating with Harmony Hub
anyone else has the same issue ?

I have the same problem! I just wanted to create a new topic for this!

It seems that the problem is not OH (I think). Harmony Hub updated itself for me, during the evening, after that I can’t access it…

I ran into the same issue while updating the Hub to the 4.15.206 firmware.

See: Logitech Harmony Hub Binding - Communication error 4.15.206 firmware

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


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


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!


var status = ThingAction.getThingStatusInfo("zwave:device:uzb:node26").getStatus()


var status = getThingStatusInfo("zwave:device:uzb:node26").getStatus()

Thank you!