I have the issue that since I upgraded from 2.5.9 to 2.5.10 the huebinding is unusable as it delays all commands for at least one minute.
Meaning, if I press the button in the sitemap (basicUI or classicUI) the light turns on/off after a 1 minute delay.
It all works when using the official Hue App on my phone or Alexa, so the issue seems not to be with the bridge or it’s connection to the lights or network.
I uninstalled the binding, I uninstalled all bindings, I restarted several times, I cleared the cache nothing helps. I use the huebinding since ages and it only started after the upgrade to 2.5.10. I cannot see any significant changes in the changelog that would cause this.
Please see the debug log entries below, you see the timestamp show that the command to the bridge gets send with a delay.
-> PRESS BUTTON IN SITEMAP TO ON
2020-11-28 20:47:49.126 [DEBUG] [hue.internal.handler.HueLightHandler] - onLightStateChanged Light Shelf Light: on false bri 3 hue 0 sat 0 temp 0 mode null XY null
2020-11-28 20:47:49.155 [DEBUG] [hue.internal.handler.HueGroupHandler] - onGroupStateChanged Group Group 0: on false bri 0 hue 0 sat 0 temp 0 mode null XY null
2020-11-28 20:47:49.156 [DEBUG] [hue.internal.handler.HueGroupHandler] - onGroupStateChanged Group Wohnzimmer: on false bri 0 hue 0 sat 0 temp 0 mode null XY null
-> MASSIVE DELAY
2020-11-28 20:50:10.007 [DEBUG] [nhab.binding.hue.internal.HttpClient] - Async sending put to address: http://192.168.0.20:80/api/pcfthpu9mIZIsUz-mAt0iZFC4y1cgqPuvIEJKccj/lights/7/state delay: 40 body: {"on":true}
2020-11-28 20:50:51.087 [vent.ItemStateChangedEvent] - Tradfri_L_Shelf_B changed from 100 to 2
2020-11-28 20:50:51.086 [DEBUG] [hue.internal.handler.HueLightHandler] - onLightStateChanged Light Shelf Light: on true bri 3 hue 0 sat 0 temp 0 mode null XY null
2020-11-28 20:50:51.115 [DEBUG] [hue.internal.handler.HueGroupHandler] - onGroupStateChanged Group Group 0: on true bri 3 hue 0 sat 0 temp 0 mode null XY null
2020-11-28 20:50:51.116 [DEBUG] [hue.internal.handler.HueGroupHandler] - onGroupStateChanged Group Wohnzimmer: on true bri 3 hue 0 sat 0 temp 0 mode null XY null
-> PRESS BUTTON IN SITEMAP TO OFF
2020-11-28 20:52:01.374 [ome.event.ItemCommandEvent] - Item 'Tradfri_L_Shelf_B' received command OFF
2020-11-28 20:52:01.378 [nt.ItemStatePredictedEvent] - Tradfri_L_Shelf_B predicted to become OFF
2020-11-28 20:52:01.382 [vent.ItemStateChangedEvent] - Tradfri_L_Shelf_B changed from 2 to 0
2020-11-28 20:52:07.344 [vent.ItemStateChangedEvent] - Presence_IPHONE11 changed from OFF to ON
-> MASSIVE DELAY
2020-11-28 20:54:11.043 [DEBUG] [nhab.binding.hue.internal.HttpClient] - Async sending put to address: http://192.168.0.20:80/api/pcfthpu9mIZIsUz-mAt0iZFC4y1cgqPuvIEJKccj/lights/7/state delay: 40 body: {"on":false}
2020-11-28 20:54:14.680 [DEBUG] [hue.internal.handler.HueLightHandler] - onLightStateChanged Light Shelf Light: on false bri 3 hue 0 sat 0 temp 0 mode null XY null
2020-11-28 20:54:14.682 [vent.ItemStateChangedEvent] - Tradfri_L_Shelf changed from ON to OFF
2020-11-28 20:54:14.710 [DEBUG] [hue.internal.handler.HueGroupHandler] - onGroupStateChanged Group Group 0: on false bri 0 hue 0 sat 0 temp 0 mode null XY null
2020-11-28 20:54:14.710 [DEBUG] [hue.internal.handler.HueGroupHandler] - onGroupStateChanged Group Wohnzimmer: on false bri 0 hue 0 sat 0 temp 0 mode null XY null
Any help is highly appreciated!
I am not sure what else I can do to fix this expect reinstall the whole machine and hope that it goes away.
I am running openHAB2 on an Intel NUC i7 with Ubuntu 20.04.1 x64.
Java Zulu JDK8
After some more debugging and testing it seems the issue is related to the “MIIO Binding” or the “Network Binding”, or both.
Both bindings were updated from 2.5.9 to 2.5.10.
Both bindings discover devices on the network and check their status, is it possible that the Hue HTTP Request gets delayed because the Hue Binding waits for something in the Network or MIIO Binding is finished before it sends commands?
I have the same issue. My delay is not that big…around 10-15 seconds, but I am also using the Network and MIIO Binding. I’m not sure if it has startet with the update from 2.5.9 to 2.5.10, but it sounds possible. Would be great if we could find a solution. Do you have any new information?
Right now I have the MIIO Binding installed again and experience no delay.
However when I install the Network Binding the delays start again. Right after installing the binding the delays are around 3-4 seconds but then they increase after a few minutes to 1-2 minutes.
Could you please also test if removing the network binding solves the issue?
For me it seems something is waiting for something to finish before sending the hue command…
Maybe the authors of the network binding could have a look?
I’ve just realised that I am not using the Network Binding. I’ve installed it some time before, but it isn’t in use at all. Its uninstalled now and I’ll test later (when I’m at home) if the response of my hue lights is faster now. Thanks for your research!
When I came home it was okay. My Hue light at the frontdoor, which is controlled by the PIR of my doorbell through openHAB, was pretty responsive. But later i’ve tried some other lights and the have still a delay. Not everytime - sometimes it’s perfect - but sometimes I have to wait for 4-7 seconds. Do you have any MIIO devices which are offline the most time. There was an issue earlier with the MIIO binding where offline devices have produced more and more open connections in openHAB. I know that I have at least one MIIO devices which is offline most of the time. My Mi Smart Fan is only reachable when I use it in the summer. Maybe it has something to do with offline MIIO devices.
No…couldn’t find it. But this was fixed long time ago and maybe has nothing todo with our issue. It was just an idea because you guessed that it could belong to it. Did you’ve found anything new? I’ve still the Hue delays.
Just watch the top output while doing the action that is delayed, and if the /usr/bin/java (=openHab) process starts using upwards to 100% or more CPUs, there is a hint of trouble.
But, it could also be other processes slowing OH down, and in you screenshot, your Plex process uses so much CPU, 99.8% that that could be the reason for the delays you are seeing.
Try killing it off and see if that helps.
A CPU usage of 100% hogs a core in the CPU. That is why, on multiple core systems, you can see CPU usage of more than 100%. It is usually a sign of trouble if it continues for a long time.
Is there a solution to the problem in the meantime? I am now observing the behaviour with the latest Openhab3 version. I do not use the network binding, but the Miio binding.
