Zwave Routing HELP

Is there a way to influence the routing on a zwave device and/or can someone tell me if I am reading the chart wrong? I have 4 zwaves going from the hub to repeater C then to the end point zwave device (o1 > 0c > 0a). That can't be good as the hub is located centrally about 7ft off the ground and that 0C device is for the light on the table below it and hidden on the floor in a corner. Its an extra hop and I dont suspect a good one given the location and the reported kbps. Is there a way to ignore that other than going out and getting a zigbee device?

Any reason (other than the zwave motion sensors) that these items don't report any mapping such as item 14?

Is anything not working? Speeds look fine, 40 is common for me, all my devices respond quickly and work w/out issues.

Z-Wave Plus devices (if any of yours are) will settle their own routing over time, so usually best to leave them to it.

The first rule for the Z-Wave Details screen is don't look at it unless you have an actual problem occuring - things not working big delays, etc. As they say, don't look at the man behind the curtain. :slight_smile:

2 Likes

Ha! Only thing not working is the dashboard.

Still testing but for the most part things seem to go on and off correctly. The dashboard keeps getting stuck though on devices (sending mode on devices) which means I can’t turn things on and off without refreshing and then retrying. My motion devices and simple automations seem to be working just need to rebuild them all.

TL, DR: From what has publicly disclosed, you have no influence on Z-Wave routing.

Unlike the Z-Wave application layer, PHY and MAC layer specifications, Z-Wave's networking layer spec hasn't been publicly released-- per the Z-Wave Alliance this was expected to happen 2H 2020 (see Silicon Labs and Z-Wave Alliance Expand Smart Home Ecosystem by Opening Z-Wave to Silicon and Stack Suppliers - Z-Wave Alliance ); AFAIK that hasn't happened yet. So the reason why nobody seems to know exactly how Z-Wave routing works is because thus far the details are proprietary. That hasn't stopped people from reverse-engineering it, especially those in the network security business.

The best description I have seen of how classic Z-Wave routing works can be found here (skip to section 4): The Z-Wave routing protocol and its security implications - ScienceDirect. Unfortunately it omits any discussion of explorer frames which were added in later Z-Wave versions; these allow devices whose tables contain no working primary or alternate route to obtain one-- but it is bandwidth intensive, essentially flooding the network for a period of time and not intended as the 'front up' mechanisim for route discovery/maintenance. That is the job of the Z-Wave controller, since it (and not the peripheral Z-Wave device) maintains the list of all adjacent nodes.

A few points stand out: Routes are computed by the Z-Wave controller (not the device), distributed to each node, and maintained in a 'source route' cache of target nodes on each device. More than one viable route is computed to allow tracking the last working route as well as an alternate path in the case of failure of an intermediate node; if the path through a given route is not acknowledged, after three attempts an alternate is tried before giving up. For routing-capable devices, an additional cache of 'backbone routes' (paths from the device back to the central controller) is maintained. If a routing node hears a route request from another node, it can transmit the backbone routes to a potentially stranded node with a stale or corrupted cache as a recovery mechanism.

Aside from the case of failed route recovery using bandwidth hogging explorer frames, the only routing function performed by a non-controller Z-Wave device is to report a list of its adjacent neighbors to the controller on request. This is the mechanism of Z-Wave repair, implemented with the NL commands described in the article in sec. 4.2.3 in the article. From the neighbor list reports, the controller maintains the only complete node adjacency table, then computes and distributes lists of routes to each node.

Regarding route prioritization, not much seems to be known. Section 4.2.1 in the article indicates that there is a byte field in the source route data structure that sometimes prevents a distributed route from being used by a recipient node; in other cases the route is given a lower priority and only used when other routes have failed. In any case it is the controller that determines route priority, not the device.

Unfortunately with the unknowns regarding the networking layer, combined with teething issues of the 700 series (RSSI reporting and 'sticky' Last Working Route issues -- see How to Upgrade Your 700 Series Project from SDK 7.12 to 7.13 – DrZWave ) the odd routing observed probably shouldn't come as a surprise. Whether it is working as intended or not seems to be unknown, as well.

9 Likes

Very helpful and comprehensive. What would be the reason a device seems to turn on via automations but does not report back its route? I say seems since its giving me headaches with my dashboard.

At least the device with node-ID 0x14 is supposed to report back it's status.
Remember I recommend in one of your other threads to turn on debug logging for the affected devices to see where the communication gets stuck?
Also note, that the Z-Wave Details view will be updated every 30 minutes only.

1 Like

Thanks. I don’t recall seeing errors but I’ve been doing a number of things to try and resolve. I’ve shut off all of the energy reports, tried making sure all the other devices that had errors get moved if possible and will try moving this one to see if it helps. It’s literally the same as, right next to and on the same power strip as another one which is making it hard for me to understand why it doesn’t and the other does.

I will pay closer attention to the logs tonight after automations stop.

Very concise and understandable. Thank you for taking the time to put this up.

1 Like