C8-Pro
Platform: 2.4.3.175
Z-Wave-JS (legacy is turned off)
Rogue device is a Zooz Zen76 >> 0x0071
I have one device with a strange route back to the hub. It is quite possible the node has a ZWave "RF hole" but I don't understand why the many hops back to the hub when the first hop to node 25 has a direct shot to the hub? How and who decides how these multi hop routes are built? Can they be reset or over run? Clearly the chosen route isn't the best path.....
rebuild route then refresh. See if it is better.
Technically, yes, per the Z-Wave Spec, but this Applicaton Routing, is not exposed in HE, which does the basic source route (with 5 routes), per the Z-Wave spec. As @TArman nodes, your only real chance of changing this in HE, is to rebuild the route, and as long as the route is working, then it's likely going to stick with that path. You can try physically moving the device, to potentially force a link failure, and then it will try one of the alternate paths, or search for a new path with explorer frames.
Depending on the device, you can also try adding the endpoint as a LR node, then it's just a direct path, with no routing involved at all..
For some good background context is called out by SiLabs here (see P5)
And the more advance APR topic is called out here
Thanks to both. I am going to try to repair is as an LR node since it is LR capable. This will be my first LR device so fingers crossed. It hadn't occurred to me to try LR but if it works I have a couple devices it might be a good solution for..
There is something amiss with how the mesh hops are created but I don't expect a fix for that is trivial or forthcoming. So LR probably my best option.
I find that most of the time, when I reroute, it picks a more direct path, even if the current path is working adequately.
something is botched now as it won't complete a rebuild route now. Stuck for 30 minutes and won't complete..... anyway going the LR route....
May be time for a shutdown with 30 sec power off, just to get the Zwave radio into a known stable state, before doing too much in the way of changes - YMMV 
I have found that if you aren't experiencing issues, worrying about routes on the Z-Wave Details page is an unecessary use of your worry-budget. 
And FWIW, if you do a Rebuild Route you won't necessarily see a change right away.
Good advice from @GuyMan to do the shut down/pull power/30s/restore power dance before you do anything else.
OK moved the problem node and a couple other fringe units to LR. They seem to be fine on LR link.
I must say the LR inclusion process is a tad cryptic and poorly documented. I had to experiment a few ways before getting it right. Regular Z-Wave pairing is super simple. Smart start seems anything but. I still don't know how they paired as LR as I never got to a prompt to select regular pair (mesh) vs LR... fortunately they self selected LR.
Final thought: Changing a couple of the poorer performing nodes to LR has improved my large All On and All Off rules. They tended to get hung up and stumble due to the flood of ZWave traffic and I assume hops and retransmissions. It seems to be better with three nodes moved to LR.
More on this. There is definitely a problem with how ZWave devices decides on multi hop routes. I've been chasing this issue for weeks now and its obvious to me. I suspect this is deep in the ST Micro code and how the mesh is managed.
I created an app to sequentially turn on a large number of lights. It waits until the ACK of the prior device before sending the next command in the list. The idea was to avoid flooding the ZWave network with a bunch of near simultaneous commands. The app writes to the log the time duration from command sent to ACK for each device and then the end to end duration of all the devices at the very end. Large variation of ACK durations even those with direct hops.
Below is the ZWave entry for Zooz 77 800 series dimmer. It is installed about 6' from Hubitat. Note the 3 hop route. This multi hop is clogging the network with knock on messages that aren't required as the device should direct connect to the hub. I have seen this extensively in this network on many nodes. So much so I coined the term "Tortured Route".
I also can't reconcile the duration variation across devices. FR Nook Lamp (9013ms), Powder Rm Hallway (8232ms), and Foyer Main (7860ms) are all direct routes to the hub. RSSi and PER is nothing unusual. I cant fathom why the long delays..
ZWave Device table:
full system logs for same sequence:
Download the Hubitat app
