I got the 'Rebuild network' button to do something that is probably relevant; lacking other details I'll climb out on a limb here.... scenario which follows includes just C-8 and 1 Zigbee plug (not migrated).
Yesterday after updating the C-8 to .109, I confirmed that the broken reset/rejoin behavior still persists. So the only device that I previously joined to it (but had since reset and tried unsuccessfully to rejoin) was a lone GE Zigbee dimmer plug which was uncontrollable after the attempted reset/rejoin; still it remained in the hub's neighbor table with its original short ID.
I unplugged the GE device and left the C-8 still running overnight. This morning the C-8's neighbor table still contained the GE plug even though that device hadn't been powered in several hours. The entry in the neighbor table showed outCost=0 meaning that the C-8 knew it hadn't received any link status from the plug (and it wouldn't be an eligible router). When plugged back in, the GE plug was still uncontrollable, though within seconds the neighbor table entry now showed outCost=1 meaning that the C-8 was receiving valid link status from the hub and a good connection. I unplugged it again. Within 15 seconds, neighbor table entry showed that inCost went back to zero.
I then hit the 'Rebuild network' button and voila, the neighbor table was cleared. Plugged the GE device back in and within seconds it reappeared in the neighbor table, inCost/outCost=1 (so the C-8 again had current link status), however the plug remained (or appeared to be, see below) uncontrollable. If 'Rebuild network' is intended as some kind of mitigation for this scenario, it didn't work in this case.
I noticed some things that are contradictory as a result of attempting to reset/rejoin a router (note that I still haven't done the drastic 'remedy' of deleting the device from the database and rejoining it to get it to work again):
-
Even though the plug's device details page shows no events for the device since its failed reset/rejoin (and its on/off state as shown on the details page can't be changed), Zigbee logging is showing entries from the plug every time an 'on' or 'off' button is pushed-- and the plug itself does in fact switch ON and OFF
-
If the C-8 is left alone with the plug still 'live' in this state, after a few minutes Zigbee logging page shows an entry for '0000' with RSSI=0. This entry (from the coordinator) was discussed in the forum a long time ago (I forget where the original post is, but the explanation was attributed to a Hubitat staff member) and was attributed to a periodic check that the hub does when it thinks that it is on a 'quiet' Zigbee network-- basically the hub transmits 'in the blind' to verify that the radio is still working. This might be a red herring since I never paid close attention to this before when running only a single Zigbee device with a hub.
So the inconsistencies are:
- after attempted reset/rejoin, there is no 'previously found' message (just the 'looks like you're' having problems' ... yet the device has at some level joined the network.
- the hub's details page for the GE plug logs no events and doesn't reflect the plugs on/off state, yet the on/off buttons on the page are sending events that do control the plug. Never noticed this before because I never actually hooked up a light bulb to the plug before...
- events generated at the plug itself that change its on/off state (from its local pushbutton) don't change the on/off state of the details page (they also produce no Zigbee logging entries, though when working properly this device does report local status to the hub)
- at some level the hub thinks it is on an idle Zigbee radio network (the 0000 in Zigbee logging), yet it's receiving valid link status (and properly indicating outCost) from the GE router.
Ultimately it looks like the reset/rejoin of a previously joined device scenario causes the hub's device database to be disconnected or out of sync with the events that the hub is actually generating (and which the device is responding to). This might explain why I'm seeing 'association successful' (reported by the hub) in the sniffer trace during seemingly 'failed' reset/rejoin attempts.. the device probably did join just fine but the C-8's database is out of the loop and not logging events or tracking the resulting on/off states that are produced by commands the hub is (successfully) sending.
Haven't tried any end devices yet; the Iris V2 sensors are capable of indicating failed rejoins by means of their blue-blinking light.
I've also been puzzled by the persistent neighbor table entries (saw them recently on the C-7 as well) and went back to the Zigbee Pro specs; turns out there is join type called 'direct' (as opposed to join by association) where the neighbor table can in fact be populated (directly) without requiring radio transmissions from any device at all (who knew). Just skimmed it so far but I'd expect to find other options that would control how/if these entries get aged out and purged.
