Automation: Please help me better understand "wait for trigger" and how to implement

Configuration
1

My use case:

  1. Two motion sensors, if either sensor detects motion, the lights to turn on.
  2. When neither sensor detects any motion, after 15 minutes, the lights will turn off.
  3. So long as either sensor detects motion, the lights will remain on and the 15-minute timer will not begin (or reset any time motion is detected).

In my automation (using GUI), I’ve setup the triggers as sensor 1 and 2 detecting motion. That is straight forward.

Under actions, I next added “wait for trigger” and added the two sensors to “stopped detecting motion”.

The last action is to turn of the lights.

I am not clear about the timeout in the wait for trigger action. There is a timeout setting for the action, and individual timeouts for each sensor. There is also a “continue on timeout” toggle.

Based on my use case, how should this be set?

Does the timeout setting mean that the trigger will fire after the timeout period? Setting the timeout in the action seems like it would not work because if either sensor stops seeing motion, the timer will begin. If I want both sensors to stop seeing motion before the timer begins, I presume I need to configure the timeout for each sensor instead of setting it in the action?

Regarding “continue on timeout”, should it be togged on or off?

Thank you.

2

I’m not sure you can wait on two triggers like that. Add both your motion sensors to a binary sensor helper group and treat it as a single device. This way your wait on trigger is much simpler. This is exactly what I do in one of my rooms.

2 Likes
3

You don’t need a wait for trigger for this. It can be done like this:

Turn on automation

trigger:
  - platform: state
    entity_id: binary_sensor.motion_1
    from: 'off'
    to: 'on'
  - platform: state
    entity_id: binary_sensor.motion_2
    from: 'off'
    to: 'on'
condition:
  - condition: state
    entity_id: light.your_light
    state: 'off'
action:
  - service: light.turn_on
    target:
      entity_id: light.your_light

Turn off automation

trigger:
  - platform: template
    value_template: "{{ is_state('binary_sensor.motion_1', 'off') and is_state('binary_sensor.motion_2', 'off') }}"
    for:
      minutes: 15
condition:
  - condition: state
    entity_id: light.your_light
    state: 'on'
action:
  - service: light.turn_off
    target:
      entity_id: light.your_light
1 Like
4

Thank you @Rofo and @tom_l. Both solutions look like they will work.

@tom_l, I have questions regarding the code–

  1. For turn on–why check to see if the light is off? If the light is on already, what’s the harm of sending another “on” command?

  2. For turn off–when checking for the sensor state to be “off”, does this mean that HA will always be polling the state of the sensor? Or, does the HA architecture work by receiving change status and react as needed? I curious about the overhead.

Also, same as #1, why verify that the light is “off”. What is the benefit?

Thank you.

5

To avoid sending a needless command; eliminate doing unnecessary things.

It depends on your light’s integration.

Some integrations receive a device’s status while others must poll the device to acquire its status. In Home Assistant, the integration’s method of receiving status is called its “IOT Class”. Each integration specifies a value for its IOT Class.

For example, the Philips Hue integration’s IOT Class is “Local Push” which means status is ‘pushed’ to from the device to Home Assistant. Other possible values are “Local Poll”, “Cloud Poll”, etc.

Screenshot_20230305-173336~2

1 Like
6

This is particularly useful on devices that write values to local flash storage and therefore have a limited lifespan. For example, I don’t send a new temperature value to my TRV’s if the value already set is the same value. Its possible the TRV would ignore that command, knowing its already at that temperature, but its also possible you’re pointlessly writing values to the device for no reason.

1 Like