Hue Binding gets into a non-responsive state every few hours

Tags: #<Tag:0x00007f617148a010> #<Tag:0x00007f6171489ea8> #<Tag:0x00007f6171489b60>

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.