Adding delay to turn light off after it's turned on

Hello,
I am pretty new and just getting my system set up. I have a door switch that I was able to trigger a wifi light switch to turn on when the door opens. However, I can’t figure how to turn the light off after, except for immediately. I’d like the light to turn off 5 minutes after it turns on. I started the animation using the UI, then started working on it in the file editor. Below is what I have so far, the light will turn on and off immediately, without a delay.

  alias: Turn on Breezway Lights
  description: Turn on laundry breezeway lights when I open laundry or front doors
  trigger:
  - entity_id: binary_sensor.wyzesense_77832ed5
    from: 'off'
    platform: state
    to: 'on'
  condition:
  - after: sunset
    before: sunrise
    condition: sun
  action:
  - data: {}
    entity_id: switch.laundry_entry_switch
    service: homeassistant.turn_on
    delay:
      seconds: 10
  - data: {}
    service: homeassistant.turn_off
    entity_id: switch.laundry_entry_switch

There is a cookbook example for this:

I have looked at that a bunch and also tried copy/pasting and replacing the values. Nothing is adding the delay - is it an issue with the automations not reloading or something after I save?

The delay is here:

  trigger:
    platform: state
    entity_id: sensor.motion_sensor
    to: 'off'
    for:
      minutes: 10 

In your case, after the door has been open for x minutes, switch off the light.

Try this

- alias: Turn on Breezway Lights
  description: 'Turn on laundry breezeway lights when I open laundry or front doors'
  trigger:
  - entity_id: binary_sensor.wyzesense_77832ed5
    platform: state
    to: 'on'
  condition:
  - condition: state
    entity_id: sun.sun
    state: below_horizon
  action:
  - entity_id: switch.laundry_entry_switch
    service: homeassistant.turn_on
  - delay: 00:05:00
  - entity_id: switch.laundry_entry_switch
    service: homeassistant.turn_off
3 Likes

You will need to reload automations after changing the YAML, yes. Configuration cog » Server Controls » Reload Automations.

Thank you!!! I used this and it works now! Really appreciate you taking the time to help me out :slight_smile:

Thank you @Troon - I wasn’t doing this and bet it was the issue. I saw it on another thread but there wasn’t instruction on how too, and I guess I just overlooked it.

You were missing a hyphen before delay: in your initial automation.
The delay is a separate action, it’s not part of the first action that turns on the light.

1 Like

Ah, makes sense now that I see and you said that. Thank you.

@santapaula11 dont use the delay use the for:

the reason is the delay will delay it so if movement then the delay start and say 5 min later a other delay start so on and so on

where if we think of it as off for 5 min then turn off mean each time the sensor get trigger the timer restarts

I have motion sensor in my office send a on then a off within 2 sec later

my work again was have a input_boolean

#=======================================
input_boolean:
#=======================================
  someone_in_room_1:
    name: "Someone in Office"
    initial: off
  someone_in_room_2:
    name: "Someone at Mame Machine"
    initial: off

and then each time the motion went off

  - id: 'motion gone off'
    alias: 'motion gone off'
    initial_state: true
    trigger:
    - platform: state
      entity_id: binary_sensor.office_motion
      to: 'on'
    action:
    - data:
        entity_id: input_boolean.someone_in_room_1
      service:  input_boolean.turn_on
    - delay: 00:00:01  # <= only did this so HA see the change and resets the timer
    - data:
        entity_id: input_boolean.someone_in_room_1
      service: input_boolean.turn_off

and then using the

for:

did this

  - id: 'motion on for x min'
    alias: 'motion on for x min'
    initial_state: false
    trigger:
      - platform: state
        entity_id: input_boolean.someone_in_room_1
        to: 'off'
        for:
          minutes: 5
    condition: []
    action:
      - data:
          entity_id: light.office
        service: light.turn_off

the way it works is
each time the input_boolean.someone_in_room_1 get turn on then off
and it must be off for 5 minutes before the light get turn off

only problem I can set still for longer than 5 minutes now

image

hope this get you thinking

1 Like

Myle I agree he should use the ‘for’ but for different reasons.
The ‘for’ is pretty bullet proof and as you say, always delivers after the specified time.
The issue with the delay (contained in the automation like this) is that : -

  1. You open the door, the light turns on (okay)
  2. With the door left open, the light turns off after 5 mins (okay)
  3. You close the door before 5 mins, the light stays on to complete the 5 mins (okay)
  4. BUT : -
  5. If you close the door after 1 min, realise you left your phone on the shelf and go back in, the light turns ‘off’ immediately (not okay) This is because the automation is still running and you triggering it again, by-passes any delays in the second activation.

Having said all this I still use delays, but I put them in a script. The script is cancelled on the light turning off AND cancelled (as the first action) on the trigger to turn the light on, and the the light goes on which calls the script.
The reason I do it this way is so that I can ignore the timer.
There’s nothing worse than (say) painting a room and having to climb back down the ladder in the dark to turn the light back on.
So each light has an input_boolean “timer off enable” that must be set to allow the timer to run. I turn off the enable and the light stays on.
I’ve not found a way with ‘for’ to replicate that functionality.

