Interesting. Glad @srwhite threw some sunlight on this particular bit of shady area in my Zigbee knowledge!
@Ken_Fraleigh that's an interesting question!
I wonder. I think I'm presently only using one Peanut, but it might be worth a remove to see what happens...
Scott
For one thing, in EmberZNet there is no such thing. A concentrator is either low ram or high ram. None isn't an option. 
But low ram concentrators have to frequently send route discovery requests prior to sending a message. That's horrible for large networks because these are effectively broadcast messages which can start to degrade a network.
The concept of high/low ram only applies to concentrators. A concentrator (or coordinator) is the hub in the Hubitat world. Whether a coordinator is high ram (full route table) or low ram (partial route table), route discovery can still happen since Zigbee is a self-updating mesh protocol.
Hubs like ST and HE use MTORR (many-to-one-routing) where the only thing a device talks to is the hub, and vice versa... Devices do not exchange messages with other devices. This requires a high-ram concentrator in order to avoid the overhead of route discovery.
What's probably happening, and one of the reasons why many bulbs suck as routers, is because they do not have a lot of RAM and processing.. They are prone to buffer overruns, corrupted messages, and who knows, they could be blasing out a ton of route discover messages (which routing devices can do) causing the network to remain in a constant state of flux.
I would remove the bulbs and see if the peanuts stabilize, then try the same in reverse by adding the bulbs back and taking the peanuts out. It won't isolate a bad device, but will potentially help narrow it down to a class of devices.
I appreciate you taking the time to explain that so well, but I have one question; When it says
[quote="Ken_Fraleigh, post:103, topic:15240"]
concentratorType:None
[/quote] , what does that mean if it isn’t a thing. I see that on bulbs, in-wall dimmers, and some plugs.
I would love to see, but this isn’t going to happen. My wife and kids would not be okay with hanging out in the dark. 60 bulbs are on the zigbee coordinator which only leaves the bedrooms, kitchen, and outdoors which have Hue, Hue, and zigbee switches respectively. I will just pitch the Peanuts into the drawer until next Christmas.
The difference is one is an API parameter, the other is a specification on a box... When you see concentrator type as being none on a spec sheet, it means that device is incapable of acting as a network coordinator (i.e. hub). It has nothing to do with the size and type of a routing table.
Hard to argue with that... Of course you can always give her your credit card and have her take the kids shopping!
But seriously, I appreciate you taking the time to explain. I have wondered what the heck that meant since I discovered the getchildandrouteinfo page.
EDIT: Peanuts have gone to the drawer btw.
But I have no bulbs on my mesh except for Sengleds, which are end devices. And I had one peanut plug that was jumping around from router to router like crazy. So, is that a problem or not?
Then why are the peanut plugs listed as low ram concentrators and why do they keep jumping from router to router?
Also, the reason this whole topic got brought up in the first place is that I have a repeater, an Iris plug, which i paired in place. It is showing up in the neighbor table of the hub with an LQI less than 100. Now, there are 8 other repeaters in my network, 3 of which sit between the hub and this plug. One has direct line-of-site to this plug and that plug has an LQI of 253. So, my question is, why is this outlet still trying to connect directly to the hub rather than go through another repeater. An LQI of less than 100 is a very bad thing, right? So, why is it still trying to do that? Shouldn't it try to do a 2-hop route to the hub instead of tring to go directly to it? I mean, isn't that what a "mesh" network is supposed to be able to do?
I should clarify since I was speaking earlier in terms of the hub and its relation to the output of getChildAndRoute report.. In a general sense, a concentrator is as routing-capable device, which the peanut plugs are (so are bulbs).. That means those devices keep a partial routing table, which they have to in order to advertise themselves as routers to other devices..
FWIW.. I have never seen any device other than the coordinator be a high ram (i.e. full routing table) concentrator.
Why your devices are link hopping is anyones guess.. The one thing I could suggest looking at is 2.4GHz inteference with 802.11 devices. If you have an Xbee available you can use it as a spectrum analyzer.. Plug it in to a laptop and move it around the house to see if there might be any RF hot spots.
XBee (Pro and non-Pro) are High Ram concentrators:
Those are the only devices I've seen that are High Ram concentrators, though.
That would make sense since you can use an XBee is a coordinator..
Just because your low-LQI Iris plug is appearing in the Neighbor Table, it does not mean that the hub is communicating with it directly (though the mere fact that it is in the Neighbor table means that it is, or has been, at least marginally capable of doing so). The Neighbor Table is not the same thing as the 'routing table' and does not show the route records (complete path of intervening routers) that the hub is actually using to communicate to this device (also note that the Route Table Entry listing is also not the complete routing table, but just the next hop recently used to reach a device). When many-to-one source routing is being used, the route records stored by the hub will contain a reverse source route (sent along with the actual outbound Zigbee message to each successive next hop)-- this does specify the actual path being used. This path will have been determined as the 'least cost'/best path via LQI and link cost exchanges that have occurred during prior route discovery in response a route request network command sent by the hub. The hub will store these route records for each device in the network in the routing table. Again, the route records are not visible through the ChildandRouteInfo page. However, if the device is indeed going through an intervening router, its next hop will at some point show up in a Route Table Entry, shown reachable as a 'via' through the intermediate router. This would be the indication that your problematic router is reachable by a router with a lower-cost/better path to the hub.
For example in my network the Neighbor Table is full, with 16 routers listed. Two of them, Iris Plugs H3 and H8, both appear in the Neighbor Table, with LQI 255 and 254 respectively. However I can see that a Route Table entry for H8 appears as follows:
[Living Room Iris Smart Plug H8, 152F] via [Living Room Xbox Iris Smart Plug H3, DD56]
So I know that even though both appear in the Neighbor Table (and each with good LQI), messages from the hub to plug H8 are being routed using H3 as the next hop as part of a two-hop route. Why this less efficient two hop path is being used when the hub is evidently capable of communicating with H8 directly is another subject. I'll chalk it up to the dynamic nature of the network, imperfect optimizations of the link path cost, or whatever. It likely makes no perceptible difference in latency so I am not stressing about it (H3 is an Iris plug literally two feet from the hub; H8 is diagonally across the room about 25 feet further away).
Then why do the iris plugs list themselves as connector type: none? That doesn't make a whole lot of sense.
And 8.02.11 interference wouldn't make any sense either. That would just make the case for this plug further away from the hub to use one of the avilable repeaters instead of trying to connect directly to the hub. If i was expecting a direct hub connection and it was routing through another repeater, then interference could be an explanation. But how could interference result in a device not picking the better route to the hub but trying for the "more difficult" one?
Okay...that I did not understand. I thought that since it is in the Neighbor table that this was the way it was communicating with the hub.
What really ticks me off is that for some reason, the plug that had the terribly low LQI is now showing an LQI of 250...so it obviously doesn't need a repeater to get to the hub. 
Sometimes you just can't win. lol
I do appreciate the explanation. It makes a lot more sense now.
Ryan,
Could there be something else other than wifi causing RF noise affecting the plug with intermittently low LQI values? Microwaves, Bluetooth, motors, fluorescent lights, cordless phones, etc. all can jam up the frequencies used.
Not long ago I went to a customer site to troubleshoot a poor wifi signal and found the entire spectrum was flooded with RF noise. The source ended up being a cell tower several hundred feet away.
Again, the issue is not the low LQI. Because of it's distance from the hub, I would not expect this device to connect directly. So, the Low LQI is expected. What was not expected was the device showing up in the neighbor table. But I believe that has been explained now.
Just because a device is capable of acting as a router does not mean that it is.. I have many Smart Plugs, last time I mapped out my mesh with an XBee, over half were effectively end devices. I also do not think that record (concentrator type) is defining the capability of the distant device. That device does not appear on the neighbor list so the hub is not aware of what its routing capabilities are.
If you look carefully, you will see every device in the Route Table Entry section has a device that it communcates through (via).
[Keypad, Back Stairs, 7D52] via [Microwave, 3EF3]
This means the hub is routing messages to the Keypad, Back stairs through the Microwave.
If you look at the Neighbor table, you'll see that the Microwave is there as a first hop router. That's all the knowledge the hub has of that route. I have SmartPlugs that appear as the second hop in that list..
Devices that more than those 2 hops won't never appear in the list, which I just confirmed with a distant plug..
I think the confusion here is that ChildAndRoute shows just one small part of the overall routing topology.
Agree. I had that discussion on here a few months ago. It is why that page is very misleading if you don't understand what it is / is for.
For instance, I have probably 20 zigbee devices that don't ever show up on that page (that I've ever been able to catch anyway). They are probably routed through too many other nodes, or are child devices that are popping on and back off the list before I see them.
Anyway, I rarely ever look at that page for that reason - it is just a slice of the whole story.
So does this mean everyone shouldn't be throwing away their perfectly good peanut plugs for nothing?
I don't follow... What does a report have to do with a Peanut plug?
That is what has got several on here considering replacing their peanut plugs based on the readings of that report.
No one is throwing them away. I moved my one plug over to my "bulbs" zigbee network. You really need to stop being so presumptuous.
And the reason I did that is that no one could explain to me why it was jumping from one repeater to another so frequently in the router table. Once every few seconds. Since it didn't seem right to me and no one could tell me why it was doing it, I removed it to see what effect it would have on my network.
I did not throw anything out. You have been on this forum for a total of 9 days and so far you have contributed nothing but criticism and nastiness. Please stop.
Download the Hubitat app
