Hue slow/delay after 3.4.0 update

CrazyElectron · January 5, 2023, 10:25am

Having a somewhat related issue with the Hue binding in 3.4.0. No delays but it is frequently missing key press/release events from the Dimmer Switch (tested with model RWL022, the new model with Hue logo on the lower button).

Often have to press it a few times before a Key Press event is triggered. Also, it usually triggers only one of the events that get generated from the bridge by pressing and releasing a key. The ON/OFF key for instance when pressed briefly should generate a 1000.0 (Initial Pressed) followed by a 1002.0 (Key Short Released). But I usually only get the first and sometimes only the second, but hardly ever both.

The bridge does get the events as I can see from the CLIP debug web interface. As a test I pressed and released Key 1 on the dimmer switch and nothing shows up in events.log but the status is updated in the bridge:

{
	"state": {
		"buttonevent": 1002,
		"lastupdated": "2023-01-05T10:23:00"
	},
	"swupdate": {
		"state": "noupdates",
		"lastinstall": "2022-12-06T13:22:17"
	},
	"config": {
		"on": true,
		"battery": 100,
		"reachable": true,
		"pending": []
	},
	"name": "Hue dimmer switch 2",
	"type": "ZLLSwitch",
	"modelid": "RWL022",
	"manufacturername": "Signify Netherlands B.V.",
	"productname": "Hue dimmer switch",
        ...

jptaszyk · January 7, 2023, 1:51am

Got the same behavior with the old switch as well in addition to the delay

exonix · January 8, 2023, 3:04pm

Dear all,

initial setup of openHAB 3.4 with corresponding Hue binding was successful. But after some time of operation the whole system became very instable. Beginning with delays the system then completely froze and restarted unpredictably.
At first, cause was not identifiable: could have been openHAB itselft, zigbee2mqtt, Hue binding, my individual rules, VS Code… Log viewer did not report any clear indication.

Did several ‘Greenfield’ setup approaches with two Raspis (SSD and SD card) using latest openhabian image: at least after 18 hours of operation the system was no longer usable.

After two weeks of suffering I became aware of the change ‘HTTP → HTTPS’ for Hue binding in openHAB 3.4. Manually siwtched back to HTTP and since then openHAB 3.4 is running well.

UPDATE/EDIT: after 18h system crashed again. ‘HTTP’ did not fix it completely. Would like to downgrade binding to v3.3 but I fail in finding a way to do so…

Best regards,
exonix

Lolodomo · January 8, 2023, 10:08pm

Why do you think the crash is due to the hue binding?
Because I am using the same binding since many days without any delay or crash.
Maybe something else like another of your installed bindings is the root cause?

CrazyElectron · January 8, 2023, 10:36pm

Hi @Lolodomo, do you happen to also use Hue Dimmer Switches (old or new model)? If so, no issues with button presses often not recognized?

Lolodomo · January 8, 2023, 11:51pm

No, I don’t have such device.
Please open a separate thread to not mix different priblems.

The current thread is about the delay after a certain time leading eventually to a crash.

jptaszyk · January 10, 2023, 9:57pm

Not sure if it’s two seperate things, I will try to test without sensors on hue in the next days

Jens_Schanz · January 13, 2023, 3:58pm

I’ve been discovering this problem since openHAB 3.3. Unfortunatly it’s not reproducible for me. Sometimes it tooks a few seconds, before a openHAB-command/-event is recognized by the Hue bridge, other times it reacts in a few milliseconds.
As I have analysed this with tcpdump, there is a lot of communication between openHAB and the Hue bridge. I’m not sure if the problem occurs when you add a huge number of Hue Elements (bulbs, sensors, etc.) to the bridge or by another event. Maybee it’s possible to loose some events in case of intense communication between Bridge and openHAB. As I’ve seen in Wireshark the bridge sends Updates to openHAB while openHAB sends shortly after that new Events to the Bridge. Perhaps someone could confirm or analyze this behaviour.
I’m not sure, since when the problem exists. But I remember I’ve done something with scenes in openHAB and in the Hue App.

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.