Just finished migrating Zigbee2MQTT from a Nabu Casa SkyConnect v1.0 to a Sonoff/Nabu Casa ZBT-2 (37+ devices, live network), then reflashed the freed-up SkyConnect as a Thread border router for Matter. Posting the full story in case it saves someone else the hours it cost me none of these were exotic problems, but none of them were obvious either.
**Setup:** HAOS, Zigbee2MQTT add-on, SkyConnect v1.0 on `/dev/ttyUSB0` (EZSP), ZBT-2 physically present but unused on `/dev/ttyACM0`.
Problem 1 Neither adapter would connect, not even the one that used to work
Swapped `serial.port` to the ZBT-2’s `/dev/serial/by-id/…` path, restarted. Got:
```
Failure to connect
{“sequence”:-1} after 10000ms
```
Crash-looping every ~75s. Tried: full add-on restart, `rtscts: true`, explicit baud rate, even a full host reboot. Nothing worked and falling back to the SkyConnect config now **also** failed with the identical error.
**Root cause:** a leftover *disabled* ZHA integration entry, still bound to the SkyConnect’s USB device from before I’d switched to Zigbee2MQTT. Even disabled, it silently held the port and blocked both adapters. The Supervisor panel actually hinted at this (“same port used by multiple apps”) but it’s easy to skim past.
**Fix:** delete the stale ZHA config entry (not just disable it) `Settings’ Devices & Services`. SkyConnect reconnected immediately.
If you’ve ever run ZHA before switching to Z2M (or vice versa), check for a leftover integration entry before you touch anything else.
Problem 2 ZBT-2 still wouldn’t connect, `dmesg` looked like a bad cable
With the ZHA conflict gone, SkyConnect worked fine again, but the ZBT-2 kept failing identically. `dmesg` showed real USB enumeration trouble on every plug-in:
```
Device not responding to setup address.
device not accepting address N, error -71
```
Tried a new cable, a different USB port same error every time (though it did always eventually enumerate on retry).
**Root cause (two things, don’t conflate them):**
- The USB enumeration hiccup was a red herring.
- The actual problem was `adapter: ezsp` in the serial config the legacy zigbee-herdsman EZSP driver. The ZBT-2’s EmberZNet NCP firmware (7.x+) wants the newer `adapter: ember` driver instead. Wrong driver = identical generic timeout, no useful error message.
**Fix:**
```yaml
serial:
port: /dev/serial/by-id/usb-Nabu_Casa_ZBT-2_-if00
adapter: ember # not ezsp
baudrate: 460800
rtscts: true
```
(Also did a clean firmware reinstall via the Hardware page first, in case the flash itself was incomplete can’t hurt.)
`ezsp` vs `ember` is the single thing that cost me the most time. If a Silicon Labs/EmberZNet adapter won’t connect, check this **before** you start suspecting hardware.
Problem 3 Bridge connected, but all 37+ devices vanished
Once Z2M connected to the ZBT-2, `database.db` (the local device table) got reset to just the coordinator entry. Every paired device gone from HA even though `pan_id`/`ext_pan_id`/`channel`/`network_key` were correctly restored from `coordinator_backup.json`.
**Root cause:** the coordinator backup only restores *network-level* identity. It can’t restore the physical coordinator’s IEEE address (unique per chip). zigbee-herdsman saw a different coordinator IEEE and treated it as a new network, wiping its device bookkeeping even though every device was still on the network and still trusted the (correctly restored) key.
**Fix:** Z2M auto-writes `database.db.backup` right before it overwrites the live file. Recovery:
- Stop the add-on.
- Take the **Coordinator** entry from the freshly-reset `database.db` (correct new IEEE).
- Take every **non-Coordinator** entry from `database.db.backup` (your old device list).
- Concatenate and write back as `database.db`.
- Start. Everything reappears, nothing needs re-pairing.
Know this exists *before* you swap coordinators. Without it, this looks exactly like “time to re-pair everything.”
Problem 4 ~80 broken entity references across automations/dashboards
Devices were back, but a lot of them came back under new default entity_ids instead of my old customized ones (e.g. `sensor.garage_droger_power`’ `sensor.droger_power`). Four `switch_as_x` helpers (switch exposed as light/fan) were also wiped.
**Fix:** cross-referenced a Z2M device export (IEEE name) against Home Assistant’s Repairs panel (“unknown entity” list) to rebuild the mapping, verified each one against live state (caught two different fridges that could’ve been mixed up), renamed ~22 entities back, recreated the 4 helpers.
If you’ve customized entity_ids, export your device list (name IEEE) *before* starting.
Bonus Converting SkyConnect to a Thread border router
The official **Settings System Hardware ’ [device]’ Firmware** flow did almost everything automatically: flashed OpenThread RCP firmware, installed + started the OTBR add-on, formed a Thread network. One hiccup: HA’s auto-discovery of the OTBR add-on hit a DNS timeout once (add-on wasn’t fully up yet when HA tried to reach it) just retried the OTBR integration setup a few seconds later and it worked.
TL;DR checklist for anyone doing this
- Check for a stale ZHA (or other) integration entry on the same USB device before assuming hardware failure.
- `adapter: ember`, not `ezsp`, for modern EmberZNet firmware (7.x+).
- `dmesg` USB errors that *do* eventually enumerate are probably not your real problem.
- `database.db.backup` is your recovery path after a coordinator swap splice it with the new coordinator entry.
- Export your device list (name IEEE) before you start if you’ve renamed anything.
- Use the built-in Hardware firmware flow for Thread conversion, not manual flashing.
- Snapshot before you start, and after every stable milestone.
Happy to answer questions if anyone hits the same wall.