Ring Flood \ Freeze sensor

So turn on debug logging in the driver, and get the sensor below 40F and see what is logged on the hub? If nothing, then the device didn't send anything (or needs to be configured differently before it will send something), if something then support can be added in the driver.

In an attempt to test this, I paired a Ring flood/freeze sensor to my Ring alarm, left it at room temp for several hours, then moved it to my refrigerator, which has a temp display of 35 deg. At some point, probably as it hit 40, I did get an alert on my Ring app on my phone.

I unpaired the sensor from the Ring alarm and I paired it to my HE, then repeated the same test using both the Ring virtual water sensor driver from the Unofficial Ring integration app and as the generic zwave water sensor. In both cases, when in the fridge, nothing happened, even overnight. Viewing the device properties (where it shows batt %, wet/dry etc...) no new attributes appeared to indicate a status consistent with sub 40 deg temps.

My HE is about 6 feet from the fridge, so I know it's not a connectivity issue, plus I opened the door and touched the contacts while it was inside and it triggered the wet status.

Not sure how it reports sub 40 temps, but I've not seen HE report that info, so must be some Ring magic...

I didn't do that in my testing, I just watched the device properties... :frowning:

That won't work. If the driver doesn't support that event, it will never make an attribute. Need to have debug logging on and see what shows up in the hub logs (if anything).

Oh, and as debug logging turns off after 30 min in most drivers, might have to plan out how to do this.

What I usually do is make a stub driver that just logs EVERYTHING forever while testing. Then go and look at the logs for events I need to verify.

Wonder if I could just hit it with freon to fast-freeze it, versus waiting on the fridge... I'm happy to test, just need to figure out the best way.

OK, share how I do that and I'm in...

Changing the driver to "device" while testing may log every message too, I can't remember offhand. Seems like it would though.

Something like this (this is untested, though - I'm not home by my dev hub right now to get the real driver):

/**
Log everything
*/

metadata {
	definition (name: "Log Everything", namespace: "Botched1", author: "Jason Bottjen") {
		capability "Actuator"
	}

 preferences {
    }
}

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Parse
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
def parse(String description) {
    log.debug "parse() >> zwave.parse($description)"
}

Here is the debug log from one of my Ring Flood/Freeze sensors when it is in the refrigerator...

2021-08-20 10:53:27.694 am [debug] Supervision Get - SessionID: 8, CC: 113, Command: 5
2021-08-20 10:53:27.690 am [debug] parse:zw device: 29, command: 6C01, payload: 88 09 71 05 00 00 00 FF 04 06 00 , isMulticast: false

There ya go @bcopeland :wink:

Just took it out of the fridge, so I'll post that debug log as soon as it warms back up.

Yea.. that wasn't the problem.. There is no standard capability for this function..

Notification Report : 0x71 0x05
Type: Heat Alarm 0x04
State Heat sensor status Idle Under heat detected 0x06 V2

No, but it could log the freeze event and make a custom attribute... Maybe an attribute called "freeze alarm" - true/false.

I dunno, just thinking out loud. :man_shrugging:

Here is warmed back up:
2021-08-20 11:03:38.444 am [debug] Supervision Get - SessionID: 9, CC: 113, Command: 5
2021-08-20 11:03:38.440 am [debug] parse:zw device: 29, command: 6C01, payload: 89 0A 71 05 00 00 00 FF 04 00 01 06 , isMulticast: false

Yea.. that is showing the clearing of that state

Or now that the notification is known, someone could always just make a custom driver for it that includes the alert. :man_shrugging: Being a water sensor it couldn't be that hard. I don't have one, though, so not going to rush out and do it.

Water sensor uses notification class too ..

Type: 0x05 (Water Alarm)
0x02 Water Leak Detected

and 0x00 for idle / clear..

Yup. And sometimes low battery alerts in 0x08. :wink:

Anyway, I'm not trying to argue. I just thought it may be a simple thing to just add the "under temp" alert as an attribute on the in-box driver. I understand if you guys aren't looking to add "oddball" notification/attribute types though!

I love notification based devices as there is no ambiguity like other classes (sensor binary for an example) ..

100%!