Zigbee2MQTT not restoring devices after coordinator migration (ZBDongle-P → SLZB-06p7 over Ethernet)

[marciza2]

Hello Zigbee2MQTT team,

I'm experiencing a restoration issue after migrating my Zigbee2MQTT setup from a ZBDongle-P to a new SLZB-06p7 Ethernet coordinator.

📦 Environment

• Previous Coordinator: ZBDongle-P
• New Coordinator: SLZB-06p7 (Ethernet, CC2652-based)
• SLZB-06p7 Firmware: 2.7.1
• Zigbee Driver: 20240716
• **Zigbee2MQTT: 2.1.3
• Deployment: Docker (same container, only reconfigured)

---

🔄 Migration Steps Taken

1. Backed up original Zigbee2MQTT files:

   • coordinator_backup.json
   • configuration.yaml
   • state.json

2. Did not create a new container; only reconfigured Docker (removing USB usage) to use SLZB-06p7 over Ethernet.

3. Updated configuration.yaml to:

   • Use the Ethernet IP and port of SLZB-06p7
   • Manually restored the previous IEEE address
   • Explicitly include original network_key, pan_id, and ext_pan_id

4. Ensured coordinator_backup.json is present in the correct directory.

---

🧪 Behavior Observed

• If I don’t specify network_key, pan_id, and ext_pan_id in configuration.yaml, Zigbee2MQTT:

  • Starts a new empty network with no devices
  • state.json is reset or overwritten

• If I do specify these values, Zigbee2MQTT throws this error:

  Error: network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby
  

Zigbee2MQTT gui not starting.

Log says:

---

⚠️ Problem Summary

Zigbee2MQTT fails to restore the previous Zigbee network and devices despite:

• Preserving the IEEE address manually on SLZB-06p7
• Using same network credentials
• Keeping the same container (no new instance)
• SLZB-06p7 being reachable over Ethernet
• coordinator_backup.json being present

---

❓Questions

• Is there an extra step required to make Zigbee2MQTT restore a network after switching from USB to Ethernet-based coordinators?
• Is this a commissioning issue or a limitation with SLZB-06p7 over Ethernet?
• Why is coordinator_backup.json ignored?

Could you please advise on the correct approach to migrate the network and coordinator to SLZB-06p7 without losing the paired devices?

Any advice would be greatly appreciated.

Thanks in advance!

[chris-1243]

• Clear the NVRAM of your SLZB-06P7 or flash a firmware (this process will clear the NVRAM as well).
• While this is done, stop Z2M and backup your app/data folder just in case of something goes wrong. I would then remove your container to start with a new one.
• Edit your configuration.yaml to point to your SLZB-06P7 and you may also suppress the device section in your docker-compose.yaml.
• Start your container and see the log output. You should be fine.

As an advice, while moving from one coordinator to an other one (same chip manufacturer), the NVRAM should be clean. Z2M will then write the backup. Or you may backup your Dongle-P and write your network to your SLZB-06P7 with a tool like zigpy-cli or ZigStar-MT

[malosaaa]

I got the same problem, i also did reflash etc.
i'm on proxmox

Error: network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby

I did use the ieee of the old device (z dongle P)and update it in the slzb, flashed firmware and loaded up.
my previous config was ember, now its zstack.
However if i change the panID it loads, it will show up all the devices but need re-pair... can someone tell me what i'm doing wrong here ?

I just got a brand new SLZB-MR3

Regards and thans in advance

    at start (/app/index.js:149:5)
