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.
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… Anyway, thanks for the help, I’m implementing this now!
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.
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.
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. 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
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.
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.
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
@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).
@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:
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?
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.
When this is triggered, all awake nodes have been queried and sleeping nodes will be queried when they awake
Perhaps there’s a node that the controller considers to be awake but it fails to respond to the controller’s query. The controller continues to wait for the response and won’t generate a network_ready event until it receives it. Meanwhile, all other nodes have responded and the network is 99% operational … but there’s no official network_ready event issued.
Everything seems to point to a festering problem in your z-wave network. Do you have any tools to examine/debug it?
Thanks, but as I said this happens for both my networks. The simplest network with four switches and a Z-Stick has never been changed. It was installed and has no phantom nodes or any problems at all. The switches work every time, nothing is dead on startup, and there are no error messages that I can see.
I can’t really see how that should be possible that there’s the exact same “festering” problem in two different and totally separate installs that has nothing in common except for the virtual environment installation and the Z-Stick V5. But of course I’d like to find out.
What kind of tools are you thinking about? I don’t have anything installed except for the standard Hass OZW stuff. I have been using OZW CP earlier, but that was on an earlier implementation of the main system, before I did a full reset of the Z-Wave devices and Z-Stick and a new installation.
I’m running non-hassio HA in Docker but I would be highly surprised if that would be the issue. But it does seem strange that it’s the same on both of your installs using a venv.
and I’m using the same Aeotec Z Stick Gen 5.
It might be worth your while to file an issue on the HA github.
@finity I just tried on my third Z-Wave-network, at my cabin. That didn’t say “Ready” either. Again a separate network, this even with a different update schedule for Home Assistant than the ones in my house. But the Z-Stick V5 and the virtual environment installation is the same. There is a dead node there (not in use at the moment, but will be again), so I got the “complete with dead nodes”. If you have the time one day, maybe you could see if you get a “ready” with dead nodes, if you pull a wall plug or something?
Aha, sorry. The thread is getting so long even I am getting confused as to who said what… OK, so that’s not the thing, then. In principle that should mean that the main difference between my three different setups, which do not send ready, and yours, which does, is that you are using a container, while I’m running a Python Virtual environment. Even if that shouldn’t make a difference, I’m starting to think that it may.
Missing “ready” on one network would be an anomaly in my system, but with three systems with different network makeup, different installation times and different types of devices there’s only the Docker/virtual environment installation that’s common in my systems and differs from yours. If that’s not it, then it may be because I have Telldus TZWP-100 Plug-in Switch on all my systems.The swhitch is the only device common for my three setups (one of them har four of those switches and nothing else). So assuming you don’t have any of that, this would be the only other possibility, with something in that type of switch that prevents the ready message.
Put in a bug report. Even if it isn’t a real bug then maybe someone there can help you out.
Or if you want before you do that you can go to the HA discord chat and see if anyone there can help you. I personally really dislike the discord chat format but I have gotten a bit of help there once.
Chatting is for kids. I’ll put in a bug report tomorrow. Even if I don’t need actual help with this (my automation is perfectly served with the network komplete with dead nodes, but it should probably be fixed.
Anyway, thanks for the help, I’m implementing this now!
So problem solved. Again thanks for the help, all of you!
