IKEA light bulbs acting weird

[simplenotezy]

I am using Conbee II as my bridge. I have created a scene in Homekit. It sets the bulbs to different values (sometimes) and I have to click the scene multiple times before it's correctly set.

Not sure what's going on there.

Have a look: https://youtu.be/9MiVmj2e6C4

[ebaauw]

Please capture and attach a debug log file, see https://github.com/ebaauw/homebridge-hue#debug-log-file.

[simplenotezy]

Will do

[simplenotezy]

I have yet to provide you with a log, however, I will give it soon.

I do, however, consider going back to the Hue Bridge and then only using the deCONZ/Procons GW for stuff such as IKEA sensors / Phillips Hue Switches (to get them to Homekit) and then having the rest in Hue. Do you have any experience / recommendations regarding this approach?

It seems like the Hue Bridge might be more stable than deCONZ. I saw that you posted an issue on their GitHub some months ago and no real response has come from their developers so I fear it's not as well maintained.

What are your thoughts @ebaauw

[ebaauw]

It seems like the Hue Bridge might be more stable than deCONZ.

I don't think that wording is correct, but certainly, the typical Zigbee network formed by a Hue bridge is more stable than the typical Zigbee network formed by deCONZ. The stability issues are due to network size and combining Zigbee devices from different vendors. People move to deCONZ because they want to use devices that aren't supported by the Hue bridge and/or because they want to overcome the (practical) size limitations imposed by the Hue bridge.

I saw that you posted an issue on their GitHub some months ago and no real response has come from their developers so I fear it's not as well maintained.

Check the Hue developers forum for Hue bridge issues that haven't been addressed for five years or longer (I only joined in 2014). Most prominently: the lack of push notifications by the Hue bridge. The deCONZ REST API is open source, so at least you can do something yourself, addressing issues. Of course, when there's a viable workaround, there's less priority to address an issue.

I do, however, consider going back to the Hue Bridge and then only using the deCONZ/Procons GW for stuff such as IKEA sensors / Phillips Hue Switches (to get them to Homekit) and then having the rest in Hue. Do you have any experience / recommendations regarding this approach?

I've been running deCONZ stably for years, over 100 devices, half routers, half end-devices. I recently split off my Eurotronic Spirit TRVs and my IKEA FYRTUR smart blind and controller to a second Zigbee network, formed by a second installation of deCONZ, because they kept becoming unreachable. I've had no issues with these devices since. I use a single IKEA repeater on the second network for reach, otherwise it's just the end-devices.

Splitting your network between lights and controllers might not be the optimal design:

• The end-devices need routers (lights) for connectivity, but you might use some repeaters instead (as I have).
• You can no longer control the lights directly from the controller (so they work even when the gateway is down).
• You can no longer use gateway/bridge rules to control the lights. I'm experimenting with web hooks from deCONZ rules, to update a CLIP sensor on the other gateway (or Hue bridge), triggering rules on that gateway/bridge. It seems to work reliably, but is somewhat limited as you need a separate rule for each sensor value. I wouldn't recommend this approach to non-tech-savvy people.

I would rather split by vendors that seem to work well together. I still haven't been able to find the source of my reachability issues; it could be some Xiaomi and innr routers still in my network; it could be the end-devices themselves. Splitting off the end-devices was easier for me, as they're controlled by the Daylight sensor and local time, which are available on each gateway/bridge.

[simplenotezy]

Thanks for your throughout answer. I will share some dump logs as soon as I can.

[Einstein2150]

I can confirm issues with scenes and Ikea bulbs too. I try to support you with a log too. In my case switching on and off and setting the light spectrum works but not dimming. Dimming up or down is mostly ignored. For example the light is at 80% but HomeKit and the DeCONZ Web UI is showing it at 1%. Reading the node info in the VNC Session gives 80%. I looks like it gets lost somewhere ...

[Einstein2150]

I created two Scenes "Test Tag" and "Test Nacht":

"Test Tag": "Deckenlampe Büro" gets Cool and Bright, "Tischlampe Büro" gets Cool and off
"Test Nacht": "Deckenlampe Büro" gets Warm and Dark, "Tischlampe Büro" gets Warm and Bright

