[RELEASE] Tuya Zigbee Valve driver (w/ healthStatus)

Hi @kkossev! Thanks for the controller than can handle my new "GIEX ZIGBEE 2-Zone Sprinkler Timer GX-03"! The open/close works on the 2nds valve and the "Set Valve2" doesn't do anything - or I don't know how to work it... (the 2nd being the right hand valve)...

I'm using rule machine for my "2nd" valve...which command can handle the 1st valve?

Thanks!

ps: I bought and returned the HAOZEE cos it wouldn't reliably work using the GIEX device controller. Now I have the GX-03 which I assume is the one that works.

Thanks again!

Jann

ps: here's my settings:


I've reconnected my Sonoff valve to my Hubitat, and am trying to understand two things:

  1. In the device list, I have "Valve Status" selected for the status column, yet it returns "shortage". What in the world does that mean??? I'd like it to show if it is open or closed...

  2. In the "Current States" there is a field for "Rate" yet no matter what, mine shows 0. Does the Sonoff not measure the flow rate?

You should select the 'valve' attribute to see the open or closed status in the device list.

'valveStatus' is a diagnostic attribute sent by the device, and 'shortage' means that for some reason the device does not detect the water flowing... :thinking:

My Sonoff valve is connected on a splitter on an outside tap, one side feeding a hose and the other side feeding my irrigation through the valve. I use the "shortage" state to trigger an alert to let me know that the tap has been inadvertently turned off. I only discovered this "shortage" state after noticing my garden bed was not doing too well and investigating on Hubitat. It transpired that someone (me) had turned off the tap days earlier and my soil sensor battery was flat. Good job I have all this smart stuff to offset my incompetence.

Thank you! I will revise it.

ok, good to know. It's been sitting with the batteries removed for a few months when the weather was cold. I stuck the batteries back in and it reconnected; maybe I need to delete and re-pair it.

Hey @kkossev, Any chance of getting dual valve Giex's working (GX-03)? I use this with my GX-03 and it controls only the 2nd valve (I think - #2). It's the right one. But I don't know how to control the left one. The rule machine only shows one device (image below) but I need the other one to operate as well.

Any ideas? The GX-03 says it requires tuya hub so I thought this would work...

Thanks!

Jann

OOPS: I see this link from @leepearson1977

So I will try that! Stay tuned!

I have a SONOFF SWV Zigbee 3.0 Smart Water Valve using this driver.

I had noticed that quite often the 'valve' and 'switch' states would be incorrect for some time. I have an audible alert when this valve opens, so it was very easy to notice.

The valve is closed now, and if I hit "Refresh" on the device page, it changes to the correct state: valve = closed, but about 1 seconds later it changes again to 'open'. The after ~1½ minute it goes back to the correct state: 'closed'.
It was physically closed all this time.

It also occurs 'randomly', without hitting refresh, it turns to 'open' without any command when in fact it is closed.

I was a bit lazy and asked an AI to analyze the problem :slight_smile:

The bug is in cases 500D and 500E on the switch inside parseSonoffCluster().

The forced sendEvent() calls should not be there. The timestamps should only update the timestamp attributes.

        case '500D' :   // Irrigation Start Time // uint32  // Local time (since 1970)
            logDebug "Sonoff cluster 0x${it.cluster} attribute ${it.attrId} Irrigation Start Time : value is ${intValue} (raw: ${it.value})"
            Date startDate = new Date((intValue + 946684800L)  * 1000L)
            String startDateString = dateFormat.format(startDate)
            descText = "Irrigation Start Time is ${startDateString}" ; if (settings?.logEnable) { descText += " (raw: ${it.value})" }
            logInfo "${descText}"
            sendEvent(name: 'irrigationStartTime', value: startDateString, descriptionText:descText, type: 'physical')
            break
        case '500E' :   // Irrigation End Time //  uint32  // Local time (since 1970)
            Date endDate = new Date((intValue + 946684800L)  * 1000L)
            String endDateString = dateFormat.format(endDate)
            descText = "Irrigation End Time is ${endDateString}"  ; if (settings?.logEnable) { descText += " (raw: ${it.value})" }
            logInfo "${descText}"
            sendEvent(name: 'irrigationEndTime', value: endDateString, descriptionText:descText, type: 'physical')
            break

After updating these code blocks, when I hit refresh there are no events, which is expected, because it didn't change any state.

Thanks! I just set up my Sonoff valve with this driver and ran into the same bug. Not quite sure what the intent of those lines are (maybe they're an intentional backstop, but they don't even check if those times are in the past), but I think part of the issue is a bit of a race condition. On a Refresh, both cases are triggered: the irrigationStartTime case sets the valve to open (because it was closed), but the irrigationEndTime doesn't set it back to closed (because it happens too quickly for the open to have registered). Removing/commenting out those lines works for me.

Another small bug that may or may not be specific to my device: the firmware on my valve (I just updated from 1.0.3 to 1.0.4) reports as 00001004 instead of 1.0.4. So I had to change the sonoffMinVersion check from 1.0.3 to 00001003 to get the driver to show the auto shut off config.

Otherwise the driver is working great! Thanks @kkossev!

@eduardo and @kdb - thank you for the reports! I think that I have found the possible root of the problems - refreshing the 0x0006 on/off cluster when the device is performing a timedOn will prevent the valve from automatically switching off! When I skipped reading the 0x0006 cluster attribute 0x0000 in the refresh() method, the valve now auto-closes as programmed. Sounds like a Sonoff firmware bug ...

I have published a new version of this driver on GitHub; there are many changes related to Sonoff's new valve series (these new models have completely different firmware!). So it may be a good idea to back up your working copy of this driver, before trying the new version...