Edit: in subsequent discussions with @carlos.vroque he has pointed out a solution.
Simply turn off the automation that turns the light off.
It’s so simple, it just didn’t occur to me.
Admittedly it’s a bit agricultural and not the sort of thing you’d ask your mother to do if you were away from home, as it needs someone familiar with how HA works and where to find things, but that’s not the point, it WILL work ! :+1:

1 Like

@mutt far point

I started this home automation stuff in 1999 (shit im getting old) these question were ask then and we (us humans) still trying to work out how a computer can (when NOT to) turn a light off or on where us humans do it with out thinking. There is the problem we should be asking what made me turn it on/off then why what made me turn it on/off and why (have i got the right condition(s) in place

eg. When I start my car or drive down the driveway it open the garage door cool as.
but one day came down driveway and park out side door open nice went inside close door.
Went outside using the sidedoor as i going up town so didnt need garage door open bugger computer did its job as i started the car but i didn’t want that to happen so thinking cap how to stop that start car with out opening the garage door
my idea was have a input_boolean (ok_to_open_door) always on but if I open sidedoor and garage door closed turn ok_to_open_door off for 5 mins now I can start the car out side without opening the garage door as long as I do it with in 5 mins of closing the garage door its does not open

and this is what i love about the home automation thing trying to get the computer to do something and then seeing all well trying to see all the differance conditions to make it right

and its the BUT condition that we all have

what do us humans say

more than one way to skin a cat…

1 Like

Isn’t that a Star Trek TNG Episode ?
:rofl:

1 Like

Just thought I’d share my setup here, I have exterior lights that are turned on with a few different methods:

  • Motion: Someone is outside
  • Alarm: When the alarm is disarmed
  • Presence: When the car connects to wifi

All of these methods also start a timer of 5 minutes, and then I have one automation to turn off the lights when the timer is finished.

By using the timer I don’t need to add a delay anywhere on my automations and I also make sure that each new trigger restarts the timer and I don’t get any conflict between automations with different purposes.

1 Like

I absolutely agree, you only use one ‘off’ automation and that is just simply triggered by the light going ‘on’.
:+1:
But that is what ‘everyone here’ is doing, you don’t particularly need a timer to do that (I currently have 957 entities and not one of them is a timer).
Mind you, that’s mainly because timers used to be a bit flakey and at least ‘delays’ were predictable in their failings, I hear that timers improved greatly around 0.9x.xx ish

1 Like

Automations take a lot of time to be just right for everyone, thanks for the pointers.

I’m new around and maybe that’s why I didn’t know about timers being flakey, so far they’re working very well and ended up being more intuitive for me than switchs/delays.

Sorry, did not mean to imply they (timers) were flakey “now” (just in the past). As far as I know they have become fully stable. Besides, I’m not the font of ALL knowledge.
If it works for you, that’s fine.
I had set these up early 2018 and they’ve behaved flawlessly, so I won’t change them unless an upgrade breaks them OR someone shows me a better way.
If you can replicate the functionality I described above, I’d be very interested to see your code.
Cheers
:beers:

Edit: Just considering this thread.
Because I previously looked into timers and had issues* I found another solution, I’m a bit lazy and never went back. I ‘Should’ re-examine that decision (but I’m lazy :smiley: )
I should also explain, in more detail, what I like about delays (especially in scripts).

  1. I create a script which becomes a mini timer
  2. I reload scripts (4 seconds) and I have a new mini timer (ignoring setting up any input numbers, but a quick and dirty test can probably survive with a hard coded number AND if it’s wrong, another 4 secs to adjust it)
  3. I can template input_numbers to change the values from the front end
  4. I can stop the timer - cancel the script
  5. I can short circuit the delay - just call the script again
  6. I can reset the timer - cancel the script and call it again
  7. The only thing I can’t do is pause the timer
  • perceived timer issues
  1. Actual timers (used to at least) require a restart (I hate waiting for z-wave to come back up again)
  2. They ‘used to’ have problems with resetting the timer (pretty sure this was fixed)

I am ready and willing to be converted :smiley: just have your arguments ready

Looking at your setup I don’t see any reason for a change! To me, your scripts look advanced and I’m glad I was able to do the same with a timer because I’m still learning scripts and wouldn’t be able to implement that myself.

Either way I decided to detail what I use, as far as I know timers do require a restart to be created, and that’s quite complicated when you’re setting things up. But the config itself is easy:

timer:
  outdoor:
    duration: '00:05:00'

In my setup when I open the door, it’ll turn the light on and start the timer with this service call:

service: timer.start
entity_id: timer.outdoor

If the timer is idle, it’ll start the 5 minutes countdown, if it was already running then it’ll restart from beginning. So the automation can be triggered as many times as possible and it won’t end up turning off because of a previous run.

And then I have this trigger to turn off:

platform: event
event_type: timer.finished
event_data:
  entity_id: timer.outdoor

In short it works better than a simple delay inside the automation, but I don’t see any reason to consider changing your script for a timer.

5 Likes

Sorry, I must not have explained properly.
Say you have a room with a 10 minute timer (you’ve templated it so can extend it to 60 minutes (the limit of the input number you set)) but you have a contractor in there painting (or doing it yourself) how do you disable the timer to allow you to just keep painting ?