Hue slow/delay after 3.4.0 update

Hello, is anyone else facing issues with hue binding being really delayed and slow after 3.4.0 update?

Only happens with hue binding. Delay is like 10 or more seconds after I toggle something or change something.

Would be really glad if someone has ideas on how to fix this :confused:

No noticed delay for me.

I noticed today that I also haves a new bridge in my inbox. I migrated my old to https. Maybe I try to replace the old thing with the one from my inbox. Will report tomorrow…

same here - I also recognize heavy delays for HUE equipment and I also see a new HUE bridge in my inbox.

1 Like

Good to know. Did you already try replacing/redoing the hue setup?
I will do it today and will report if it helped.

Switched to the new thing that was found for the bridge and changed all the lamps etc. to it being thhe bride. Nothing changed.

One additional thing I noticed:
After reboot everything seems to be fine for a few moments.
I could reproduce the delay by just switching on and off lamps for a couple of times.

Also created an issue on Github:

1 Like

well, I didn’t have the delay problem, but all of my Hue devices stopped working after going from 3.3 to 3.4 today. I re-authed the bridge, and the bridge added as a thing says “Online”. All the other Hue devices added as things say “bridge uninitialized”. I’ve tried removing them, but they stick in a “removing” status. I’ve tried uninstalling and installing the hue binding without success.

Disclaimer: I’m running 3.3.0, not 3.4.0.

My issue is probably not the same as this as the binding has got a huge overhaul since 3.3.0, but I had a similar experience with delays. Not at first after a reboot, but after some minutes.

Turned out the thingHandler threadpool was starved, and by adding

org.openhab.threadpool:thingHandler = 20

to conf/runtime.cfg solved my issue. (I think 5 is the default in 3.3.0)

I have a rather average+ setup (including 3 Hue bridges) on a Pi4B, so my solution may not apply to your problem.

2 Likes

Since my last post, I tried to remove, then force remove all my of my hue things, including the bridge. I uninstalled the Hue binding. Rebooted. Then, installed the Hue binding.

But now, when I go to add a thing, it doesn’t find anything in the Hue binding scan. I have not yet attempted to add something manually, because something tells me it’s not going to work.

Restarting the hue bridge actually fixed my problem… shoulda tried that first…

I tried to reboot the bridge, but It is by no means better now :frowning:

All other bindings work fine.

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",
        ...
1 Like

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

1 Like

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… :sob:

Best regards,
exonix

1 Like

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?

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?

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.

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

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.