Why are motion automatons so difficult?

I have this automation to turn on my govee lights when any of my 4 motion sensor change to any state. It was working for a week then today it just stopped working. I confirmed the motion entities changed state but the automation did not fire. Nothing shows in the log. Here is the script for reference:

alias: Govee Motion Control
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.irg_front_1
      - binary_sensor.irg_front_2
      - binary_sensor.irg_front_3
      - binary_sensor.irg_front_4
actions:
  - data:
      name: Govee Motion Control
      message: >-
        Triggered by {{ trigger.entity_id }} changing to {{
        trigger.to_state.state }}
    action: logbook.log
  - target:
      entity_id: light.permanent_outdoor_lights
    action: light.turn_on
    data: {}
  - wait_for_trigger:
      - entity_id:
          - binary_sensor.irg_front_1
          - binary_sensor.irg_front_2
          - binary_sensor.irg_front_3
          - binary_sensor.irg_front_4
        trigger: state
    timeout: "00:05:00"
    continue_on_timeout: true
  - condition: template
    value_template: "{{ wait.completed == false }}"
  - target:
      entity_id: light.permanent_outdoor_lights
    action: light.turn_off
    data: {}
mode: restart

You’re using the same entities for the triggers and the Wait triggers while using restart mode… that won’t work. The Wait will never complete due to being triggered, because the automation will restart.

Then there’s the conundrum of using continue_on_timeout followed immediately by {{ wait.completed == false }}… so the continue_on_timeout will never do anything.

Why are motion automatons so difficult?

… you did make it overly complicated…

Why not simplify it:

alias: Govee Motion Control
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.irg_front_1
      - binary_sensor.irg_front_2
      - binary_sensor.irg_front_3
      - binary_sensor.irg_front_4
    to: on
actions:
  - data:
      name: Govee Motion Control
      message: >-
        Triggered by {{ trigger.entity_id }} changing to {{
        trigger.to_state.state }}
    action: logbook.log
  - target:
      entity_id: light.permanent_outdoor_lights
    action: light.turn_on
    data: {}
  - delay: "00:05:00"
  - target:
      entity_id: light.permanent_outdoor_lights
    action: light.turn_off
    data: {}
mode: restart

or even more, since you don’t need to manually tell HA to create a log entry…

alias: Govee Motion Control
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.irg_front_1
      - binary_sensor.irg_front_2
      - binary_sensor.irg_front_3
      - binary_sensor.irg_front_4
    to: on
actions:
  - target:
      entity_id: light.permanent_outdoor_lights
    action: light.turn_on
    data: {}
  - delay: "00:05:00"
  - target:
      entity_id: light.permanent_outdoor_lights
    action: light.turn_off
    data: {}
mode: restart

Thanks for the replies! I want it to trigger if any of the binary sensors change to any state. I’m guessing I can just remove the on state?

    to: on

Why do you want to turn a light on when the sensor clears? Yes, you can remove the to: on but that defies the point of my code and will not work as well since you’ll end up with a 10 min delay before the lights turn off rather than a 5 min delay. Try it my way and see what I mean, it will work well.

Can you clarify the thought process for this?

Because the motion sensors I have flip flop state. They never clear. When it first sees motion it goes from 0 to 1. It stays that way till the next motion event and it goes from 1 to 0. Maybe I can fix this in the motion software.

Are those flip-flopping sensors the same entities you are using in the automation, or are you using some kind of proxy?

They are the same. They are custom sensors I made using letsconrolit or espeasy. Basically I took a long range Guardline IR and implanted a esp8266 coupled with opto couplers. They connect via mqtt.

Why not fix the sensor config so they have proper ‘motion / no-motion’ states?

1 Like

I think the meat of this thread proves the subject.