Is it? What leads you to believe the service is actually executed when called that way?
Perhaps all it does is fail silently when calling the unavailable service.
Oh, sorry! I was so preoccupied trying to find out what was going wrong that I didnât see that suggestion! 
Iâll try that at once, thanks!
Iâm not saying that it works, Iâm saying that it doesnât lock up the automation when triggered by MQTT. I can fire it again and again with the same âService not foundâ message.
Can you explain how youâre calling the service via MQTT.
That works, of course. The thing is that I think this is just a temporary thing, since one of the nodes are out (ID Lock that died, only the lock itself, the Z-Wave chip works and will be back in the next lock I get). I think it starts up a lot faster when it doesnât have any problems.
easy way to test that 
take it out for nowâŚ
@123 I was piggybacking off an MQTT signal that goes out every time a temp sensor in a room with a Z-Wave thermostat tells the main system that the room is over the set temp, wich of course happens every time one of the sensors fire in July. 
So like this:
- id: '1535832688944'
alias: Fikse døde noder
trigger:
platform: mqtt
topic: ZWaveTermostatAv
action:
- service: zwave.test_network
in the 7 minutes the startup takes for now this can fire the automation 20-30 times and still only get the âService not foundâ and then no other problems.
Oh, you misundrestand. It is taken out, so the node is dead for now. I think OZW is looking for it for a long time, being a battery node.
ok sorry, as said, I donât have the zwave node in my HA setup. Of course I meant taken out the logical (software) bit, not the hardware node itself.
Using another Zwave setup parallel to HA, I appreciate the issues you have, and send you my best wishes 
An automationâs action is functionally equivalent to a script. The two share the same rules for content and structure. In other words, calling a service from within a script or within an automationâs action is no different.
I think the only operational difference in your case is because the automationâs action consists of only one service call. After the call fails it causes the automation to abort. The action only has that one service call and nothing else left to do ⌠so it would appear the error is handled gracefully. Itâs not. It just happens to coincide with the end of the automationâs action.
In contrast, your script contains a sequence of service calls and delays. It executes the first delay then fails after the first service call. However, thatâs not the end of the script; it has more steps in its sequence. They wonât get done because, as with the automation, the failed service call causes an abort.
So comparing the one-call automation to the multi-call script is a false equivalency. Calling the unavailable service causes an abort that is only perceived with the script because it has more things left to do.
There isnât much software, ony a lock and unlock that goes to the HA service, and a battery check. But that only happens every night at 20.00.
@Mariusthvdb that worked, thanks! it doesnât change how it reacts to it, thereâs still the âTask exception was never retriedâ after one minute (which isnât there on an MQTT trigger, then I only get "Service not found " within a second or two). But the rest of the commands fire even if the first errors out!
@123 It doesnât seem like thatâs the reason. I still get the same error with this code, and thereâs no actions or anything after the first delay and call:
- id: '1535832688941'
alias: Fikse døde noder
trigger:
platform: homeassistant
event: start
action:
- delay: '00:01:00'
- service: zwave.test_network
So there actually has to be a difference in how the core handles calls from MQTT and the delay. Maybe because the delay is using internal code, while the MQTT is a command that comes from outside?
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
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.
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! 
1 Like
Nah⌠still as confused. 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.
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.
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.
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).
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. 
However, that question remains. Where can the user find the results of the test_network service apart from probably the OZW logs?