WTH does the delay feature in automations have to reset if HA restarts?

Month of "What the heck?!"
#5

You could do this:

alias: Robotics club
description: ""
trigger:
  - platform: time
    at: '15:00:00'
condition:
  - condition: state
    entity_id: calendar.robotics
    state: 'on'
action:
  - service: input_boolean.turn_on
    target:
      entity_id: input_boolean.robotics_reminder
mode: single

Alternatively, you could ditch the condition and replace the trigger with a calendar trigger:

trigger:
  - platform: calendar
    event: start
    entity_id: calendar.robotics
    offset: +15:00:00

The second option feels weird though, but that might just be because I’ve never used a calendar trigger before.

#6

Here’s an example of a similar automation from my config that might be a good reference.

In short, when either the washer or dryer is done (first trigger), it sends a notification and also turns the respective reminder boolean on. When either reminder boolean is on for 30 minutes (second trigger), it sends a reminder notification and turns off the respective reminder boolean. The reminder booleans can also be turned off when the laundry room is entered (determined by the contact sensor on the door or the motion sensor in the laundry room).

Unfortunately, I don’t think this would survive a restart, so it’s not a solution to the problem. It might be a good reference for other ideas though at least.

#7

I actually tried your solution before coming up with what I have… my reasoning:

  • Full-day calendar events were only considered “on” at midnight
  • I couldn’t get the offset function to work for calendar triggers, but I could get it to trigger at the event time (midnight)
#8

Ah, that is unfortunate…I guess I figured all-day events would be on, well, all day :grinning_face_with_smiling_eyes:

In that case, you could turn a boolean on when the calendar entity goes to on and then use my automation with the boolean instead of the calendar. You would then just need to turn the boolean off with something else.

2 Likes
#9

Brilliant! I’m using booleans all over the place for similar reasons. Don’t know why I didn’t think of that!

#10

You can do this with timer helpers. For example on the robotics reminder automation:

  • Create a timer.robotics_reminder_delay helper set for 15 hours, and check the restore box.
  • Add a 2nd trigger to the automation for when the timer expires, and add a trigger ID called “timer_expired”
  • Add a trigger ID to the existing calendar event trigger called “calendar_event”
  • For the actions, if the trigger ID was the calendar_event then start the timer.
  • if the trigger ID was the timer_expired then fire the reminder
2 Likes
#11

Nice! Just noticed that, as of 6 months ago, timers can survive HA restarts by setting restore to True.

2 Likes
#12

So a better WTH would be why doesn’t a delay (or any “wait_x” function in general) have the same “restore” functionality as a timer?

2 Likes
#13

I believe it’s because a timer is an entity, that only gained the ability to be restored this year, whereas delay, wait_template, etc are scripting statements within an automation entity and automations that are in-progress are not resumed after a restart/reload.

Restoring a timer simply involves computing the remaining duration. In contrast, restoring an automation would require keeping track of which statement was being executed when the automation was stopped. Then it must determine what remains for that statement to do. For example, if it’s a repeat - count how many more iterations remain. If it’s a delay then how much longer to wait. It gets more complicated for other statements that are monitoring other entities (wait_template) because, after a reload/restart, those other entities may have already changed state.

The situation would be mitigated by the introduction of incremental reloading. Only a new/modified automation would be reloaded and all other in-progress automations would remain undisturbed. Only a full reload, or a restart, would stop all in-progress automations and reload them. There’s an existing Feature Request for this and at least one other WTH.

#14

yeah, I guess adding “wait_x” was incorrect tho I think there might be some way to increase reliability of some of those, too.

However, it is still valid for delays and “for:”.

I even offered a possible solution in one thread a while back (not that I can find it now). It was basically set a datetime instance for the delay, etc in the background (I foresee it being similar to how “for:” works but it will be retained thru restarts) and then use that datetime as a trigger to resume the automation. Of course the automation step would have to be retained thru restarts as well so it would know which automations to auto restart and to know where it left off.

Then you could use that same retained step data to allow for a “wait_x” step to complete the remainder of it’s automation.

it may not be easy but at least it’s starting the discussion (again) on a possible solution to this long running issue.

#15

Currently, a reload doesn’t concern itself with any aspect of an in-progress automation. It effectively “wipes the slate clean” and starts over from scratch.

Only when it’s capable of handling in-progress automations differently, such as with incremental reloading, will it be able to preserve for, delay, etc.

#16

Right.

That’s what I’m suggesting changing.

I’m not even sure it would have to rely on incremental reloading either.

