Ashley’s Light Fader 2.01✨: fade lights and/or color temperature with your choice of easing (curves), including ease-in, ease-out, and ease-in-out

Share your Projects! Scripts
,
290

I completely understand your concerns, and honestly, the comments in Kenny’s script didn’t sit well with me because they don’t feel complete.

Maybe it’s early and I haven’t had enough coffee so I’m missing this, but do you think your version from a few days ago solves the problem I had above where an error sending to a device would cause the script to fail?

If so, I’ll happily give yours a test and let you know.

I really, really like waking up to the lights coming up and don’t really want to go back if it’s not expected to fix things, but if it is, I’ll absolutely test.

(I did actually put yours in place just now and I’ll see how it goes over the next couple days, but I’d love some affirmation of fix presence if available.)

291

@c0nsumer Just to check, when you say “affirmation of fix presence,” are you referring to the upcoming data_template → data adjustment? Or are you referring to something else?

(I haven’t put that into place just yet—and I still will be—but as someone who runs the script herself, I can say that the script appears to be working fine for me nonetheless.)

292

Sorry for not being clear…

I was curious if your latest version will handle dropouts of Zigbee. Like, does it handle when messages to the bulbs don’t make it there and the script was erroring on that “Failed to send request: device did not respond” error in the log.

Also, I feel a little weird saying this, but I’ve also fed your script + Kenny’s changes into Claude to make a substantially new thing for me to play with, but I’ve no plans to distribute that. I’d rather use your latest version instead. I’m experimenting with rearchitecting my HA config, teasing out some really esoteric edge cases that cropped up over ~2 years of playing with some automations, etc. If you’d like a copy, I’m happy to share it privately; reach out to [email protected].

(I’m trying to figure out why those bulbs are occasionally having problems. I’m also suddenly having issues with a Bluetooth speaker located about 30’ from there. Makes me wonder if the RF landscape in our semi-dense suburban area has changed… Maybe a neighbor is doing something weird.)

293

@c0nsumer The current version of the script intentionally doesn’t try to continue if it encounters ZigBee dropouts.

I coded the script that way because I personally feel that ignoring ZigBee dropouts would like if your car were to not show a dashboard warning light if one of your turn-signal lights were to fail. That is, if your car were to not show a dashboard warning light when one of your turn-signal lights were out, then that could make it much harder to realize that your turn-signal lights weren’t working as they should be.

As well, the script relies on the target lights being able to accept each of the set-brightness-level commands to make sure that the resulting fade is smooth.

For whatever it’s worth, and if it might help at all, I have a couple of ideas that you could try for potentially debugging those ZigBee dropouts?

  • The first thing that I’d try would to make sure that your ZigBee coordinator is running the latest version of its firmware. For whatever reason, I’ve noticed that the manufacturers of many ZigBee coordinators have sort of a “we’ll fix it in post!” attitude when it comes to code quality, and so the out-of-the-box firmware for many ZigBee coordinators can sometimes be a bit marginal. I myself was having some ZigBee-reliability issues at one point, but once I updated the firmware on my ZigBee coordinator, I found that that made a night-and-day difference. (And as that goes, this video from BeardedTinker goes over how you can update the firmware for many ZigBee coordinators right from Home Assistant.)
  • The second thing that I’d try would be to look over a signal-strength map of your ZigBee network:
    • If you’re running ZHA, you can view your network map under Devices and Integrations → ZigBee Home Automation → [gear icon next to your ZigBee coordinator] → Show map.
    • If you’re running Zigbee2MQTT, you can view your network map by going to ZigBee2MQTT → Network. Then, check the box for “Enable routes,” and then under “Display type” select “Map”.
    • From there, once you have your signal-strength map open, look for any devices in that have a connection to another device with LQI of less than 100—those are the ones that are most likely to be causing problems.
    • And if you might have any devices with a lowish LQI, it may be worth picking up a couple of plug-in ZigBee repeaters, such as these Aeotec ZigBee range extenders. [no affiliation]
294

Would a possible solution be to continue on error, but state an error in the log?

For long fades (many steps) missing one isn’t critical, and would make the script work while trying to work out why some commands fail.

295

Thanks for all of that, and I really appreciate those suggestions. And I completely understand how ignoring errors isn’t great practice and fixing root cause is the best solution.

What’s maddening about troubleshooting this is it (the alarm clock triggered script) would only fail maybe once a week. And I use quite a few other Zigbee things a few times an hour when home and it all always just works. The network is solid, there’s a wide range of mains powered devices sprinkled around the house already, and I don’t notice any other dropouts when turning things on/off/etc.

It’s so infrequent that nailing down the cause would be a lot. It could even be something with the bulbs? And in this case, I’m just going to step around the error instead. Maybe I should add something to log the errors so I can see if they really are as infrequent as it seems…

EDIT: I should add that the LQI for the two bulbs, peered directly to the coordinator, are 252 (both, from the coordinator to the bulbs) and 128 and 179 respectively for the reverse path. So, pretty solid there. And they’ve never ever failed when I send the All Lights Off signal while laying in bed, or an at-sunset automatic on… So it almost makes me wonder if the bulbs get a bit overwhelmed with a series of successive changes? Wouldn’t be the first time I’ve found a bug in Zigbee implementation in bulbs…

