Am I missing something or is this automation just a little too ambitous?

Having a weird problem with a light automation. Everything works fine except there is a condition right at the end of the code for a light to only turn off once a sensor has detected no movement for 5 minutes.

But according to my logs the automation ignores this 5 minute condition and turns the light on but then off immediately afterwards. I hope the comments in the code make sense. Apologies this automation is perhaps a bit too complicated and I may have made a logic error somewhere. Grateful for any pointers!

 id: '1630278597828'
  alias: living room lights
  description: ''
  trigger:
#start the automation when movement is detected in room
  - type: occupied
    platform: device
    device_id: 1069a605af077ab7fe03158f91e57c33
    entity_id: binary_sensor.philips_sml001_a32fb404_occupancy
    domain: binary_sensor
#condition - only if illumination sensor says its dark
  condition:
  - type: is_illuminance
    condition: device
    device_id: 1069a605af077ab7fe03158f91e57c33
    entity_id: sensor.philips_sml001_a32fb404_illuminance
    domain: sensor
    below: 7
#and dont turn on the light if we are watching a movie on plex - so need both plex sensors to be NOT playing
  - condition: not
    conditions:
    - condition: state
      entity_id: media_player.plex_plex_for_xbox_xboxone
      state: playing
    - condition: state
      entity_id: media_player.plex_plex_htpc_for_windows_bigbox
      state: playing

#if conditions met, turn the nightlight on if its after 11pm and before 6am. If its outside those times turn on the living room lamp and another light called "space TV"
  action:
  - if:
    - condition: time
      after: '23:00:00'
      before: 06:30:00
    then:
    - service: light.turn_on
      data: {}
      target:
        entity_id: light.yeelight_ceiling18_0x10d694c7_nightlight
    else:
    - service: light.turn_on
      data: {}
      target:
        entity_id: light.livingroomlamp
    - service: switch.turn_on
      data: {}
      target:
        entity_id: switch.space_tv

#now we want to set conditions for when the lights will be turned off. Wait for the sensor to detect no movement for 5 minutes
  - wait_for_trigger:
    - type: not_occupied
      platform: device
      device_id: 1069a605af077ab7fe03158f91e57c33
      entity_id: 6a285f4d7010e442ed2a67fb799712f5
      domain: binary_sensor
      for:
        hours: 0
        minutes: 5
        seconds: 0
    timeout:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 0

#but the motion sensor is unreliable - if someone is sitting down watching TV they probably arent moving much so the sensor will change its state to no movement after a few minutes - But we dont want the light to go off if someone is still in the room, so this condition checks to see if the TV is turned on (which would indicate someone is still in the room). If it is - then dont turn off the light. Otherwise, turn it off.
  - condition: not
    conditions:
    - condition: state
      entity_id: media_player.denon_avr_x2200w
      state: 'on'
  - service: light.turn_off
    data: {}
    target:
      entity_id:
      - light.yeelight_ceiling18_0x10d694c7_nightlight
      - light.livingroomlamp
  mode: restart

Move the “not occupied” trigger out of the automation’s action and into its trigger section. I recently offered the same advice to another user (who had employed the same wait_for_trigger technique you did) and posted an example here:

Thank you for taking the time to read about my problem. I checked your link.

So essentially your method is to use two totally different triggers in the trigger section, but insert a condition which says - if the light is already off, turn it on. And if the light is already on, turn it off. Is that the gist of it?

That’s the gist of it. The triggers for detecting motion and no motion exist exclusively in the trigger section (a very common design pattern) thereby ensuring the automation spends very little time within its action section.

FWIW, the condition is optional. It simply spares Home Assistant from turning on a light that’s already on (or turning it off if it’s already off).

1 Like

but to answer the original question of why the automation action is acting the way it does…

the problem is using the “timeout:” the way you are.

Since the timeout is 0 the automation will just completely ignore the “wait_for_trigger” and continue on with the actions as if it didn’t exist.

to try to better explain:

in your use case the wait_for_trigger is using two different triggering conditions

  • the no motion sensor being active for 5 minutes

or

  • the timeout

since the timeout is 0 seconds it’s the trigger that happens first in the wait so actions move immediately to the next step ignoring the 5 minute wait.

1 Like

Call me silly, but this is a big part of the reason why I use multiple automations for almost everything. One turns things on, the other turns them off again.

Could almost all of what I’m doing be converted to one automation for each instead of two? Probably, but at what cost? My automations are exceedingly easy to follow, easy to troubleshoot, and even easier to modify.

Just something to think about…

But for the record, I agree that the issue with this is most likely the multiple triggers in the action section.

Just my $.03 (inflation).

Right. This is the crux of my issue as my automation stands. It therefore seems that using this method means I’m unable to use the motion sensor being inactive for 5 minutes, because if I put a timeout of 5 minutes trigger, then the light turns off even if the motion sensor is still active.

I’m working on implementing @123 method which I like the sound of because I want to avoid separate automations for switching stuff on and off. I too originally used @exx approach but I found I just had massive lists of automations. I thought combining automations would keep things neat and tidy. But it’s harder to implement from a logic standpoint.

Massive lists of automations aren’t a problem - you just need to use a naming standard so that things are easy to find.