Some bindings gets into a non-responsive state every few hours (in v2.5.6 - v2.5.8)

Hi community,

I am struggeling with my Hue Binding since I updated to 2.5.6. It was working flawlessly for a long time but since a few days I encounter a really stange behaviour.

Every few hours (around 6-10 hours) my hue binding gets into a non-responsive state.
That means it is running normally after a fresh start of the openHAB service but later on the binding does not accept anymore commands. When pushing my light buttons (homematic) I see the button events correctly in the log viewer. But the rule commands for setting the lights ON and OFF are not issued against my hue bridge anymore.

When I stop (or restart) the openHAB service all former commands that weren’t issued correctly get then fired (during the service shutdown process) to the bridge so that the lights are getting the ON, OFF, ON, OFF etc. commands in a row. After the restart everything is running smooth again for the next couple of hours. It feels like the commands were queued but not processed before.

My openHAB is running on a PI 4 using - belong a few other bindings - the hue binding with two bridges. One is the original Phillips bridge and I run a DiyHue emulation bridge as well.

I already tried the following things without success:

  • There are no errors regarding showing in the logs regarding this issue, neither on INFO nor on DEGUG level
  • Reinstalling the binding
  • Clean cache
  • Deleting the DiyHue bridge to have only the original hardware bridge running
  • The bundle shows up as ACTIVE - even in the non-responsive state

Right now the system needs at least two service restarts every day :frowning:

Did someone encounter this issue, too? Any help would be highly appreciated.

Maybe a compatibility problem with your DiyHue emulation bridge?
The support of hue groups was recently added to the hue binding. Maybe this is not working well with your bridge emulator.
You could disable your emulation bridge and check if the problem is solved?
Any recent changes on your emulator?

Thanks for sharing ideas!

The DiyHue bridge is already deleted so that I run the standard Phillips Hue bridge only.
I also know about the new rooms and zone functionality which I had running correctly in 2.5.4 and 2.5.5.

Any more ideas?

Is it now ok without the diyhue bridge emulator?
Are you sure your problem only started with 2.5.6 ?

No, I have already turned off the DiyHue bridge thing since my first post (was off during all test).

But I found out another strange thing. When looking to my Grafana chart for my weather from openweathermap binding (which I recently installed, I see that there are plateau phases which I assume to be the same as the downtimes of the hue service:

I’ll try to deactive the openweathermap binding to check if that interferes with the hue binding.
Keep you updated…

Do you happen to use amazon echo binding? Several people recently unexpectedly encountered memory hog issues with that, often the first apparent clue was some other sub-system misbehaving.

Yes I do. Had the OOM issues in 2.5.4 (or 2.5.5?) and ran with the updated jar.
Since 2.5.6 this problem has gone and amazonecho binding is still working, even is hue binding is non-responsive.

:unamused: Ran into the same non-responsive hue again with openweathermaps (and diyhue bridge) disabled.
I also uninstalled 2.5.6-1 (purge, restore, clean cache) and reinstalled to 2.5.6-2 and the issue is still there.

Now I switched back to 2.5.5-1 + fix amazonecho jar again and see if it is really a version problem or something deeper in my system.

I should maybe also mention that the hue bridges (original as well as diyhue) are allways still working properly through the Hue App and I can access then from openHAB in the non-responsive state still through direct API calls with the exec binding.

Found another binding that behaves strange whilst the non-respnsive hue state. Where I can exclude the openweathermaps binding I see that system binding also reports no values in theses time whereas other bindings such as my heatpump and also homematic still keeps on reporting so that the persistence can be excluded as reason, too.

Btw, is it really only me that has this problem? No one else out there…?
Keep on reporting on the 2.5.5 + fixed jar scenario…

No problem noticed on my side, OH is running since several days without restart and I can still control my hue lights.

So, I monitered my system for now more than one week and in the constellation for having 2.5.5 incl. amazonechofix running I did NOT encounter this issue again.

Even if I can’t get a log proof for this, I assume that this is due to version 2.5.5 / 2.5.6.
@Kai, would you mind to read into this thread as this might be an information that could be important for the next release fixes? Let me know if I can help in any way.

This is probably a combination of bindings or your setup that leads to your problem.
I would be very surprised that there is a particular issue with the hue binding as I am using it myself without any problem.

In case you are not owning hue sensors, I would recommend to disable this feature by setting the refresh interval to 0 (2.5.6 version) or a very high value (<2.5.6 version - value is in milliseconds) to avoid very frequent requests to the hue bridge (twice per second by default).

That is true that mine is disabled.

Good hint with the sensor interval, which I changed immediately.

It might be indeed an issue resulting of the combination of bindings. Anyway, the combination was working since a very long time and isn’t working anymore since 2.5.6.
I’ll keep on watching this in further releases and will report back.

Thanks for sharing ideas!

Hi, are you still experiencing this issue? I am also having problems with Hue devices and have done so for approx 2 weeks. I cannot pin down what has changed, it happen around the time that I applied the Amazon binding fix, but I have disabled the binding and still have the same issues, so not sure if it is related. I am having to reboot my system about once a day. The symptoms vary, but the Hue motion sensors always cease to work after a period of time, while the Hue lights will sometimes be operational and sometimes they are not (from Openhab mobile App). If they are, then I also have some Zwave sensors that will operate the lights, but the Hue sensors will not. I thought it may be something to do with my Hue hub as it is getting pretty busy from all the lights, sensors and switches attached. I set up a 2nd Hue hub with just one sensor and 6 lights to see if that solved the issue. It did not.

I have the same issue with my HUE motion sensors (20+ of them). I’m actually running 2 different bridges to create redundancy with groups across the bridges. I actually thought it was an issue with network routing since I don’t have bulbs as repeaters so I started buying innr plugs (4x) to supplement each bridge for repeaters on the network. I’m not convinced that this step has helped or not yet.

I’m running an older version of HUE and I’ve also changed out the Amazon binding for the fix.

openhab> list -s | grep hue
212 │ Active │ 80 │ │ org.openhab.binding.hue

Best, Jay

So I did put my own post up here:

I first noticed this issue upgrading to 2.5.3 a few weeks ago but didn’t have time to investigate.
Then I see my vendor (qnap club) release the 2.5.6 update but it’s still happening.

It’s always the hue binding that causes my whole openhab to crash, nothing else in the logs other than what I put in the link above about the discovery service and too many open files.

I have 3 x genuine hue bridges linked and did not have these issues on 2.5.2

I also have the amazon echo fix installed

Please consider there were no changes of the hue binding between 2.5.0 and 2.5.3.
First enhancements started in 2.5.4.
So if your problem started with 2.5.3, it cannot be directly due to the hue binding.

I’m sure it was 2.5.3 but cannot be 100% as there were a few updates over the course of a couple of weeks on my system. Ive removed the amazon echo binding for now to test. Will report back

So I have had the amazon echo fix removed for a couple of days now And I still have a working openhab. Seems the fix didn’t fix it.