For the life of me, I can’t get the latest driver to update. I’m still on 2026-07-30T12:24:42.
EDIT : I was able to force the update by attempting to delete the driver. Found an earlier post suggesting that method, and it seemed to work.
- Please make sure that the device’s firmware is up-to-date. Use the eWeLink app to check and update via Bluetooth.
- Re-install the driver: delete the device in ST, delete the driver, install the driver, re-add the device. This procedure makes sure that everything is initialized correctly. The driver itself supports driver switching, but who knows if the device accepts certain settings only after pairing - it’s a sleepy (and buggy) device after all.
- Very important: go through the settings and change the Device-side watering limit. The default is still 10 minutes, because that’s the factory preset default on the hardware itself (at least in some firmware versions).
I also need to know your model and the current firmware version.
There is now some rather revealing clarification about the upcoming official WWST support for the SONOFF Hydro valves.
The original WWST pull request #3027 merely added fingerprints for SWV-ZFE, SWV-ZFU, SWV-ZNE and SWV-ZNU to the generic Zigbee valve driver. SmartThings later confirmed that SONOFF had requested basic valve control only.
That PR has since been closed because “some custom changes” were required. The replacement is PR #3157, which adds a SONOFF-specific subdriver.
Unfortunately, “SONOFF-specific” currently means little more than:
- send standard Zigbee
OnandOff; - translate the resulting OnOff reports into Valve states;
- report the battery;
- support Refresh.
The entire private SONOFF cluster 0xFC11 is still ignored. That includes attribute 0x501D (manualDefaultSettings), which is precisely where the valve stores the duration used for ordinary manual watering.
I therefore asked the developer whether the valve had actually been left open for longer than ten minutes. The answer is refreshingly unambiguous:
- The valve still switched itself off after ten minutes.
- The tested device was already running firmware 1.1.0.
- The current SmartThings driver will not affect the automatic ten-minute shutdown.
- Support for private attributes is planned only after the initial WWST certification.
So the official driver is apparently going to certify a valve that opens correctly, reports that it is open correctly - and then closes itself ten minutes later exactly as before.
A WWST badge alone will, unsurprisingly, not reconfigure the firmware.
This also confirms that firmware 1.1.0 has not magically removed the limit. A normal Zigbee On still starts a watering session using the duration already stored inside the valve. The driver may send On perfectly, but that does not make the valve remain open.
The behavior is already documented by the independent work in ZHA and Zigbee2MQTT. Their hardware investigations showed that the relevant duration is stored in private cluster 0xFC11, attribute 0x501D, and that changing this configuration allows the valve to remain open beyond ten minutes.
That is the difference between “the device pairs and reacts to On/Off” and “the product is actually supported.”
My driver is already far ahead of the proposed official implementation.
It supports:
- Hydro ONE, ONE Lite and Hydro DUO;
- standard Valve and Switch control;
- both DUO channels;
- custom timed watering;
- driver-side automatic closing;
- recovery after driver or hub restarts;
- device-side duration configuration through
0x501D; - verification of both duration fields and the separate fail-safe timeout;
- child lock;
- irrigation duration and volume statistics;
- shortage, leakage, frost and fail-safe alarms;
- alarm and auto-close configuration;
- firmware-aware behavior;
- substantially more routine actions and conditions.
Most importantly, basic Open and Close remain exactly as simple as in the official driver: standard Zigbee OnOff commands are sent immediately. The private configuration runs independently and cannot block normal valve control.
That separation is not accidental. We already learned the hard way that undocumented private attributes must never sit in the critical Open/Close path.
To be completely transparent, the corrected 0x501D implementation in the current version still needs its final timed hardware confirmation. But unlike the official proposal, it at least implements the mechanism required to solve the problem rather than knowingly certifying the ten-minute limitation as-is.
The official driver will certainly be useful for users whose irrigation sessions conveniently last no longer than ten minutes and who need nothing beyond Open, Close and Battery.
Everyone else will discover fairly quickly that successful pairing is not the same thing as proper device support.
And once users begin asking why their newly WWST-certified irrigation valve keeps closing after ten minutes, the official driver will eventually have to implement the same private attributes and device-specific behavior that we are already dealing with now.
Thank you so much for getting back to me. I updated the firmware via bluetooth. It’s a SWV-ZFE now running 1.1.0. I reinstalled the driver (and the device) and I can see that there is now a setting in your driver allowing the change to the inbuilt default - thank you. Much appreciated!
It was there pretty much from the beginning… I have changed the description in the latest version, though.
Can you please change that setting to maybe 20 minutes and let the water run?
New version: 2026-08-03T18:19
- changes only total_duration_min at bytes 2-3 of 0x501D;
- preserves bytes 1 and 4-12 from the fresh device read;
- verifies duration mode and the first duration field only;
- leaves the serializer, read-modify-write sequence, delayed readback, timeout, retries, and command isolation unchanged.
Code on GitHub and yes, it is a little bit more complicated (generated docs) than the PR for the official driver.
After a short absence, I see another wall of text 
What’s the current status? Is it finally possible to change the default manual watering limit?
Yesterday I upgraded the firmware from 1.0.8 to 1.1.0 and re-added the device to ST, but not much has changed. The valve closed after 10 minutes.
Read this first:
Current version: see my previous comment.
Still waiting for someone to provide logs. Instructions in this comment:
Hi @Andreas_Roedl , I’m out of town again but I’llrun logs later this week.
New version: 2026-08-04T18:48
Thanks for the logs, @Pajacyk0v !
I have uploaded a new test version: 2026-08-09T11:45
There has been some useful new hardware evidence since the previous build.
On a real SWV-ZFE with firmware 1.0.7, Zigbee2MQTT users have now confirmed end-to-end that the valve’s native manual timer works like this:
write manual_default_settings / 0x501D
→ verify the value
→ send one ordinary Zigbee On command
→ valve closes by itself after the configured duration
A separate ZHA hardware test had already demonstrated the same principle with a 15-minute run on an SWV-ZFU.
That makes the device-side timer the most promising solution to the ~10-minute limit. However, I did not want to replace functionality that is already known to work with a more complicated experimental path.
This version therefore uses a hybrid approach:
- 1–10 minutes: unchanged driver-timer behavior. No
0x501Dwrite is required. - More than 10 minutes: the driver uses the valve’s native timer. It reads
0x501D, builds the selected payload, writes it if necessary, verifies the result, arms a driver-side safety timer and only then sends a normal ZigbeeOn.
Normal Open and Close remain ordinary Zigbee On/Off commands.
The driver-side safety timer for native timed watering is deliberately later than the requested duration. For a 15-minute run, the valve is expected to close itself around 15 minutes; SmartThings will only send a backup Off after 16 minutes if the valve is still open.
Device-side limit payload strategy
The three experimental 0x501D strategies are still available:
- Full composite (recommended) - writes both duration fields and the related composite values. This now has the strongest direct support from the SWV-ZFE Zigbee2MQTT hardware tests.
- Preserve device fields - changes only the primary duration field and leaves everything else as read from the valve. This remains the default because it modifies the least.
- ZHA-style total-duration payload - forces duration mode and changes the primary total-duration field while preserving the remaining fields.
The strategy affects only the private 0x501D configuration used for the device-side timer.
How to test this version
Please first verify that the things which already worked still behave normally:
- Test ordinary Open.
- Test ordinary Close.
- Test Open valve for 2 minutes.
The two-minute test should use the existing driver-side timer and should not perform an 0x501D synchronization.
After that, please test the actual >10-minute fix:
- Select Full composite (recommended) as the Device-side limit payload strategy.
- Briefly press the valve’s physical button so it is awake and communicating.
- Use Open valve for 15 minutes.
- Do not set Device-side watering limit to 15 minutes first. This version will synchronize the requested duration automatically.
- Watch the driver logs.
The expected sequence is roughly:
fresh 0x501D read
→ build/write 15-minute payload
→ verify 0x501D
→ arm 960-second safety backup
→ plain Zigbee On
→ 0x501F scheduled=900s
The important 0x501F result is:
requested=15min scheduled=900s
scheduled=900smeans the valve reports/plans a 15-minute native irrigation session.scheduled=600smeans it is still planning the old ten-minute session.
If it reports 900 seconds, please let the complete run finish and confirm whether the valve physically closes by itself after approximately 15 minutes.
The driver-side backup should only become relevant if the valve is still open after 16 minutes.
If Full composite still produces 600 seconds or the synchronization fails, the same 15-minute test can then be repeated with:
- Preserve device fields
- ZHA-style total-duration payload
Please test one strategy at a time.
Thanks!
The three different strategies explained
0x501D payload layout
The 12-byte aggregate is interpreted as:
wire offset 0 mode
wire offsets 1–2 total irrigation duration
wire offsets 3–4 irrigation duration
wire offsets 5–6 interval field
wire offset 7 irrigation amount unit
wire offsets 8–9 irrigation amount
wire offsets 10–11 fail-safe
The 16-bit values are stored big-endian.
For example, 15 minutes is:
00 0F
Preserve device fields
This strategy starts with the complete fresh 12-byte value read from the valve.
It requires the valve to already be in duration mode and changes only:
wire offsets 1–2 = requested duration
Everything else is preserved.
Example:
Source:
00 00 0A 00 0A 00 0A 01 00 00 00 1E
Target 15:
00 00 0F 00 0A 00 0A 01 00 00 00 1E
^^
This is the most conservative strategy because it changes only one field.
ZHA-style total-duration payload
This strategy also starts with the complete value read from the valve.
It changes:
wire offset 0 = 0 duration mode
wire offsets 1–2 = target total duration
Everything from wire offset 3 onward is preserved.
Example:
Source:
02 00 0A 00 0A 00 0A 01 00 00 00 1E
Target 15:
00 00 0F 00 0A 00 0A 01 00 00 00 1E
^^ ^^
If the source is already in duration mode, this can produce the same payload as Preserve device fields.
Full composite
This is currently the recommended strategy for the SWV-ZFE test because the current Zigbee2MQTT implementation writes the complete duration-related composite and that approach has now been demonstrated on real SWV-ZFE hardware.
It sets:
wire offset 0 = 0
wire offsets 1–2 = target
wire offsets 3–4 = target
wire offsets 5–6 = 10
wire offsets 7–9 = preserved amount unit and amount
wire offsets 10–11 = preserved or adjusted fail-safe
The fail-safe is not simply set equal to the requested duration.
If the existing fail-safe is disabled (0) or already longer than the requested duration, it is preserved. If it would end the experiment too early, the driver raises it above the requested duration.
For a 15-minute test with an existing five-minute fail-safe:
Source:
00 00 0A 00 06 00 1E 01 00 00 00 05
Result:
00 00 0F 00 0F 00 0A 01 00 00 00 10
^^ ^^ ^^ ^^
00 10 is 16 minutes, so the fail-safe cannot mask a successful 15-minute native timer.
The amount unit and irrigation amount remain exactly as read from the valve.
New version: 2026-08-09T20:54
Thanks again for the logs, @Pajacyk0v !
Incredible happy with thsi driver, all works
Tip: make sure the Device-side watering limit higher then Hydro timed watering Open valve for minutes, otherwise will cause a conflict and cause the Hydro to default to 10 minutes.
Also, automation works great, just set a start routine, don’t need to setup a stop one.
Here is my setup and routines.
For info the symptoms discussed re BT/Zigbee mode switching on this thread:
I also observed with the Hydro and eWeLink, the rescan fix you suggested for the Air:
Worked in this case…
I have challenges getting the device to stay on for longer than 10 minutes. My use case of controlling dishwasher and washing machine water will require the device to stay on for 240 minutes or more. I have tried the following without results
- Changing device side watering limit
- Payload strategy (tested them all) and then set open valve for minutes (see screenshots). I will get a loading icon spinning and then an network error message.
What works
- On /off from app
- Open valve for minutes less than 10 minutes
How could I get this decice to work as intended?
As you can see in this thread, I’ve already tried pretty much everything I can think of in my own driver to deal with the 10-minute cutoff, so for the moment I’m waiting to see how SONOFF themselves solve it in their official SmartThings driver.
The whole story is actually quite interesting. At the end of July, SONOFF submitted their own driver code to SmartThings for official certification. At first, the discussion was mostly about normal code-review things like naming, comments and whether some of the custom handling was really necessary.
Then, on August 3, I asked the SONOFF developer whether they had actually tested what happens when the valve is left open for more than 10 minutes. I pointed out that several Hydro ONE users had already seen the valve shut itself off automatically because of a SONOFF-specific setting in the device.
He tested it with firmware 1.1.0 and confirmed exactly that: even if SmartThings simply sends the normal Zigbee command to open the valve, the device closes itself again after about 10 minutes.
What surprised me was that his initial reaction was basically that this was expected device behavior and that they wanted to get the official SmartThings certification done first and add support for the SONOFF-specific settings later.
A SmartThings developer then stepped in and said, in effect, that this probably shouldn’t remain unfixed in the official driver. Another SmartThings developer also explained that they don’t need any exotic SmartThings feature for this - they can expose the relevant setting as a normal device preference and let the driver write the corresponding SONOFF-specific Zigbee attribute.
So now everyone who has been following this is rather curious to see how SONOFF will actually implement it in their own driver.
And that’s basically where things are stuck at the moment. The SONOFF developer seemed to be arguing that these private settings should be left out of the first certified version, while SmartThings told him that there is a perfectly valid way to include them. Since then, there hasn’t really been a response.
So I’m waiting as well. If SONOFF comes up with a clean solution in the official driver, that will be very useful for figuring out how this should be handled properly.
I wonder if SONOFF will do something similar for their SWV-BSP/SWV-NH series. I have 2 of the NH ones, and they have a 30 minute time auto shutoff, but none of the other attributes from the Hydra One series.
Hi everyone,
First of all thank you for the great work. I’m less than a beginner with everything related to SmartThings and zigbee devices but i’m playing around with it since i bought a sonoff Hydro duo. I may have stumble on another issue.
I installed this edge driver and everything seemed fine, at first working as intended. But it kept going offline and the only way to reconnect it was to make the pairing again, but the new pairing lasted only for a few hours. So i started looking for a connection problem. I got a sonoff zigbee plug to use as a node, upgraded the internal driver through eWelink to the latest available and tried over several days any other option. No solution.
Then i uninstalled the dedicated edge driver and tried the pairing with the vanilla SmartThings app. Now it is already 2 days and it never went offline. It is working fine, but only of course as a basic “Zigbee switch 1 and 2”
Does someone have the same problem? Do you know if it can be actually related to the driver?
Thank you and sorry if i’m going too much off topic.
My theory is that there’s a bug in the firmware and this setting can’t be changed via Zigbee.
There’s currently one single report that someone was able to change the limit beyond 10 minutes. Forgot if it was ZHA or Zigbee2MQTT, but Home Assistant. The other users are using a workaround: turn on if off.
As I said in this thread: normally it should be a simple write to an attribute of a manufacturer specific cluster, and not some voodoo magic handcrafted Zigbee packets.