SLZB-06P7 (CC2652P7, fw 20240710): whole network dies with `SRSP - AF - dataRequest after 6000ms`, Z2M stays healthy — recovered without a power-cycle

What happened?

The coordinator stopped passing traffic in both directions while Zigbee2MQTT itself stayed perfectly healthy: process up, MQTT connected, TCP socket to the coordinator established, bridge/health published on schedule. Every ZCL operation failed with SRSP - AF - dataRequest after 6000ms. The network was dead for 3 h 08 min until I intervened.

This looks like the same class of failure as #31092 (closed as stale), Koenkk/Z-Stack-firmware#518 (same adapter model, same firmware 20240710) and Koenkk/Z-Stack-firmware#592. I'm filing because I have two observations that I did not find in those threads, and because the problem is clearly still present on current versions (Z2M 2.13.0, August 2026).

Timeline (local time, -03):

Time	Event
06:35:39	Last successful Zigbee message (Radar Presença Brinquedoteca). Traffic was completely normal up to this second.
06:36:09	bridge/health published normally.
06:36:51	First failure: Publish 'set' 'state' to 'Interruptor Brinquedoteca' failed.
06:36:51 – 09:44	100% of operations fail with SRSP - AF - dataRequest after 6000ms. No reconnect, no adapter-disconnect event, no crash.
06:50	Devices start going unavailable in Home Assistant.
09:44	Recovered (see below).

Observation 1 — bridge/health gives an objective, unambiguous signature of this state.

Per-device message counters are completely frozen across consecutive health checks, which shows RX is dead too (not just TX, and not a routing problem):

[08:56:09] "devices":{"0x385b44fffe054b51":{"messages":43292,"messages_per_sec":0.2373,...},
                      "0xa4c138e270c71e58":{"messages":113181,"messages_per_sec":0.6205,...}}
[09:06:09] "devices":{"0x385b44fffe054b51":{"messages":43292,"messages_per_sec":0.2366,...},
                      "0xa4c138e270c71e58":{"messages":113181,"messages_per_sec":0.6185,...}}
"mqtt":{"connected":true,"queued":0,"published":568660 → 568662}
"process":{"uptime_sec":183011}   ← ~50 h, never restarted

0x385b44fffe054b51 normally reports ~0.24 msg/s. Not a single message in 10 minutes, from any device, while the process reports itself healthy. (messages_per_sec only decays because it is an average over uptime.)

Observation 2 — a full device reboot / power-cycle was NOT required. Z-Stack-firmware#592 and smlight-tech/slzb-os-scripts#5 state that only a full reboot recovers the device. In my case, escalating step by step:

1. Zigbee radio restart alone (SMLIGHT web UI / button.press via the SMLIGHT HA integration): NOT sufficient. Waited ~2 min: counters stayed frozen, Z2M kept failing. Z2M did not attempt to reconnect on its own.
2. Radio restart + Zigbee2MQTT restart: recovered immediately. Socket ready → zigbee-herdsman started (resumed) → Currently 96 devices are joined in 5 s. Zero SRSP errors since. Only Data request failed with error on a handful of devices for the first minute, as the mesh re-routes.

So the coordinator is recoverable without cutting power — but only if the client re-establishes the ZNP session after the radio reset. Neither half alone is enough.

