@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.
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”:
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 }}
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!
maybe I don’t understand something, but there are so many functions in this script that I don’t know or don’t understand how and where to set the starting percentage from which I want to start increasing the brightness?! (the fact is that my dimmer does not turn on from 0 percent, but from 11, so this is important for me)
Hi! Thank you so much for this script, Ashley and everyone who contributed. It’s really good! 
I just wanted to point out that the direct link to the raw code of the gist does not seem to point to the most recent version of the gist. I used the raw link and now realise I’m missing the end colour variable.
If there might be certain functions of the script that you don’t understand, feel free to ask about those, and I’ll be happy to elaborate!
As for setting the starting point, you can do that by including an action just before you call the script in which you set the light’s brightness value manually to whichever starting value you might like.
Wow …just wow! This is awesome. I have a few automations that I hard-coded some similar linear effects for my bulbs - but this is just so much better! Thank you for sharing - I’m looking forward to replacing my garbage with your fader - great work!!
Dear Ashley !
We are absolutely addicted to your script and cant be thankful enough for your time and effort ! You are the queen of light ! 
I would like to kindly ask you about two new features included in this fantastic script !
The “End color temperature (in Kelvin)” works absolutely great, if i turn on the bulb and start fading with your script in a range of “WHITE LIGHT”. I understand, that COLOR TEMPERATURE is correspoding exactly to this value, the value of white color in Kelvin, as the script describes. Is it somehow possible to achieve the fading TO WHITE LIGHT (with specified Kelvin) from RGB color ? Use case : The bulb turns on with the lowest possible brightness value in the morning with green colour and fades for 30minutes to maximal brightness level in 2700k white color ? The reason im asking and using the lights like this is, that even the smallest white value is “too much” in the morning. I covered this with more automations, fadeing the green, then switching to white and fading it again. Just asking 
Im waiting finally for my new light bulbs, so i will try this functionality on them also.
The next function is the “(experimental) If available, use the lamp’s native transitions too” option. As i mentioned, im switching my bulbs and LED strip controllers continously to new devices and ESP32s, where native fading is available. However the native fading is the smoothest one, we know that is limited in HA to 300seconds. How handles this limitations the script please ? Is it also limited to 300seconds, or is the script able somehow to prolong this functionality to desired time and keep the smoothest “native” fading effect ? Is in this case the “Minimum delay per step” ignored ?
Is it please possible to use the two upper mentioned new functionalities together ?
Thank you very much once again Ashley !
Greetings
Ronnie
I wanted to say a quick thanks for this script. I used it as part of a system to make a sunrise alarm clock and it’s working great.
I also really appreciate the thoughtful discussion around fading across colors. I was considering picking up an RGB bulb to to try and have a more red-to-daylight sunrise simulation, but I now understand why that’ll be a lot harder to make happen than I’d originally thought. I’ll just stick with fading between °K because that looks really good as it is.
If any of you are interested here’s how I used @handcoding’s script. I’m really happy with this setup: Sunrise-like Alarm Clock via Home Assistant + Android – nuxx.net
amazing script @handcoding! Thank you very much for your hard work on the topic, the explanation and support. I’m not quite there for a use case (except for a wake-up light) but really like the approach!
Thanks for the awesome script!
I have an issue when trying to use the “(optional) End color temperature (in Kelvin)” function.
If I activate it, the script will just stop immediately after starting, leaving my Ormanäs LED light strip from IKEA (connected via zigbee2mqtt) on with 0% brightness and the lowest kelvin value.
I have experience coding, but no experience coding for HA; how could I go about debugging this?
Maybe for consideration: My Home Assistant instance is localized to german.
Thanks!
Hi @RaBoom!
I have two ideas that may be able to help with debugging this:
As a first step, you might try enabling the script’s debugging option; then try taking a look at your Home Assistant logs while you manually run the script. (To view your logs, you might already have a “Log Viewer” item in your sidebar, which works fine. Or you can also view your log through Settings → System → Logs.)
Then, as a second idea, you might try looking up your lamp under the Developer Tools. That is, if you go to your local Home Assistant installation → Developer Tools → States, and if you then type that lamp’s entity name in the “Filter entries” box, what’s shown under that lamp’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—and depending on what might show up in the logs—there may be some further steps that we can take.
Many, many thanks for your kind words, @ronnieSVK—that really means so much!
I can understand where you’re coming from, but I think that the tricky part in this sequence is that I’m not aware of any algorithms for smoothly transitioning between an RGB-based color and a Kelvin-based color.
If you enable the “(experimental) If available, use the lamp’s native transitions too” option, the native lamp-based transition that’s applied will max out at 10 seconds per step.
So for example, if you were to fade a lamp from 1% brightness to 3% brightness over a span of 30 seconds, the script might hypothetically send a sequence of commands to the lamp along these lines:
The “minimum delay per step” option works independently from the “use the lamp’s native transitions too” option:
Hi Ashley (@handcoding)! First off, Oh My God, thank you so so much for making this! This is what I’ve been trying to find for the past several months and finally, my dreams of doing really beautiful fade in and out of the lights in my house as though they’re in some kind of boujie hotel makes me super excited! And again, thank you @123 for directing me here!
I do seem to be running into a small bit of an issue. I’m testing this with one of my light switches before I switch everything over to the script, but for some reason, the light will not go brighter than something that looks like maybe 1 or 2% brightness. I do see it fade on over a few seconds but then it just stops at the above percentage of brightness. I’ve set the end brightness level to 100% so not sure why it’s not maxing out.
Also, as I’m writing this, I clicked on three dots on the action and selected run multiple times, and the light eventually got to 100% brightness. I think I hit run like 4 or 5 times to get to max brightness. I also noticed quite a bit of stepping as it got brighter.
Thank you in advance for any help
@aquariuz23 Big, big thanks for your kind words!
As a first step, you might try enabling the script’s debugging option; from there, try taking a look at your Home Assistant logs while you manually run the script. (To view your logs, you might already have a “Log Viewer” item in your sidebar, which works fine. Or you can also view your log through Settings → System → Logs.)
And depending on what might show up in the logs, we can potentially go from there.
