Automation stopped without warning

Pedro34 · February 9, 2022, 5:28pm

Restarting the server (configuration/settings) breaks running automations without any warning.
Request:

Under automations make the active, running automation somehow visible: icon, color, …
When shutting down the server (components?) a warning should pop up explaining what automation is still running, with the option to
```
1. cancel the shutdown/restart process

2. continue with shutdown/restart and therefore break/stop the running automation
```

Explanation:
I use automations to start the power generator if the batteries soc indicates. The automation contains a wait function waiting for the soc to reach a certain level. This wait period can take an hour or more. It happened that i fiddled around HA and restarted the server. The generator continues to run, producing power und using fuel. But it never ends as there will be no stop order!

yaml code

alias: HA004 - Generator start / stop
description: start gen if soc low, wait for soc, stop
trigger:
  - platform: numeric_state
    entity_id: sensor.battery_soc
    below: '88'
    for:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0
condition: []
action:
  - scene: scene.generator_on
  - service: telegram_bot.send_message
    data:
      message: >-
        HA004.1 - Generator started. soc: {{states("sensor.battery_soc")}}
        batt.v: {{states("sensor.battery_volts")}} - Waiting for soc to stop
        generator 
      message_tag: HA004
  - service: logbook.log
    data:
      name: HA004
      message: >-
        HA004.1 - Generator started. soc: {{states("sensor.battery_soc")}}
        batt-v: {{states("sensor.battery_volts")}} 
  - wait_for_trigger:
      - platform: numeric_state
        entity_id: sensor.battery_soc
        above: '91'
        for:
          hours: 0
          minutes: 1
          seconds: 0
  - scene: scene.generator_off
  - service: telegram_bot.send_message
    data:
      message: 'HA004.2 - Generator stopped. soc {{states("sensor.battery_soc")}}. '
  - service: logbook.log
    data:
      name: HA004
      message: >-
        HA004.2 - Generator started. soc: {{states("sensor.battery_soc")}}
        batt-v: {{states("sensor.battery_volts")}} 
mode: single

123 · February 9, 2022, 5:44pm

It’s a fine Feature Request but your automation containing a wait_template (or wait_for_trigger or delay) can be cancelled not only by a restart but also by execution of Reload Automations.

It’s reasonable to ask for confirmation prior to restart (when there are automations in-progress) but making the same confirmation prior to Reload Automations would be problematic. Why? Because anyone who uses the Automation Editor transparently executes Reload Automations whenever they click the Save button. In other words, if you use the Automation Editor, any automation that is in-progress is terminated whenever you create/modify an automation and click Save.

FWIW, currently there’s no support for ‘incremental reloading’ of only a new or modified automation; all automations are reloaded.

It may be possible to re-design the automation so that it can survive a restart and a Reload Automations. Post it in a separate topic (categorized under Configuration) and we can see what can be done to make it more fault-tolerant.

Pedro34 · February 10, 2022, 7:30am

#Taras: i changed the category to configuration

koying · February 10, 2022, 8:17am

HA is a big event-based state machine.
IMHO, waits, loops, … in an automation are never a good idea.

For your use case, you could just create a 2nd automation with your “wait’” trigger (+ maybe trigger on homeassistant start) to achieve the same result and be oblivious of HA restarts.

Pedro34 · February 10, 2022, 12:14pm

I had this solution also. But then the stop automation triggers even if the generator is not running.

If there would be a HA status saying that a certain automation is active/running (aka if active(automation xy) = true then do action) then yes.

Pedro34 · February 10, 2022, 12:25pm

I just found something: The attribute “current” changes from 0 to 1 when the automation is active:

last_triggered: 2022-02-10T12:18:38.539242+00:00
mode: single
current: 1
id: 1642691497311
friendly_name: HA001 - Watering trees, start/stop pump.

The question now is: How can one test a single attribute?

123 · February 10, 2022, 12:55pm

This template reports true if a given automation is busy executing its actions.

{{ state_attr('automation.whatever', 'current') > 0 }}

koying · February 10, 2022, 1:00pm

You don’t have a way to tell if it’s running or not?
How do you tell it to start/stop?

Pedro34 · February 10, 2022, 7:09pm

yes there is: I use a sonoff switch to power on and off. switches also have a status “on” and “off” .
Disadvantage of having two automations is that they should be somehow synchronised.

I liked the idea to have on program (automation) that does both: start AND stop an engine.

koying · February 10, 2022, 8:23pm

Then you can have a condition on that switch to know if you actually have to switch off, if it matters one way or another.

Try to have 2 doing what you want as a baseline. You can merge them later (it adds complexity)

Pedro34 · February 10, 2022, 10:56pm

