A coordinator firmware update can fix a radio problem, add driver support or address a security issue. It can also interrupt a working Zigbee network if the image, hardware variant or update procedure is wrong. Before flashing, identify what the new release changes and make sure you can recover the existing network.
This guide is for an established Zigbee2MQTT installation with paired devices and working automations. The aim is to update deliberately while protecting that setup. The procedure depends on the exact adapter and its firmware format, not just the brand or the radio-chip vendor.
The short answer
Read the release notes, then decide whether the update is needed for compatibility, a relevant bug fix, security or continued support. An older version number alone is not a diagnosis, but a stable mesh is not a reason to ignore an applicable security fix either.
The Home Assistant Community discussion captures the practical concern: owners do not want to disturb a working network without a reason. Treat those replies as individual maintenance choices, not a universal update policy. The adapter manufacturer’s instructions and Zigbee2MQTT’s current driver requirements take priority for your hardware.
Reasons to update
Driver compatibility is one clear reason. The EmberZNet adapter guide currently lists supported firmware branches 7.4.x, 8.0.x, 8.1.x, 8.2.x, 9.0.x and 9.1.x for the ember driver. Saying simply “7.x or 8.x” is too broad: a build must match the protocol support in your installed Zigbee2MQTT version as well as your hardware. The older ezsp driver is deprecated, and multiprotocol firmware is not supported by the current Ember adapter guide.
Other reasons include a changelog fix matching errors in your logs, a manufacturer security advisory, or a required upgrade before a future Zigbee2MQTT release. Confirm the required sequence if the change involves the host driver, bootloader, radio firmware or serial settings. Avoid changing all of them at once without recording what changed.
A normal coordinator firmware update generally does not require re-pairing. That depends on preserving the coordinator’s network state and compatible firmware. Erasing nonvolatile memory, changing radio mode, forming a new network or changing its key is a different operation.
Before flashing: back up the complete installation
Network information exists in two places: the coordinator’s nonvolatile memory and Zigbee2MQTT’s data directory. The live network is not stored solely in coordinator_backup.json. That file is a backup representation available for supported adapters, not a substitute for the coordinator’s running state or the rest of your configuration.
Save an off-device copy of the complete data directory, including configuration.yaml, any referenced secrets, database.db, and coordinator_backup.json where supported. If configuration or custom files live outside that directory, preserve those too. Use the supported backup controls for your installation and retain a consistent copy with Zigbee2MQTT stopped before the firmware operation. Confirm that the files are readable and belong to the network you intend to preserve.
Zigbee2MQTT’s FAQ limits its adapter backup/restore support to zstack and ember. Do not promise the same recovery for conbee, ezsp, zboss or zigate. Even a supported backup is not a guarantee after an incompatible firmware change or hardware failure; check your adapter’s restoration procedure before you need it.
Record the adapter’s exact model, hardware revision, coordinator IEEE address, current radio firmware, driver, serial path and relevant baud-rate/flow-control settings. For network adapters, record core/network firmware separately from Zigbee radio firmware. Download the intended image and keep a known-good image if the vendor supports rollback. Stop Zigbee2MQTT and any other application using the radio before flashing.
The Ember/Silicon Labs path: verify the exact model
SkyConnect, now Home Assistant Connect ZBT-1, the Sonoff ZBDongle-E and SMLIGHT SLZB-07 are examples of adapters using Silicon Labs radios with Ember firmware. The SLZB-06M also belongs in this group. The unsuffixed SLZB-06 uses a Texas Instruments CC2652P instead, so a guide for an “SLZB-06/07 family” is not specific enough. The ZBDongle-E versus ZBDongle-P comparison explains a similar distinction between those Sonoff models.
Nabu Casa’s universal-silabs-flasher is one documented command-line option, not the only supported updater. It can enter a bootloader through communication with running firmware or a supported reset method. Its README documents rts_dtr for ZBDongle-E; methods such as slzb07, yellow, ihost and baudrate exist for particular hardware. Do not copy one model’s reset method to another.
python -m pip install universal-silabs-flasher universal-silabs-flasher --device "/dev/serial/by-id/REPLACE_WITH_YOUR_DONGLE_ID" \ --bootloader-reset rts_dtr \ flash --firmware "/path/to/your-zbdongle-e-zigbee-ncp-firmware.gbl"
The filename above is deliberately not a downloadable image. Obtain the correct Zigbee coordinator/NCP .gbl for your exact hardware from a source linked by the adapter vendor or Zigbee2MQTT. Confirm baud rate and flow control before restarting. A Thread, router or incompatible multiprotocol image does not serve the same purpose. Newer flasher device profiles may provide a model-specific route; check the installed tool’s help and current README.
For a network-connected SMLIGHT, the Ethernet coordinator setup and the manufacturer’s updater may be more relevant than a USB command. Read the update dialog for any option that erases radio NVM: do not treat an erase as an ordinary state-preserving upgrade. Use the correct radio image and keep core firmware and radio firmware distinct.
The ConBee/RaspBee path: use Dresden’s instructions
Dresden Elektronik documents GCFFlasher for ConBee I, II and III and RaspBee I and II. Select the image for the exact model. ConBee II and ConBee III do not take interchangeable firmware.
The tool choice is a product and bootloader question, not a reliable shorthand for chip family. The ConBee III specification identifies a Silicon Labs EFR32MG21, despite the vendor’s GCFFlasher update route. It ships with Zigbee firmware and offers an alternative OpenThread application; switching to that is a protocol change, not an upgrade that preserves a Zigbee coordinator’s function.
Follow the vendor’s device-selection and update sequence, stopping other radio users first. A host data-directory copy remains worthwhile, but Zigbee2MQTT does not document ConBee backup/restore as equivalent to its zstack and ember support.
The TI/Z-Stack path
Sonoff ZBDongle-P and the original SLZB-06 use TI radios and Z-Stack coordinator firmware. The supported-adapter index links to the model-specific flashing route. Depending on the hardware, that may be a vendor web updater, a serial bootloader tool or a debugger-based method.
The commonly linked cc2538-bsl is a community serial-bootloader tool for supported TI chips, not a Texas Instruments-owned universal updater. Confirm bootloader access and the exact board/chip image before using it. A CC2652P file, an EFR32 .gbl and a ConBee image are not interchangeable.
| Update route | Examples | What to verify |
|---|---|---|
| Ember NCP | Connect ZBT-1/SkyConnect, ZBDongle-E, SLZB-07, SLZB-06M | Supported Ember branch, exact board image, reset method and serial settings; universal-silabs-flasher is one option |
| Dresden product firmware | ConBee II, ConBee III, RaspBee | GCFFlasher procedure and model-specific firmware; chip vendor alone does not select the tool |
| TI Z-Stack | ZBDongle-P, unsuffixed SLZB-06 | Exact chip/board and vendor updater or supported bootloader tool |
What the SLZB-06 failure reports show
Issue #27560 reports that an SLZB-06 with Zigbee2MQTT 2.3.0-1 would not start after radio firmware 20250325. The owner then generated a new PAN ID, which changed the recovery situation, and reported unsuccessful recovery attempts. That is a reason to preserve state and investigate startup errors before generating a new network; the report does not prove that every update to that image destroys a mesh.
Issue #31329 is a different case: Zigbee2MQTT 2.6.2, SLZB core v3.0.8 and an automatically installed radio update to 20260307. The owner reported that rollback restored operation. Its log shows a TCP connection followed by a radio-protocol timeout. A reachable network socket does not mean the radio firmware is responding correctly.
These are version-specific reports, both now closed. They establish reported failures, not their frequency or a universal present-day defect. Keep the old configuration and network identity intact while checking firmware compatibility, serial settings and the vendor’s recovery instructions.
On SMLIGHT hardware, check the selected firmware channel and automatic-update setting as well as the offered version. The Home Assistant SMLIGHT integration documents separate core and Zigbee update entities and an automatic Zigbee-update switch. Update visibility depends on your hardware and integration; checking versions is not limited to reading a generic GitHub changelog.
Will you need to re-pair?
Normally, a compatible firmware update on the same coordinator preserves the network, so devices should not need re-pairing. Give the mesh time to settle and check reporting and commands. If devices are slow to respond, follow the FAQ’s recovery checks before assuming their pairings are lost.
Erasing coordinator storage, deliberately changing the network key or PAN ID, switching to a different radio protocol, and some adapter migrations can require re-pairing. A backup may help when the adapter and firmware support restoration; missing a backup is not the only possible reason re-pairing becomes necessary. If the radio starts correctly but device records appear duplicated or unresponsive, the ghost-device guide covers that separate investigation.
FAQ
Should I update a stable coordinator? Review the release notes for security, compatibility and relevant fixes. Plan a maintenance window and recovery route if an update is warranted; do not flash solely because another model has a higher version number.
Can an update break the network? Yes. Incompatible images, erased state, changed settings and firmware defects can interrupt it. Dated reports show that failures occur, but do not measure the risk of your exact upgrade.
Does every coordinator have a restorable backup? No. Zigbee2MQTT documents adapter backup/restore for zstack and ember. Save the full host configuration regardless, then check the recovery support for your adapter.
Can I use the same tool for every Silicon Labs radio? No. Use the adapter vendor’s supported procedure. ConBee III uses an EFR32MG21 but has Dresden’s firmware/update route; that does not make a ZBDongle-E image or command appropriate.
What should I check afterward? Confirm the expected radio version, driver connection, unchanged network identity, commands and reporting from representative mains-powered and battery devices. Keep the pre-update files and known-good firmware until normal operation is established.
Sources and practical limits
The linked adapter documentation, flasher repositories and original issue reports support the procedures and distinctions here. No hardware was flashed for this guide. The command is a syntax pattern, not a tested instruction for an unidentified adapter. Firmware can be built and published by a manufacturer or a community maintainer using the chip vendor’s stack; check the provenance of the exact image rather than assuming every build comes directly from the chip vendor.
The radio can operate locally after installation, but obtaining tools, images and release notes usually needs internet access. Vendor web update flows may fetch images online too. Downloading a file and flashing it locally are separate steps. While arranging maintenance, review the setup’s MQTT and frontend security as well.