What could not be blamed (all checked while the failure was live): network (ICMP 0.7 ms, TCP socket established the whole time), PoE/power (switch port reported on, 15.4 W, uninterrupted), cabling (0 input errors, 0 CRC, 0 output errors, no link flap), host resources (load 0.06, Z2M at 207 MB / 2.6%), temperature (radio chip 48.3 °C, ESP 52.2 °C), and a spontaneous radio reset (the device's own "Zigbee uptime" still pointed at its previous boot, ~2 days earlier).

For what it's worth, the previous hang on this same unit was 2 days 6 h earlier, with a different signature: the adapter failed at connect time (SRSP - SYS - ping after 6000ms) and Z2M crash-looped, which at least made the failure visible. That interval matches the "every 2–6 days" reported in #31092 and the "2 days / 6 days" in Z-Stack-firmware#518.

What did you expect to happen?

I don't believe the root cause is in Zigbee2MQTT — it looks like the CC2652P7 / serial-bridge side, as concluded in the linked issues. But two things seem addressable here:

1. Detection. In this state Z2M reports itself healthy, so nothing downstream can tell that the network is dead: the Home Assistant add-on watchdog sees a healthy container, MQTT is connected, and bridge/state stays online. A sustained "all devices failing with SRSP timeouts" or "zero received messages from every device across N health checks" condition seems detectable from data Z2M already computes for bridge/health.
2. Recovery. Since re-establishing the adapter connection was sufficient here (no power-cycle), an optional auto-restart of the adapter connection after a sustained all-device SRSP-timeout condition would have turned a 3-hour outage into a ~1-minute one. This is the same improvement requested at the end of #31092.

If this belongs in Z-Stack-firmware rather than here, I'm happy to move it — the issue template there points contributors to this tracker first.

How to reproduce it (minimal and precise)

1. SLZB-06P7 (CC2652P7, Z-Stack firmware 20240710) in Ethernet mode, used as a network coordinator over its TCP serial bridge (tcp://<ip>:6638).
2. Point Zigbee2MQTT at it with adapter: zstack, ~96 joined devices.
3. Run it and wait — this unit hung twice in 3 days (2 d 6 h apart); #31092 reports every 2–6 days on a CC2652P7 in the same architecture.
4. Observe: every device fails with SRSP - AF - dataRequest after 6000ms, per-device messages counters in bridge/health stop advancing, and Zigbee2MQTT never reconnects or reports itself unhealthy.

Zigbee2MQTT version

2.13.0-1 (Home Assistant add-on)

Adapter firmware version

20240710

Adapter

SMLIGHT SLZB-06P7 (CC2652P7), zstack, Ethernet mode, TCP serial bridge tcp://192.168.88.13:6638, 115200 baud

Setup

Home Assistant OS on a Raspberry Pi, official Zigbee2MQTT add-on 2.13.0-1 (watchdog: true, boot: auto), Mosquitto add-on as broker. Coordinator connected by Ethernet over PoE, on a dedicated VLAN, 96 devices joined, channel 11, transmit_power: 20.

serial:
  port: tcp://192.168.88.13:6638
  baudrate: 115200
  adapter: zstack
advanced:
  transmit_power: 20
  log_level: info
  channel: 11
availability:
  enabled: true

Debug log

Log level was info (the failure is not reproducible on demand, so I could not capture it at debug).

Failure — identical for every device, 89 occurrences in the last 100 log lines before recovery:

[2026-08-13 08:52:05] warning: z2m: Failed to ping 'Radar Presença Sala TV' (attempt 1/1,
  ZCL command 0x385b44fffe054b51/1 genBasic.read(["zclVersion"], {"timeout":10000,"disableResponse":false,
  "disableRecovery":true,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false,
  "sendPolicy":"immediate"}) failed (SRSP - AF - dataRequest after 6000ms))

Last healthy message and the transition, 72 s apart:

[2026-08-13 06:35:39] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Radar Presença Brinquedoteca', payload '{...}'
[2026-08-13 06:36:09] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/health', payload '{...}'
[2026-08-13 06:36:51] error: z2m: Publish 'set' 'state' to 'Interruptor Brinquedoteca' failed:
  'Error: ZCL command 0xa4c1385d69cb485a/3 genOnOff.off({}, {...}) failed (...)'

Recovery, after restarting the radio and then the add-on:

[2026-08-13 09:44:12] info: zh:zstack:znp: Socket ready
[2026-08-13 09:44:17] info: z2m: zigbee-herdsman started (resumed)
[2026-08-13 09:44:17] info: z2m: Coordinator firmware version: '{"meta":{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20240710,...}}'
[2026-08-13 09:44:17] info: z2m: Currently 96 devices are joined.

In the ~3 hours before the hard failure there were also 35 ZCL-level Timeout after 10000ms errors on genOnOff commands to several different devices (a different layer than the SRSP ones). My log buffer starts at 03:03, so I cannot say when those began, and I cannot claim they are a precursor — I'm noting them only because the timing may be relevant.

Start with the bridge/health data and the zstack adapter connection handling described in the issue. Determine how sustained SRSP AF dataRequest timeouts and frozen per-device message counters could be detected, then evaluate adapter reconnection and unhealthy-state reporting. Done means the failure is detected and the adapter can recover without a power-cycle, with behavior covered by tests.