we already have automation traces so there is already some means to keep track of where the automation currently is in it’s step. Just save that data to a non-volatile location in .storage (it might already be since we can look at traces after restarts) and then use that data after automation reloads etc to start the automation back up at the last recorded step was at reload.

Then once the automation completes flush the automation in-progress data (including any datetime instance data for delays etc) for that automation until the automation is triggered next.

#17

The timer solution posted by @mekaneck works really well. I used to use a delay to make lights turn off at a random time. I switched to the timer solution and now my lights don’t stay on if HA is restarted in the delay window. So the automation contains

trigger:
  - platform: time
    at: "22:30:00"
    id: time-off
  - platform: event
    event_type: timer.finished
    event_data:
      entity_id: timer.light_timer
    id: timer-finished
  .
  .
  .
action:
  - choose:
      - conditions:
          - condition: trigger
      - conditions:
          - condition: trigger
            id: time-off
        sequence:
          - service: timer.start
            data:
              duration: "{{ range(60, 1800) | random }}"
            target:
              entity_id: timer.light_timer
      - conditions:
          - condition: trigger
            id: timer-finished
        sequence:
          - service: light.turn_off
            data: {}
            target:
              entity_id: light.bedroom
  .
  .
  .
1 Like
#18

I may be wrong but I believe the reason we can see traces after a restart/reload is because they are created for completed automations. I don’t recall seeing partial traces for interrupted automations.

Nevertheless, even if partial traces are available, to help resume interrupted automations, it may work for resuming delay and for (although I don’t think their remaining duration is currently recorded in a trace but could be added) it still presents a “logic problem” for statements that monitor other entities. A restart (not a reload) is likely to change entity states (so a wait_template or wait_for_trigger will miss that state-change because automations are loaded after entities).

Having said that, I think your idea of using the trace, for resuming the interrupted automation, stands a far better chance of implementation than inventing incremental reloading.

2 Likes
#19

Is a negative chance worse than a zero chance? :laughing:

That’s how much traction my last attempt at a similar suggestion to fix this got.

#20

I think the challenge is to convince the development team (or a volunteer developer) that the current behavior is a significant weakness in the product.

All it takes to abort an in-progress automation is a single Reload Automations … which happens automatically, and invisibly, the instant a user saves an automation with the Automation Editor. Effectively, the “Save” button is a “Save … and kill all running automations”.

1 Like
#21

Yea I’m skeptical this will happen as well for similar reasons. I personally think it’s more likely we’ll get a feature where pressing save only reloads the automation you saved, not all. Since HA already knows how to do targeted reloads from YAML, it just needs a more precise targeting option.

And that would probably massively reduce the need for this feature since it would likely be limited to only occurring on restart. And of course saving an automation would stop any running instances of that automation but I don’t think people would be as surprised by that.

Although I do think that if this FR is not taken up the UI should probably show a warning if for or wait options exceed a threshold. The current behavior is definitely an unpleasant surprise for many folks judging by all the posts on the forum.

#22

I didn’t suggest a UI change but I did actually try to make a documentation change a while back with a warning that the timer implementation was unreliable for long (>5 minute?) time values. If that one was accepted I was going to do the same for the rest of the time components.

It languished for a long time then was auto closed.

The concern was that it gave the impression that people shouldn’t use timers/delays/etc for long wait times and that they were unreliable. Well, yeah. They are unreliable. Which was the point.

I doubt a UI warning would fare much better for the same reason.

#23

Yea its kind of a pickle. I think the problem is that when seeing a PR/issue like that people would rather fix the underlying issue then spend time adding a warning like that. Which is a great sentiment but its been a very long time at this point and in the meantime many users are getting into bad situations with long delays not realizing the pitfalls.

My personal feeling is that one of the following 3 should happen:

  1. Wait steps and for options survive restarts and reloads (this WTH)
  2. Saving one automation does not reload them all (this WTH)
  3. A warning shows up for wait and for configurations that could take over 5 minutes (a stopgap if neither of the above happens)

#2 might ideally be combined with a documentation note that mentions restarts/updates kill running automations. But I think if that change was made its no longer egregious enough to require an in-your-face UI warning.

1 Like
#24

I wish that was the case but unfortunately that sentiment wasn’t conveyed in the PR discussion.

It only centered around the thought that we didn’t want to give users the idea that they shouldn’t use them because they were unreliable.

I was asked to tone down the warning to make it less…“warning-y” I guess. :man_shrugging:

But I couldn’t figure out how to do that and keep the actual concern conveyed by the warning intact. I actually asked for a suggestion to give me an idea what would be acceptable and that’s when things got ignored.

As much as it’s been brought up in the forums (by many of us in this thread many times) I can’t see how the devs don’t understand how much of a problem this tends to be.