Co-ordinator backup failure causes crash
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 15.7k
- Forks
- 2k
- Avg merge
- 18h 55m
- Merged PRs (30d)
- 35
Description
What happened?
Zigbee2MQTT terminated when its scheduled coordinator backup timed out while querying a network-connected SMLIGHT Z-Stack coordinator.
Immediately before the failure, Z2M published a normal bridge health response with:
[2026-07-21 10:22:03] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/health', payload '{"response_time":1784625723481,"os":{"load_average":[0.06,0.06,0.01],"memory_used_mb":2329.21,"memory_percent":61.656},"process":{"uptime_sec":518409,"memory_used_mb":160.5,"memory_percent":4.2484},"mqtt":{"connected":true,"queued":0,"published":6162059,"received":904},"devices": { ... } }'
Then the failure - with a stack that shows it's a backup process:
Error: SRSP - SYS - version after 6000ms
at Object.start (/app/node_modules/.pnpm/zigbee-herdsman@10.6.1/node_modules/zigbee-herdsman/src/utils/waitress.ts:68:23)
at /app/node_modules/.pnpm/zigbee-herdsman@10.6.1/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:256:45
at AsyncMutex.run (/app/node_modules/.pnpm/zigbee-herdsman@10.6.1/node_modules/zigbee-herdsman/src/utils/async-mutex.ts:17:26)
at Znp.request (/app/node_modules/.pnpm/zigbee-herdsman@10.6.1/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:249:27)
at Znp.requestWithReply (/app/node_modules/.pnpm/zigbee-herdsman@10.6.1/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:228:34)
at AdapterBackup.getAdapterVersion (/app/node_modules/.pnpm/zigbee-herdsman@10.6.1/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/adapter-backup.ts:437:48)
at AdapterBackup.createBackup (/app/node_modules/.pnpm/zigbee-herdsman@10.6.1/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/adapter-backup.ts:58:48)
at ZStackAdapter.backup (/app/node_modules/.pnpm/zigbee-herdsman@10.6.1/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:1021:49)
at Controller.backup (/app/node_modules/.pnpm/zigbee-herdsman@10.6.1/node_modules/zigbee-herdsman/src/controller/controller.ts:482:47)
And subsequently every automated restart failed with:
[2026-07-21 10:22:31] error: z2m: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
at ZStackAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@10.6.1/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:95:27)
The uptime reported in the health payload 518409 is six days, nine seconds, which made me think this failure is probably something that happens on a daily schedule. Surre enough the backup timer is hard coded to daily:
// Set backup timer to 1 day.
this.backupTimer = setInterval(() => this.backup(), 86400000);
The SMLIGHT network interface and web UI remained reachable. The coordinator later recovered after the SMLIGHT/radio was restarted.
So... the underlying radio hang might be an SMLIGHT/firmware problem. But the scheduled call currently appears to discard the promise returned by backup(). So when the backup rejects, the rejection is not handled and terminates the Z2M process.
Environment:
- Zigbee2MQTT version:
2.12.1(Home Assistant add-on) - Herdsman:
10.6.1 - Adapter: SLZB-MR3
- Radio: CC2674P10
An AI search found several related historical reports, and reported that none appears to cover the current unhandled scheduled-backup rejection, though I haven't verified that info:
- https://github.com/Koenkk/zigbee2mqtt/issues/8711 — same timeout/unhandled rejection in 2021; resolved by updating old coordinator firmware
- https://github.com/Koenkk/zigbee2mqtt/issues/8452 — daily CC26x2 crash without a backup stack
- https://github.com/Koenkk/zigbee2mqtt/issues/31927 — backup failure during shutdown after an existing USB/serial failure
- https://github.com/Koenkk/zigbee2mqtt/issues/29116 — recurring SMLIGHT freezes without the daily-backup correlation
What did you expect to happen?
An unexpected adapter response during a backup should not crash the process.
How to reproduce it (minimal and precise)
I imagine you may be able to reproduce the problem by mocking adapter.backup() to reject when the scheduled callback runs.
Zigbee2MQTT version
2.12.1
Adapter firmware version
ZStack3x0 0x00212effff05da74 Revision: 20260310
Adapter
SLZB-MR3 - Radio: CC2674P10
Setup
Add-on in Home Assistant OS
Device database.db entry
No response
Debug log
No response
Notes
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in zigbee-herdsman/src/controller/controller.ts at the daily backup timer and trace how the scheduled backup promise is handled. Reproduce the case by mocking adapter.backup() to reject when the callback runs, then verify the rejection no longer terminates the process and that the existing restart behavior remains intact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend, embedded-iot
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 64/100