Stuck on automation with delay

Configuration
53

If that’s the case, nesting the service in a script would have worked and got what @Mastiff wanted without the mqtt call.

script:
  zwave_test_network:
    sequence:
      service: zwave.test_network

- id: '1535832688944'
  alias: Fikse døde noder
  trigger:
      platform: homeassistant
      event: start
  action:
  - delay: "00:02:00"
  - service: script.zwave_test_network
  - delay: "00:01:00"
  - service: script.zwave_test_network
  - delay: "00:01:00"
  - service: script.zwave_test_network
  - delay: "00:01:00"
  - service: script.zwave_test_network
  - delay: "00:01:00"
  - service: script.zwave_test_network
  - delay: "00:01:00"
  - service: script.zwave_test_network
  - delay: "00:01:00"
  - service: script.zwave_test_network
  - delay: "00:01:00"
  - service: script.zwave_test_network
  - delay: "00:01:00"
  - service: script.zwave_test_network
54

Change your automation to call the script.

- id: '1535832688944'
  alias: Fikse døde noder
  trigger:
    platform: mqtt
    topic: ZWaveTermostatAv
  action:
  - service: script.fikse_dode_noder

Let’s see if it still terminates gracefully.

55

It seems to error out in a completely different way, but this time it happens fast:

Invalid config for [script]: [zwave_test_network] is an invalid option for [script]. Check: script->script->script->zwave_test_network.

I will try to run the script when Z-Wave has started up to make sure it works then.

Edit: Sorry, no. It seems I’ve made a mistake again, copying the code, because I see that Script could not be set up! I copied in this:

script:
  zwave_test_network:
    sequence:
      service: zwave.test_network

OK, I think I see the error. More like this:

zwave_test_network:
  sequence:
    service: zwave.test_network

And this errors out in the same way as the MQTT automation did.

Edit again: OK, I think I got it right this time… The automation:

- id: '1535832688941'
  alias: Fikse døde noder
  trigger:
      platform: homeassistant
      event: start
  action:
  - delay: '00:01:00'
  - service: script.zwave_test_network

The script:

zwave_test_network:
  alias: Teste Z-Wave-network
  sequence:
    service: zwave.test_network

Error executing script script.zwave_test_network. Service not found for call_service at pos 1: Unable to find service zwave/test_network

So it seems it errors out the more graceful way when I go via a script! :slight_smile:

1 Like
56

Nah… still as confused. :wink: I get both error messages when doing it this way. I still get the task exception, only this time it’s a lot longer:

Thu Jul 25 2019 18:28:40 GMT+0200 (sentraleuropeisk sommertid)
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 1150, in async_call
    self._execute_service(handler, service_call))
  File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/core.py", line 1172, in _execute_service
    await handler.func(service_call)
  File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/script/__init__.py", line 119, in service_handler
    context=service.context)
  File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/script/__init__.py", line 183, in async_turn_on
    raise err
  File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/script/__init__.py", line 178, in async_turn_on
    kwargs.get(ATTR_VARIABLES), context)
  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

This is without any references to the service itself in the automation.

57

Did you try the test I suggested? Namely changing the MQTT-triggered automation to call a script (containing the service call) as opposed to calling the service call directly. The goal was to prove the automation’s trigger-type has nothing to do with whether or not there’s a graceful termination.

Anyway, whether you did or didn’t doesn’t matter. Ideally, the zwave integration should signal you when its ready as opposed to polling it. I’m not sure how such a mechanism could be created.

58

Yeah, sorry. I did. The post got so messed up by my errors in trying to code the script stuff. When calling the automation from MQTT, and have the automation call the script, it works as when I have the network test in an automation and call that directly from MQTT. And I agree that it should signal me. Finity seems to have a way to do that in this post: Any sneaky way to check and send over MQTT if the Z-Wave network is still up and running?

So I’m waiting for him to answer back, he showed the result, but not the actual automation code.

59

OK, so the z-wave integration does in fact fire an event when the network is ready. That’s good news because it means you can achieve your goal (run a z-wave test ASAP after startup) without relying on this problematic polling technique.

Just modify @finity’s automation to execute the zwave.test_network service when the integration is fully up and running. It would be as simple as this:

- alias: 'Test zwave network when ready'
  trigger:
    platform: event
    #  event_type: zwave.network_ready
    event_type: zwave.network_complete_some_dead
  action:
    service: zwave.test_network

EDIT
Updated event_type.

Mastiff discovered an event that is a better fit for the given situation and it’s called network_complete_some_dead (see post below).

60

What is the benefit of running the test_network service? what information does it provide that the user has access to to provide a notification or take some other action in response?

EDIT to add:

I got a bit confused as to which thread I was replying to. I didn’t realize these two threads were related. I thought I was replying to you in the other thread until I scrolled up to see that it was completely different. :crazy_face:

However, that question remains. Where can the user find the results of the test_network service apart from probably the OZW logs?

61

Apparently this:

The goal of this (now very long) thread is to tell the z-wave integration to re-run its network discovery shortly after it has initialized itself at startup.

