Delay during "bri" change on TRADFRI bulbs starting deCONZ v2.05.76+

[stickpin]

Hi All,

Starting deCONZ v2.05.76+ I see a strange behavior once I am sending two simple commands at once to all my TRADFRI bulbs. It's creating some kinds of glitchy effect.
It looks like a bulb, first of all, turning on with low brightness bri 2 or something like this and after some delay which is varies it's changing bri to 254, which creates a very ugly effect. I don't see such an issue by sending the same payload to my Philips Hue bulbs.

PUT /api/<key>/lights/17/state HTTP/1.1
Host: IP:PORT
Content-Type: application/json

{
	"on": true,
	"bri": 254
}

Any suggestion?

Thanks in advance.

[stickpin]

Here's in the log on the deCONZ side:

13:23:07:567 button 1002 On
13:23:07:668 delay sending request 53 dt 0 ms to <MAC_ADDRESS>, ep: 0x01 cluster: 0x0006 onAir: 1
13:23:07:668 delay sending request 55 dt 0 ms to <MAC_ADDRESS>, ep: 0x01 cluster: 0x0008 onAir: 1
13:23:07:668 delay sending request 56 dt 0 ms to <MAC_ADDRESS>, ep: 0x01 cluster: 0x0300 onAir: 1
13:23:07:716 	<MAC_ADDRESS> force poll (2)
13:23:07:733 ZCL attribute report <MAC_ADDRESS> for cluster: 0x0006, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
13:23:07:737 <MAC_ADDRESS> level 254 --> 2
13:23:07:737 ZCL attribute report <MAC_ADDRESS> for cluster: 0x0008, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
13:23:07:768 delay sending request 55 dt 0 ms to <MAC_ADDRESS>, ep: 0x01 cluster: 0x0008 onAir: 1
13:23:07:768 delay sending request 56 dt 0 ms to <MAC_ADDRESS>, ep: 0x01 cluster: 0x0300 onAir: 1
13:23:07:815 	<MAC_ADDRESS> force poll (2)
13:23:07:869 delay sending request 56 dt 0 ms to <MAC_ADDRESS>, ep: 0x01 cluster: 0x0300 onAir: 1
13:23:07:913 	<MAC_ADDRESS> force poll (2)
13:23:08:014 	<MAC_ADDRESS> force poll (2)
13:23:08:724  <MAC_ADDRESS> level 2 --> 254
13:23:08:724 ZCL attribute report <MAC_ADDRESS> for cluster: 0x0008, ep: 0x01, frame control: 0x08, mfcode: 0x0000 

As you can see at 13:23:07:737 it set level 254 --> 2 and almost a second after 13:23:08:724 level 2 --> 254 which may explain this glitching.

[ebaauw]

It looks like a bulb, first of all, turning on with low brightness bri 2 or something like this and after some delay which is varies it's changing bri to 254

Indeed, see #1111 (comment).

which creates a very ugly effect.

I assume you're referring to the API resource, not to the light itself? What happens is that the API updates its cache with the value PUT (254). Then the light issues a report for bri 2, followed by a report for bri 254, after the transition has finished.

I don't see such an issue by sending the same payload to my Philips Hue bulbs.

They don't support attribute reporting. And when an IKEA light is connected to the Hue bridge, the bridge doesn't configure attribute reporting.

[stickpin]

It looks like a bulb, first of all, turning on with low brightness bri 2 or something like this and after some delay which is varies it's changing bri to 254

Indeed, see #1111 (comment).

which creates a very ugly effect.

I assume you're referring to the API resource, not to the light itself? What happens is that the API updates its cache with the value PUT (254). Then the light issues a report for bri 2, followed by a report for bri 254, after the transition has finished.

Not really, I am actually talking about light (bulb) itself, not API response, which doing kind of flicking effect once you turning it on. What you see in the log that I've posted above, this is what is actually happening with the light (bulb). It's turning on with low brightness (2) and after second or sometimes even more changing brightness to 254.

I don't see such an issue by sending the same payload to my Philips Hue bulbs.

They don't support attribute reporting. And when an IKEA light is connected to the Hue bridge, the bridge doesn't configure attribute reporting.

