Not sure if this is a bug (in deCONZ, HA) or if this is a configuration issue.
When I’m calling light.turn_on with a brightness, the light briefly flashes with the brightness from when it was turned off, and only then dims to the desired brightness.
Example steps:
Turn light on at full brightness (255).
Turn light off.
Call light.turn_on with specific brightness (e.g. 64).
Expected result:
The light turns on with brightness 64.
Or dims from 0 to 64 if using a transition.
Actual result:
The light turns on with previous brightness from when it was turned off (255).
Then quickly sets brightness to 64.
Or dims from 255 to 64 if using a transition.
I find that flash unexpected and it looks weird.
When I tell the light “turn on with 64” I never wanna see 255.
Also, when I tell the light “turn on to 64 with a transition” I wanna see the transition from 0 (as it was off), and not from the previous brightness.
I feel like this should happen:
a) When I just turn the light on (or toggle it) without specifying a brightness, it should use the previous brightness.
b) When the light is off and I turn it on with a brightness (and transition), it should assume a previous brightness of 0 and then set the desired brightness (or transition to it from 0). No flash with the previous brightness!
c) When the light is already on and I call turn_on with a new brightness, it should just set the new brightness (or transition from it from the current brightness).
Not sure if this is a bug or working as intended.
If this is working as intended, then do you have a tip for achieving this behavior without too much effort in my configuration?
I could get half-way there by first setting the brightness to 0 before turning it off.
That would cover case b) and c) above. Would not cover a).
This is usually a limitation of the device. It cannot process the dim variable while the device is off, so it must turn on first with its previous properties, then it will dim accordingly. I have quite a few devices that act the same way. Its particularly annoying because I drive LED strips for ambient lighting at night, if they flash with the daytime settings it will definitely blind you. I usually have it so the “off” command actually sends the dim and color change variables before it turns off, so when it turns on it wont blind you.
Tim, so your “off” command sets brightness to 0 before turning off.
Is there a good way to configure this globally?
Or do I need to adjust all my automations to call “brightness = 0, then off” instead of just “turn off”?
I’m not aware of a way to set it globally. I had to adjust my automations accordingly.
I’m using Node Red to create an automation flow.
My automation goes something like this:
Kitchen button press > If LED strip is ON, dim to 5% and change the color from white to red (this is my night time ambient setting for when my motion sensors in the home detect motion at night, in your case you’d just send brightness = 0% and color if you’re changing colors). Then the next flow will be to send the actual OFF command. So it essentially changes brightness in one automation, then turns off in the next.
Another kitchen button press at this point will turn it ON with the brightness and color all in the same flow/automation, as the the device can process brightness and color with ON.
But generally, you guys are saying that this is a problem of the Paulmann/Osram lights?
They get the command “fade in”, but they turn on with the prev brightness before fading in? Other lights/dimmers behave as expected? I.e., Home Assistant or deCONZ cannot fix this?
mine did do that but i have a work around for both
for mqtt i send 100% when light is turn off so next time it turn on 100%
my mqtt Dimmers
alias: Lounge Light OFF
trigger:
- entity_id: light.lounge
platform: state
to: 'off'
action:
- data:
payload: 100
topic: cmnd/Lounge/Dimmer
service: mqtt.publish
and my deCONZ ZigBee stuff
as u cant send 100 (255) brightness when off
had a brain fart why do it when turn on
- id: 'front door lights ON'
alias: front door lights ON
trigger:
- entity_id: light.front_door_2
platform: state
to: 'on'
condition: []
action:
- data:
brightness: 255
entity_id: light.front_door_2
service: light.turn_on
i have a issue different to you but also with the brightness. I have a motion detection turn on light to brightness automation witch should turn on the light to full brightness (255) with transition 3 seconds. After 1 Minute the light will turn off by fading the brightness to 0 in 120 seconds. The most time the light will turn on without fading to full brightness! The light is still at lowes brightness.
I use Ikea tradfi GU10 bulbs and the deconz Conbee. anyone else with such problems?
So this makes sense to me but I would think there is a way to handle this within the integration so we all don’t have to go making template lights or template switches to work around it.
I don’t recall my sengled lights behaving in this fashion, however, in one of the two most recent updates (currently on 0.114.2), I am experiencing this behavior. I see there is now an attribute circled here, which I suspect might solve the issue, but, I can’t find any documentation anywhere as to how to set it. Creating template switches, and manually programming all the lights sounds like a major pain. Can anyone shed any “new light” (no pun intended), on this situation. Thank-you.
I am wondering if it makes sense to raise a Feature Request to have the chance to change the default behaviour of turn off light to set brightness to 0. This way when turning on also the selected brightness and color is correct from the start.
No, I never did. In fact, I reprogrammed all of my automatons to dim the lights to 1% before turning off; thereby eliminating the “flash”. I was so successful, I honestly forgot about it; but, it should probably be fixed “for real” somewhere.
