So I experienced the following today while trying to set up a shelly i3 switch as a trigger for calling scenes: (the switch is momentary)
I have one automation which calls a bright scene when there is no light on - on a single flick of the switch
A second automation switches all the lights in the room off on the condition if a light is on - again on a single hit.
A third automation should call a darker and more warmer tone on a double click.
The problem i had is the color temperature did not change from one scene to the other when the lights are turned off in between.
I double checked in the scenes.yaml and the values are all there and all correct.
I built a workaround which works now but i still wonder if i missed something.
Another thing i noticed is when there is a transition set for switching scenes with different color temperatures and brightness values the transition works only for the brightness while the color temperature switches immediately.
I’ve noticed similar behavior with scenes, but have not dug into the issue yet. I have a simple scene to set several bulbs on and as a warm white. Once turned off, the next time the scene is called they default to cool white.
It is hard to tell without seeing the scene and having similar devices around. My guess is that it depends on the integration implementation what happens if you try to set all the entities properties at once, which is what seems to happen when you create scenes from the UI.
That is why I use scrips instead of scenes. I set what I need to change, and it does not set things I care less about. I can use conditionals and templates and input_numbers. I have not experienced the troubles you name. But that could be sheer luck of course.
But if it is indeed integration implementation dependent, then it would be nice if the integration owner fixes it. Because on the fly scene creation and restoring is a neat feature, and it will suffer the same quirks.
Well, I’m still googling/reading → as it’s not a “new” nor “rare” problem as far as I can see. No matter “who” is to “blame”: HA / integration / device → unfortunately, calling the scene twice “kinda works” but is not “ideal”.
The scene was created by using the GUI:
- id: '1711663231067'
name: Evening Red 2
entities:
light.wiz_lighbulb_bedroom:
min_color_temp_kelvin: 2202
max_color_temp_kelvin: 6535
min_mireds: 153
max_mireds: 454
effect_list:
- Ocean
- Romance
- Sunset
- Party
- Fireplace
- Cozy
- Forest
- Pastel Colors
- Wake up
- Bedtime
- Warm White
- Daylight
- Cool white
- Night light
- Focus
- Relax
- True colors
- TV time
- Plantgrowth
- Spring
- Summer
- Fall
- Deepdive
- Jungle
- Mojito
- Club
- Christmas
- Halloween
- Candlelight
- Golden white
- Pulse
- Steampunk
- Rhythm
supported_color_modes:
- color_temp
- rgbww
effect:
color_mode: rgbww
brightness: 112
color_temp_kelvin:
color_temp:
hs_color:
- 1.694
- 97.255
rgb_color:
- 255
- 14
- 7
xy_color:
- 0.697
- 0.3
rgbww_color:
- 255
- 0
- 0
- 8
- 23
friendly_name: Bedroom
supported_features: 4
state: 'on'
You’ll probably be able to fix it by reducing it to one color coordinate system in the scene. But as soon as you edit in the gui you’ll be back where you started.
It is not so much blame, but the gui cannot decide for all types of devices, brands and models what to do. So i figure it takes all attributes and tries to restore them (in some order determined by the code). A lot of those have overlapping information. Applying them all, maybe in a less than great order may have unexpected side effects.
The service calls from scenes do something similar to what I mentioned above: pick one way to specify color/temperature that you know works, not use three or more in succession. That way it is more clear what is being done.
No success, unfortunately: I left only rgbww_color setting, removing other color specifications, restarted HA, the effect is still the same (first call to the scene only turns on the light, being bright white, second call finally sets the color – and it’s “too slow” for not being noticeable):
Although it kinda defeats the purpose of having scenes at all… [?]
Scenes are supposed to enable a quick and easy saving/restoring state of multiple devices. I just set up the house the way I want, save scene, done.
If I were to convert a scene to a script, I’d have to know exactly what needs to be set to which device, and what exact services need to be called, and how.
True, but creating something that works for all 50.000+ types of devices is hard, Some devices will probably handle it more gracefully than others.
What you say is the other way around: the light requires it to be set a certain way, how is HA supposed to know to without integration builders taking care of the tricky bits?
The question of turning on a light using a predefined brightness/colour has been asked multiple times in this forum. The general consensus seems to be that this is entirely hardware dependent. Some brands of lights support extra parameters when turning on, but most don’t.
My suggestion is to check if your bulbs support a (global) transition time when turning on. That way when you call the first scene, it is still ramping up the brightness when the command for the second scene arrives.
I understand now, that it is my bulb’s issue, for sure:
IMHO there should be some kind of flag to mark which lightbulbs will work (with scenes) and which don’t (so HA could optionally do the workaround of turning them on twice) → but that’s more for a FR than this topic.
