Scenes comprised of scenes

Configuration
1

So, is it safe to assume that with the advent of the scene editor in 0.102 that triggering scenes inside of other scenes is no longer possible?

  • I already had scenes in scenes.yaml
  • I converted my existing (and formally working) scenes to the newer format with ID
  • I can now see and edit scenes in the scene editor

For example, this once worked:

- id: all_evening
  name: All Evening
  entities:
    scene.upstairs_evening: on
    scene.den_evening: on
    scene.living_room_evening: on
    scene.master_bedroom_evening: on
    switch.smart_cord_one: on
    switch.den_porch_light: on
    switch.front_porch_light: on

but now only the devices are affected when the scene is called in automation or my activating it.

2

Ok, so no one?

Anyway, I tried to delete the example above and build it back using the scene editor. The editor allows me to add scenes as entities but the scenes are still not triggered. Interesting thing though is that the scene state for scenes is “scening” instead of on.

- id: all_evening
  name: All Evening
  entities:
    scene.den_evening:
      state: scening
    scene.living_room_evening:
      state: scening
    scene.master_bedroom_evening:
      state: scening
    scene.upstairs_evening:
      state: scening
    switch.den_porch_light:
      state: 'on'
    switch.front_porch_light:
      state: 'on'
    switch.smart_cord_one:
      state: 'on'
3

Confirmed.
Scenes that call other scenes is no longer supported:

1 Like
4

That’s a big shame. Scenes within scenes prevented a whole load of duplicated config. Why wouldn’t you want this?

7 Likes
5

Exactly! My thoughts as well.

1 Like
6

It does seem like I’m going to be re-entering a lot of things without this!

1 Like
7

And a pain modifying all the scenes whan an entity is added or replaced.

8

I found this topic when I googled scene inheritance.

I wanted a dashboard scene button to apply a “base” scene before the one I ultimately clicked on, so here’s a little workaround automation for that.

When user activates a scene in our trigger, activate base then re-activate original:

alias: "Scenes: Heat"
description: ""
trigger:
  - platform: event
    event_type: call_service
    event_data:
      domain: scene
      service: turn_on
      service_data:
        entity_id:
          - scene.heat_desk
          - scene.heat_couch
          - scene.heat_whatever
condition:
  # triggered by user, not an automation (avoid triggering self)
  - condition: template
    value_template: "{{ trigger.event.context.user_id is not none }}"
action:
  - service: scene.turn_on
    metadata: {}
    target:
      entity_id: scene.heat_base
  - service: scene.turn_on
    metadata: {}
    target:
      entity_id: "{{ trigger.event.data.service_data.entity_id }}"
mode: queued
max: 10

Though now it’s going through three scenes, e.g. heat_desk -> heat_base -> heat_desk which is a little nasty.

If you wanted that from an automation (or script) you’d probably just activate heat_base before heat_desk yourself. (Still some unfortunate redundant state changes.) I just liked this because it keeps my dashboard simple and unmodified, and scenes.yaml clean.