Automation seems to stop when 1 action fails

Configuration
1

Hi,

First post here, new HomeAssistant user. Been using HomeSeer for a long time and looking for something new…

In my ‘away’ automation i want to lock the doors, stop my media players and turn of some devices and close the gate. The smart locks are Nuki. It seems like HA stops executing the automation whenever an action fails. For example, if the Nuki battery is dead, the rest of the actions is not performed (e.g. the gate is left open). I could shuffle the actions around, but if the gate command fails …

Is there a way to conintue execution the rest of the actions whenever te previous action fails ?

Best regards and thanks !
Deva

2

Please post your ‘away’ automation (formatted) so we can examine it and make suggestions to make it more resilient to the Nuki lock’s issues.

3

Hi,

This is (part of) my config:

groups:
  Residents:
    name: Bewoners
    control: hidden
    entities:
      - device_tracker.phone1
      - device_tracker.phone2

  locks_house:
    all: true
    entities: 
      - lock.back
      - lock.front
      - lock.side

away_turnoff:
  name: Appliances to be turned off when away
  entities:
    - switch.edimax_quooker

automations:
  - alias: Away actions
    trigger:
      platform: state
      entity_id: group.Residents
      from: "home"
      to: "not_home"
    action:
      - service: lock.lock
        data_template:
          entity_id: >
            {% if states.input_boolean.guests.state == 'on' %}
            group.locks_house
            {% else %}
            group.all_locks
            {% endif %}
      - service: homeassistant.turn_off
        data:
          entity_id: group.away_turnoff
      - service: media_player.media_stop

The problem is that the actions after the lock are not executed because one of the locks is offline (battery dead). It happens that HA restarted after the battery was dead, so the entity appears to be missing.
I understand that this raises errors, but I would expect the rest of the automation to execute fine.

4

I tried to duplicate your results but, in my case, Home Assistant doesn’t care if the entity is missing.

I created a group, called group.test_group, containing two lights (I don’t have two locks).

  • The first light doesn’t exist: light.none
  • The second light does exist: light.family

I made a simple automation to toggle the lights when I turn on an input_boolean:

- alias: 'test group'
  trigger:
  - platform: state
    entity_id: input_boolean.toggler
  action:
    - service: light.toggle
      entity_id: group.test_group
  • When I turn on the input_boolean, it causes light.family to turn on.
  • When I turn off the input_boolean, it causes light.family to turn off.

Even though the group contains a non-existent entity (light.none) it doesn’t prevent Home Assistant from controlling the other light.

I don’t know how to explain what’s happening in your situation. Maybe it has something to do with the specific lock platform you are using.

5

Thanks for your help 123 !

If I remove the lock from the automation, everything works ok. Need to get to the bottom of this …

6

Try lock automation without the template and just set to entity_id: group.all_locks .

Maybe the test condition running causes automation to fail if it cannot resolve entities

7

The problem is that your group.away_turnoff has the wrong spacing, so it doesn’t exist. The action is probably happening, it’s just happening to nothing.

You have:

groups:
  Residents:
    name: Bewoners
    control: hidden
    entities:
      - device_tracker.phone1
      - device_tracker.phone2

  locks_house:
    all: true
    entities: 
      - lock.back
      - lock.front
      - lock.side

away_turnoff:
  name: Appliances to be turned off when away
  entities:
    - switch.edimax_quooker

It needs to be:

groups:
  Residents:
    name: Bewoners
    control: hidden
    entities:
      - device_tracker.phone1
      - device_tracker.phone2

  locks_house:
    all: true
    entities: 
      - lock.back
      - lock.front
      - lock.side

  away_turnoff:
    name: Appliances to be turned off when away
    entities:
      - switch.edimax_quooker

Also, you should remove the capital R on Residents. Field names in yaml should be all lowercase.

8

Hi Petro,

The error with the group is a copy paste layout error, it is correct in the configuratoin file. Some of the locks actually lock, it’s just that one errors out and than it bails out of the entire automation.

9

I have the same question as the OP - if one element of script or automation action fails, the script just stops and everything beyond it doesn’t happen. This usually happens when some external service temporarily fails (today it was an Ecobee server failure), but I’ve also seen it with my Harmony hub and Arlo. Unfortunately, cloud functionality is inherently fragile.

