Worked a charm, thank you!
Those services do work as you described based on what I read. Using those service calls with templates should make it easy to capture the current state of lights to be applied later.
https://www.home-assistant.io/integrations/scene/#creating-scenes-on-the-fly
What I’m failing to understand is the purported benefit of the new services. In the example showing how to ‘create a scene on the fly’, the automation lists all the entities and their desired states. In other words, the scene is defined within the automation’s action.
What is the advantage of that over defining the scene the traditional way? Then just calling it in the automation?
Let’s say you have an automation that turns the lights off in your living room when playing media. You could capture the state before turning the lights off and restore it when you stop playing media. I think that’s one potential use case at least.
How would you capture the current state? The documentation’s example doesn’t show how that can be done, it explicitly defines the entity’s state.
action:
service: scene.create
data:
scene_id: my_scene
entities:
light.tv_back_light:
state: on
brightness: 100
light.ceiling: off
media_player.sony_bravia_tv:
state: on
source: HDMI 1
Pardon my thick skull but I don’t see how it can capture current states unless templates can be used sort of like this:
action:
service: scene.create
data_template:
scene_id: my_scene
entities:
light.tv_back_light:
state: "{{ states('light.tv_back_light')}}"
brightness: "{{ state_attr('light.tv_back_light', 'brightness')}}"
light.ceiling: "{{ states('light.ceiling')}}"
media_player.sony_bravia_tv:
state: "{{ states('media_player.sony_bravia_tv')}}"
source: "{{ state_attr('media_player.sony_bravia_tv', 'source')}}"
Now scene.my_scene contains the current states of the two lights and media_player. If I now change the states of the lights or media_player, I can use scene.my_scene afterwards to restore them to their previous states.
However, this assume templates can be used and I’m uncertain if that’s true.
EDIT
Correction. Replaced data with data_template.
With data_template I’d imagine that would be possible (that’s what I ultimately meant). But I also don’t know for sure.
I’m pleased to report that it works. With some pre-planning, it’s possible to store entity states as a new (temporary) scene and then restore it afterwards (but before the next restart because temporary scenes don’t survive a restart).
Here’s the test. I’m using an input_boolean to trigger the automations just for convenience’s sake.
- alias: test1
trigger:
platform: state
entity_id: input_boolean.toggler
to: 'on'
action:
service: scene.create
data_template:
scene_id: test1
entities:
light.family:
state: "{{ states('light.family')}}"
brightness: "{{ state_attr('light.family', 'brightness')}}"
light.kitchen:
state: "{{ states('light.kitchen')}}"
brightness: "{{ state_attr('light.kitchen', 'brightness')}}"
- alias: test2
trigger:
platform: state
entity_id: input_boolean.toggler
to: 'off'
action:
service: scene.turn_on
entity_id: scene.test1
Initial conditions:
- Family room light is at 25%.
- Kitchen light is off.
Test procedure:
- Turn on the input_boolean and the automation stores the current states of the two lights in a temporary scene (called
scene.test1). - Manually turn off the family room light and turn on the kitchen light.
- Turn off the input_boolean and the automation turns on
scene.test1. The two lights are restored to their previous states (family room light is back on at 25% and the kitchen light is off).
This is a very useful feature and it seems like it hasn’t received the attention it deserves. The need to ‘set-restore’ states comes up often and this does the trick.
5 Likes
Awesome, glad to hear it. I hadn’t gotten around to testing it out, so I’m glad to see it works. It got some pretty positive reactions during the State of the Union stream, so there’s that at least.
Only issue I found is with your input_boolean. Entity ID should be input_boolean.flippy_boi
Well I do have one called flipper …
Excellent. 
Wasn’t this one is the things they talked about in the state of the union in November?
Yeah it was
I thought so. It certainly seems very useful. Do you know if you can ‘overwrite’ a scene? I can see it being very useful to create a scene based on current conditions and then reverting to that state later on, but if I do it more than once, then that scene will already exist.
Create another scene with the lights off…then activate that scene.
Not the same. I don’t just want to turn the lights on and off I want to capture the state of an area, like lights on/off, their brightness, media volume, etc. to be able to set it back to that state later.
Eg. One automation captures the state and sets everything to something else. Then a separate automation sets everything back the way it was when it was captured using that scene. The next time that first automation runs, I would want that scene to be overwritten. Maybe I can delete it after it’s applied back?
Referring to the example I posted above, the first automation’s action stores the current state of the two lights to scene.test1. That’s a snapshot in time. Running the automation again will overwrite scene.test1. Is this what you want, or something else?
Yeah, that’s exactly what I want. Perfect!
But what’s the issue? After creating the scene the same automation cannot change the state of entities inside the scene.
- alias: Kettle_work
initial_state: true
description: 'Switching off Boiler&Microwave plugs'
trigger:
- platform: numeric_state
entity_id: sensor.0x00xx7f_power
above: '500'
action:
- service: scene.create
data_template:
scene_id: KeBefore
entities:
switch.0x00xx85_switch:
state: "{{ states('switch.0x00xx85_switch') }}"
switch.0x00xxa2_switch:
state: "{{ states('switch.0x00xxa2_switch') }}"
- service: switch.turn_off
entity_id:
- switch.0x00xxa2_switch
- switch.0x00xx85_switch
Without creating the scene everything turns off. Including scene.create fragment makes it not to turn the switches off
To dig up an old thread…
Lets say you want to turn some of your rgb lights red as a notification for example, it’s easy to create a scene for that. I love the “just set all devices the way you want and save the scene” feature.
I wonder if you could capture the previous state of those devices on scene activation, so to implement “turn off scene” by restoring those stored states.
In case someone manually changed something while the scene is active, one would simply remove that particular device’s state from the stored list.
If another scene turned on, you would then restore the states of those devices that are not part of the newly activated scene…?
Would this logic work?
This is a mistake on a fast moving platform such as homeassistant. A year old thread is really out of date and commenting on it brings it back to the recent threads list implying it may still be a problem.
In fact, everything you suggest as a solution to this has long since been included in homeassistant by default (including doing so dynamically), see the scene.create service in the scene documentation.