Koenkk / Koenkk/zigbee2mqtt

SWV-ZFE: documented control payloads are unreliable / incomplete on real hardware, need correct device-specific docs

Open
#32,479 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

problem
Dominant language
TypeScript
Stars
15.7k
Forks
2k
Avg merge
18h 55m
Merged PRs (30d)
35

Description

What happened?

We are trying to control a real SONOFF SWV-ZFE valve via Zigbee2MQTT.

The current SWV-ZFE documentation suggests that normal switch control should work via:
{"state":"ON"}

and that timed control might work via:
{"state":"ON","on_time":300}

optionally with:
{"state":"ON","on_time":300,"off_wait_time":120}

On our real hardware, these documented paths were not reliable enough to build a safe integration.

Direct local observations from repeated MQTT tests against the real valve:

  • {"state":"ON","on_time":1} did not start the valve.
  • {"state":"ON","on_time":5,"off_wait_time":1} did not start the valve.
  • {"state":"ON","on_time":30} did not start the valve.
  • plain {"state":"ON"} was also not reliably sufficient from state=OFF / schedule_status=end.
  • {"state":"TOGGLE"} did not reliably start the valve either.

The only repeatedly observed positive control path on our device was:

  1. first write manual_default_settings
  2. then immediately send plain {"state":"ON"}

Example of a working sequence we observed:

{
"manual_default_settings": {
"irrigation_duration": 1,
"irrigation_mode": "duration",
"irrigation_amount_unit": "liter",
"irrigation_amount": 0,
"fail_safe": 2
}
}

followed by:

{"state":"ON"}

That sequence produced a real transition to:

  • irrigation_schedule_status.schedule_status = "start"
  • state = "ON"

We also observed another successful run with:

{
"manual_default_settings": {
"fail_safe": 2,
"irrigation_amount": 1,
"irrigation_amount_unit": "liter",
"irrigation_duration": 1,
"irrigation_mode": "capacity"
}
}

followed by a start reaching:

  • schedule_status = "start"
  • state = "ON"

Additionally, the documentation seems incomplete or at least unclear around irrigation_mode:

  • The current SWV-ZFE docs list manual_irrigation_mode values as duration and capacity.
  • On our real device, we also observed duration_with_interval in runtime data.

That makes it unclear which modes are actually supported for SWV-ZFE, which are user-settable, and which command combinations are expected to work.

We also repeatedly observed confusing runtime data during tests, for example:

  • year-2000 timestamps
  • extremely large real_time_irrigation_duration
  • extremely large real_time_irrigation_volume

That made it harder to distinguish valid state reporting from stale/corrupted-looking telemetry.

What did you expect to happen?

We expected the SWV-ZFE documentation to provide a correct and device-specific way to:

  • start the valve manually
  • start it for a bounded time
  • stop it again
  • understand which payload combinations are actually supported

More concretely:

  • if {"state":"ON","on_time":N} is documented for this device, it should either work on supported firmware or the docs should clearly state limitations
  • if manual_default_settings must be written before state=ON, that should be documented explicitly
  • if duration_with_interval is a real SWV-ZFE mode, that should be documented explicitly
  • if some control methods only work on some firmware/hardware revisions, that should also be documented explicitly
How to reproduce it (minimal and precise)

Use a real SWV-ZFE device in Zigbee2MQTT.

Start from a state where the valve reports:

  • state: "OFF"
  • irrigation_schedule_status.schedule_status: "end"

Then send the following payloads to:

zigbee2mqtt/<friendly_name_or_ieee>/set

Non-working examples we observed

{"state":"ON","on_time":1}

{"state":"ON","on_time":5,"off_wait_time":1}

{"state":"ON","on_time":30}

{"state":"ON"}

{"state":"TOGGLE"}

Observe that the device may remain on:

  • state = "OFF"
  • irrigation_schedule_status.schedule_status = "end"

Working sequence we observed

First send:

{
"manual_default_settings": {
"irrigation_duration": 1,
"irrigation_mode": "duration",
"irrigation_amount_unit": "liter",
"irrigation_amount": 0,
"fail_safe": 2
}
}

then immediately:

{"state":"ON"}

On our device, that produced a real start with:

  • schedule_status = "start"
  • state = "ON"
Zigbee2MQTT version

2.10.1

Adapter firmware version

{"meta":{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20210708,"transportrev":2},"type":"ZStack3x0"}

Adapter

zstack

Setup

Local Docker Compose setup.

Relevant local evidence:

  • compose image: ghcr.io/koenkk/zigbee2mqtt:latest
  • frontend port mapping: 8099:8080
  • Zigbee2MQTT data directory: /app/data
  • MQTT broker used by Zigbee2MQTT: mqtt://mosquitto:1883
  • startup log showed: "Starting Zigbee2MQTT version 2.10.1"
Device database.db entry

