-
Hi - I'm trying to understand the route selection of my nodes. Here's one example. Take a look at 3d Printer down in the bottom left. What route should one expect it to take back to the controller? My guess was 3d Printer -> Garage Extender -> Controller. But that's not the case. Rather than taking the short hop from Garage Extender to the controller over a 100kbps connection, it chooses to do an extra hop over a 9.6kbps connection, then do ANOTHER hop. I know the standard wisdom of "Let the mesh do it's thing because it accounts for things that aren't obvious", but I'd like to wrap my head around this. Also, is it a function of the zwave protocol, or the node-zwave-js implementation that determines these routes? Finally, this isn't purely academic. I've been struggling for a year with poor zwave performance and I'm trying to finally dig in and figure out if I can make it better. Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Route selection in Z-Wave is strange. It happens in the controller firmware, and from what I could gather, it attempts to spread routes over the network. However, this algorithm only takes into account whether nodes are neighbors, not how good the connection is. It should prefer shorter routes, but anecdotally this isn't always the case. When a route fails, the next one on the list is tried. If that works, it will stick, regardless of how good it is. When everything fails, routes are automatically determined by flooding the network with requests and seeing which one reaches the target. That route is then kept until it fails again. Aside from that, I always recommend working through https://zwave-js.github.io/node-zwave-js/#/troubleshooting/first-steps when there are connectivity issues involved. Not sure if you've done that before. |
Beta Was this translation helpful? Give feedback.
Route selection in Z-Wave is strange. It happens in the controller firmware, and from what I could gather, it attempts to spread routes over the network. However, this algorithm only takes into account whether nodes are neighbors, not how good the connection is.
It should prefer shorter routes, but anecdotally this isn't always the case.
When a route fails, the next one on the list is tried. If that works, it will stick, regardless of how good it is. When everything fails, routes are automatically determined by flooding the network with requests and seeing which one reaches the target. That route is then kept until it fails again.
This might have very well been the case here.
Aside from …