Light switch automation with trigger

Configuration
1

Hello.

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

switch automation
switch automation502×562 9.85 KB

2

Re-triggering an automation while waiting in a delay causes the delay to be cancelled. Do it with two automations like this instead:

3

Thanks. It works know.

I copy-paste a chat on the same topic with some additional information for those like me who want to better understant the behaviour.

TinkererAujourd’hui à 10:41

See https://www.home-assistant.io/cookbook/turn_on_light_for_10_minutes_when_motion_detected/ @JMG

JMGAujourd’hui à 11:39

thanks a lot. I will try it. But still, I do not understand the behaviour when using my way… (Light switch automation with trigger)

TinkererAujourd’hui à 11:41

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

JMGAujourd’hui à 12:00

ok. Thanks a lot for your help!

4

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.)

1 Like
5

Great!

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.

6

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.

7

Ah ok! It is 100% clear now. Thanks a lot for explanation.