[ST Edge] SONOFF Hydro ONE / DUO family (SWV-ZFE / SWV-ZFU / SWV-ZNE / SWV-ZNU / SWV-ZF2E / SWV-ZF2U)

Pajacyk0v · July 2, 2026, 10:05pm

I see we wrote practically the same thing at the same time XD

johnconstantelo · July 2, 2026, 10:06pm

See my post right above yours that I posted at the same time. The valve works fine, it’s just a few changes needed within the edge driver.

Andreas_Roedl · July 2, 2026, 11:07pm

Thanks for the feedback. Please keep in mind that I don’t have the device and a lot of the development is just trial and error. Even Zigbee2MQTT is still trying to figure it out. I found two details behind the 10-minute cutoff.

First, SONOFF’s manual_default_settings at 0x501D is not quite a normal ZCL array. SONOFF/eWeLink private-cluster arrays appear to use a one-byte element count, while a standard ZCL Array uses a two-byte count. That can shift the payload by one byte, so the device may not receive the duration value where it expects it. There is a current (one day old!) Zigbee2MQTT issue about exactly this kind of parsing problem with manualDefaultSettings / 0x501D and related eWeLink array attributes:

github.com/koenkk/zigbee2mqtt

Sonoff SWV-ZFE: RangeError [ERR_OUT_OF_RANGE] when reading seasonalWateringAdjustment

opened 01:21PM - 01 Jul 26 UTC

ingoblum

problem

