Stuck on automation with delay

[Mastiff]

I am trying to run a test of my Z-wave network 6 and 8 minutes after Home Assistant startup. Sometimes a random node is shown as dead on startup, and the only way to wake it up is to run a test., which always works when I run that manually. But it’s not much of a home automation if I have to do it manually… And the startup time for the Z-Wave network at the moment is around 7 minutes, but I wan’t it to run as soon as it’s possible to do so (which it isn’t until the netwok has started). But I can’t really get it to work. Here’s the code I’m trying:

- id: '1535832688944'
- alias: Fikse døde noder
  trigger:
    - platform: homeassistant
      event: start
  action:
  - data:{}
  - delay: '00:06:00'
  - service: zwave.test_network
  - delay: '00:08:00'
  - service: zwave.test_network

This gives me all kinds of errors, Even running the delay and service only once doesn’t work. I get errors if I don’t have data, and I get errors about required data missing when I remove it. I never seem to get the hang of this YAML programming, I understand LUA Script and a bit of Python scripting, but not this. Can somebody please put me out of my misery?

[123 (Taras)]

- id: '1535832688944'
  alias: Fikse døde noder
  trigger:
    platform: homeassistant
    event: start
  action:
  - delay: '00:06:00'
  - service: zwave.test_network
  - delay: '00:08:00'
  - service: zwave.test_network

[Mariusthvdb (Marius)]

@Mastiff

I don’t have data, and I get errors about required data missing when I remove it

which are those errors?

@123 's automation should run smoothly, without any data field.

if anything, you could indent the dashes with 2 spaces, but that isnt formally required as long as you use the same indentation on all actions.

also, and that has been documented elsewhere on the community, using delay like this can cause mishaps. If you still run into issues try:

- delay:
    minutes: 6

since you say the timing isnt always the same, you could also try an input_number, to set the delay timing in the frontend, and not have to change the automation in the backend:

      - delay: 
          minutes: >
            {{ states('input_number.delayed_startup')|int }}

main error though is the double dash in your automation before both id: and alias:

[Burningstone]

Did you check out this page?

Automation Actions

There is a good example with delay. Did you try without ‘data’?

- id: '1535832688944'
  alias: Fikse døde noder
  trigger:
    - platform: homeassistant
      event: start
  action:
    - delay: '00:06:00'
    - service: zwave.test_network
    - delay: '00:08:00'
    - service: zwave.test_network

Please try this and show us the errors you get.

Oh @123 was quicker

[Mastiff]

Thanks, all! @123’s automation works, it seems! No errors. I always mess up with the indentations and dashes on this. I swear that’s what gets me every time!

Oh, the errors I had were:

Invalid config for [automation]: [data] is an invalid option for [automation]. Check: automation->action->0->data. (See /home/homeassistant/.homeassistant/automations.yaml, line 3).

required key not provided @ data['trigger']. Got None. (See /home/homeassistant/.homeassistant/automations.yaml, line 2)

[Mastiff]

@Mariusthvdb, you were right. The first way of delay wasn’t working. No errors, it just didn’t fire. So I tried your way, and it works the first time:

- id: '1535832688944'
  alias: Fikse døde noder
  trigger:
      platform: homeassistant
      event: start
  action:
  - delay:
      minutes: 2
  - service: zwave.test_network
  - delay:
      minutes: 3
  - service: zwave.test_network
  - delay:
      minutes: 4
  - service: zwave.test_network
  - delay:
      minutes: 5
  - service: zwave.test_network
  - delay:
      minutes: 6
  - service: zwave.test_network
  - delay:
      minutes: 7
  - service: zwave.test_network
  - delay:
      minutes: 8
  - service: zwave.test_network

But it doesn’t work any of the other times. Maybe that’s because it’s not erroring out in the same way as other, too early calls to zwave services do. With those I get:

Error while executing automation automation.termostater_til_5_grader. Service not found for call_service at pos 1: Unable to find service zwave/set_config_parameter

With the test command ran by the delay I instead get this mess:

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File “/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/script.py”, line 131, in async_run
await self._handle_action(action, variables, context)
File “/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/script.py”, line 210, in _handle_action
action, variables, context)
File “/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/script.py”, line 299, in _async_call_service
context=context
File “/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/service.py”, line 89, in async_call_from_config
domain, service_name, service_data, blocking=blocking, context=context)
File “/srv/homeassistant/lib/python3.7/site-packages/homeassistant/core.py”, line 1127, in async_call
raise ServiceNotFound(domain, service) from None
homeassistant.exceptions.ServiceNotFound: Unable to find service zwave/test_network

But if I trigger the same test command with MQTT I get:

Error while executing automation automation.fikse_dode_noder. Service not found for call_service at pos 1: Unable to find service zwave/test_network

And I have no idea why that is so different. Also, maybe the best way would be to retry the test until it actually works, if that’s possible? With my way I may run the test 3-4 times when the service is available if the startup of my Z-Wave network comes up faster.

