Scene.deactivate initially sounds useful, but it really isn’t.
A scene may, say, set your lights to 20% dim and play some soft romantic music. What is the definition of deactivate in that case? Turn the lights to 0%, 100%, 21%, a random level?. Play some AC/DC? At a simpler level, what is the opposite of a given ‘state’?
AC/DC would be cool 
Jokes aside, how do you let you scene play a sound? There is no such sensor with state as sound or is it?
You can set the state and attributes of your media_player.
Since we’re playing WTH… WTH isn’t it useful? You can’t say it isn’t useful. It may not be useful to you. It is useful to me.
I use a scene when I sit down in the family room. When I go to bed I’d like to turn off all the lights in the family room. I’m not thinking this new feature is going to solve everyone’s problem but it simplifies not having to group the same three lights together so that I turn them off.
Seriously this is not a big deal for me. I’m WTHing something that simplifies my config.
You can simply make a second scene for switching everything off. Or would you just like to restore everything to the state they was before you activated your scene first?
Yes I could define a second scene. As a developer I can’t easily vacate the DRY principle, which is the real reason for this WTH. Every time I have to define the same list of entities more than once I cringe a little. Which is why I’d be happy with simply being able to get the list of entities that a scene uses.
Like looking at the yaml?
Pretty sure he means from the scene entity
Wow. I thought WTH was to explore in curiosity what is possible. Since that doesn’t seem to be the spirit, I’m out.
I think you pressed a button with that whole scene thing. For me this is one of the most useless default features in HA for several reasons:
So the usage is so limited, I really have no valid use-case next to “scene tv on/off” with power plugs and basic lights being turned on and off. But maybe it’s just me not understanding the true power of scenes 
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.
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: