I just discovered the power of Scenes. I was previously just using scripts, but having the ability to just add entities and live-preview the settings I want for them is quite convenient.
However, as I’m currently trying to setup multiple scenes for my living room lightning setup, I find that the way of configuration could be improved a lot:
group multiple scenes in a single scene selector. I’m currently using an external input_select variable with multiple options, and automations that triggers scenes based on the input_select value, but that’s not very intuitive and a bit cumbersome.
being able to detect scene statuses. If I manually trigger a scene directly, or update a light entity manually, it won’t be reflected in the input_select value (and so not on the dashboard as well). It could be useful to be able to have an automatic “manual” override that would detect that I changed a single light setting (or used other light switchs/remotes) and update the input_select value accordingly, instead of having to check against all scene settings to see what currently matches.
Scenes do not have a state they are a collection of actions. “Turn this on, turn that red, etc…”. Would you want your scene to become “active” if for example someone just by chance manually put a bunch of devices in the same state as the scene would?
I started the same way, setting up “ambiances” using scripts (+ input_select + automations), but never quite liked the UI/UX for that (I never remember if I need to enter brightness as percentage, or 0-254, or 1-255) and felt a bit like hacking keeping all these objects around.
Versus just creating a scene, adding all my lights and just configure with them as I normally do using the regular dialogs, with instant feedback, save and boom I’m done. I still need to have the input_select + automations around, but that’s why I was thinking about hiding all that in a “group” of scenes.
This is where I would probably disagree. Scripts are great (and much more powerful) for that, but I see scenes probably more as a snapshot of the state of some devices/entities. If said devices/entities are in the same state as configured in the scene, then it would mean that the scene is “on”.
I know it’s not designed like that for now, but as there’s some work being done on scenes in the recent releases, I was thinking about how this could be developed even further.
I agree that it would be nice if Scenes had states. I think it would enhance their usefulness quite a bit as you could then easily pull them into automations. For example “run nightly lights off / lockup routine unless XYZ scene is active”. I know that can be accomplished in other ways already but it would be nice to use Scenes like as well.
I can imagine this. I actually have a Python script which checks a list of entities in a group on state. Works fine on a HA Blue.
I just use it to see if the lights are normal, if not clicking the button will set them normal, if they are the button will switch the lights off. This button will show if the lights are normal or adjusted based on the scene detected.
Maybe the odd case, but thats what you get with a large enough user base
I too understand why scenes do not have a state (or rather: why the state is something else entirely). And I too started using scripts over scenes, mainly because they allow for conditions and because they do not set my home in the scene’s desired state when editing.
But at the same time I have template entities that try to detect if the entities from the scene are in the state that the scene expects, so I can show on the dashboard what scene is active. Those do turn on when you manually pick the same combination of states, and I like that. But creating those template entities is a pain. So much so I have several scenes on my todo list, waiting for when I’m in a masochist mood So I do see where this is coming from.
This is a perfect topic for a WTH because it is about what many users hope and expect, despite it being technically challenging.
Scenes having implied states is somewhat problematic because the details really matter and lead to surprises. If your light intensity on one light is off by a percent the scenej is off, if a color hue is minimally different the scene is off. There are lots of possible attributes that would need to be exact. This would almost assuredly then result in requests for guard bands in the definition of the scene. It’s a rathole other hubs have debated.
On the other hand I do wish we had a notion of a scene group that made all the devices in the group appear in each scene. I find it common to have a room with multiple scenes in it using the same devices and it is too easy to miss a device from one of the scenes unintentionally.
Absolutely! Count me in the camp that thinks this would be the primary value-add of using a Scene over a script. Performing a list of actions is the definition of a script. Defining a collective state and being smart enough to not just set it, but know if it is true, seems like a key smart home feature… sort of an advanced next-generation concept of Groups.
In theory you can do this today with a complex switch template, making it a somewhat advanced feature and difficult to maintain (notably, this is also true of Groups, so they have their own UI). It seems sensible to make the Scenes UI a convenient way to set all that up, rather than have two UIs that effectively do the same thing (scripting). You could package this as a feature with a different name, but what would you call it if not Scenes? State Presets? Diverse Groups?
I’d love to have that as well, but I understand that detecting that collective state might not be trivial and/or would be resource intensive.
The middle ground I’d be happy to live with at first would be having scene groups, with only one possible scene active at the time (that would be the “state” of the group), and a “other/manual” fallback state that would be set if I configure one entity of the scenes outside of the scenes selections (if I manually set a light directly for example).
This is somewhat possible using scenes + one input_select as the scenes group state + automations (to trigger scenes when changing input_select value), but the “manual” override is a bit more tricky to detect as it’s a bit challenging to know if one entity has been updated as part of triggering a scene or from a direct action on the entity. Having scenes groups directly could be helpful with that?
The reason I currently have template sensors to see if the most used scenes are on, is that if some one changes the states with manual actions, or automations affect parts of the scene, I want to know the scene is no longer “on” so I can activate the scene again to set it back.
I accidentally posted a duplicate of this WTH, so figured I would add my thoughts here. I’ve worked as a programmer on some of the luxury home automation systems out there, and stateful scenes are one of the most useful features when programming indicators on a keypad. It’s especially useful for rooms with lots of lighting zones that are part of multiple scenes. It’s also really nice to be able to just edit a scene live, and then know that the keypads will automatically track the modified scene without having to edit it anywhere else.
And of course, the scene becoming active whether it was actually applied or individual lights were turned on to get the same result, is very useful for maintaining actuate status indicators.
not so sure anymore.
So I do see where this is coming from.