First, what I THINK I know. Please correct me if you think the following are incorrect:
The Child Data section shows end devices that communicate directly with the Hubitat Hub.
The Neighbor Table Entry section shows devices that have repeating capability and (I think) also communicate directly with the Hub.
The Route Table Entry section shows the path devices take when passing through a repeater.
I'm curious about the entries for "Peanut_Outlet_1" highlighted above:
The bottom entry tells me that Peanut 1 passes through Ikea Bulb_Clear to get to the Hub.
The Neighbor Table Entry implies that Peanut 1 can talk directly to the Hub.
I suppose both could be true. The top entry shows "age:3" and "outCost:0" Does a zero outCost mean that this connection is broken?
The bottom entry shows "age:0". Does this mean that this entry is brand new, or is "age:0" a flag that says this route is stale?
Any corrections or clarifications greatly appreciated.
From the looks of the neighbor table entry for Peanut_Outlet_1, it is (apparently marginally) within one hop radio range of the hub. But the relatively low LQI (>200 is a threshold for 80% probability of packet reception per Ember docs) means that from the hub's point of view the link isn't great; and the outCost of 0 in this entry is a red flag. This field is supposed to indicate to the hub the quality of the link from the Peanut outlet's point of view (derived from the LQI that the Peanut plug sees on this path). Lower numbers are better but zero is a special case. Zero usually means that no link cost has yet been provided to the hub, or link status messages are no longer being reported and the hub has set this cost to zero (6 intervals have elapsed with no link status report. Not quite sure why it is showing age 3 there; that is usually the value the age counter gets reset to when a non-zero cost has been reported. I'd expect it to see it in the range of 0 to 2). Given that, it isn't surprising that the Route Table Entry shows that the hub is actually trying to use Ikea Bulb_Clear as an intermediary when talking to Peanut_Outlet_1. Looks like Ikea Bub_Clear is the best link from your hub to the rest of your Zigbee network.
There seems to be more information available (at least in SiLabs docs) about the meaning of the age field in Neighbor Table entries (as opposed to Route Table entries; I always seem to see 64 when looking at mine). For neighbor table entries, age numbers increment from 0 to 2 each time a 16 sec. reporting interval elapses without a status message when a link is in the establishment phase; once a nonzero cost has been reported by the neighbor the age field gets set back to three and then its range will increment from 3 to 6 each time an interval lapses without a report (ages >6 indicate stale neighbors).
Try refreshing your webpage and see how the table entries change periodically. Stable neighbor table entries will count up from 3 and get reset back to 3 again when the hub receives a link status message from a neighbor router. I'm curious as to how the Peanut_Outlet_1's figures look over time.
I've been told not to completely trust this table because reporting is limited. If you really want to know what's going on with your zigbee mesh, then it's time to invest in xbees. There are a lot of things that aren't reported in that table. So, what's given there is not 100% of what's actually going on. I've been told by those that know how this works within hubitat. Just my two cents.
Granted it doesn't provide info about your mesh (aside from a one-hop bubble around the hub). But it's a good window into the stability of the radio links that the hub is relying on to reach the rest of your network. I use XCTU with an Xstick (Xbee for dummies) to keep tabs on my mesh and think that this info complements that very well.
Yeah, must say.
I put in two IKEA Signal Repeaters two days ago.
I still found that all my Xioami devices still where listed under Child Date. Even after turning the HE Hub off for an hours or so, they still did not reroute.
I then wanted to force them over, and did a reconnect to the hub (Zigbee discover and resat the device)
They dissapeard from the Child Data part of the list, but never showed up again(still 4 hours since I did it)
I do think they are routed through the Ikea repeaters now, but maybe it takes more time to update the Routing Table completely?
They dissapeard instantly after reconnecting, so not sure if they should show up under Route Table Entry just as fast?
It’s a guessing game for now, but everything works perfectly, so who knows. I’ll give it a day or two, to see if it shows up.
Here is what I see now, and a lot is missing here.
Any thoughts?
If your Xiaomi devices are end devices (not repeaters), and they are now child devices of other Zigbee routers (the Ikea repeaters you added), you shouldn't expect to see them in the output of the hub's GetChildandRouteInfo page. That page is hub centric and will only show the hub's child devices as well as the neighbor routers that it is currently using (only links that the hub is currently using or has recently used will be listed in the Neighbor Table entries).
You won't see every device in your network listed here, nor the path through every repeater that will be traversed when the hub talks to a device-- although that information is gathered and maintaned by the hub (from prior Many-to-One route requests), it is not displayed here; there are tables internal to the hub where that info is stored.
That's because the GetChildandRouteInfo output isn't intended to show all the routing information used by the hub. It does show a list of child devices joined to the hub, and the status of the currently used neighbor routers. As the Silicon Labs EZSP reference states, "A neighbor table entry stores information about the reliability of RF links to and from neighboring nodes". That's the intent of the neighbor table entries shown here.
This type of info (child devices and link status to neighbor routers) is maintained by every Zigbee repeater. If you had the equivalent GetChildandRouteInfo output from every repeater in your network, you could use it to construct a complete map of your mesh. But again, all you get from hubsipaddress/hub/zigbee/GetChildandRouteInfo is the piece of the mesh with links to the hub.
Depending on the timing, you may spot a reference to a child end device in one of the Route Table entries (which show which of the neighbors is the 'next hop' of the route to that device). But as those entries get re-used and aren't static (and are only a piece of the routing logic) you likely won't see all your devices here. If things are working well, its possible that all of those entries could actually be blank (as the necessary source route info would be coming from internal routing tables) and all would be well.
Trying to determine recent zigbee issues and I found this link on routing tables. Trying to understand the below highlighted route table entry of status in discovery. Looks like a failed Zigbee discovery? Very strange in that I do daily hub reboots and haven't added or deleted devices for months!
I'm not sure I have an explanation for the persistence of this entry if it is always present (AFAIK 'in discovery' should be a transitory state), but the 'Route Table Entry' list is not related to Zigbee device joins; it is related to route discovery in 'many to one' routing.
The Route Table Entry list is like a 'cache' of previously discovered 'first hop of the route to device XYZ' and is used in lieu of doing a route discovery request each time the hub wants to transmit to a device (if the next hop to a device isn't found in the internal source route tables, or present in the Route Table Entry list, an on-demand route discovery would need to be initiated).
Can anyone tell me what it means when the routing table shows a device repeating to itself? This kitchen light (which is a zigbee switch by the way, not a bulb) is one of a few examples in my table. Just curious, everything works great!
The route table entry indicates the target 'first hop' router in the path to a device, so when the path to a destination device is via 'itself' that means that the device is within a one hop radius of the hub (a potential neighbor) and that the destination is itself a router.
