Hello all!
I’m sure there are plenty of good reasons for why, but the state of all scenes in Home Assistant are currently “scening”.
It would be practical if we could see what scenes are currently in use, e.g. scene state: “active”.
Currently my work around is to use helpers with input_text.
Best regards,
CF6
Yeah, this has been one of my annoyances for awhile now. Currently, I use the same work around as you do.
Also, make sure you vote for your own WTH.
Maybe I’m misunderstanding how a scene works under the cover but aren’t they analogous to a momentary push button - they are not active or inactive - they only trigger state changes when called?
All scenes always have the state of “scening”, even when they haven’t been activated. Thus, they always have the same state.
However, they should (at least imho), be more like a switch or at least have some sort of status of which scene was last triggered.
and how does home assistant know all those scenes are related to your single bathroom? What happens when you have scenes from other rooms? How’s it going to know that a scene in another room shouldn’t ‘turn_off’ the scene from your bathroom? What happens when you turn on a scene and someone physically turns off 1 light in your scene, or changes the brightness from 30 to 40? Is the system going to turn off the scene? Similarly, what happens if a person turns on every light by hand and it matches your scene, is the scene supposed to turn on even though you didn’t invoke it?
Hmmmm, good questions. For the first question, maybe scene grouping? [Edit: Or, maybe being able to assign scenes to areas? I know there’s a “Scene” section in the Areas UI, but I’ve never tried actually assigning a scene to an area.]
Perhaps a switch is a bad implementation for sure, but a status attribute would achieve the same thing I think. Something like scene_activated? I haven’t put a lot of thought into how I would solve it, but the current “scening” for state doesn’t work for knowing what scene is currently activated. There’s a lot to scenes under the covers and I get that 100%.
I think that the word “Scening” is probably confusing. Maybe a better state would be “Listening” or “Waiting.”
I can answer your questions based on how another product handles scenes.
This is an excerpt from Premise’s documentation and describes a scene’s two modes of behavior:
The properties of the objects in a scene can be set with two behaviors when a scene is played:
Set-Restore - sets the properties to the state in the scene when it is played, then sets the properties back to the original state when Play is false.
Set - sets the properties to the state in the scene when it is played and does not set the properties back to the original state. Play will revert to False immediately when the behavior is Set.
Note: Scene Reversion only applies if the Behavior property is set to “Set-Restore”.
An object’s properties will be changed to the state of the property which was set in the previous Scene when the Scene is stopped. For example if you have Scene 1, 2, and 3 all playing (started in that order). If you stop Scene 3, the property of the object would revert to Scene 2. If no Scenes are applied the object will revert to it’s ambient state.
Let’s compare Premise’s scenes to Home Assistant’s scenes:
Set behavior is like Home Assistant’s scene which is effectively stateless. Execute the scene and done.I’ll answer the questions based on how Premise handles the given situations:
Scenes behave independently of other scenes. However, not only can a scene set the state of an entity, it can also be used to turn on another scene (and start/stop timers and set global variables). So it’s possible for one scene to call another one.
Nothing special happens other than whatever you changed gets changed.
What’s important here is that when a ‘Set-Retore’ scene is deactivated all entities are restored to their original states, including any that may have been manually changed while the scene was activated. This means that any manual changes are simply considered to be temporary deviations from the scene’s “orchestration”.
Simple example:
Scenes set an entity’s state, they don’t monitor an entity’s state. So if various entity states happen to match a defined scene, the scene is not automagically turned on.
I haven’t used scenes as yet so I’m not sure, but do they have a last_triggered attribute ?
If so you’d be able to determine which scene was last used, and when any scene was last used
Not that I know of. They only have 3 attributes that I know of: entity_id (list of entities in the scene), id, and friendly_name.
What I do currently is set an input_text with the scene id. I have to do that from every automation that I have the deals with scenes and it’s tedious to say the least.
Don’t forget that on startup, all entities have their last_triggered set to the startup time. This behavior may cause calculations employing last_triggered to produce unexpected results.
Afaik it should be possible to create a scene sensor based on the entities in the scene. It seems to me for instance that it is possible to recreate such a sensor in appdaemon by simply subscribing to all state changes with the right condition and then checking if all states are ‘in place’, or am I missing something?
As long as scenes are not mutually exclusive, they can both be on, there’s no need for an overall logic.
I tried coding this a while ago, but got lost in the logic of scenes in the home assistant core code and gave up. Maybe I’ll give it another try.
Yes, this is what I was getting at with my comments. Basically, scenes don’t have on/off states.
All entities have a last_updated and last_changed. I don’t use scenes so I cant say if either of those are changed when the scene is executed. I would assume last_changed never changes if the state is always ‘scening’. Last updated may change when you activate it. Someone with scenes should toss this into the template editor and see what happens:
{{ states.scene.xxxx.last_updated }}
Yes it should be possible, I was trying to make it known about the complications behind doing this. I’m not against something like this, but we’d need to have requirements before implementing it.
Instead of updating an input in every automation you could write an exclusive automation that listens for a scene change and writes the scene name to the input (service: event, domain: scene, service: turn_on)
That’s a genius idea! Thanks for the tip!
I understand a scene is just a shorthand to set/restore different states. But check if the referenced states are currently equal/different to the definition sounds not that hard to me. Why do we need some kind workaround to do so?
No one said it was hard, you need to build requirements before moving forward with a PR.