### What happened? When attempting to read the `seasonal_watering_adjustment` f…rom the **SONOFF Hydro ONE (SWV-ZFE)** smart water valve, Zigbee2MQTT crashes or reports a ZCL command error with `RangeError [ERR_OUT_OF_RANGE]: The value of "offset" is out of range`. Specifically, running: ```bash mosquitto_pub -h <mqtt_broker> -t "zigbee2mqtt/<device_name>/get" -m '{"seasonal_watering_adjustment": ""}' ``` produces this error in the Zigbee2MQTT bridge logs: ``` z2m: Publish 'get' 'seasonal_watering_adjustment' to '<device_name>' failed: 'RangeError [ERR_OUT_OF_RANGE]: ZCL command 0xa4c138144fa6ffff/1 customClusterEwelink.read(["seasonalWateringAdjustment"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (The value of "offset" is out of range. It must be >= 0 and <= 21. Received 22)' ``` ### What did you expect to happen? The request should succeed, and Zigbee2MQTT should report the current monthly adjustment multipliers for all 12 months. ### How to reproduce it (minimal and precise) 1. Set the seasonal watering adjustment: ```bash mosquitto_pub -h <mqtt_broker> -t "zigbee2mqtt/<device_name>/set" -m '{"seasonal_watering_adjustment": {"january": 0.1, "february": 0.1, "march": 1, "april": 1, "may": 1.3, "june": 1.8, "july": 2, "august": 2, "september": 1.5, "october": 1, "november": 0.1, "december": 0.1}}' ``` 2. Retrieve the seasonal watering adjustment: ```bash mosquitto_pub -h <mqtt_broker> -t "zigbee2mqtt/<device_name>/get" -m '{"seasonal_watering_adjustment": ""}' ``` 3. Observe the crash/error in the bridge logs. ### Zigbee2MQTT version 2.12.0 ### Adapter firmware version Koenk/Z-Stack_3.x.0_coordinator_20250321 ### Adapter Sonoff 3.0 USB Dongle Plus (ZBDongle-P) ### Setup Zigbee2MQTT installed in Home Assistant Core 2026.6.4 running in a Qemu/libvirt VM on x86_64 with USB passthrough. - **Zigbee2MQTT Version:** 2.12.0 - **Device Type:** Sonoff Smart Water Valve SWV-ZFE - **Device Firmware ID:** 1.0.7 (20260317) - **Device Firmware Version:** 4103 ### Device `database.db` entry {"id":10,"type":"EndDevice","ieeeAddr":"0xa4c138144fa6ffff","nwkAddr":56373,"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":{"genOnOff":{"attributes":{"onOff":1}},"genBasic":{"attributes":{"hwVersion":0}},"genPollCtrl":{"attributes":{"checkinInterval":14400}},"genPowerCfg":{"attributes":{"batteryPercentageRemaining":200}},"customClusterEwelink":{"attributes":{"20504":[0,0,0,0],"manualDefaultSettings":[0,0,6,0,6,0,10,1,0,0,0,30],"childLock":0,"rainDelayEndDatetime":0,"valveAlarmSettings":[7,5,1,5],"realTimeIrrigationDuration":100663296,"realTimeIrrigationVolume":134217728,"hourIrrigationDuration":0,"hourIrrigationVolume":0,"seasonalWateringAdjustment":[1,1,10,12,14,18,20,20,15,10,1,1],"valveAbnormalState":0,"irrigationScheduleStatus":[0,0,1,0,0,0,213,228,0,0,215,76,1,0,0]}}},"binds":[{"cluster":32,"type":"endpoint","deviceIeeeAddress":"0x00124b0024c273da","endpointID":1},{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b0024c273da","endpointID":1},{"cluster":1,"type":"endpoint","deviceIeeeAddress":"0x00124b0024c273da","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":1782911609403,"checkinInterval":3600} ### Debug log The debug logs show the raw buffer response and the resulting crash stack trace: ```log [2026-06-30 18:43:41] debug: zh:zstack:znp: <-- AREQ: AF - incomingMsg - {"groupid":0,"clusterid":64529,"srcaddr":56373,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":0,"securityuse":0,"timestamp":7075077,"transseqnumber":0,"len":22,"data":{"type":"Buffer","data":[24,1,1,30,80,0,72,72,12,0,0,0,0,0,0,0,0,0,0,0,0,0]}} [2026-06-30 18:43:41] debug: zh:controller: Failed to parse frame: RangeError [ERR_OUT_OF_RANGE]: The value of "offset" is out of range. It must be >= 0 and <= 21. Received 22 [2026-06-30 18:43:41] debug: zh:controller: Received payload: clusterID=64529, address=56373, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=0, frame=undefined [2026-06-30 18:43:41] debug: zh:controller:endpoint: RangeError: ZCL command 0xa4c138144fa6ffff/1 customClusterEwelink.read(["seasonalWateringAdjustment"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (The value of "offset" is out of range. It must be >= 0 and <= 21. Received 22) at boundsError (node:internal/buffer:88:9) at Buffer.readUInt8 (node:internal/buffer:254:5) at BuffaloZcl.readUInt8 (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/buffalo/buffalo.ts:42:35) at BuffaloZcl.readArray (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/zspec/zcl/buffaloZcl.ts:147:34) at BuffaloZcl.read (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/zspec/zcl/buffaloZcl.ts:1108:29) at BuffaloZcl.readArray (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/zspec/zcl/buffaloZcl.ts:153:36) at BuffaloZcl.read (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/zspec/zcl/buffaloZcl.ts:1108:29) at Object.parse (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/zspec/zcl/definition/foundation.ts:84:44) at Function.parsePayloadGlobal (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/zspec/zcl/zclFrame.ts:193:24) at Function.parsePayload (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/zspec/zcl/zclFrame.ts:146:29) ``` ### Notes ## Analysis & Cause The underlying issue is a mismatch between how the Sonoff/eWeLink device formats custom array attributes and how standard ZCL Arrays are parsed by `zigbee-herdsman`'s buffalo reader. ### 1. The Attribute Definition In `zigbee-herdsman-converters` (specifically `src/devices/sonoff.ts`), the custom cluster attributes are defined using `DataType.ARRAY` (0x48): ```typescript seasonalWateringAdjustment: {ID: 0x501e, type: Zcl.DataType.ARRAY, write: true}, manualDefaultSettings: {ID: 0x501d, type: Zcl.DataType.ARRAY, write: true}, ``` ### 2. The standard ZCL Array spec vs. eWeLink implementation According to the Zigbee Cluster Library (ZCL) spec, a `DataType.ARRAY` payload contains: - `elementType` (1 byte) - `numberOfElements` (2 bytes, 16-bit little-endian) - `elements` (N elements, sized based on `elementType`) However, Sonoff/eWeLink devices do **not** use a 2-byte length field. Instead, they use a **1-byte length** field for arrays inside their custom cluster (e.g. cluster `0xfc11`): - `elementType` (1 byte, value `0x20` for uint8) - `numberOfElements` (1 byte, value `0x0c` for 12) - `elements` (12 bytes) - `checkCode` / `checksum` (1 byte, appended at the end of custom command payloads) This results in a total ZCL payload attribute value of 14 bytes (plus 1 byte checksum = 15 bytes). ### 3. Parsing error in `zigbee-herdsman` In `zigbee-herdsman`'s `src/zspec/zcl/buffaloZcl.ts`, the `readArray()` method parses array attributes as follows: ```typescript private readArray(): unknown[] { const values: unknown[] = []; const elementType = this.readUInt8(); const numberOfElements = this.readLengthUInt16(); // <--- Reads 2 bytes! if (!Number.isNaN(numberOfElements)) { for (let i = 0; i < numberOfElements; i++) { const value = this.read(elementType, {}); values.push(value); } } return values; } ``` Because `readLengthUInt16()` reads **2 bytes** starting at the length offset: - The low byte is read as `0x0c` (which is the actual 1-byte length). - The high byte is read from the first element of the array (January = `0x01`). - The parser interprets the array length (`numberOfElements`) as `0x010c` (which is **268 elements**). The loop then attempts to read 268 elements from the buffer. Since the response buffer length is only 22/23 bytes, it quickly runs out of bounds and throws `RangeError [ERR_OUT_OF_RANGE]: The value of "offset" is out of range` on the 13th element read (offset 22). ### 4. Impact on other attributes This also impacts other attributes defined as `Zcl.DataType.ARRAY` like `manualDefaultSettings`: - For `manualDefaultSettings` (12 elements), the first element is `mode` (typically `0` for duration). - If `mode` is `0`, the parsed 2-byte length is `0x000c` (12). This prevents a crash, but all elements are **shifted by 1 byte**, and the actual first element (`mode` = 0) is lost because it is consumed as part of the 2-byte length. If `mode` is set to `1` or `2`, reading this attribute will also crash with a `RangeError`. #### Payload Buffer Decoding: The raw payload byte array is: `[24, 1, 1, 30, 80, 0, 72, 72, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]` - **Bytes 0–2 (ZCL Header):** `24, 1, 1` (Direction: Server to Client, Command: Read Attributes Response) - **Bytes 3–4 (Attribute ID):** `30, 80` (`0x501e` low/high byte for `seasonalWateringAdjustment`) - **Byte 5 (Status):** `0` (`SUCCESS`) - **Byte 6 (Attribute Data Type):** `72` (`0x48` = `Zcl.DataType.ARRAY`) - **Byte 7 (Array Element Type):** `72` (`0x48` = `Zcl.DataType.ARRAY`) *(Here is the anomaly: the device reports the elements themselves are also arrays)* - **Bytes 8–9 (Number of Elements):** `12, 0` (`0x000c` = 12 elements) - **Bytes 10–21 (Payload Elements):** 12 bytes of `0`s (`0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0`) Because the parsed element type is `0x48` (ARRAY), the parser calls `readArray()` recursively for each of the 12 elements: - **Sub-Array 0 (starting at byte 10):** Reads `elementType` = `0` (`NO_DATA`), `numberOfElements` = `0` (reads 2 bytes). Consumes 3 bytes (`0, 0, 0`). Returns `[]`. (New offset is 13) - **Sub-Array 1 (starting at byte 13):** Reads `elementType` = `0` (`NO_DATA`), `numberOfElements` = `0`. Consumes 3 bytes (`0, 0, 0`). Returns `[]`. (New offset is 16) - **Sub-Array 2 (starting at byte 16):** Reads `elementType` = `0` (`NO_DATA`), `numberOfElements` = `0`. Consumes 3 bytes (`0, 0, 0`). Returns `[]`. (New offset is 19) - **Sub-Array 3 (starting at byte 19):** Reads `elementType` = `0` (`NO_DATA`), `numberOfElements` = `0`. Consumes 3 bytes (`0, 0, 0`). Returns `[]`. (New offset is 22) - **Sub-Array 4 (starting at byte 22):** The parser attempts to read the `elementType` at offset 22. Since the total ZCL payload is exactly 22 bytes long (indices 0 to 21), offset 22 is out of bounds, throwing the `RangeError [ERR_OUT_OF_RANGE]`. This shows that when the device memory contains uninitialized/default data (all `0` elements with `0x48` element type), a recursive `readArray` loop is triggered that parses the remaining buffer bytes as child empty arrays and crashes. --- ## Possible Fix `Zcl.DataType.ARRAY` (0x48) could be avoided for these custom attributes. An option would be to use `OCTET_STR` (0x41) or maybe `LONG_OCTET_STR` (0x42). With that `seasonalWateringAdjustment`, `manualDefaultSettings`, and other eWeLink array attributes could be redefined as `Zcl.DataType.OCTET_STR`. With this there would be a 1-byte length prefix followed by raw bytes, matching the device's actual format. In `fromZigbee` and `toZigbee`, the values could then be treated as raw buffers/Uint8Arrays. Another option, if the device writes standard datatype bytes in response packets, could implement custom `toZigbee` and `fromZigbee` logic that bypasses the built-in herdsman array parser, or map them to raw custom buffer handlers.