#123 Taras: People try to convince me of the concept of two automations, one for start and one for stop function. But this is what i had before i merged it into one, using the wait_for operation.

What is the meaning if a wait function if a simple edit-and-save operation breaks any running automation? Even without a wait function active, it can happen that a automation gets killed this way.

Therefore it is essential that HA informs about running automations: A semaphore on the dashboard and on the automations overview (configurations/automations). Or changing the concept of storing all automations into one single yaml file!

What do you mean with re-design the automation so that it can survive a restart ?? How should that go?

123 · February 11, 2022, 12:24am

I mean you should change the automation’s design so that it doesn’t use anything within its action that causes it to spend a lot of time there (such as a long delay, wait_template, wait_for_trigger, repeat, etc).

Personally, I don’t allow the action to wait for longer than about 5-10 minutes. If it must wait longer, I use a different method.

For example, in your automation could use two State Triggers, each with an id option, and either a choose to differentiate between the two triggers or a templated service call.

koying · February 11, 2022, 8:17am

That’s a good question, indeed.
Still wondering what was the use-case that allowed that to go into HA, tbh

Conceptually, state machines are meant to replace loops/waits, and are mutually exclusive…

123 · February 11, 2022, 1:37pm

Home Assistant continues to evolve and improve due to the efforts of volunteers. Some of the improvements are daunting because they require architectural changes. I suspect the ability to perform an incremental reload, of just the new/modified automations, that doesn’t interrupt busy automations, is one of those daunting challenges.

If it were to ever be implemented, then a busy automation would only be terminated by a full restart.

FWIW, I use another home automation software (that was created over two decades ago), together with Home Assistant, and it has transparent, incremental reloading of everything. In other words, it’s not an impossible software problem to solve but nevertheless still presents a challenge (otherwise, arguably, it would have been already done for Home Assistant).

Pedro34 · February 11, 2022, 11:51pm

I made another interesting observation: The automation to start/stop the generator was running while i was testing a few ideas (based on this discussion). I we now know: Once saving a automation the running ones get canceled. So happened here: It can be seen in the timeline: It ends with “canceled”. But the generator was still running as the Sonoff switch was not changed.

After thinking about what best i could do i decided to simply run the automation again. After that the automation was in the “wait_for” phase, waiting for soc to reach 91% in order to stop the generator. But that trigger never occured. I waited until the soc reached 92% before i manually switched it off.

Strange! no?

khvej8 · February 12, 2022, 1:13am

create a “helper” which you set to 1 when the generator is started and set to 0 when stopped. use the helper as a condition to avoid starting the generator again, if already running The helper does not reset during a restart. Then you can have 2 automations. I use this a few places to control lights which should stay on for very long time.

123 · February 12, 2022, 3:04am

Here’s what I suggest:

alias: HA004 - Generator start / stop
description: start/stop gen based on soc 
trigger:
  - id: 'on'
    platform: numeric_state
    entity_id: sensor.battery_soc
    below: '88'
    for: '00:05:00'
  - id: 'off'
    platform: numeric_state
    entity_id: sensor.battery_soc
    above: '91'
    for: '00:01:00'
condition: []
action:
  - variables:
      msg: >
        HA004.{{ iif(trigger.id == 'on', '1', '2') }} - Generator {{ iif(trigger.id == 'on', 'started', 'stopped') }}.
        soc: {{ states('sensor.battery_soc') }} batt.v: {{ states('sensor.battery_volts') }}
  - service: scene.turn_on
    target:
      entity_id: "scene.generator_{{ trigger.id }}"
  - service: telegram_bot.send_message
    data:
      message: '{{ msg }}'
      message_tag: HA004
  - service: logbook.log
    data:
      name: HA004
      message: '{{ msg }}' 
mode: single

EDIT

Correction. Replaced scene: with service:

Pedro34 · February 14, 2022, 11:13pm

Hi 123 Taras. That indeed is a completely new approach for me. The code is generated just before it is executed. Wow! Very clever but this technique also makes the code hard to read and understand. I will add a few lines of comment.

For developing: Is there a debugging, Trace, method that shows the statement of code generated?

123 · February 15, 2022, 12:17am

Why?

Which part of it makes it so much more difficult to “read and understand” for you?

It has two Numeric State Triggers. Depending on which one triggers, the corresponding scene is turned on and a message is sent. It’s as simple as that.

The most important thing is that it is unaffected by a restart or a by reloading automations.

Pedro34 · February 15, 2022, 7:22am

Why? Because one has to assemble the statement to be executed in mind before understanding. One cannot simply read the code (program). It is self-modifying.

Could the action part not be programmed like the trigger part? With two sections where only one is executed? A kind of IF… THEN… ELSE section. Then the message and the scene to be run are in clear words.