Automation of light based on sensor

I have a sensor (via my alarm) and an actor (Shelly light). I would like to make an automation when the sensor is breached, the light should be turned on for 15 minutes. This is not so difficult.

But if the sensor is breached again, lets say after 5 minutes the time should be extended with another 15 minutes (in case 20 min in total).

How can I automate this appropriately ? Do I need to make an extra variable which is set at the moment when breached plus adding 15 minutes and then checking this variable?

The easiest way is to have the trigger for turning the light off set to the alarm going from on to off, with a for clause of 15 mins. So the alarm being off for 15 mins.

Another option is to set a timer, and restart that every breach. But that requires an extra helper.

1 Like

Do you mean create 2 automations? The 1st for turning on the light when PIR is breached and the 2nd for turning it off after e.g. 5 minutes when PIR is cleared?

So, like this:

Turn on:

alias: Turn Light On - Hall 2nd level
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.pir_overloop_2de
    from: null
    to: "on"
conditions:
  - condition: sun
    before: sunrise
    after: sunset
actions:
  - action: light.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: light.hall_2nd_level_light_hall_134
mode: single

Turn off:

alias: Turn Light Off - Hall 2nd Level
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.pir_overloop_2de
    from: "on"
    to: "off"
conditions: []
actions:
  - delay:
      hours: 0
      minutes: 5
      seconds: 0
  - action: light.turn_off
    metadata: {}
    data: {}
    target:
      entity_id: light.hall_2nd_level_light_hall_134
mode: single

However, I have the feeling that it won’t be extended. So, it will be roughly turned off after 5 minutes even if there has been another breach in between… I actually would like to cancel the “Turn off” automation and restart when breached.

Should I set “Change mode” to “Restart”? Is that the proper way to do this? I’m just checking my approach as I will implement it for many PIR’s in my house… thx

This is how you do that:

alias: Turn Light Off - Hall 2nd Level
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.pir_overloop_2de
    from: "on"
    to: "off"
    for:
      minutes: 5
conditions: []
actions:
  - action: light.turn_off
    target:
      entity_id: light.hall_2nd_level_light_hall_134
mode: single

If you’re duplicating for many sensors, you can combine the on/off automations into one:

alias: Manage light - Hall 2nd Level
description: ""
triggers:
  - trigger: state
    entity_id: binary_sensor.pir_overloop_2de
    to: "off"
    for:
      minutes: 5
    id: "off"
  - trigger: state
    entity_id: binary_sensor.pir_overloop_2de
    to: "on"
    id: "on"
conditions:
  - or:
    - and:
      - condition: trigger
        id: "on"
      - condition: state
        entity_id: sun.sun
        state: "below_horizon"
    - condition: trigger
      id: "off"
actions:
  - action: light.turn_{{ trigger.id }}
    target:
      entity_id: light.hall_2nd_level_light_hall_134
mode: single

Should the last line “mode: single” be “mode: restart”? As after for instance 4 minutes the PIR is breached, it should be extended by another (new) 5 minutes. Currently, I’m only seeing the trigger is started once even breaching in the time frame of 5 minutes several times…

The same question I have for the second code, this looks even better as I can combine them into one :partying_face:

No: the automation isn’t waiting. It’s triggered as soon as the sensor has been off for 5 minutes, turns the light off and exits. All done in a fraction of a second.

This is the best way to write automations — avoiding delays, loops, waiting etc.

…but am I correct that this is not exactly what I want although it’s maybe better? As in my example, when the PIR sensor is breached after 4 minutes, your automation turns off the light after 1 minute. While mine is slightly different like the “delay” for 5 minutes and “mode: restart” which extends with 5 minutes every time the sensor is breached…

Yours is the best to write automation your wrote and of course I believe. Is my version not the way to go? Could that unnecessarily slow down my system?

I think my version is exactly what you want. It only triggers after a continuous five minutes of the sensor being off. You’re making incorrect assumptions about how it’s operating, I think.

I have tested it and I agree it does what it needs to do. thx.

To optimize a bit further. Can I merge the 2 trigger states “Breach” and “Alarm” in the following code:

alias: Light - Dinner Room
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.pir_eetkamer
    to: Normal
    for:
      hours: 0
      minutes: 15
      seconds: 0
    id: "off"
  - trigger: state
    entity_id:
      - sensor.pir_eetkamer
    to: Breach
    id: "on"
  - trigger: state
    entity_id:
      - sensor.pir_eetkamer
    to: Alarm
    id: "on"
conditions:
  - or:
      - and:
          - condition: trigger
            id: "on"
          - condition: state
            entity_id: sun.sun
            state: below_horizon
      - condition: trigger
        id: "off"
actions:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - "on"
        sequence:
          - action: light.turn_on
            metadata: {}
            data: {}
            target:
              entity_id: light.dining_room_light_diner_table_182
      - conditions:
          - condition: trigger
            id:
              - "off"
        sequence:
          - action: light.turn_off
            metadata: {}
            data: {}
            target:
              entity_id: light.dining_room_light_diner_table_182
mode: single

Yes, I was thinking that, too. But, also, after turning on this timer, cancel the previous one.

True, with a timer there may be situations where you want to cancel it. But a for clause on the alarm turning off makes more sense in the first place, and there’s no need to cancel anything either.

Yes, like the second example in the state trigger docs:

  - trigger: state
    entity_id:
      - sensor.pir_eetkamer
    to:
      - Breach
      - Alarm
    id: "on"

Merging the two states in Yaml is possible and is working. Only the graphical interface doesn’t support it:

I would like to extend the functionality a bit.

Within the timeframe when the light is on, it could be that someone is manually switching off the light. However, this switch is in the same area and the automation is triggered automatically again as there is a movement within the reach of the PIR/sensor area.

How can I ignore any breach within - let’s say 10 seconds after switching off the light - to avoid this automation is switching on the light again?