Second, the device has both a manual watering duration and a separate manual fail-safe timeout. The previous build could change the duration, while the fail-safe value could still remain at 10 minutes.

The new build therefore writes 0x501D using the SONOFF/eWeLink array format and sets both values together:

Manual watering duration = selected value
Manual fail-safe timeout = selected value

So if you set Manual watering duration to 60 minutes, both internal limits should now be set to 60 minutes. Make sure to have the latest driver version 2026-07-02T22:59 installed, set the value again, press Refresh, and test whether the valve stays open beyond 10 minutes.

The waterSensor = dry part is still expected: in this driver, dry means no leak detected, not “no water supply.” That wording is confusing in SmartThings, because waterSensor means water leak sensor.

Andreas_Roedl · July 3, 2026, 12:00am

2 am here. Going to bed now.

johnconstantelo · July 3, 2026, 2:02am

I did all that and verified the driver version, but unfortunately the 10 minute issue is still happening. I’ll be glad to help test if you want help.

Andreas_Roedl · July 3, 2026, 7:44am

New version: 2026-07-03T07:38.

I made one more adjustment to the 0x501D manual watering setting.

The previous build was based on a Zigbee2MQTT finding that some SONOFF/eWeLink private array attributes are parsed differently from normal ZCL arrays. That was a useful clue, and manualDefaultSettings / 0x501D is one of the affected attributes.

