Since the introduction of the Zigbee and Zwave maps, I have wondered how to interpret them, and what to do with that information. For instance, can you use them to change a routing that makes no sense? Could someone please enlighten me? Yeah, I have looked at them, and the dots and lines are neat and all, but it's about akin to reading Navajo Petroglyphs, Any help is appreciated!
2 Likes
I'm glad I'm not the only one that thinks this. Cool? Yes. Informative? Not without a key to interpret the data.
2 Likes
I don't know how the ZW version works, but the ZB version is simply a graphical representation of the getChildAndRouteInfo endpoint data.
If you search the community here for posts about how to interpret that endpoint's information, get some aspirin first -- to say the least, it's not easy to understand!
However, mad props to @Tony - in so many of those threads, he does as great a job as is possible trying to explain the nuances in language plain enough for dummies like me
But I long ago surrendered trying to make any ongoing sense of that endpoint (and correspondingly, the new graph) - it's just too much for my puny brain to digest, but more importantly, the data presented is simply not consistently complete enough to be genuinely useful.
4 Likes
The 'Zigbee graph' can't really serve as a substitute for a map of the mesh, since it's derived from a single source of data: the neighbor and child connections of just one router in the mesh (it's always the hub)--- and there may be dozens of routers in a Zigbee mesh. The child and neighbor connections of each of those would be needed to depict a bonafide map.
Probably best to think of the Zigbee graph as a cumulative history (if it weren't cumulative, you may not see much) of communications between:
-
the hub and devices which are, or may have been, its 'single hop radius' neighbors
-
the hub and its current (or past) child devices
-
the hub and devices which were the first hop destination in routes to a device elsewhere in the mesh... and that 'target device' may actually be directly connected to a device not even currently shown on the graph.
3 Likes
Can you explain why the graph includes devices which were connected in the past?
What use is that?
Wouldn't it be more helpful to see a snapshot of the current single hop neighbors, child devices and first hop destination routes?
And what is the difference between single hop neighbors, child devices and first hop destination routes?
The hub (or any Zigbee router, for that matter) always tracks the status of its neighbor devices and child devices. Every 15 sec or so a Zigbee router expects to see status from a valid 'in range' neighbor; if not, it can be evicted from that router's neighbor table. But it may not get evicted until a vacant slot is needed.. so its entries may remain but be 'stale' and not eligible for routing messages (indicated by the 'zero' cost numbers).
A single 'pass' of the process that generates the Zigbee graph will only detect what can be gleaned from the current state of the getChildandRouteInfo at that time... If there were no Route Table entries present (that is, no 'device XYZ via router ABC' )-- and those entries can get 'expired' if they haven't been used recently-- the resulting graph wouldn't have any devices to display, aside from what's in the hub's neighbor table. It would likely be an uninteresting picture.
By making the graph 'accumulate' the connections made over a period of time, you do get a sense of what devices have been involved in message traffic (and at least the 'first hop' devices in routes used by the hub to communicate with them).
But it's a skewed picture (in favor of the hub's view, routing wise) since routers in subsequent hops of a path to a device may not be represented... and connections that are no longer current will still be shown along side the present ones (hence the misleading view which can depict an end device with simultaneous connections to more than a single parent-- Zigbee end devices only maintain a single parent/child connection at a time; very different from Z-Wave where in-range neighbors of end devices are all potential communication paths).
...that's pretty much exactly what refreshing the getChildandRouteInfo page displays.
2 Likes
Here's what the maps have taught me:
ZigBee is much more resilient than ZWave.
Open the ZigBee map, pull out a repeater and watch all your devices rearrange their connections pretty quickly and everything goes back to normal.
Open the ZWave map, pull a repeater, and watch nothing happen at all. Then, for the next week, scream and yell everytime you flip a light switch and a ZWave connected light does not turn on or an automation fails because now your ZWave is borked.
1 Like
I thought that the ZWave map would help me in placing a repeater in an optimum location. But I see two devices at opposite ends of the house that are shown close to one another. It is cool to look at but I am also trying to find some practicality to it.
1 Like
and I have three devices in my garage (one in each corner to form a motion zone), and on the Zwave map they are more like each corner of the house.
Me too.
I added 12 plugs, mostly for experimenting, since my battery devices all connected well to the hub, mostly, except for the ST arrival sensors in the garage sometime.
Today, I pared that down to four: one on each level and the garage.
The mesh kept on ticking, and evidence was in the graph as well.
If that was Z-wave, forget about it.
So maybe for stuff that can get plugged in and out, zigbee might be best.
When I had all 12 plugs installed, I had a virtual switch turning them all on and off and it was almost instantaneous.
I have a wireless switch turn on all the Z-Wave lights, and today, while exercising it, it was hit or miss for quite a while until it settled in. Now, there are more devices, but even when they all actually turned on or off, it took maybe 8 seconds, best.
