How to survive a Zigbee coordinator failure
Back up the Zigbee network key from ZHA or Zigbee2MQTT, restore it onto a spare coordinator, and rebuild your mesh in Home Assistant without re-pairing a single device. Hubitat notes included.
On this page
- What a dead coordinator takes with it
- Backing up with ZHA (built into Home Assistant)
- Backing up with Zigbee2MQTT (add-on/project)
- Backing up a sealed hub (Hubitat, Aqara, etc.)
- Storing backups off the box
- Restoring the network
- What restore does not magic away
- Build redundancy into your coordinator hardware
- Test your backup regularly
- Separate critical from non-critical Zigbee devices
- Have a recovery procedure documented
Zigbee is the radio most local smart homes lean on. It’s reliable, low-power, and works well with Home Assistant. But a Zigbee network is more fragile than it looks, and when your coordinator dies - because hardware fails, or you update firmware and something breaks - you need a plan. The thing you can’t afford to lose isn’t the devices themselves; it’s the coordinator’s network data: the PAN ID, the extended PAN ID, the network encryption key, and the channel. If you keep that data, you can move to a new coordinator stick and your devices rejoin on their own. If you lose it, you re-pair every device by hand.
The device list is replaceable; the coordinator’s network credentials are not. If you run ZHA, your network backup rides along in normal Home Assistant backups and you can also download it from Network Settings. If you run Zigbee2MQTT, grab coordinator_backup.json from Settings - Tools and keep a copy off the box. Keep a spare coordinator, test the restore before you need it, and write the steps down. Do that and a dead coordinator becomes a ten-minute swap instead of a weekend of re-pairing.
This guide covers backing up and restoring that data for the two Zigbee stacks people run in Home Assistant, ZHA and Zigbee2MQTT, plus notes for Hubitat, and then the redundancy and recovery planning that goes around it. Running Z-Wave as well? The backup process is different there - see how to back up and restore a Z-Wave network. If the mesh is merely flaky rather than dead, start with how to debug flaky Zigbee devices before assuming the coordinator failed.
What a dead coordinator takes with it
Your Zigbee coordinator is the single point of failure for your entire mesh. Unlike WiFi devices that connect independently, Zigbee devices relay through each other, and they all report to one gateway. When that gateway goes dark, you lose control of those devices and every automation that depends on them.
Most people don’t think about this until they’re standing in a dark living room at 11pm, staring at a dead USB stick, wondering why their lights won’t turn on and their thermostat won’t respond. Coordinator failures will happen: USB dongles die, firmware updates break things, power glitches corrupt firmware. Hoping your hardware never fails is not a plan; redundancy and a rehearsed recovery are.
Every Zigbee device is paired to one coordinator using shared network credentials. A standard Home Assistant backup saves your config and database, but the Zigbee network credentials are what let a replacement coordinator impersonate the old one so devices reconnect without re-pairing and your entity IDs survive. Back those up separately and a coordinator failure becomes a swap, not a rebuild.
In a Home Assistant setup the coordinator is usually a USB stick such as the Sonoff Zigbee 3.0 USB Dongle Plus, the Home Assistant Connect ZBT-2, or a ConBee-family adapter, or it’s a self-contained hub like the Aqara Hub M3 or Aeotec Smart Home Hub. On a sealed hub you don’t get raw access to the network key, so your “backup” is whatever export the hub vendor provides.
One clarification worth getting right: deCONZ/Phoscon is the software for Dresden Elektronik’s own ConBee USB sticks and RaspBee Pi modules - it is not what a Sonoff dongle uses. Sonoff and most other generic coordinators run under ZHA (built into Home Assistant) or Zigbee2MQTT (a separate add-on/project you install). Pick the right tool for your hardware before you think about backups.
Backing up with ZHA (built into Home Assistant)
ZHA backs up the network automatically. Every time the network configuration changes, ZHA writes a backup, and these are included whenever you take a normal Home Assistant backup - so if you already run Home Assistant backups, your ZHA network credentials are covered.
For a manual copy, go to Settings - Devices & Services - Zigbee Home Automation - Configure - Network Settings, where you can view and download the current network backup. Keep that file with your other backups so you can re-create the network on a new stick.
Backing up with Zigbee2MQTT (add-on/project)
In the Zigbee2MQTT web UI, open Settings - Tools and choose Request Z2M backup, then Download Zigbee2MQTT backup. You get a zip; inside it is a coordinator_backup.json holding the network credentials. Zigbee2MQTT also writes this file continuously to its data directory, so it’s captured by a full Home Assistant backup as well. Save the standalone coordinator_backup.json somewhere safe regardless - it’s the single most useful file for a fast recovery.
Backing up a sealed hub (Hubitat, Aqara, etc.)
On a Hubitat Elevation C-8 - discontinued in March 2026, with the standard C-8 Pro now the hub to buy for Zigbee, since Hubitat’s Thread Special Edition of the Pro replaces the Zigbee radio with a Thread one - you cannot export the raw Zigbee key. Hubitat’s built-in local backup (Settings - Backup and Restore) downloads the hub database: your apps, rules, and device entries. It does not include the Zigbee radio. Backing up the Zigbee radio itself and migrating it to a replacement hub is part of Hubitat’s paid Hub Protect / Cloud Backup subscription, and Zigbee radio migration is supported on the C-8 and C-8 Pro. Take the local backup anyway, on a schedule, and pull a copy off the hub.
Storing backups off the box
Wherever the file lives, get a copy off the device that created it. A NAS, an external drive, or encrypted cloud storage all work. Treat the Zigbee network key as a secret - anyone with it can join your network - so encrypt it if it’s leaving your house.
Restoring the network
ZHA: When you set up ZHA on a new or re-flashed coordinator, the network-formation dialog lets you upload a manual backup. Point it at your ZHA backup (or even a Zigbee2MQTT coordinator_backup.json - ZHA can import that) and the new stick adopts the old credentials. Devices rejoin on their own, usually within an hour; you don’t re-pair them.
Zigbee2MQTT: Put your saved coordinator_backup.json in the Zigbee2MQTT data directory before first start so the new coordinator comes up with the original network. One caveat straight from the Zigbee2MQTT docs: backup and restore is only implemented for the zstack (Texas Instruments) and ember (Silicon Labs) adapters, so a coordinator swap without re-pairing is a supported move only on those. The migration is also one-directional in tooling terms: you can restore a Z2M backup into ZHA, but there is currently no supported path to load a ZHA backup into Zigbee2MQTT.
Hubitat: Restore the local backup through Settings - Backup and Restore. On the same hub, with its radio untouched, that brings back your apps, rules, and device entries. Moving to a replacement hub is a different story: without a Hub Protect / Cloud Backup restore, the new hub’s radio holds none of the old network data, so you re-pair the Zigbee devices by hand.
What restore does not magic away
Even a clean credential restore has rough edges. After a Z2M-to-ZHA migration, device names and some higher-level settings don’t carry over, and entity IDs change - so dashboard cards and automations referencing the old entities need fixing. Battery and sleepy end devices can take a while to check back in; mains-powered routers reconnect fastest. And a backup taken before you added a batch of devices won’t know about them.
Build redundancy into your coordinator hardware
The cheapest insurance is having a spare coordinator sitting on a shelf. A SONOFF Zigbee 3.0 USB Dongle Plus (ZBDongle-P) costs about $20 bought direct from SONOFF - noticeably more through Amazon - and can serve as a backup. Leave it unpowered in a drawer - a spare stick does nothing on its own. What makes it useful is the network backup you restore onto it, which is what lets it impersonate the dead coordinator.
For more permanent redundancy, consider running two coordinators simultaneously. Some setups support multiple Zigbee adapters, or you can run a secondary Home Assistant instance with its own coordinator for critical devices only. This adds complexity but isolates failures.
The same principle applies whatever you run, but the backup path depends on the stack. The ZBDongle-P is a Texas Instruments CC2652P stick and runs Zigbee2MQTT’s zstack adapter; the SMLIGHT SLZB-07 is a Silicon Labs EFR32MG21 stick and runs the ember adapter. Both are inexpensive, and both have full backup and restore support under ZHA or Zigbee2MQTT. A ConBee III is the exception worth knowing about: Zigbee2MQTT implements backup and restore only for the zstack and ember adapters, so a ConBee’s backup lives in deCONZ/Phoscon instead.
Whatever you run, don’t rely on a single point of failure.
Test your backup regularly
A spare stick is only half the plan. The other half is the network backup above - grab it before you need it. Then test it. Every few months, do a dry-run recovery:
- Power down your primary coordinator
- Restore your network backup onto the spare, then swap it in
- Watch how long devices take to check back in
- Note which devices are slowest to return
Mains-powered routers reconnect fastest; battery-powered sensors can take an hour or more to check in on their own schedule. That lag is normal and is not a failed restore - knowing it before you’re stressed at midnight is the point of the drill.
Also test your network without the coordinator. Determine which devices have local fallback (some smart plugs remember their last state) and which are completely dead. This helps you set expectations for what works when the coordinator is down.
Separate critical from non-critical Zigbee devices
Not all Zigbee devices deserve equal priority. Lights are nice, but your security sensors - door sensors, motion detectors, water leak sensors - actually matter. Consider which devices you want operational during a failure and which you can live without temporarily.
A practical approach: run parallel protocols for critical functions. Use an Aqara Hub M3 or Hubitat for security sensors, which operate independently and don’t require your main Zigbee coordinator to function. You lose the unified view but gain independence.
For lighting, you have more flexibility. Zigbee lights can sometimes operate locally without the coordinator depending on the firmware, but most won’t. If you need guaranteed lighting during a coordinator failure, keep a few WiFi switches or smart bulbs as backup.
Have a recovery procedure documented
Write down the steps to get back online. Include:
- Where your backup coordinator is stored
- How to swap it in (which USB port, any adapter needed)
- Which devices to check on first, and which would need a manual re-pair if you ever lose the network backup
- Any network settings that might need adjustment
- How to restore your Zigbee network configuration from backup (the restore steps above, for your stack)
This sounds tedious, but in a crisis you won’t think clearly. A printed card or a text note you can reference takes 30 seconds to read and saves hours of troubleshooting. Accept that some devices will drop during a failure and plan around that.