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?
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.
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 tooff 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
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.
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.