Hue light response increasing slows up

Setup, Configuration and Use Runtime
1

I’ve just started making the move to use OpenHab as my automation hub. So far I’ve only integrated a limited number of devices, as I fully familiarise myself with the architecture. My system consists of :

  • Intel i3 CPU, 8GB DRAM, 1 x 512GB SSD system disk and 9TB magnetic disk storage

  • Windows 10 Pro 1809

  • Java (Zulu 8.40.0.25-win64)

  • OpenHAB v2.4.0 (Stable)

I have 3 bindings loaded - Drayton Wiser, Z-Wave and Hue. All appear to be working as intended, for the things and items I’ve defined, but the Hue lights become unresponsive very quickly. The other bindings seem to continue to respond as expected.

With the HUE devices, on restarting OpenHAB, everything is very responsive. But very quickly, they become laggy and within a few hours are unusable. I don’t believe it’s network latency, as pinging the Hue hub from the OpenHAB PC sees <1ms over a long period, and with no packet loss. The PC is running at about 80-85% CPU idle, and DRAM use is around 40%.

I’ve put logging into DEBUG, and can see the delay in the logs, but don’t really know what to look for in the Hue debug output. I’m also not fully familiar with what other tools may be available to help me track this down.

Below is a log extract, about 12hrs after restarting OpenHAB. You will see the entry to switch one of the bulbs on at 08:53:38, but it doesn’t appear to be sent the request until 08:54:47 - a full 1m9s later. Initially, after a restart, this all takes place in 1s.

Anyone got into any insight as to what might be the cause of this? If I can investigate further, I’m happy to take guidance on what else to try/look for, and what tools OpenHAB has to help me.

08:53:38.414 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'LivingRoomTableLampSpeaker_onoff' received command ON
08:53:38.420 [INFO ] [arthome.event.ItemStatePredictedEvent] - LivingRoomTableLampSpeaker_onoff predicted to become ON
08:53:38.421 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingRoomTableLampSpeaker_onoff changed from OFF to ON
08:54:47.341 [DEBUG] [thome.binding.hue.internal.HttpClient] - Async sending put to address: http://192.168.1.218/api/gucwxrSfRvrZlQsTMSmc83C6icra3d5YDxlsz61m/lights/10/state delay: 40 body: {"on":true}
08:54:52.874 [DEBUG] [hue.internal.handler.HueBridgeHandler] - Status update for Hue light '10' detected.
08:54:52.875 [DEBUG] [hue.internal.handler.HueBridgeHandler] - Sending lightStateChanged for light '10'
08:54:52.875 [DEBUG] [hue.internal.handler.HueBridgeHandler] - Sending lightStateChanged for light '10'
08:54:52.875 [TRACE] [.hue.internal.handler.HueLightHandler] - onLightStateChanged() was called
08:54:52.876 [DEBUG] [hue.internal.handler.HueBridgeHandler] - Sending lightStateChanged for light '10'
08:54:52.876 [TRACE] [.hue.internal.handler.HueLightHandler] - onLightStateChanged() was called
08:54:52.877 [TRACE] [.hue.internal.handler.HueLightHandler] - Received state change for another handler's light (10). Will be ignored.
08:54:52.877 [INFO ] [smarthome.event.ItemStateChangedEvent] - LivingRoomTableLampSpeaker_Color changed from 0 to 84
2

I think it you should post an issue on gitHub

3

Hey,

Thanks for the reply.

I’d assumed that this was probably a set-up / config issue of my own making, but are you suggesting that it is more likely to be a bug, and needs one of the developers to look at it? Sorry - just trying to find my way around the correct procedures, and appreciate any direction on how best to get help.

4

Hi Neil,

Thanks for reporting this issue. My first guess would be a potential memory leak. Probably in the Drayton binding as the Hue binding as well as the Zwave bindings are stable since a long time. But it is just a guess.

The best way to verify a memory leak would be to have a look into a heap dump from your system. This dump should be created at the time when the system responds slow. I posted - hopefully detailed enough - instructions on how to get it here or here. May I ask you to give it a try?

I am offering my help to analyze your heap dumb if you are able to upload it somewhere and share a link with me via PM.

1 Like
5

Hi Christoph,

Thank you for your reply. I have the dump, and will PM a Dropbox link.

6

What version of the Hue binding are you referring to as my previously stable hue implementation has been dead for weeks.

7

All versions since latest release. Currently I do not face any issues with it. What is you problem exactly. May I ask for a link or some more information? Let’s see what we can do.

8

@cweitkamp

https://github.com/openhab/openhab2-addons/issues/6121

Basically about three plus weeks ago amazon implemented new code that prevents our devices from being seen. All of my devices in the Amazon app show a status of unreachable.

Squid

9

I expected that answer.

I am afraid I cannot help you with that. We are talking about the Philips Hue binding in this case not the openHAB Hue Emulation service.

10

Is the problem solved for you by now?
Because I am facing the same problem since a few weeks.
After a while the response time for receiving the state of a Hue remote slow up to 20 seconds or more.
Also lights won’t turn on that fast anymore.

A restart of the binding doesn’t affect that much, but restarting OpenHAB helps a lot.
After that the response time becomes a second or less.

Hope there is any progression.

  • Jordo
11

Is there a solution for this problem? I having this issue with the latest Version of openhab 3. thanks.

Regards Jörg

12

I switched to Zigbee2Mqtt which improved the speed and quality of the Zigbee lights I use. Unfortunately, can’t tell you more about the hue binding.

1 Like