Turn a light off after x mins if it was turn on via rule

That is correct. The motion sensor I have is pretty quick to turn off so for me it’s perfect. Wallk in lights go on. Walk out and they go off

Yes that’s possible but it wouldn’t have the extend ‘time’ ability. Meaning, if you open the door and close the door, then within 2 minutes you open it again, as soon as the first automation is done, it will shut off your light.

So you could open the door at 8 am and close it. Then at 8:01:58 you open the door again. No matter what, at 8:02:00, the light will shut off. That’s why the timer method is more favorable. Anyways, this is what it would look like without the timer:

trigger:
… (motion.sensor)
condition:
… (sun, light_level, etc…)
action:
  - service : homeassistant.turn_on
    entity_id: switch.office_lights
  - delay:
      minutes: 2
  - service: homeassistant.turn_off
    entity_id: switch.office_lights

Also, @ptdalen @psyciknz @dedlefou you don’t have to use the script method. You guys can actually use the timer component. Only reason I used a script to handle my business is solely because the timer component didn’t exist when I wrote it back in 2016.

1 Like

Thank you so much Petro !
It’s exactly what I’m looking for :slight_smile: just a 30sec light.on in fact…

I “dissected” your approach with script and I should confess that it’s not too complicate :wink: and more smart & elegant… I’ll need it too !

Tks again

In my case I really want the lights to turn off almost immediately after the motion turns to ‘off’, even 1 minute is too long. Although, once in a while I will say that since my timeout is pretty short, I’ve been meaning to tweak it to be like

wait_template: "{{ is_state('binary_sensor.centralite_3326l_05989ed5_1_1280', 'off') }}" for 10 seconds

but not sure how to do that.

But maybe if I did delay that would work

Just to be clear, if I did a 1 minute delay after motion was detected ie ‘on’, then 30 seconds later it went ‘off’ then 35 seconds later it went on, the timer would start over. Since my motion sensor turns off 30 seconds after motion, the lights would stay on only 30 seconds after motion went to ‘off’. I could change the delay to 45 seconds or so, which would give me 15 seconds of buffer to ‘trigger’ to keep the lights on if I was in the room longer.

so wait template waits until movement is gone. so if you want to add 10 seconds, just add a delay after:

  - wait_template: "{{ is_state('binary_sensor.centralite_3326l_05989ed5_1_1280', 'off') }}"
  - delay:
      seconds: 10

to clarify, the wait template should wait til movement is gone. the situation

above shouldn’t happen because of the wait template.

duh!!, genius. So, if in that 10 seconds, motion is triggered again, the lights would stay on, since the automation would trigger again, right?

I’m not sure. I’ve always thought it doesn’t cancel the previous automation, so after that 10 seconds it should end the automation regardless if it gets triggered again. Thats why I always create a timer.

I’m going to try and will report back. I could definitely create a timer that was 10 seconds longer than the motion sensor timout.

But this is where I get stuck

I come in to a room, motion is triggered, lights turn on
2 minute Timer starts
I stay in room moving around, motion stays on for 3 minutes.
It never goes off and back on, so the timer does not get reset, right?

That’s what I was using the wait template. for me about 90% of the time its perfect, the only times are when I come into room, do something where I’m still enough to not keep the sensor ‘on’ then the lights turn off, and then back on as soon as I move.

you can use the cancel timer event at the begining of the automation. then start it up during the automation. This in essence could ‘keep it on forever’

1 Like

Hmm, Still having trouble with the timer logic

Walk into room, timer is not running
Trigger – Motion
Lights turn on
Timer starts 2 minutes
Motion never goes to off, I’m having a dance party, haha.
Timer ends, lights go off
I take a break from dancing, then get up, lights turn back on, repeat, etc.

Or
I walk into room,
Lights on
Timer starts
Motion stops,
timer still going
Motion Starts
Timer canceled
Timer starts over, lights still on

The second scenario is the most common, but the with the first scenario, the lights would turn off if motion continued throughout the timer right.

