When to Update Zigbee Coordinator Firmware and When to Leave It Alone: An EZSP Version Decision Tree

The question behind the question

Most “should I update my coordinator firmware?” threads start with a symptom, not a version number. Someone’s network drops a sensor every few days, or Zigbee2MQTT won’t start after a host upgrade, and the first instinct is to flash the dongle. That instinct is usually wrong, and occasionally it’s the only thing that works. The difference is whether you can name the gate you’re passing through.

This is a decision tree for EZSP coordinators — Silicon Labs EmberZNet radios running under Zigbee2MQTT or ZHA. It is not a firmware changelog. I can’t give you one, because the Silicon Labs release notes I’d need to cite didn’t retrieve cleanly, and I won’t invent what a given build fixes. What I can give you is the compatibility gate that is documented, the driver migration that masquerades as a firmware question, and a backup-first procedure for when you do decide to flash.

The default position is: leave it alone. A coordinator is the least replaceable component in your mesh. Flashing it is a change to the one device every other device depends on. “A newer version exists” is not a reason. Three conditions are.

Gate 1: Are you inside the supported window?

Start by reading your current coordinator revision. In Zigbee2MQTT it’s under Settings → About → Coordinator revision. In ZHA it’s on the Network information page under Settings → Connectivity → Zigbee. Write the exact string down before you touch anything.

Zigbee2MQTT’s EmberZNet adapter page lists the currently supported firmware versions as 7.4.x, 8.0.x, 8.1.x, 8.2.x, 9.0.x, and 9.1.x (Zigbee2MQTT EmberZNet adapter documentation). If you’re inside that window and your network is stable, no gate has fired yet. Keep reading, but the burden of proof is on the update.

If you’re below 7.4.x, the decision is made for you. The ember driver — now the recommended driver for EmberZNet adapters — requires EZSP v13, which corresponds to EmberZNet 7.4.x. Zigbee2MQTT logs this explicitly: “NCP EZSP protocol version of XX does not match Host version 13: ember currently requires a firmware with EZSP v13 (EmberZNet firmware 7.4.x). You will need to upgrade your adapter’s firmware.” That’s not a suggestion. It’s a hard floor.

One caveat on the supported list: it’s a statement of what the driver supports, not a claim that every version in the window is better than every other. The list tells you where the walls are. It doesn’t tell you the floor is more comfortable than the ceiling.

Gate 2: Are you actually migrating drivers?

This is the misdiagnosis I see most often. Someone on a 7.3.x dongle running the old ezsp driver sees a deprecation warning at startup and reads it as “update firmware.” What they’re actually facing is a driver migration, and the firmware flash is a prerequisite, not the goal.

