I need some help on a basic light switch automation based on a radar trigger witch should light for 30s then stop. After a motion detection, the trigger will rise for a few second and then fall. If motion still occurs, it will raise again. The problem is that the new raise turn the light off before the 30s delay.
Here is the code:
- id: '1578238530262'
alias: Front door light
description: ''
trigger:
- entity_id: binary_sensor.node_frontdoor_4_5
from: 'off'
platform: state
to: 'on'
condition: []
action:
- entity_id: switch.node_frontdoor_4_2
service: switch.turn_on
- delay: '30'
- entity_id: switch.node_frontdoor_4_2
service: switch.turn_off
The problem is in the way delays and automations being repeatedly triggered currently behave - basically the delay is bypassed
Youâre also setting it up for a fixed interval, you get 30 seconds of light when motion is detected, even if thereâs still motion
JMGAujourdâhui Ă 11:55
indeed, it works now. for your second point, I was aware of this limitation (and understand it). The new way is effectively better on this pint.
for the first point, I understand that the delay could mess things up. But I still do not understand why a change state from on to off could stop the light (off)
TinkererAujourdâhui Ă 11:58
Its a âfeatureâ of the way that itâs currently handled - 0.106 will change things so that youâve got control
Yes, for now. Iâm working on fixing that behavior. Hopefully before too long youâll be able to specify what the automation should do if it re-triggers while a previous run of the action sequence is still on-going. The choices will be to ignore the trigger, raise an error, restart the action sequence, or run the action sequence again in parallel with the previous run(s.)
However, I still not understand how this improvement will solve the issue of sending a âswitch.turn_offâ after an off to on change state. If the delay is cancelled, it should resend a âswitch.turn_onâ. It seems that the âswitch.turn_xxâ acts like a toggle switch.
Maybe âcanceledâ was the wrong choice of words. Currently if you retrigger an automation waiting in a delay the delay âcompletesâ instantly and execution of actions after the delay continues.
With Philâs proposed improvements, for the way your automation was written, you could choose to restart the actions on the second and subsequent triggers, until the delay completes. Then it would work as you expected it to.