Transcendent brightness handling

Hi, i would like HA to fade light brightness independent of the light being turned on or off.

I think it would be beneficial if the brighness state attribute also “exists” when the light is turned off, so that a transcendet modification of the brightness is possible.

also the very welcomed brightness_step (brightness_step_pct) would be great to be usable indepndent from the service light.turn_on or at least additional with light.turn_off to have the possibilites to perform realtive brightness modifications when the light is turned off.

i want all my lights to fade from a bright state during day to a dimmed state in the evening. this transition should be over a course of 1 or 2 hours. durign this time, also turned off lights should follow this trend, and when turned on, it should have exact the brightness value of the transcendet dimming, and even continue dimming.

thank you.

When the light is off the brightness by definition is zero.

ok, so let me rephrase:
it would be cool to decouple the brightness information from the turned on state.

this is the case for e.g. shelly dimmer devices.

so a transcendent brightness information would make scenarios as the one mentioned above possible, or at leas much easier to implement.

Check out adaptive lighting, could probably be a solution for your goal.

I have this working in some rooms.
I use the brightness value from adaptive lightning. When I turn on my light the brightness is set from this value using templating

Why do you use templating for this? The adaptive lighting component already does this automatically.

this sounds very interesting. at a first quick look, though im not sure if it exactly fits my needs.

i will test it out soon. thank you.

still, decoupling brightness information and turn on information is a valid feature request, imo.

The hardware needs to support this and most bulbs don’t support this.
Most bulbs turn on to the previous brightness/color first and then change to the brightness/color that you defined. That’s nothing that can be solved through software.

i see, so using shelly dimmer from the very fist beginning of my smart home has lead to wrong assumptoins about the hardware out there :slight_smile:

sad. transcendent brightness info would have enormous potential.

thx anyway

Can you name some examples? I don’t see any benefits from this, that are not covered by the adaptive lighting component.

well as the automaion setup can also be modified by frontend, it would be a overall benefit of the workflow of creating scalable quick individual automations, just by selecting atrributes from a drop down menue (this is the future i think)

i have to admit i havent used the adatpive lightning component yet. as i alread mentioned, of cours im highly intersted, but e.g. im not fully comfortable with the idea, do only be able to “lock” the all day long brightness to the position of the sun.

rather i would like to have static light durign the day, and only in the evening i want a sophisticated light transition.


Create an automation that turns on adaptive lighting only in the evening.

Just my use case. I don’t want the light changing automatically in that room( as it plays havoc with my white balance on my webcam), only when I turn it on.

Create an automation that disables the afaptive lighting when your webcam is running or something similar.

What I have works for me

ok, now i am testing around with adaptive lighing and it seems, that this is perfect for my needs. :see_no_evil:

thanks @Burningstone

i will continue spreading it across my whole lights and check if there is any need, which could not be fulfilled with this integration.

1 Like

now i ran into an issue:

every light, which havent been turned on since brightness value of have changed, “flickers” at the “first” turn on with the new brightness value.

so light get turned on with old brightness value, adaptive light integ. notice and update to the new value …

during day its just a second of low light. at night on the other hand a bright short “flash” is noticed.

here, a transcendent brightness information would be beneficial, because from the very first millisecond the light would turn on with the correct brightness value and e.g. no bright flash will frighten you in the evening and night.

my guess is, that adaptive light integration also can only update throughout the light.turn_on service. so we are back at my initial feature request.

Again, this depends on your hardware, most bulbs are not able to set brightness when the lights are turned off. This is nothing that you can handle with software, when the underlying hardware doesn’t support it. The only workaround that I know is turning the lighr on at the desired brightness for 1 second and then off again, so that it will turn on at the correct brightness later on.

so, dimming actors which support this are rare yet, ok.

but tell me, do you think the idea is not good at all, or is just the cost-benefit consideration poor, because of rarely supported hardware ?

because the idea itself is actually not bad, imo … i mean devices become smarter … would a decoupled system mandatorily be not compatible with bulbs which are not “smart enough” ?

whats with another service such as e.g. light.set, to set brightness ?

The services already exist for bulbs that support this feature. At least for LIFX it’s the case -> here
Personally, I think that’s the way to go, to add a specific service for the platforms that support it, instead of a general light.set or whatever service that doesn’t apply for most lights.

Then you should at least vote for your own request :wink: