Everytime Homeassistant restarts all the running automations are cancelled.
This is logical from a computing stand point but I got a automation that turns on the dishwasher when enough power is send back to the grid. This usually means its running from the evening till somewhere early next day.
Is it at all possible to let Homeassistant remember in what state the automation was on shutdown and let it resume where it was?
Maybe add a option so you could select only certain automations to be remembered.
While it may be technically possible, It does come with the risk that the automation is resumed in a state that it isn’t supposed to be in (and won’t be in if the automation isn’t interrupted).
Best practice is to avoid long running automations altogether and have the second part in a separate automation with it’s own triggers. That is almost always possible.
Agreed the suggestion would break the hell out of a whole different class of automations that rely on NOT restarting when ha restarts and hack off those users. There is no universal ‘this fixes everyone…’
IMHO the solution is add when ha starts to the trigger of your automation and write the script to be restart able and handle the conditions properly so when it restarts it ends up exactly where it needs to be.
I could see this work if we had a way to resume with context at a position in the automation. It would only apply for delays, but at the start of the delay, we’d cache to disk the current run variables and then just resume when the delay is met after the restart. It could be a relatively easy add?
What happens if HA is down for an extended period and when it comes back on all the states of entities used in the automation are different from when it stopped?
Info would be unloaded, we have this functionality right now with restore state, it’s not too complicated. Hard part would be running the automation from a specific point
But half the automation has run with one set of states and then after resumption a new set of states. What if variables were calculated before the interruption?
That is the problem. You are now using a variable calculated with state data that no longer exists.
e.g. When the automation started the variable said the heating should be set to on as the room was 16°C. After restarting is now 30°C in the room and the automation turns the heating on because it is using out of date data calculated before the restart.
If you conceptually think about it, the delay and execution of the automation would be the same as if it didn’t restart. There’s no checks like you’re talking about right now
It’s all the variables, some things that the automation does, the delay, then more things. It does not recheck or build variables again
Anyhow, first i also totally agree with Edwin, I also prefer short Simple automation/templates
Then there are a “cumbersome” way
i.e file-text-sensors, for shutdown/boot timestamp , ( are useful for other useful purposes )
and you need a “persistant” file(platform.file) for the Loong important automation traces using the automation.logger in realtime
First step read trace, was latest run aborted ?
Then you run(record) at start in your “important” automation
Then you have all data (almost)
*Then you write your automation with various “checkpoints”, using conditions
*Read current variables
*was last run aborted ? goto i.e latest timestamp, or checkpoint(what ever)
( read timestamp > < , (skip to / continue)
( read timestamp > < , (skip to / continue) etc etc
You have the time of latest checkpoint/abortion/shutdown/startup
so you can also calculate the “time ofline” So maybe its already to late, goto bed
And you also have the New variables, to hot, cool down
Then it would be up to the “author” i guess which should be next step(checkpoint) Continue ?
PS: I would probably never consider writing such an automation , was just spinning away, of to bed now, 2am here
Last post for the night, this is the YAML code of the automation that caused me to make this topic.
What it basicly does is check if the door is closed and the remote start button is pressed.
Then it waits until either the power going into the grid is higher than 500W or its been 12:00.
Afther that it start the dishwasher.
Since we load and activate the dishwasher after dinner it can be waiting for a good part of the day to start. Looking at it I could probally change it so it triggers on the “wait for triggers” instead but then it would trigger allot more times. No clue if thats more resource intensive or not.
alias: Start Vaatwasser
description: Start vaatwasser als er genoeg zonnestroom is of op een vaste tijd.
triggers:
- trigger: state
entity_id:
- binary_sensor.vaatwasser_deur
to:
- 'off'
conditions:
- condition: state
entity_id: binary_sensor.siemens_dishwasher_remote_start_allowed
state:
- 'on'
actions:
- wait_for_trigger:
- trigger: numeric_state
entity_id:
- sensor.totaal
id: Teruglevering
below: -500
for:
hours: 0
minutes: 2
seconds: 0
- trigger: time
at: '12:00:00'
continue_on_timeout: true
- action: button.press
metadata: {}
target:
entity_id: button.vaatwasser_start
data: {}
mode: single
To improve that from being interrupted and not running. Get that wait for trigger out of your actions and use it as a trigger for an automation instead. That way you are not waiting in the automation and it has a minuscule chance of being interrupted.
alias: Start Vaatwasser
description: Start vaatwasser als er genoeg zonnestroom is of op een vaste tijd.
triggers:
- trigger: numeric_state
entity_id:
- sensor.totaal
id: Teruglevering
below: -500
for:
hours: 0
minutes: 2
seconds: 0
- trigger: state
entity_id: binary_sensor.siemens_dishwasher_remote_start_allowed
to:
- 'on'
for:
hours: 12
minutes: 0
seconds: 0
conditions:
- condition: state
entity_id: binary_sensor.siemens_dishwasher_remote_start_allowed
state:
- 'on'
- condition: state
entity_id:
- binary_sensor.vaatwasser_deur
state:
- 'off'
actions:
- action: button.press
metadata: {}
target:
entity_id: button.vaatwasser_start
data: {}
mode: single
Worst case: you have not been exporting all day and a restart happens just before the 12 hours is up, so it delays for another 12 hours then starts. Not great but at least it runs.
You may need another condition to cheek if the dishwasher is already running.
I would say that if the behaviour to resume an automation is optional (part of its config), then one could design your automation for dealing with possibly changed states, variables, conditions, etc.
gotta make assumptions
, was just spinning away, of to bed now, 2am here