One axis is from the Hub's point of view.. what it knows are direct reachable neighbors.
The other axis is what the hub received from each device telling the hub what neighbors they could reach.
Devices that are known to the hub as a result of some previous inclusion that are unreachable are red in both axis. The hub can no longer reach it directly AND none of the devices have found it as a neighbor. A grain of salt should be included when reading this for battery devices. They may not have been awake during the poll of neighbors.
The hub then builds the routing table and distributes it.
If you have a problem with a device.. perhaps there's a clue in your mesh that shows in the topology map. Devices with 2+ neighbors can communicate via multiple paths. You cannot tell from the Topology Map what decisions are incorporated in the route table. But having two or more blue intersections for every device will tell you how close to "healthy" your mesh is.
So you don't have to go all blue necessarily.. I was worried a bit because mine looks really sparse as well but appears to be functioning normally. Of course with more devices... more area to fill.
Yes! and Yes!
lol.
From brief read I am sure when I re-red and think about it , it'll put the pieces together for me.
I've got a few devices taking some really weird paths around the house. Everything is working, I had to raise up my outside GE Z-Waze plugs so they'd connect better.
Do devices re-route naturally over time as environment change or is it best to repair the whole network?
The presentation states that if explorer frames are in use (supported by the device SDK level and application) the order of routing attempts is always:
Use last working route, if it exists ('LWR')
Use direct RF (to an in-range neighbor)
Use calculated routes <<< the 'routing table'
Explorer Frames as last resort
If you can believe the following slide, there really is no 'learning over time' that will improve calculated routes in the routing table.
However, this is not mean that 'routes do not change over time'. They certainly can... though not without some likely notable performance issues (due to timeouts and protocol retries) that happen at the time of use. Without those, the controller's routing table does not modify or 'improve' routes unless the following happens:
A device is included/excluded (at which point current in-range neighbor nodes get reported back to the controller)
A repair is initiated (which updates the controller with current in-range neighbor nodes)
Either way, it's not something that happens without explicit user intervention.
Lacking that, the controller's routing table doesn't change. It's not Zigbee and doesn't dynamically self-heal.
So if a device's observed routing appears to have gotten 'fixed over time' without exclusion/inclusion or repair, it's likely becase a failed LWR (last working route) got updated to one that now works. This woud have been a result of failed transmissions using 'current LWR' , followed by failed direct RF, and lastly failed calculated routing (using the stale routing table).
There are slides in the Mesh Performance presentation that itemize the timeouts of the various failed transmission methods-- they can range upto 30 seconds in a dense network using explorer frames. This is consistent with the reports of many users that have experienced severe lags in performance from time to time.
True that it doesn't happen on its own. That said, starting w/2.2.7 the hub is doing some nightly maintenance on routes/hints to the SDK on routes - at least on the hub preferred route side of things, I don't know that it does ther equivalent of a repair on every node to change device side routes. @bcopeland would have to chime in there.
The 2.2.7 changes do make routing improve over time - I know I've definitely seen the difference.
Yes.. if a route change is needed the device routes will be updated.. This is completely at the SDK layer as all we are doing is a node neighbor update request. But if you are watching on zniffer while this is happening you will see quite a few SUC route updates..
That's a nice enhancement. It wasn't that long ago that Z-Wave repair seemed to be actively discouraged. It is still key to keeping a Z-Wave network viable, routing wise, since explorer frame discovered routes don't get reflected in routing table... and the routing table is always in the list of routing attempts, whether its accurate or not.
Thanks for clarifying! I wasn't sure of exactly what you were doing, so I mangled the wording a bit.
I do know that the routing is vastly improved in 2.2.7 even over what a standard node repair did in the past. Measurably. I was never able to get my routes as reasonable/logical with manual repairs as what 2.2.7 is doing automatically.
To route efficiently, Z-Wave nodes need to have an accurate list of their current neighbors, not just for their direct communication attempts but also to enable the controller to generate correct routes for an accurate 'big picture' view of the network... and they never look for changes unless told to do so explicitly.
One thing that Zigbee got right is continuous neighbor node topology updates via link level status exchanges.
I have an abundance (6) of Ring Range Extenders Gen 2 sprinkled about and a couple Aeotec Range Extender 7 devices, just about a dozen Z-Wave Plus devices.
I am seeing constant churning in the routes. I just shrug my shoulders, everything is working fine for me; Whatever.
Well it looks like now the hub is effectively doing the same thing without involving the user. And as far as I know, a Z-Wave repair is essentially the same thing as a neighbor update which, when communicated back to the controller, results in route updates that the controller then communicates back to the relevant devices.
Although I will still point out that on my main zwave hub routing in 2.2.7 is substantially better than I was ever able to do pre-2.2.7 with manual repairs. The routing looks almost completely different on my hubs in 2.2.7 versus what it looked like before then with semi-frequent manual repairs.
So I'm not 100% convinced it is really doing the same thing, just automatically. But maybe I'm nuts.
I will say I never got up in the middle of the night to do the manual repairs. So there could be (likely is) a time difference to when the maintenance is happening too.
A couple of points made repeatedly (but not elaborated upon) in the silicon Labs presentation slides indicate that both the SDK and the application can influence routing. So I doubt that you are nuts.
And one other point made in the voiceover (but not bullet pointed in a slide) was that Flirs devices (locks) cannot use explorer frames.. another good reason to have a valid routing table in the controller.
Well, that's nice of you to say, but I still won't rule that option out.
While I keep digging more and more into the guts of the SDK and protocol over the years, I am still just an amateur so sometimes misinterpret both the specs/SDK as well as what I see from the sniffer/results on the hub.
I'm just happy the routes "seem" better/more logical/more reliable (less PER, fewer route changes overall, higher data rate on a number of devices) than I had before. So no complaints here.
All good points. I know I've been fairly vocal in the past about repairs not being "necessary".
And that is true (FLiRS maybe being the notable exception!!!) for most devices in terms of them finding a route to the hub and "working" for device initiated updates.
But to your point, having a correct and up-to-date routing table is also very important for the overall health of the mesh and hub initiated communication. And that really only happens on the equivalent of a "repair".
So I guess while I was right in my narrow line of thinking, that thought process did not account for FLiRS or routing table impacts.
I guess that is a long way of saying, I think I was a bit off base/too narrow in my thoughts of the value of repairs.
The documentation is nutz and spread out in so many places.. Some is doxygen web pages, pdfs, excel files, etc... You basically have to devote your life to z-wave to keep it together
