Hello All,
With the help of ChatGPT I was able to fix this issue, but wanted to document for others possible benefit in the future (paying it forward in the community).
Platform:
Hardware Version: C-8 Pro
Platform Version: 2.4.3.164
Situation:
- All commands sent to Zigbee devices completely stopped working. Sending a new command from the Hubitat UI resulted in “Command Sent” message in the UI, but logs showed zero device activity and device state both physically and in UI never changed following commands. Either the radio was not transmitting, or the devices were not receiving the messages.
- Checking Zigbee Details page showed the radio was ONLINE and the message counters for check-ins from the devices were incrementing. This means the devices are powered up and transmitting messages and the C8 radio is listening and receiving the messages. Inbound works.
- When checking my hub logs I noticed my Zigbee smart deadbolt door locks had recently started spewing “catchall” warning messages.
Troubleshooting Steps:
- Removed the batteries from all smart door locks to take them off the network (no change)
- Upgraded to latest platform version (no change)
- Rebooted hub (no change)
- Powered down hub, removed power for 30 seconds, powered back on (no change)
- Upgraded Zigbee radio firmware in UI (no change)
- Reboot Zigbee radio in UI (no change)
- Rebuilt Zigbee network in UI (no change)
So at this point I was at a loss and turned to ChatGPT for some assistance. I supplied all of the above details and troubleshooting steps. GPT suggested one thing I did not do which I felt was redundant from all the restarting and power down events, but I was wrong!
Zigbee Details:
- clicked “Disable”
- waited 15 seconds
- clicked “Enable”
That did the trick! Afterward my Zigbee network immediately started functioning again with commands being sent successfully to control devices.
Here is the output from ChatGPT that describes the situation and what happened (in GPT’s words, accuracy is unknown).
Your hub’s Zigbee NCP wasn’t fully stuck — it was half-hung.
- The host firmware (Hubitat) was fine
- The Ember NCP (the actual Zigbee chip) was alive enough to receive packets
- But the APS/NWK transmit queue inside the NCP was locked in a “pending ACK / retry” loop
- A normal reboot or even a power pull doesn’t always force the NCP to drop that internal state
- But disabling the Zigbee radio unloads the EZSP stack completely, which does clear the blocked TX queue
That’s why:
- Reboot? No effect
- Power pull? No effect
- Radio firmware upgrade? No effect
- Rebuild network / reboot radio? No effect
- Disable → 15 sec → Enable?
immediate recovery
You forced a full NCP teardown instead of a reboot that only reinitializes the host side. That’s exactly why Hubitat support themselves recommend this trick. It’s the only action that forces the entire Zigbee firmware stack to unload and restart, including internal buffers the hub OS can’t touch.
Why it happened
Your failing Zigbee lock had been blasting malformed catchall frames. That can push the coordinator into a “stuck outbound state.” Think of it like:
- It was waiting to ACK a frame that wasn’t valid
- It never got a response
- So it stopped accepting new outbound frames
- But inbound still processed normally
This is classic TX-only failure on Ember Zigbee radios.
