well i need to have one in order to sort it out since i need to do a packet capture whilst its pairing to see what we aren't doing that we were doing on c5/c7's
There isn't any other way of doing it.
2 Likes
So I did another migration of a few devices (GE Plug, Iris V2 motion, two LoraTap Zigbee 3.0 4-buttons) from C-7 to C-8, primarily to convince myself that I wasn't delusional: previously, LoraTap paired easliy to C-7, migrated perfectly and worked after migration on C-8, however after being reset LoraTap would never again pair to C-8.
This time around, as before, everything migrated perfectly. And the same 'bogus' child shortID's turn up in the C-8's getChildandRouteInfo page's child table. Turns out they aren't garbage; they correspond to the rightmost 16-bits of each devices IEEE address. They're bogus only in the sense that they never get transmitted by the radio (and of course, aren't the child device ID's by the definition of that term).
Based on that (and "research"-- thanks ChatGPT!) I'd speculate that C-8's assignment of non-randomized shortID's to end devices might be intended behavior (maybe part of a 'custom join procedure' implemented in the coordinator to force static node ID assignments during join according to chosen criteria, in this case their MAC address). Speculating (again) I'd think this was done to facilitate migration. @mike.maxwell, does this sound reasonable?
As before, the migrated LoraTap Zigbee 3.0 buttons that joined/worked perfectly on C-7 also worked perfectly after migration to C-8, and once again if they're reset, they subsequently cannot be joined again (nor can new ones). Original observations unfortunately confirmed.
A difference I'm seeing with this latest migration (two firmware releases later than the one I based my original notes on) is that now the GE plug also is gets an unchanging static shortID when it is reset/rejoined, so apparently now both routers and end devices are being treated consistently in getting assigned the same short ID even when they have been reset. Quite sure I didn't imagine that the first time; I performed that exercise a few times. This may help migration (if that is the intent) but it now lumps router devices into the category of "WILL ALWAYS FAIL TO PAIR AS USUAL AFTER BEING RESET--WON'T BE RECOGNIZED AS PREVIOUSLY JOINED-- MUST BE REMOVED AS A DEVICE FIRST" (I verified this on the GE plug).
EDIT: I just noticed that resetting (not rebooting) Zigbee radio does allow previously joined devices to 'drop into their own slots' without 'Remove' with the obvious side effect of having to reset/rejoin every Zigbee device in the database. All the devices get new shortID's (which then do not change after subsequent reset/rejoins, per the new normal...). After resetting (again, not rebooting) the Zigbee radio even the LoraTap button could be reset and rejoined again (once).
If this isn't being considered an issue (it's not listed as 'known issue' in the firmware release notes), I think it should be. If my trials with a reset C-8 are any indication, it affects join behavior when there is no migration scenario. Maybe implement a 'kill switch' for the custom join behavior?
1 Like
I have seen the same with the two child devices that showed up in my routing table - the 4 character "short" name is the last 4 characters of the device's address. One of those was the Hue Outdoor Motion Sensor that I had to rejoin after it dropped (and is now working), the other was a Nyce contact sensor that migrated (apparently) successfully and is working.
Good to know I'm not in some weird bubble and the only one seeing this, lol. Were you able to rejoin the Hue sensor normally (without using 'Remove') and get it to be recognized as a previously joined device? I haven't been able to do that with the usual Iris V2 motions and contacts (and now, GE Zigbee dimmer plug) I have tried.
1 Like
Yes. I just started the Zigbee join from the Devices page and pressed the button on the back of Hue. It was recognized with the correct name and it is working . . . for now.
Anything to do with this......... 
Certainly possible they could be related. Some people have experienced a very serious problem such as Zigbee not starting up at all or not being able to join any devices to the Zigbee network. What I experienced seems (at least at the moment) to be much more subtle.
Could be, but honestly when I tried that link it took me to 'warranty claim'. None of the scenarios listed applied (Zigbee offline was the closest, but that's not happening to me). I didn't pursue further.
1 Like
I messaged Bobby about it and decided it was not appropriate to submit a warranty claim . . . at least not at this point.
1 Like
Actually I think one of the scenarios I noted above did result in a 'previously found' rejoin-- that when done through a router. My sniffer trace showed a new shortID got issued in that case (by the router). However in that case, the device (a V2 motion sensor) appeared to be joined (by its flashing green normal looking LED) but in fact the details page didn't reflect its events.
1 Like
I do not have a C8 so thought I'd just mention it.
As for the link, if it goes to the warranty claim page, they may be pointing to the wrong page.
Yes; actually I don't want to burden the support team with my scenario since I'm not trying to do anything productive with the C-8. If these issues are real (I'm sure they are) I'd expect they'll be assessed appropriately.
2 Likes
Thanks, the alternative link was provided more for those who are unable to send a message to @support_team.
2 Likes
I’ve seen the same behavior that you have described. I’ve only had one device that dropped off after migrating 80 or so Zigbee devices, and it was easy to delete and re pair with the C-8. I initially tried to reset and rejoin the device, and it seemed to be working, until I saw that it wasn’t functioning via the device page. Multiple attempts that followed didn’t even find a device to rejoin. That’s when I decided to try deleting, resetting, and rejoining it, which worked as expected. Since then I set my Zigbee radio to 20 (I don’t have real close neighbors) and lqi went up for most routers and stayed flat for the rest. I’m now in a holding pattern and not touching any of my Zigbee devices until things get ironed out. I’m very happy overall with the C-8 and have seen a noticeable improvement in responsiveness for distant Zigbee devices and all z-wave devices, which I deleted from another C-5 and easily joined to the C-8.
2 Likes
Please PM me if need a volunteer to send over a device.
I have a v1 coming, thanks!
2 Likes
Excellent news, thank you.
2 Likes
Credit to @scunny for helping out with the V1 unit for Mike!
And thanks for offering, @liquidskin.
3 Likes
@Tony, just discovered this thread. Your detailed description matches my experience perfectly. My Zigbee table contains the Null children. In my case I was trying to join a basic Zigbee 3.0 Tuya motion sensor. This sensor was joined to my other C7 with no issues.
No amount removing the battery, of joins or rejoins, to the C8 ended in success. Seems to get stuck in the join process according to the logs. However it appears to join in the UI. The device does not work, there is never any motion events.
I only tried joining near the hub. I gave up and joined the sensor back to the C7 with no issue.
2 Likes
Yes, these devices (I used LoraTap Zigbee 3.0 4- and 6-buttons) join/work normally on C-7 (and C-3, for whatever that's worth). Try this on the C-8, and a sniffer trace shows the C-8 responds immediately to the association request with 'association successful' and assigns it a device ID, however after several seconds of data exchange between the device and hub, the device ID stops appearing in the trace and it apparently leaves the network. I was able to produce a successful join (once) after resetting the C-8's Zigbee radio. Not sure why (note it was a 'nuclear option' reset, not a mere radio reboot).
Having watched how the C-7 handles rejoins, it now mimics the C-8's unusual join behavior in most respects, with a new oddity of its own-- 'disappeared' devices never get aged out of its child table. I'll put my observations in a separate thread.
1 Like
