Here's the latest. I removed the lock from Hubitat and reset the ZigBee on the lock. I used the Advanced Zigbee Pairing in the community Zigbee Map app and used an outlet with near line of sight to both the hub and the lock. It DID pair and initialize correctly.
Initially after pairing everything was working - lock and unlock and correct reporting (locked/unlocked) in the web device. About an hour later i could still push lock or unlock on the web device, but it stopped reporting the correct state.
I don't get this - why does the original lock and a brand new one out of box behave this way?
I have the hub powered down (unplugged) and I'm going to leave it down for 30+ minutes then see how things behave.
I swear there is something just not right with the Zigbee Radio and or the Radio Driver in the C-8 Pro that may be casing many of the ZigBee issues we are seeing not only in this thread but the Sengled threads that are out there. I went though the "hell" with bulbs that didn't repeat (Sengled) and having a strong mesh with Inovelli Blue Switches and ThridReality outlets. My solution was when a light fell off the network add a new bulb to the Zigbee Network and use the "replace" command to swap out the devices in my automations. Then remove the old bulb from the Hubitat and factory reset the bulb.
That worked up today when I added another ThrirdReality outlet, updated it firmware, and then moved it to it final location. Everything was swell until my evening routine kicked in one one of the bulbs refused to respond to on commands.
I am also on channel 25 power level 8. I haven't tried "panic" mode yet to see if I can recover the bulb but I really think there is something with routing tables that are making the Non-Repeating bulbs (yes they are always powered) lose its route in the Zigbee Network when reconfiguring.
I have had years of no ZigBee issues so I wanted to get my story out here also.
There might be something wrong, but it surely wouldn't be widespread or this forum would have an explosion of reports of Zigbee issues.
Many of us don't seem to be having issues, not sure why some seem to be? Have you had any of the staff look at your hub, or worked with you to see if they have anything in the logs that might indicate trouble?
Not really @neonturbo I have been a Hubitat user since the C-4 days (2019) been up and down the log files, etc. The only common item I have is that I retired 4 Peanut Zigbee devices from my home last year and saw the Sengled bulbs start having issues when the drivers were updated in a release a long while back in 2025 (Sengled Classic and Sengled Classic (Legacy).
My build out is the C-8 Pro with radio's and automation and my older C-7 for cloud devices brought over with Hub Mesh. I would say I have been really happy with my Hubitat's even when my C-4 decided to kick the bucket I got good use out of it. I am just wondering if there is a threshold that exposed a defect in routing table construction in some of the devices.
I have these ZigBee devices on my network there is at least one repeating device in every room of the house.
12-Sengled Bulbs (Classic type non-rgb, non-repeaters)
4-ThirdReality RGB bulbs (they repeat)
5-Inovelli Blue mmWave Switches (repeaters)
9-Samsung Buttons (battery)
5-Samsung Leak Detectors (battery)
9-ThirdReality Gen2 Outlets (repeaters)
1-Centralite Lamp Module (yea very old)
1-Jasco In Wall Outlet (repeater)
For myself I have has 0 zigbee issues on my C8p, my old c8, c7 and c5. Have had some z-wave but those were generally my own fault (havent had any on my c8 or c8p). I have around 60+ zigbee devices.
I feel the same. On my C7 Zigbee was rock solid, once I migrated over to C8P issues started to show up with Zigbee. I wasn't going to report it, because I already know it's my fault. probably a unique combo of devices coupled with the new 3.0 chipset possibly exposes a yet undiscovered firmware issue, plus I don't have the energy to spend hours troubleshooting. I'll come home to find all 15 of my Sylvania downlights on, logs & events are totally empty of any info regarding this. These lights behaved 99% on my C7 and never did this.
At the end of the day it all works well enough that I stick with it.
changing channel may take up to 48 hours for devices to update and mesh to settle. Every time you change the channel, it will make it harder for your mesh to settle.
when pairing a device, the device is boosting its power to make discovery easier. Once the device is paired, the power is reduced. So if the device has a week connection, it could stop working after the power level is reduced.
Thanks - but this isn't likely a channel issue - i changed it based on suggestion from others. this is likely a repeater device that is failing - and i don't know which one or how to identify it. can someone grab my engineering logs and try to identify the culprit?
I grabbed my old lock and reset it then tried to add it - wouldn't initialize from my office (bedroom next to where hub lives). I did the double luck process with device sitting next to hub - it joined happily and seems happy for now. i'll check it again in an hour or so.
whatever i have going on is NOT the device - could be the hub, could be a repeater - but from 10 feet away trying to join should not have involved a repeater.
@gopher.ny or @mike.maxwell could you look at my hub/engineering logs and see if anything jumps out? hub ID ends with 6c56e8.
I have all of my Sylvania downlights and light strips (around 22 devices) on their own mesh (a C-8). When I did this, I had to join some of my GE Zigbee wall switches and a Sonoff dongle for them to all be 99.9% reliable. Maybe once a year I have an issue with one of them.
Edit: I should clarify that the entire mesh was originally added to a C-5 and migrated to the C-8 (without any issues). Also, the GE Zigbee wall switches are Zigbee 1.2 devices. The only Zigbee 3.0 device on that mesh was the Sonoff dongle. I have added 3 Linptech mmwaves and an Aqara FP1E over the past couple years because I didn’t trust the Linptechs on my other mesh with all of my Zigbee locks and sensors. The Aqara wouldn’t join that mesh, which is why it ended up with the Zigbee lights.
Are those Third Reality outlets power reporting? That could be putting a strain on your mesh. I have a couple of the ones that don’t report power, and they aren’t exactly impressive repeaters. I haven’t seen anything route through them and they are pretty close to the hub.
I keep all my ZB devices on a C7 with HubMesh for just this reason. Matter and ZW are on a different C8P hub. Just keeping the older radio for Zigbee - But that's just me..
Since the lock in question was going thru the Garage Light (and it appeared to have a direct connection to the hub, at least at the time of that one capture posted above), what model of device is that?
For the technically inclined, this post offers the best explanation I've seen (which was never confirmed nor denied by Hubitat staff). TL;DR: older devices may fail to rejoin on a C8/C8-Pro.
Aside: Zigbee is designed for devices surviving failure modes through multiple means, including attempting a mesh rejoin. I have yet to find any reliable supporting evidence (e.g. the spec) for some of the folklore around "mesh settling time" or "panic mode".
A lot of troubleshooting efforts fall into the category of Zigbee “folklore” — behavior that isn’t formally documented in the specs, but is based on years of real-world observations and troubleshooting.
Both the so-called “settling time” and “panic mode” mostly relate to offline devices or sleeping battery-powered ones.
For example, after a Zigbee channel change, many battery devices won’t immediately learn about the new channel because they are asleep most of the time. They only update once they wake up and attempt communication again. That’s why channel changes can appear inconsistent at first and may take hours, or even longer, to fully stabilize.
The same logic applies to the “panic mode” concept. If the coordinator is taken offline long enough, devices eventually mark it as unavailable after repeated failed communication attempts. When the coordinator comes back online, devices are more likely to actively rediscover and rebuild routes to it instead of relying on stale routing information.
Because many end devices sleep for extended periods, the coordinator has to remain offline long enough for those devices to wake up, fail communication, and realize the coordinator is missing. Otherwise, some devices may continue trying to use outdated paths and never properly refresh their routing.
That said, “panic mode” is rarely effective on modern Zigbee devices. Over the years, the protocol has significantly improved routing behavior, self-healing, and network recovery logic. Most newer devices are much better at adapting to topology changes automatically, without requiring the coordinator to be intentionally taken offline for extended periods. In many modern meshes, patience and allowing the network time to naturally stabilize tends to work better than forcing recovery behavior.
Quite right and that is unfortunate, at least for this engineer. Although I do understand the need for pragmatism on the part of HE support (not every user will pull out their Zigbee sniffer, obviously), resorting to folklore can usually be avoided.
There is only spec and deviation from the spec. The deviations are real and it is rare that someone knowledgeable with the spec won't figure out the reason for the troublesome behaviour (as @tony did).
Instead laypeople build mental models for what is going on (such as "mesh settling time" and "panic mode", neither being an actual thing) and, as it happens in many contexts, the model appears to fit reality in some proportion of observed cases and becomes the "accepted answer".
Wouldn't it be simpler to tell @DarellCraighead that (if such is really the case) their Kwikset 914 is running an older version of the Zigbee stack, doesn't honor TCLK negotiation, and once paired, will never rejoin the mesh on its own on a C8/C8-Pro (and that Hubitat has no intention of implementing a "Secure Mode" switch a la SmartThings?)
