I just finished migrating my ZHA coordinator from a SONOFF Zigbee 3.0 Dongle-M to a SMLIGHT SLZB-MR4U over LAN (socket mode), and since I couldn’t find a complete, accurate guide anywhere, here’s what I learned — including the actual root cause of a persistent “Connection failed” error that isn’t covered anywhere I could find.
Hardware background
SLZB-MR4U is a dual-radio device: an EFR32MG26 for Thread/Matter and a CC2674P10 (Texas Instruments Z-Stack) for Zigbee. Don’t confuse the two ports in the “Serial Options” page — on my unit the Zigbee radio was on port 7638, not the commonly-cited “default” 6638 (that port was actually assigned to the Thread/Matter radio). Check both explicitly before assuming.
Correct ZHA settings for the Zigbee radio
- Radio type: ZNP (Texas Instruments Z-Stack) — NOT EZSP/bellows, even if your old coordinator was EZSP-based (e.g. the Dongle-M is Silicon Labs EFR32-based, not the same chip family despite both being “SONOFF/SMLIGHT Zigbee sticks”).
- Flow control: none — confirmed by the device’s own “hardware flow control” toggle being off. Software flow control is wrong for this chip/bridge combination and will corrupt binary frames.
- Baud: 115200.
- Firmware: check the update panel carefully — the “latest coordinator release” isn’t always the top item; newer entries are often explicitly marked as dev/beta firmware, and at least one beta build is documented to force a PAN ID change on flash. Don’t blindly update.
The actual blocker: IEEE address mismatch
Even with all of the above correct, and with the TCP port itself confirmed reachable (Test-NetConnection/nc to IP:7638 succeeded), both the automatic and manual ZHA migration flows failed with a generic “Connection failed”, no further detail in the UI.
The cause: the new coordinator’s IEEE address is fixed in its own hardware/firmware and differs from the old one. Zigbee end devices and routers keep the coordinator’s IEEE address in their own binding/routing tables — a network-key/PAN-ID/channel restore alone isn’t enough to make them treat the new radio as “the same” coordinator. ZHA’s migration flow is supposed to include a step to permanently overwrite the new radio’s IEEE address with the old one, but for this hardware combination that step never appeared (this seems to be a recurring theme — see this thread about the same missing step during SkyConnect migrations: ZHA SkyConnect Migration missing Permanently replace the radio IEEE address step).
Working fix
- Note the old coordinator’s IEEE address (ZHA → coordinator device info).
- On the SLZB-MR4U’s own web UI (SLZB-OS), find the IEEE address field for the Zigbee radio and set it to the old coordinator’s address, with the colons removed. Save.
- In ZHA, start “Migrate radio” → manual migration, enter the socket://: connection string for the new radio — but don’t click Next yet.
- Power off the old coordinator now.
- Click Next. ZHA will complain it can’t factory-reset the old adapter — expected, since it’s now unreachable. Proceed anyway.
- Finish the migration, restore the correct backup (the one taken from the old coordinator, not a newer one from a failed attempt), rename the device if you like.
Since doing this, the network has been fully stable with zero dropouts.
One important caveat: don’t ever power the old coordinator back on with its original IEEE address while the new one is using the same identity — that’s a guaranteed IEEE collision on the mesh. If you want to reuse the old stick for something else later, reset/change its IEEE first.
Hope this saves someone else the troubleshooting time it cost me.