Support for persistent waits and delays

Feature Requests
1

Hey there,

I wanted to first issue a deep “thank you” to everyone who works on HA. I truly love it.

There might be a reason this is not possible or is a bad idea, but I figured I would ask.

It would be great if the delay functionality in HA survived a restart, like a timer does.

For example:
“For:”
“Delay:”
“Delay_on”
“Delay_off”

None of these survive a restart AFAIK. I’m wondering if HA could just create an ephemeral timer behind the scenes, that might be the simplest option?

When the automation, template sensor, template binary sensor, or script is loaded that contains one of the directives above, a timer entity could be created and hidden from the UI, so the functionality was the same to the end user but it survives restarts.

Just a thought! Thanks for reading!

Matt

2

My use cases for this FR would need more than just setting a timer. For example, I have an automation for laundry. The idea is to set a bulb to a specific color (purple for dryer/blue for washer in another rule) until the motion sensor in the laundry room picks up movement. Since this isn’t at timed action, it would need to restart whatever backend mechanism watches for the entity state change. Same as you though, I just had the thought that I could add the laundry motion active as a trigger, with a choose block to turn an input_boolean on when the dryer finishes and only reset the light if the motion is triggered while that helper is turned on. Still would be simpler if I didn’t have to do that.

alias: Laundry Automation - Dryer
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.dryer_helper
    from: "on"
    to: "off"
condition: []
action:
  - if:
      - condition: and
        conditions:
          - type: is_no_motion
            condition: device
            device_id: 69d34b5ca76d727dc546dabe01f00705
            entity_id: binary_sensor.laundry_room_motion_sensor_occupancy
            domain: binary_sensor
    then:
      - service: notify.all_mobile_apps
        data:
          message: The dryer is done.
      - if:
          - condition: state
            entity_id: binary_sensor.tv_helper
            state: "off"
        then:
          - service: light.turn_on
            data:
              color_name: purple
            target:
              entity_id: light.bar_overhead_light2
        else:
          - wait_for_trigger:
              - platform: state
                entity_id:
                  - binary_sensor.tv_helper
                to: "off"
            continue_on_timeout: false
          - service: light.turn_on
            data:
              color_name: purple
            target:
              entity_id: light.bar_overhead_light2
      - wait_for_trigger:
          - type: motion
            platform: device
            device_id: 69d34b5ca76d727dc546dabe01f00705
            entity_id: binary_sensor.laundry_room_motion_sensor_occupancy
            domain: binary_sensor
      - service: light.turn_on
        data:
          kelvin: 3000
        target:
          entity_id: light.bar_overhead_light2
      - if:
          - condition: state
            entity_id: light.bar_overhead_light1
            state: "off"
        then:
          - service: light.turn_off
            data: {}
            target:
              entity_id: light.bar_overhead_light2
mode: single
max_exceeded: silent
3

They’re not comparable.

delay is a script statement. All running scripts and automations are terminated by a restart. In order for delay to survive a restart, an automation/script would have to resume from the point it was terminated. It represents a non-trivial re-design of how automations/scripts work (it’s also a breaking change).

A timer is an entity created by the Timer integration. So its behavior is independent of others, unlike a script/automation that is very much dependent on other entities.

for is an option of a State Trigger and so is part of an automation (which gets terminated on restart).

How do you envision a State Trigger’s for would use a timer entity? Triggers don’t execute service calls (like the service calls to start/reset/cancel a timer). If you’re saying they should, then that’s a major change to trigger architecture.

tl;dr
Any attempt to “persist” the things you mentioned, requires a terminated automation to resume from where it left off and that’s a major architectural change. FWIW, I would be surprised if anyone volunteered to make that change (and for the development team to approve it).

1 Like
4

@123 I wanted to thank you for your detailed and thoughtful reply. Your reply is inline with what I might have suspected, given the architecture, but I figured I’d ask anyways. If there’s any clean way for me to close this out, I’m happy to.

Again, it makes sense and thank you for educating me on some of the reasons why it’d be a big change to make - it totally makes sense.

Matt

5

Leave your FR open. You never know, maybe in the future it will become easy to implement.

1 Like