I was trying to get various blueprints for the IKEA 5-button remote like this one to perform smooth dimming when the up/down buttons are pressed and held the way the standard IKEA gateway performs dimming. I realized that those who had a way to control the dimming step could not achieve that; dimming always seemed to be in discrete steps despite the author using transition argument in calling service light.turn_on.
After some testing with this service in Developer Tools/Services I realized that the service seems to ignore transitions less than 1, in fact it seems to truncate fractional parts, casting the passed value into an integer. The UI of the service draws a red underline when I enter a value with decimal part implying that it should be an integer but it still accepts it.
Is transition meant to be always an integer, i.e. increments of one second? Why? If this is so then it seems it is impossible to achieve smooth dimming on button hold as the automation needs to send small increments in brightness with a small transition time, i.e. 200ms (transition: 0.2) on every button hold loop or they flood the message loop. Perhaps some light vendors do not support fractional transition times? Tradfri lamps seem to support it though since the remote does smooth dimming when paired to a Tradfri Gateway and the default transition time when lights are turned on/off seems to be considerably less than a second (about 600-700ms).
It represents the time duration to transition from one brightness level to another. It only works with lighting integrations that can perform that operation natively. Normally you wouldn’t specify a sub-second duration for this purpose.
The scenario you described is typically performed without employing the transition option and simply sending a stream of discrete brightness values using a repeat with a delay (which supports a sub-second duration).
Yes, this is how some other blueprints implement it but it is still choppy. It seems that without a small transition effect it is impossible to make it smooth; at least I cannot imagine a way.
This is an occasion where a sub-second duration is needed. And if the lamp firmware can handle fractional transitions I see no reason to exclude it. I can only imagine a reason if this is implemented/simulated with a delay loop in internal HA code that counts in second increments. But I believe that if that was the case then all transitions would be always choppy no matter the duration which is not the case for Tradfri when an integer transition is passed, so I believe transitions can and are being passed to the lamp firmware to execute.
In any case allowing transitions with decimal parts without truncating them wouldn’t hurt existing installations that use only integer transitions. And in cases where decimal transitions have been used like the blueprint I linked to that uses a transition of 0.25 it would just “magically” start to produce smooth transitions.
Maybe this wasnt the case a year ago, but now i do believe that while it seems to suggest that a non-integer number is invalid, it not only accepts it but it is reflected in yaml, and the value seems to my eyes to be executed as input regardless
