Announcing a Hubitat driver for Yale Assure 2 locks over ZWave by sleuth255/trunzoc!
This driver is a significant enhancement for these already reliable Yale locks. Recommended for use with the black ZW3 module using S2 security since both efficiency and reliability are dramatically improved as compared to the green ZW2 module that only provides S0 security. The black ZW3 module also has significantly improved battery level reporting.
Version History
v1.05 Initial release
v1.06 Capture Autolock
v1.07: adopt kdb-jc mods: jam detect, fingerprint triggers keypad unlock event, ignore truncated lock codes, rule machine "lockcode trigger" support
Features:
Doorsense and Biometric unlock are captured to the current state
Full Support for ZW2 (green) and ZW3 (black) ZWave modules
Fully compatible with Lock Code Manager
Automatically selected for all YRD4xx series locks during installation
Install the “Yale Assure Lock 2” driver using the Hubitat Package Manager. You can either search for “yale assure” or by using the “lock” and “ZWave” tags.
Black ZW3 modules have part number AYR-MOD-ZW3-USA and can generally be found on eBay. It is recommended to purchase a BLE (Bluetooth only) lock variant then install this module after the lock has been added to your Yale keychain. WiFi connectivity can be enabled using a Yale or August (cheaper) WiFi bridge if remote control via the yale app is desired.
Known Issues:
For biometric unlocks, the user name isn’t captured since this is maintained on the Yale app itself. A generic “unlocked by fingerprint match” event is recorded.
If the device driver is selected after the generic lock device has been in use, be sure to either run the "Initialize" command or hit "Save" on the preferences tab to properly initialize state variables and clean up the LockCodes state.
(Fixed) The driver won’t capture auto-lock events that are set up using the Yale app when the ZW2 module is installed. This is because no ZWave event is produced by this module for auto-locks. Instead, use rule machine to create a simple auto-lock routine that leverages both lock and door-sense states:
Hey this is great! I happened to be debugging 2 Yale Assure Lock 2s I recently installed to replace ancient and always problematic Schlage locks (flaky S0 connections), and it annoyed me that DoorSense wasn't accessible in the built-in driver when it's clearly reporting it, so your release timing was perfect! I did a bit of a deep dive into it (based off of version 1.05) to work out all the kinks with my 2 locks, iterating a bunch with Claude. If you're open to it, I'll clean it up a bit and send you a PR?
FYI, my locks are Touch with fingerprint (one keyed, one keyless), both with ZW3 modules, so those variants are pretty well tested at this point, but nothing else. A few key things I fixed:
Not sure if this is a defect with (both) my locks, but they regularly truncate user codes to just the first digit in UserCodeReports, which would mangle the code map in the device and LCM (e.g., 1234 became 1). This also affected the built-in generic driver.
Deleting a code from LCM would go into a loop because the driver was sending a userCodeGet to verify the delete, which was never answered, so it kept trying again until LCM timed out, never believing the code deleted (when in fact it was on the lock itself).
Added physical/digital labeling of lock/unlock events. Also, remapped bad states of the lock (e.g., jammed) to unknown instead of unlocked.
Handled report parsing more robustly for unlocks by codes and fingerprints. Requires adding fingerprints in the same order as codes, since that's handled in the Yale app and Hubitat can't change it, but it works (fingerprint differentiated from code, and mapped to correct user, etc.).
Handle admin codes (slot 251, etc.) more explicitly, so they're visible but still isolated from LCM.
Optionally redact codes from logs. Added getCode to query specific slot.
This driver should address those issues. We did test with both biometric and regular variants. However, if you were using the generic driver then the admin codes were stored and the issue with code mangling (older firmware v1.3 lock with ZW3 module bug that we had to work around using state variables) was also stored. The generic driver doesn't work well at all with the ZW3 module and picks up the programming code in slot 251 when it scans the lock codes since only 250 slots are available to store user codes but the lock doesn't report this. We decided to remove the programming code from the lockcodes json because Lock Code manager also doesn't do well with it either. v1.05 should correct most of the issues if you run the initialize command. For some of the mangled codes, you may need to remove them with lockcode manager. We also decided to go with a generic "unlocked by fingerprint match" due to the Yale app being the source of truth for those. The initial development thread talks about most of this and is located here:
Thanks, I did skim that thread but I admit didn't read every post. And sorry I did cram a bit too much into that previous list of changes, so after a bit more (re)testing I trimmed it down to a minimal diff of just the things that specifically affected me, the main things being:
Adding a code sometimes got truncated to just the first digit in LCM (might be a quirk of my locks, and also only happens when my mesh is congested). Fixed that by suppressing 1-digit codes.
Differentiating fingerprint vs keypad unlocks (my locks didn't follow the pattern already implemented). I followed your design choice of not naming the code on a fingerprint unlock (since truth is external to Hubitat), but still stored it in state anyway in case someone (me) wants to use it.
Capture auto-lock and jam events, and physical/digital tagging.
Also threw in a tiny bit of cleanup that shouldn't affect anything. I dropped the other items (different handling of admin codes, redaction). Will send you a PR shortly since it's just easier to see it in code than explain my changes here, but feel free to reject it if you'd prefer to keep development more contained. I'm happy to keep running my own rogue version.
Interesting info on auto-lock events. I didn't see that a zwave notification happened when those events occurred using the ZW3 module. I'll take a look at it. Also, are you saying that this driver did not capture your fingerprint unlock events with the generic "unlocked by fingerprint match" description? We tested that as well with both ZW2 and ZW3 modules....
edit: yup, seeing event type 9 for autolocks. I'll put an update in for the driver.
Yep on my locks (YRD420-F and YRD450-F with ZW3) I'm getting an event type 0x09 for auto-lock and 0x06 for fingerprint unlock (same as keypad unlock). No 0xFE on fingerprint (so no generic "unlocked by fingerprint match"). Could be different firmware? Mine are both on 1.5.2 for the lock and 2.40 for the ZW3 module.
Ok, I'm testing most of your changes now and will release v1.07 if everything checks out. I've noticed lots of ideosyncracies based on lock firmware. I put in a request with Yale to update my mule locks on v1.3.28 to the latest version (which appears to be v3.0.16 based on my identical but newer door locks) but no joy so far. Thanks for helping out with this driver!