I don't use Hue Bridge, all my bulbs connected to the same deCONZ environment.
And as I've said this delay issue was not present in v2.05.75 and older... I guess it's related to light logic refactoring...

[ebaauw]

Hm, what bulbs? What bulb firmware (ZLL vs ZB3)?

[stickpin]

AND

[stickpin]

@ebaauw any ideas? :)

[ebaauw]

Need to dust off my IKEA bulbs and test. Not sure if I'll have the time before this weekend.

[stickpin]

Need to dust off my IKEA bulbs and test. Not sure if I'll have the time before this weekend.

No rush. Thanks a lot for your effort!

[ebaauw]

OK, I see what you mean. When using longer transition times, e.g. {"on": true, "bri": 254, "transitiontime": 100} it looks "normal", but with shorter transition times, the light seems to pause between turning on and moving to the requested brightness. I don't see this on Hue lights.

[stickpin]

OK, I see what you mean. When using longer transition times, e.g. {"on": true, "bri": 254, "transitiontime": 100} it looks "normal", but with shorter transition times, the light seems to pause between turning on and moving to the requested brightness. I don't see this on Hue lights.

Yes, that correct. But as I was saying it was not present before deCONZ v2.05.76+. It looks like something in the lights refactoring code leading to this behavior. I hope you will be able to find the root cause. :)

Thanks a lot for your support!

[ebaauw]

It looks like something in the lights refactoring code leading to this behavior.

Yes, by design, see #2553.

I'm afraid this is yet another area where the Zigbee standard leaves too much room for interpretation and different manufacturers have implemented this differently, causing different behaviour by different lights. Handling this is becoming unmanageable in the current code; we really need APIv2 capabilities.

The sending Move to Level (with On/Off), On, Move to Level works, but sometimes I see a slight tinkle in the light. I think we'd want to send either Move to Level (with On/Off) or On, but not both. That would mean whitelisting the lights that actually turn on on Move to Level (with On/Off), just like whitelisting the Hue lights for Off with Effect. Without light capabilities, this becomes unmanageable. Again, LightNode seems the logical place to implement these.

Looking at the sniffer, I'm still sending On in between the Move to Level (with On/Off) (2, 0) and the Move to Level (bri, tt). Testing what happens if I don't...

Ok that's better, but still not as smooth as the Hue lights.

Another fun difference: when sending {"on": true} after {"on": false, "brI": 1}, the Hue lights come on at brightness 1; the IKEA at full brightness.

It looks like both IKEA and Hue lights react "normally" to Move to Level (with On/Off) (bri, tt) when they're off. Makes me wonder why the Hue bridge sends two commands. Maybe for some ancient Hue firmware or pre-Hue Philips lights?

[stickpin]

The issue seems to be still present after deCONZ v2.05.78. :(

[stickpin]

One more finding after deCONZ v2.05.78.

If I am sending request in the following way:

{
	"on": true,
	"bri": 254,
	"transitiontime": 2
}

It looks more or less ok.

but If I send it with "transitiontime": 0

{
	"on": true,
	"bri": 254,
	"transitiontime": 0
}

The Ikea bulbs are "jumpy".

[stickpin]

A bit more info...
I was checking what exactly Home Assistant is sending to deCONZ.
And this is what being send:
2020-06-18 21:43:55 DEBUG (MainThread) [pydeconz.gateway] Sending "put" "{'on': True, 'xy': (0.459, 0.408), 'bri': 254, 'transitiontime': 0}" to "172.30.33.0 /lights/17/state"

So if the request sent as:

{
	"on": true,
	"xy": "(0.459, 0.408)",
	"bri": 254
}

It's working fine.

If you add "transitiontime": 0 it's "jumping".

Home Assistant for IKEA bulbs sending it by default:
https://github.com/home-assistant/core/blob/e92e26b73a57f0d615e293984701c691558b185d/homeassistant/components/deconz/light.py#L158

Which is required due to the known issue with color transition.

@ebaauw any chance you can try to resolve it?

This issue is not present in deCONZ v2.05.75.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stickpin]

The issue still not resolved.
@ebaauw any chance you can try to find a solution for it?

Thanks in advance.

[ebaauw]

No, this needs to be solved in the IKEA firmware. Until then, use the transitiontime workaround (for a lousy user experience) or make HA send separate requests for on/bri vs xy.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.