Is something like AppDaemon the only way to continue executing when part of an action fails?

10

take the parts that fail frequently and place them in their own script. Call that script from the action sections. That way, the script will fail or not but it will not produce an error in the top-most script.

1 Like
11

As close to a try-catch block as one can get with an automation … but minus the catch clause. :slight_smile:

12

Yeah pretty much. It’s a pain in the ass but it gets around the issue.

13

Thanks for the quick responses. It turns out that another quirk I was seeing around multiple triggers of automations with delays can also be solved by pushing actions into scripts. I see more scripts in my future :slight_smile:

14

I have the same problem. Creating a script for each of the actions that can fail doesn’t work for me. The problematic call is a restful command that fails if my PC is switched off.

This is in my scripts.yaml:

pcsleep:
  sequence:
    - service: rest_command.sleep

foco_on:
  sequence:
    - service: light.turn_on
      data:
        entity_id: light.0xd0cf5efffe2ebeb4_light

and this in my automations.yaml:

- alias: apaga_tele_y_luces_salon
  initial_state: true
  trigger:
  - platform: event
    event_type: duracell
  action:
  - service: script.pcsleep
  - service: script.foco_on

script.foco_on is never called if pcsleep fails

thanks,
Paco

15

no reason at all to use a script for that, since it is an unconditional service, and not even using extra data at that, so use:

    - service: light.turn_on
      entity_id: light.0xd0cf5efffe2ebeb4_light

either as a script (if you must) but just as good, or maybe even better as a standalone service in your automation. A failing script prior to that action will not prevent it from actioning.

16

Thanks, Marius, but it doesn’t work.

I previously had the rest_command in the automation and moved it to a script following Petro advice. I did the same with the light, but this is not important, since it is not called in any case.

If the target of the rest_command is switched off, it fails logging an obvious message “Cannot connect to host”. I cannot find a way to do anything after that.

17

you then could try to make a service_template out of the first script (with the rest command) and have it use a condition to act upon. It target is not off, rest_command, else do nothing. This is a main would also be the only reason for a subscript: to use it with a test for state, and depending on that state configure the action. But mainly to have the automation continue, if 1 of the actions fails, halts or doesn’t fire. Or to build other logic in to that part of the action.

add a script pcsleep_test using your pcsleep script, in the form of:

- service_template: >
    script.{{'pcsleep' if target != 'off' else 'continue'}}

and have a script continue like this:

continue:
  alias: 'Continue'
  sequence:
    delay: 00:00:00

of course replace ‘target’ with the entity_id you’re testing

- alias: apaga_tele_y_luces_salon
  #initial_state: true <-- no longer necessary unless you need it to be always on/off on restart
  trigger:
    - platform: event
      event_type: duracell
  action:
    - service: script.pcsleep_test
    - service: script.foco_on
18

Thanks, I’ve used this idea and it works. Actually, I’ve added a condition in the script:

pcsleep:
  sequence:
    - condition: state
      entity_id: binary_sensor.salon
      state: 'on'
    - service: rest_command.sleep

My target is a Windows 10 PC and the binary_sensor.salon is based on ping:

binary_sensor:
  - platform: ping
    name: salon
    host: 192.168.1.6
    scan_interval: 15

But this solution is not ideal, since it needs a periodic ping. It would be better to be able to detect and respond to the rest failure. I feel that it is wrong for the rest command to abort the automation with an uncatchable exception.

19

well, that doesnt happen now does it? So you can search for a solution to that specific issue. Always try to narrow down what is bugging the proceedings, and solve that.

Agree though that is is somewhat counterintuitive that the original automation would halt on the failing rest command

20

Just found another solution. Instead of running a scrip, trigger an automation. The second automation runs in parallel and can fail without affecting the first one.

In my case, I don’t care about the order of events, so running in parallel is fine.

my automations:

- alias: pcsleep
  trigger:
  action:
  - service: rest_command.sleep

- alias: apaga_tele_y_luces_salon
  trigger:
  - platform: event
    event_type: duracell
  action:
  - service: automation.trigger
    entity_id: automation.pcsleep
  - service: script.foco_on
1 Like