He is out on a super secret personal project, he said he might be back around September, IIRC
4 Likes
I have one and it's working great on C8 hub for several months now, but it might be a different Tuya version. Seems to utilize the auto-reconnect feature quite a bit
https://www.amazon.com/dp/B0DHTRQ2GV?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_3
| Application | 4A |
|---|---|
| Endpoint Id | 01 |
| Manufacturer | _TZE204_a7sghmms |
| Model | TS0601 |
| Tuya Version | 1.0.10 |
State Variables
| Comment | Works with Tuya TS0001 TS0011 TS011F TS0601 shutoff valves; Tuya TS0049, GiEX, Saswell, Lidl, FrankEver irrigation timers |
|---|---|
| Device Profile | TS0601_GIEX_VALVE |
| Driver Version | 1.4.0 2024/11/19 7:25 PM |
| Last Rx | {"parseTime":1746025289216} |
| Last Tx | {"pingTime":1732216162969} |
| States | {"debounce":false,"isRefresh":false,"isDigital":false,"notPresentCtr":1,"lastBattery":"100","lastSwitch":"closed"} |
| Stats | {"RxCtr":1804,"TxCtr":142,"rejoinCtr":39} |
Just wanted to jump in and thank you. I recently acquired one of these dual valves, which identifies as:
Manufacturer. _TZE284_fhvpaltk
Model. TS0601
No luck with the Sinope driver and initially couldn't get it to respond to your driver either. Eventually I turned on "Advanced Options" and by trial and error ended up choosing "TS0601_TZE284_VALVE"
Working like a charm now!
I created two virtual switches and some RM stuff to turn each valve on/off (I only needed basic functionality).
So thanks again for your work.
3 Likes
I purchased and added to hub almost a year ago, but finally got around to installing my drip irrigation system and getting set up and testing. I noticed there's some major discrepancies with the times displayed:
At 08:35am local time I started a 300 second (5 minute) run.
The driver is stating irrigationEndTime of 16:35 (+8 hours)
At 08:40am local time it stopped the 5 minute run.
In the current states:
Ignoring the timezone differences, it's reporting __:30 as start and __:35 as the end when in reality it was __:35 as start and __:40 as end.
I'm not going to lose sleep over this because setting the number of seconds and turning it on appears to work properly (it turns itself off after the appropriate time elapsed) but just pointing this out because it's confusing when troubleshooting/checking.
Is the timer turning itself off after the configured time or is the hub sending the off/close signal? (I think/hope it's the former.)
Thanks for that note!
I just acquired one of these (very similar) dual Zigbee valves: Amazon.com: Haozee Zigbee Sprinkler Timer 2 Zone,Smart Water Timer for Garden Hose, Requires Zigbee 3.0 Hub,Support Home Assistant Zigbee2mqtt, Rain Delay and Manual Watering, Leakproof for Yard Lawn Watering : Patio, Lawn & Garden
It's fingerprint selected this driver (I already had it installed), but I needed to manually set the device profile to TS0601_TZE284_VALVE (via the Advanced Options) to get the "Set Valve2" to operate. Thanks for your note!
fingerprint profileId:"0104", endpointId:"01", inClusters:"0000,0004,0005,EF00,0000,ED00", outClusters:"0019,000A", model:"TS0601", manufacturer:"_TZE284_fhvpaltk", controllerType: "ZGB"
ZCL version:03
Software Build Id:unknown
Model:TS0601
Manufacturer:_TZE284_fhvpaltk
I have a SONOFF Zigbee Smart Water Valve and am using this driver. I had the February version, but just updated to the most recent version, and it hasn't helped.
The problem is if I press the button on the device to turn the valve on, i don't get an "open" event to Hubitat, and so my rule to turn it auto-off doesn't run.
If I open the valve using the "open" command on the device page, then I do get the "valve->open" and "switch->on" events and the auto-off works.
If I open by pressing the physical button on the valve, I do get "IrrigationVolume", "IrrigationStartTime", "LastValveOpenDuration" events, but no "valve->open" and "switch->on" events.
Is there a way to fix it so I get those events, or is it possible to trigger my rule on the events I do get ?
(And setting a value in the "Set Irrigation Timer" section doesn't seem to work either, as an aut-off. I think it worked a couple of times once, but then doesn't seem to work any more.)
2 Likes
Bookmarked, I will come back to the Sonoff valve driver after finishing the Tuya mmWave driver refactoring project.
2 Likes
I installed 3 of these Sonoff valves for irrigation and I am happy with the driver. Works fine so far.
So then I decided to install one more to the entrance of the house (in front of the main valve)
But Sonoff doesn't seem to be a suitable device for this as it is designed solely for irrigation.
Any ideas on this ?
If not, then what can I put for the main valve ? There are cheap bolt-on solutions as @kkossev has tested "working" (Moes in the first post)
But I also need flow measurement.
What can I use that is also compatible with Hubitat or this driver ?
+btw, what is the "lqi" reported by this device ? what does lqi=64 mean ?
+one of my valves' "irrigationvolume" report is being reset to zero at each "on" command. the others save the value and add over it. What is the difference ?
LQI is a relative measurement of zigbee link quality. Google "zigbee LQI" for more info.
If things are working fine overall, I'd caution against getting too wrapped up about any LQI numbers though. Chasing improvements based on that value risks a descent down a deep (and almost certainly not worthwhile) rabbit-hole.
I've never had a need to look at any of my LQIs, so I never have.
2 Likes
Hi @kkossev
I had to do some work in my utility room today that is fitted a Tuya TS011F VALVE.
I manually closed the valve. When I looked at the valve on my dashboard I saw that it still showed as being open. Looking at the device page in HE it also showed as open.
It appears that manually/physically opening/closing the valve using the button on the body of the valve does not update the state of the device.
I've tried a re-pair of the device followed by a configure/refresh etc. and it still doesn't update it's status if manually changed.
I have 2 of these and both do the same.
I'm not sure if I've missed something but do you know if this is the problem with these devices or maybe I need to configure something.
Here is the log (if it's of any use) when I press the configure button on the device page.
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:27.365 warn Kitch-Stopcock Read attribute response: unknown status code 8F Attributte 0000 cluster 0006
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:27.357 debug
Kitch-Stopcock Desc Map: [raw:catchall: 0104 0006 01 01 0040 00 74A0 00 00 0000 01 01 00008F, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:74A0, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, data:[00, 00, 8F]]
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:27.350 debug Kitch-Stopcock parse: description is catchall: 0104 0006 01 01 0040 00 74A0 00 00 0000 01 01 00008F
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:27.277 debug Kitch-Stopcock **sendZigbeeCommands** (cmd=[he rattr 0x74A0 0x01 6 0 {}, delay 2000])
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:27.209 debug Kitch-Stopcock refresh()...
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.686 info Kitch-Stopcock power on behavior is **last state** (02)
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.677 debug
Kitch-Stopcock TuyaE00xCluster Desc Map: [raw:74A001E0010810D02002, dni:74A0, endpoint:01, cluster:E001, size:08, attrId:D010, encoding:20, command:0A, value:02, clusterInt:57345, attrInt:53264]
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.667 debug
Kitch-Stopcock parse: description is read attr - raw: 74A001E0010810D02002, dni: 74A0, endpoint: 01, cluster: E001, size: 08, attrId: D010, encoding: 20, command: 0A, value: 02
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.657 debug Kitch-Stopcock parseZHAcommand writeAttributeResponse cluster: E001 status:86
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.648 debug
Kitch-Stopcock Desc Map: [raw:catchall: 0104 E001 01 01 0040 00 74A0 00 00 0000 04 01 8610D0, profileId:0104, clusterId:E001, clusterInt:57345, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:74A0, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:04, direction:01, data:[86, 10, D0]]
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.635 debug
Kitch-Stopcock parse: description is catchall: 0104 E001 01 01 0040 00 74A0 00 00 0000 04 01 8610D0
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.505 debug
Kitch-Stopcock parseZHAcommand writeAttributeResponse cluster: 0000 status:86
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.490 debug
Kitch-Stopcock Desc Map: [raw:catchall: 0104 0000 01 01 0040 00 74A0 00 00 0000 04 01 86DEFF, profileId:0104, clusterId:0000, clusterInt:0, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:74A0, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:04, direction:01, data:[86, DE, FF]]
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.472 debug
Kitch-Stopcock parse: description is catchall: 0104 0000 01 01 0040 00 74A0 00 00 0000 04 01 86DEFF
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.311 debug
Kitch-Stopcock exception java.lang.NumberFormatException: For input string: "Z3" caught while parsing event: read attr - raw: 74A001000064040042105F545A333030305F74767561726B73610000002003010000204305000042065453303131460700003001FEFF86, dni: 74A0, endpoint: 01, cluster: 0000, size: 64, attrId: 0004, encoding: 42, command: 01, value: 105F545A333030305F74767561726B73610000002003010000204305000042065453303131460700003001FEFF86
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.296 debug
Kitch-Stopcock parse: description is read attr - raw: 74A001000064040042105F545A333030305F74767561726B73610000002003010000204305000042065453303131460700003001FEFF86, dni: 74A0, endpoint: 01, cluster: 0000, size: 64, attrId: 0004, encoding: 42, command: 01, value: 105F545A333030305F74767561726B73610000002003010000204305000042065453303131460700003001FEFF86
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.213 debug Kitch-Stopcock **sendZigbeeCommands** (cmd=[he raw 0x74A0 1 0x01 0x0000 {10 00 00 04 00 00 00 01 00 05 00 07 00 FE FF}, delay 150, he wattr 0x74A0 0x01 0x0000 0xFFDE 0x20 {0D} {}, delay 50, he wattr 0x74A0 0x01 0xE001 0xD010 0x30 {02} {}, delay 251])
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.178 debug Kitch-Stopcock setting powerOnBehaviour to last state (2)
[dev:700](http://192.168.0.23/logs#)2025-09-19 17:10:24.171 info Kitch-Stopcock configure()..
Hi @kkossev
Just bumping my post above in case you missed it.
Any thoughts if this is just how it is or is something going wrong.
I'm wondering if this is anything to do with it.
Hi Bob,
I am way from home now and when back I must finish first the Tuya mmWave driver refactoring, then I will have the chance to look at the other items in the backlog .
Two things that I need to know - the Zigbee model/manufacturer data for your device (TS011F is just a generic Tuya modlel). Also, with debug logging enabled - do you see anything in the live logs when you operate the valve manually?
1 Like
Nothing in the logs when the valve is manually opened/closed by pushing the button on the device.
I changed the driver to device and cleared all the states etc.
On re-pair the device shows this.
I have 3 of these. 2 of them shows " * irrigationDuration : disabled" but the other one doesn't have this property in device page.
This one always resets the irrigationVolume attribute when switched to on
how can I change this behaviour ?
I don’t have my Sonoff valve connected to water pipe, so I don’t know what should be the correct behavior… Hopefully someone else who really uses it can share his experience.
Look for differences between your three devices - do they have one and the same firmware (application) version?
When paired for a first time, was this driver selected automatically, or did you assign it later? This makes a difference in the initial configuration/initialization of the device.
@kkossev
there is no difference between the devices. This seems to be a driver behaviour issue.
My question is:
when the driver shows " irrigationDuration : disabled" ?
I recall playing with the irrigationtimer and other features of the driver when I installed the first valve (which is also the one with difference), I didn't set anything on the other 2 valves.
"there is no difference between the devices" is a pretty vague answer... Are all 3 valves on the same firmware? (yes or no)
You haven't answered this question yet -- and this is a particularly relevant question since your last post there confirms that the valve with the difference is the very first one you installed.
1 Like
answer is "yes"
and "first installed" does not mean it is from a different batch.
I received them all at once. I just installed them one by one.
Btw, as I wrote, this is a behaviour of the driver. It is not coming from the device itself.
Driver resets the data when I click the "on" button.
Anyway, I removed the device and reinstalled. The problem is gone.
Probably, an "initialize" command would do the same, because probably when I set the "irrigation duration" it changed something.
What's weird is that we all don't know the behaviour of the driver.
Hi @ilkeraktuna ,
The 'irrigationDuration' is a parameter for some of the valves supported in this driver, and it is shown as a driver attribute at the same time. It shohould have a numeric value (in seconds or in minutes, depending on the device). The 'irrigationDuration' event is normally sent when the driver receives this numeric value from the device - FrankEver and Sonoff valves sent it, other valves do not. The irrigationDuration event is of a type 'physical in this case.
Looking at the code, I see that irrigationDuration : disabled text is sent also in the configure() method, if the autoOff timer preference is zero, i.e. disabled. I don't remember now why this was done - it may be a bug, maybe not.
I don't know (do not remember) all the details for all the different types/models of valves either... 
The driver became rather complex, so when the time permits, I will refactor the code to make it easier to understand and to maintain.
But as I wrote here, currently I am working on the refactoring of the mmWave driver - this is a really important and blocker priority task, as it was impossible to add any new mmWave sensors in the last months. When I am done with this project, will come back to the valve driver, it is on top of my backlog.
1 Like
no problem. my issue is solved somehow.
