Ring Contact G2 is now Zwave Long Range

Model Number 5AT3S2

Well, guys, first time Ring Contact Sensor user here, looks like Ring updated them to be LR compatible and I tried pairing them with SmartStart and with the "classic" non-LR mode and the pairing process seems to be fine BUT after pairing the status open/close is not sent anymore to HE... Am I missing something or is there something "new" going on with the compatibility of these devices?

I'm on platform 2.3.9.193

Which pairing process seems to be fine - SmartStart or the other way?

LR requires SmartStart inclusion.

If you paired it via SmartStart, does the device's entry on your Z-Wave Details page identify it as LR, and does the entry look good otherwise?

What driver are you using for it?

I paired it many times in classic (non-LR) and with SmartStart (LR mode). The pairing process seems to be fine in both modes but after pairing if I open or close the contact, the status is not updated as expected.
Hubitat selects the driver automatically as "Ring Alarm Contact Sensor G2"


deviceId: 1537
deviceType: 513
firmware1Version: 32.38
firmware2Version: 34.0
firmwareVersion: 1.4
hardwareVersion: 1
inClusters: 0x5E,0x9F,0x6C,0x55
manufacturer: 838
protocolVersion: 7.17
S2: 2
secureInClusters: 0x59,0x85,0x80,0x70,0x5A,0x7A,0x87,0x72,0x8E,0x71,0x73,0x86,0x84
serialNumber: redacted
zwaveSecurePairingComplete: true
zwWakeupInterval: 43200

To be clear: the status updates for open/close don’t work in both modes.

Turn on debug logging on the device detail page and see if you get ANY event in the logs when doing the open/close. If not, it is likely a device issue.

If you do, then post it here and hubitat can likely add support for it.

If it's not reporting then likely they changed something in the LR version.. With debug logging on we should be able to see the messages and fix the driver to support this version. So if you could post any messages that show up in the log, that would be a big help.

1 Like

Once I get home I’ll get the debug logs. The interesting thing is that I see the battery reports being received normally, so I guess this is a good thing.

1 Like

Yea.. It really sounds like they changed the reporting.. Pretty easy fix when I see that log..

Here are the logs:



Looks like the open event is being caught but not the close...


How fun this is? I opened and closed the sensor... But looks like I received a batch of opening then a batch of closing events... and looks like they are being received with an interesting delay...

I could make a good guess why, but it's hard to prove without zniffer logs, which requires additional hardware.

We'll see with Bryan says he's the guru.

I would shut down the hub from the UI. Physically remove power for 30 seconds. Power back up. Wait a minute and try the test again and see if it does the same thing...

It appears that it's not seeing the supervision response.. :thinking:

2 Likes

I have a zooz zwave 800 dongle if that helps…

That's almost definitely what's happening. The question really is whether the acks are actually transmitted or not.

If they are (which is likely I would think) then it has to be a device or signal range issue (if it's far away - although that's unlikely with LR).

Might be worth looking at the zwave logs on the hub while doing this. I would think the ack transmissions would show up (although maybe I'm remembering incorrectly - not in front of a hub to check).

I'm seeing this on z-wave logs when I open the device:

Not to mention that the device blinks red once after some time I close it...

1 Like

Bryan I had a ZCOMBO device I played around with and made a custom driver for. I found that I had to add a delay to the supervision acks in order for it to process them. If I sent the response immediately it kept sending the notification over and over until it tossed a system failed error back at me. I landed on a 500ms delay and it worked reliably.

	sendCommands(["delay 500", secureCmd(zwave.supervisionV1.supervisionReport(sessionID: cmd.sessionID, reserved: 0, moreStatusUpdates: false, status: 0xFF, duration: 0), ep)], 0)
1 Like

As of now, no luck with the sensors… this disturbs me a lot… :frowning:

I have a custom tilt/contact driver I made for someone a while ago. I think this will pick up the reports for your device as contact events correctly. I modified it to add a 500ms delay to the supervision as I suggested above. So if anything we will see if that makes it stop repeating and then going into the failure state.

https://pastebin.com/raw/sv8kBtKU

Still no luck with your generic driver BUT maybe these "unhanded notification messages" bring some light:

Is it still going into that failed state with the red flash? I was hoping the delay on the supervision replies would satisfy it. It looks like those first 4 log entries are all repeated retries from the device (it is a cleared tamper alert). Then the other two are heartbeats.

Did you activate the contact sensor at all during those logs? I dont see any contact open or closed events. Might need to turn on debug logging.