Transparent zstack → ember migration of a 125-device network: tools + gotchas

[vwidor]

Title: Transparent zstack → ember migration of a 125-device network: tools + three gotchas

Sharing tooling and the runbook from a recent in-place migration of a
production Z2M coordinator from a SLZB-06P10 (CC2674P10 / zstack) to a
SLZB-MR4U (EFR32MG26 / ember) over LAN/TCP. 0 devices required
re-pairing; mesh resumed within minutes.

Repo: https://gitlab.com/vwidor/z2m-zstack-to-ember-migration

The three issues that each took hours to isolate:

1. SLZB-MR4U socket settings — three toggles in vendor UI need to be off
   for raw ASH traffic to reach the chip: Hardware flow control, Enable
   Zigbee Socket packet processing, Multi-Radio Queue Control. With any
   of them on, TCP socket connects but ASH RST gets no RSTACK.

2. Backup format gatekeeping — the Open Coordinator Backup format is
   advertised as vendor-neutral but herdsman's ember adapter strictly
   requires stack_specific.ezsp + metadata.internal.ezspVersion ≥ 12.
   Plus hashed_tclk (AES-MMO of TC link key) is needed for restore.
   The repo has a standalone converter that computes the hash without
   external Python deps.

3. EFR32 factory IEEE silently used — herdsman tries to write the
   backup IEEE to MFG_CUSTOM_EUI_64 but the call silently fails on this
   chip; ember adapter then reports the new (factory) IEEE as if it
   were the old one. Mesh appears alive in bridge/devices but a
   2-minute sniff showed 0/125 devices active. Vendor UI's "Flash
   custom IEEE" button does work — write the old coordinator's IEEE
   before migrating.

Tested with: Z2M 2.10.0 / zigbee-herdsman 10.0.7 / SLZB-OS 3.3.1 /
EFR32 firmware 20240602.

---

Separately observed (not a migration issue, but worth flagging here):
After the migration, new pairings of Philips Hue Dimmer Switch V2
(RWL022) fail. Interview + Configure complete fine, then chip reports
ezspZigbeeKeyEstablishmentHandler: status=TC_REQUEST_KEY_TYPE_NOT_SUPPORTED.
Hue Motion V2 / Tap V2 / lights pair fine — only devices that request
an Application Link Key are affected.

Two independent causes:

• Z2M side: ALLOW_APP_KEY_REQUESTS is hardcoded false in
  emberAdapter.ts:1082.
  Would there be appetite for making this a runtime config option?
  Happy to send a PR.
• Vendor side: even with that patched to true, the SMLIGHT-shipped
  EFR32 firmware returns TC_REQUEST_KEY_TYPE_NOT_SUPPORTED — App
  Link Key Table not enabled in their build. Filed as a SMLIGHT
  support ticket separately.

The Z2M-side change alone wouldn't fix this specific hardware, but
would unblock other ember-based coordinators whose firmware does
support app link keys.