Once automation is triggered, can it be terminated?

But you can do this.

- alias: Stop Automation
  mode: parallel
  trigger:
  - platform: event
    event_type: stop_automation
  condition:
  - condition: template
    value_template: >
      {{ trigger.event.data.automation is defined states(trigger.event.data.automation) not in ['unknown', 'unavailable'] }}
  action:
  - service: automation.turn_off
    target:
      entity_id: "{{ trigger.event.data.automation }}"
  - service: automation.turn_on
    target:
      entity_id: "{{ trigger.event.data.automation }}"

Then using this in your automation…

- event: stop_automation
  event_data:
    automation: "{{ this.entity_id }}"
6 Likes

Got it. Yeah, that’s true. Thank you.

I know I’m late…
But just in case someone is looking for a different (easy) solution:
Script Syntax - Home Assistant (home-assistant.io)

The stop feature you linked to serves a different purpose and doesn’t achieve what qjlang88 originally requested.

Sorry, maybe I misunderstood the discussion. But anyway, if someone needs an answer to the title question “Once automation is triggered, can it be stopped?”, the link might help. I sometimes use “stop:” to terminate automations.

Can you explain how you terminate a running automation that contains the stop feature?

Use the example in the first post; the automation contains a 2-hour delay and, before it has finished its countdown, you want to terminate the automation.

If you have to do it using “delay” it might be difficult.
I have not tested the following, but I think it should work.
The automation waits for someone to come home or for two hours to pass.

mode: single
trigger:
  - platform: state
    entity_id:
      - binary_sensor.someone_at_home
    to: "off"
condition: []
action:
  - wait_for_trigger:
      - platform: state
        entity_id:
          - binary_sensor.someone_at_home
        to: "on"
    timeout:
      hours: 2
    continue_on_timeout: true
  - if:
      - condition: state
        entity_id: binary_sensor.someone_at_home
        state: "on"
    then:
      - stop: ""
    else:
      - event: turn_off_power
        event_data: {}

Ok… You won’t even need a stop in this case…
Sry, I just saw this approach is the same anon supposed above.

Read the first post; delay is exactly what the topic’s author used.

So pick an example where you ‘sometimes use “stop:” to terminate automations’.

I see. Still…
The title question is: “Once automation is triggered, can it be terminated?”. I think stop can do this.

I would use stop if, for example, the automation would be much longer and/or would have multiple branches but has conditions under which further code should not be processed (as in the example above). “Stop” is in my opinion a way to keep the code clean. It can also be helpful for debugging, e.g. when analyzing the trace paths.
Often there are several ways to archive this. “Stop” is just another option.

You’re free to think whatever you want but you have yet to post an example proving how stop would solve the topic author’s problem. The reason you can’t is because it’s not the solution for this particular situation.

To get back to the original question:

Personally I do not like automations with long delays in them because you cannot see what actions are pending. Also, however many changes are made to relieve this, they will not survive a HA restart.

The solution that is seldom mentioned: timers. You can set an option to restore a timer on restart. You can see if a timer is running so you know what actions are planned ahead and when. You can have conditions test if they are running. You can pause them, reset them to their original time or cancel them. You can also start them from more than one place.

I have a auto entities card showing me all running timers too, so I can see which events are scheduled ahead.

1 Like

For scripts that run for a certain amount of time (although even a few minutes can be “too” long), you could query conditions (again) before executing the action. Then you do not necessarily have to cancel a running script, but make sure that it does not continue to run when it is no longer needed.

Just for the sake of completeness: I faced the same challenge of stopping a running automation; from within that very automation. I also wanted the automation to be self-contained (i.e. without a second automation just for stopping it), such that it can be distributed as a blueprint.

The (so far working) solution I came up with is as follows:

  • Set the automation mode: restart
  • Add a trigger event: stop_it
  • Add a first action to stop if triggered by the event
  • Fire the event as appropriate in the else branch

The restarted automation will kill the previous run. The stop action will make sure, the main script of the automation will not actually be restarted.

I know, it is quite involved. But the only idea I could come up with to achieve the requirements set out above. (Oh what a blessing it would be, if blueprints could actually create more than just a single automation. But that is another story…)

Here’s the blueprint for reference: Home Assistant Blueprint: Notify or do something when an appliance like a dishwasher or washing machine finishes · GitHub

1 Like