Although the different Tuya branded Zigbee valves may look the same, they are produced by different manufacturers and have different Zigbee commands implemented.
Most of the Tuya valves should work in HE stright away, using the inbuilt Sinope Water Valve driver.
In the cases when Sinope Water Valve driver does not work for your model, you can try this driver that is intended to provide support for several different Tuya modles.
ver. 1.2.0 2023-02-28 - added deviceProfiles; stats; Advanced Option to manually select device profile; dynamically generated fingerptints; added autOffTimer; added irrigationStartTime, irrigationEndTime, lastIrrigationDuration, waterConsumed; removed the doubled open/close commands for _TZE200_sh1btabb; renamed timer_time_left to timerTimeLeft, renamed last_valve_open_duration to lastValveOpenDuration; autoOffTimer value is sent as an attribute; added new _TZE200_a7sghmms GiEX manufacturer; sending the timeout 5 seconds both after the start and after the stop commands are received (both SASWELL and GiEX) ; added setIrrigationCapacity, setIrrigationMode; irrigationCapacity; irrigationDuration; added extraTuyaMagic for Lidl TS0601 _TZE200_htnnfasr 'Parkside smart watering timer'
ver. 1.2.1 2023-03-12 - bugfix: debug/info logs were enabled after each version update; autoSendTimer is made optional (default:enabled for GiEX, disabled for SASWELL); added tuyaVersion; added _TZ3000_5ucujjts + fingerprint bug fix;
ver. 1.2.2 2023-03-12 - _TZ3000_5ucujjts fingerprint model bug fix; parse exception logs everity changed from warning to debug; refresh() is called w/ 3 seconds delay on configure(); sendIrrigationDuration() exception bug fixed; added rejoinCtr
ver. 1.2.3 2023-03-26 - TS0601_VALVE_ONOFF powerSource changed to 'dc'; added _TZE200_yxcgyjf1; added EF01,EF02,EF03,EF04 logs; added _TZE200_d0ypnbvn; fixed TS0601, GiEX and Lidl switch on/off reporting bug
ver. 1.2.4 2023-04-09 - _TZ3000_5ucujjts deviceProfile bug fix; added rtt measurement in ping(); handle known E00X clusters
ver. 1.2.5 2023-05-22 handle exception when processing application version; Saswell _TZE200_81isopgh fingerptint correction; fixed Lidl/Parkside _TZE200_htnnfasr group; lables changed : timer is in seconds (Saswell) or in minutes (GiEX)
ver. 1.2.6 2023-07-28 - fixed exceptions in configure(), ping() and rtt commands; scheduleDeviceHealthCheck() was not scheduled on initialize() and updated(); UNKNOWN deviceProfile fixed; set deviceProfile preference to match the automatically selected one; fake deviceCommandTimeout fix;
This seems like exactly what I need and looks great, but it isn't working for me. My manufacturer is listed as "_TZE200_sh1btabb", is this the problem?
This Tuya manufacturer is not in the list of the known devices (yet).
Make sure the Debug option is turned on, then power the valve off, wait 10-15 seconds and power it on again.
Switch the valve for on/off from the device button.
Then post the debug logs (you can do this in. a PM )
P.S.
Have you tried the built in Sinope driver?
Also, when this Tuya driver is selected, pair the valve for a second time. Some Tuya and Aqara devices do not pair successfully to the hub from the first try,
I just searched for information about this device, and it is something very different than the simple water/gas shutter valve... It's a much more complex smart irrigation controller. Seems like the water flow can be regulated in 5% steps, not just fully opened/fully closed like the shutter valves.
Such a controller will require a custom driver to handle the specific Tuya commands for it, there is not a known driver for Hubitat yet.
Ok. I have a development background, can you help me get started? It's unclear to me how one determines what the commands are from interrogating the device.
Many of Tuya platform devices do not follow the Zigbee Cluster Library specifications, so the commands for each particular device are usually reverse-engineered by sniffing the traffic when connected to Tuya proprietary Zigbee coordinator. Often this work is already done by other home automation communities :), so it becomes a matter of finding the information on Github. Searching Github for _TZE200_sh1btabb" shows that this device is already supported in ZHA and Zigbee2MQTT, so the information on the commands ('data points' in Tuya terminology) is already there.
It shouldn't be so hard to add support for this device in Hubitat, the only problem is the time .. ;(
If you are sure that you want to dive into writing Zigbee drivers for Hubitat, I will surely help you to get started. The first step is to understand the debug logs that most of the HE drivers provide, so my proposal was to start from here.
I also found those pages in GitHub last night. I think I'm missing some sort of primer on zigbee drivers. I searched around a bit and mostly found official protocol documentation which would be laborious to consume. Can you recommend a good 101 guide?
If I'm understanding correctly, the mqtt work does not contain the zigbee commands themselves, rather the instructions to the Tuya hub to send the zigbee commands. Is that correct?
There is no way to communicate directly to Tuya zigbee hub, These communicate only to Tuya cloud. Tuya cloud provides API for integration to other systems - it is used in HE by this excellent project : [BETA] Tuya Cloud Driver (Limited device support)
This is one possible way to bring Tuya devices to HE, that do not have a Zigbee driver yet (or the devices use WiFi or BT communication to Tuya hub).
An MQTT broker does not directly talk to Tuya devices or Tuya Zigbee hub, In Home Assistant, the Zigbee2MQTT add-on communicates to a lot of Zigbee devices from one side and to HA MQTT broker on the other side.
Ok, that's interesting. I think the outcome is the same though; the information I need to write a zigbee driver is not contained within the mqtt code we both found on GitHub, meaning the only way for me to get it is to buy a Tuya hub, and a zigbee dongle and sniff the traffic. Correct?
Having a Tuya Zigbee hub and sniffing the traffic is very useful, but not absolutely necessary. I have it, but I use it relatively rarely, I call this approach 'the heavy artillery '
Usually, collaborators from Home Assistant or deConz, or other HA communities have already walked this way, so the information needed to add a particular device is already available on GitHub. As of today, searching GitHub for '_TZE200_sh1btabb' finds 3 issues (the request, discussions implementation, and test results of the same device in both ZHA and Zigbee2MQTT) and 1 'code' ( Zigbee2MQTT definitions for this Water irrigation valve). In our case we are lucky as almost all of the information can be found in this single giex.js file. Here we have all the Tuya 'data points' - parameters that are reported from the device (fzLocal) and commands / parameters that can be sent to the device (tzLocal ). We still have to guess what is the meaning of 'mode' vs 'state' vs 'irrigation_target', etc... In this case, I have not spent time reading more about this device, so most of parameters and commands are not very clear to me.
Next step is to start adding the new device commands and parameters to a new or better find an existing HE driver that is most close to the new device functions. This driver can be a good starting point, although this irrigation valve is much more complex that the simple on/off valve. But often not all of the particular Tuya device parameters needs to be implemented in Hubitat. Probably all these 'irrigation start', 'irrigation end', irrigation duration parameters (having a strange data type 'GMT+8' - this is the China central time zone ) are not needed in HE, because the operation of the valve will be controlled by Hubitat.
If you want to continue with writing the driver, let me know.
I absolutely do and this is super helpful, I think my mental model is almost complete enough to begin. One thing that's not clear just yet, wears the relationship between clusters (seemingly simple memory addresses or similar) and the human readable datapoints etc named in the above mentioned file?
More to the point, I'm under the impression that I need to send some specific magic numbers to the device and that those datapoints are convenience names. Seems like maybe that's where my disconnect is.
I would like to know if anyone has seen or worked with these. One of the three reviews says it doesn't work with Hubitat but I think it is pretty new and maybe nobody has it yet to sniff it out. If I were to purchase one, what would someone need to get it to work with a driver? It mentions it is a Tuya chipset and, right now, would require a Tuya hub. I would happily be the test rat if it means getting away from the Orbit setup I have now.
In the development branch ver. 1.0.2 (the link is in the second post) I have added basic On/Off control for the new Tuya Water Irrigation Valve. I do not have this device and am unsure whether it is only one model/manufacturer. If someone has this or a similar device please make some tests. There is no known way to automatically recognize whether the device is a simple valve or a more sophisticated water irrigation valve, so for each new manufacturer the new fingerprint must be added into this driver. Currently, _TZE200_sh1btabb is recognized as an irrigation valve.
This is a basic On/Off valve control only. There are other advanced features like irrigation timer start/end times, irrigation duration, etc.. which functionality is not clear to me. If someone has this device and can explain the meaning of these parameters and how these can be used in HE, please let me know.
Great! I purchsed it and should be here tomorrow. All I really care about is on/off really but my needs are probably far different than others. 5-10 second delay with Orbit is just too much for me to handle anymore for my situation.
When you have it, please send me the debug logs from the first pairing in a PM.
What is your use case, are you planning to use it for water irrigation (limited time on)?
My main doubt is whether this device can be switched on permanently or not.. It's a battery-powered device, so I have a doubt that these complex timers should be used, but we will understand after the tests...