However, the working deCONZ implementation for the Hydro ONE Lite writes 0x501D more specifically as a normal ZCL Write Attributes payload with a standard array header. So this build now follows that deCONZ write format, while still writing both the manual duration and the fail-safe timeout to the selected value.

Please test again by setting Manual watering duration to 20 minutes, refresh, and then checking whether the valve stays open beyond 10 minutes.

johnconstantelo · July 3, 2026, 8:54am

Will test a little later this morning, thanks for your work on this driver, much appreciated!

johnconstantelo · July 3, 2026, 7:24pm

Hi @Andreas_Roedl ,

Unfortunately I have to report that it’s still 10 minutes. Requested 14 minutes, but closed after 10:

Settings:

Andreas_Roedl · July 3, 2026, 7:37pm

Well … I think it’s time for some logs. I had a guy who was providing me logs, but he’s on vacation or something.

Anyway. New version: 2026-07-03T19:54

Added a keepalive to override the firmware timeout.

Make sure that the latest version is installed.
Keep Timed watering mode = driver timer.
Set Manual watering duration to 20 or 60.
Refresh.
Request Open valve for minutes = 14 or 15.
Check whether it now runs beyond 10 minutes.

johnconstantelo · July 3, 2026, 8:31pm

No worries, I can provide logs for you too, but I just left for a short holiday until Tuesday. This isn’t urgent by any means, but I’ll let you know how my additional testing goes. Hope you have a good weekend and your temperatures are cooler.

Andreas_Roedl · July 3, 2026, 8:46pm

Outside and wearing a jacket now.

TheHundredthIdiot · July 4, 2026, 7:22pm

Hi @Andreas_Roedl

Ermmmm… Since the driver updated to …07-03… it has failed to operate my valve at all, just not responsive

Re-added device but no joy, I’ve had to resort to ST stock

Andreas_Roedl · July 4, 2026, 7:45pm

Sorry about that. That version introduced an regression while trying to work around the 10-minute timeout, and that could make the valve stop responding. I’ve pulled that build and replaced it with a newer one (2026-07-04T19:41), which rolls back the risky changes and is meant to restore reliable basic valve operation first.

The timed-watering cutoff is still under investigation, and I’ll need logs before trying another fix.

Edit: version 2026-07-05T00:56 changes Open valve for minutes to use Zigbee On with Timed Off with strict ZCL timing, while keeping the driver-side close timer as a backup and leaving normal Valve/Switch control unchanged.

Andreas_Roedl · July 5, 2026, 12:17am

To keep the logs useful, please capture only the driver log around one clean test.

Before testing (important):

Make sure that the latest version is installed: 2026-07-05T00:56
Open the device settings in SmartThings.
Enable Debug logging.
Set Manual watering duration to 60.
Make sure Timed watering mode is set to driver timer.

Then start SmartThings Edge logcat for this driver, for example:

smartthings edge:drivers:logcat 51a4dea2-3014-4988-9ac2-3821070cd2b9

Now perform this exact test:

Set Manual watering duration to 60 again and save.
Wait 5–10 seconds.
Refresh by pulling down.
Use Open valve for minutes and request 14 or 15 minutes.
Let the valve run until it closes by itself, or until the requested time has passed.
Stop logcat.

