SLZB-MR4U: Ember→Z-Stack coordinator migration fails with "network commissioning timed out" even after fully disabling the Ember radio (CC2674P10)

What happened?

Attempting to migrate the active Zigbee coordinator role on a SMLIGHT SLZB-MR4U
from Radio 1 (EFR32MG26, adapter: ember) to Radio 2 (CC2674P10, adapter: zstack),
reusing the identical pan_id/ext_pan_id/network_key/channel to preserve
device continuity.

First attempt: Radio 1 was still active as coordinator during commissioning of
Radio 2 → failed with the expected network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby.

Second attempt: explicitly switched Radio 1's role to "Matter-over-Thread" in
SLZB-OS first, and confirmed in the device UI that no Zigbee-coordinator role
was active anywhere on the device before starting Z2M on Radio 2. Result:
identical timeout error, after the full 100000ms, despite there being no
competing coordinator broadcasting the same PAN ID anymore.

This suggests the timeout is not actually caused by a real PAN ID collision in
this case, but by something else in the zstack commissioning path for this chip.

What did you expect to happen

Successful commissioning on Radio 2/CC2674P10 once the only other radio on the
device is confirmed not running as a Zigbee coordinator.

Relevant log output

[info] zh:zstack:znp: Opening TCP socket with :7638
[info] zh:zstack:znp: Socket connected / Socket ready
[info] zh:zstack:znp: Writing CC2530/CC2531 skip bootloader payload
[info] zh:zstack:znp: Skip bootloader for CC2652/CC1352
...(~100s later)...
[error] Error: network commissioning timed out - most likely network with the
same panId or extendedPanId already exists nearby (Error: AREQ - ZDO -
stateChangeInd after 100000ms

Note the chip is identified/logged as CC2652/CC1352 family, not CC2674P10 —
possibly relevant since CC2674P10 is a newer/different TI chip.

Setup

• Zigbee2MQTT version: 2.13.0
• zigbee-herdsman: 10.8.0
• Adapter: zstack (CC2674P10, firmware znp-SLZB-06P10-20240716.bin)
• Coordinator: SMLIGHT SLZB-MR4U, network connection (TCP)

What did you expect to happen?

Successful commissioning on Radio 2/CC2674P10 once the only other radio on the device is confirmed not running as a Zigbee coordinator.

How to reproduce it (minimal and precise)

1. Have a SMLIGHT SLZB-MR4U with an already-running Zigbee network on Radio 1
   (EFR32MG26, adapter: ember).
2. In SLZB-OS, switch Radio 1's role away from "Zigbee koordynator" to
   "Matter-over-Thread" (confirmed via UI that Radio 1 is no longer running
   as a Zigbee coordinator).
3. In SLZB-OS, switch Radio 2's role (CC2674P10) to "Zigbee koordynator".
4. In Zigbee2MQTT's configuration.yaml, set:
   serial:
   port: tcp://:7638
   adapter: zstack
   baudrate: 115200
   Keep the same advanced.pan_id / ext_pan_id / network_key / channel that
   were used on Radio 1, to preserve device continuity.
5. Move the existing coordinator_backup.json aside (it's in ember format,
   incompatible with zstack).
6. Start Zigbee2MQTT.

Expected: commissioning succeeds since no other radio on the device is
running as a Zigbee coordinator.
Actual: fails after 100000ms with "network commissioning timed out - most
likely network with the same panId or extendedPanId already exists nearby".

Zigbee2MQTT version

2.13.0

Adapter firmware version

20240716

Adapter

zstack

Setup

Home Assistant Add-on

Device database.db entry

No response

Debug log

[2026-08-28 11:25:44] info: z2m: Logging to console, file (filename: log.log)
[2026-08-28 11:25:44] info: z2m: Starting Zigbee2MQTT version 2.13.0 (commit #unknown)
[2026-08-28 11:25:44] info: z2m: Starting zigbee-herdsman (10.8.0)
[2026-08-28 11:25:44] info: zh:zstack:znp: Opening TCP socket with 192.168.3.161:7638
[2026-08-28 11:25:44] info: zh:zstack:znp: Socket connected
[2026-08-28 11:25:44] info: zh:zstack:znp: Socket ready
[2026-08-28 11:25:44] info: zh:zstack:znp: Writing CC2530/CC2531 skip bootloader payload
[2026-08-28 11:25:45] info: zh:zstack:znp: Skip bootloader for CC2652/CC1352
[2026-08-28 11:27:40] error: z2m: Error while starting zigbee-herdsman
[2026-08-28 11:27:40] error: z2m: Failed to start zigbee-herdsman
[2026-08-28 11:27:40] error: z2m: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start_crashes-runtime.html for possible solutions
[2026-08-28 11:27:40] error: z2m: Exiting...
[2026-08-28 11:27:40] error: z2m: Error: network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby (Error: AREQ - ZDO - stateChangeInd after 100000ms
at Object.start (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/utils/waitress.ts:68:23)
at ZnpAdapterManager.beginCommissioning (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:376:31)
at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
at async ZnpAdapterManager.start (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:90:21)
at async ZStackAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:135:16)
at async Controller.start (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/controller/controller.ts:146:29)
at async Zigbee.start (/app/lib/zigbee.ts:70:27)
at async Controller.start (/app/lib/controller.ts:117:29)
at async start (/app/index.js:156:5))
at ZnpAdapterManager.beginCommissioning (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:378:23)
at async ZnpAdapterManager.start (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:90:21)
at async ZStackAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:135:16)
at async Controller.start (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/controller/controller.ts:146:29)
at async Zigbee.start (/app/lib/zigbee.ts:70:27)
at async Controller.start (/app/lib/controller.ts:117:29)
at async start (/app/index.js:156:5)

Notes

This is a dual-radio SMLIGHT SLZB-MR4U (EFR32MG26 + CC2674P10 on the same
physical device). The Zigbee network on Radio 1 (ember) is healthy and has
run for over a week with 72 devices - so this is not a general hardware defect,
it's specific to commissioning on Radio 2 (CC2674P10/zstack) when reusing an
existing network identity from a different radio family.

Reverting back to Radio 1 (ember) with the same pan_id/ext_pan_id/network_key
worked immediately and cleanly (clean "resume", zero data loss), so the
coordinator_backup.json handling and config itself are not the issue.

Possibly related but distinct: we separately hit Koenkk/zigbee2mqtt#28842
(ROUTE_ERROR_ADDRESS_CONFLICT on the EmberZNet/Radio 1 side) - that is a
different symptom on the other radio and not what this report is about.

Happy to provide more debug output (e.g. increased zigbee-herdsman log level)
if useful for diagnosing this.

Start with zigbee-herdsman’s z-stack adapter, especially adapter/manager.ts beginCommissioning at the reported timeout and zStackAdapter.ts startup flow. Review the CC2674P10 handling indicated by the logs and compare the commissioning path with the reported CC2652/CC1352 identification. Done means commissioning succeeds on the CC2674P10 while reusing the existing network identity without the 100000ms timeout.