Looks like it (UTC+8). I am also in UTC-4, so the exact opposite of Beijing currently. It would be a reasonable default, since a quarter of the world's population lives in that time zone.
The absolute time on the valve is little more than a curiosity to me. My open/close logic is through webCoRE and the valve timer provides an emergency backstop duration. Delighted so far.
I don’t use it for anything either. I mostly need to figure out why my one valve won’t follow the set timer, while my other two follow it without issue. There the exact same valves.
@kkossev , the health status online/offline attributes don’t correlate to the Geix valves being on the network (C-8). For several days I have received alerts that 2 of the valves are offline (and it says offline on the driver page), but the device responds immediately to commands and then changes to online. Maybe this could be replaced by last message introduced in .127?
I will test this opportunity ASAP.
But it will be a solution for C-8 hubs only for now..
The alternative is to periodically ping the valve, but this also doesn’t work for all types of Zigbee2mqtt devices. Will have to experiment.
Do you see battery level reports in the Events page? How often is the battery level reported, when there is no other activity?
Looks very inconsistent. I’ll have to increase the events history and watch it.
Yes. Apparently not for any hubs prior to C-8.
Just pushed version 1.2.4 (2023-04-09) for updates via HPM. You can also update manually..
The ping() command measures the rtt (the round-trip time). What does it show with the GiEX battery-powered device?
1200 to 4000. Very inconsistent. Makes sense though. They are slow to respond to open and close events and were slow on the Tuya hub as well.
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.
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.
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.
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.
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.
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! : )
Download the Hubitat app
