SWV-ZF2: device becomes completely unresponsive for extended periods

What happened?

The device (SONOFF SWV-ZF2, dual-channel water valve) intermittently becomes completely unresponsive to all Zigbee commands — reads, writes, and OTA checks alike — for durations ranging from ~15 minutes up to over a day. This is confirmed via continuous multi-day automated MQTT monitoring (not just occasional manual observation), so the pattern is well-characterized rather than anecdotal.

What did you expect to happen?

Consistent responsiveness to Zigbee commands, similar to the single-channel SWV-ZFU unit on the same network (<0.3% downtime over the same multi-day period).

How to reproduce it (minimal and precise)

The device (SONOFF SWV-ZF2, dual-channel water valve) intermittently becomes completely unresponsive to all Zigbee commands — reads, writes, and OTA checks alike — for durations ranging from ~15 minutes up to over a day. This is confirmed via continuous multi-day automated MQTT monitoring (not just occasional manual observation), so the pattern is well-characterized rather than anecdotal.

Environment

• Zigbee2MQTT: 2.13.0 (latest at time of testing)
• zigbee-herdsman: 10.8.0
• zigbee-herdsman-converters: 26.90.0
• Deployment: Debian, Docker
• Device firmware: went from 1.0.7 → 1.0.9 via OTA during testing

Troubleshooting steps and findings

1. Initial observation: genOnOff bind/reporting configuration failed with timeout errors even during initial pairing — present from day one, not something that developed over time.

2. Power cycling: Removed and reinserted batteries multiple times. Device worked normally for a short period (~5 minutes to a few hours) after each reset before becoming unresponsive again.

3. Re-pairing: Deleted and re-paired the device multiple times. Same pattern repeated each time.

4. Physical button testing: Confirmed the valve motor/water flow works correctly via physical button press even during periods when Zigbee communication is completely dead — ruling out a mechanical fault. LED responds to button presses during dead periods, but the Zigbee radio stays silent.

5. Factory reset attempt: Tried the 10-second button long-press for factory reset during a dead period — no response (LED did not enter fast-flash state), suggesting the main controller couldn't even process a local reset trigger at that moment.

6. OTA update attempts: Repeatedly triggered manual OTA checks; most failed with "Device didn't respond to OTA request". One eventually succeeded, updating firmware 1.0.7 → 1.0.9. This temporarily resolved the issue for ~8 hours before the same unresponsive pattern returned.

7. Long-term automated monitoring (~4 days, ongoing): Script subscribing to the device's MQTT state topic, continuously logging last_seen to precisely characterize unresponsive windows.

   • A recurring ~15.0–15.1 minute unresponsive window appears very consistently (~200 occurrences in one 4-day sample), suggesting an internal timer/cycle.
   • Longer, unpredictable dead periods occur on top of this baseline, including one lasting 28.22 hours.
   • As of the latest sample, another outage began and had already lasted 11+ hours with no recovery at time of writing.
   • Across the full observation window, unresponsive periods have accounted for roughly 37–66% of total time depending on the sample window, with the trend showing repeated cycles of "recovery → several hours to ~1.5 days of relative stability → relapse into extended unresponsiveness" rather than a steady improvement.

8. Comparison with a second unit: A single-channel SWV-ZFU on the same coordinator, same Zigbee2MQTT instance, same network remained stable throughout, with <0.3% downtime over the same period — ruling out network/environmental/coordinator-side causes.

9. Signal quality check: Compared linkquality (LQI) values immediately before, during (where any messages were received), and after unresponsive windows. LQI remained stable in the ~136–152 range throughout, with no discernible drop correlating with unresponsive periods — ruling out a signal-strength explanation.

