Notify on error, continue remainder of automation

I have an automation which runs several actions in a row. If one action fails, the whole automation stops. I understand I can put continue_on_error: true in my action yaml config, so the automation continues running, but it doesn’t solve the issue of letting me know that something went wrong.

Occasionally, I’ll get a " EmberStatus.DELIVERY_FAILED" message– it’s not that the entity is unavailable, just that the command to the entity never arrived. I’d like to be notified that there was an error, while the automation finishes the rest of its routine.

Is this possible?

2 Likes

See the example in the documentation:


- alias: "If this one fails..."
  continue_on_error: true
  service: notify.super_unreliable_service_provider
  data:
    message: "I'm going to error out..."

- alias: "This one will still run!"
  service: persistent_notification.create
  data:
    title: "Hi there!"
    message: "I'm fine..."

Yes, I saw this, but I’m really looking for a way to make an if statement on error. If error, then notify, else continue.

This will just continue to the next action (in this case, the persistent_notification.create) everytime, regardless of whether the previous action failed or not…

I don’t think I’m understanding you.

Isn’t it exactly that what continue_on_error does?

No.

Let’s say I have an automation, whose action sequence is A-B-D-E. I’d like to insert an if statement that says, If B fails, do C, then continue with D and E, else if B doesn’t fail, continue with D-E.

Assuming B has an error, continue_on_error: true will only ever do A-B-D-E, where the default continue_on_error: false will stop after B. My question is whether you can insert a conditional based on the error status of an action. Can I make C conditional to the output of B?

Ah, ok.

How about this:


action:
  - service: light.turn_on
    target:
      entity_id: light.unreliable
    continue_on_error: true

  - delay: 1 # optional

  - if:
      - condition: state
        entity_id: light.unreliable
        state: "off"
    then:
      - service: notify.me
        data:
          message: Light is bitchy

  - another action

While that might work sometimes, it’s not really a reliable way to solve my issue…

For example, what if the light takes more than 1s to toggle? In your script, this is also uni-directional from on to off. What if I want to toggle in the opposite direction? Or check the specific value of a sensor? This isn’t the most reliable solution.

I’m really just wondering if it’s possible to know if an error has been thrown in the script sequence. That is all.

@123 Are you aware if this is possible? Perhaps through templating?

Then post more details. At the moment, I’m completely assuming.

I understand and appreciate your attempts to help, but I asked a very specific question:

Is it possible to script an If statement, based on an error condition in a running automation?

The answer to this question is all I am looking for.

FAQ Guideline 16: Should I tag people?

Apologies!

1 Like

I’m looking for the same thing. I have automations that turn on or off several Zigbee lights. I’d like to be informed if a Zigbee device fails to respond when running an automation. Now I have to notice that something that should be on or off isn’t and then go to automation traces to see what went wrong. Basically I’d like to receive the error in traces as a notification.

1 Like

I have the sam issur.
I’m calling the service last_called_alexa which from time to time gives an error.
This service fills a sensor with the latest called alexa device.
I’d like to know, that the service went in an error in order to know, that the sensor still provides an old information and not the latest.

What we need is:

Do_on error:
  - service.last_called_alexa
  - delay: "00:00:01"
  - variables:
       - varlastcalled == "error"
1 Like

+1, same here. I sometimes try to set a zigbee-device like a TRV back to a normal state, which sometimes fails, but nobody has a chance to realise that the service-call failed. This resulted in a too high temperature for the TRV (so in additional costs). Being able to “catch” the error like in other programming languages would be a great advance making the code more reliable.