I just received a new BE469ZP Schlage lock an attempting to get it working in openHAB, This is a newer version of the BE469 that has some additional functionality and also uses Z-Wave Plus. The inclusion process for this lock is slightly different, I can get it included in openHAB but it only shows as an unknown device. I’m currently running openHAB 2.4 and using the Z-Wave 2.4 stable binding. I’m wondering if I need to migrate to the 2.4 snapshot binding or if the database needs to be updated with the binding info for this newer device? Thanks!
Did a node.xml file get produced in the userdata/zwave directory. If so, please post the manufacturer, deviceType, deviceId, and version from that file. We will use that to see if the device is in the database.
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.
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.
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.
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!
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
. 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.