search

openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.88k stars 3.59k forks source link

[hue] 3.4.0 upgrade introduced delay issues #14107

Closed JohannesPtaszyk closed 1 year ago

JohannesPtaszyk commented 1 year ago

I recently upraded my system from 3.3.0 to 3.4.0. With that update I noticed my hue devices responding really slow (delay of up to 40 seconds).

Expected Behavior

Hue devices should update almost immediately.

Current Behavior

Hue devices become slow after a couple of interactions (e.g. Switching off/on lamps).

Possible Solution

No real solution, but it can be fixed for a small amount of time, by restarting openhab.

Steps to Reproduce (for Bugs)

  1. Start openhab after 3.4.0 upgrade
  2. Toggle lamps on and off
  3. After a couple of times (for me around 30-40 interactions) the devices start to respond really slow

Context

Your Environment

openhab-bot commented 1 year ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/hue-slow-delay-after-3-4-0-update/142435/7

JohannesPtaszyk commented 1 year ago

Looking through the commits on hue binding, I would say that if the issue is the result of one of the latest commits, it is probably most likely this one: https://github.com/openhab/openhab-addons/commit/ee34d92c1706727df7e4b364f623684172b59d5f

Currently I am looking into these changes to see if there is code that could be causing the delay. However since I am not very familiar with the binding and the core itself, support would be highly appreciated.

maltemx commented 1 year ago

I have the same issue, works fine directly after restarting openhab, but after a few actions, it takes more than a minute from sending a command to a reaction of the hue component.

I would like to mention tough, that there has been a recent firmware update for the hue bridge, which might also have something to do with that. Since this was also only a few days ago, I can't say with certainty that the symptoms didn't start with the firmware update....

lolodomo commented 1 year ago

No such issue with an old bridge V1.

lolodomo commented 1 year ago

Someone on the community forum resolved this problem by rebooting the Hue bridge. @JohannesPtaszyk : please try it and close the issue if it works better after hue bridge reboot.

jlaur commented 1 year ago

No such issue with an old bridge V1.

I don't have the issue with V2 bridge either. I'm not sure it's related to the bridge generation. The shared HTTP client is now being used, which perhaps makes the binding more vulnerable to problems in other bindings. I have issues with short bridge disconnections after the change to shared client and HTTPS. But I also have problems with general system stability - after a few days everything slows down significantly, and for sure I can't have openHAB running for more than a week without a restart. I have my eyes on a few bindings I need to investigate more. Just wanted to add that it might be a somewhat complex issue perhaps not entirely isolated to the Hue binding.

JohannesPtaszyk commented 1 year ago

Reboot did, sadly, not help. However restarting openhab does, as mentioned, help for a few hours.

andrewfg commented 1 year ago

Just to say that #13570 will probably resolve this, because a) it uses SSE for event driven status updates, and b) HTTP 2.0 for faster persistent stream throughput.

lolodomo commented 1 year ago

Just to say that #13570 will probably resolve this, because a) it uses SSE for event driven status updates, and b) HTTP 2.0 for faster persistent stream throughput.

I am now afraid, you are keeping the current behavior for old bridge not supporting SSE?

lolodomo commented 1 year ago

Someone on the community forum reported that switching hue binding to HTTP solved his problem.

jlaur commented 1 year ago

Someone on the community forum reported that switching hue binding to HTTP solved his problem.

Unfortunately that is only a temporary solution: https://developers.meethue.com/develop/application-design-guidance/using-https/

The Hue API can currently be accessed over HTTP on port 80 and HTTP over TLS (HTTPS) on port 443. For security reasons HTTP access to the API will be disabled in a future firmware release. This section explains the differences and how to upgrade to HTTPS.

This page also mentions performance, so actually this might be something to double-check:

Performance For performance reasons it is important to make sure consecutive requests within a short timeframe share the same connection by keeping the connection alive. This is typically supported by proper HTTP client libraries. The Hue Bridge also supports stateless session resumption with TLS session tickets, which we prefer clients to use to quickly resume TLS sessions on consecutive connections.

lolodomo commented 1 year ago

Maybe the thread pool for things is more or less exhausted due to other OH stuff (other bindings) ?

I I correctly remember, there is a frequent poll if you are using sensors. Maybe you should check that you have not set a very small value. In my case, it is disabled (I set the parameter sensorPollingInterval to 0 because I have no sensors). Default is 500ms.

JohannesPtaszyk commented 1 year ago

Tried a sensor poll-timing change, but even values above 1,5 seconds do not change behavior.

JohannesPtaszyk commented 1 year ago

Seems to be fixed in 3.4.1 somehow. Does anyone have an idea why? 🤔

lolodomo commented 1 year ago

@jlaur : is it solved for you after you stabilized some other bindings you are using?

@JohannesPtaszyk @maltemx : is it confirmed to be fixed for you using 3.4.1?

lolodomo commented 1 year ago

Does anyone have an idea why? 🤔

Maybe due to fixes for other bindings you are using?

maltemx commented 1 year ago

For me, 3.4.1 fixed it, too. Reaction times are back to "instant", behavior is like it was before 3.4.0.

Before 3.4.1 came out, I tried fixing it by deactivating other bindings that weren't that important to me. I was able to reduce the delay from >1-2 minutes to ~2-5 seconds (the delay wasn't consistent, sometimes more, sometimes less), but it still was a noticeable delay I couldn't get rid of.

To me, it looked more like a general resource problem (like a queue being full until things time out), since I wasn't able to pinpoint it to a single other binding. It seemed that the fewer bindings I had activated, the shorter the delay got.

jlaur commented 1 year ago

is it solved for you after you stabilized some other bindings you are using?

I think actually it's fixed for me after I was able to pinpoint a problem in the WeMo binding. I initially improved my monitoring rules intended to detect offline sensors etc. to not notify me when the bridge itself was offline. I still get notifications about the bridge being offline, but haven't seen it for weeks.

lolodomo commented 1 year ago

@JohannesPtaszyk: please close this issue if the problem is confirmed to be solved also for you.

JohannesPtaszyk commented 1 year ago

Yes, seems like it was related to the Chromecast binding having so many issues with http requests.

Closed :)