I decided to try @kkossev your Tuya NEO Coolcam Zigbee water leak driver and it appears to work. It reports "dry" every 60 minutes. I'm chasing this because I upgraded all of my Third Reality water leak sensors to get battery status which also reports with your Tuya. driver. It would be great if a version of your driver could report every 12. I don't know enough to know if that would have less impact on battery life. I assume the battery report is coming from some sort of polling that wakes up the sensor.
The Tuya NEO Coolcam driver was not intended to work with non-Tuya sensors... It does not explicitly configure the battery reporting periods of the standard IAS devices, such as the ThirdReality.
I checked the code - this event "${device.displayName} is dry" is sent only when the device really sends a dry/wet IAS Zone status message (i.e. it is not fake! ...
)
There is no polling.
1 Like
Edit: Looks like I'm wrong about battery. I went back and set Device as the driver and cleared out states and battery came back as power source "battery."
Thanks for the feedback. I've tested the device and it properly alerts when wet and turns off my well pump and water pressure tank. If the hourly "dry" makes device activity check happy I'm good for now. Prior to updating the firmware I had no battery reporting. If your driver isn't correctly reporting battery I'm at least back to where I was, depending on device activity check notification to tell me that the battery likely needs attention.
Using @kosssev's Tuya NEO Coolcam Zigbee Water Leak Sensor driver the Third Reality sensor reports "dry" hourly. If the generic driver could report that would it solve the device activity check problem.
I checked the deConz implementation, they are explicitly configuring the battery reporting interval to 24 hours.
I suppose that without configuration, the remaining battery percentage level is reported only when it is changed, i.e., if the level stays 100% for a long period, it will not be reported automatically. This is actually not needed if the device reports the dry/wet status every hour.
This means the device is sending this report every hour. Which also means the system driver must be filtering out the event as a duplicate and not even posting it to the hub 
.
IMO they should at a minimum post the event and let the hub decide if it is a state change or not, this would have been updating the Last Activity properly. I understand they don't want to spam the logs with duplicated events because people will complain about it, but logging is totally separate from the actual event being posted. Filter the logs if you want, not the events.
1 Like
@bbrannon can you make an experiment - temporarily change the 3RWS18BZ driver to the Zigbee Generic Zigbee Switch driver and click on the on() command button ... will the buzzer switch on?
Selecting on and off with the generic ZigBee switch driver turns the beep on and off. Since it is no longer a leak sensor it does not activate Hubitat Safety monitor and the associated valves. I did not understand what this had to do with a buzzer until I heard the "beeps." 
1 Like
That's pretty cool, a battery powered Zigbee device that responds to on/off commands. Doesn't it need yo sleep?
@kkossev must have a method to his mad...... I'm looking forward to where it takes him/us. Definitely beyond my paygrade.
Yep, its rather unusual a battery-powered leak sensor to listen all the time for on/off command.
I am pretty sure the device will also react to the Zigbee Group broadcasts...
But what would be the practical use of such a feature?
When one leak sensor gets activated, should the alarms on all other leak sensors across the different rooms be turned on? This will not help to quickly identify where the actual leak occurs .... 
Follow-up on Third Reality water leak sensor 3RWS18BZ with new firmware 38. with Generic Zigbee Moisture Sensor (no temp) built-in driver it does report battery level but does not report status on any regular interval so device activity check is of no use.
Using Tuya NEO Coolcam Zigbee Water Leak Sensor driver. There is no battery level reporting. It reports wet/dry, and it reports "water" status "wet/dry" hourly. That does work with device activity check. I'm switching mine to the Tuya driver because knowing if one of these is no longer online is important to me.
It would be great if Hubitat could enable "water" status in the built-in driver. @mike.maxwell
Its not a matter of enabling anything, they just need to post all events to the hub instead of filtering them. As I explained above.
So I just happened to look in HPM. There is a community driver for these sensors, and I just installed it. Will see how it plays out.
https://raw.githubusercontent.com/tmastersmart/hubitat-code/main/third-reality-water-sensor.groovy
1 Like
It looks like that driver does NOT filter out any events, they should all be getting posted. The hub will filter duplicated events from the event history but it will still update the last activity.
Looks like it would log every event also, even if duplicated.
Code looks like sort of a mess but if it works it works I guess.
From the users perspective that's semantics. The built-in driver would do what I need if those broadcasts were exposed. @kkossev discovery that the beeper can be turned on and off would be useful. After the device alerts it would nice to turn off the beeping while one is trying to dig out the sensor. I have one under the fridge and dishwasher that require removing some trim to get to.
I just installed this on one sensor. It will be interesting to see how the logs look throughout the day.
1 Like
Curious too with yours on the newer firmware...
[edit] Seems to be reporting Dry every hour with the new driver.
If the device reports battery remaining pecentage (not only the battery voltage), you can also try the IKEA Badring Water Leakage Sensor driver. During the pairing, it should configure the device to report battery every 5 hours. No polling required, the device is doing all the work.
2 Likes
Does it report an error if an he cr request fails or is ignored? Iām not able to look into it right now but that would be my theory for why the new firmware works differently. Other TR devices are known to ignore cr requests
