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.
3 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 
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… 
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.
I also tried changing the timing-settings for polling from the bridge, but I couldn’t see any differences.
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.
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.
Update: Still working fine 2 days later. Lets see where we get end of the week
Seems like 3.4.1 magically fixed the issue.
Not for me! Anyone else still seeing very slow hue responses?
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