I’m using the “automation.turn_off” service with “stop_actions: true” to cancel a running automation. The logbook shows it has been disabled. However the action it is executing (waiting for a certain amount of time) is not stopped/interrupted.
It looks like the “stop_actions: true” does not work. At least not to cancel ‘wait time’. Maybe this doesn’t work in this situation? If can do it in another way but just want to be sure I’m not doing anything wrong here. Thanks!
It should according to the docs. Wht else is the stop_actions parameter for?
It does not stop all actions mid operation though. It always understood it should cancel delays, but maybe not a wait for trigger? What way of waiting are you using?
Personally I’d put the actions in a script and turn that off though. Not that I think that would help for this particular problem, but do you also mean to disable the automation triggers for future use? The action does two things, which might not always be what you want. Turning off a script is canceling the actions but the script remains usable.
Turning automations off should be available to you to disable misbehaving automations. Doing so programmatically is advised against.
Another option here is: rather than using delay, set a timer and move the turn_off part of the automation to a separate automation triggered by the timer. Then you can turn off that second automation.
I just highlighted all the advantages of a timer in a different thread, so yeah. But then simply cancel the timer, no need to disable automations. Advantages of timers: You can see them, test for them, manipulate them from other automations (start, restart, cancel,…). And they survive a restart of HA if you tick the box while creating the helper.
Your automation turns on a light, waits for 3.5 hours using a 3.5 hour delay, then turns off the light. This design cannot survive a restart.
If Home Assistant were to restart during the delay, the automation would be immediately terminated and, on startup, would not resume the automation’s actions from where it left off. That means the light that was turned on would not be turned off.
That’s why everyone is suggesting you redesign it to use a timer entity which does survive a restart (but is admittedly more complicated to work with than a simple delay statement).
Be advised that if you do use a 3.5 hour timer and cancel it with the timer.cancel action, you still need to consider what to do about the light that the automation turned on.
EDIT
Post the entire automation. It will help us understand what you’re trying to accomplish. It may be possible that no timer is needed.
One additional consideration: rather than use automation.turn_off, if you’re using a timer, simply cancel the timer to prevent the automation from firing at the timer’s expiration.
I’m not too worried about a HA restart. Like the old HomeWizard that I’ve been using (and still use with rest integration to control my heatlink) for 10+ years now, HA on RPI turns out to be very reliable, definitely with the SSD that I’m using now. In 5 years I only had 1 problem, with the sd card. Manual restarts are not applicable here because the automation part is for when we’re not at home :-).
But I’m always in for better/easier/more efficient way of doing things. Here’s the full automation.
If for any reason there’s a need to restart Home Assistant during that 3.5 hour window, all automations that are busy executing their actions are instantly terminated. Whatever actions they had yet to process won’t be executed.
EDIT 1
Please format your posted automation. YAML indentation is critical and the way it’s currently presented makes it a mess.
If I have understood your automation correctly, it is possible to design it without a delay or a timer. It would use at three Sun Triggers, two with positive offsets plus an Input Boolean to control execution.
If the input_boolean is on, the automation processes actions at the scheduled time. If it’s off, it will not execute the actions.