@Tony, nice write up and it leads to more questions, lol. If a device is a child of the hub and the hub shuts down, then the device found a repeater, would it go back to the hub or stay on the repeater if it was "happy" on the repeater? Even if the hub has a better signal?
1 Like
I'd like to take a whack at this, only to test my understanding. If I fail, let's pretend I never said anything. 
Based on this...
...my (barely educated) expectation would be that the device would stick to its new-found repeater unless that connection went pretty far south.
OK, how wrong am I? 
3 Likes
the problem i have seen with this is the device doesnt seem to know the connection is bad in many cases ie it is missing incoming messages so never initiates a reconnection.
So if you have a lot of repeaters and a good strong mesh it's not unreasonable to think that you would have no Child devices. They could all be on repeaters, more so if the hub was being updated / shutdown, rebooted often.
This I wonder about, and the new options on how to join devices that are stubborn. I mean on the C-7 it was never an issue, it just worked.
I think you've got it. Pretty sure that the device would stay put if it has found a good parent. AFAIK an end device needs to decide it is orphaned (polling its parent fails; that's also the only way it receives routed data) before it goes through the orphan scan/rejoin scenario to pick another parent.
1 Like
Yes; my C-3 has no child devices (there are a dozen repeaters within as many feet from it). With that hub, if there were a repeater 10 feet away and I joined a device right next to the C-3, the end device would always pick the repeater even though it was farther away.
If I wanted to 'stick' a Xiaomi device to it (it handles them fine as child devices) I'd have to power down every repeater within a few yards away and join the Xiamoi close to the hub; it would stick to it after that. Yet doing the same thing with a Xiaomi friendly repeater, I could reliably get it to join just by doing it right next to the targeted repeater without disabling any others further away. Always figured because of that C-3's radio or antenna wasn't the greatest.
2 Likes
The way it should know the connection is bad is when it periodically wakes up and uses it, and it should do this regularly enough so that detecting a bad link (by the device at either end of the parent/child connection) isn't an issue. A properly functioning Zigbee sleepy end device never really passively listens for messages-- its radio is usually turned off and 99.9% of the time the device is asleep, drawing nanoamps and waiting for a timer to kick it back to life (or if it's a sensor, for an external event to do the same). Then it wakes up and polls its parent for messages (including broadcasts that the parent may have received and buffered for it); this is the 'check-in' that the parent is also expecting.
If the end device's poll fails (it gets no response), that's when it would know its link is broken.... likewise if the parent doesn't receive a poll within the expected 'end device timeout', it assumes the child has gone away and goes through a process where it tells the device to leave and try to rejoin if it is still around (other routers also can hear this process happening in case they somehow have latched on to the child).
Bad things happen if the end device poll timeout isn't set properly (which should happen when the end device joins the mesh). The end device is supposed to tell the parent-- which can be the hub or the router it's joining to-- how often it will check in and poll. Different devices have different check in periods-- Iris V2 sensors check in every 3 to 4 seconds; same for Zigbee locks. Most Zigbee buttons will only check in a few times an hour; the infamous Xiaomi non 1.2 compliant devices have longer than standard check-in times, so 'incompatible' parents will assume they've gone and aren't coming back... and for some reason the Xiaomi's don't try to rejoin.. that's why they need Xiaomi-friendly parent devices which give them more leeway in poll intervals.
2 Likes
in a perfect world it should work correctly but it seems not to on the c8. maybe an issue with the reconnection protocols or something?
Sure seems like a lot of ways things could go wrong... equally bad things can happen when an end device somehow winds up 'claimed' as a child by more than one router... when an end device joins (or rejoins) the mesh, it's supposed to send a 'device announcement' broadcast (via its parent) that hub & all routers hear; that's how they would know an end device has joined a new parent (same way they would know if its short ID had changed). If they contained that 'stale' child entry, it would be purged. If that process breaks somehow, you could get a device present in more than one router's child table....
Say the hub somehow didn't know that one if its child devices had in fact joined a new parent; every time the hub had data for it, it would assume that (as its child) its (bogus) child would eventually poll for it... so it actually transmits nothing over the air. Meanwhile, that device could be polling its actual parent like clockwork, getting nothing in return.
3 Likes
stepping into this - i ask only for educational purposes - but the 'power of the hub vs the power of the device' - doesn't the whole point of a mesh network mimic an IP network in that its route based? the device would recognize the path back as being to whatever device its table shows connection to - it wouldn't have to make it back to the hub directly as I interpret what rwclements said. I'm unclear why the author implied syncronicity - or do I misunderstand mesh topology?
Psst...the word on the street is 20 is happening. The bumping has been bumped. It's on the down-low, keep it to yourself... 
2 Likes
For a minute I thought that finally one of my battery devices dropped off the mesh, but it turned out to be a dead battery. I put in a new battery and the device started working straight away. 
I hope 20 is good to you as well.
If it is, you get all the credit!
If it isn't it will all be your fault!
Either way I get off scott-free, which is my main goal on life anyway. 
2 Likes
If it breaks things, youâre better half isnât going to believe that itâs anyoneâs fault but yours. You will not get off scot-free. You can only pretend that you will .
BTW, you said that you donât have any repeaters in the room where the hub resides. I have a Sonoff dongle 2 feet away from mine that a large number of devices route through. They chose its 9dbm output over the hubâs 20dbm output.
1 Like
I'm starting to suspect, that Zigbee radio is offline/online issue is signal related somehow too.
As I mentioned earlier, I started to have that problem, after changing version to higher than "131", but, I did notice, that I accidentally again turned hubitat from my "normal" for me position of hub (vertical one, so antennas are pointed horizontaly) to "wrong" one (horizontal).
After setting hub again in vertical position I do not have (so far) any "Zigbee radio is offline/online" messages.
Breaking things... 
Came home from a movie and several devices off-line, automations not working, etc. Not good... Luckily wife was surprisingly forgiving (after I blamed you).
Likely go back to 16, which behaved better than this...
Is there any pattern to the devices that are going offline? Are they always the same end devices? Are you losing repeaters as well?
If you think there's a correlation with your mesh reliability and radio power, why not go back to whatever setting is supposed to be the same as C7 (I forget whether it was 8 or 4) and get a baseline... I know you mentioned you had issues at lower settings, but it doesn't seem like you are seeing improvment by turning it up. There shouldn't be any reason for needing higher radio power with the C-8 vs. what you had before in your environment; maybe the whole radio power setting is just a red herring...
2 Likes
I jokingly said the same thing in an earlier post, but I do think there's some truth here...
After all, if the C8's radio and firmware are working right and you have a strong mesh of device placements, then you should be perfectly fine with min power on the C8.
Again assuming a good mesh, then if upping the radio power to the high #s seems to fix stuff for you, then (to me) that actually confirms there's a problem with the radio and/or firmware -- there should be no reason upping power improves performance in a solid mesh. Nor should that "improvement" be something you are content with -- at best, it's just a band-aid on whatever the real problem is.
So perhaps those power-number options are indeed red herrings, but if not, I've concluded they are an unhelpful distraction until the real issues are discovered and fixed in the firmware.
I just hope that fix is actually possible with firmware, and not an unfixable issue with the Gecko chip itself.
2 Likes
What if some of his repeaters arenât playing well with the C-8. I know he had mentioned the Tuya usb repeaters didnât show up repeating for devices like they did on his C-7. I know that most everything that shows up in my routing table is routing through one of my Sonoff dongles, a Samsung Zigbee 3.0 outlet, or a Hue outlet. This wasnât really the case on my C-5 that I migrated from, it was mostly the Samsung outlets doing the brunt of the repeating on that hub (if the route table is correct). Dana also said that he doesnât have any repeaters in the same room as the C-8.
Good points, Ken -- but if repeaters / other devices aren't working right, that's a firmware/chip issue we need resolved. Sure, upping power may help temporarily as a band-aid, but is that the solution you are really happy with long-term?
If the future of this new Gecko chip truly ends up being limited or no compatibility with devices I already own & have in place (and I know they work well), then I'm going to go back to my C7.
ETA - But I am confident (well, hopeful anyway!) the issues can be resolved with firmware -- zigbee should be backward-compatible, and the Gecko chip sounds like a good one, so fingers crossed firmware tweaks will eventually get to the bottom of all this.
