Painless Zigbee2MQTT Coordinator Migration Guide: Sonoff Dongle-E to SLZB-MR3

Moving your Zigbee network to new hardware always sounds scarier than it should be, and this Zigbee2MQTT coordinator migration guide exists because I wanted a clear, no-fluff answer to one question: how do you move an entire Zigbee2MQTT network from a SONOFF Zigbee 3.0 USB Dongle-E Plus (EFR32MG21, running the legacy ezsp driver) to a SMLIGHT SLZB-MR3 (CC2674P10, zstack) without re-pairing every single device in the house? This Zigbee2MQTT coordinator migration guide is written from real logs, real errors, and real screenshots — not a clean, theoretical happy path. 🏠

The short answer: it’s possible, it’s not officially guaranteed, and there’s one critical detail that will break your restore if you skip it. This Zigbee2MQTT coordinator migration guide walks through the whole process, in the order that actually matters. Let’s go through it step by step.

Why Move From Sonoff Dongle-E to SLZB-MR3 in the First Place

The Sonoff Dongle-E Plus is a solid, cheap USB stick — but it’s still a USB stick plugged directly into your Home Assistant host, which means antenna placement is fixed to wherever that box sits. The SLZB-MR3 changes that: it’s a network-attached coordinator (Ethernet/PoE/USB-C/Wi-Fi) with a +20 dBm amplifier and dual radio (CC2674P10 for Zigbee, EFR32MG24 for Thread/Matter), so you can place it in the middle of your house instead of next to your server rack, and you get independent Zigbee and Thread radios in one box. It’s also SMLIGHT hardware designed in Ukraine, which is a nice bonus if that matters to you. 🇺🇦

The One Thing That Will Ruin Your Migration

Here’s the part most people miss, and it’s the reason this Zigbee2MQTT coordinator migration guide starts with a warning instead of a shopping list.

⚠️ Critical: Zigbee2MQTT’s official backup-and-restore mechanism (coordinator_backup.json) is only implemented for the zstack (Texas Instruments) and ember (Silicon Labs) adapter drivers. It is explicitly not supported for ezsp, conbee, zboss, or zigate. Since your current config uses adapter: ezsp, Zigbee2MQTT cannot generate a valid backup to restore onto the SLZB-MR3 as-is. This is stated directly in the official FAQ (zigbee2mqtt.io/guide/faq).

The fix is simple and doesn’t touch your hardware at all: ezsp and ember are two different Zigbee2MQTT drivers for the same Silicon Labs EFR32 chip family — switching between them on the same Sonoff dongle is a configuration change, not a firmware flash. Once you’re running ember against your existing Sonoff Dongle-E, Zigbee2MQTT treats the later Sonoff→SLZB-MR3 move as an ember → zstack migration, which the community has reported working reasonably well even though it’s still officially “unsupported.”

What You Need Before You Start This Zigbee2MQTT Coordinator Migration Guide

