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
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
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?
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:
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.
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).
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.
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 │ 188.8.131.52908160411 │ org.openhab.binding.hue
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.