With mine, as long as there is motion the lights stay on, then turn off as soon at motion goes to ‘off’, If I could have an ‘off + 10 seconds’ that seems like it would work better, right? Or am I over thinkng it

thats a sticky situation. You could change your automation to just look at the to_state instead of from:off to:on

1 Like

Create a binary sensor around the motion sensor with “delay_off” set to 10 seconds. Will delay the reported “off” by 10 seconds. If the state of the motion goes back to true during that 10 seconds it will not turn off.

Then you automation doesn’t change except for the binary_sensor that is the trigger.

Related example; but with delay_on but delay_off works the same way:

garage_door_stuck:
      friendly_name: Garage Door Stuck
      device_class: garage_door
      value_template: "{{ is_state('binary_sensor.garage_door_detected', 'on') }}"
      delay_on: 
        minutes: 10
3 Likes

You don’t have a timer extend function? In openHAB we know the timer exists and is it null, and in subsequent actions can say reschedule the timer for another 5 mins.

But that’s an edge case somewhat.

I did once try this

  - wait_template: "{{as_timestamp(now()) - as_timestamp(states.binary_sensor.centralite_3326l_0e33c46e_1_1280.last_changed) > 10 }}"  

But I could not get that to work, lights came on, but of never turned off.

So, based on your feedback, This look good?

binary_sensors.yaml (called from my configuration.yaml)
 - platform: template
   sensors:
     motion_delay_kitchen:
       friendly_name: Kitchen Lighting motion delay
       value_template: "{{ is_state('binary_sensor.centralite_3326l_0e33c46e_1_1280', 'on') }}"
       delay_off: 
         seconds: 15

Then automation.yaml

- alias: Motion Lighting in the Kitchen
  trigger:
  - platform: state
    entity_id: binary_sensor.centralite_3326l_0e33c46e_1_1280
    from: 'off'
    to: 'on'
  condition:
  - condition: state
    entity_id: group.kitchen_zwave_lights
    state: 'off'
  - condition: state
    entity_id: sun.sun
    state: 'below_horizon'
  action:
  - service: homeassistant.turn_on
    entity_id: group.kitchen_zwave_lights
  - wait_template: "{{ is_state('binary_sensor.motion_delay_kitchen', 'off') }}"
  - condition: state
    entity_id: group.kitchen_zwave_lights
    state: 'on'
  - service: homeassistant.turn_off
    entity_id: group.kitchen_zwave_lights

Nice trick, thanks everyone for the ideas.

Edit: I did go back and make one change. I’m going to keep the trigger as the motion sensor, but the wait to the new binary sensor. I figure that will be slgihtly faster triggering the lights to on. One less thing to monitor

@petro I have an other need :stuck_out_tongue:

When I open a door I’d like to turn on a light.
When I close the door… Turn the light off.

I’m sorry to disturb you again for simple stuff but with my actual knowledge I need to create 2 " - alias : " automation :frowning:

Creating 2 de-activable items in front panel…

Thanks again

Finaly I got it :wink:

- alias: 'Grenier'
  trigger:
    - platform: state
      entity_id: binary_sensor.nano_grenier_4_3
      to: 'on'
  action:
    - service: switch.turn_on
      entity_id: switch.nano_grenier_4_2
    - wait_template: "{{ is_state('binary_sensor.nano_grenier_4_3', 'off') }}"
    - service: switch.turn_off
      entity_id: switch.nano_grenier_4_2
1 Like

Looks good. I think it’s a matter of style and opinion on keeping the trigger and wait as you have them.

In my opinion I’d base them both off motion_delay_kitchen as that way if something got buggered in a future release you would be more likely to notice the entire automation not working; versus partially. As you have it you could end up with a split-brain situation.

But I also respect your “need for speed”

1 Like

Yep, you got it. That’s the purpose of wait templates. Good use of it!

Thanks again for the help. The binary sensor template idea was great. Worked perfect last night. Tonight, I’ll swap it to use the binary sensor as the trigger too, and see if I can tell any difference in speed. :slight_smile:

1 Like