ver. 1.7.0 2026-04-25

  • Sonoff SWV bug fixes:
    • version check fixed;
    • valve status 'shortage and leakage' now reported correctly;
    • water flow unit corrected to m³/h;
    • daily irrigation volume now shown as waterConsumed attribute;
    • auto shut-off (firmware 1.0.4+) now configures and reads reliably;
    • valve work state no longer causes errors on unexpected values;
  • irrigation start/end timestamps (0x500D/0x500E) epoch offset now firmware-conditional (fw<1.0.4 uses Zigbee year-2000 epoch, fw>=1.0.4 uses Unix epoch);
  • fixed spurious valve/switch open flips on Refresh: 500D/500E state inference now skipped when isRefresh=true (only applied for autonomous unsolicited reports)

ver. 1.7.1 2026-04-26 :

  • added Sonoff SWV-ZN series (SWV-ZNE, SWV-ZFE, SWV-ZNU, SWV-ZFU);
  • fixed setDeviceNameAndProfile() fingerprint fallback matching for multi-model profiles;
  • fixed SWV flow rate reported 10x too high (ZCL 0x0404 units are 0.1 m³/h, now divided by 10);
  • fixed SWV workState (0x5010) labels: old SWV firmware uses boolean 0=idle/1=working, not ZN-series multi-state values.
  • fixed Sonoff SWV on_with_timed_off auto-close timer cancelled by refresh(): skip genOnOff read (cluster 6) when valve is open.

Thanks for the quick fix! Yeah that firmware bug you found makes more sense than my guess about the race condition. Either way, skipping the state inference on refreshes seems like the more correct way to address it anyway (rather than flipping the valve state to open then immediately closed if the firmware bug were fixed). Tested out your latest github version and everything looks good so far. I'll report back if I notice any other issues in the next few days.

This isn't a real big deal to me but is there anyway to reset the waterConsumed attribute?
It would be nice to reset this field for each season noting how much was laid down.

Hi @kkossev
With the latest ver. 1.7.1 and Snoff SWV-ZNU
I have this unknown attribute in my log.
SonOff Valve1 Sonoff cluster 0xFC11 unknown attribute 501E value is 0 (raw: 200C000A0A0A0A0A0A0A0A0A0A0A0A)

The valve is working fine but not sure about this log. Thanks!

dev:3292026-05-21 18:42:17.783debugSonOff Valve1 Sonoff cluster 0xFC11 unknown attribute 501E value is 0 (raw: 200C000A0A0A0A0A0A0A0A0A0A0A0A)
dev:3292026-05-21 18:42:17.782debugSonOff Valve1 parseSonoffCluster: it.value 200C000A0A0A0A0A0A0A0A0A0A0A0A is not a number
dev:3292026-05-21 18:42:17.780debugSonOff Valve1 parseSonoffCluster: [cluster:FC11, attrId:501E, value:200C000A0A0A0A0A0A0A0A0A0A0A0A, status:null]
dev:3292026-05-21 18:42:17.779debugSonOff Valve1 Desc Map: [raw:677B01FC11241E5048200C000A0A0A0A0A0A0A0A0A0A0A0A, dni:677B, endpoint:01, cluster:FC11, size:24, attrId:501E, encoding:48, command:0A, value:200C000A0A0A0A0A0A0A0A0A0A0A0A, clusterInt:64529, attrInt:20510]
dev:3292026-05-21 18:42:17.777debugSonOff Valve1 parse: description is read attr - raw: 677B01FC11241E5048200C000A0A0A0A0A0A0A0A0A0A0A0A, dni: 677B, endpoint: 01, cluster: FC11, size: 24, attrId: 501E, encoding: 48, command: 0A, value: 200C000A0A0A0A0A0A0A0A0A0A0A0A


Application 10
Endpoint Id 01
Firmware MT 1286-200C-00001007
In Clusters 0000,0001,0003,0006,0020,FC57,FC11
Manufacturer SONOFF
Model SWV-ZNU
Out Clusters 0003,0019
Software Build 00001007

Edit: ignore what I said above. Reloaded the driver and pressed initialize seem to fix the log. Thanks!

I just installed this driver to use with a couple of Sonoff Sprinklers and I noticed the irrigation start and end times are off by - 4 hours. My hub time and time zone are both correct and the timestamps in the logs for this device are also correct. It’s just the irrigation timestamps in the variables that are incorrect.

Using this driver with Geix GX02 valves, I noticed the same; from observation, the internal clock starts at 00:00:00 when the batteries are inserted, with no way seen to set/reset it.

I wound up writing a wrapper rule that saves off the actual start and end times.

Yeah, I essentially did the same thing using variables. I created a start and stop variable set in webCoRE based on the on / off state changes instead of using the device’s start and stop times.

Good to know WC is fine.

I have 2 on the way for the front and back watering.

Is there a chance you can add support for the new Sonoff SWV-ZF2E/U?

Just installed one of my new vales and it works great.

I did, however, have to create a virtual valve to reverse the tile indication.

I have a Dome valve that’s always open so the tile indicates Green (open), and Red (closed, water leak somewhere) on my Dashboard. I always want that valve Open for the house water as a normal condition.

If I use the Dashboard valve template for the Tuya it indicates very Red and unhappy as it’s normal operating state is Closed, not watering the garden.

It would be a nice mod to add a Prefs switch to reverse the state to handle the normal operational use case.

:slight_smile:

Sorry, this driver is not suitable for controlling double valves.. A simple on/off for the second valve could be possible, but not the full functionality (no auto shut-off, etc..)

I should have checked here first! I have a SONOFF SWV-ZF2E arriving later today, having just “assumed” that it would work okay with HE.

Does this mean that one valve can be used with this driver and it works as planned, and the other valve will do nothing at present? Or could I control the second one with simple on/off? That would be a start, at least.