Light Hook: Made the transition period configurable.

[vandalon]

Added an option to make the transition period when dimming, configurable.

I encountered the issue that dimming for me was just not smooth, upping it with 10ms fixed this for me.
I can imagine this is also depended on the controller and debounce settings so I made it configurable :)

[EPMatt]

Hi @vandalon, thank you!
Another nice parameter to add to the Light Hook, for making it more customizable.
I'll review your changes in a few minutes. :)

[vandalon]

Are you sure you want to remove the float filter? the output has to always be float right?

[EPMatt]

Hi @vandalon,
I've updated docs with the change, as well as tweaked a few things on the blueprint.

Most importantly, I used the step_duration input also for the delay step in the *_repeat sequences, so that we should have the dimming experience even smoother and more configurable than before.
This will result in the *_repeat actions to act as follows:

Pseudocode for each step:

1. Execute the light change with transition: step_duration
2. Wait: delay: step_duration

[vandalon]

I'm afraid that won't work, the delay should be static. Because of debouncing the difference between transition time and the actually delay is causing it to be less smooth. So if you now sync those two again it will cause the issue I tried to fix :)

[EPMatt]

Are you sure you want to remove the float filter? the output has to always be float right?

Not required as stated in the Jinja2 documentation.

https://jinja.palletsprojects.com/en/2.11.x/templates/#math

/
Divide two numbers. The return value will be a floating point number. {{ 1 / 2 }} is {{ 0.5 }}.

Also I did check this on my instance before committing. :)

[EPMatt]

I'm afraid that won't work, the delay should be static. Because of debouncing the difference between transition time and the actually delay is causing it to be less smooth. So if you now sync those two again it will cause the issue I tried to fix :)

Could you test this on your instance?

Moreover, we should be careful not to mess up with assumptions between different blueprints. For the Light Hook, debouncing on a Controller blueprint should not exist: the Hook already receives filtered events and should never be aware of any mechanism Controller blueprints implement to fire events.

Btw this should already be in place: in the code of Controller blueprints the event for a long action is sent only once, before looping the custom action. As a result, no duplicate events are sent for long actions, if controller events are correctly debounced.

I'm not excluding using a parametric delay might worsen the dimming experience, but at least we should try and see what we get. :)

Thank you for the quick feedback. :D

[vandalon]

I will test it :)

You are right in regards to the debouncing part, it should not interfere with the timings in the hook.

[EPMatt]

Hi @vandalon,

Today I performed a few tests with this configuration. On my instance everything works great (and increasing the step_duration to 500 really makes the dimming experience much smoother).

I've just pushed a fix for the delay steps in the *_repeat actions: we were using step_duration / 1000 as value for milliseconds. My fault due to my previous commit, but the issue is now solved. :D

Please let me know when you have time to complete your tests. After that if you are okey with it I think we can merge this PR and make the feature publicly available. :)

Thank you again for your help!

[vandalon]

Sorry, not had time for this one yet, hope to find some time in the weekend :)

[EPMatt]

Don't worry @vandalon, you are already doing a lot for this project. Really appreciate your effort :)