296

@c0nsumer That could possibly be the case!

If you might like to see whether that’s indeed happening, you can do so by enabling debug mode in the script and then checking your logs at whichever point things end up going awry. (I described the step-by-step process for enabling debugging and such in an earlier comment.)

And for whatever it’s worth, if a particular instance of the script were to only fail occasionally, there’s little harm in just leaving debug mode enabled for a couple of days—and then from there, if things go weird at some point, you can always then check your logs for more details at that point.

(That said, I’d be hesitant to leave debug mode enabled for weeks on end just since that could really fill up your logs.)

297

I’d overlooked that toggle before, thanks. I’ll give that a go. Maybe I’ll see something useful. If I do, I’ll be sure to share here.

298

(Little note, but of course, overnight last night… no issues. I’ll keep monitoring. Thanks again for the help.)

299

@doffen I could theoretically do that, but I’m not particularly inclined to do so.

And that’s mostly because I’d venture that most folks who are using the script have a ZigBee network that runs without errors, and in turn, those folks would want to the script to stop if it were to unexpectedly encounter an error.

For whatever it’s worth, though, if you might have occasions where you’re trying to figure out why some commands are failing, the script does have a built-in debug mode that you can enable. And if you were to turn on debug mode and then refer to your logs, that might be able to shed some light on the specifics of why something isn’t working as you had expected?

300

Personally my network seems quite stable now, and if I have issues with this script its months apart.

Or, I kinda have one issue, but i doubt it’s related to the script. one of my led strips turns on with an effect, and every time it gets a new brightness it turns off and on again. I think I’ll let it dim up without an effect and then maybe turn on the effect afterwards.

Truth to be told I’m too sleepy when the lights dim up to really notice the flicer in the one strip :sweat_smile:

301

(The problems I’ve had with poor Zigbee implementations…)

I personally would advocate for a toggle, like debug, that allows resuming the fading on device transmit errors or so.

I 100% recognize that it’s a bandage around a problem, but to me, if it stops the script from breaking in an isolated number of cases, and is not defaulted to on, it’s a fair compromise when dealing with the reality of RF networks.

302

@c0nsumer You make a reasonable case for this. I’ll give that some thought!

303

Thanks @handcoding !

304

Sorry for a probably stupid question: When an update of the script is available I cannot reload it like a blueprint for an automation but I have to build my script from scratch, right?

305

I’m pretty sure that so long as the existing fields and the blueprint name/alias don’t change you should just be able to replace the blueprint and continue on like normal.

Using a script blueprint simply creates a script that references said blueprint passing the field variables back to it, the same goes for automation and template blueprints.

306

@muesli79 That’s not a stupid question at all!

And as that goes, when an update for the script is available, you can install the update with these steps (without having to rebuild any of your existing automations that might already be using the script):

  1. First, open the current version of the script in your browser, and copy its text to your clipboard.
  2. Then, go to Home Assistant → Automations & Scenes → Scripts, and then click on the script to open it.
  3. From here, go to the “…” menu and choose “Edit in YAML”.
  4. Next, select all of the existing text in the script and then paste in the text from your clipboard to overwrite it.
  5. Lastly, choose “Save”.
307

Thank you very much!

308

I use this script on a daily basis and it really improves my life in a small subtle way.

I do think I might hav found a bug though, or a limitation?

Using a light group created in home assistant (spanning lights in both a zha and z2m network) the script fails if I fade from off and use the option fade to colour temperature kelvin.

Ashley’s Light Fader: Error executing script. Error rendering template for variables at pos 6: ZeroDivisionError: division by zero

Checking the attributes for the light group (while off) in tools I find this:

min_color_temp_kelvin: 2000
max_color_temp_kelvin: 6535
effect_list: blink, breathe, candle, channel_change, colorloop, cosmos, enchant, finish_effect, fireplace, glisten, none, off, okay, opal, sparkle, stop_effect, stop_hue_effect, sunbeam, sunrise, sunset, underwater
supported_color_modes: color_temp, xy
effect: null
color_mode: null
brightness: null
color_temp_kelvin: null
hs_color: null
rgb_color: null
xy_color: null
entity_id: light.z_utelys_huset, light.garasjeport_lys_light
friendly_name: utelys_g
supported_features: 44

And the attributes while on:

min_color_temp_kelvin: 2000
max_color_temp_kelvin: 6535
effect_list: blink, breathe, candle, channel_change, colorloop, cosmos, enchant, finish_effect, fireplace, glisten, none, off, okay, opal, sparkle, stop_effect, stop_hue_effect, sunbeam, sunrise, sunset, underwater
supported_color_modes: color_temp, xy
effect: off
color_mode: color_temp
brightness: 166
color_temp_kelvin: 2352
hs_color: 29.294, 78.165
rgb_color: 255, 153, 56
xy_color: 0.562, 0.389
entity_id: light.z_utelys_huset, light.garasjeport_lys_light
friendly_name: utelys_g
supported_features: 44

After searching I guess what I’m experiencing is related to color_temp_kelvin: null?