The chosen approach, which has proven to be problematic, is to poll the z-wave integration (using delays) where each poll calls a z-wave service that won’t exist until the z-wave integration initializes fully. Naturally, calling a non-existent service will result in an error. Most of this thread has been about how this error is handled by Home Assistant (gracefully or not). Basically, after dozens of posts, we’re off in the weeds …

The simpler approach is not to poll but to be advised when the z-wave network is ready. Z-wave’s ‘network ready’ event serves that purpose.

62

Ah, OK.

glad I didn’t read the whole thing then, I guess.

And, glad I could help…? :thinking:

63

Consider yourself lucky; it’s a long trip down the wrong road.

1 Like
64

Yeah, this road is a lot better! It’s not dependant on how long the Z-Wave network takes to get ready. I still wonder why there’s such a difference in how HA reacts to an MQTT message and a delay timer firing exactly the same service, but I guess some mysteries are not meant to be solved… :wink: Anyway, thanks for the help, I’m implementing this now!

65

Your not listening to people trying to explain.
When your triggering it with Mqtt, it is triggered separately each time. So each time it’s triggered you get an error.
When you are triggering it from start, it’s triggers once at start. Delay isn’t a trigger it’s part of the action.
If an action fails at any point the next part won’t happen. So you only get the one error.
Does this make sense? Is pretty simple really
Anyway much better to wait until the network tells you it’s ready.

66

It would make perfect sense except for one thing: It’s not the same error. The MQTT one is a regular service not found, which of course is to expected since the service doesn’t excist yet. The delay one is “Task exception was never retrieved”. So for some reason the two ways of triggering the same code is handlet differently. But I’m done with this, as the “some mysteries are not meant to be solved” should indicate.

67

As I have said in the thread with the setup @finity has, it didn’t work for some reason. The event dit not come. But I found a better one: zwave.network_complete_some_dead That means that the code will only be run when there are dead nodes after startup. :slight_smile: So problem solved. Again thanks for the help, all of you!

Edit: This is the code, which both runs the service and sends an MQTT message telling the main system that a node was dead on startup:

  alias: Z-Wave-nettverket har døde noder
  trigger:
  - platform: event
    event_type: zwave.network_complete_some_dead
  action:
  - service: mqtt.publish
    data:
      topic: eg/Z-Wave-nettverket har døde noder
  - service: zwave.test_network
68

I’m glad to hear that the event-based approach worked for you and you found an event that fits the situation (network_complete_some_dead).

Be advised that although spaces are allowed in MQTT topics they are not considered to be a good practice. See the Best Practices section of HiveMQ’s MQTT Topics and Best Practices.

69

I’m not sure why having a dead node would prevent the network ready event. I’ve had a dead node for a few weeks now (because the light switch for a wave light bulb keeps getting turned off…but that’s another story…) and my automation for the network ready indication works fine.

If you aren’t getting that event then I would suggest figuring out why because you are apparently having other issues other than a dead node.

70

A, syncronized posting. Sort of like syncrhonized swimming, but without the swimsuits. At least I’m not wearing one…

@123 Yeah, I know. But I have built my whole MQTT system with descriptive messages (and the Norwegian special characters æøå), and it always work.s :slight_smile:

@finity Yeah, I find it weird too. And I don’t think that the dead nodes are the reason, but the door lock has been dead for almost two weeks, I don’t know if that’s the reason. I will check this when I get that working again, and if it doesn’t help I may find the time to dwelve deeper. Weird that both network_complete and the one with the dead works. The same goes for network start, so it seems the ready message is the only one not working. Can this be something with versions of Home Assistant? I have a newly installed lastet version (at least it was the latest version a week ago).

71

I doubt it. I’m on 96.3 right now and it’s working. I don’t remember seeing anything changed related to z wave in a while.

72

@finity Then I’m at a loss. I have another Pi 3B+ with Stretch and a Z-Stick running stability control. Basically it turns off the power and turns it on again if one of the main Pi’s in the system freeze and doesn’t react to a soft reboot with my special purpose Python script, which happens maybe once a month for a random Pi. This was installed monoths ago and has no connection what so ever to the one I’m running the main Z-Wave network on, which is a P4 with Buster. The only thing that’s similar is that they’re both installed in the Python virtual environment (in the recommended way, step by step), and they both have a V5 Aeon Z-Stick. I tried this code on that one:

- id: '15358326889'
  alias: Vise Z-Wave-nettverket  klart
  trigger:
  - platform: event
    event_type: zwave.network_ready
  action:
  - service: mqtt.publish
    data:
      topic: driftskontroll/Z-Wave-nettverk

And it does not get triggered at all. As you can see I have removed spaces in the MQTT message and otherwise made it as generic as I could. Nothing. It does work when I trigger it manually. Are there other differencies betwen our systems, like are you running in a container, or are you using another type of Z-Wave device than the Aeon Z-Stick or even another version of the stick?

Edit: I tried this code:

- id: '15358326890'
  alias: Z-Wave-nettverket har døde noder
  trigger:
  - platform: event
    event_type: zwave.network_complete
  action:
  - service: mqtt.publish
    data:
      topic: driftskontroll/Z-Wave-nettverk2

This triggers when all the nodes (four switches, five with the Z-Stick) have been marked as ready in the GUI. So the zwave.network_complete event comes every time, while the zwave.network_ready never comes, not even after waiting 20 minutes.