10. "Keepalive" mitigation attempt: Script sending a child_lock toggle every 10 minutes, later upgraded to also verify actual command success (waiting up to 15s for a state update confirming the change was applied, not just checking that the publish call didn't error).

    • Over 243 attempts across ~2 days, 193 succeeded (79.4%) and 50 failed (20.6%), with failures clustering heavily during known unresponsive windows (near-0% success during the 11+ hour outage still ongoing as of this writing).
    • During earlier unresponsive windows (before the result-verification upgrade), keepalive commands consistently failed with Request superseded (each new command canceling the still-pending previous one before the device ever woke to process it) — confirming the device wasn't waking up at all during these windows, not just failing to process one command type.
    • genOnOff.on commands sent independently during the same windows also timed out (timed out after 10000ms), confirming all command types fail uniformly during dead periods.
    • During the 28.22-hour outage specifically, Zigbee2MQTT's console log showed zero log entries at all for this device during the entire outage — suggesting the availability mechanism may have stopped even attempting to queue commands to it. Recovery was marked by a log message not seen elsewhere in our logs: "Failed to read state of '...' after reconnect", suggesting the device rejoined the network rather than simply "waking up" from a poll cycle.

11. Device attribute inspection: genPollCtrl.checkinInterval reports as 14400 (quarter-seconds = 3600s = 1 hour) — longer than the observed baseline "dead window" (~15 min) and much shorter than the longest observed outages (28+ hours).

What did you expect to happen?

Consistent responsiveness to Zigbee commands, similar to the single-channel SWV-ZFU unit on the same network (<0.3% downtime over the same multi-day period).

How to reproduce it

No specific trigger identified. The unresponsive periods occur intermittently and unpredictably during normal/idle operation — no watering schedules or heavy automation running beyond periodic monitoring/keepalive polling.

Current status

As of this writing, the device is in the middle of an outage that has lasted 11+ hours with no signs of recovery.

Zigbee2MQTT version

2.13.0

Adapter firmware version

20250220

Adapter

SMLIGHT SLZB-06M

Setup

Running Zigbee2MQTT in a Docker container (image: koenkk/zigbee2mqtt) on a Debian x86-64 host, alongside a separate mosquitto broker container.

uname -a && cat /etc/issue.net output:
Linux 6.1.0-41-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.158-1 (2025-11-09) x86_64 GNU/Linux
Debian GNU/Linux 12

Device database.db entry

{"id":21,"type":"EndDevice","ieeeAddr":"0xa4c138eafe1c1a0a","nwkAddr":31252,"manufId":4742,"manufName":"SONOFF","powerSource":"Battery","modelId":"SWV-ZF2","epList":[1,2],"endpoints":{"1":{"profId":260,"epId":1,"devId":2,"inClusterList":[0,1,3,6,32,64599,64529,1028],"outClusterList":[3,25],"clusters":{"genOnOff":{"attributes":{"onOff":0}},"genBasic":{"attributes":{"dateCode":"20260724","swBuildId":"1.0.9"}},"genPollCtrl":{"attributes":{"checkinInterval":14400}},"genPowerCfg":{"attributes":{"batteryPercentageRemaining":200}},"customClusterEwelink":{"attributes":{"7":0,"20495":0,"20504":[0,0,0,0],"20506":0,"childLock":1,"manualDefaultSettings":[0,0,10,0,0,0,0,1,0,0,0,0],"rainDelayEndDatetime":0,"valveAlarmSettings":[7,5,1,5],"seasonalWateringAdjustment":[10,10,10,10,10,10,10,10,10,10,10,10],"unitOfWaterFlow":0,"irrigationScheduleStatus":[1,0,1,0,50,11,80,231,50,11,83,63,50,11,80,237,1,0,0,0,0],"realTimeIrrigationDuration":0,"realTimeIrrigationVolume":0,"valveAbnormalState":0,"hourIrrigationDuration":0,"hourIrrigationVolume":0}},"msFlowMeasurement":{"attributes":{"measuredValue":0}}},"binds":[{"cluster":32,"type":"endpoint","deviceIeeeAddress":"0x449fdafffe61df2e","endpointID":1},{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x449fdafffe61df2e","endpointID":1},{"cluster":1,"type":"endpoint","deviceIeeeAddress":"0x449fdafffe61df2e","endpointID":1}],"configuredReportings":[{"cluster":1,"attrId":33,"minRepIntval":3600,"maxRepIntval":65000,"repChange":10}],"meta":{}},"2":{"profId":260,"epId":2,"devId":2,"inClusterList":[0,6],"outClusterList":[],"clusters":{"genBasic":{"attributes":{}},"genOnOff":{"attributes":{"onOff":0}},"customClusterEwelink":{"attributes":{"20506":0,"realTimeIrrigationDuration":0,"irrigationScheduleStatus":[1,0,1,0,50,11,80,241,50,11,83,73,50,11,80,245,1,0,0,0,0],"hourIrrigationDuration":0}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x449fdafffe61df2e","endpointID":1}],"configuredReportings":[],"meta":{}}},"appVersion":16,"hwVersion":0,"dateCode":"20260724","swBuildId":"1.0.9","zclVersion":8,"interviewCompleted":true,"interviewState":"SUCCESSFUL","meta":{"configured":"0.0.0"},"lastSeen":1786710416108,"checkinInterval":3600}

Debug log

valve-monitor-clean.log

keepalive-results.log

Notes

No response

No source file, test, or entry point is named. Start by reviewing valve-monitor-clean.log and keepalive-results.log, then trace handling for the SONOFF SWV-ZF2 and its availability or reconnect behavior. Done means identifying a reproducible software cause and adding a verified fix or clearly isolating the problem to the device firmware.