Allow scripts/automations to continue after a failed action

It would be useful to be able to specify that an action should not prevent further execution of a script/automation upon failure.

I have a sequence of actions that first attempts to pause any playback from a specific media player (using Spotify). However, if that media player is not playing, the service call will fail and the remaining actions in the sequence will not be executed.

In the above example, I’m fortunate that I can simply re-order the actions to place the failing one at the end. However, there will be other cases where multiple steps have the potential to fail and a ‘best effort’ to complete all steps may be preferred.

My proposal would be to introduce a syntax similar to that of the wait timeouts, where a user can currently specify continue_on_timeout with a boolean value. For actions within a sequence, a property such as continue_on_fail could be set by the user, defaulting to false if omitted to maintain backward compatibility.

Not the best workaround but you could use choose templates as actions.
So template is media player is playing, action pause.
But a short version of that could be handy.

Another option is Node red where you can put all call services in parallel.

Indeed, there are workarounds for specific cases if you anticipate where actions might fail. This is more so you can define something upfront as ‘best effort’ and not need to know all the ways in which it might fail ahead of time.

Isn’t that exactly what the wait templates together with a timeout do? :slight_smile: Wait for something to get to a specific state, and if not, move on after a set timeout… So in your case, wait for pause, if it won’t get there, move on after X minutes…

Not quite. Let’s say you call light.turn_off and for whatever reason it throws an exception. Now your script just ends prematurely. There’s nothing to wait for, since you’re the one issuing the service call in the first place.

exactly my problem right now… did you find any workarounds?
if (exec failed) then?

My current workaround is to have a script like script.play_media with all the variables etc and then call this script via the ‘indirect’ method as described here: Scripts - Home Assistant
Hope this helps

Agree, this has already negatively impacted me a few times but now I know to be cognizant of it.

I agree on this one. It is become more an more needed and it allows us to require all integration to fail on error (instead of suppressing it).

The result would be more predictable and consistent and allowing failure to become a conscious choice.

I’ve prepared a change for this. This PR start by creating a way to manually allow failure/stopping (and makes a clear distinction between aborting and stopping.

I’ll try to make a follow up for this feature request after that.


Implemented in:

Should become part of Home Assistant 2022.5


Hi @frenck, thanks for this!
I’ve just been troubleshooting a daily ZWJS battery level refresh that was not refreshing all entities and discovered one of my entity_id’s had changed for reasons that are obviously clear to me now that I’ve found it. It would be nice to obtain a direct notification of the failed automation action in addition to the standard logger entry. Something like on_error: service: notify.persistent_notification data: title: message: {{ error_message }}
Alternatively, does the error in the automation/script fire an event on the event bus that I could watch for? If not, might that be possible?

1 Like

Guys, updated to 2022.5

so yaml:

  alias: Alles uit
  continue_on_error: true

but gives me:

2022-05-04 22:27:58 ERROR (MainThread) [homeassistant.config] Invalid config for [script]: [continue_on_error] is an invalid option for [script]. Check: script->continue_on_error. (See /config/configuration.yaml, line 130).

It’s a property of an action, not of the script itself. Try moving continue_on_fail: true into one of your actions instead.

1 Like

It would be nice if this option were also available as a tick box in the UI editor…


I would like to see it as an option for the entire automation and not just one action. @frenck