-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Immediately perform colour transitions for ColorControl commands where TransitionTime is zero #26987
Conversation
Commands to the colour control server that had a transition time of zero were being deferred for 100 ms. Instead they should be handled immediately.
When the transition time is 0, the remaining time should also be 0.
PR #26987: Size comparison from 77b1596 to 3db9546 Increases (29 builds for bl602, bl702, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, psoc6, qpg, telink)
Decreases (5 builds for psoc6, telink)
Full report (58 builds for bl602, bl702, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
I believe we can streamline those changes in a cleaner way. I am not convinced we need the new vars in each function I agreed with removing the But setHsvRemainingtime() and similar should remain the focal point where to update the RemainingTime attribute Lastly the only change left would be |
…the number of steps remaining. This ensures the calculation for time remaining is correct when both a hue and a saturation command are running simultaneously.
Calculate the amount of time to delay the first step where it's used instead of at the start of the functions.
Calculate the value where it's used instead.
I've added the time remaining in the transition states so it's distinct from the number of steps. This keeps SetHSVRemainingTime as the place where the RemainingTime attribute is set for hue and saturation commands. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, that makes a lot more sense now!
PR #26987: Size comparison from 9828293 to c34cf1f Increases (30 builds for bl602, bl702, cc32xx, cyw30739, efr32, esp32, k32w, linux, nrfconnect, psoc6, qpg, telink)
Decreases (10 builds for bl702, k32w, psoc6, qpg, telink)
Full report (58 builds for bl602, bl702, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
General Q: Level control and on/off have a similar mechanism - do they also suffer from this problem? |
Level control's implementation will correctly schedule the work to occur immediately when the transition time is zero. I'm not familiar with the on/off cluster, but I think the OnWithTimedOff command might have a similar issue? In some cases it schedules a timer for 100 ms after the command is received, and I believe it's possible it could do so while OnTime is set to zero. |
PR #26987: Size comparison from a73c8e9 to f1a3ed7 Increases (30 builds for bl602, bl702, cyw30739, efr32, esp32, linux, nrfconnect, psoc6, qpg, telink)
Decreases (10 builds for bl702, cc32xx, psoc6, qpg, telink)
Full report (57 builds for bl602, bl702, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
Fixes #26929
Problem
When TransitionTime is zero, the ColorControl cluster treats it as one instead so commands that should apply instantly instead take 100 ms.
When followed by another command (e.g. MoveToColorTemperature followed by On), the introduced delay would cause the later command to be applied before the colour-changing command.
Change overview