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

Devices & Integrations Community Created Drivers
101

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.

102

@Seoultraveller

  • 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.

103

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 On and Off;
  • 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:

  1. The valve still switched itself off after ten minutes.
  2. The tested device was already running firmware 1.1.0.
  3. The current SmartThings driver will not affect the automatic ten-minute shutdown.
  4. 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.

104

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!

105

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?

106

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.

107

After a short absence, I see another wall of text :distorted_face: 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.

108

Read this first:

Current version: see my previous comment.

Still waiting for someone to provide logs. Instructions in this comment:

109

Hi @Andreas_Roedl , I’m out of town again but I’llrun logs later this week.

110

Works With SmartThings*

Screenshot_20260804_113900_Samsung Browser
Screenshot_20260804_113900_Samsung Browser1200×1649 333 KB

* barely

111

New version: 2026-08-04T18:48

Thanks for the logs, @Pajacyk0v !

112

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 0x501D write 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 Zigbee On.

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:

  1. Test ordinary Open.
  2. Test ordinary Close.
  3. 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:

  1. Select Full composite (recommended) as the Device-side limit payload strategy.
  2. Briefly press the valve’s physical button so it is awake and communicating.
  3. Use Open valve for 15 minutes.
  4. Do not set Device-side watering limit to 15 minutes first. This version will synchronize the requested duration automatically.
  5. 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=900s means the valve reports/plans a 15-minute native irrigation session.
  • scheduled=600s means 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:

  1. Preserve device fields
  2. 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.

113

New version: 2026-08-09T20:54

Thanks again for the logs, @Pajacyk0v !