Scenes are basically useless IMO outside creating and restoring states on devices. Parallel scripts do the same thing as scenes and have way more control.
Or, framing the same sentiment in a more positive way, scenes are extremely useful and well designed for the specific task of creating and restoring states on devices. 
When you need to perform other tasks, there are tools, like scripts, designed for those purposes.
I’m a great fan of scenes for efficiently managing sets of interdependent entities in different parts of the house.
For each location I have a “standard” (default or ‘deactivated’) scene, and a group of alternative scenes that control states of lights, enabled/disabled automations (particularly for motion triggered lighting), media players etc.
(A markdown card auto-generates YAML for all my scenes based on current entity states, for easy configuration.)
(Template sensors keep track of the currently active scene for each part of the house.)
I’m not sure that HA could automatically interpret a single scene to determine what the default ‘deactivated’ alternative should be. In my case every scene enables some entities and disables others, and the “standard” default scene for example usually turns a set of automations back on (to take back automatic motion control of lights when other scenes and associated entities are off).
The suggested function of scene.deactivate to turn all entities off could produce counterintuitive and unwanted results in some cases, and many entity domains (such as lock.* and climate.*) don’t even support the turn_off service call or an off state.
IMHO the current implementation is preferable - to explicitly define a default/deactivated/standard scene (that the user has full control in configuring), rather than trying to make HA guess what the set of entity states and attributes should be.
4 Likes
It is for that, but I don’t think you’d thought it through.
By the way if you want to create a “reversal” of a scene by going through the same entities and changing their state (eg to ‘off’) then you can duplicate the scene, then go though and set what you want the entities to be. Change the name, done.
scene.activate should store the previous states of the entities
scene.deactivate should restore the previous state
Discussion on what to do about states that were changed by the user, automations etc in the meantime…
You can do that already with scene.create and scene.apply
Interesting, thanks!! I’ll look into that!
I still agree with OP though, it should be the default behaviour and not require workarounds with automations etc.
The real problem with scenes in it’s current form are 2 major miseries.
1st one is the scene editor. If one compares it against the automation editor you’ll see that reaching for the 3 dots in the top right edge won’t allow you to get a short preview of the YAML. Sad thing beside the fact that the GUI isn’t consistent here.
2nd one is again the scene editor. There’s a sentence saying “Set all entities in each device to the state you want for this scene”. Pardon?
One likely would expect 2 vital things here.
a) a visualisation of the current state of that device so one got the chance to correct it if assuming it was different to what it really is.
b) the ablity to chance that state without the need to leave the scene editor at this point.
c) if a & b isn’t given then the text mentioned should be in BOLD RED … since it’s most vital.
or
d) it’s not a scene editor … it’s more a grab state of selected devices and call this a scene. Sort of a scene recorder if ever.
I kept myself from using scenes so far since chances are given one ends up with a mistake which does produce unwanted results. Or one must validate them by reading the scenes.yaml being the final step.
Like @petro said, I personally use scene.create on the entities {{ state_attr(scene, 'entity_id') }}.
Then apply the scene.
After that it is possible to call the previous scene when needed.
Here is a full exemple blueprint:
This is the automation logic I am using to toggle with a single button (I don’t have a 2 state prompt like window open or close)
if:
- condition: template
value_template: >-
{{(states('scene.film_before') == 'unknown') or (0 <
as_timestamp(states('scene.film_before'),0) -
as_timestamp(states('scene.film_mode'),0)) or (as_timestamp(now()) -
as_timestamp(states('scene.film_mode'),0) > 14400)}}
alias: >-
If film_before activated more recently than film mode or if film mode has
not been activated for more than 4 hours
then:
- service: scene.create
data:
scene_id: film_before
snapshot_entities: "{{ state_attr('scene.film_mode', 'entity_id') }}"
- if:
- condition: template
value_template: "{{(states('scene.film_before') == 'unknown')}}"
alias: If scene before has never been activated before
then:
- service: scene.turn_on
data: {}
target:
entity_id: scene.film_before
- service: scene.turn_on
target:
entity_id: scene.film_mode
metadata: {}
else:
- service: scene.turn_on
data: {}
target:
entity_id: scene.film_before
Might turn this into a blueprint
I made a blueprint.
In this ‘deactivation’ means - return to the pre-scene state, not ‘turn everything off’.
To toggle between scene, and everything in it ‘off’ then there’s this blueprint: