I realize that it’s been a little ways since you had asked your question, and I’m sorry about the delay in my reply.
For whatever it’s worth, from looking over the log excerpt that you had provided, it looks like there’s around 200 ms between log entries, which suggests that the limiting factor might come down to how quickly your lights is able to process set-brightness commands from the script.
Just to share some back-of-the-envelope math—
I gather that you were trying to go from 0% brightness to 50% brightness in 2 seconds (or 2,000 ms).
From there, if it takes around 200 ms for your lights to process a change-brightness command, that would mean that your lights would be able to accept no no more than around 10 change-brightness commands within that span of 2 seconds.
In turn, if you’re trying to span a brightness range of 50%, then that would mean that the script would end up having to use an increment of around 5 percentage points each time that it sends a change-brightness command to your lights to be able to reach the desired end brightness within that time span.
You had also mentioned that the light fades don’t look smooth even if you were to use a transition time of 25 seconds? Out of curiosity, if that’s something that you might still be running into, would you perhaps be open to sharing a log excerpt for that duration?
As while I’m guessing that there’s probably more than one way to tackle what you’re trying to do, the approach that I might take would be to:
First create an entity in your configuration.yaml that solely calculates the value of 5% + the current brightness of that lamp. For instance, you could potentially go with something along these lines:
- sensor:
- name: "Under cabinet brightness level plus five percent"
unit_of_measurement: "%"
state: >
{% set rawRoomLevel = state_attr('light.under_cabinet_light', 'brightness') %}
{## If a light is off, its brightness will return "None"? So first check if there's a valid brightness before doing the calculations ##}
{% if rawRoomLevel %}
{## the "X / (255/100)" bits below convert the current brightness from being based on 0-255 to being based on 0-100 ##}
{% set currentRoomLevel = ((rawRoomLevel | int) / (255/100)) | round(0) %}
{% else %}
{% set rawRoomLevel = 0 %}
{% set currentRoomLevel = 0 %}
{% endif %}
{{ (currentRoomLevel | int) + 5 }}
(Naturally, be sure to swap the reference to light.under_cabinet_light for the actual name of the entity that refers to your light.
Also, after adding that code to your configuration.yaml, you’ll need to reload your YAML files to have that sensor go into effect, which you can do under Home Assistant → Developer Tools [in the sidebar] → YAML [tab] → Restart → Quick Reload.
And then once you’ve got that new entity set up, I would then make use of the script’s Use an entity instead for the end-brightness value? section to point the script to that Under cabinet brightness level plus five percent entity that you had just created in the previous step.
And as always, if by chance you get stuck anywhere along the way, feel free to DM me or reply in this thread, and I’ll be happy to help you out!
Yup—you sure can! And while there’s nothing wrong with using three automations if that might be your preference, another option that you might also try is to make use of Home Assistant’s Run in Parallel action (which you can get to under the Add Building Block button within any automation)
Yeah, that sounds doable! And if there might be any portion of that sequence where you’re getting stuck, please feel free to reply in this thread, and I’ll be happy to help you out!
It so happens that the script only supports fading for one light at a time. Nonetheless, as youve discovered, you can definitely run multiple instances of the script at the same time using Home Assistants Run in Parallel action.
Off the top of my head, I’m not quite sure what might be happening here, but just as a starting point, could you try going to Home Assistant → Developer Tools [in the sidebar] → Actions? And then from there, if you select “Light turn on” from the dropdown on that page, and if you try to manually set one of your IKEA Trådfri lights to a given color temperature, does that work?
It could be the case that your lights might not support setting their color using Kelvin units?
If it may help, here’s one way that you can check that:
First, go to Home Assistant → Developer Tools [in the sidebar] → States [tab].
Then, within the Filter entities field, start typing the name of your light.
From there, under the Attributes column, you should hopefully see entries for min_color_temp_kelvin and max_color_temp_kelvin if your lights support Kelvin color temperatures.
For instance, here’s what I see when I search for one of my Hue lights using that screen:
Hi, @nbJosh—and thanks very much for your kind words!
For whatever it’s worth, the sticky part about RGB fades is that there’s no clear means for handling things if someone were to try to fade from an RGB color to a Kelvin color temperature (or the other way: from a Kelvin color temperature to an RGB color). And that’s because—as @parautenbachaptly conveys in this earlier comment—there aren’t any consistent formulas available for converting from RGB to Kelvin (and from Kelvin to RGB):
And while I’m not quite sure as to what might be causing that issue off the top of my head, I’ll be happy to help you with that if I can!
If it wouldn’t be too much trouble, would you perhaps be open to enabling Debuggin mode and then capturing the script’s log output while you run a test automation that triggers this scenario?
It so happens that there isn’t really an easy way to do this at the moment, but if you had really wanted to do this, I may have a potential workaround that you could try?
Basically, the idea is that you’d create a sensor in your configuration.yaml that outputs the current brightness level (0 to 255) of a given lamp that you had wanted to change only the color temperature for.
Then—from there—if you were to make use of the script’s Use an entity instead for the end-brightness value feature, you could set the end-brightness entity to that sensor that you had created earlier. And that way, you’d essentially be telling the script, “Fade this lamp from its current level to [the lamp’s current brightness level]”, which should let you then fade just the lamp’s color temperature.
And if perhaps you might like to give that a go, here’s some code that you could add to your configuration.yaml to get the current brightness level for a given lamp:
(Naturally, be sure to also update the reference to light.under_cabinet_light to the actual entity name of your particular light.)
- sensor:
- name: "Under cabinet brightness level"
state: >
{% set rawRoomLevel = state_attr('light.under_cabinet_light', 'brightness') %}
{## If a light is off, its brightness will return "None"? So first check if there's a valid brightness before doing the calculations ##}
{% if rawRoomLevel %}
{% set currentRoomLevel = (rawRoomLevel | int) %}
{% else %}
{% set rawRoomLevel = 0 %}
{% set currentRoomLevel = 0 %}
{% endif %}
{{ currentRoomLevel }}
You’re not the first person to request this, and I wish that there were a good way of doing this, but unfortunately there’s no clear means for handling things if someone were to try to fade from an RGB color to a Kelvin color temperature (or the other way: from a Kelvin color temperature to an RGB color). And that’s because—as @parautenbachaptly conveys in this earlier comment—there aren’t any consistent formulas available for converting from RGB to Kelvin (and from Kelvin to RGB):
For whatever it’s worth, the script’s “Cancel the fade if the lamp is turned off during the fade?” feature is ~supposed~ to be able to account for the situation where a lamp were to start off at 0%?
Nonetheless, I always appreciate bug reports, and I can’t rule out that there might be a weird bug or an edge case somewhere that could potentially be preventing that feature from working properly with some lighting setups.
If I might ask a favor of either or both or you—if you might be up for it, could you perhaps paste the YAML from a sample automation or script of yours where you can consistently see this bug happen?
And if it wouldn’t be too much of an inconvenience, if you might also be open to sharing the log output for what you see on your end when you run that script or automation with “Debug mode” enabled, that would be the icing on the cake!
(And once I have that data in hand, as long as I can find a way to consistently reproduce this bug in my home, I’ll do my best to fix it!)
Hi,
I ment that it would be nice if script have start brightness level also, there’s only stop brightness level now. So it would be possible to do for example 5%-80%.
