Why I’m Doing This
My Yale Assure Lock 2 (keypad/touchscreen, no fingerprint) was originally sold with promises of eventual Matter support, so it shipped without any smart module installed at all. Yale never delivered on that promise. In the meantime I’ve been relying on Bluetooth and Yale’s cloud service (the Yale Access app) to manage the lock, and it’s been unreliable and offers very little real control — no local automation hooks, inconsistent status updates, and a dependency on Yale’s servers staying up.
I run Home Assistant on a Home Assistant Yellow, which gives me:
- A built-in Zigbee/Thread radio (Silicon Labs MGM210P, Zigbee 3.0)
- No built-in Z-Wave radio (requires a USB dongle)
I want to get this lock fully integrated locally, with no cloud dependency, so I can:
- Create and manage user PIN codes for the lock directly from Home Assistant
- Get real-time, reliable status: locked/unlocked state and battery level
- Ideally also get door open/closed (DoorSense) status, so I know if the door itself is ajar, not just whether the deadbolt is thrown
To do this over Z-Wave, I bought an Aeotec Z-Stick 7 Plus USB Z-Wave controller to plug into the Home Assistant Yellow.
Current Architecture / Devices
| Component | Details |
|---|---|
| Hub | Home Assistant Yellow (Raspberry Pi CM4-based), running Home Assistant OS |
| Built-in radio | Zigbee 3.0 / Thread (Silicon Labs MGM210P) — not currently used for this lock |
| Z-Wave controller | Aeotec Z-Stick 7 Plus (USB dongle, Z-Wave 700-series, S2-capable) |
| Lock | Yale Assure Lock 2, keypad/touchscreen variant, no fingerprint sensor (base model YRD410/420/430/450-BLE) |
| Lock module (planned) | Yale AYR-MOD-ZW3-USA — Z-Wave Plus 700-series “Smart Module,” firmware v2.40 |
| Current lock connectivity | Bluetooth + Yale Access cloud app (unreliable, being replaced) |
| Target integration path | Z-Wave JS integration in Home Assistant, paired to the Z-Stick 7 Plus, S2 Access Control security |
Why this module specifically
Yale’s official compatibility list for the plain Assure Lock 2 (YRD4x0-BLE) only lists the older AYR-MOD-ZW2-USA module, which only supports S0 legacy security (weaker Z-Wave encryption). The newer AYR-MOD-ZW3-USA (700-series) module supports S2 Access Control, the current Z-Wave security standard, and community reports (zwave-js GitHub discussion) confirm it works on non-Touch Assure Lock 2 units as well, even though Yale doesn’t officially cross-list it. Firmware v2.40 specifically has been reported as reasonably reliable by other users.
A Zigbee module for this base lock also exists in principle (Zigbee2MQTT documents “YRD420-BLE” as a supported device), but I wasn’t able to find a currently-purchasable Zigbee module confidently confirmed for this specific base hardware — so Z-Wave via the ZW3 module is the practical path for now.
The Goal: DoorSense (Door Open/Closed) Over Z-Wave
Out of the box, lock/unlock state, battery level, and user code management all work reliably over Z-Wave with this module. DoorSense — Yale’s built-in door-open/closed sensor — is the outstanding gap. It works over Bluetooth (in the Yale app) but has a long history of not reporting over Z-Wave, which Yale has acknowledged as a module firmware limitation without ever properly fixing.
One community member documented a workaround: enabling DoorSense notifications over Z-Wave by writing a specific value to a Configuration command class parameter, based on Yale’s own Z-Wave Integrator’s Guide. This document captures that fix.
Step-by-Step Guide
1. Install the module and physically pair the lock
Power down the lock, insert the AYR-MOD-ZW3-USA into the module slot on the interior assembly above the battery compartment (it only fits one way), and put the batteries back in. Note the DSK code printed on a sticker on the module itself — you’ll need the last few digits during pairing.
In Home Assistant: Settings > Devices & Services > Z-Wave JS integration > Add Device, then put the lock into pairing mode per its manual (usually a button combo on the keypad, or it auto-enters pairing mode briefly after battery insert).
2. Complete S2 secure inclusion
When the inclusion wizard prompts for a security class, choose S2 Access Control (it should default to the highest class the device supports). Enter the DSK PIN from the module’s label when prompted. The interview process can take a minute or two as it queries all the lock’s command classes.
If it silently downgrades to S0 or fails, remove the device and retry, keeping the Z-Stick 7 Plus physically close to the lock — inclusion is more RF-sensitive than normal day-to-day operation.
3. Confirm basic functionality first
Before touching any configuration parameters, verify lock/unlock control and battery reporting work from the Home Assistant device page. This confirms the module paired cleanly and that the Configuration command class is responding — which the next step depends on.
4. Open the device’s Z-Wave configuration parameters
Go to the lock’s device page: Settings > Devices & Services > Devices > [your Yale lock]. In newer Home Assistant versions, configuration parameters show up directly as number/select entities on the device page, prefixed “Configuration parameter N.”
If you don’t see them there, use the Z-Wave JS panel instead: Settings > Devices & Services > Z-Wave > (three-dot menu) > Open Z-Wave JS panel (or the Z-Wave JS UI / zwavejs2mqtt add-on’s own web UI if you’re running that instead). Navigate to your lock’s node, then the Configuration tab.
5. Write 0xFF (255) to parameter 19 (“DPS Alarms”)
Find parameter 19 in the list. If this device doesn’t yet have a full config-DB entry in Z-Wave JS, it may show up unlabeled as “Parameter #19” with a raw numeric field rather than a friendly name — that’s fine.
Set it to 255 (equivalent to 0xFF in hex) and save/apply. If the field only accepts hex input, enter 0xFF or FF instead.
6. Trigger the door and watch for a new entity or state change
Open and close the door a few times. Watch the lock’s entity list for either a new binary_sensor entity (something like “Door” or “Notification: Access Control”) appearing, or an existing Notification/Alarm entity starting to report door position.
If nothing appears after a few cycles, use the device’s three-dot menu to re-interview the device, then test again.
7. If nothing shows up, don’t force it further
This fix isn’t guaranteed. It worked for at least one user on one firmware revision, but Yale’s module firmware has varied a lot across batches (v1.x, v2.17, v2.35, v2.40 have all been reported, sometimes behaving differently). If parameter 19 doesn’t produce a DoorSense entity after a re-interview, the reliable fallback is a standalone Zigbee contact sensor (~$15–20) mounted on the door frame, using the Home Assistant Yellow’s built-in Zigbee radio. That sidesteps the whole DoorSense-over-Z-Wave reliability question entirely.
Practical Notes Before Starting
- Back up the Z-Wave network first. Settings > Devices & Services > Z-Wave > three-dot menu > “Back up network.” Configuration writes are low-risk, but cheap insurance is cheap insurance.
- Firmware v2.40 is a good sign. It’s the most recent revision reported in the wild for this module, roughly matching the firmware the original parameter-19 workaround was documented on.
- If parameter 19 doesn’t appear at all in the friendly UI, that likely means there’s no config-DB entry for this device yet in Z-Wave JS. Look for an “Advanced” or manual/raw configuration parameter entry option in the Z-Wave JS panel to write to parameter 19 by number directly.
Wrap-Up: Summary and Sources
What reliably works via Z-Wave with the AYR-MOD-ZW3-USA module:
- Lock/unlock control and real-time lock state
- Battery level reporting
- User PIN code creation, editing, and removal (Z-Wave User Code command class)
What’s uncertain and depends on the parameter-19 fix:
- Door open/closed (DoorSense) status — works for some users on some firmware revisions, not officially supported by Yale
What doesn’t currently work over this module:
- Auto-unlock detection via Bluetooth proximity (this only ever worked over BLE, not Z-Wave)
- Detailed “who unlocked and how” audit trail (Notification/Alarm command class has been unreliable on this device when using S2 security)
Sources referenced in this guide
- DoorSense parameter-19 fix: “Experiences with a Yale Assure Lock 2 (YRD420) and a 700 series Smart Module (AYR-MOD-ZW3),” zwave-js/zwave-js GitHub Discussion #5391 — https://github.com/zwave-js/zwave-js/discussions/5391
- ZW2 vs. ZW3 security class (S0 vs. S2): Same GitHub discussion, and “Yale Assure 2 lock with z-wave module,” Hubitat Community forum — https://community.hubitat.com/t/yale-assure-2-lock-with-z-wave-module/113124
- Alarm/Notification command class unreliability with S2 security: “Z-Wave JS - Not receiving Alarms (unlock notifications) from Yale Keyless Smart Lock using S2 security,” home-assistant/core GitHub Issue #83135 — https://github.com/home-assistant/core/issues/83135
- Official Yale module compatibility listing: Yale Home Smart Modules page — https://shopyalehome.com/pages/smart-modules
- Zigbee2MQTT device support reference (for context on the lock’s base hardware, even though the Zigbee path wasn’t pursued here): https://www.zigbee2mqtt.io/devices/YRD420-BLE.html
This guide reflects community-sourced, unofficial findings as of August 2026. Yale has not officially documented or supported the parameter-19 DoorSense workaround, and module firmware behavior has varied across production batches — results may differ from what’s described here.
