Dear readers,
I want to improve the zwave routing, some routes seem very long, from the second floor to the attic, to the ground floor, surely not the shortest route. In an attempt to fix this I tried the “heal” command, in the developper tools.
In case of node 47 (a pir sensor) after the heal the route to this device is via node 128. But node 128 does not exist. Not in the routing table and also not in the devices overview. And after the heal, node 47 cannot be reached anymore, which is of course to be expected.
Any ideas how homey has figured out that a non existing node should be part of the new route ?
And in my search for routing issues, I came across a zwave antenna mod that seemed to help, does anyone have a link how to do this ?
Thanks for your ideas
Special read: Limited range during pairing
Also note the big “Unknown” in front of the route, indicating that Homey doesn’t know the last taken route.
Yes the unknown in the routing tablet is not very encouraging. But I wonder why homey would need a routing table in a mesh network. I would expect that homey just sends the zwave command and that the nodes themselves make sure the endpoint is reached. But it looks like homey has some form of routing control if it needs a routing table. I am no expert in the zwave protocol, any insights much appreciated.
This routing table is only a snapshot of the fastest last message, not every message that is send through the mesh, as yes Z-Wave is a mesh network and a message can (and will) go through different routes with every message.
Also why the routes that are known are called “Last working route”, as it was the route that worked/was used the last.
The actual full mesh network is not shown (anymore) on the developer tools for a long time now.
Do you just want to know the possible background of this problem, which I definitely can’t answer, or do you also need help to get the PIR working again?
The antenna mod can extend the Z-Wave range and you may be able to save a few repeaters, but the Unknown Node problem would probably still have occurred.
Hi, I have recovered the PIR by pulling out the battery and inserting it again. Now it has a route which does not have non existing nodes, and it is working again.
But because I have issues with slow zwave devices, timeouts, and nvm errors in the backup, I was looking at the background how the zwave mesh network works, and if homey even has a form of control.
I bought my homey second hand, it already had the Wifi and Zigbee antenna mods, this weekend I want to mount the zwave antenna mod.
My homey has worked fine for about 2 years, but the problems occured at some point a few months ago, I cannot define the root cause. App performance impact is almost none, I have disabled most of my flows, I have added some zigbee temperature devices that report every hour. So I am thinking that the 868 Mhz band has become more occupied because perhaps some neigbours have installed zwave domotics, what could cause interference.
Also I have a large house, and the homey itself and some devices are in rooms I do not heat, perhaps the electronics are a bit off the specs when operating at 8 degrees.
First attempt is the antenna mod, see what that delivers.
Before homey I had a Zipato, I switched to homey because it supports more devices and protocols, and I Iike the open community support, and making flows and java scripts is much easier. But the Zipato had an external antenna, and never had any connectivity issues.
As described earlier in my topic, I see strange routes in the zwave routing table on my homey. Not only sometimes non existing nodes, but now I have encountered double nodes. See node 12 being used twice, which is a range extender. I wonder how this table is made up, based on what information from the network. As Caseda stated, the table only shows the last used route, so you can wonder what is the use of the table. The shown route may not be used the next time, and an unreachable node may be reachable using another route, which I have indeed tested, unreachble nodes according to the table can be switched on/off from the devices screen, so are reachable. What is missing in this tooling is a kind of tracert command, to see which hops are taken, and the delay per hop. Otherwise finding the root cause for zwave delay issues is a needle in a haystack, trial and error.
