Could you also tag this post with the zwave tag?
Yes, it did.
<version>4</version>
<manufacturer>0x3b</manufacturer>
<deviceId>0x469</deviceId>
<deviceType>0x1</deviceType>
Thanks for your help!
Thanks. This device will need a new database entry.
You can add it to the database yourself if you like. Just follow the directions in database guide.
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-database-guide
As described in the database guide, uploading the node.xml file will get the command classes set up. You just need to manually add the associations and config parameters, which look pretty straightforward.
Once the database is updated, you’ll need to wait for a new binding release (usually a few days), then install that new version of the binding.
Post back here with any questions/issues, and we’ll help you get it set up.
Perfect, thank you again for your help!
Just so I understand, once the database is updated I’ll need to migrate to the 2.4 zwave snapshot binding in order to get the newest bindings correct? Thanks again!
Almost. You’ll need the 2.5 zwave snapshot. If you don’t want to update to the openHAB 2.5 snapshot release, you can do just the zwave binding using the console as described here.
Excellent, thanks again!
I skimmed through the device you created and it looks good. I approved the change, so now it’s a matter of waiting for it to show up in the next build.
Awesome, thanks. I haven’t updated my binding to the 2.5 snapshot version yet so I need to start looking in to that next.
Sure thing. Just ask if you have any questions. The next version should be available in a few days.
Finally got around to getting the zwave binding updated to the 2.5 snapshot version. Got the new lock included and discovered in Paper UI just fine. I haven’t tested all the parameters and channels yet but basic functionality seems to be working great. Thanks again for all the help!
Does the new version report the lock states when manually operated? The BE469 requires the alarm_raw channel to figure this out. It’s also used to determine who’s code was used to lock/unlock. I suggest you remove the other alarm Channels and add this. Also, I expect all of your config params with a -1 value will not work or throw an error. The manual has negatives, but has to be an error. We’re talking bytes… no such thing as a negative byte.
Yes, the lock reports the state when manually operated. I was suspect of the -1’s as well but without any good documentation I didn’t know what else to put. What would you suggest, 255?
The endpoints are really just a SWAG on my part. I couldn’t find any documentation on how they should be configured so I copied them from the previous version of the lock where relevant. I’m no expert with this but I don’t see an alarm_raw in the nodeXML that was generated for the device. I do see the other four alarm types that were created though but can’t really see what usefulness they provide.
Take a look at the BE469. The parameters are very similar, if not identical, and have 0 and 1.
Remove the other Channels from the NOTIFICATION command class, and add alarm_raw, just like the BE469. I’m not sure you will have permissions though, so try and let me know. If you can’t do it, I’ll take care of it.
It’s great that Schlage finally realized that they needed to report the lock state! 
Ok, thanks Scott. I updated the parameters that had a -1 to match the BE469 model. I couldn’t figure out a way to remove the Channels though. The interface has the option to add or edit but not delete, am I missing something? Also, I added the alarm_raw Channel as you suggested but as soon as it updated it displays that the Channel is deprecated. Alarm (raw) [deprecated]
Yes… the permisions 
. I mentioned this may not be possible for you… I’ve removed them. Once you see what comes in with alarm_raw, you may find a use for breaking out one or more of them again. Easily put back.
There is a Deprecated checkbox on the edit page used to signify a duplicated Channel. You must have accidently ticked it. Gone now!
Cool, thanks for your help!
1 Like
So grabbed one of these and installed it. I can’t get it to register from the database to save my life. Seeing that several say these locks have to be nearly touching the zwave stick, I removed it and tried that. Also loaded zwave pc controller trying to remove the nodes (it somehow in my attempts got node 8-11 created) Still can’t get them removed. Anyways, it sits and doesn’t get any manufacturer information
I keep seeing this in the console:
17:12:08.473 [WARN ] [zwave.discovery.ZWaveDiscoveryService] - NODE 11: Device discovery could not resolve to a thingType! Manufacturer data not known.
Running a rather current binding version:
openhab> bundle:list |grep -i wave
283 x Active x 80 x 2.5.6.202005180339 x openHAB Add-ons :: Bundles :: ZWave Binding
Do you have the exact model number or link for your lock? The new ZP models being sold have some minor variations (i.e. 468ZP vs 469ZP) and may also need to be added to the zwave database.
Did you try inclusion via the new include/exclude button inside the lock or via keypad? I’ve used both, but keypad is more reliable for me.
For the removal part. If you run into a partial include and need to exclude the lock to start over again, you don’t need PC controller to remove the node. You can exclude from habmin and punch in the exclusion code on the keypad. At least that’s what worked for me.
I only did it with the button inside battery cover (from looking at the instructions). I didn’t even these could do that on the keypad. How did you do that? I’d give that a try. This one is model BE469ZP
When you exclude in habmin, where did you get the exclude code? I didn’t know you could do that via the keypad. Maybe that will make the difference. It keeps adding but increments up the nodes and how I have a gap. I kept trying that button from the manual to enroll.