Multiple 'wait_for_trigger's on same entity in automation won't execute

Configuration
1

My automation turns a light on when motion is detected, dimms it to 65% percent when motion stop and I want it to turn off 3 minutes later if no motion is detected.

I like wait_for_triggers to help me to do this, but the second trigger (with the ‘for’ argument) does never execute. Is it possible that I can’t bind a trigger with a ‘for’ argument when the device already has that state?


- alias: Outside motion
  trigger:
    platform: state
    entity_id: binary_sensor.motion_sensor_outside
    to: 'on'
  action:
    - service: light.turn_on
      entity_id: light.floodlight
      data:
        brightness: 255
    - wait_for_trigger:
      - platform: state
        entity_id: binary_sensor.motion_sensor_outside
        to: 'off'
      timeout: '00:10:00'
      continue_on_timeout: false
    - service: light.turn_on
      entity_id: light.floodlight
      data:
        brightness: 160
    - wait_for_trigger:
      - platform: state
        entity_id: binary_sensor.motion_sensor_outside
        to: 'off'
        for: '00:03:00'
      timeout: '00:10:00'
      continue_on_timeout: false
    - service: light.turn_off
      entity_id: light.floodlight
2

When you have continue_on_timeout set to false, the actions stop after the timeout period. Anything lower in the action list will not be completed.

3

I’m aware of that, but the first wait_for_trigger actually completes and the brightness of the light gets set to 160.
The wait_for_trigger statement after that never works, even when there hasn’t been any motion since.

4

I’d use multiple triggers:

- alias: Outside motion
  trigger:
    - platform: state
      id: 'on'
      entity_id: binary_sensor.motion_sensor_outside
      to: 'on'
    - platform: state
      id: 'off'
      entity_id: binary_sensor.motion_sensor_outside
      to: 'off'
    - platform: state
      id: 'off for 3min'
      entity_id: binary_sensor.motion_sensor_outside
      to: 'off'
      for: '00:03:00'
  condition: []
  action:
    - choose:
        - conditions:
            - condition: trigger
              id: 'on'
          sequence:
            - service: light.turn_on
              entity_id: light.floodlight
              data:
                brightness: 255
        - conditions:
            - condition: trigger
              id: 'off'
          sequence:
            - service: light.turn_on
              entity_id: light.floodlight
              data:
                brightness: 160
        - conditions:
            - condition: trigger
              id: 'off for 3min'
          sequence:
            - service: light.turn_off
              entity_id: light.floodlight
      default: []
5

The first wait_for_trigger triggers when the binary_sensor changes some from another state (normally on but it could be unavailable) to off. It’s this state-change that causes the State Trigger to trigger.

The second wait_for_trigger also waits for a state-change to occur (from some other state to off). Except there won’t be one because the binary_sensor, having passed the first wait_for_template, is already off. It must change state to off which means it has to be on first but that’s not the scenario you had in mind when you created it.

Try this version:

- alias: Outside motion
  trigger:
    - id: 'on'
      platform: state
      entity_id: binary_sensor.motion_sensor_outside
      to: 'on'
    - id: 'off'
      platform: state
      entity_id: binary_sensor.motion_sensor_outside
      to: 'off'
    - id: 'off_3'
      platform: state
      entity_id: binary_sensor.motion_sensor_outside
      to: 'off'
      for: '00:03:00'
  action:
    - choose:
        - conditions: "{{ trigger.id in ['on', 'off'] }}"
          sequence:
            - service: light.turn_on
              target:
                entity_id: light.floodlight
              data:
                brightness: "{{ 255 if trigger.id == 'on' else 160 }}"
      default:
        - service: light.turn_off
          entity_id: light.floodlight
1 Like
6

Wow, that is a very clever use of those trigger id’s, a whole new way to look at sequential automations for me!

7

That makes sense, it seems that those triggers work a little bit different behind the scenes than I expected, but that explains why my automation doesn’t work.

I really like the multiple trigger version with the trigger ids, a new way to look at automation steps.

8 
alias: Badkamer_vochtigheid te hoog
description: ""
trigger:
  - platform: state
    to: "off"
    entity_id: binary_sensor.badkamer_bewegingsmelder_occupancy
    for:
      hours: 0
      minutes: 5
      seconds: 0
condition:
  - condition: numeric_state
    entity_id: sensor.badkamer_vochtigheid
    above: 76
action:
  - service: cover.open_cover
    data: {}
    target:
      entity_id: cover.3
  - wait_for_trigger:
      - platform: numeric_state
        entity_id: sensor.badkamer_vochtigheid
        below: 73
      - platform: state
        to: "on"
        entity_id:
          - binary_sensor.badkamer_bewegingsmelder_occupancy
        for:
          hours: 0
          minutes: 2
          seconds: 0
  - service: cover.close_cover
    data: {}
    target:
      entity_id: cover.3
mode: single

The wait for triggers… is this in my case “and”, or “or”

i want the screen closed if the humid is below a value, or the presence detection detects some one…

9

Triggers are always “or”, it doesn’t matter if they are in a Wait for trigger action or in the Trigger block.

FWIW, you may find that putting an automation into an indefinite wait yields behavior that can seem random or unreliable since waits do not survive restart or reloading the automation.

1 Like