Please send only the relevant part of the log, starting shortly before changing Manual watering duration and ending shortly after the valve closes.

Thanks!

Turns out that the fail-safe timeout must be set to 0 and not the duration! That’s what the official ZHA quirk does.

By the way: they have the same issue in Home Assistant and there’s no definite confirmation that it works.

TheHundredthIdiot · July 5, 2026, 9:11am

Thanks @Andreas_Roedl , 2026-07-05T00:56 installed and back to running with it now

Not using duration specifically at present but watching the discussion with interest…

Thanks again

johnconstantelo · July 5, 2026, 3:57pm

Hi @Andreas_Roedl , I’m still waiting for SmartThings to update the driver on my end. I’m still on 2026-07-04T20:14:16.

I noticed that on this version that if I selected any value with timed watering that the presentation showed the valve open and on, but it actually didn’t open. Even though I’m on holiday, I can still monitor water flow because my water meter is “smart” and in ST. It’s not showing any water flow:

Opening via timed watering:

no water flow:

Just turning on the valve does open the valve and water begins to flow:

I’ll wait for the new driver version to get installed on my hubs and try again, but I wanted to let you know about this behavior. Unfortunately I’m still on holiday and don’t have my laptop available to do any logging for you until Tuesday.

Thanks again for all your work on this, especially since you don’t have the device to work with.

Andreas_Roedl · July 5, 2026, 4:14pm

That’s weird, because the driver was packaged and assigned about 16 hours ago and automatically updated on my hub in minutes.

I’ll wait for the new driver version to get installed on my hubs and try again, but I wanted to let you know about this behavior.

I’m quite confident that the latest version fixed the issue, because I have found the “official” ZHA quirk from eWeLink/Sonoff and my driver is doing exactly what they are doing.

johnconstantelo · July 6, 2026, 2:29pm

Hi @Andreas_Roedl , my hubs got updated to 2026-07-05T17:45:51.965082118 since my last post, and I was able to do some testing this morning before leaving for the day.

I set the timed watering for 14 minutes, and it closed after 14 minutes, which is great. Unfortunately it didn’t actually open the valve because my meter recorded no water flow. If I just opened the valve, or turned it “On”, the valve did open and the meter recorded water flow. I have set the manual watering duration for 20 minutes, so now I’m just waiting to see if it shuts off after 10 minutes, or at 20 minutes. I’ll edit this post with any updates.

EDIT : It shut off after 10 minutes, not the 20 that was set up in preferences. See the last screenshot below.

Sorry for not being able to provide any logs while I’m away, but I will as soon as I get home.

Andreas_Roedl · July 6, 2026, 4:41pm

Cool. But make sure that version 2026-07-06T16:27 is installed.

Test:

Start the logging
Set Manual watering duration = 20
Save
Refresh
Wait for 0x501D readback
Then open valve normally and let it run
Paste log here

Andreas_Roedl · July 8, 2026, 6:55pm

Finally some (740 lines) logs! Thanks, @Pajacyk0v !

This log is very clear: the previous version did not fix the 10-minute cutoff because the 0x501D write was rejected by the device.

The important line is:

DefaultResponse || cmd: 0x02, ZclStatus: FAILURE

That means the standard/non-manufacturer-specific 0x501D write did not get accepted. The later readback also returns only zeroes, so the device never stored the requested 59 minutes. The normal On command itself succeeded and the valve opened, but the internal 10-minute device limit remained active.

The new version 2026-07-08T18:48 writes 0x501D through the SONOFF manufacturer-specific frame again, as one of the earliest versions of the driver.

Topic		Replies	Views
Edge driver for an external Vaticas zigbee water valve actuator Devices & Integrations	48	2403	December 10, 2024
Watercop zwave valve driver wrong state display in the app Devices & Integrations	16	810	December 11, 2023
[ST Edge] Driver for SONOFF SNZB-02 Community Created Drivers edge-device , edge_lighting , edge_sensors , edge_remotes	37	9432	February 24, 2026
WaterCop Z-Wave Water Shutoff Valve (rebranded Fortrezz) $136 Deals	70	8475	August 26, 2022
Fortrez Z Z-Wave Water Valve Randomly Showing Incorrect State Devices & Integrations	30	2259	October 24, 2023

[ST Edge] SONOFF Hydro ONE / DUO family (SWV-ZFE / SWV-ZFU / SWV-ZNE / SWV-ZNU / SWV-ZF2E / SWV-ZF2U)

Related topics