{"id":4,"type":"EndDevice","ieeeAddr":"0xa4c138145043ffff","nwkAddr":9176,"manufId":4742,"manufName":"SONOFF","powerSource":"Battery","modelId":"SWV-ZFE","epList":[1],"endpoints":{"1":{"profId":260,"epId":1,"devId":2,"inClusterList":[0,1,3,6,32,64599,64529],"outClusterList":[3,25],"clusters":{"genBasic":{"attributes":{"modelId":"SWV-ZFE","manufacturerName":"SONOFF","powerSource":3,"zclVersion":8,"appVersion":16,"hwVersion":0,"dateCode":"20260317","swBuildId":"1.0.7"}},"genOnOff":{"attributes":{"onOff":0}},"genPowerCfg":{"attributes":{"batteryPercentageRemaining":200,"batteryVoltage":0}},"customClusterEwelink":{"attributes":{"20495":0,"20504":[0,0,0,0],"20506":0,"childLock":0,"realTimeIrrigationDuration":10,"realTimeIrrigationVolume":85,"hourIrrigationDuration":0,"hourIrrigationVolume":0,"manualDefaultSettings":[1,0,1,0,1,0,10,1,0,1,0,2],"rainDelayEndDatetime":0,"valveAlarmSettings":[7,5,1,5],"seasonalWateringAdjustment":[10,10,10,10,10,10,10,10,10,10,10,10],"irrigationScheduleStatus":[1,0,1,1,0,3,203,206,0,3,204,70,0,3,203,132,0,1,0,0,0],"valveAbnormalState":0}},"genPollCtrl":{"attributes":{"checkinInterval":14400}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b0039df8b5d","endpointID":1},{"cluster":1,"type":"endpoint","deviceIeeeAddress":"0x00124b0039df8b5d","endpointID":1},{"cluster":32,"type":"endpoint","deviceIeeeAddress":"0x00124b0039df8b5d","endpointID":1}],"configuredReportings":[{"cluster":1,"attrId":33,"minRepIntval":3600,"maxRepIntval":65000,"repChange":10}],"meta":{}}},"appVersion":16,"hwVersion":0,"dateCode":"20260317","swBuildId":"1.0.7","zclVersion":8,"interviewCompleted":true,"interviewState":"SUCCESSFUL","meta":{"configured":"0.0.0"},"lastSeen":1783106029569,"checkinInterval":3600}

Debug log

Relevant local startup log excerpt:

[2026-06-30 17:05:54] info: z2m: Starting Zigbee2MQTT version 2.10.1 (commit #94751abaacb66989e688f21d8ac3773cf5d754a9)
[2026-06-30 17:05:54] info: z2m: Starting zigbee-herdsman (10.0.7)
[2026-06-30 17:05:54] info: zh:adapter:discovery: Matched adapter=zstack path=/dev/ttyUSB0, score=4
[2026-06-30 17:05:56] info: z2m: Coordinator firmware version: '{"meta":{"maintrel":1,"majorrel":2,"minorrel":7,"product":1,"revision":20210708,"transportrev":2},"type":"ZStack3x0"}'
[2026-06-30 17:05:56] info: z2m: 0xa4c138145043ffff (0xa4c138145043ffff): SWV-ZFE - SONOFF Zigbee smart water valve (EndDevice)

Relevant live-error excerpts during our control tests:

[2026-07-03 20:54:56] error: z2m: No converter available for 'valve_abnormal_state' on '0xa4c138145043ffff': ("")
[2026-07-03 20:54:59] error: z2m: No converter available for 'valve_abnormal_state' on '0xa4c138145043ffff': ("")
[2026-07-03 20:55:27] error: z2m: No converter available for 'valve_abnormal_state' on '0xa4c138145043ffff': ("")
[2026-07-03 20:55:32] error: z2m: No converter available for 'valve_abnormal_state' on '0xa4c138145043ffff': ("")

Relevant observed examples from our local testing include:

  • failed on_time attempts from OFF/end
  • successful manual_default_settings + plain state=ON
  • observed runtime telemetry containing stale/corrupted-looking values
Notes

This issue is specifically about SWV-ZFE, not SWV.

That distinction matters because:

  • SWV and SWV-ZFE have different documented capabilities
  • related reports for SWV should not automatically be assumed to apply to SWV-ZFE

Relevant docs:
https://www.zigbee2mqtt.io/devices/SWV-ZFE.html

Possibly related issue for a different device (SWV, not SWV-ZFE):
https://github.com/Koenkk/zigbee2mqtt/issues/27465

The main request is better and correct SWV-ZFE documentation for real-world manual valve control.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the SWV-ZFE device documentation at the linked page and compare its control payloads and irrigation modes with the reported real-hardware observations. Reproduce the documented and working MQTT sequences on SWV-ZFE hardware, then update the device-specific documentation to state supported payloads, modes, firmware limitations, and telemetry caveats clearly.

Written by the indexing model from the issue text.

Assessment

Domain
documentation, embedded-iot
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.