Hue slow/delay after 3.4.0 update

jptaszyk · January 14, 2023, 10:40pm

I also tried changing the timing-settings for polling from the bridge, but I couldn’t see any differences.

CrazyElectron · January 15, 2023, 7:28am

My issue was a bit different, but moving several switches and lights from the bridge that had about the maximum number of devices to the second bridge that had only a few devices solved my issue of missed key presses completely.

jptaszyk · January 21, 2023, 3:54pm

After upgrade to 3.4.1 my system is running smooth for a few days now.
Will keep track and report here. If everything runs smooth til end of the month I will close th GH issue.

jptaszyk · January 23, 2023, 8:18pm

Update: Still working fine 2 days later. Lets see where we get end of the week

jptaszyk · January 25, 2023, 7:52pm

Seems like 3.4.1 magically fixed the issue.

SteveBuckell · February 2, 2023, 9:36pm

Not for me! Anyone else still seeing very slow hue responses?

Casa75 · February 10, 2023, 2:00pm

I also have slow responses and I run on 3.4.1.
It started when I updated from 3.2.0 to 3.4.1

Jens_Schanz · February 10, 2023, 3:22pm

Yes … After a restart, the delay ist back.

SteveBuckell · February 10, 2023, 5:31pm

Does anyone have any thoughts on how to troubleshoot / fix? Happy to help but not really sure where to start. It’s quite a big deal for me as I have numerous motion sensors that trigger lights and none of this is working currently

laursen · February 10, 2023, 6:28pm

Some of you having a V2 bridge might want to try a new version:

github.com/openhab/openhab-addons

Comment by andrewfg to [hue] Implement CLIP 2 / API v2

openhab:main ← andrewfg:#13456-hue-clip2

@J-N-K and other testers FYI .. concerning the issue with the OH core and the Je…tty dependencies: notwithstanding the dependency, you can still test the code already as follows.. - Place the binding Jar, and all the dependency Jetty Jars in the ‘addons’ folder. - This causes the Jetty Jars to be loaded at start level 80 — which is too late for HTTP2 Hpack to be properly initialised. - The binding detects if Hpack is NOT properly initialised and so it uses HTTP/1.1 for its PUT calls. - Use the karaf ‘bundle:list -t 0’ command to identify the bundle Id of the ‘Jetty :: HTTP2 :: HPACK’ bundle (say e.g. 123), and then use ‘bundle:start-level 123 30’ to cause that bundle id to be started earlier i.e. at start level 30 versus start level 80. - Reboot the system. - The binding now detects that Hpack IS properly initialised, and so it uses HTTP/2 for its PUT calls. Note: once the OH core will have been updated so that the Jetty Http2 jars are included in the main system installation, then the above tricks will no longer be required, and the binding will therefore always use HTTP/2 for PUT calls.

This would not help finding the root cause for this problem, but serves two other purposes:

Helps testing the new version.
Could possibly solve your problem, since it works quite differently.

struppie · June 19, 2023, 7:04pm

Did anybody find a solution for the slow behaviour?
I recognized slow updates from the Hue motion sensors out of a sudden.
I was using the Hue binding successfully for a long time and didn’t touch anything of my OpenHAB v3.4.1. Maybe this is related to automatic updates of the Philips Hue Bridge itself, which were done during May.
Updating to OpenHAB v3.4.4 did not help.
It’s definitely an issues with OpenHAB/Hue binding, because I see other apps (like Apple HomeKit) and the native Philips Hue App reporting quickly about movings via the Hue motion sensors. Only OpenHAB needs up to about 1 minute to report about changes. Checked via events.log file.

Unfortunately the recommended new version of the Hue binding with API v2 support does not work with my OpenHAB installation - opened different thread for this.

Any help / ideas appreciated

ubeaut · June 24, 2023, 9:02am

I am using Openhab 3.4.4 and Hue motion sensor and it works fine but I am using zigbe2mqtt.
I haven’t had any issues regarding slow response.