As already mentioned, here comes a big change for the ‘relative dimming’ part of the blueprint. My goal was to be able to stop dimming at any point when you release the dimm button. In the past dimming was always done stepwise without the possibility to stop in between.
I had to change a lot internally and hope that there are no bugs left. Please see the changes as a beta release which has to be tested (by you).
@kalhimeo : I post the code here in this thread. Feel free to upload it to github. I don’t think that I should create an own project for this.
Changes in detail:
In order to be able to stop dimming at any time, you need to use a ‘number helper’ instead of a ‘toggle helper’. Using a toggle helper is still possible (so the new blueprint won’t break your existing automations) but you will not benefit of the new function.
If you have lights that support transition and you use the ‘number helper’, the lights just get triggered once at the beginning and maybe once at the end of the dimming process. This might result in a jumping brightness at the end of the dimming if your lights don’t transition perfectly. E.g.: My lights take ~10% more time for transitioning as they should. So lets say I would like to go from 0% to 100% in 10 seconds. After 9.9 seconds the (internal) brightness of the light will be just at around 90%. When I stop dimming it will instantly be set to 99% and so the brightness jumps.
You can change this behaviour so that your light will also receive an update with every dimm step by activating the new switch ‘Enable HA bus updates with relative dimming and transition’. Either way the KNX bus will receive updates for each dimm step.
In order to keep everything mostly consistent (even without transition and/or a ‘number helper’) there is a change in behaviour when the light does not support transition: Before the change, the dimm process changed the brightness of the light at the beginning of each dimm step. After that there was a small delay and then it started again until the dimm process was stopped. Now the delay comes first and after that the brightness change. So if you have a just few dimm steps combined with a long dimm time (and a toggle helper and no transition), you will notice the delay before the first brightness change.
Minor improvements:
The calculation of the length of each dimm step should be a bit more accurate.
The last dimm step now takes less time if there is no full step left for dimming.
Bug fix:
It was possible to start multiple dimming sequences at once if you managed to stop and start dimming during one ‘dimm step’. This is fixed by replacing the fixed ‘delay’ with a ‘wait_template’.
Internal Aesthetics:
I changed the code to reflect the newest Home Assistant changes (e.g. ‘trigger’ instead of ‘platform’, ‘action’ instead of ‘service’).
Caveats:
I have just tested switching (on and off) and brigthness changes. I have not done any tests for RGB colors or color temperature. So be carefull if you use these features with your lights.
There are now quite a bit more checks and calculations which might result in a higher cpu load and/or longer time needed for the single automation steps. On my hardware (HP T630 Thin Client) I could see delays up to 150ms. This does not seem to be much but could add up when using a lot of dimm steps. On the other hand I never checked how it was before these changes.
(The code will be posted in the next 2 posts because it exceeds the character limit of one post).