General guidelines for restart-proofing automations?

Configuration
1

The two scenarios I have come across include motion light timers and “wait for trigger” functions. If the automation is running but waiting on a timer or trigger and HA restarts, the automation does not pick up where it left off.

I’ve seen Blueprints where restarts are handled or other functions are used to restart-proof an automation, such as using a service call. Here is one example: Automation that turns a device on, then off based on condition, did I do it right? - #4 by 123

I am wondering if there are general guidelines for creating automations so that they are unaffected by restarts? Thanks.

2

I think what this comes down to is, does the automation maintain some kind of internal state for a prolonged period? For example, does the automation wait for something during the Action section? This could be wiating for a time delay for turning something off after the same automation has turned it on.

If the automation has no internal state (it doesn’t need to remember anything that isn’t available as the state of some entity) or it runs for a very short time (and would be unlucky to be interrupted by a restart) then there is little need to worry.

If the automation needs to store information that isn’t the state of some entity then it may be safest to create a Helper entity to store this information.

To avoid having the automation run for a long time it is probably best to have anything that causes the automation to run, or change it’s internal state, as a trigger in the Triggers section, rather than using Wait for Trigger actions. Then, the combination of Choose actions and any internal state stored in helper entities could be used to decide what to do.

Here is an example:

alias: Hall Cupboard 2 Door
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.hall_cupboard_2_door_contact
    id: Hall Cupboard 2 Door Contact Changed
  - platform: event
    event_type: timer.finished
    event_data:
      entity_id: timer.hall_cupboard_2_timer
    id: Timer Finished
condition:
  - condition: state
    entity_id: input_boolean.automations_enabled
    state: "on"
action:
  - choose:
      - conditions:
          - condition: trigger
            id: Timer Finished
        sequence:
          - type: turn_off
            device_id: a2b9ce77b7c437fecb59a162a40a0b2a
            entity_id: light.hall_ceiling_light_3_level_on_off
            domain: light
          - type: turn_off
            device_id: e711fd8e4fe64a6c804a4649bf894bc5
            entity_id: light.hall_cupboard_2_lights
            domain: light
      - conditions:
          - condition: state
            entity_id: binary_sensor.hall_cupboard_2_door_contact
            state: "on"
          - condition: state
            entity_id: binary_sensor.hall_cupboard_2_door_contact
            state: "on"
        sequence:
          - type: turn_on
            device_id: a2b9ce77b7c437fecb59a162a40a0b2a
            entity_id: light.hall_ceiling_light_3_level_on_off
            domain: light
            brightness_pct: 100
          - type: turn_on
            device_id: e711fd8e4fe64a6c804a4649bf894bc5
            entity_id: light.hall_cupboard_2_lights
            domain: light
          - service: timer.start
            data:
              duration: "00:10:00"
            target:
              entity_id: timer.hall_cupboard_2_timer
      - conditions:
          - condition: state
            entity_id: binary_sensor.hall_cupboard_2_door_contact
            state: "off"
          - condition: state
            entity_id: binary_sensor.hall_cupboard_2_door_contact
            state: "off"
        sequence:
          - type: turn_off
            device_id: a2b9ce77b7c437fecb59a162a40a0b2a
            entity_id: light.hall_ceiling_light_3_level_on_off
            domain: light
          - type: turn_off
            device_id: e711fd8e4fe64a6c804a4649bf894bc5
            entity_id: light.hall_cupboard_2_lights
            domain: light
          - service: timer.cancel
            target:
              entity_id: timer.hall_cupboard_2_timer
            data: {}
    default: []
mode: single

In simple terms, this turns on the light inside a cupboard when the cupboard door is opened. It turns off the light when the cupboard door is closed. In addition, it turns off the light if the door is open for more than 10 minutes. It uses a Timer Helper (with restore enabled) to ensure the ‘state’ of the automation is preserved across restarts.

1 Like
3
1 Like
4

Thank you @123 and @templeton_nash! I’ll chew, swallow, and digest this and return with any questions. YAML is foreign to me, but I am able to [mostly] look at a script and replicate it using UI. Where UI is not supported, I am able to implement that section using YAML (thank you, @123!).

For the most part, I would like to understand why something works the way it does. For example, the idea of a service call rather than an event trigger, where the service call can properly handle a restart.

5

It’s unclear what you’re asking because a service call and an event trigger are completely different animals.

  • A service call is an action, not a trigger.
  • An event trigger is a trigger, not an action.

The linked post (above) demonstrates, in stages, how to make a fairly straightforward application (turn on a light at sunset and turn it off at sunrise) from something ultra basic to something robust that always sets the light to the correct state even if it missed triggering at sunrise/sunset due to a restart.

1 Like
6

Thanks for the explaination. I finally had some time to look at the example that I listed in the first post of this thread (provided by you), and I see the difference now. The service call is responding to a condition so it does not matter if HA restarted, as long as the condition is met, the service call is placed and the action is executed.

On the other hand, a “wait for trigger” function occurs mid-automation. After a restart, the automation does not return to that stage, which causes the intended action to fail.

Many have said that HA’s utility is only limited by one’s imagination. To me, automation scripts are only limited by one’s creativity and logic. Some automations’ construction and efficiency are very impressive indeed.

Thanks again, @123. I will dig in to the other examples you provided.

1 Like