given the strength is should be on first floor close to hub?
also notice how there are no routes.. impressive .. my old c8 had many routes but not sure why either the antenna is better (although same andtenna) or my old c8 just had weak zigbee. thinking the routing is incorrect as obviously i have some routes as i have 50 zigbee devices.. weird that none are routing to first level neighbors.
You could get an Xbee3 and scan your network see how it is connected to your network.
Try powering down one device at a time and rescan your network each time to see what device is causing the issue.
I believe so, but not 100% sure I'm remembering correctly. I don't have any now that I'm aware of so it must have sorted itself at some point. Those neighbor tables are known for holding on to old data IIRC,and that data feeds the Zigbee graph, so it's likely just old data that isn't going to cause any issues.
I sometimes get "Unknowns" in my graph when I'm removing devices from the mesh. They clear away on their own after some time. I believe the hub is sometimes lazy to remove records from its 3 tables unless it needs to use the space.
Right now I have one Unknown as I've been removing and re-adding an Aqara T2 switch, trying to figure out how its OTA firmware update works.
thanks good idea that seemed to fix it.. now to do a new cloud backup. something was corrupt because the whole second section of the routes table was always missing.. see it now .. more normal..
Now that it is gone which is correct as the hub should not show traffic from a zigbee device not in the hub zigbee table. But the fact that the info like lqi etc changing leads me to believe that i may still have a rogue zigbee device out there. Should not be a hue light as they are on a different channel?
It can't, but its short ID has likely changed recently and the database (which maintains the MAC - short ID - device label correspondence) hasn't caught up yet. I assume that when a database reference to what was the former short ID happens, 'unknown' gets substituted, even though that physical device has gone nowhere.
The database gets temporarily out of sync because short ID assignments can happen periodically and don't always originate from the same place (like the hub's host Amlogic CPU-- that would be too easy).
Instead, they can come from the hub's 'Zigbee chip' (think EFR32MG21XXX) or that of any router elsewhere in the mesh that handles a join request. Or for hubs that don't use the stochastic assignment scheme (like recent HE models) they can get changed to whatever the hub's Zigbee application wants them to be.
Short ID's exist for a good reason; they save transmission airtime as well as nanojoules of radio power but that leads to a lot of complications.. a device receives an initial random short ID from the parent router (or hub) that handled the join.... followed a 'device announce' broadcast to check for collisions and resolve them, potentially assigning a different randomized short ID should they occur. And they'll change whenever a device leaves and rejoins the mesh (either from a 'reset/rejoin' or from some mesh disruption causing a device to leave and rejoin on its own).
Ultimately the reassignment ripples back into the database... at which point 'unknown' gets replaced by the device label associated with the current short ID for that device.
Geez I hope not... I've seen i C-7 erroneously hanging on to child table entries (pretty sure that's why 'rebuild network' got invented) but bogus neighbor tables really would "wreak havoc on your mesh".
Actually you're right, an old neighbor entry wouldn't disappear instantly (say, if someone unplugged a neighbor router)... but it would show evidence of that before too long: the age counter would continue to increment but the InCost would go to zero within a minute or so; then the entire entry could disappear if there was another eligble neighbor to take its place... not a bug but just how it works.
The C-7's stale child table quirk would still show end devices still in its child table that were not on the netwok at all... and as I recall they'd even persist across hub reboots.
yes as i said i am not sure that was my issue as the age did not continue to increment but would reset and lqi changed.. more likely what he said it was an active device using on old short id.. but i went through the devices with a fine tooth comb and there were none missing in the device list.. i guess it could have been one in the device list but using unknown and the wrong id.
I don't have any now that I'm aware of so it must have sorted itself at some point. Those neighbor tables are known for holding on to old data IIRC,and that data feeds the Zigbee graph, so it's likely just old data that isn't going to cause any issues.