The maintainer discussion is unambiguous: the ember driver is now the recommended way to use EmberZNet-based adapters, and the ezsp driver is deprecated but kept for old firmware support (pre-7.4.x) (Zigbee2MQTT discussion #21462). When the ember driver was introduced, it supported only EmberZNet firmware 7.4.x (EZSP 13); older versions were not supported.

So if you’re on ezsp below 7.4.x, treat the firmware flash and the driver switch as one change with one rollback plan. Don’t flash to 7.4.x, stay on ezsp, and call it done — you’ve done half a migration and gained nothing. And don’t switch to ember without flashing first; it will refuse to start.

There’s a framing detail worth knowing if you’re coming from much older hardware. The bellows README documents that EZSP v5, v6, and v7 share a framing format, but EmberZNet 6.7.x.x / EZSP v8 introduced a new framing format and expanded the command ID field from 8 to 16 bits, and is not backward compatible (zigpy/bellows README). That’s the kind of break that makes “just flash it” a bad idea on very old sticks. If your coordinator predates EZSP v8, you’re not doing a routine update; you’re crossing a protocol boundary.

Gate 3: Is there a concrete symptom?

If you’re inside the supported window and already on ember, the only remaining reason to flash is a symptom that a firmware change plausibly addresses. Not a vibe. A symptom.

What counts:

Startup loops or NCP fatal errors. Zigbee2MQTT logs “NCP Fatal Error” when the coordinator fails, attempts a reset, and stops the service if the reset doesn’t take. That’s a real failure mode, and it’s worth investigating.
Repeated delivery failures to specific devices that survive a channel change, a router addition, and a re-pair. The ember page notes that a few network/route errors over time are expected, and too many too often indicate a problem in your network — which is not the same as a problem in your firmware.
A documented incompatibility between your firmware and a device class you actually own. This is where I have to stop: I can’t tell you which build fixes which device, because the release notes didn’t retrieve. If you’re chasing a specific bug, the release notes are the source, not this article.

What doesn’t count:

A newer version exists.
Someone on a forum said 8.x is “more stable.”
You’re bored on a Sunday.
You haven’t checked whether the problem is interference, a weak router, or a serial connection issue. ZHA’s documentation is explicit that running a coordinator through a serial proxy over Wi-Fi, WAN, or VPN is not recommended, because the coordinator needs a stable local serial connection without drops (Home Assistant ZHA integration docs). If your dongle is behind a Wi-Fi bridge, fix that before you flash anything.

If no gate has fired, the tree says: leave it alone. Note the version in your maintenance log and revisit only when a symptom appears or the supported window moves past you. This is the branch most people should take, and it’s the one nobody writes forum posts about.

The backup-first procedure

If you’ve passed a gate, the actual skill being tested is backup discipline, not version selection. A coordinator backup taken before the flash, stored off the host, and verified to exist is worth more than any heuristic about which build to pick. If you can’t produce that file, you’re not ready to flash.

Zigbee2MQTT’s ember driver only supports EZSP v12 and above backups. Older backup files are renamed automatically, and a new one is created on successful start (EmberZNet adapter docs). So check the EZSP version inside coordinator_backup.json before you rely on it. A v11 backup is not a rollback plan; it’s a file with a misleading name.

The sequence:

Record the current revision string exactly. Screenshot it. You will want to compare after.
Take a coordinator backup and copy it off the host. Verify the file exists and opens. Note the EZSP version inside it.
Download the target firmware file and keep it locally. Don’t rely on a URL that might move.
Flash one adapter. Not two. Not the spare “while you’re at it.”
Verify the coordinator revision in the UI matches what you intended to flash. If it doesn’t, stop and diagnose before re-pairing anything.
Re-pair only devices that fail to rejoin. Don’t preemptively re-pair the whole network. Most devices will find their way back; the ones that don’t will tell you.

On the backup caveat: bellows warns that NVRAM backup and restore is a highly experimental feature, that it can migrate between different radio hardware only if they’re based on the same chip, and that restoring to different hardware produces a different EUI64, which makes the binding tables on all your devices wrong (bellows README). Read that twice if you’re planning to move a backup onto a replacement dongle. Same chip, or expect to re-pair.

One more thing the docs are clear about: Home Assistant does not update firmware on third-party adapters, and users should use the manufacturer’s tools (ZHA docs). That means the flashing tool is your responsibility, and so is knowing which file is correct for your specific model. The Zigbee2MQTT adapter page lists per-model firmware and flashing tools; don’t generalize a baud rate or flow-control setting from one board to another.

Graceful degradation when the flash goes wrong

Plan the maintenance window around the worst case, not the best case. The worst case is: the flash completes, the coordinator boots, and the network doesn’t come back cleanly. What you want on hand before you start:

The previous dongle as a known-good spare. If you’re replacing rather than reflashing, keep the old one. If you’re reflashing in place, this doesn’t apply — which is an argument for having a spare on the shelf if your household depends on the mesh.
The previous firmware file, locally. Rollback is a flash in the other direction. I’m not going to give you step-by-step rollback instructions for a specific adapter, because the retrieved sources don’t establish them and the procedure varies by board and bootloader. Check your adapter’s documentation.
The backup, verified, off-host. If the flash bricks the stick, the backup is what lets you restore onto a replacement of the same chip without re-pairing everything.
An honest acceptance that re-pairing may be required. If the backup is incompatible or the hardware differs, you may be re-pairing devices. Budget the time for that, not for the flash.

There’s a failure mode worth naming because it’s documented and it’s not firmware: a zigbee-herdsman issue reports that EZSP recovery can strand device commands when AsyncMutex.clear() drops waiting promises (zigbee-herdsman issues). I’m citing it as an example of a coordinator-layer problem that a firmware flash won’t fix, not as a claim that it’s caused by or fixed by any firmware version. The point is that “coordinator trouble” and “firmware trouble” are not the same set, and the logs are how you tell them apart.

Two worked examples, clearly hypothetical

These are illustrations of the tree, not case records.

Example A: the 7.3.x dongle. A reader on a 7.3.x EZSP v12 dongle running the ezsp driver sees the deprecation warning at startup. The tree says: Gate 1 fires (below 7.4.x), Gate 2 fires (driver migration). This is not an optional update. Take a backup, confirm it’s v12 or above, flash 7.4.x, switch serial.adapter to ember, verify the coordinator revision, and re-pair only devices that fail to rejoin. There is at least one user report of exactly this migration on a SONOFF ZBDongle-E from 7.3.1.0 build 176 to 7.4.1, with the coordinator showing EmberZNet 7.4.1 afterward and the user reporting it worked fine (discussion #23020). One report is one report. It’s evidence that the path exists, not a guarantee about your network.

Example B: the stable 7.4.2 network. A reader on 7.4.2 with a stable network and no symptoms asks whether to move to 8.x. The tree says: no gate has fired. Leave it alone. Note the version in the maintenance log and revisit only if a symptom appears or the supported window moves past you. If they flash anyway and something breaks, they’ve traded a known-good state for an unknown one with no diagnostic question to answer.

What the tree can’t tell you

It can’t tell you which firmware version fixes a specific bug, because the release notes didn’t retrieve and I won’t fabricate them. It can’t tell you whether your particular backup will restore cleanly onto a newer EZSP version in practice, beyond the documented statement that v12+ backups are supported. It can’t give you adapter-specific rollback steps. And it can’t tell you whether a firmware update is safe — no update is risk-free, and anyone who says otherwise is selling something.

What it can tell you is the order to ask the questions: read your revision, compare against the supported window, check whether you’re on ezsp or ember, and only then decide. Doing it in reverse — flashing first, diagnosing later — is how people end up re-pairing sixty devices on a Sunday.

If you’re auditing the small systems that quietly run your week, this is one of them. A coordinator firmware decision is a maintenance decision, and it belongs in the same log as your other maintenance decisions. If you haven’t built that log yet, the audit guide at How to Audit the Small Systems That Quietly Run Your Week is the place to start.

FAQ

My coordinator is on 7.4.x and stable. Should I move to 8.x or 9.x?

Not unless a gate fires. The supported list includes 8.x and 9.x, but “supported” means the driver will talk to it, not that it’s better for your network. If you have no symptom and no documented incompatibility, the tree says leave it alone.

Can I switch to the ember driver without flashing firmware?

Only if you’re already on 7.4.x or above. The ember driver requires EZSP v13 (EmberZNet 7.4.x); below that, it will refuse to start and log the version mismatch.

Will I have to re-pair my devices after flashing?

Maybe. A compatible backup restored onto the same chip should preserve the network. A backup restored onto different hardware produces a different EUI64 and breaks binding tables, per the bellows README. Plan for the possibility rather than assuming either outcome.

Is multiprotocol firmware an option?

Zigbee2MQTT’s EmberZNet page states that multiprotocol firmware is not supported, and recommends one adapter per protocol instead. If you’re considering it to run Zigbee and Thread on one radio, the documented position is to use two radios.

Where do I find the firmware for my specific adapter?

The Zigbee2MQTT EmberZNet adapter page lists per-model firmware repositories and flashing tools. Use the entry for your exact model; don’t carry a baud rate or flow-control setting over from a different board.