Nice!
Your script helped me to wrap my head around templates!
I still prefer an implementation by a few scripts, an outer script is a declaration and nested scripts hide the implementation. Then an implementation might be changed while the earlier usages of the script are not affected. I have some buggy lights, this way I could implement for them a bit different behavior.
Also, it allows using mode according to the nature of a script.
Hi,
When I use brightness % 0 with a list of entities I get the error:
Failed to call service script/light_fader. Error rendering data template: ZeroDivisionError: division by zero
however, if I just specify one entity it works fine.
Here is my service call:
light: ‘light.gold_lamp_2, light.hallway_ufo’
end_level_pct: 0
transition: ‘00:00:30’
Hi. I am currently using the version Taras posted in August, 2020, and while I do see the description indicates the ability to pass a list, I am guessing that this was an interesting idea that did not get implemented, or at least not yet. The portion of the script where the YAML templating calculates the interval of the delay between individual transition steps (delay_milli_sec: template) is only set up to calculate that value for one light entity at a time.
So if you are using that version as is, you would have to make one service call for each light, which is what I do currently.
I do have an idea about how to modify the script to do what is advertised in the YAML description, but that would take a bit of time and effort. Basically would need to parse the input for the light variable, and create a new branch that is executed when the light value is a list. That new branch would break the “request” into however many lights are assigned to the light variable, and run each one through the existing script by doing what I currently do manually (i.e. call the script again, but with just one light entity at a time).
Hi there,
I am having the same problem for me, the lights do not go over 45% and don’t go below 90%. I found that if l continually hit the Call Services button a number so times it would eventually reach its destination.
Amazing work here. Just one problem I have. When the lights are off for some time and I run the script it starts goes to ~20% and stops, goes to 50% and back to 20%. Looks like it’s some kind of sleep problem in dimmer?
I am having some problems with these automations:
- id: '1635967913203'
alias: Tijdsgebonden blauwe strip inschakelen
trigger:
- platform: time
at: '11:00'
condition: []
action:
- service: script.light_fader
data:
light: light.aquariumleds_blauw
end_level_pct: 100
transition: 02:00:00
mode: parallel
max: 10
- id: '4c075626967740e187de503ebc8eec52'
alias: Tijdsgebonden blauwe strip uitschakelen
trigger:
- at: '20:00'
platform: time
action:
- service: script.light_fader
data:
light: light.aquariumleds_blauw
end_level_pct: 0
transition: 02:00:00
mode: parallel
max: 10
Both of them do start, but the first one stops at 55% brightness and the second one stops immediately after it has started.
Am I doing something wrong, or is this a bug?
I am using @123 's script
Your scripts use a transition time of 2 hours.
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
I suggest you try the revised version of the Light Fader script I posted here:
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’).
love the script, I’m using it to fade-out my lights
action:
- event: light_fader_parameters
event_data:
branch: calculate
entity_id: light.kamer_lamp
end_level_pct: 0
transition: '00:05:00'
- event: light_fader_parameters
event_data:
branch: calculate
entity_id: light.vensterbanken
end_level_pct: 0
transition: '00:05:00'
- event: light_fader_parameters
event_data:
branch: calculate
entity_id: light.tafellamp
end_level_pct: 0
transition: '00:05:00'
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:
supported_color_modes:
- color_temp
- hs
the bottom light does not have hs supported …
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 }}
Excuse my ignorance, but could you provide a step-by-step guide on how to add this script to HA?
I guess I need to add it to the scripts section and then call it in the automations by just giving the variables - but how do I do that?
Thank you!
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:
light: light.hallway_main_lights
end_level_pct: 100
transition: 00:02:00
For entity_id “light.front_foyer_chandelier” I used this:
light: light.front_foyer_chandelier
end_level_pct: 0
transition: 00:04:00
Screenshot example:
Logs have no errors.
Script traces, etc., are blank pages:
The logbook has this:
Where did I go off the rocker here?
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.
Thanks! Seems your code worked. I just borked the entry. I may play with the other person’s v2.
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.
