If debug is on, and it is for 30 min after the pairing, the driver will log everyting it receives from the device and we can find an entry if the device says "binding failed" or "configuration reporting failed" (but not with so many words).
If the device ignores the requests and sends nothing back, we should find nothing in the logs, but that also tells us something.
Post the pairing logs and we can take a look at it.
I'm seeing "dry" every hour. I'll watch it until my device activity check report at 8 am. The Third Reality driver seems to work well enough. Reports battery remaining, wet / dry, and not spamming the logs.
With the Third Reality driver I'm not seeing a battery report. However, they log "water" wet/dry hourly which satisfies device activity check. On the device page battery and voltage are reported. I have them set up in dashboard tiles and battery as well as wet/dry is displayed. Additionally, battery seems to increment in 10% intervals, five are at 80, one at 90 and one at 100 which seems reasonable based on install date. The good news is they don't all read 100.
Yeah, I'm seeing the same with the older firmware.
I'm still tempted to return this device and buy something that works properly with hubitat. It's not tripping my activity check stuff anymore, but I have enough other devices that don't properly report battery.
I'm over not knowing if a device fell off the network, or if the battery died.
I'm happy with these. Eventually there will be a better driver but the one you found is suitable for now. The new firmware reports battery. Wet/dry logs hourly which is the "I'm still alive" signal for device activity check. Battery life is well over a year. Set up device activity check. I get a notification if one of my battery devices doesn't show up in a 24 hr period. Time frame is adjustable for devices that you can group as desired. Several notification options. Easiest way to get it Hubitat Package Manager. All but two of these are Third Reality on the new firmware.
Can't re-pair the device at the moment, but switched the driver and hit Configure, looks like the Configure Reporting commands are denied by the new firmware:
Older firmware appears to ignore them (no Configure Reporting Response is received). I'm not sure they ever worked. It seems this new firmware simply behaves differently. Looks like polling the device state is the only option.
I updated them with the built-in generic zigbee moisture sensor (no temp) driver. After selecting update firmware I watched the live log and it updated in 10% increments over five or ten minutes.
Yep, you are right. No reporting on this device. I checked and the zigbee2mqtt converter also does not configure reporting, it just reads the battery percentage on configure.
Responds to on/off commands (although it does not list cluster 0x0006 in the inClusters list), needs polling to retrieve battery level... this is a weird device
and it apparently doesn't sleep However it has proven to be an effective sensor here, on a number of occasions. I suppose the on/off commands could be useful for (temporarily) muting the (loud) built-in alarm if the situation requires it.
Otherwise, using the generic system driver + setting the "Refresh" option in Device Activity Check is an acceptable workaround for me.
FYI the community driver "Third Reality water sensor" reports "water" wet or dry every hour which satisfies device activity check. I'm not seeing anything else in the logs.
I’ve only given a cursory look at the code but believe this is the result of the community driver polling the device, not the device reporting on its own, in which case there is no benefit using this driver over using Device Activity Check to issue a Refresh request to the built in driver (I use a 1 day interval).
I tried both ways, no idea which has less effect on battery life. I'm going to assume that a proper driver will surface and we can all profit from that skillful generous person.
The "tmaster" community driver does perform the appropriate "Configure Reporting" request, yet the configuration request is explicitly denied by the device in its response message. It's not a problem with the driver.
The ability to configure a device for self-reporting attributes at regular intervals (or for specific deltas) is a feature that must be implemented by the device firmware. This cannot be fixed at the driver level. When this feature is not available, polling is the only alternative - it's lucky we can even rely on it in this case, as battery-powered Zigbee End Devices are usually sleepy and don't respond to polling.
How you do the polling - either using a driver that does it for you, or via Device Activity Check - is up to you.
I'm very confused. I have 10 of these and this "trick" worked on one of them, but I've tried it at least a dozen times now on other ones and absolutely nothing happens in the logs after telling it to update. Very strange.
I wouldn't bother with the firmware update. The one I did failed device activity check with the built-in generic driver. I went back to the Third Reality water Sensor, author "tmastersmart" driver which doesn't report battery correctly but does report wet/dry hourly and is then tracked by device activity check. When it shows up on the report it will be time to change the battery.