Devices 0x20 and 0x22 are literally four feet from each other, on the same wall, same height, and facing the same direction. Looks like HE can get to 0x20 in three hops, but to get to 0x22, it has to go from 0x20 to 0x17, then to 0x22. The odd thing is that 0x17 is about 40' away (thru several walls) and it's on the right side of 0x20 whereas 0x22 is on the left side of 0x20. The hops thru 0x1C and 0x1D make sense given the physical locations.
0x20's box is actually a 2-gang box containing the Zooz dimmer and a dumb rocker switch. The dumb rocker switch is on the left side of the box, so a direct hop from 0x20 to 0x22 would have to "go through" the dumb rocker switch. It doesn't seem like that would be less interference than going thru 0x17 (increasing the total distance from 4' to 85'). 0x22 and 0x17 are both single gang boxes.
All the wall boxes are plastic.
Also, I thought there was a four hop maximum.
Everything works fine. I'm just trying to get a better understanding of this stuff.
Who knows, but if you repair the device, hit Config in the device page, and then refresh the z-wave details page, you could probably see it routing direct to the hub. Does for me, when I've got time on my hands.
Pretty much when Z-wave is working let it do its thing. It does what it wants.
There is no understanding the routes sometimes. Realize that the hub/radio has no spatial awareness, only latency and signal strength. If one route falters it looks for a better one. If the route being used is working it keeps using it until it fails.
I have a Ring Range Extender 2 that is three feet from my hub, it is literally the closest device I have to the hub, and its four hops. The same as a zooz temp/humidity sensor in my safe on the far side of the house. Everything else in the house is direct, so I'm not too worried about it.
The issue with Z-Wave routing (designed in the '90s around '80s era 8-bit 8051 MCU's, amazingly not upgraded to 32-bit ARM Cortex SoC's until the -700-series) is that it's simplistic.
Even in the latest -800 series Z-Wave, the only 'smarts' for determining topology-based routes (those that take into account neighbor adjacencies, and potentially device RSSI's) resides in the controller/hub. Only there are routes actualy calculated (along with potential backup routes if any exist) and sent to each device where they are stored. Problem is, these calculations only happen as a result of a device inclusion or manually initiated "Z-Wave Repair".
And to calculate 'good' routes, it's key that the hub have an accurate picture of each devices' in-range neighbors. Since Z-Wave devices only report neighbors when explicitliy requested, if a signal in one of those pre-calculated paths is blocked or degraded, it remains the front-up 'last working route' until it's actually used, whereupon it must be tried, fail, and be retried multiple times before another stored route (if one exists) can be used.
Early -300 series Z-Wave relied completely on controller-derived routes; later series introduced 'explorer frame flooding' allowing route discovery to be initiated by a device (but only after all hub-derived routes had been tried, retried, and failed, in succession). But even if caused by temporary interference or signal blockage, that newly discovered path (however unoptimal) gets retained as LWR until it too completely fails in which case the controller derived list of routes gets reused.
This is a helpful explanation.
I've also read that a Zwave network degrades to its oldest device. Does this mean that even if you have a C-7 and 700 or even 800 series devices on your mesh, the presence of even one old 300 series zwave device on the mesh will bring the entire thing down to 300 series specs?
Not necessarily; but the limitations of -300 series would come into play in certain areas-- they might not be capable of forwarding explorer frames to certain mesh segments (hampering the ability of other devices in the mesh to obtain efficient 'last resort' routes); the speed of the individual route segment involving the old device would be limited to -300 series speed (40kbps); also they likely wouldn't be capable of forwarding NWI frames (for network wide inclusion) so inclusions of newer devices out of range of the hub might not succeed.
That's an unfortunate side effect of Z-Wave's 'all Z-Wave devices are compatible' selling point. You need to dive into the specs to see what a given device actually supports (even NWI wasn't a universal feature until well into the -500 series timeframe) and while basic functions should work, all the 'tacked on' enhancements (NWI, NWE, explorer frames, RSSI reporting 100kbps link speed) may not be supported in any given vintage mix of devices.
