How to survive a Zigbee coordinator failure

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. A usable backup and a compatible replacement can avoid rebuilding the network, but the recovery path depends on the integration and radio type. If the network cannot be restored, plan to re-pair devices.

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, preserve its full data directory and the coordinator backup where supported. I would choose a spare against the documented migration requirements, then rehearse recovery and write down the result. There is no fixed recovery time for every mesh.

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 Wi-Fi 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. Keep the integration configuration as well as the radio backup: network credentials alone are not a guarantee that every replacement radio or software change will preserve devices and entity references.

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 app, formerly add-on, or a standalone 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 (app, formerly add-on)

Keep a copy of Zigbee2MQTT’s full data directory off the host, including database.db, configuration and coordinator_backup.json where the adapter supports it. A radio backup alone is not a substitute for the application data. Check the current Zigbee2MQTT backup and migration requirements for your adapter before relying on a restore.

Backing up a sealed hub (Hubitat, Aqara, etc.)

On a Hubitat Elevation C-8 you cannot export the raw Zigbee key. (The C-8 was discontinued in March 2026; the standard C-8 Pro is now the Zigbee hub to buy, because the Pro’s Thread Special Edition swaps the Zigbee radio for Thread.) 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 radio recovery

Use the documented ZHA backup and migration process. It covers supported radio families with a backup made inside ZHA and lists firmware prerequisites. That procedure assumes the old network already used ZHA; it does not establish a general Zigbee2MQTT-to-ZHA migration method. Allow devices time to rejoin and check any that do not resume operation.

Zigbee2MQTT radio recovery

The Zigbee2MQTT FAQ distinguishes supported same-adapter-type replacements from other moves. Backup/restore support is limited to zstack and ember; even within zstack, moving from CC2530/CC2531 running Z-Stack 1.2 to CC2652/CC1352 running Z-Stack 3 requires re-pairing. Cross-stack zstack/ember migration is unofficial and results vary. Follow the matching procedure instead of assuming that copying one JSON file is enough.

Switching integrations is a separate job. Plan for re-pairing and checking entity references and automations rather than treating a radio replacement as proof that a cross-integration restore will work. My ZHA and Zigbee2MQTT comparison covers the software choice.

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 changing integrations, check device names, entity references, dashboard cards and automations instead of assuming they transferred. 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.

Two active coordinators would run separate Zigbee networks, not automatic failover for one mesh. After cloning a radio identity during migration, keep the old radio powered off; ZHA warns against operating both with the same IEEE address in the same area.

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. Check the old and new adapter types rather than treating these sticks as interchangeable backups. A ConBee III can use ZHA’s documented migration path when its prerequisites are met, but Zigbee2MQTT does not provide the same backup/restore support for its ConBee adapter. deCONZ/Phoscon has its own recovery procedure; its backup is not automatically a substitute for another integration’s data.

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:

1. Save and verify your backups before starting
2. Follow your integration’s documented migration process for the compatible spare, including its power-down timing; keep a replaced radio with a cloned identity powered off afterward
3. Watch how long devices take to check back in
4. Note which devices are slowest to return

Battery-powered devices may need time or waking before they check in. Verify that each device resumes operation instead of treating a delay as proof of either success or failure.

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 Wi-Fi 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.