You must specify a color along with it. So it won’t retain the bulb’s previous state, and you can’t transition between two colors.
It only works for turning a bulb ON, not off. So it feels incomplete.
You can also set transitions in scenes, but that won’t work for one-off light change requests (e.g. “Alexa, set living room lights to blue”).
As a dev, I know things are often much harder than they seem, but it does seem pretty simple for the aesthetic benefit – that “smart home feel” that comes with lights fading in and out in unison.
Question: Is it the wrong approach to change the base light.turn_on service to accept an optional “defaults” object that it uses to inject params not explicitly sent by an integration?
As opposed to making each light integration implement that logic before calling turn_on.
I’m gonna push up a PR soon that does the latter, if you (or others) prefer to talk over code.
EDIT: I have the the logic flipped in my head. The base light.turn_on must call the integration’s turn_on, not the other way around.
not only transitions.
the light_profiles.csv only supports xycolor, but there’s no way of defining color_temp
We can’t do enough with xycolor values alone… Some way of defining a color_temp is really needed.
I don’t see a lot of activity here My lights (hue and others) only support HS and color temp.
For HS, xy color can be sufficient.
for color temp, there’s nothing…
I cannot get the same white color in xy color, as I can get in color temp mode.
So, please, add color temp too ?