My great white spot in automation is Z-wave. Well, after a discussion with my wife “we have agreed” (hrm) not to upgrade to a RPi4 at this point but to stay with the Pi3. Which after some grumbling have lead me to look a bit more objective on what is working well and not. Tbh, most works satisfactory - except for my Z-wave where there is obvious lag and intermittent fails. So I figured it is time to do something about it.
I started by taking a look at the network view in HABmin and sort of choked over what I saw. I think it is safe to say that the mal, if I read it at all correctly, supports my notion that my Z-wave works less than perfect.
So. I would appreciate any pointers where to go to get both knowledge on Z-wave overall and troubleshooting mess specifically.
I am running OH2.4 stable with the usual Z-wave-stick from Aeotec. It’s all on an Openhabian based RPi3. Most nodes are battery powered and, with the exception from that poor 30, which is out in the garden, spread fairly evenly across a two story house.
Note that this is a “before I start troubleshooting myself” kind of input, in the hope of being more efficient in attacking the problem later today.
Battery nodes are asleep most of the time to preserve battery life and don’t provide the meshed network. Only mains powered devices extend the zwave network and provide a meshed network, so this could be your initial problem.
Thanks a bunch for the links! And the tip. Didn’t know that battery nodes don’t act as mesh links, but it certainly makes sense. I will include mapping mains connected nodes specifically in my troubleshooting. It sounds quite possible that I have a “hole” in the net somewhere too far away from the relatively few powered ones.
I have no experience with this myself, though I´m running z-wave as well with just a few devices. But I wonder if it would be an good idea to add one or two z-wave repeaters, when having a rather big network with mainly battery devices. The repeater should then act as a mesh routing device given a much better and direct way to the controller. At least thats probably the way I would try sort things like these.
Your network doesn’t look good to me. Many unidirectional links from battery (red circle) AND mains powered (blue) devices to the controller (node 1).
Essentially the controller almost always has to route across either of the nodes 4 or 6 and the return path has to be through nodes 3 or 4. So each message takes at least one hop and sometimes two or even more, and those named nodes can become bottlenecks.
No bidirectional links from the controller to most of your nodes (bottom line), I therefore doubt it works unidirectional as the picture indicates. Many nodes believe they can reach the controller directly but as the opposite direction does not work that may be wrong and if so causes timeouts+retries because that (bad) direct route is always tried first.
I believe you need to heal your network and eventually even physically move the controller to improve the situation. Normally the controller should be able to reach at least the majority of nodes directly.
@chris correct up to here?
Please could you also explain what it means if nodes are along one horizontal line - does it really mean each node has two bidirectional links to its direct neighbours in the graph only?
Also, I’ve been searching for this sort of explanation of the view ever and only found some forum posts to explain parts only. Would you mind to point us to the “official” docs (if any)?
Battery nodes are asleep most of the time to preserve battery life and don’t provide the meshed network.
I must question that a bit; the only two nodes really providing to the mesh are nodes 4 and 7… which are both battery powered (and at that, Node 4 is not even inside). Or am I missing something?
The thing to remember with that network node view, is that it shows neighbors, not the actually used routes. So it only says that node x sees (and have been seen) by node y.
I’ve been told by Chris that there is essentially no difference between a repeater and any other mains powered devices in terms of network routing. You would be better off getting a mains powered device that can actually do something so you at least have the option of doing something useful. A repeater will just be a box plugging up an outlet.
But indeed, more mains powered devices should help the network by giving more routes to the controller.
Awhile back, I had missed commands and delays on my relatively small zwave network. It turned out that only one mains powered device had the controller listed as a neighbor. So I added a repeater (this was before I learned the above) in what I thought was a good location and that gave two paths to the controller and all my problems disappeared.
I know. But often af repeater are cheaper. And if you dont need the device itself an repeater could do the job.
(Most people could probably always need an outlet I guess. So it´s a simple question of money, if the outlet is cheaper ).
Does anyone know howcome I get an empty network view in habmin for my z-wave network? It has been working before (i think it was back on openhab 2.4). But now I´m on openhab 2.5M2 and it doesnt show anything. All things and controller are online and working.
jwiseman
(Mr. Wiseman (OH 4.2 Snapshot on Pi4))
16
I have 4 Aeotec repeaters in my house (don’t need anymore zWave devices hence went this direction). They cover 3 floors and the garage for mailbox and garage door devices.
