Major automation issue!

Configuration
1

I run a script every morning as my wake up thing. It runs a sequence of events; turn on specific lights, run an Alexa wake up announcement, read my calendar, tell me the weather… all minor stuff… until a simple request to turn on a zigbee light bulb that somehow lost it’s configuration… hangs and abends the entire script, causing my oversleeping.
This script has been running fine for 6 years now without a hiccup so I have grown fond of it.
NOW… anyone know of a way to keep a script/automation from abending just because of 1 device unresponse and keep on carrying on anyway?

2

continue_on_error: true?

1 Like
3

Is that a real item or a request?

4

That is a line you can add to your light.turn_on action

1 Like
5

Its very much in the docs…

1 Like
7

Error:extra keys not allowed @ data['continue_on_error']. Got True .

- id: good_morning_richard
  alias: "Good Morning Richard"
  description: "Good Morning Richard"
  continue_on_error: true
  initial_state: true
  trigger:
  - at: '06:55:00'
    platform: time
  condition: []
  action:

# Turn off/on some automations
  - service: automation.turn_on
8

It’s per action, not script-wide.

1 Like
9

YEAH! That worked… (on all 22 individual actions). Thank you!

10

I said add it to the light turn on action.
Not the automation

1 Like
11

someone should fix the documentation.

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

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

What is wrong with that?

13

Those two actions from the documentation example you pasted are sequential elements of a script or automation; they’d be indented within an actions block to define the body of an automation. Your automation is using legacy syntax–not a surprise since you said you’ve had it for a long time–and action today corresponds to what you have in your automation as service.

Perhaps that’s what threw you about where continue_on_error goes. In the legacy syntax, the body of the automation was defined with a keyword called action instead of the current syntax, actions.

The documentation doesn’t mean that you can put a continue_on_error at the level where you’re defining the automation and its triggers; it goes into individual elements in the body of the automation, as others have explained.

So there is nothing wrong with the example in the documentation.

14

And shouldnt be triggers: (and actions:) ?

Or is the old format?