Scene entity only restoring one of two stored entity states

[Vitruvius]

I have set two automations that work in tandem:

• One stores the positions of my screens through the scene integration, then moves them to a preset position.
• The second automation restores the old positions when the first automation is ‘deactivated’.

However, the second automation only restores the position of the first cover (cover.screen_1), I do hear cover.screen_2 move for a split second, but it does not go back to its original position and instead stays on the predefined position from the first automation.

First automation:

- alias: 'Screens: venting active'
  triggers:
  - trigger: state
    entity_id: binary_sensor.screens_venting
    from: 'off'
    to: 'on'
  conditions: []
  actions:
  - action: scene.create
    data:
      scene_id: screen_position
      snapshot_entities:
      - cover.screen_1
      - cover.screen_2
  - action: cover.set_cover_position
    metadata: {}
    data:
      position: 10
    target:
      floor_id: 2nd_floor  # Moves both cover.screen_1 and cover.screen_2
  mode: single

Second automation:

- alias: 'Screens: venting done'
  triggers:
  - trigger: state
    entity_id: binary_sensor.screens_venting
    from: 'on'
    to: 'off'
  conditions: []
  actions:
  - action: scene.turn_on
    target:
      entity_id: scene.screen_position

[Vitruvius]

Update: I ran a few tests, and the forgotten settings seem random. One time it’s screen 2 that gets stuck, but it can be screen 1 just as well. It just seems the scene cannot reliably store the values for both, which looks like a bug to me?

[petro]

It’s likely the covers, not the scene. Start by looking in your logs.

[Vitruvius]

The HA core logs don’t show anything, the automation trace shows this:

Related activity:

[Edwin_D]

That is a very quick succession of opens and closes. Are those the same covers being opened and closed in the same second?

[Vitruvius]

Those are two screens total, yes (the ones listed in the snapshot_entities in the automation). The screen that restores its previous position has smooth movement, I only see a single movement there. One click from the motor as well. So the subsequent open/close in the log does not seem to translate to screen movement.

I’m not sure why HA thinks the screens should open, as the screens’ positions should be restored. In this case, they were fully closed before they were moved to venting position. So they should only be closing, not opening.

The second screen clicks and stalls immediately. A bit less anonimised, where you can see it’s two screens, and only one actually gets closed:

[123 (Taras)]

Assuming it is due to a timing problem, try the following experiment. Create a separate snapshot scene for each cover.

- alias: 'Screens: venting active'
  triggers:
  - trigger: state
    entity_id: binary_sensor.screens_venting
    from: 'off'
    to: 'on'
  conditions: []
  actions:
  - action: scene.create
    data:
      scene_id: screen_1_position
      snapshot_entities:
      - cover.screen_1
  - action: scene.create
    data:
      scene_id: screen_2_position
      snapshot_entities:
      - cover.screen_2
  - action: cover.set_cover_position
    metadata: {}
    data:
      position: 10
    target:
      floor_id: 2nd_floor  # Moves both cover.screen_1 and cover.screen_2
  mode: single

Then execute each snapshot scene separately with a short delay.

- alias: 'Screens: venting done'
  triggers:
  - trigger: state
    entity_id: binary_sensor.screens_venting
    from: 'on'
    to: 'off'
  conditions: []
  actions:
  - action: scene.turn_on
    target:
      entity_id: scene.screen_1_position
  - delay:
      seconds: 2
  - action: scene.turn_on
    target:
      entity_id: scene.screen_2_position 

• If both snapshot scenes are restored correctly, try reducing (or even eliminating) the delay.
• If the second snapshot scene fails to restore correctly, try increasing the delay. If it still fails then the problem is probably not due to timing.

[Vitruvius]

Thanks. I already split it into two separate scenes, without the delay though. Both screens just stay stuck at 10% then. The delay does not seem to make a difference.

(I’ve switched to a boolean so I can use a button switch in the UI, but that shouldn’t make any difference for what’s happening here.)

alias: 'Screens: venting'
triggers:
  - trigger: state
    entity_id: input_boolean.screens_ventilatiestand
    from: 'on'
    to: 'off'
conditions: []
actions:
  - action: scene.turn_on
    target:
      entity_id: scene.screen_position_1
  - delay:
      seconds: 2
  - action: scene.turn_on
    target:
      entity_id: scene.screen_position_2

[petro]

What integration is providing the covers?

[Vitruvius]

The KNX integration. Is there a way to see which data the scenes store?

[Vitruvius]

I have given this some more thought. I first tried to store the shade positions in a variable in the automation, like this:

  - variables:
      cover_position_gxxx: "{{ state_attr('cover.screen_gxxx', 'current_position') | int(0) }}%"
      cover_position_lxxx: "{{ state_attr('cover.screen_lxxx', 'current_position') | int(0) }}%"

That doesn’t seem to work with the second automation, the variables seem scoped. When thinking about how to integrate it all in one automation, I realised we won’t be going back to the original positions most of the time - the shades will either be fully closed or opened - manually. So the automation is gone, and we now have a few buttons to open/close the shades, and to set them to a venting position.

I don’t think the KNX integration is part of the issue here; I have been using floor_id to steer all the shades for a while, and that has worked fine so far. Both shades on that floor react at the same time. So to me, it looks like something goes wrong with the scene bit.

Thanks everyone for the insights.