I use a combination: My Shelly smart bulbs only support a native transition of a few seconds, but setting a default that roughly matches the external update frequency leads to a much smoother transition effect. Note that I only recently discovered this script, so I’m still using my own version, but the principle should be the same.
1 Like
@joepfeifer Although it’s possible that some documentation might theoretically exist for some brands, I’ve found that experimentation is the main way to figure out how many commands a device can receive per second.
For instance, Hue’s developer program mentions that Hue lights can receive “roughly around 10 commands per second”, which might at first sound pretty great—but the caveat with Hue is that that “10 per second” number is for the Hue system as a whole. So if by chance you were to be fading two Hue lights at the same time, it would seem that that number would drop to around 5 commands per second (since 10 ÷ 2 = 5).
And if it may be of interest, the google query that I happened to use to find that page from Hue’s developer documentation was “hue lights commands per second”—so it may be possible that if you were to swap out “hue” for other brand names, that might be able to bring up similar results for other brands.
And while this next part isn’t an exact science, you can sometimes get a general idea for how well a light might perform based partially on how that light’s integration is rated on Home Assistant’s integrations page.
-
For instance, Home Assistant’s Lutron Caseta integration is categorized as “Local Push”, and out of Home Assistant’s various cloud-vs-local subcategories, “Local Push” is the best out of that bunch. (In contrast, for instance, Google Cast is classified as “Local polling”, which isn’t as snappy.)
-
Sometimes—not always, but sometimes—Home Assistant integrations also have a rating on Home Assistant’s integration-quality score, which can also offer an indication of how quickly that integration can process commands. As that goes, Home Assistant’s Hue integration is rated as platinum, which is the highest score for that category.
-
With that being said, Home Assistant’s quality scale—while helpful—isn’t the be-all end-all either. For instance, Home Assistant’s Lutron integration doesn’t happen to have a quality score, and yet I’ve found my Lutron Caseta lights to be absolutely flawless with Home Assistant. (So all that is to say: I wouldn’t necessarily dismiss a given brand if by chance it’s only would-be “fault” might be that its Home Assistant integration doesn’t yet have a quality score.)
Just to get it out of the way: If by chance you were to set up a light fade with the assumption that a light were to internally use a 0–255 scale (but if it were to actually use an internal 0–100 scale), or if you were to do the other way around: nothing bad will happen, and the fade will still work. In that scenario, there’s merely a chance that the light miiight not fade quite as smoothly as it would have otherwise.
That being said, here’s one way that you can check whether a light might internally use a 0–100 scale:
- First write a short test automation for the light that you want to test. And in that test automation, add an action where you set that light to a brightness of 34/255.
- Then manually run that test automation.
- Lastly, go to Home Assistant’s Developer Tools page, and manually look up the reported brightness level for that lamp.
- If that lamp uses an internal 0–255 scale, you should find that that lamp is currently set to a brightness of 34/255.
- On the other hand, if that lamp might use an internal 0–100 scale, it might have internally gone through this sequence when processing that set-brightness command:
- The lamp would first convert that “set brightness to 34/255” command into a percentage, which in this case is 13.333%.
- And then the lamp would set its brightness of 13/100 (since 13.333% × 100 = 13.333, which rounds down to 13).
- From there, once Home Assistant queries the lamp for its current brightness, Home Assistant would convert that 13/100 value back to an X/255 value to display that value on the Developer Tools page.
- And lastly, it so happens that when you convert 13/100 to an X/255 value, you get 33/255 (because 255 × 13% = 33.15, which rounds down to 33).
tl;dr: So all that is to say, after you run that test automation where you set a given lamp’s brightness to 34/255, if you check the lamp’s brightness value in the Developer Tools and if its reported value is 34/255, then the lamp probably uses an internal 0–255 scale; while if the lamp’s reported value is 33/255, then the lamp probably uses an internal 0–100 scale.
1 Like
Hi, Nice Project! I want to fade my light out, so its starts at 100% and goes sown to 0%, is there already a way to do this? Thanks!
Hi, @Maxibauser!
And, yes, you can do that with this script. To have a light start at 100% and fade to 0%, you would need to create an automation with two actions:
- First, manually set the light to 100% brightness.
- From there, you can then use Ashley’s Light Fader to fade the light’s brightness to 0%.
Hi, @handcoding : what a great work!
Sorry for the extremely noob question, but I can’t get the script working… It simply doesn’t apear in services.
I’v tried:
- Coping raw directly to scripts.yaml
- pasting the code in my scriptsmanual.yaml (which is working)
- making a new file called ashley.yaml with the code and including It in configuration.yaml
What am I doing wrong?
Thank you in advance.
Hi, @JohnnyBra—thanks so much for your kind words!
And as for getting the script to work, have you had any luck with the steps from the top-level post?
Or for convenience, I’ve also pasted those below:
- Open the gist for this fader , open the gist in raw mode , and then copy that code to your clipboard.
- Then within Home Assistant, go to Settings → Automations & Scenes.
- Select Scripts from the tabs across the top.
- Click the Add Script button.
- Once the blank script loads, open the “…” menu and choose Edit in YAML.
- Select all the boilerplate text within the script, and delete that. Then paste in the code from your clipboard.
- Lastly, choose Save Script.
Ty for your answer.
If I try to do that, I receive this error:
I think i’ve found the error! When I copy the raw with a mobile device it seems that there IS a limitation with the numbers of characters that can copy. I’m goong to try with a Pc and i’ll update the post.
1 Like
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