Zigbee2MQTT’s frontend flags an adapter as running old firmware, or a GitHub thread you were reading for something else mentions your coordinator’s chip is a version or two behind. Either way, the question is the same. Is this worth doing, and if it is, how do you do it without breaking a mesh that’s been stable for months.
This is a maintenance-cycle question, not a first-install one. If you’re at the point of comparing coordinator firmware versions, you already have a working network with paired devices and automations depending on it. Everything below is about protecting that while deciding whether an update earns its risk.
The procedure also splits hard by chip family. What flashes a SkyConnect will not touch a ConBee, and neither applies to a TI/CC2652-based coordinator. Conflating them is the fastest way to end up flashing the wrong file to the wrong device.
The short answer
Update when you have a specific reason. Not on a schedule.
That’s the position that comes through clearly in a Home Assistant Community thread built entirely around this same update-or-not dilemma. The exact decision-paralysis this topic creates shows up there directly, and the community consensus is to update when you need driver support you don’t currently have, or when a bug fix in a newer build actually affects you. Updating “because it’s there” isn’t the consensus recommendation, and the coordinator update path carries enough documented risk (more on that below) that routine updating isn’t obviously the safer choice either.
Why you might actually need to update
The clearest case is driver support. Zigbee2MQTT’s own EmberZNet adapters documentation states that EFR32-based adapters — SkyConnect, Connect ZBT-1, Sonoff ZBDongle-E, and the SLZB-06/07 family — need firmware 7.x or 8.x to run the modern ember driver. An adapter still on 6.x firmware won’t work with ember until it’s updated first. If you’re moving off the older EZSP driver, or your adapter shipped on old firmware and you want the current driver, that’s a concrete reason, not a routine one.
The second case is a bug fix that’s actually hitting you. If a firmware changelog entry addresses a stability issue you recognize from your own logs, that’s worth updating for. Chasing every changelog entry on principle is a different thing entirely, and it’s the behavior the HA Community thread above pushes back against.
Zigbee2MQTT’s own adapter docs and FAQ note that a coordinator firmware update does not normally require re-pairing devices. Network state lives in the coordinator’s persisted backup, not in the firmware itself. Take a manual backup anyway, since recovering from a bad flash without one means re-pairing everything.
Before you touch anything: back up your network
Do this regardless of adapter family. Z2M’s network state, the thing that lets your devices keep working after a firmware swap, lives in a backup file separate from the firmware image on the chip. If a flash goes wrong and you don’t have a recent backup, the practical fallback is re-pairing every device by hand. Take the backup, confirm it exists on disk, and only then move to the adapter-specific steps.
The EFR32/Silicon Labs path: SkyConnect, ZBDongle-E, SLZB-06/07
NabuCasa’s universal-silabs-flasher is the standard tool for EFR32/Silicon Labs-based adapters. It’s installed via pip, and it handles putting the adapter into bootloader mode through device-specific reset methods rather than a manual button-press sequence. The --bootloader-reset value is rts_dtr for the Sonoff ZBDongle-E (which we compare against the CC2652-based ZBDongle-P in a separate coordinator buying guide), slzb07 for the SLZB-07 — a sibling of the SLZB-06 we set up over Ethernet — with yellow, ihost, and baudrate as the other documented methods.
pip install universal-silabs-flasher universal-silabs-flasher --device /dev/ttyUSB0 \ --bootloader-reset rts_dtr \ flash --firmware <adapter-specific-firmware>.gbl
The device path and the exact firmware filename vary by adapter and by which build you’re targeting, so pull the correct .gbl from your adapter’s official firmware source rather than reusing another model’s file. The --bootloader-reset method names are documented in NabuCasa’s flasher repository — rts_dtr for the Sonoff ZBDongle-E and slzb07 for the SLZB-07 are the two you’re most likely to need; the full list of valid values lives in the tool’s README, so confirm yours there rather than guessing.
The ConBee/RaspBee path: a different tool entirely
Dresden Elektronik’s ConBee and RaspBee adapters don’t use the Silicon Labs flasher at all. They use GCFFlasher, a separate tool with its own firmware files that differ by model — ConBee II and ConBee III take different builds — and by whether you want a Zigbee-only firmware or one of the Thread/Matter-capable builds. Grabbing the wrong file for your specific ConBee model and radio-stack target is the main way this goes wrong, so confirm the exact model and firmware target before flashing rather than assuming a Zigbee-only ConBee II file works on a ConBee III.
Worth knowing: this is not a case where one flashing tool covers every Zigbee adapter. The chip families genuinely need different toolchains, and using the EFR32 flasher against a ConBee, or vice versa, won’t work.
The CC2652/TI path: yet another toolchain
CC2652-based coordinators use Texas Instruments’ own flashing tooling, in the same family as the cc2538-bsl-style serial bootloader flashing used elsewhere in the TI ecosystem. TI’s chip shows up in the Sonoff ZBDongle-P and other third-party adapters. This isn’t the Silicon Labs flasher and isn’t GCFFlasher either. We’re deliberately not printing an exact command here: the tool and flags vary enough by adapter that a copy-pasted command would be more likely to mislead than help. Check your specific adapter’s page on Zigbee2MQTT’s Supported Adapters index for the current, adapter-correct flashing instructions.
| Adapter family | Example hardware | Flashing tool |
|---|---|---|
| EFR32 / Silicon Labs | SkyConnect, Connect ZBT-1, Sonoff ZBDongle-E, SLZB-06/07 | universal-silabs-flasher (NabuCasa) |
| ConBee / RaspBee | ConBee II, ConBee III, RaspBee | GCFFlasher (Dresden Elektronik), model-specific firmware |
| CC2652 / Texas Instruments | Sonoff ZBDongle-P and other TI Z-Stack coordinators | TI flashing toolchain, adapter-specific — see official adapter page |
When it goes wrong: the SLZB-06 lesson
The risk here isn’t theoretical. Two separate GitHub issues on the Zigbee2MQTT repository document coordinator firmware updates breaking an SLZB-06 network outright, one tied to a March 2025 firmware build, a second reported later against a different firmware date. Both describe the same pattern. The coordinator fails to reconnect after the update completes.
Two documented GitHub issues describe SLZB-06 coordinators failing to reconnect after a firmware update, on two separate firmware releases. This isn’t a universal outcome, and most updates on most adapters complete cleanly, but it’s the concrete reason the backup step above isn’t optional. Read the linked issue for your specific adapter and firmware version before updating if one exists.
I think Z2M’s frontend would do readers a favor by surfacing the current and latest firmware versions directly in the adapter settings pane, rather than leaving version-checking to a GitHub changelog scan. That single UI addition would turn “is my firmware outdated” from a research task into a glance.
Do you need to re-pair devices after updating?
In the normal case, no. As covered above, network state persists in the coordinator’s backup rather than in the firmware. A clean update should leave your paired devices and automations untouched. The re-pairing scenario only comes up when the update itself goes wrong and there’s no recent backup to restore from, which is exactly the failure mode the SLZB-06 issues above describe. If devices show up afterward reporting as unresponsive or duplicated rather than simply missing, that’s a different and separate failure pattern worth checking against ghost-device troubleshooting.
FAQ
Do I need to update my Zigbee2MQTT coordinator firmware?
Only if you have a specific reason. You need the ember driver and your EFR32 adapter is still on 6.x firmware, or a documented bug fix in a newer build addresses something you’re actually seeing. Updating without a reason isn’t the community consensus recommendation.
Will updating my coordinator firmware break my existing Zigbee network?
Usually not, but it isn’t risk-free. Two documented SLZB-06 GitHub issues describe exactly this happening on two separate firmware releases. Back up your network before updating regardless of adapter.
Do I need to re-pair all my devices after a coordinator firmware update?
No, in the normal case. Network state lives in a separate backup, not in the firmware. Re-pairing becomes necessary only if the update fails and you don’t have a backup to restore.
What’s the difference between flashing a ConBee vs a Sonoff/SLZB adapter?
They’re different chip families entirely. ConBee and RaspBee use GCFFlasher with model-specific firmware files. Sonoff ZBDongle-E and the SLZB-06/07 family are EFR32-based and use universal-silabs-flasher instead. The tools aren’t interchangeable.
How do I back up my Zigbee2MQTT network before updating firmware?
Zigbee2MQTT keeps your network state in a coordinator_backup.json file that it writes automatically into its data directory — the same file a restore reads from. Before you touch any flashing tool, copy that file, along with database.db from the same directory, somewhere off the device. That copy is what turns a bad flash from a re-pair-everything event into a restore.
What this covers, and what it doesn’t
This piece is built from Zigbee2MQTT’s own adapter and FAQ documentation, the universal-silabs-flasher project and independent write-ups covering its use on Sonoff hardware, Dresden Elektronik’s GCFFlasher documentation, and two GitHub issues documenting real SLZB-06 firmware-update failures. No coordinator firmware update was performed as research for this article. It stays local either way: the flashing tools run against your adapter over USB or your local network, and none of them require a cloud round-trip.
What still depends on the vendor is the firmware image itself. You’re flashing a build Silicon Labs, Dresden Elektronik, or Texas Instruments (via their adapter partners) actually produced, not something the Z2M project builds independently. After any update, check that the adapter reconnects cleanly in the Z2M frontend, confirm a handful of devices are still reporting, and keep the pre-update backup somewhere safe for a few days rather than deleting it immediately. The exact CLI syntax for your specific adapter is worth confirming against its current official page before you run anything, since flag names and firmware filenames do change between releases. It’s also a reasonable moment to sanity-check the rest of your coordinator’s local exposure and MQTT broker hardening while you’re already in maintenance mode.