[Mariusthvdb (Marius)]

not familiair with the service myself, but could it be the service hasn’t finished before you call it the next time?

[Mastiff]

I don’t think so. The same service, while ran by an MQTT message gives the same result as the other service I showed above, and it says:

Error while executing automation automation.fikse_dode_noder. Service not found for call_service at pos 1: Unable to find service zwave/test_network

14:16 helpers/script.py (ERROR) - message first occured at 14:15 and shows up 6 times

If the service itself was the reason, it should error out in the same way as ran by the delay, instead of showing that the service fails 6 times.

[Mariusthvdb (Marius)]

yes, ok. it seems to be called 6 times, indicating the delay is working just fine, but it errors out on the service itself…

[petro]

check your services in the dev tools. Verify that your system see’s it.

[Mastiff]

Sorry, but you’re not getting the point. The service isn’t there before Z-Wave system has finished starting up. I know that. It’s just that another way of calling the same service (by MQTT) errors out nicely and let me call the service again a second later (when it errors out nicely again and so on). So I need to find out why it errors out differently when ran by a startup trigger with a delay.

[petro]

Try executing a script that calls the service instead. It’s possible that the hass object is ‘stuck’ 6 minutes in the past after the delay. So when it tries to fire the service, it didn’t/doesn’t exist. If you plop it into a script, when the script runs it should now see the service.

[Mariusthvdb (Marius)]

@Mastiff

it errors out differently

as far as I can see the errors, the mqtt version says: Service not found for call_service while the automation returns: ServiceNotFound(domain, service) from None both leading to Unable to find service zwave/test_network

seem related errors to me… Then again, as said, I dont have the Zwave services in my setup, so must leave it to fellow members that do.

[Mariusthvdb (Marius)]

yes, thats smart. Should be different scripts though probably, since calling the same scripts over again, while the service hasn’t finished will most likely lead to the same issue…

[Mastiff]

@petro As I just wrote it works when I trigger the same automation (calling the service) by MQTT. So that means that with a delay trigger it gets stuck? It’s not stuck as long as the delays are, though. It errors out before that, but it takes a few minutes, instead of a second.

@Mariusthvdb I would have thought that the key difference between the ways they error out would be:

Error doing job: Task exception was never retrieved

Meaning that with the delay the exception doesn’t come as it does when triggered by MQTT. Or am I totally off base?

[123 (Taras)]

@Mastiff

The first way of delay wasn’t working. No errors, it just didn’t fire.

That makes no sense because this format is documented and works for me all the time:

# delay 5 minutes
- delay: '00:05:00'

To prove it I created this simple automation to log two messages. The first one occurs on startup and the second one is delayed by one minute:

- alias: 'delayed message'
  hide_entity: true
  trigger:
    - platform: homeassistant
      event: start
  action:
  - service: system_log.write
    data_template:
      message: "Started at: {{ now() }}"
      level: warning
  - delay: '00:01:00'
  - service: system_log.write
    data_template:
      message: "Delayed message at: {{ now() }}"
      level: warning

It works perfectly:

[Mastiff]

@123 but does it work when you have the first one running after one minute and the second one after 2 minutes, and a third after 3 minutes? As you see in my code I have several different delays, not just one trigger at once and one delay. I think that may be the difference between the two ways of doing it.

[petro]

Yeah no, that’s just wrong. Delays work the same way no matter the format. Something else is causing the odd behavior.

BTW. Why are you compounding the delays like that? Are you expecting your delays 2,3,4,5,6 to fire at 2 minutes, 3 minutes, 4 minutes, 5 minutes, and 6 minutes from startup? Because what’s actually happening is your delays will cause it to fire at 2 minutes, 5 minutes, 9 minutes, 14 minutes, and 20 minutes from startup.

[123 (Taras)]

@Mastiff

does it work when you have the first one running after one minute and the second one after 2 minutes,

Yes it does.

- alias: 'delayed message'
  hide_entity: true
  trigger:
    - platform: homeassistant
      event: start
  action:
  - service: system_log.write
    data_template:
      message: "Started at: {{ now() }}"
      level: warning
  - delay: '00:01:00'
  - service: system_log.write
    data_template:
      message: "First delayed message at: {{ now() }}"
      level: warning
  - delay: '00:02:00'
  - service: system_log.write
    data_template:
      message: "Second delayed message at: {{ now() }}"
      level: warning

@Mastiff

I think that may be the difference between the two ways of doing it

No.

[Mastiff]

@petro Why? Because I didn’t know any better, of course! In my logic they all took their trigger from the startup and then fired the mentioned minutes after the startup trigger, not after each other. I’ll fix that at once and retry.

@123 OK, then I have no idea why it didn’t work the first time. Anyway, it’s a lot more tidy the way I’m doing it now.