I’ve got a set of scenes, that set my lighting during the day and night and also keep my speakers [sonos, google homes etc.] with a specified volume. I can override it by saying/setting volume higher or lower, but I use scenes to set “default volume” for each time of the day.
very convenient, as for example: after playing music with loud volume at the midday, I can be sure that if at the evening I’ll ask google to play some music - it won’t blow my speakers but it will play gently with the “evening setting”. I know that I can set night profile on the speaker, but it’s not enough - anyway, why I bother to do that if I have Home Assistant and all the scenes configuration!
now mandatory “states” goes in.
by setting that - I’m forceing my media_players to be off when I don’t want them to. I’m ok if the volume changes because the time of the day changes, but with state in the scene [and for the safety - I’m gonna use “off”] if the speaker is playing during change of time of the day - it will be stopped.
is it me, or it just sucks and some basic features were cut down now?
I don’t really understand what that means, but why would anyone want a scene ‘reproduced’? Scenes are called to set a series of things in one go to the state of the authors choosing are they not? That’s why the scene’s state is always ‘scening’.
Seems another case of devs not understanding how end users actually interact with the product.
Seems like there’s a lot of issues with this change to scenes. All of my scenes stopped functioning correctly. The only thing that still works is brightness. “color_name” and “transition” no longer work. I was able to change all instances of “color_name” to “rgb_color” to get the color changes to function but haven’t been able to find a working substitute for transition time. Weirdly, the service calls from the developer tab work fine, but scenes saved in the configuration.yaml do not. I hope they get this sorted out soon. In the meantime, I guess I’ve got another reason to migrate even more functionality away from Home Assistant to Node-Red…
I upgraded yesterday and noticed today that my wake up light didn’t turn on slowly. Is transition for scenes removed? Is there anything I should do to make it work?
I’m not sure I really understand how to use an existing state in a scene with a template. My scenes are pretty simple, just setting brightness and color. For example:
name: Movie Time
entities:
light.living_room_color_left:
state: on
brightness: 32
# color_name: red
rgb_color: [255, 0, 0]
transition: 60
light.living_room_color_right:
state: on
brightness: 32
# color_name: red
rgb_color: [255, 0, 0]
transition: 60
This produces the correct color using “rgb_color”, but not “color_name”. Brightness level is correctly set, but transition is ignored. @nickrout I suppose I might be able convert all my scenes to automations, but I guess I’m really most interested in how scenes are meant to function after the update. The documentation doesn’t really help explain, so I’m just kind of lost…
I had opened this issue on the gitbub repo, but it’s been closed with some illuminating comments and clarification from Paulus. For anyone that’s interested, here is the pull request that actually clarifies a lot of the breaking changes: https://github.com/home-assistant/home-assistant/pull/27182 (notably in the “Additional Information” section)
My understanding is that these changes were made to comply with architectural standards and the loss of some functionality is just a necessary casualty. Going forward I think the best approach might be to use scripts to scripts to achieve the light transitions.
IMHO the change doesn’t make any sense. I understand they want to keep some standards through all config, but that made scenes less useful and almost obsolete. why should we bother with scenes if scripts/automations are needed inside of them or even they did stuff better than scenes? devs just killed one of the important features. they can get rid of scenes anyway as they are pointless…
It would be a lot easier if scene.turn_on had a transition argument. That would not break scenes requiring reproducable state and it would give us a link between scenes and transition.
The quote in that thread from the Supreme Leader is “Scenes are a declarative interface to reproduce a given state”
I refer back to my original observation about devs that don’t understand how their own products are used because I would estimate that prior to this change around 100% of end users used scenes in homeassistant to set a scene
for me that official explaination means rather that “scenes are scripts, but with different name” than “scenes are for setting scenes”. so I totally agree with your observation. they should change “scene” to something other, so we don’t ever confuse it…
No 100% of the users that used scenes, used them to set scenes, not to set states.
To an end user ‘states’ are inconsequential, it’s the visible and audible effect from the automations, scripts, scenes that matters.
Previously scenes handled setting things (entities) to a particular setting (state or attribute) in a particular way (transition). The 2 reasons they were so powerful is that you didn’t have to specify states and you could transition the changes at whatever pace you desired, and it would do so for all the concerned entities simultaneously.
Scripts do things in sequence, as do automations.
So effectively removing all the powerful parts from scenes has made them pointless, as you now have to fire a script or automation to set the transition and if necessary template the state.
I found little use for scenes before this change. It was less YAML than a script with similar functionality in some cases, but otherwise, did nothing special that a script couldn’t do and yet, did far less than a script could do.
While I certainly understand the goal of this change to scenes it does make them even less useful for me.
In short, I use scripts instead of scenes. They are fully capable, even though the YAML is more verbose.
yeah, but even the name “scenes” said that it’s an option to set specific scene, theme, etc. in the room. for many (me included) it was more logical than using scripts and even although few things were very similar, it was natural to use scene for setting light values, volumes etc. without having to set the state which in case of media players totally resets it’s current state.
now it looks like duplication and makes no sense for scenes to exist at all.
Admittedly, I’m having trouble thinking of a compelling reason to use scenes now. In my case, I liked having scenes as a way to organize all my lighting looks into a separate folder, and I could simply call them from a script or automation. This made my scripts and automations less verbose and allowed for reusability. Because I prefer smooth lighting transitions over the abrupt default behavior, almost all of my scenes had at least a couple seconds of transition. So of course I can accomplish this with scripts, I’ve already converted them all over and given them a “lights_” prefix to help me keep them organized, but that leaves me really wondering if I’ll ever really have a use for scripts again.
While I do understand from a dev point of view why this was done, and I’m not just looking to complain, but I’m really interested to know if anyone has an understanding of how scenes might be useful or preferable over scripts at this point. Thoughts?
