There is no guarantee as to which route a message is going to take.
Also, despite what might sound like common sense, a higher LQI isn’t necessarily a determining factor in whether a device is or should be the next hop router. Remember, one of the the primary goals of mesh networking is maximizing contour (coverage area). This can mean that devices further from the hub are promoted to first hop routers even when closer neighbors with better LQI exist.
The child device limit of the hub was upped to 32 shortly after it came out, as I recall. The neighbor table limit is indeed 16. Found the link: Limits?
Btw, this doesn't mean that only 16 routers can join directly to the hub, just that 16 are used for routing.... so a 17th repeater not in the neighbor table, but in single-hop radio range of the hub would still be a two-hop destination.
I am suspect of that...
When you run the /hub/zigbee/getChildAndRouteInfo it shows only 16 entries in the routing table, and those are all end-devices.. In theory, there should be 32 entries in that table, but then again, I'm basing this strictly on that report. I've never seen more than 2-3 child devices under Child Data either. Who knows.
That is the neighbor table, not child table AFAIK. Only routers can appear there. Or am I missing something? I actually always have 0 entries in my child table (the nearby routers are much more adept at snatching them during device joins).
This screenshot should clarify the issue, I think.
1 Child Device (end device - its a sensor)
16 routing devices in Neighbor table
All the devices in your neighbor table are routers, correct? Edit: Never mind, I just read your post again where you confirmed this.
I think this should help bring clarity to this conversation...
The hub uses the EmberZNet zigbee stack, a detail I learned around this time last year when I was testing some of the Zigbee improvements.
That platform has some in-built limitations which are called out in their official documentation.
Neighbor Table Size:
page 5, EZSP_CONFIG_NEIGHBOR_TABLE_SIZE, max 16, min 8 : The maximum number of router neighbors the stack can keep track of. A neighbor is a node within radio range.
We know that Hubitat is set to 16 because we see 16 entries in the ChildAndRoute table.
Child Device Table Size:
page 5, EZSP_CONFIG_MAX_END_DEVICE_CHILDREN min 0, max 32 : The maximum number of end device children that a router will support.
Hubitat is in fact set to 32 so disregard my previous post.. However unlike the ChildAndRoute table, unused entries are simply not printed out.
If anyone wants to read up on these, in the link above...
I don't even try to understand how these devices choose their routes. I mapped it out with my xbee and I have devices in the basement that connect through a router upstairs just to get back to the basement hub.
As long as it works I don't think about it too much.
You didn't read my last post, did you? 
I would like to re-iterate the question that I started this thread for. I have resisted the urge to cry foul of a hijacked thread because no one would care anyway (but wait until the next time I do it and I'll be strung up by my toes for it). But, the original question was:
Why is a repeater that is too far from the hub to get a decent signal still trying to get a direct route to the hub when there are other repeaters it would route through that do have a strong signal?
I don't see this at all. If the mesh was trying to do this, repeaters would join to other repeaters like they are supposed to when their direct signal to the hub is so low. But I am not seeing that happening.
I just read it, lol, sorry
My hub also has no child devices; they're all joined to nearby routers. This isn't unusual, just a result of how a device goes about evaluating a parent during the join process. Actually the only time I've had child devices joined to my hub was before I owned any routers capable of hosting Xiaomi end devices (I would power down all my Iris plugs and let the Xiaomi join directly to the hub).
The odd is I have more devices, not showing in the table and I know they are not directly to the hub, is that normal?
Ryan, you should try yoga.
I just want an answer to my question.
I didn't see that original question in your post; the question I saw (and tried to answer) was:
So, this device could get to the hub with one additional hop. Is that the route that it will take? Or does this table indicated that it is connecting directly to the hub?
My response (in my reply above): So if a device appears in the Neighbor table, by definition it is a router and it is reachable from the hub as a single-hop routed destination. Packets outbound from the hub will be sent directly to it without going through any intervening router, as long as it maintains it status as a neighbor.
The key takeaway here is that route request command contains amongst other things, a path cost, which we see in the ChildAndRoute table. How that value is calculated is above my pay grade, but that is basically the field that determines what hop is best...
AODV is a very complicated protocol to understand.
Then why is it doing that??? There is a repeater literally half way between this device and the hub that has an LQI of 249. The device in question now has an LQI of 90 something. Why is it still trying to connect directly to the hub? This makes me think you can only have one layer of repeaters connected to the hub.
That is true, and that limit is 16 (neighbor table size). But those 16 routers can and do make routes to other router devices, and so-on. Up to 12 hops. However the hub is always limited to 16.. Think of them as 1st hop routers.
Download the Hubitat app