[20:24:43] INFO: Preparing to start...
[20:24:43] INFO: Socat not enabled
[20:24:44] ERROR: Got unexpected response from the API: Service not enabled
[20:24:44] INFO: Starting Zigbee2MQTT...
Starting Zigbee2MQTT without watchdog.
[2025-06-14 20:24:48] info: 	z2m: Logging to console, file (filename: log.log)
[2025-06-14 20:24:49] info: 	z2m: Starting Zigbee2MQTT version 2.3.0 (commit #unknown)
[2025-06-14 20:24:49] info: 	z2m: Starting zigbee-herdsman (4.0.0)
[2025-06-14 20:24:49] info: 	zh:zstack:znp: Opening TCP socket with 10.10.11.208:7638
[2025-06-14 20:24:49] info: 	zh:zstack:znp: Socket connected
[2025-06-14 20:24:49] info: 	zh:zstack:znp: Socket ready
[2025-06-14 20:24:49] info: 	zh:zstack:znp: Writing CC2530/CC2531 skip bootloader payload
[2025-06-14 20:24:50] info: 	zh:zstack:znp: Skip bootloader for CC2652/CC1352
[2025-06-14 20:26:07] error: 	z2m: Error while starting zigbee-herdsman
[2025-06-14 20:26:07] error: 	z2m: Failed to start zigbee-herdsman
[2025-06-14 20:26:07] error: 	z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html for possible solutions
[2025-06-14 20:26:07] error: 	z2m: Exiting...
[2025-06-14 20:26:07] error: 	z2m: Error: network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby (Error: AREQ - ZDO - stateChangeInd after 60000ms
    at Object.start (/app/node_modules/.pnpm/zigbee-herdsman@4.0.0/node_modules/zigbee-herdsman/src/utils/waitress.ts:67:23)
    at ZnpAdapterManager.beginCommissioning (/app/node_modules/.pnpm/zigbee-herdsman@4.0.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:362:31)
    at processTicksAndRejections (node:internal/process/task_queues:105:5)
    at ZnpAdapterManager.start (/app/node_modules/.pnpm/zigbee-herdsman@4.0.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:91:21)
    at ZStackAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@4.0.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:154:16)
    at Controller.start (/app/node_modules/.pnpm/zigbee-herdsman@4.0.0/node_modules/zigbee-herdsman/src/controller/controller.ts:133:29)
    at Zigbee.start (/app/lib/zigbee.ts:70:27)
    at Controller.start (/app/lib/controller.ts:104:13)
    at start (/app/index.js:149:5))
    at ZnpAdapterManager.beginCommissioning (/app/node_modules/.pnpm/zigbee-herdsman@4.0.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:364:23)
    at ZnpAdapterManager.start (/app/node_modules/.pnpm/zigbee-herdsman@4.0.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:91:21)
    at ZStackAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@4.0.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:154:16)
    at Controller.start (/app/node_modules/.pnpm/zigbee-herdsman@4.0.0/node_modules/zigbee-herdsman/src/controller/controller.ts:133:29)
    at Zigbee.start (/app/lib/zigbee.ts:70:27)
    at Controller.start (/app/lib/controller.ts:104:13)
    at start (/app/index.js:149:5)

[Koenkk]

Make sure to always copy over your database.db file (just copy over the whole data folder)

[malosaaa]

Because i have the same problem i dont know what to do ?

As i did try again and this time most of my entities got renamed in hass that was a mess..
I needed to put backup back as everything was just messed up.

So the things i tried:

• reflash SLZB-M3
• use the IEEE from the sonoff P into SLZB-M3
• updated the settings according the manufacturer
• using the CC2674P10 chip
• let it reboot and still giving me pan error
• try on other new system and still pan error

Secont i tried:

• change the pan
• let it boot

This caused to boot the device correctly and loading up the devices, however the need all to be repaired. thats not what i want.
So i reverted back to my sonoffP stick

[malosaaa]

Finally i fixed the issue, and its none of the above.

1. put out all antenna's and cover the mr3 with something
2. disconnect all router devices
3. start up z2m and connect the antennas after startup
4. then insert all routers
5. all routers will become available so do the entities
6. restart z2m to check if everything is ok now
7. done

Thanks to my AI who told me i need to do this

i use the last experimental 20250325 FW on CC2674P10

[Pau1yMichigan]

Adding another data point — same root cause, different symptom, same fix.
Setup: SLZB-06, CC2652P firmware 20260311 (DEV channel), SLZB-OS v3.3.1, Z2M 2.10.1, Home Assistant OS
Trigger: Manually updated SLZB-OS to v3.3.3.dev1 beta. This corrupted the CC2652P NVRAM.
Symptom: Z2M started successfully, all devices loaded with correct cached states and linkquality values, MQTT connected, bridge showed online — but the CC2652P radio was not transmitting. Every command returned NWK_NO_ROUTE (0xcd) or Timeout after 10000ms. The coordinator appeared fully functional but no Zigbee packets were going over the air.

Fix:
Downgrade SLZB-OS from v3.3.3.dev1 back to v3.3.1
Reflash CC2652P coordinator firmware (same version 20260311) via Radio OTA — this forces a full chip erase
Reboot SLZB-06

After this, Z2M reinitialized from coordinator_backup.json and all devices responded immediately with no re-pairing required.
Conclusion: Updating to v3.3.3.dev1 beta corrupted the CC2652P NVRAM on an established working network. A chip erase via firmware reflash is the reliable fix.