Excellent, thanks for that update, and thank you to @Pajacyk0v for providing you those logs.
I just couldn’t get to testing for you today, sorry about that. Due to bad weather in our area of the US, it caused so many flight delays that we didn’t get home until 2am this morning.
No worries. Take your time!
New logs, new version: 2026-07-09T17:19
Old:
0x501D write = mfg frame + standard/ZHA Array
→ rejected
New:
0x501D write = mfg frame + Sonoff private array shape
→ outer type Array 0x48
→ inner marker 0x48
→ one-byte length
→ payload
Thanks for testing. Even without logs, this confirms that this version does not yet change the valve’s internal 10-minute limit. Since the driver writes the selected duration again immediately before opening, the remaining problem is almost certainly the exact private Zigbee write format rather than the SmartThings preference or timer itself.
I’ll ask in the eWeLink/Sonoff forums if they can provide the exact raw write format. As I said before, it’s quite complicated on SmartThings to format the correct Zigbee frame.
New version: 2026-07-12T12:14
Different payload, more debug logging.
Hi @Andreas_Roedl, I had to focus the last few days on some big projects we had at work so I hadn’t done much testing for you. I’ll be able to do quite a bit on Tuesday and post logs for you on what I’m seeing.
First of all, thank you for continuing to test these builds. I know that repeatedly installing a new driver and then waiting more than ten minutes to see whether anything changed is becoming frustrating.
The important point is that the driver is working correctly: the valve can be opened and closed, water consumption is reported, and the SmartThings timer works. The remaining problem is the valve’s own internal manual-watering limit, which is stored in SONOFF’s private Zigbee attribute 0x501D.
Unfortunately, this is not a normal numeric Zigbee setting. It is part of a complete 12-byte manual_default_settings configuration containing the watering mode, duration, interval, volume unit, volume and fail-safe timeout. The valve appears to reject the entire write when even the framing or array serialization differs slightly from what its firmware expects.
The repeated test versions have therefore not been random changes. Each one tested a different interpretation of the private protocol:
test11 standard Zigbee frame, simplified array
test12 manufacturer-specific frame, simplified array
test13 manufacturer-specific frame, private SONOFF-style array
test14 manufacturer-specific frame, complete Z2M-style configuration
test15 standard Zigbee frame, complete Z2M-style configuration
The logs from the earlier versions showed that the normal On command was accepted, while the 0x501D configuration write was rejected. That is why the valve opened normally but still closed itself after approximately ten minutes.
SmartThings is not the only integration having trouble. Zigbee2MQTT currently has an open issue specifically about the SWV-ZFE because its documented timed-control methods are unreliable on real hardware. Users there report that on_time may not open the valve at all, which is the same behaviour we observed when testing OnWithTimedOff on SmartThings. The only repeatedly successful Zigbee2MQTT sequence reported there was to write the complete manual settings first and then send a normal On command.
Zigbee2MQTT also recently had to revert changes to these settings after it became clear that fields such as the duration and fail-safe cannot safely be written independently. The complete configuration has to be sent atomically in one transaction, which confirms that this device protocol is more complicated than it initially appears.
ZHA support for the Hydro ONE and Hydro DUO family is also still being developed in an open pull request. It adds device identification and sensor support, but it does not currently provide a hardware-verified solution for changing this internal manual-watering limit.
A Home Assistant user did confirm that changing the Manual Default Settings through Zigbee2MQTT raised the valve’s limit from around 10 minutes to 15 minutes. That proves that 0x501D is the correct setting, but it does not tell us exactly how SmartThings must serialize the write on the Zigbee wire.
Test15 is currently the most evidence-based implementation. It mirrors the current Zigbee2MQTT code as closely as SmartThings Edge allows:
standard, non-manufacturer-specific Write Attributes frame
standard Zigbee Array with Uint8 elements
complete 12-byte manual_default_settings configuration
normal On command after the settings write
It is therefore not simply another speculative variation. It tests the combination that the current Zigbee2MQTT source appears to use.
I do not intend to keep asking for endless tests of versions that merely rearrange bytes. If test15 is also rejected, the next meaningful step will be to capture a known-working raw Zigbee2MQTT transaction and compare it byte for byte with the SmartThings packet. That would require to buy a device and test it on a different platform. At that point the problem is most likely SmartThings’ low-level array serialization rather than the logical values being sent.
One final test15 test, preferably with logs, would therefore give me a clear answer about whether this approach works or whether we need to move to a raw packet comparison. 
Thank you again for the time and patience you have already invested. Even the unsuccessful tests have narrowed the problem considerably and prevented unverified behaviour from being released as a finished solution.
CC: @Pajacyk0v
Okay…
Please test the device with the driver from the PR for the official SmartThings Zigbee Valve Edge Driver.
Update the firmware via Bluetooth and the eWeLink/SONOFF app from 1.0.7 to 1.0.8! This works while the device is connected to ST.
CC: @Pajacyk0v
Oh wow, ok. I had to leave town again for a family matter, but I’ll do all that as soon as I get home.
If you only have limited time to do some tests, just update the firmware and test it with my driver.
The PR for the official driver only adds the fingerprints and the stock driver does pretty much the same as my driver, but without the special features. As long as it doesn’t set the timer limit, it will stop after 10 minutes.
That’s probably the reason why the PR is lingering for a month now. My guess: they are waiting for a firmware update.
A device that has an internal limit should make it easy and predictable to configure this limit. It shouldn’t require a magic spell or hidden message.
I’ve added a comment on the PR, asking what firmware they were using for the WWST certification and how they are planning to change the preset on-device limit of 10 minutes.
For those interested, this is the relevant code to create and send the payload:
local cluster_base = require "st.zigbee.cluster_base"
local data_types = require "st.zigbee.data_types"
local EWELINK_CLUSTER_ID = 0xFC11
local ATTR_MANUAL_DEFAULT_SETTINGS = 0x501D
local function standard_write_attribute_data(device, cluster_id, attr_id, data)
return cluster_base.write_attribute(
device,
data_types.ClusterId(cluster_id),
data_types.AttributeId(attr_id),
data
)
end
local function write_manual_default_duration(device, minutes)
local value = math.max(1, math.min(719, math.floor(tonumber(minutes) or 10)))
local high = (value >> 8) & 0xFF
local low = value & 0xFF
local irrigation_interval = 10
local interval_high = (irrigation_interval >> 8) & 0xFF
local interval_low = irrigation_interval & 0xFF
local payload = {
0x00, -- irrigation mode: duration
high,
low, -- total irrigation duration
high,
low, -- irrigation duration
interval_high,
interval_low, -- irrigation interval = 10
0x01, -- irrigation amount unit: litre
0x00,
0x00, -- irrigation amount = 0
high,
low, -- fail-safe timeout
}
local array_data = data_types.validate_or_build_type(
{
data_types.Uint8(payload[1]),
data_types.Uint8(payload[2]),
data_types.Uint8(payload[3]),
data_types.Uint8(payload[4]),
data_types.Uint8(payload[5]),
data_types.Uint8(payload[6]),
data_types.Uint8(payload[7]),
data_types.Uint8(payload[8]),
data_types.Uint8(payload[9]),
data_types.Uint8(payload[10]),
data_types.Uint8(payload[11]),
data_types.Uint8(payload[12]),
},
data_types.Array
)
local message = standard_write_attribute_data(
device,
EWELINK_CLUSTER_ID,
ATTR_MANUAL_DEFAULT_SETTINGS,
array_data
)
device:send(message)
end
local function send_on(device, component_id)
write_manual_default_duration(
device,
device.preferences.manualDuration
)
send_zcl_to_component(
device,
component_id,
OnOff.server.commands.On(device)
)
end
Payload for 15 minutes: 00 00 0F 00 0F 00 0A 01 00 00 00 0F
New version: 2026-07-17T00:44:49
Minor change to the payload: fail-safe = duration + 1
Quick update: firmware is full of bugs:
Especially the format of the array.
New version: 2026-07-18T18:19
2174 lines of code (Lua only) for a valve…
First of all, thank you for taking the time! I have red every comment about solving the water duration. I am not a developer, but I can image that it is frustation for you as well that the issue is not solved yet. Do we now have to wait for a firmware update to solve this? I am on 2026-07-18T18:19
I know that quite a few people have already contacted SONOFF by now - not only from this community, but also from the much more active Home Assistant/ZHA/Z2M community.
I’d also like to know how they envision the WWST certification, where only the fingerprints are added to the existing Zigbee Valve Edge Driver and nothing else at all. In that case, it wouldn’t even be theoretically possible to change any settings on the device - and of course not the factory-preset 10-minute limit either. Someone tested the driver from the PR channel and of course the valve turned off after 10 minutes. I don’t think that this is what they want.
I’ve commented on the pull request - there’s nothing more I can do.
When I think about how much time and effort has been wasted, because after countless versions my driver still does nothing different from the very beginning, just like the other integrations. Everyone has been trying for weeks or months to find the secret magic spell, and in the end it’s probably just a firmware bug. I mean, it seems to be quite unstable and unreliable anyway, because another developer reported constant crashes.
We’ll see…
Thanks for the update.T hat really clears things up.
It’s wild that so many people across different communities have contacted SONOFF and we still end up with the same 10‑minute shutdown because nothing in the driver can actually change any settings.
You’ve done what you can by commenting on the pull request.
We will wait indeed…
Hi @Andreas_Roedl ,
I think my valve just isn’t right.
All of a sudden it just turned on/open all by itself a couple hours ago, and what’s odd is that ST still showed the valve as off/closed. I found out that it was on because my water meter notified me of a device using too much water and I saw that the soaker hose was actually releasing water.
I tried turning it off/closed via ST, but all that did was change the state to on/open, so I tried again. This time it did change the state to off/closed, and you could hear the valve “click” closed, BUT it immediately opened again all by itself.
I thought, OK let’s see if the firmware upgrade does anything. Nope, nothing.
Next I thought maybe something with ST is weird, so I removed it from ST, reset the device, added it back to ST, and nope - still opening on it’s own after closing.
Ok, now I’m really puzzled, so I removed it from ST, reset it, and added it to the eWeLink app and made sure the firmware was current. No luck that way either. It still turned itself on/open.
Even the most simplest manual operation via the button on the device performs this way. As soon as you press the button to turn the valve off/open, you can here it “click” back on/open and water flows again. What’s interesting via the manual method is that the ST or eWeLink app will show the valve opening or closing when done manually, BUT when it turns on by itself, neither app shows it as on/open.
I’m beginning to regret this purchase just because of what you’ve mention above with all the issues, and now with this behavior. I’ll submit a support ticket to Sonoff to see what they have to say about how this in behaving.
Nothing needed from you, just giving you info and thanking you again for working on this.
Sounds like it’s fundamentally broken. The valve has an internal schedule, but it should be cleared after a factory reset. Who knows what happens on the device when the firmware crashes.
The decisive point is that the behaviour continued after you removed the valve from SmartThings, factory-reset it, paired it with eWeLink and even operated it only with the physical button. SmartThings can therefore be ruled out almost completely. The fact that the valve physically opens again while SmartThings or eWeLink still shows it as closed is particularly concerning, because the real valve position and the reported Zigbee state have become disconnected.
I searched for recent reports of similar behaviour. I did not find another case matching your complete sequence exactly, but there are several closely related reports:
OFF, as well as valves that did not stop reliably when an irrigation timer expired.The only non-hardware explanation I can still imagine would be a locally stored irrigation schedule or a corrupted active watering session. These valves can execute schedules locally, without a gateway connection. However, after everything you have already tried, a defective motor-position sensor, corrupted persistent state or another internal firmware/hardware fault appears at least as likely.
I would no longer leave this valve connected to an unattended water supply. A valve that can open while every connected app reports it as closed is not safe to rely on. SONOFF support should ideally confirm whether a factory reset really clears all stored schedules and irrigation state. If it still closes and immediately reopens while factory-reset and completely unpaired, I would consider the unit defective and request a replacement.
Please let us know what SONOFF says. Your report is valuable because it also shows that these devices can apparently move physically without publishing the corresponding standard On/Off state - a problem that cannot be fixed by changing my driver.
Yup, no problem. I just submitted the support form. Stay tuned.
I definitely did not have any schedule in ST or eWeLink. We always operated the valve through ST or manually via the button on the device.
Agreed, and thankfully my water meter monitors water flow and notifies us when things happen that shouldn’t be happening regardless if we’re home or away. That’s probably one of my most used/valuable devices I have set up in SmartThings.
Some good news for everyone following the SONOFF Hydro saga. The upcoming SONOFF Hydro firmware update looks very promising!
A new zigbee-herdsman-converters pull request has just been merged that adds support for the latest firmware versions of the SONOFF Hydro family:
According to the PR author, the new firmware has been tested on real hardware, including pairing, manual irrigation, irrigation plans, and the updated water flow unit support.
The really interesting part is that the converter now contains explicit compatibility handling for both the older and the new firmware generations. This strongly suggests that SONOFF has continued developing the Hydro firmware and addressed protocol issues that previously required workarounds in multiple Zigbee ecosystems.
The update also introduces support for the new 0x5021 Water Flow Unit attribute, including imperial gallons, while remaining compatible with older firmware versions.
Hopefully the corresponding OTA firmware will become publicly available soon. It will be very interesting to see whether these firmware updates also resolve some of the long-standing interoperability issues that users have encountered across SmartThings, Zigbee2MQTT and ZHA.
Overall, this is a very encouraging sign that the Hydro product line is still actively maintained by SONOFF.
Source:
CC: @Pajacyk0v @Leetjevw
Edit: New version 2026-07-21T12:40
unitOfWaterFlow (0x5021) on single-channel firmware 1.1.0+ and Hydro DUO firmware 1.0.9+. The attribute is read and recorded, but never changed by this build.manualDefaultSettings (0x501D) parsing mode-aware, preserving valid capacity-mode configurations even when both duration fields are zero.They got back with me early this morning and want me to tap on the side of the valve to make sure the solenoid isn’t stuck, and to also send them a short video of what it’s going. They said that if we can’t figure it out, they should be able to replace it.