Zigbee2MQTT crashes with SIGSEGV (exit 139) every ~30 min, tied to sleepy end device Poll Control checkin

What happened?

Zigbee2MQTT crashes with exit code 139 (SIGSEGV) approximately every 30 minutes, and Supervisor's Watchdog auto-restarts it. The crash is silent at the application level — even with log_level: debug enabled, nothing is logged between the last normal message and the process dying. No JS exception, no stack trace, no warning.

The crash cadence lines up exactly with the Poll Control "checkin" cycle (1800s / 30 min) of a single sleepy end device on the network: a SONOFF SWV Zigbee smart water valve. In every debug-log capture we have, the very last message logged before the process dies involves this device — most often a clusterID=10 (genTime) exchange, sometimes a customClusterEwelink (0xFC11 / 64529) report.

We are aware of Koenkk/zigbee2mqtt#31995 and its fix, Koenkk/zigbee-herdsman#1755 (merged into 10.1.0), which addressed an uncaught JS error when fastPollStop fails after a genPollCtrl checkin from a sleepy end device. Our zigbee-herdsman version (10.8.0) is already past that fix, and we are still seeing what looks like the same triggering scenario (checkin from a sleepy end device), but manifesting as a hard native segfault (139) rather than a catchable JS exception. This may be either an edge case not covered by #1755, or a distinct native-level bug in the same code path.

Diagnostic steps already taken:
Confirmed exit code 139 (SIGSEGV) on every occurrence, via Supervisor Watchdog logs (App Zigbee2MQTT exited with non-zero exit code 139).

Enabled debug logging (advanced.log_level: debug) — captured multiple crashes; in each case the log stream simply stops mid-session with no error, exception, or warning logged. This suggests the fault is at the native/process level, below what Node.js can catch or log.

Ruled out the device's proprietary cluster as the sole cause: wrote and installed an external converter (ESM, modernExtend) that completely omits any reference to the device's customClusterEwelink cluster (0xFC11 / 64529), keeping only standard genOnOff and genPowerCfg. The device's active definition was confirmed to expose only switch + battery + linkquality after this change. The crash persisted on the identical ~30-minute cadence after this fix was installed and confirmed loaded, ruling out the proprietary cluster's parsing as the (sole) root cause.

Ruled out DHCP/network-layer causes: coordinator (SLZB-MR1U POE) was already on a static IP; VM network adapter confirmed in Bridged mode (not NAT); Zigbee channel moved from 11 to 25 to avoid Wi-Fi interference. None of these affected the crash cadence.

Ruled out auto_close_when_water_shortage as the (sole) cause: disabling this device feature stopped a separate, actuation-triggered crash (opening/closing the valve), confirmed via live testing (open/close via switch.turn_on/switch.turn_off, verified real device response in logs, no crash). However, the periodic ~30-minute crash continued unaffected by this change.

Confirmed the crash stops when the device is powered off: removing the SWV's batteries reliably prevented the periodic crash from recurring during the test window. Reinserting the batteries and resuming normal operation caused the crash pattern to resume on the same ~30-minute cadence.

What did you expect to happen?

Zigbee2MQTT should not crash the entire process when a sleepy end device's Poll Control checkin cycle completes, regardless of which cluster is involved in the exchange, and regardless of whether the device uses a proprietary/manufacturer-specific cluster elsewhere in its definition.

How to reproduce it (minimal and precise)

Not fully isolated to a minimal repro yet — occurs organically on our network every ~30 minutes tied to this device's checkin cycle. Removing the device's batteries reliably stops the crash; reinserting them reliably resumes it (tested twice).

Zigbee2MQTT version

2.13.0 (herdsman 10.8.0, herdsman-converters 26.90.0)

Adapter firmware version

Z-Stack 3.x, coordinator meta: majorrel 2, minorrel 7, maintrel 1, revision 20260310, transportrev 2

Adapter

SLZB-MR1U (POE, network-attached)

Setup

Home Assistant OS (Supervisor/add-on), running as a VM (VirtualBox, Bridged network adapter) on an Intel N95 mini PC.

Device database.db entry

Affected device SONOFF SWV (Zigbee smart water valve) model_id: SWV ieee_address: 0x187a3efffe38c265 network_address: 30385 software_build_id / firmware: 1.0.4 (OTA index reports installed_version/latest_version: 4100 — already on latest available firmware) power_source: Battery, type: EndDevice

Debug log

[2026-08-27 05:43:11] debug: z2m: Saving state to file /config/zigbee2mqtt/state.json
[2026-08-27 05:43:13] debug: zh:controller:database: Writing database to '/config/zigbee2mqtt/database.db'
[2026-08-27 05:43:14] debug: zh:zstack:unpi:parser: <-- [254,25,68,129,0,0,10,0,177,118,1,1,0,12,0,100,117,101,0,0,5,0,45,0,7,0,177,118,29,156]
[2026-08-27 05:43:14] debug: zh:zstack:unpi:parser: --- parseNext [254,25,68,129,0,0,10,0,177,118,1,1,0,12,0,100,117,101,0,0,5,0,45,0,7,0,177,118,29,156]
[2026-08-27 05:43:14] debug: zh:zstack:unpi:parser: --> parsed 25 - 2 - 4 - 129 - [0,0,10,0,177,118,1,1,0,12,0,100,117,101,0,0,5,0,45,0,7,0,177,118,29] - 156
[2026-08-27 05:43:14] debug: zh:zstack:znp: <-- AREQ: AF - incomingMsg - {"groupid":0,"clusterid":10,"srcaddr":30385,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":12,"securityuse":0,"timestamp":6649188,"transseqnumber":0,"len":5,"data":{"type":"Buffer","data":[0,45,0,7,0]}}
[2026-08-27 05:43:14] debug: zh:controller: Received payload: clusterID=10, address=30385, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=12, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":45,"commandIdentifier":0},"payload":[{"attrId":7}],"command":{"name":"read","ID":0,"response":1}}
--- [process dies here, no further output — Watchdog log confirms exit 139 at 05:43:15.938] ---

Notes

Given the confirmed relationship to Koenkk/zigbee2mqtt#31995 / Koenkk/zigbee-herdsman#1755, this may be:

An edge case in the same genPollCtrl checkin / fastPollStop code path not covered by that fix, or
A distinct, lower-level (native) crash triggered by the same class of event (failed command delivery to a sleepy end device immediately after checkin).

Start by reproducing the crash with the SONOFF SWV powered on and capture the Poll Control checkin logs around the clusterID=10 message. Compare the behavior with zigbee-herdsman#1755 and isolate whether the failure is in that code path or a native dependency. Done means identifying the cause and preventing the process from exiting with SIGSEGV, ideally with a regression reproduction.