# SmartStart with a custom Z-Wave driver — SmartStart option missing from driver pairing flow **URL:** \ **Category:** Developers\ **Tags:** z-wave, homey-pro, homey-pro-2023\ **Created:** [October 1, 2026, 10:45pm UTC](https://community.homey.app/t/smartstart-with-a-custom-z-wave-driver-smartstart-option-missing-from-driver-pairing-flow/160261 "2026-10-01T22:45:25Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![J\_Reeves](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/j_reeves/32/79349_2.png) [@J\_Reeves](https://community.homey.app/u/J_Reeves)\ **Post date:** [October 23, 2026, 9:58pm UTC](https://community.homey.app/t/smartstart-with-a-custom-z-wave-driver-smartstart-option-missing-from-driver-pairing-flow/160261/2 "2026-10-23T21:58:40Z")
Following up on my October 1 question: is there a supported SDK3 route for SmartStart enrollment into a custom driver, or for using the required notification while the device remains Generic-owned? For clarity, the observed test setup and results were: - Homey Pro (Early 2023), Homey OS 13.5.0 at the time of testing. - Yale YRD430-F-ZW3, Z-Wave firmware 2.40; S2 Access observed on a working paired Yale. - Non-secret fingerprint verified from a working paired Yale: manufacturer 297 (0x0129), productType 33031 (0x8107), productId 18899 (0x49D3). All three match the custom HA-002 v1.5.4 Apps SDK3 driver’s manifest, which sets requireSecure: true. - Classic inclusion failed through both the custom-driver and Generic Z-Wave paths. - Controller-level SmartStart through Devices \> Add Device \> Z-Wave paired successfully, but assigned the device to Generic/Default Z-Wave rather than HA-002. - The inclusion UI launched from the custom driver’s Connect button did not offer SmartStart. I would appreciate clarification on four points: 1. **SmartStart and driver ownership:** What is the supported enrollment/provisioning workflow for an SDK3 custom Z-Wave driver? Should controller-level SmartStart match an installed custom driver by fingerprint? Are additional manifest settings, publication/distribution requirements, or other documented conditions involved? 2. **Generic-to-custom reassignment:** Is there a supported way to transfer an already-included device from Generic to the matching custom driver while preserving its inclusion/security relationship? If this is unsupported, please confirm the supported alternative and its limitations. 3. **Generic-owned notifications:** Can an SDK3 app subscribe through a supported API to Notification CC Access Control (type 0x06), Event 6 (Keypad Unlock Operation), from a device owned by Generic? Alternatively, does Generic expose documented event/source metadata that distinguishes keypad unlock from manual/thumbturn or RF unlock? Ordinary Unlocked state alone is insufficient for this project; runtime source metadata has not been validated. 4. **Comparable Classic-inclusion report:** In [this Yale Assure Lock 2 report](https://community.homey.app/t/yale-assure-lock-2/108762/16), Dustysa4 describes learn-mode inclusion through Generic Z-Wave followed by a DSK prompt, explicitly without SmartStart. The preceding post identifies Assure Lock 2 Touch with AYR-MOD-ZW3-USA firmware v2.40.0. This is comparable hardware, not proof of identical hardware or fingerprint. Are there documented model/module, inclusion-sequencing, Homey-version, or security-negotiation differences that could explain why that Classic path works while ours failed? Has later Homey support changed either path? Links to official documentation, a minimal supported example, or a clear statement of unsupported behavior would help us choose the next step. No further pairing or driver changes are being performed while this is unresolved. Please keep replies free of PINs, DSK values, network/security keys, or other credentials. Thank you! --- _[View the full topic](https://community.homey.app/t/smartstart-with-a-custom-z-wave-driver-smartstart-option-missing-from-driver-pairing-flow/160261)._