Switching between the scenes changes Cool/Warm every time but the brightness and on/off-state are randomly not triggered (often after the third activation of the scene"

Here are screenshot from switching through the scenes:

Here you can see that the Deckenlampe Büro changed from 95% to 1% but stays at Level 241

Here you can see that the Deckenlampe Büro changed from 1% to 95% but stays at Level 3

Manual activities for example dimming in the Home-App are triggered correctly in real-time

[Einstein2150]

@ebaauw here is the log:

homebridge.log.gz

I think the problems are the alerts triggered after setting the scene and the ignoring of settings:

set scene:
[37m[18.11.2020, 10:34:55] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 13: put /lights/15/state {"bri":3,"ct":413}�[39m
�[37m[18.11.2020, 10:34:55] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 14: put /lights/17/state {"bri":231,"on":true}�[39m
�[37m[18.11.2020, 10:34:55] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 13: ok�[39m
�[37m[18.11.2020, 10:34:55] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 14: ok�[39m

�[37m[18.11.2020, 10:34:55] �[39m�[36m[Hue] �[39m�[90mDeckenlampe Büro vorne: state changed event: {"alert":null,"bri":3,"colormode":"ct","ct":413,"on":true,"reachable":true}�[39m
�[37m[18.11.2020, 10:34:55] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: state changed event: {"alert":null,"bri":231,"colormode":"ct","ct":413,"on":true,"reachable":true}�[39m
�[37m[18.11.2020, 10:34:55] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: attr changed event: {"colorcapabilities":0,"ctmax":65279,"ctmin":0,"id":"17","lastannounced":"2020-11-12T16:15:35Z","lastseen":"2020-11-18T09:34Z","manufacturername":"IKEA of Sweden","modelid":"TRADFRI bulb E14 WS 470lm","name":"Tischlampe Büro","swversion":"2.3.050","type":"Color temperature light","uniqueid":"bc:33:ac:ff:fe:61:c4:e7-01"}�[39m
�[37m[18.11.2020, 10:34:55] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: state changed event: {"alert":null,"bri":2,"colormode":"ct","ct":413,"on":true,"reachable":true}�[39m
�[37m[18.11.2020, 10:34:55] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: light bri changed from 231 to 2�[39m
�[37m[18.11.2020, 10:34:55] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: recently updated - ignore changed bri�[39m
�[37m[18.11.2020, 10:34:56] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: state changed event: {"alert":null,"bri":231,"colormode":"ct","ct":413,"on":true,"reachable":true}�[39m

and:

[37m[18.11.2020, 10:35:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 17: put /lights/15/state {"ct":250,"bri":241}�[39m
�[37m[18.11.2020, 10:35:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 18: put /lights/17/state {"on":false,"ct":165}�[39m
�[37m[18.11.2020, 10:35:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 17: ok�[39m
�[37m[18.11.2020, 10:35:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 18: ok�[39m

�[37m[18.11.2020, 10:35:01] �[39m�[36m[Hue] �[39m�[90mDeckenlampe Büro vorne: state changed event: {"alert":null,"bri":241,"colormode":"ct","ct":250,"on":true,"reachable":true}�[39m
�[37m[18.11.2020, 10:35:01] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: state changed event: {"alert":null,"bri":231,"colormode":"ct","ct":165,"on":false,"reachable":true}�[39m
�[37m[18.11.2020, 10:35:01] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: state changed event: {"alert":null,"bri":231,"colormode":"ct","ct":364,"on":false,"reachable":true}�[39m
�[37m[18.11.2020, 10:35:01] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: light ct changed from 165 to 364�[39m
�[37m[18.11.2020, 10:35:01] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: recently updated - ignore changed ct�[39m

[ebaauw]

I think the problems are the ignoring of settings:

No that's completely unrelated.

The issue is caused by a firmware bug in the IKEA lights, see dresden-elektronik/deconz-rest-plugin#3507. From the HomeKit scene, you set both brightness and colour temperature, which Homebridge Hue translates into a single API call (per light) setting both ct and bri. deCONZ (or the Hue bridge) translates this into two separate Zigbee commands: Move (to the Level Control cluster) and Move to Color Temperature (to the Color Control cluster), adding a default transition time of 0.4 seconds to each command. Due to the firmware bug, (some?) Trådfri lights don't accept the second command, while the transition from the first command is still in progress.

This needs to be solved by IKEA in the light firmware. Until then, there are a couple of possible workarounds:

1. Make Homebridge Hue add a transitiontime of 0 to the API call, which deCONZ/Hue bridge passes to each Zigbee command, causing the light to transitions instantly. You do this in Eve, by adding the Transition Time characteristic from the gateway/bridge accessory to the HomeKit scene. Homebridge Hue will reset this to 0.4s after the scene has been recalled. This workaround will effect all lights in the scene: you'll notice a blunt change, rather than the more subtle transition you're used to.
2. Make Homebridge Hue send two separate API calls, hoping that this will cause enough delay for the second command to arrive at the light 0.4s or more after the first command. You do this by setting waitTimeUpdate to 0 (ms) in config.json. This global setting will effect all HomeKit scenes and might cause delays in lights reacting when recalling a scene.
3. Use Zigbee scenes instead. Set both groups and scenes in config.json to expose these to HomeKit, see Expose bridge/gateway scenes to HomeKit #475.

It might be needed to combine 1 and 2, e.g. setting a transitiontime of 0.2s in combination with a 0ms waitTimeUpdate. It might also be enough just to set the transitiontime to 0.1s or 0.2s.

[Einstein2150]

Make Homebridge Hue add a transitiontime of 0 to the API call, which deCONZ/Hue bridge passes to each Zigbee command, causing the light to transitions instantly. You do this in Eve, by adding the Transition Time characteristic from the gateway/bridge accessory to the HomeKit scene.

I tried it and it works. The scene changes insane fast 😅

Make Homebridge Hue send two separate API calls, hoping that this will cause enough delay for the second command to arrive at the light 0.4s or more after the first command. You do this by setting waitTimeUpdate to 0 (ms) in config.json.

Where is the right spot to set waitTimeUpdate in the config.json? I want to try the combined settings.

[ebaauw]

Where is the right spot to set waitTimeUpdate in the config.json? I want to try the combined settings.

In the platform section for Homebridge Hue. Best use the plugin's Settings dialogue in Homebridge Config UI X (under Advanced Settings, obviously) to update config.json.

[Einstein2150]

waitTimeUpdate doesn't help. Transition Time 0 is the only suitable solution for me at this time. Other values or mixed values of solution 1 and 2 doesn't work correctly.

[ebaauw]

Can you verify in the debug log, that Homebridge Hue sends separate commands for ct and bri with waitTimeUpdate?

[Einstein2150]

with waitTimeUpdate the commands ct bri and on are transmitted separately but the lights react still crazy:

[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 23: put /lights/15/state {"bri":3}�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39mTischlampe Büro: homekit brightness changed from 90% to 56%
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 24: put /lights/17/state {"bri":142}�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39mDeckenlampe Büro vorne: homekit color temperature changed from 250 mired to 413 mired
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 25: put /lights/15/state {"ct":413}�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39mTischlampe Büro: homekit on changed from 0 to 1
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 26: put /lights/17/state {"on":true}�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39mTischlampe Büro: homekit color temperature changed from 390 mired to 454 mired
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 27: put /lights/17/state {"ct":454}�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 26: ok�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 23: ok�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 25: ok�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 24: ok�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mPhoscon-GW: gateway request 27: ok�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: state changed event: {"alert":null,"bri":142,"colormode":"ct","ct":454,"on":true,"reachable":true}�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mDeckenlampe Büro vorne: state changed event: {"alert":null,"bri":3,"colormode":"ct","ct":413,"on":true,"reachable":true}�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: state changed event: {"alert":null,"bri":142,"colormode":"ct","ct":454,"on":true,"reachable":true}�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: state changed event: {"alert":null,"bri":207,"colormode":"ct","ct":454,"on":true,"reachable":true}�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: light bri changed from 142 to 207�[39m
�[37m[20.11.2020, 07:56:01] �[39m�[36m[Hue] �[39m�[90mTischlampe Büro: recently updated - ignore changed bri�[39m

homebridge.log.gz

[ebaauw]

Homebridge Hue is still sending the requests in parallel, i.e. it’s sending the next request before the previous request has returned. You could try and set parallelRequests to 1 in combination with waitTimeUpdate. Again, this will impact overall responsiveness; using Transition Time looks weird, but, indeed, works.

[Einstein2150]

I tried parallelRequests 1 and waitTimeUpdate 0. There are still commands ignored by the lights 😞

[Einstein2150]

@simplenotezy I made a workaround for the scenes in home. I execute 2 different scenes - one changes only brightness and on/off-state and a second changes the colourtemp. By using virtual automation switches you can trigger this by one click.

Example:

For my day ambience I have a virtual switch "Tagmodus Büro" and two scenes "Büro Tag Helligkeit" and "Büro Tag Farbe". I use a transition time in each scene of around 9 Seconds. I wrote a home-automation which is triggered by turning the virtual "Tagmodus Büro"-switch to on. The automation executed the two scenes with a delay of 10 seconds between each scene. After the execution I switch the virtual switch to off again.

Here is the home-automation:

Here is the scene definition in eve:

For the virtual switch I use https://github.com/grover/homebridge-automation-switches#readme.

Here is a example config for the switch:
{ "platform": "AutomationSwitches", "switches": [ { "type": "switch", "name": "Tagmodus Büro", "stored": true, "default": false }, { "type": "switch", "name": "Nachtmodus Büro", "stored": true, "default": false } ] }