STOP a running automation (NOT TurnOff)

Configuration
1

Is there a way to stop an automation?
eg have an automation that turns a switch on > then Delays for 3 hours > Turns the switch off.
but, if I want to start the automation, then turn the switch off, and restart, it doesn’t work, as I assume, it still sees the already running timer?
Thanks.

2

I would not incorporate such a long delay. Prolonged delays are generally not recommended since they do not survive a system restart/reboot.

What mode are you using? mode: single

If so start with mode: restart

3

Even a reload of config can reset them.

4

Yes sir, I agree!

5

Yeah don’t do that. Turn the switch on with your existing automation then write a second automation to turn it off triggered by:

trigger: state
entity_id: switch.your_switch_here
to: 'on'
for:
  hours: 3

Or add that trigger to your existing automation and use a choose action to turn the switch on or off.

6

Thanks for the replies, point taken, but…
Is there a way to STOP an automation?

7

You can use with stop_actions:true but it’s not ideal

action: automation.turn_off
target:
  entity_id: automation.xxxx
data:
  stop_actions: true

image
image805×185 6.21 KB

8

If mode: restart is acceptable, you can also define a trigger that “does nothing” (i.e., the automation does nothing in response to this trigger). A custom event trigger is suitable for this. Then, fire this event to stop the automation.

Also not ideal because it will spam the logs.

9

Thanks.
But have edited to mode: restart, and does the trick!
Thanks.

…gradually learning…

10

My first bit of advice, but explore Tom’s suggestion too :down_arrow:

11

We might be at the “post the yaml of your automation” part of this thread. My guess is if you are thinking you need to stop a running automation there’s probably a better approach.

Think in terms of events: Something happens to trigger an automation and the automation does something at that moment and finishes.

12

Related question, if I may ask… Would this kind of thing survive a restart/reboot?

I’m new to HA (and in an abundance of caution), I’ve been using Timer Helpers to bridge extended on-vs-off automations, but perhaps that’s overkill?

13

No it won’t strictly survive a restart. It will reset the timing. 3 hours after the restart it will trigger. As during a restart the switch changes from unknown to on when its state is restored.

It will survive a reload of automatons if you have not changed that particular automation (only changed automations are reloaded). If you have changed the automation and reloaded then no it won’t trigger until 3 hours after the switch next changes to on.

Timers are a good way to ensure better continuity of timing as they can be restored after a restart. Another way is to use a time trigger that uses an input datetime helper that has the on time plus three hours stored in it. Both of these methods only fail if the system is off at the time the automation should trigger.

14

That is very helpful info - thank you, good sir!

15

It’s an edge case, of course, but it might be important. For example, on my irrigation system I use a timer to make sure I don’t water (up to) twice as long if I was using a “for:” in my automation. In cases like this I have a homeassistant start event look at the timer and if the timer is NOT running then I turn off the irrigation valve.

16

My method would be to create an input boolean (Toggle). The automation watches the toggle. If the toggle goes on, it flips the switch to match.
Then you have timers or automations or scripts or push buttons on the dashboard or physical buttons, whatever, control the toggle. When the toggle changes, the switch follows.

I use this theory in a couple of places now where I want to control something thru multiple methods. The actual on-off is fairly clean and straight forward. The control of the toggle is more convoluted.

17

Yeah, similar here. But, I don’t use a separate template boolean, I just send an event. As with the toggle, it allows separating out the actual turning on the device so you can centralize any needed condition checks:

For example, this automation turns on the pump when the guest bath door closes. I have a few other automations that also send the event (like switches around the house).

  - alias: HWP - Turn on pump guest bath
    id: hwp_tun_on_guest_path_id
    triggers:
      - trigger: state
        entity_id:
          - binary_sensor.guest_bath_door
        from: "on"
        to: "off"
        for: '00:00:20'
    conditions:
      - condition: time
        after: "05:00:00"
        before: "23:30:00"
    actions:
      - event: turn_on_hw_pump

Then the automation to turn on the pump with its condition:

  - alias: HWP - turn pump on
    id: turn_hw_pump_on
    triggers:
      - trigger: event
        event_type: turn_on_hw_pump
    conditions:
      - "{{ is_state('timer.hot_water_pump_delay', 'idle') }}"
    actions:
      - action: switch.turn_on
        target:
          entity_id: switch.hot_water_pump

And then another automation for what happens when the pump turns on. In this case it’s only needed for setting a timer to limit frequency of running the pump:

  - alias: HWP - the pump turned on
    id: hwp_the_pump_turned_on_id
    triggers:
      - trigger: state
        entity_id: switch.hot_water_pump
        to:
          - "on"
    actions:
      - action: timer.start
        target:
          entity_id: timer.hot_water_pump_delay

The actual turn off of the pump is triggered by a binary template sensor using a “delay_on”.

18

Another way to control an Automation where you want time delays is using a Timer and Boolean “pair”. I created a custom card that allows for both control and visibility of such situations… Bypass & Timer Manager Card - Control and Monitor Timers and Input Helpers

19

Timers are good, but they can’t carry data (context), and you can’t create an ad hoc timer. That’s why I prefer custom events. I have a single script in parallel mode, to “offload” the waiting from any single-mode automation. It then triggers a custom event, passing the data back, which restarts the automation (logically, automation resumes after waiting, thanks to the context).

I don’t save these “timers” because my wait times are very short, but they could be saved in a trigger-based template attribute and brought back on system start.

20

You have a generic script that you call and pass in a time to delay and an event to call when done? Is the calling automation waiting for the script to finish or does it fire the script and finish and then another trigger catches the event?

I used to wish for ad hoc timer creation, but over time I haven’t really found where I needed to create one dynamically. When I use a timer it’s for a specific need so I just create it.