As far as I know, a Z-Wave network is only built up by things that are not battery-operated. That means only devices that are connected to the power supply route messages between the controller and more distant devices.
If so, I do not understand the network structure in my network. As you can see in the attached network plan, the controller (node 1) only has two neighboring nodes (node 3 and node 9). This also agrees with the zwave_neighbors entries of the nodes. Node 3 is a smoke detector and node 9 is a heating thermostat, both are battery-operated and also significantly further away from the controller than five other mains-operated nodes.
What is wrong here? Can battery-operated nodes route messages after all, or are the neighborhood entries in OpenHAB 3 incorrect?
The network consists of ALL devices that are included into controllers with the same network ID. Even battery operated devices.
Battery operated devices do not route messages, though.
Your network diagramm may still be correct under the assumption that the controller not necessarily has ID “1” in all cases. Or you have a second controller?
No, I’ve only one controller and it has the node id 1. So either the diagram is wrong or battery devices are routing.
Another odd thing is: If the true value of the zwave_routing property means that the device can forward messages, all of my cordless devices can forward.
Do you’ve battery devices with a property value equal false?
Please remember that the diagram shows neighbours - not routes. Battery devices will show links to neighbours - it does not mean that they are used for routing, and they aren’t.
That is not the meaning of the zwave_routing property. It means that they devices can participate in routing - it doesn’t mean that they will route messages. Again battery devices do not route, but they are able to send messages that need routing, and therefore report that they support routing.
But then the routing neighbours of node 1 are missing. All of the nodes are working as expected. Therefore, if you are right, there must be a path from each node to node 1 which has only routing nodes in the path between both nodes. This is not the case in my network.
But not necessarily a direct neighbour path.Ig Nodes 25 & 9 act ac routers your network should be OK. Z-Wave is a mesh network, not a star network topology.
Node 25 isn’t a direct neighbour of node 1. Node 1 has only the nodes 3 and 9 (the content of the zwave_neighbours property of node 1 is “3, 9”) as neighbours and both are battery devices. Therefore in my mind at least one of them must be a routing node.
I think, that also in a mesh network, there must be a path between each node and the Z-Wave controller node (node 1 in my case). Each of theses paths must consist of only routing nodes (0 to 3) and no non routing nodes between its first and its last node. Only the last (end) node - at the opposite side of the controller node - of the path can be a non routing node.
I was just going by tour diagram. Does 25 see 1 as a neighbour?
you know, I’m starting to wonder what the point of the zwave network map even is. I mean it is kind of cool looking but seems to cause a lot of unnecessary confusion
It would be nice to have a feature to move the nodes by mouse for such cases.
No, node 25 has a lot of neighbours, but not node 1 and I’ve just noticed, that node 25 is also a battery device.
I don’t know for sure, but I think that the map is only a visualization of the zwave_neighbours property of all nodes. I’ve checked some, but not all properties and find no node, which has other neighbours in the map than in its property.
So in my case either some zwave_neighbours properties have wrong vales or it isn’t true, that no battery device is able to route messages. If the second is true, I fear that my network is not optimal because battery devices should at least not be as fast and responsive as devices connected to the power supply.
So you both agree with Chris.
The map is part of the UI and not part of the binding. The UI was developed by a different developer. If you submit an Issue or PR for the WebUI on GitHub i am sire it would be considered.
So to summarize it again briefly. You are all absolutely certain that battery-operated devices can never route messages. Which means that both the network display and the contents of the zwave_routing property are sometimes incorrectly, at least in the user interface.
If so, I’ll create a corresponding issue on Github (openhab / openhab-webui).
Many thanks for your help.
The Network Display correctly shows neighbours as designed. The usefulness of such a display is another question. Personally I never used the z-wave display in HABmin either.
But either the network display is wrong or battery devices are able to route.
Or do you see a third alternative?
The display just shows neighbours and has nothing to do with routing.
Exactly, I assumed wrong initially too (I’m just a Z-Wave user) but @chris enlightened me then: Increase the polling delay after a command beyond 15 seconds · Issue #1507 · openhab/org.openhab.binding.zwave · GitHub
So I agree the network map could be confusing for newcomers but it’s basically the equivalent of what was in HABmin. I don’t know how it could be made less confusing, though.
The map shows the successful returns of neighbour update calls and only shows neighbouring nodes found during this process.
The neighbour update process uses lower than normal power so it is possible that all neighbours do not show though those with the stronger signals do normally show. It is also possible that calls can time out or nodes can be busy and not report back during the process so that the map is not complete.
You can see a more accurate map of neighbours in pc controller 5 which you can download from Silicon Labs. Even this will not give you any information on the actual repeaters used.
The easiest way to see the actual repeaters being used is a zniffer but you can also see the saved routes from pc controller 5.
You’ll note that you have a yellow ring around nodes that have the zwave_listening property set to true. To me it meant it was the nodes that weren’t battery-powered and therefore allow routing; but I’d be glad to have a confirmation of this.