Background
I developed this device driver since the built-in driver was becoming unresponsive if status changes (open/close/tamper/button) occurred rapidly (more than 1 in a second). This unresponsiveness wouldn't be easily fixed (sometimes a hub restart, sometimes a mesh repaid) and sometimes required a re-pairing. Since these devices were going to be used for security (intrusion detection), unreliability or unresponsiveness could not be tolerated.
Benefits
This driver has the following advantages over the built in Driver :
Button is now able to be seen/used by the hub
Solved the unresponsiveness of the device
Added all missing notifications sent by device to hub for logging
Added all missing configurable options to the preferences
Solution to the unresponsive issue
According to the SDK release notes : "Z-Wave controller not ACKing Routed Ack during OTA due to a race condition in the protocol task." I might be mistaken, but I believe this was the issue. To fix this, I added a delay to the supervisionReport reply to the device's supervisionGet. The original driver sent it back too soon and the device wasn't ready to receive, which would result in the "red ring light" around the device's button. By adding a slight delay (400ms), the red ring light stopped occurring unless many status changes happened very quickly. By increasing the delay to 1000ms, almost no amount of rapid status changes caused the device to show the red light & become unresponsive.
This device driver allows the user to customize the delay.
Instructionswritten for non-technical, new hubitat users
Install the driver by either :
A) Use Hubitat Package Manager (TBD, still adding the code)
B) Add directly by going to the developer options ('dev' in left menu; might need to enable the section in settings). Steps :
-go to "Device code"
-click "add driver"
-click the 3 dots in the top right
-select "Import"
-paste the GitHub Driver Code link from above
Pair your device. The manufacturer default is do so by SmartStart in Long Range mode. Do the following :
-While on the same network as your hub, open your phone's Hubitat app
-click devices
-click the '+' to add a device
-click "Add SmartStart Devices"
-click "SmartStart"
-click the QR code icon on the top right
-scan the QR on the side of the device
-change any settings you wish, but default for the contact sensor is : "Security 2 Class 1 - Authenticated" and "Long Range" ---- NOTE : Do not use Security 0... the device will not work!
-once powered on, the device should auto-connect to the hub if using "SmartStart Boot Mode" or "Long Range". If using "S2 Boot Mode", you'll need to hold the button on the device for ~3 seconds & put the hub in pairing mode. Remember to always use with security.
Go to the device details (click the device in the device screen) and setup the device by :
A) Ensure the device is using this driver. It should automatic if driver is installed prior to pairing. If not, go to "Device Info" in device details, change "Type" to this driver, hit save, go to "commands", click "configure", and then hit the button on the device to wake it up & receive the commands.
B) In preferences, change all settings to your liking and hit save
Test the device by performing some state changes
Preferences
I added all configurable settings that the manufacturer allows. Please read through the Preference notes. Below are additional notes for your consideration :
Wake Up Interval should be kept low to ensure that battery life is extended
A Supervisor Report needs to be received by the device after each state change (open/close/tamper/button). The device will wait the amount of time listed in "Supervisory Report Timeout (milliseconds)". If no report is received, it will repeat the process (resend the state change & wait) the amount of times listed in "Application Retries".
"Supervisory Report Delay (milliseconds)" is the solution of the unresponsiveness. Note that 400ms allowed a few state changes per second, while 1000ms allows for near unlimited state changes (as per my experimentation at least).
"Supervisory Report Delay (milliseconds)" must be no more than ~200ms less than "Supervisory Report Timeout (milliseconds)" or else you risk never having your report received.
Although your device won't become unresponsive, if state changes happen while the device is waiting for a report to be received, the device won't tell your hub. Thus, the hub will receive the state changes with a delay between each state change equal to the "Supervisory Report Delay (milliseconds)". Think of it like this : the device puts all state changes in a queue and sends them to the hub at an interval of "Supervisory Report Delay (milliseconds)", so that delay ends up being the frequency at which the hub can see state changes. All changes will be seen eventually, but they will come in delayed. Thus, choose your delay wisely based on your situation & use case for the sensor.
It is recommended to keep Info Logging on as it records all events. Debug logging can be turned off unless you are having problems since it records the entry into every method as well as major variables during code execution.
Commands
Configure resends all configurations to the device, but the device won't see them until it wakes up.
Poll Device Data won't return any data until the device wakes up.
"Push" will not wake up the device like pushing the physical button, it only makes the driver think you pushed the button.
Use Cases
You can use this as a normal contact switch
You can use this as a button.
-- the button is #1
-- button also wakes up the device to receive queued commands
General
I commented the code such that a novice looking to code their own drivers can learn why certain things are done and use it as an example/template
I strive to make sure my drivers and apps are usable by all & cover all use cases. If you have any issues or have recommendations, please post below. If I don't respond, message me directly.
I'll update this post (the 1st/main post) as time goes on if any links or other information changes
I wonder if this solution can also fix the unresponsiveness for the Ring Keypad G2 (the version with the newest hardware/firmware that you can buy now from Amz)? The symptoms are similar, although, in the keypad's case, the device receives commands just fine from the driver, but does not send any keypress messages when it's stuck.
I worked a Keypad driver too. It's also in draft / beta, but you can find it on the same Github as this driver. I have not yet made a community post on it.
I have not implemented this solution on it yet, but I plan to as a test. I'm told by others using the driver that it hasn't hung up at all with my driver. Why, though, I do not know. I bought contact sensors and keypads off Amazon back in Nov 2024. The Contact sensors were SDK 7.17 while the keypads were SDK 7.16. I checked the release notes for SDK 7.16 for the keypads (looking for the issue I found in 7.17) and there was no mention of an issue that would contribute to the unresponsiveness. Thus, I'm still theorizing and testing solutions.
For that driver, I still have to implement the missing configurable settings (adding the missing 16 configs the original community driver missed), adding an option for report delay (like this one), and checking some little things. Once all that is done, I'll make a community post like this one.
Hi Mike,
Thank you for your work on this driver! I have been experimenting with your driver (as of Feb 2, 2025), and a Ring G2 sensor. I have a Hubitat C8 Pro, 2.4.0.151. ALL of my devices are ZWave S2 LR. I had no issues including the sensor (firmware 1.4). The driver defaulted to "Generic Z-Wave DT Sensor" (which did not work), and I switched to your driver. I observe the following issues:
1] the "Rooms" panel of the hub reports "undefined button" associated with the device, and the icon does not change state with the sensor open/close.
2] I get (2) reports from each device state change (open or close), always 21s + some mS apart, provided the state changes are made > 21s apart. If the device is open/closed < 21s apart, the 2nd state change isn't reported by the hub. I have quite a long debug log trace that I can send you if interested.
As a side note, I have tried the Generic Z-Wave Contact and Generic Z-Wave Plus Contact drivers, and do not see any state changes at all from the sensor with them.
Thanks for the feedback! The button is likely showing due to the fact I added button capability to the driver. It allows you to know when the button on the device is pushed.
As for the 2nd open/closed... what are your supervisor report timeout and # of retry settings? Also, am I to assume you're using the latest version of the driver?
I'm on a work trip now and won't be able to experiment with the code for a few more days.
I am using the version committed Jan 26, 2025. My preferences are all the defaults:
Wake Up Interval: 43,200
Supervisory Report Delay: 1,000
Heartbeat Interval: 70
Application Retries: 1
Application Level Retry Base Wait Time Period: 5
LED Indicator: On Open and Close
Supervisory Report Timeout: 5,000
Default Current State:
Additionally, not mentioned previously , I do not see any LED indication on "open or close", or "on open" either. I have occasionally seen the LED flash red, though I can't correlate that with any action with the contact.
Setting the Default Current State to "contact" does not seem to change the double report behavior.
LMK if you would like any other details once you have the time to take a look.
Red light? It is not working correctly. I've seen the red light before when I first started using these sensors. Once it starts, they become very inconsistent. I've only got it to work correctly after that by doing a factory reset (long hold of the reset button) and rejoining with security.
I excluded the device and removed it via the REMOVE function in the device details page. The device led began the three-green blink, pause, repeat cycle. However, joy, the device is still present in the Z-Wave details list, with "no response" to the REFRESH. Rebooted the hub, shutdown the hub with power off, rebooted with database rebuild: the device is still listed in Z-Wave details. Factory reset the device and tried it all again - the device is in the still three-green blink, pause, repeat mode (waiting for inclusion I gather from the docs). Removed the batteries for a bit. Same result.
I attempted to include the device again via the iOS app and SmartStart. The app now lists the device as included in the SmartStart list, but the device doesn't think so (still three-green blink, pause, repeat cycle). Interestingly both have the same device id 0x0122. The device is still present in the Z-Wave details list, with "no response" to the REFRESH (makes sense since the device doen't think it is included). I can't seem to get successfully included now, and I can't remove it.
This is my 3rd Z-Wave ghost created by doing normal things while closely following the documented procedures. I have 26 Zooz switches of various kinds all included S2 LR. I believe that these should not cause problems because my entire Z-Wave install will be LR, but would appreciate guidance.
Please advise if I should shift to another thread as it isn't helpful regarding testing your driver.
I've just come across this thread after a lot of frustration trying to get the contact sensors working in LR mode. It seems to report fine and be stable not in LR mode.
I added your driver code, and it seems I still can't get consistent responses from the sensor. I removed it completely, readded it not in LR mode (through the normal inclusion process) and now the event log is reporting everything just fine and consistently.
Please let me know what I can provide to help troubleshoot this
FWIW, I gave up on the Ring sensor and I shifted to the Zooz ZSE41 as my test device is working perfectly in LR S2. The sensor is about 50' from the hub (C8 Pro), and 2 floors up. My test application is a closet light auto/on with trivial Simple Automation Rules and Auto Off. If this continues to work will, I will invest a some more and will likely reconfigure without S2 for the max battery life I can get.
The ZSE41 spec indicates that gap between sensor and magnet should be <= 0.25 inch, which my installation respects, but it does seem to work nicely (at least with a fresh battery), to about 0.5 inches.
Sorry you felt you had to hop to a different sensor. The Ring devices are definitely more finicky than anticipated.
I don't know why LR wouldn't work but classic inclusion would. Might have something to do with Hubitat or another sensor in your network. I've heard Zooz devices sometimes mess up other devices in the mesh by not retransmitting commands/responses.
If you ever find out or stumble across the solution to this issue, please let me know.
Sorry, I totally missed that the responder before me wasn't you If I can provide any logs or info to you to help diagnose why the LR isn't working, would be glad to. For now at least, everything is responding to the hub with the classic inclusion though.
Is there a way to make the icon match the original contact sensor on the device page?
I can change it in the dashboard display, but can't find a setting for this one.
Have you observed this behavior? This is only happening on devices with the custom G2 driver from you installed. The first two open/closes are legitimate from us moving about, but after that these other tamper and closed triggers are popping up without any interaction from us. The tamper alerts are roughly 12hr apart.
I've switched it back to the normal driver for now to see if it resolves, but it isn't happening on a few other contact sensors I set up before finding this custom driver you created.
Picture is newest timestamps at the top, oldest at the bottom
If I can provide any logs or info to you to help diagnose why the LR isn't working, would be glad to. For now at least, everything is responding to the hub with the classic inclusion though.