• The SLZB-MR3 already updated to a recent SLZB-OS build and reachable on your LAN (you already have its Zigbee TCP endpoint: tcp://192.168.1.220:7638) — this Zigbee2MQTT coordinator migration guide assumes that part is already done
• Zigbee2MQTT updated to the latest version — this is a hard requirement per the official migration guide
• Access to your Home Assistant add-on config, either via the File Editor / Samba add-on or SSH
• A full Home Assistant backup/snapshot taken before you touch anything — if this migration goes sideways, you want a one-click way back
• Patience for the “some devices may need a power cycle or re-pair” part — this is normal, not a sign you did something wrong

Step-by-Step: Zigbee2MQTT Coordinator Migration Guide

Step 1 — Switch the current Sonoff Dongle-E from ezsp to ember

In your configuration.yaml, change only the adapter line:

serial:
  port: /dev/ttyUSB0
  adapter: ember

Leave everything else (channel, network_key, pan_id if set) untouched. Restart Zigbee2MQTT and confirm your existing devices still report state normally. This step is the whole reason this Zigbee2MQTT coordinator migration guide works at all — without it, there’s no backup to restore later.

⚠️ In practice, this switch alone will probably fail on stock firmware. Here’s exactly what happened when I tried it during this Zigbee2MQTT coordinator migration guide, and how I fixed it — this is the part most other guides skip.

Error #1 — firmware too old for ember:

Error: Adapter EZSP protocol version (8) is not supported by Host [13-19].

This means the Sonoff Dongle-E Plus was still running its old factory EmberZNet firmware, which only speaks EZSP protocol v8. The ember driver requires EZSP v13, which only exists in EmberZNet NCP firmware 7.4.x and later. This isn’t a one-off — the identical error is documented in the Zigbee2MQTT repository itself: GitHub issue #25260, and the official adapter documentation states this requirement directly (zigbee2mqtt.io/guide/adapters/emberznet.html).

The fix: flash new EmberZNet NCP firmware (7.4.4 or newer, per the official docs) onto the Sonoff Dongle-E Plus before the ember driver will start — skipping this is the single most common way to get stuck on this Zigbee2MQTT coordinator migration guide. Two documented ways to do this:

1. Without unplugging the stick from your Home Assistant host — SONOFF’s official “SONOFF Dongle Flasher” add-on (via the iHost Open Source Project repository, https://github.com/iHost-Open-Source-Project/hassio-ihost-addon) flashes over the same USB connection and stops the conflicting service (Z2M) automatically if the port is busy (dongle.sonoff.tech guide).
2. With a PC — unplug the dongle from the Home Assistant host, plug it into a Windows/Mac/Linux machine running Chrome or Edge, and use the community WebSerial flasher at darkxst.github.io/silabs-firmware-builder.

Community reports (not an official guarantee) say this firmware upgrade does not wipe your paired devices, since the network data lives in a separate flash region from the radio firmware — but take a Home Assistant backup first regardless, per the prerequisites above.

Error #2 — after flashing, ezsp itself refuses to start:

Error: 'ezsp' driver is not compatible with firmware 8.x.x or above (EZSP v14+). Use 'ember' driver instead.

This is actually good news: it confirms the firmware flash worked. The ezsp driver now refuses to talk to firmware this new, and is explicitly telling you to switch to ember. This exact message is also documented in the Zigbee2MQTT repository: GitHub issue #26700 and GitHub issue #31504.

The fix: apply the adapter: ember config change from the top of this step now — this time it should start cleanly. Confirm via Settings → About in the Zigbee2MQTT frontend that the coordinator firmware version shows 7.4.x or newer and that no ember startup errors appear in the log. Once this starts cleanly, the hardest part of this Zigbee2MQTT coordinator migration guide is already behind you.

Step 2 — Confirm a coordinator backup exists

With ember running, Zigbee2MQTT will maintain coordinator_backup.json inside its data folder (/addon_config/zigbee2mqtt/ for the Home Assistant add-on). Open the frontend → Settings → Tools, or check the folder directly via Samba/SSH, and confirm the file is recent (its timestamp should update automatically as the network changes). Without this file, the rest of this Zigbee2MQTT coordinator migration guide has nothing to restore from, so don’t skip the check.

Step 3 (optional, recommended) — Copy the old IEEE address onto the SLZB-MR3

Some Zigbee devices remember the coordinator by its IEEE address rather than just its network parameters, and if that address changes they can silently stop routing through it correctly. Zigbee2MQTT’s own documentation recommends writing the old coordinator’s IEEE address onto the new one before switching (zigbee2mqtt.io/guide/adapters/flashing/copy_ieeaddr).

You do not need a third-party flashing tool for this. Both halves of the job are already built into software you’re already running.

Step 3a — Read the current IEEE straight from the Zigbee2MQTT frontend

Once ember is running (from Step 1), open the Zigbee2MQTT frontend → Settings → About. The Coordinator panel shows the driver (EmberZNet), the IEEE address, and the firmware revision directly — no separate tool, no browser restrictions, no unplugging anything. Write this address down exactly as shown.

Step 3b — Write that IEEE onto the SLZB-MR3 through its own web interface

The SLZB-MR3 runs SLZB-OS, and SLZB-OS ships a built-in IEEE tool on its own Z2M and ZHA settings page, in a section called “ADVANCED: Adapter IEEE address change.” It exposes exactly four actions: Read factory IEEE, Read current IEEE, Flash custom IEEE address, and Write IEEE address (SMLIGHT Manuals — Zigbee2MQTT / ZHA Settings).

Two things the same documentation states explicitly, worth repeating so you don’t get caught out:

• ⚠️ Using IEEE read/write (or a Zigbee network scan) breaks your current Z2M/ZHA connection — stop Zigbee2MQTT before touching this section
• ⚠️ This tool does not work in USB mode — the SLZB-MR3 needs to be in its Ethernet/network mode, which is already the case for your tcp://192.168.1.220:7638 setup

Paste the IEEE address from Step 3a into the “Flash custom IEEE address” / “Write IEEE address” fields, confirm, and restart Zigbee2MQTT with the SLZB-MR3 configuration from Step 5 below.

If this feels like too much for a first migration, you can skip it entirely — most devices will still rejoin without it, just with slightly higher odds of a stray re-pair.

Step 4 — Stop Zigbee2MQTT

Do this from the Home Assistant add-on page, not by pulling power on the Sonoff dongle mid-write.

Step 5 — Update the configuration for the SLZB-MR3

Replace the serial and advanced blocks with the values SMLIGHT’s own web interface already gave you:

serial:
  port: tcp://192.168.1.220:7638
  baudrate: 115200
  adapter: zstack
  disable_led: false

advanced:
  transmit_power: 20

+20 dBm is the documented maximum for the CC2674P10 radio, so that value is safe as-is. Because you’re still running the same Home Assistant add-on installation, coordinator_backup.json stays exactly where Zigbee2MQTT expects it — you don’t need to move any files for this part of the Zigbee2MQTT coordinator migration guide to work.

Step 6 — Swap the hardware

Physically disconnect the Sonoff Dongle-E Plus and make sure the SLZB-MR3 is powered and reachable at 192.168.1.220:7638. Everything before this point in the Zigbee2MQTT coordinator migration guide was preparation; this is the point of no easy return.

Step 7 — Start Zigbee2MQTT and watch the log

This is the moment where the ember → zstack restore either takes cleanly or doesn’t. Watch the Zigbee2MQTT log closely:

• If it logs a successful restore from coordinator_backup.json, your devices should start reporting within a minute or two without any re-pairing
• If instead you see network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby, herdsman is trying to create a new network instead of restoring the old one — this is a known rough edge in cross-chip-family migrations and usually means the pan_id/ext_pan_id/network_key in your configuration.yaml don’t explicitly match what’s in the backup. Setting them explicitly to the old values (visible in coordinator_backup.json) before starting again is the usual fix

Verifying the Zigbee2MQTT Coordinator Migration Guide Steps Worked

• Open the Zigbee2MQTT frontend and check that your device list is intact — this is the moment this Zigbee2MQTT coordinator migration guide either pays off or tells you where to go back and re-check a step
• Mains-powered routers (bulbs, plugs, in-wall switches) are the most forgiving — a lot of community reports confirm they simply rejoin on their own once power-cycled, since the NWK-layer bookkeeping differs slightly between the ember and zstack stacks
• Battery-powered end devices (door/window sensors, buttons) are the ones most likely to need a manual re-pair — this doesn’t mean the whole migration failed, just that those specific devices didn’t survive the stack change
• If new pairing doesn’t work at all, run a coordinator check (zigbee2mqtt/bridge/request/coordinator/check via MQTT) and re-pair a router close to the coordinator first — pairing through that re-paired router usually unblocks the rest

Zigbee2MQTT Coordinator Migration Guide: Troubleshooting Notes

• Give the network a few minutes to settle before assuming a device is dead — this applies to any coordinator swap covered by this Zigbee2MQTT coordinator migration guide, not just cross-family ones
• If devices show correct cached state in the frontend but nothing actually responds, the coordinator’s radio firmware/NVRAM may be corrupted rather than the migration itself being at fault; reflashing the CC2674P10 firmware via SLZB-OS forces a clean chip state and has resolved this exact symptom for other users
• Don’t touch network_key or pan_id “just to see” — either of those forces a full re-pair of every device, which is exactly what this whole Zigbee2MQTT coordinator migration guide is trying to help you avoid
• 🥫 The weirdest fix that actually worked: if Zigbee2MQTT refuses to start with network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby, try unscrewing both antennas from the SLZB-MR3 and wrapping the unit in aluminum foil before starting Zigbee2MQTT. This isn’t superstition — it’s a direct consequence of how commissioning actually works. Per zigbee-herdsman issue #286, forming a new network involves sending a Beacon Request and listening for replies to check whether the configured PAN ID is already in use nearby. The catch: routers, not just coordinators, answer that Beacon Request if they’re still part of a network (Digi’s Zigbee network discovery docs confirm this explicitly). If your old mains-powered routers are still plugged in, they still remember the old pan_id and will answer “yes, this network exists” — which is your own leftover network, not a stranger’s. Cutting the antennas stops the new coordinator from hearing those replies during the scan, so it proceeds to commission successfully. Reattach the antennas afterward and bring routers back online one at a time. Documented working in the wild on this exact hardware in GitHub discussion #27423.

Zigbee2MQTT Coordinator Migration Guide: Quick Checklist

• [ ] Switch Sonoff Dongle-E from ezsp to ember, confirm devices still work
• [ ] Confirm coordinator_backup.json is current
• [ ] (Optional) copy old IEEE address onto the SLZB-MR3 with XZG Multi-Tool
• [ ] Take a Home Assistant backup
• [ ] Stop Zigbee2MQTT, update configuration.yaml to the SLZB-MR3’s zstack settings
• [ ] Swap hardware, start Zigbee2MQTT, watch the log for a restore vs. a fresh network
• [ ] Power-cycle mains routers that don’t respond; re-pair battery devices that don’t come back

Following this order is what makes an unsupported migration path behave, in practice, a lot like a supported one. It won’t be 100% painless for every device on a 60+ node network, but it’s a long way from resetting your whole smart home from scratch. 🔋

Related Reading on vahac.com

If Zigbee reliability is a running theme for you too, these might help:

• Kitchen light with a MOES Zigbee knob in Home Assistant
• Syncing two Matter lights in Home Assistant
• Home Assistant 2026.4: new features and areas dashboard

A Note on Accuracy for This Zigbee2MQTT Coordinator Migration Guide

Backup-and-restore across chip families (ember ↔ zstack) is explicitly labeled “not officially supported” by the Zigbee2MQTT project itself — it works for most people, most of the time, based on community reports, not a guarantee. If your network has devices you genuinely cannot afford to re-pair, budget time for a manual fallback and don’t schedule this migration right before you need the network to behave perfectly.