I’m not, because I personally prefer to set the states using scripts rather than scenes. For example for climate entities; I just want to set the preset and not the temperature/HVAC mode.
Nonetheless you could also start a scene in the script or instead of the script.
You replied to my post, made over a year ago, to claim you made an improvement, yet it doesn’t employ what this topic is all about: scenes.
Your example suggests replacing a scene with a Template Switch that manages all entities which would otherwise be in a scene.
That might be practical if the scene is created by the user but impractical if it’s a scene created by an integration (increases maintenance by having to keep the entities of the value_template in sync with those in the scene; no single source of truth).
Come on, don’t be a jerk. I’m not trying to one-up you.
Correct, and this template switch is a representation of whether a scene is turned on or turned off. In my eyes this is a proper workaround for statefull scenes, which is what this topic is about. It works perfectly well for my use-case and it might help others here as well.
True, but workarounds are almost always impractical.
So please be nice here - I’m only trying to help others out, as should you.
Please take a moment to review the community’s Guidelines.
I never publicly claimed or privately felt that you did.
You responded to one of my year-old posts claiming an improvement that ultimately doesn’t employ the central element of this topic’s discussion: a scene entity.
Your workaround is an outright replacement for a scene entity. Although it may suit your particular use-case, it’s less practical for those who have existing scene entities especially if it’s a scene created by an integration (as explained above). To be clear, the example I posted a year ago uses a scene created by an integration (UPB).
For users with existing scene entities they created, your suggestion requires them to replace them entirely. It’s a feasible option for anyone who wants stateful scene-like behavior without employing an actual scene.
That’s good advice you should consider before saying “don’t be a jerk”
As for helping others, check my profile, over the past five years I’ve helped thousands of community members.
The tone of your message(s) are dismissive (why mention it is a year old post? why questioning whether it is improvement or not?), while I make an effort to help others out. Secondly, it is an improvement on your post, because it exactly implements the functionality that scenes are missing as you’ve mentioned in an earlier post:
It therefore is an improvement, so your dismissive tone is ungrounded.
Both not true;
If you’re able to define the state of a scene in a template switch, like in my example, it can serve as an addition to using scenes - even if they are from integrations.
And even if the example does replace a scene entity, so what? People googling statefull scenes, or active scenes will find this topic and can use the example.
Words I totally agree with, which are also applicable to my example above 
Your responses imply you may not have read and understood the discussion from a year ago. That may be why your example paradoxically purports to enhance a scene entity by not actually using a scene entity.
Lol, as if I was not part of the discussion.
Anyway, thanks for helping me understand the purpose of this topic and calling out that I didn’t use the scene entity 
That’s at least the second time you have misinterpreted what I wrote. I never said you weren’t part of the discussion (you obviously were) but now, a year later, your responses appear to suggest you have misinterpreted what it was about, namely providing a scene entity with a state. Your example didn’t employ a scene entity. Yes, it can include one but then the user must maintain two sources of entities, in the scene and in the Template Switch’s value_template.
A scene provides convenience. It’s a single entity that can set the state of multiple entities. However it lacks the ability to indicate when it’s active/inactive.
It has always been possible to replicate the functionality of a scene using, for example, a script or a switch that is based on the Template Switch integration. The advantage of a Template Switch is that it’s not stateless like a scene (the central pain point of this WTH).
I have several hardware-based scene entities (produced by the UPB integration). The members of the scene are maintained by software outside of Home Assistant. I shared how I simulate a state by wrapping the scene in a Template Switch. I used an Input Boolean to serve as the state indicator.
Your recent post replaces the Input Boolean with a template that references the entities existing in the scene entity. My point was, although effective, it comes at the expense of increased maintenance; it requires duplicate sources of entities.
If you add/remove an entity from the scene you must remember to do the same in the value_template. By doubling maintenance, it negates the convenience and efficiency of using a scene.
To minimize this inconvenience, my point was that if one is referencing entity states in a Template Switch, one may as well also use it to control the entities thereby making it the sole source of entities. However, this is merely using a Template Switch for what it was designed for and by eliminating the scene entity it essentially loses the thread of this WTH (a scene entity ought to have a state). It’s why I said
If anyone’s still looking for a solution, I wrote a boolean template sensor which tracks if any entity in a scene had its state changed after the scene was last activated:
{% set scene_name = 'scene.livingroom_bright' %}
{% set scene_activated = as_datetime(states(scene_name)) %}
{% for entity_id in state_attr(scene_name, 'entity_id') %}
{% if (states[entity_id.split('.')[0]][entity_id.split('.')[1]].last_updated - scene_activated).total_seconds() < 1 -%}
{% else %}
false
{% break%}
{% endif %}
{% if loop.last %}
true
{% endif %}
{% endfor %}
Just change the scene_name variable to the name of the scene you want to track. So far, I’ve only used it for lighting but it seems to be working fine.
My reasoning: a scene only becomes active when it has been turned on, not when all related entities happen to be in a state that match the scene. As soon as any entity in the scene changes its state, the scene is no longer active.
That’s really useful - thanks for sharing 
Smart idea!
The template below checks if any of the entities used in the scene was changed more than half a second after the last time the scene was activated, without the need for a for loop.
{% set scene_name = 'scene.new_scene' %}
{% set scene_activated = as_datetime(states(scene_name)) %}
{% set time_check = scene_activated + timedelta(seconds=0.5) %}
{{
expand(state_attr(scene_name, 'entity_id'))
| selectattr('last_updated', '>', time_check)
| list
| count = 0
}}
Note that this will always be true after a HA restart, as that will reset the last_changed property, but not the scene state
In each scene change event there is a context id (in this example ending in 90CYP.
Any external changes to the scene, e.g. a light being switched off, references that scene’s context ID.
With this it should be quite simple to add an additional property to the scene state as being valid, and any event seen which is not a scene activation with that same context ID (which must be an action invalidating the scene) should remove the valid state from the scene.
So in short, it’s clearly possible to add statefull scene’s
As I don’t see a use case I didn’t build a node-red thingy yet, but should not take long
The problem with this is that the contex.id will not change when the entity is already in the wanted state set in the scene.
I don’t see how that’s an issue ?
a scene is a scene, and only has a single valid state, right ?
The way I read your post, you want the scene to be on if the context.id of the scene matches the context.id of all entities which are set by it.
However, if in a scene you eg set a light to 100% and that light was already on 100%, the context.id of that light will not change, so not all entities will share the context.id of the scene. So how to determine the state of the scene then?
lemme test this and think about this
Just want to say this helped me a ton and was exactly what I was looking for. Thanks!
This is great! I’ve expanded this to work with a template select helper. It shows the currently “active” scene, and allow you to switch it to another one defined within the given area. It also empties if any of the entities change after activating a scene.
State Template:
{% set area_id = 'my_area' %}
{% set last_scene = expand(area_entities(area_id))
| selectattr('domain', 'eq', 'scene')
| sort(attribute='state', reverse=true)
| map(attribute='entity_id')
| list
| first
%}
{% set scene_activated = as_datetime(states(last_scene)) %}
{% set time_check = scene_activated + timedelta(seconds=0.5) %}
{% set changed_entities = expand(state_attr(last_scene, 'entity_id'))
| selectattr('last_updated', '>', time_check)
| list %}
{% if changed_entities | length == 0 %}
{{ state_attr(last_scene, 'friendly_name') }}
{% else %}
None
{% endif %}
Available Options:
{% set area_id = 'my_area' %}
{{
expand(area_entities(area_id))
| selectattr('domain', 'eq', 'scene')
| map(attribute='name')
| list
| sort
}}
Action:
action: scene.turn_on
target:
entity_id: |
{{
states.scene
| selectattr('name', 'eq', option)
| map(attribute='entity_id')
| first
}}
A warning is shown in the logs when the state becomes “None”, but I can live with that.
You can do this to avoid the warning:
{% set area_id = 'my_area' %}
{{
(expand(area_entities(area_id))
| selectattr('domain', 'eq', 'scene')
| map(attribute='name')
| list
| sort) + [ 'None' ]
}}
if: "{{ option != 'None' }}"
then:
- action: scene.turn_on
target:
entity_id: |
{{
states.scene
| selectattr('name', 'eq', option)
| map(attribute='entity_id')
| first
}}
Unfortunately, I tried this, and “None” always appears to convert to null, causing the warning to appear when the state changes. When I use a different value, the warning disappears. I would rather “None” wasn’t an option in the input, as it would do nothing when selected. I’m not sure if there’s a way to do that and also not receive the warning.