During those 2 hours, if you restart Home Assistant, or reload automations, or reload scripts (that happens automatically whenever you create/modify an automation script via the UI) all running automations/scripts are canceled.
If you have not restarted/reloaded during the 2 hour transition period, I don’t know why your lights behave the way they do.
I haven’t even touched Home Assistant during the 2 hour period so that can’t be the problem.
I think I will just make a hard-coded transition with delays, maybe that works.
Hello, I have been attempting to write this script myself but stumbled across yours, and figured why reinvent the wheel? Thanks for all the contributors of this thread! I am using @123 (Taras) iteration of the script YAML and have been trying to debug it for several hours now. I added a “logbook.log” service call to show all the variables that the “calculate” branch produced and narrowed it down to the fact that I am unable to get the “brightness” attribute from my light. If I test a template in the developer tools I can get the value from the entity:
{% set light = 'light.shelly_shdm_2_f4cxxxxxxx' %}
{{state_attr(light|string, 'brightness')}}
But within the script the state_attr for the light variable returns null (I even tried typing it to a string).
I am calling the service from the Developer Tools as shown in the scree capture but the service stops on the first iteration because it can not evaluate the current “brightness” level of the entity. I am using HA core-2021.12.1 and supervisor-2021.12.1
Any ideas how to retrieve the brightness attribute of the “light” variable that was passed in? TIA
Thanks for the heads up. I am using that one now and the brightness attribute is present but it still only goes through one iteration and then reports “turned off” by me. I will move my discussion to that thread. Thanks again for your help!
The script is designed to stop iterating if it detects the last brightness value it sent is not the light’s current brightness level. The implication is that the user manually changed the brightness level to something different and that serves as a signal for the script that the user wants to override (stop) the script’s fading operation.
In your case, it’s possible the first brightness level the script transmits fails to actually set the light’s brightness. Before sending the second brightness level, it first confirms that the light’s current brightness level matches what it had sent. It discovers it’s not the same so it assumes it was manually overridden and stops the fading process (i.e. stops after one iteration).
If that’s what’s happening then the question is why did the light fail to be correctly set to the first brightness level?
FWIW, I tested the script with a regular light bulb controlled by a UPB dimmer switch and it dimmed/brightened properly. Someone else tried it with Zigbee-based lighting and had mixed results (possibly because this script transmits a continuous stream of commands and it might cause a ‘Zigbee traffic jam’).
but a few lights don’t go below 10 % , can’t figure out why ?
the two lights at the bottom are light groups , and the tafel does turn off nicely first 2 don’t ?
what I’ve noticed thatthe first 2 have this:
I suggest you try the revised version of the Light Fader script.
If it doesn’t produce better results then the problem may be due to communication issues with the lights. The script produces a lot of commands/traffic for whatever lighting protocol used by your lights. A separate command is sent to each member of a Light Group (and, perhaps, some are discarded if there are simply more commands than the communication channel can handle).
For anyone who’s lights stop at a certain %. I solved the problem by adding a tolerance to the condition that kills the script if brightness doesn’t match. Instead of (b | round(0, default=0) == start_pct + ((repeat.index - 1) * sign)) }} you can do (b | round(0, default=0) - (start_pct + ((repeat.index - 1) * sign))) | abs <2 }}
Running latest HA 22.12.7 First time attempting any scripts here. Installed your iteration of the fader script. I tested it in Developer Tools and no changes occurred.
For entity_id “light.hallway_main_lights” I used this to test:
Several months after that script was first posted (November 2021) users reported it (silently) failed to work. Clearly something changed somewhere to cause its failure. However I didn’t investigate because I don’t actually have a need for the script and simple offered it as-is. My goal was to demonstrate efficient scripting techniques by simplifying mrsnyds original work; all of my lighting supports transition natively so I have no practical application for the script.
Someone discovered that if they modify the script to accept the transition time as an integer value (instead of HH:MM:SS format) they could get it to work. Why? I have no idea because I never examined their revised script.
You can follow the discussion in the other topic and it’s also where you’ll find several modified versions of the script.
FWIW, it’s now over a year since I posted the script. At the time, the repeat statement was a new addition to scripting and the fading application was a perfect candidate for showcasing repeat. Other scripting improvements have been introduced since November 2021 so it’s possible that the fading script can be refined even more.
Bro I was following this every so quietly to setup a store’s lighting. I just installed this tonight and have no idea how to do this. Got to you post and got instantly depressed that no one responded to you.
