Finally, this didn’t solve the problem. Script is not appearing in Scripts (UI), only in scripts.yaml file, and can’t call it as service…
@JohnnyBra I just want to confirm that you went through the steps of adding the script using the steps from the top-level post?
If by any chance you might’ve previously added the script to any of your .yaml files manually, that will very likely not work. If perhaps that might be the case, I’d recommend removing the script from your .yaml files, then restarting Home Assistant, and then going through the installation steps from the top-level post, if you could.
I got It!!!
It seems that something was wrong in configuration.yaml, so scripts.yaml was not working…
Now I can smoothly turn on my lights as Sun IS falling down…
Very thank you for your support and, of course, for your delicate work.
1 Like
I just wanted to say thank you for all your hard work on this.
Do you have any specific tips on getting smooth transitions, no matter how hard I try and how ever many settings I change / experiment with I just can’t seem to get any of my tuya lights to fade smoothly over the course of say 3-4 seconds.
1 Like
@GTunney I have a potential idea here—and the gist of it is that nonsmooth fades are generally caused by the fader script having to take too large of a jump between its brightness, levels. For instance, if the fader were to have to apply brightness levels of 1%, 20%, 40%, 80%, and then 100%, that would almost definitely not be terribly smooth.
I’ll get to the specifics of the idea in just a moment, but before I do, I’ll briefly go over the two main things that can cause fades to have large brightness jumps in their sequence:
-
Any given light takes a certain amount of time to process each set-brightness command. For instance, if a given light were to hypothetically take 500 ms to process a given light command, and if the fade were to be requested for 5 seconds, then that would only allow for about 10 set-brightness commands between the start of the fade (0 seconds) and the finish (5 seconds).
- So if it might turn out that your light isn’t be able to process set-brightness commands very quickly, then that may be one factor.
-
A related factor is that even if a given light might be able to process set-brightness commands rather quickly, you still can’t exceed what the math might allow.
- So for example, let’s suppose that a given lamp might be able to process set-brightness commands super quickly—perhaps it might be able to process 10 per second (which would work out to 100 ms per set-brightness command). In that scenario, if supposing that you were to try to fade that light from 0% to 100% over a span of 1 second, that probably wouldn’t work go very smoothly since you could only fit in about 10 set-brightness commands within that 1 second.
Of those two factors, the first one—the inherent delay within the lamp—is outside of your control. While the second one—the fade’s duration or the fade’s brightness span—is something that you might have some control over.
Anyhow, so there are two ways that you can potentially lessen the second factor, depending on how exacting you might want to be:
The quicker version:
Since large brightness jumps within a fade are typically caused by large brightness jumps over short periods of time, you can oftentimes make a fade feel smoother by either reducing the fade’s overall brightness span or by increasing the fade’s overall duration. And as that goes, you had mentioned that you’re having some trouble getting the fade to look smooth over 3 to 4 seconds.
-
First—as a baseline—you might see whether you can get that same fade to look smooth if you were to set its duration to, say, 25 seconds.
-
Then from there, you might try checking whether that same fade looks smooth over, say, 20 seconds. And if it does, you might try 15 seconds, and then try 10 seconds, and so on.
-
And eventually you’ll get to a point where the fade no longer looks smooth. And then if you go back to the previous fade duration in your testing sequence, that’ll represent approximately the minimum duration that that particular lamp can fade over that brightness span while still fading smoothly.
The more exacting version:
This approach follows the same idea as the previous one, but it may offer more precision:
-
First, if you haven’t yet installed the Home Assistant Log Viewer add-on, install that. (This should add a “Log Viewer” item to your sidebar within Home Assistant.)
-
Then open the Log Viewer in one of your browser tabs. And then in a second browser tab, open the automation where you have that 4-to-5-second fade.
-
Then within the automation with the 4-to-5-second fade, enable Debug Mode within the options for Ashley’s Light Fader.
-
From there, run that 4-to-5-second fade as is—without any modifications yet—and while the fade is running, switch over to the browser tab where you’ve got the Log Viewer open.
-
You should see some debugger output within the Log Viewer that looks something like this:
(I’ve sliiightly reformatted the below log bits just for clarity.)
2024-04-30 15:02:25.660 WARNING (MainThread) [homeassistant.components.system_log.external]
easeInOutSine easing type with 686 ms delay. remainingTimeInMilliseconds = 44923, and absoluteBrightnessSpan = 50
2024-04-30 15:02:25.661 WARNING (MainThread) [homeassistant.components.system_log.external]
startBrightness = 25, endBrightness = 75, and processingDelayInMilliseconds = 62
2024-04-30 15:02:28.548 WARNING (MainThread) [homeassistant.components.system_log.external]
Set Living Room Lamps to 26 brightness. (Linear brightness would have been 28.)
Delay is 686 ms. Elapsed time is 2.97 seconds. (endBrightness is 75.)
2024-04-30 15:02:30.750 WARNING (MainThread) [homeassistant.components.system_log.external]
Set Living Room Lamps to 27 brightness. (Linear brightness would have been 31.)
Delay is 686 ms. Elapsed time is 5.17 seconds. (endBrightness is 75.)
2024-04-30 15:02:32.237 WARNING (MainThread) [homeassistant.components.system_log.external]
Set Living Room Lamps to 28 brightness. (Linear brightness would have been 32.)
Delay is 686 ms. Elapsed time is 6.66 seconds. (endBrightness is 75.)
- At this point, you’ll probably notice within your logs that there are some pretty big jumps in the brightness level between each step.
-
In an ideal world, you might want there to be only a brightness jump of 1 between each step.
-
Buuuut the good news is that the human eye usually isn’t that precise so as to require a brightness jump of only 1 between each step. So if you can get that brightness jump down to maybe 2 or 3 per step—or maybe even as much as 5 per step—that may be enough to get the fade to look smooth to the human eye.
-
So from here—as a baseline—you might see whether you can get that same fade to look smooth if you were to set its duration to, say, 25 seconds.
-
If the fade does look smooth at 25 seconds, then try a lower number. And if that next run looks smooth, then try an even lower number. And so on. (And since you’re able to look at the logs during each test run, that may also offer some insight as to how much of a duration reduction you might be able to spare from one test run to the next.)
-
Eventually you’ll get to a point where the fade no longer looks smooth. And then if you go back to the duration from your previous test run, that’ll represent approximately the minimum duration that that particular lamp can fade over that brightness span while still fading smoothly.
A few closing tidbits:
-
I know that all of this is probably a lot to take in, so if you might get stuck anywhere along the way, feel free to reply here, and I’ll be happy to chime in.
-
If you might be unsure of how to interpret any of the debugging statements that you come across in your log, feel free to share them here, and I’ll do my best to help you out.
2 Likes
Yes exactly, it always tries to get a higher number.
@julianrehm87 So just to pick an example, if a lamp were to have a starting point of perhaps 50% and if you were to fade it to—say—0%, does the script end up not fading all the way down to 0%?
Fantastic script. I’m using another simpler one, but I’m changing for this.
I’d like to make a sugestion:
as there’s the option to choose an alternative entity to Max Brightness, I have (using on the other script) an entity to the duration of the fader. I use it to make a slider on a configuration panel I have.
I’m using it on this script as well, using states, but this way I loose the graphic config editor.
Thanks !!!
1 Like
Hi, @alexantao—thanks so much for your kind words!
And I’m not opposed to your idea about adding an option so that users could optionally have the script use an entity to set its fade duration. I think that I might just put that at the #2 slot on my features-to-add list.
As that goes, can I ask how you have your slider set up on your configuration panel? For instance, is the slider setting an number that represents a duration in minutes? Or is it perhaps setting a duration in seconds? (Or maybe something else?)
Hi @handcoding . I just created an account and logged in to say thanks. This is perfect for gradually fading out the lights in my snake tank instead of turning them off suddenly. It works perfectly. Kudos!
1 Like
Thank you @handcoding ! Your fader script worked a treat.
One question, though: am I the only one who would like to do the opposite (defade?) for lights in the morning. Start from the low brightness and warm temp the lights were faded to in the evening and work up to the normal day lights. I tried but the script didn’t work for that purpose.
1 Like
I made some test, your work seems awesome @handcoding … Unfortunatly, i encounter some problems.
1 - If the light is off (for a 0% → 100% brightness fading), using the script will lead to the following situation : The light switch on at the minimal brightness (or even not switch on) and the script instantanly stop.
→ a little turnaround is easy : setup the light at minimal brightness (1%) before using the script
→ Hint for solution : Looking my logs, I think that the default value of ‘Turn of the fade if the light is switch off’ was creating a problem. I hadf an error with that, but the light wan’t turned off, it was the initial state. Turning on and off this option resolve the problem.
2 - If i try to change, brightness and color… Only Color Temperature changes and the brightness stay at minimal value
Thanks a lot for your work and your help 
@carnosine Could you perhaps elaborate on the troubles that you had encountered with this scenario?
If you might like, feel free to enable the script’s logging for more info. (If you haven’t yet installed the Home Assistant Log Viewer add-on , I’d recommend installing that. That should add a “Log Viewer” item to your sidebar within Home Assistant.)
@Sim209 Could you perhaps share an excerpt from your logs from when you had tried this? (The script should automatically compensate if you enable "Turn off the fade if the light is switched off.”)
If you might be up for sharing your logs for this scenario, I’d be interested in taking a look at those too. The script should be able to fade both color temperature and brightness (and in my testing on my home system, it’s been able to do that).
(If you haven’t yet installed the Home Assistant Log Viewer add-on , I’d recommend installing that. That should add a “Log Viewer” item to your sidebar within Home Assistant.)
The lamp’s brightness or color temp just wasn’t changing at all when trying to go brighter/cooler with the script. I thought that the script was never meant to be used that way and that’s why. Sure I’ll try to see why that is if the script indeed should and does work in that direction, too.
I don’t think I can install add-ons because I’m on a docker core installation. But I’ll try and dig up some logs if the script indeed is supposed to work in both directions.
The logs say this:
—clip—
2024-07-24 16:58:57.340 WARNING (MainThread) [homeassistant.components.system_log.external] Stopped Ashley’s Light Fader because a color fade was requested for Cabinet, but its current color temperature doesn’t seem to be defined using Kelvin units. (You can look into this by going into Developer Tools and checking that Cabinet has a defined “color_temp_kelvin” attribute.)
—clip—
This is true. The lamp is an Ikea lamp and it has an internal temp scale that is not in Kelvin. However I have set it up identically for fade and defade where a number helper provides the target temp in the internal scale. And it works on fade but croaks on defade.
@carnosine For whatever it’s worth, I personally think of “fading” as “transitioning between two levels”—though I get the impression that you might not think of “fading” in that way?
So I just wanted to check, when you when you refer to “fading” and “defading,” does “fading” for you mean “going from brighter to dimmer”? And does “defading” mean “going from dimmer to brighter”? (Or is it the other way around?)
And along those lines—when you say, “I have set it up identically for fade […] and it works on fade,” is that to say that you were able to use the script to have the light simultaneously go from brighter to dimmer and from a higher color temperature to a lower color temperature? And that that worked fine? (Or it is the reverse?)
(This script can only fade color temperatures in Kelvin, so if you might be saying that the script is able to fade from a higher non-Kelvin color temperature to a lower non-Kelvin color temperature, I’m not sure how that might be possible?)
I meant fading = going from cooler to warmer and from brighter to dimmer. Defading is the reverse. Defading: dat’s only da mounin.
Both my Ikea and Philips Hue bulbs takes color_temps in mired which is a Kelvin scale but not the regular one. Values are between say 100-500. As strange as it may seem your script does work to fade those lights.
There is some interpretation going on somewhere as the HA gui does show those bulbs color temp in regular Kelvin though the z2m integration uses the mired scale.