-
Notifications
You must be signed in to change notification settings - Fork 483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue setting bri and color (ct/xy) simultaneously in IKEA trådfri lights #895
Comments
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. |
As suggested in #894, posted on Reddit: https://www.reddit.com/r/tradfri/comments/au903n/firmware_bugs_in_ikea_bulbs/ |
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. |
To my knowledge the bug still isn't fixed. Hopefully the new device revisions which will be released in August (?) have improved firmware. |
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. |
Please check #894 for reference about the setup. I'm reporting here what it looks like a different firmware bug.
In IKEA lights, if you set
bri
and color (ct
orxy
) simultaneously in the same REST call, the light changes to the requested configuration for a fraction of a second but then goes back to the previousbri
and only the color "sticks". Setting it separately works. Strangely, if you set both and also specifytransitiontime
of0
or1
, then it works.My understanding is that setting
bri
andxy
is not possible within the same Zigbee message, so deCONZ must be sending two when they're specified simultaneously. The fact that a transition of 0 works makes me speculate that the light has a firmware bug in which when it gets two messages in quick succession, the second overwrites the state of the first when the light is still transitioning from the first message. Setting a shorter transition than the light default (which seems to be a bit over 100ms) works because the light finishes changing state before the next message and the race condition is avoided.As with the other issue, I'm reporting this to check if it's possible to implement some sort of workaround in the deCONZ side to address this firmware bug (at least partially) and hopefully help getting one implemented.
Potentially related issues: #753, #445, #81
The text was updated successfully, but these errors were encountered: