Makes sense to me too.
Waking up and listening for incoming commands for a short time period every 3-4 seconds is a normal compromise implementation for other battery-powered Zigbee devices as well.
1 Like
No battery reports since yesterday when I opened and closed them. They still are connected and open and close from the device page. Initial rtt 7591 on first valve, 2297 on second valve, 3477 on third valve. They report battery percentage when activated.
1 Like
I have a TS0001 I am trying to pair and control from a C-7 hub.
Seems to pair, I get:
Device pairing info
| Manufacturer: | _TZ3000_5ucujjts |
|---|---|
| Endpoint 01 application: | 64 |
| Endpoint 01 endpointId: | 01 |
| Endpoint 01 idAsInt: | 1 |
| Endpoint 01 inClusters: | 0000,0006,0003,0004,0005,E001 |
| Endpoint 01 initialized: | true |
| Endpoint 01 manufacturer: | _TZ3000_5ucujjts |
| Endpoint 01 model: | TS0001 |
| Endpoint 01 profileId: | 0104 |
| Endpoint 01 stage: | 4 |
But using the Tuya Zigbee Valve v1.2.4 driver, I get no response from the valve when I give Open or Close commands from the device page.
Logs show:
dev:822023-04-22 09:27:36.311 AMdebugWater Main sendZigbeeCommands (cmd=[he rattr 0x1CC4 0x01 6 0 {}, delay 2000, he raw 0x1CC4 1 0x01 0xE000 {10 00 00 01 D0}, delay 200, he raw 0x1CC4 1 0x01 0xE000 {10 00 00 02 D0}, delay 200, he raw 0x1CC4 1 0x01 0xE000 {10 00 00 03 D0}, delay 200, he raw 0x1CC4 1 0x01 0xE001 {10 00 00 10 D0}, delay 200, he raw 0x1CC4 1 0x01 0xE001 {10 00 00 30 D0}, delay 200, he raw 0x1CC4 1 0x01 0x0006 {10 00 00 01 40}, delay 200, he raw 0x1CC4 1 0x01 0x0006 {10 00 00 02 40}, delay 200, he raw 0x1CC4 1 0x01 0x0006 {10 00 00 01 80}, delay 200, he raw 0x1CC4 1 0x01 0x0006 {10 00 00 02 80}, delay 200])
dev:822023-04-22 09:27:36.274 AMdebugWater Main refresh()...
dev:822023-04-22 09:27:33.297 AMdebugWater Main sendZigbeeCommands (cmd=[he raw 0x1CC4 1 0x01 0x0000 {10 00 00 04 00 00 00 01 00 05 00 07 00 FE FF}, delay 150, he wattr 0x1CC4 0x01 0x0000 0xFFDE 0x20 {0D} {}, delay 50, he wattr 0x1CC4 0x01 0xE001 0xD010 0x30 {02} {}, delay 251])
dev:822023-04-22 09:27:33.250 AMdebugWater Main setting powerOnBehaviour to last state (2)
dev:822023-04-22 09:27:33.244 AMinfoWater Main configure()..
Is this the problem with Zigbee 3.0 devices mentioned above that we need to wait for a hub software fix for?
Thank you
Seems like the same problem with some other Zigbee 3.0 devices, that will not keep connected to Hubitat. The debug logs don't show anything to be received back from the device... If it stays paired to HE, the hub should receive a message when the valve is manually switched on/off even when using the HE inbuilt 'Device' driver ...
Did you purchase it from some of the links shown in the first post?
All I can do at this time is to put a warning "Do not buy"...
I bought it from a similar AliExpress store.
Will hope the Zigbee 3.0 issue gets solved at some time.
Since .129 a strange thing has happened. All 3 Tuya (Geix) valves have been listed as child devices of my C-8. I am not having any trouble with them. Just an observation. They had previously all been listed as routing through a GE outlet. They are stored behind the cabinet the C-8 sits on top of. I haven’t been using them due to plenty of rain, but have been checking them daily by sending on/off commands and they have been connected for many weeks now.
1 Like
This can be expected, as the C-8 has a much more effective antenna compared to the older generations hubs.
You can try sending Ping command instead, every 12 hours. This should keep the device healthCheck status online until I implement an automatic pinging function in a future driver version.
Any idea why my device isn't being recognized during Zigbee pairing? I can tell in the code you added the fingerprint but something isn't right..
dev:8202023-04-26 09:41:14.270 AMtrace destinationEP = 01
dev:8202023-04-26 09:41:14.268 AMtrace model = TS0001
dev:8202023-04-26 09:41:14.265 AMinfoTuya Zigbee Valve tuyaVersion set to 1.2.4
dev:8202023-04-26 09:41:14.187 AMinfoTuya Zigbee Valve all states and scheduled jobs cleared!
dev:8202023-04-26 09:41:14.181 AMwarnTuya Zigbee Valve device model TS0001 manufacturer _TZ3000_5ucujjts was not found!
dev:8202023-04-26 09:41:14.178 AMwarnTuya Zigbee Valve unknown model TS0001 manufacturer _TZ3000_5ucujjts
dev:8202023-04-26 09:41:14.156 AMinfoTuya Zigbee Valve InitializeVars()... fullInit = true
dev:8202023-04-26 09:41:14.144 AMinfoTuya Zigbee Valve installed() model TS0001 manufacturer _TZ3000_5ucujjts driver version 1.2.4 2023/04/09 10:55 PM
sys:12023-04-26 09:41:12.979 AMinfoInitializing Zigbee Device 70B3D52B600136D7, 4644
Same as the case above ... Hubitat latest platform updates incompatibility issues with some Zigbee 3.0 devices. The device will send a Zigbee ''leave' command, change it's NWK address and will not be reachable by HE hub anymore.
1 Like
The hub must be doing this on its own since .129 implemented pinging devices that haven’t checked in. I haven’t seen anymore offline events since .129.
1 Like
C8 only - added logic to proactively ping devices that had no messages in 3 hours or more. This should stop devices from dropping off the network
I owe @gopher.ny a 
for saving me some extra work on this custom driver then! : )
1 Like
@kkossev This isn't insanely important, but I wanted to at least report it. No matter what I can't get mine to use duration. It is always capacity. Tried changing the "Set Irrigation Mode" numerous times but it never actually changes anything. Like I said not a massive deal as I can set the capacity to a crazy high number and it works fine.
To add to what I just posted. Entering a value in the Set irrigation Timer field, is what it bases its capacity run time to.
So if I enter in 10 seconds. It's runs until the capacity reaches 10. Hopefully that makes sense.
1 Like
Hi @JmikeyB , thank you for the feedback!
This may be a bug in this driver, or may be a 'feature' of the GiEX valve, I don't know.. The device uses one and the same 'Tuya Data Point' command to report both parameters - duration in minutes or capacity in Liters (depending on mode). Probably, a better approach would be to remove the separate setup of the duration and the separate setup of the capacity, as combine both in one single parameter? So depending on the device mode (duration or capacity), this parameter will be interpreted differently.. I don't know if this will be better or worse.
Can you confirm, that for the GiEX valve the duration is actually in minutes (not in seconds, as the driver shows it now)?
My Giex valve duration is in minutes. I have 3 identical valves, 2 follow the set duration perfectly, 1 will not follow the set duration no matter what. I have deleted it and rejoined several times and no change.
Does anyone know how to get the TS0601 valve controller into pairing mode? I've tried holding down the button but that doesn't seem to work.
You need to be in a dark area to see the red flashing led. After holding down the button for at least 6 seconds, after releasing the button, you should see the flashing led on the left side, close to the button.
I believe it is minuets not seconds. But I honestly can't tell for absolute certainty as I have never been able to change out of capacity mode.
@Ken_Fraleigh are we talking about the same valve controller? There is a LED right below the button (not to the left) but it doesn't flash no matter how long I hold down the button.
Sorry. Apparently not. Same model number, but mine is the irrigation valve.
