Amazing news, thanks Ashley 
1 Like
Hey Ashley. I’ve got an existing basic script based on Jeffrey Stone’s (Slackerlabs) Lights With Level script that works pretty well, but I’ve added your script too and will put it through its paces later 
.
I’m also now stalk… I mean following you on X or Twitter or whatever it’s called these days
Thanks.
1 Like
I’m rooting for ya!
Appreciate the update!
Your script is such an effortless addition to my family’s daily use of HA 
I’m baffled that this feature isn’t baked into HA itself!
Stay fantastic!
2 Likes
This is fantastic! I’m wondering if it’s possible to allow an area to be input in lieu of entity id. I know you can use groups, and maybe that’s actually the way to go… What I’m hoping to do is use this script with the assist feature, and say “sunset {{ area name }}” to trigger a script called “sunset” (which then calls your script,) on lights in whatever area is mentioned.
I tried using
{{ expand(states.light)|selectattr('entity_id', 'in',
area_entities('Living Room'))|map(attribute='entity_id')| list}}"
but I get an error about dict not having “lower” probably because it’s expecting a string instead of a list of entity ids
1 Like
@ThreepE0 For better or for worse, that isn’t something that the script supports.
That’s in part because a given area might have various lights that could all be at different starting brightnesses—and so if the script were to try to natively support fades for multiple lights like that, this script would probably need to be multithreaded, which I don’t think is in the cards.
With that being said, as one alternative option, you could certainly use groups (as you had mentioned). Or—alternately—you could potentially create an automation that were to make use of the “Run in Parallel” action to call this script multiple times, once for each lamp in a given room. (And if any of that might not quite make sense right away, I’d be happy to elaborate on that.)
Hiya, friends!
By the way, I’ve just released version 2.0 of Ashley’s Light Fader, which includes a bunch of new features!
~~Some highlights ~~
- You can now fade between color Kelvin temperatures. (And shout-outs to @damru, @kvikindi, and @ThatBlockyPenguin for requesting this!)
- You can (optionally) have the script automatically cancel its fade if you turn off the lamp during the fade sequence.
- And by request for @ronnieSVK: If you set a lamp to fade down to 1%, and if that lamp uses a 0-to-255 brightness scale, the script will infer you’re looking to have the lamp fade down to its lowest level—so the script will automagically fade the light down to 1/255 brightness.
Anyway, the post at the top of this thread has all the deets!
4 Likes
You magical hooman bean!
It works amazingly now, thank you!
My next challenge is with my esphome/libretiny-hacked RGBWW lightbulb that won’t play game.
Because I’ve set color_interlock: false (as I do love having fine grain control over all the colours!), it doesn’t present as a basic colours and a warm/cold slider, but rather colours/warm light slider/cool light slider.
I’m not sure if my next avenue of exploration should be within your script (which, btw is miles beyond my current capabilities, but I can still appreciate its beauty!), or dive deeper into what I can do in esphome in order to instruct the bulb via Kelvin values…
I’ve completely lost the plot here for a moment, so I’ll just say THANKS again for a super useful script! 
1 Like
@kvikindi Thank you so, so much for your kind words! 
For whatever it’s worth, while I have no particular experience with ESPHome/LibreTiny, I have one idea that miiiight potentially offer some options depending on how things pan out—
If you go to your local Home Assistant installation → Developer Tools → States, and if you then type that RGBWW bulb’s entity name in the “Filter entries” box, what’s shown under that bulb’s attributes column?
(By way of example, here’s what’s shown under the attributes column for my patio lamp:)
min_color_temp_kelvin: 2000
max_color_temp_kelvin: 6535
min_mireds: 153
max_mireds: 500
effect_list: None, candle, fire, prism
supported_color_modes: color_temp, xy
color_mode: color_temp
brightness: 255
color_temp_kelvin: 2906
color_temp: 344
hs_color: 27.987, 59.51
rgb_color: 255, 174, 103
xy_color: 0.505, 0.385
effect: None
mode: normal
dynamics: none
friendly_name: Patio Lamp
supported_features: 44
Anyway, it’s mostly the supported_color_modes attribute that’s of interest in this context. And while I’m not making any promises, depending on what your bulb might show for that supported_color_modes attribute, there may be a chance that we miiiight be able to finagle something for this.
1 Like
Alas, it’s only RGBWW in there at the moment… but I’m sure that there is a way for me to wangle this somehow, probably with some lambda magic somewhere… Once I get proper time to look at it, I’m sure I’ll find it (a 1.5 year old is a time sink!).
For what it’s worth, here the state of the lamp from dev tools:
effect_list:
- None
- Custom RGBWW Effect
- DDP
supported_color_modes:
- rgbww
color_mode: rgbww
brightness: 143
hs_color:
- 28.383
- 65.49
rgb_color:
- 255
- 167
- 88
xy_color:
- 0.524
- 0.388
rgbww_color:
- 0
- 0
- 0
- 0
- 255
effect: None
icon: mdi:floor-lamp
friendly_name: Stand Lamp Light
supported_features: 44
1 Like
Hey Ashley,
Congrats and thank you for the script, it is the by-far best effect that I was able to see, especially for the lamps which doesn’t support transition attribute.
I have (may be a dumb) question / goal. I am trying to use your script to simulate the transition effect - as my lamp doesn’t accept transition key in the service calls. I am trying to adjust the brightness of the floor lamp with a philips hue tap dial switch…
Your script works great with buttons on the switch, like increasing the brightness from 10% to 70% in a second with a press on button 1, etc… very smooth transitions.
But I am also trying to make use of the dial to increase and decrease the light brightness with the turn of the dial. The dimmer switch supports, 3 actions for increase and decrease. Fast Turn Right, Slow Turn Right and Step Turn Right and similar 3 actions for left turns.
My goal was to use your script by creating a custom entity (sensor) which will have some more or less some value to the current brightness of the lamp, and I will be able to use that entity for the endBrightnessEntity .
For example, if the current brightness of the lamp is 40 (0-255 range), I will have 3 custom sensors that I can use with your script - for the endBrightnessEntity value… (to keep 0-255 range)
sensor_increase_fast: current brightness of the light + 50 (so 40 + 50 => 90)
sensor_increase_slow: current brightness of the light + 25 (so 40 + 25 => 65)
sensor_increase_step: current brightness of the light + 10 (so 40 + 10 => 50)
Using your script in 3 different automations for increase, and another 3 automations for the decrease actions…
something like: (only the last line changes for the 6 increase / decrease automations)
service: script.ashley
data:
lampBrightnessScale: zeroToTwoFiftyFive
easingTypeInput: easeOutSine
endBrightnessEntityScale: zeroToTwoFiftyFive
autoCancelThreshold: 10
shouldStopIfTheLampIsTurnedOffDuringTheFade: true
shouldResetTheStopEntityToOffAtStart: false
shouldInvertTheValueOfTheStopEntity: false
minimumStepDelayInMilliseconds: 100
shouldTryToUseNativeLampTransitionsToo: false
isDebugMode: false
light: light.floor_lamp
transitionTime:
hours: 0
minutes: 0
seconds: 1
endBrightnessEntity: sensor.sensor_increase_fast ## or sensor_increase_slow or sensor_increase_step in each automation
This works ok but not with smooth transtion.
I guess when I turn the dial, the script is called multiple times and that’s why the transtion is not smooth anymore due to parallel executions. It still works but it looks very like linear increase then the smooth increase / decrease that I can get with the buttons.
Can you think of any solution for this kind of a use-case ?
2- I wish we could have used milliseconds in transitionTime 
3- I wish the increase calls were able to get cancelled if there is a decrease (and vice-versa)
Thanks very much.
Marco
1 Like
Hey Ashley,
your script is almost perfect.
I am currently using your super script like below:
- if there is no presence then start dimming, if there is presence then stop dimming.
Is it possible to restore the brightness level (when I trigger entity from “stopEntity:” ) of the light before the script started dimming it?
I would like to get the effect like below:
- if there is no presence then start dimming, if there is presence then stop dimming and set light britghness to level before dimming.
alias: Sypialnia - wygaś światło jeśli brak ruchu
description: ""
trigger:
- platform: state
entity_id:
- binary_sensor.sypialnia_ruch_presence
from: "on"
to: "off"
for:
hours: 0
minutes: 0
seconds: 10
condition: []
action:
- service: script.1699737075083
data:
lampBrightnessScale: zeroToTwoFiftyFive
easingTypeInput: auto
endBrightnessPercent: 0
autoCancelThreshold: 10
endBrightnessEntityScale: zeroToOneHundred
shouldResetTheStopEntityToOffAtStart: false
minimumStepDelayInMilliseconds: 100
isDebugMode: false
light: light.sypialnia_swiatlo
transitionTime:
hours: 0
minutes: 1
seconds: 0
stopEntity: binary_sensor.sypialnia_ruch_presence
mode: single
Hey @PanMarekPL - I’m not entirely sure how to go about this, but my gut instinct tells me to look towards templating somehow, be it through a text/number helper and templating there within?
The way I have got some of my automations set up to go back to a previous state is by setting an action for service->scene create->scene “before”, and then whatever action thereafter (scene change etc.). That way when I want to “recall” the previous state of devices, in the “restore” automation I simply load the scene “before”.
But hopefully you can find something through the text/number helper templating.
I’d probably set it somehow like:
no presence detected → create scene (or write state of x light into a helper/template) → start dimming lights.
And then if there’s suddenly presence detected, then you could run Ashley’s script, using the helper as a value, as per the “Use an entity instead for the end-brightness value”.
Hope this points you towards where you wanna be
thank you for the suggestion. I created a helper and there I store the value before dimming, and later after detecting motion I restore it.
2 Likes
Hello!
Thank you so much for all your work on this, it looks awesome.
I am trying to implement some long fade in/outs.
Generally it fails if my transition time is more than a few minutes
I have kind of wonky connectivity, I think, so maybe my bulbs are briefly disconnecting?
I see this kind of thing in my automation traces:
"
Ashley’s Light Fader (script.1702486433421) started
(script.1702486433421) turned on
2 minutes later
(light.scarf_light) turned on
Stopped because an error was encountered at December 15, 2023 at 9:24:53 AM (runtime: 1492.89 seconds)
src/app/CommandSender.cpp:271: CHIP Error 0x00000032: Timeout
"
Again, my connections are floaty - but is there a way I can have a graceful recovery from intermittent connection failures?
These errors stop my automation, so no ensuing calls happen.
I have worked around it by just making the Ashley fade the last thing any automation does - but it is inelegant.
Any ideas?
1 Like
@macrosa Marco have you done this rotary encoder thing without the script, using some more direct code…and found it joy or wanting, smoothness-wise?
I only ask because I just coded a rotary controller to control my stereo volume, and I am sure a similar code-strategy would work. Should I dig it out?
My case is specific for the lights which lack the support of transition (fade) attirbute in the service call - if that sounds similar with the volume, sure, would appreciate it…
Hi @the.nw.enterprise! I wish that I could help more, but as far as I’m aware, I don’t thiiink there’re any Jinja mechanisms that I could hypothetically use to try to work around the timeouts that you’re coming across.
For whatever it’s worth, if your lamps might be connected through ZigBee, I can vouch from this video from @makeitworktech that goes over some approaches for improving the strength of one’s ZigBee network. As well, this video from Home Automation Guy covers some handy ZigBee tips too.
For better or for worse, I think that this issue might mostly be in your hands.
2 Likes
Hi @macrosa!
I can’t say for certain whether the smoothness might be affected by the parallel executions, but I miiight be able to help with a few aspects here:
I can understand the temptation for this, but at the same time, I don’t think that millisecond-based transitions would be all that practical in real-world use. And that’s mostly just since light.turn_on service calls from Home Assistant to an average lamp tend to take around 150+ ms apiece.
And so even if the script were to hypothetically support millisecond-based transitions, and even if you were to specify a transition time of, say, 800 ms, that would only allow for 4 to 5 light.turn_on service calls—which doesn’t allow for all that many interim steps in pursuit of a smooth transition.
I believe that there’s a way that you may be able to do that by making some adjustments in your automation that calls Ashley’s Light Fader:
-
First, you would need to combine your 3 different automations for increase and 3 automations for the decrease actions into a single automation by making use of trigger IDs. I won’t go into too much detail on the process for that here, but this video from @smarthomejunkie offers a fantastic primer on how you can use trigger IDs.
-
Then once that’s in place, open that new single automation in Home Assistant, go to the “…” menu (in the top right), and then choose “Change Mode”:
- And then within the dialog that pops up, set the automation’s mode to “Restart”:
- From there, close that dialog, and then click Save to save that change to the script.
When an automation is set to “Restart”, if the automation is triggered while a previous instance is still running, the automation will automatically cancel the previous instance, and it’ll start from scratch again.
PS Just as a quick tip (and perhaps this may be something that you’ve already taken care of?): Within each of these sensors, be sure to check that their resulting values don’t exceed 255.
For instance, just as pseudo code, you might go with an approach along these lines:
sensor_increase_fast:
{% set newBrightnessValue = currentBrightnessValue + 50 %}
{% if (newBrightnessValue > 255) %}
{% set newBrightnessValue = 255 %}
{% endif %}
{{ newBrightnessValue }}
1 Like
Hi and thank you for this script! I’m trying to use it to set up a wakeup light and I’d like to start with a warm 2000K temperature at low brightness transitioning to a colder 4500K at max brightness. I see you have implemented the end temperature feature in v2, but how can I set the initial one?
Nevermind, dumb question. Since it transitions from the current state, before running the script I just have to invoke the Light ON action with an initial brightness of 1% and 2000K initial color temperature. The script takes care of everything else.
Thanks this is awesome!
2 Likes