Schlage Connect Thing Detector Busted

Have a Schlage Connect electronic lock. It’s detected by the Z-Wave stick as three things:
Node 3: Z-Wave Node 3: BE469 Touchscreen Deadbolt
Node 4: Z-Wave Node 4
Node 5: Z-Wave Node 5

… all showing as zwave:device:59841e71.

I Add any one of them and link whatever, and it pretends it works and is online. I change the setting User PIN to 6 digits, save, and it pops up Thing Updated, but then immediately “Error 500: Internal Server Error”. Still Online!

And it never shows up in Control. All my other Things show up and work. And this lock works great in Home Assistant. Key is set to the same as Home Assistant. What’s a nigga to do?

I’m assuming you are using OH 2.1, which doesn’t support Locks. The first few posts of the following thread will show you how to set up the test binding that does. Or you could wait, it may be merged into the nightly snapshot soon.

Thanks Mike. Yes the current stable OH 2.1.

For those unwilling to wade through the infinitely-long thread, here is the short version:

Installing the -secure- ZWave binding: 1. Delete all Zwave Things from Habmin. 2. Uninstall the Zwave binding from HABmin. - You will NOT reinstall it. 3. Stop OH2 4. Make sure zwave is -not- in /var/lib/openhab2/etc/org.openhab.addons.cfg 5. www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar Copy the JAR file to your /usr/share/openhab2/addons folder. 6. Start OH2. 7. Log into Karaf ie... ssh openhab@localhost -p 8101 password is habopen 8. Start the zwave binding with: bundle:start org.openhab.binding.zwave 9. If get an error, you need to install the serial binding first: feature:install openhab-transport-serial 10. Now got back to Habmin, and Readd a Zwave Controller. Do NOT re-install the 2.0 Zwave Binding. 11. Set your USB port and rescan for devices. 12. To check that zwave binding is running check on Karaf console with list. # ssh openhab@localhost -p 8101 password is habopen openhab> feature:install openhab-transport-serial openhab> list (and look for ZWave) 13. For discovery use HABmin as it will provide a popup if secure inclusion worked or not.

Unfortunately it didn’t work with my Schlage Connect lock. The ZWave binding now sees everything else automatically unlike before, like all my Leviton dimmers and switches, and Trane thermostats, but the three locks are unrecognized, even right next to the server. (Locks intentionally have a weak signal) I did a complete factory reset on two of the locks, and genned a new key for OH.

Maybe Nodes 3-5 are my locks:

.2017-07-03 10:14:27.946 [WARN ] [ome.core.thing.internal.ThingManager] - Initializing handler for thing 'zwave:device:4ac8b282:node11' takes more than 5000ms. 2017-07-03 10:16:56.501 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 3: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0 2017-07-03 10:16:56.501 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:4ac8b282:node3' to inbox. 2017-07-03 10:16:56.521 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 4: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0 2017-07-03 10:16:56.541 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:4ac8b282:node4' to inbox. 2017-07-03 10:16:56.544 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 5: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0 2017-07-03 10:16:56.547 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:4ac8b282:node5' to inbox. 2017-07-03 10:17:51.324 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error. 2017-07-03 10:17:51.337 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error. 2017-07-03 10:18:28.405 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 3: Remove failed node failed! 2017-07-03 10:18:28.433 [WARN ] [rialmessage.IsFailedNodeMessageClass] - NODE 3: Is currently marked as failed by the controller! 2017-07-03 10:19:35.533 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error. 2017-07-03 10:19:35.541 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 3: Remove failed node failed as node not found
That last entry, I tried to use HABmin to remove node 3 from the controller.

Examining the properties of nodes 3-5 they all show as zwave_class_specific SPECIFIC_TYPE_SECURE_KEYPAD_DOOR_LOCK

[code]zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_ENTRY_CONTROL
zwave_frequent true
zwave_neighbours 1,4,6,7,9,11,12
zwave_nodeid 3
zwave_version 0.0
zwave_listening false
zwave_routing true
zwave_beaming true
zwave_secure false
zwave_class_specific SPECIFIC_TYPE_SECURE_KEYPAD_DOOR_LOCK

zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_ENTRY_CONTROL
zwave_frequent false
zwave_neighbours 1,3,5
zwave_nodeid 4
zwave_version 0.0
zwave_listening true
zwave_routing true
zwave_beaming true
zwave_secure false
zwave_class_specific SPECIFIC_TYPE_SECURE_KEYPAD_DOOR_LOCK

zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_ENTRY_CONTROL
zwave_frequent false
zwave_neighbours 1,4,7
zwave_nodeid 5
zwave_version 0.0
zwave_listening true
zwave_routing true
zwave_beaming true
zwave_secure false
zwave_class_specific SPECIFIC_TYPE_SECURE_KEYPAD_DOOR_LOCK[/code]

Of course, now that you have the new binding, the Schlage detection is actually broken. I had to set up an OH1 install to pair it, then copy the key over to my OH2 install. As long as you are using a USB zwave stick it works.

I don’t understand. (This is not self-evident) I’ve read that version 2 is not version 1, and never the twian shall meet.

Why would a version 1 work to pair, when the headers in version 2 SNAPSHOT are completely different?

It’s actually the lock itself that does the state of the secure pairing by accepting the key from the controller. If you then take the USB zwave stick to another install, as long as you use the same key the pairing will be secure. Some people have used domotics to pair the Schlage Connect. The maintainer of the binding is working on it.

Oh man. So I’m out of luck for now. All three locks work perfectly in Home Assistant.

Gotta warn people against trying the new ‘security’ ZWave binding – nothing works. At least none of my Leviton dimmers and switches, Trane thermostats, nor Schlage door locks.

OpenHAB is non-functional now.

You need to delete all the zwave Things in paper UI and re add them when upgrading to the new binding.

I did that assiduously, as it says in my instructions #1 above.

Home Assistant controls everything I have flawlessly, including locks. I don’t understand why that .xml can not be used in OpenHAB2.

Report your issues and reproduction steps in the thread so Chris can take a look. The Schlage thing is a known issue that he is working on figuring out and more info is always helpful. If the locks work in HASS then you should just be able to plug the zstick in an OH2 machine, copy the key used in HASS to the OH2 zstick Thing and discover the lock Thing. But if your other devices aren’t working, it may be a configuration issue. There can be a problem with the online binding not uninstalling correctly and your OH2 install trying to run 2 bindings.

1 Like

pulling my hair out. I know this post is old but it’s the closes I can find to pairing a Schlage lock (BE469) with OpenHAB2 using a Aeon Gen5 ZStick.

How do you pair the zstick with the lock?

  1. Do I unplug the stick and pair it with the lock or
  2. Do I use openHAB2’s Inbox scan and while that scan is happening, do I put the lock in pair mode?

If I unplug the zstick and put it in pairing mode next to the door lock, it pairs up OK but then nothing works in openHAB2. I assume this has to do with the network key

NOTE: In openhab2, I have tried pairing with the lock using the zstick in network wide mode, high power mode, and low power mode and none of them work this way.

I’m confused as to whether or not openHAB2 puts the zstick in pairing mode when you go to the Inbox and scan for new devices. Specifically, I click on the Inbox, then the plus sign, I chose z-wave bindings, and while that searching graphic is shown I try to put the lock in pairing mode. This always fails. Yet I can’t find any documentation, not even on the openhab site, that explains this process in any amount of detail.

I wish someone would put the dots real close together as in a step-by-step how-to. I am so close to ditching openHAB and starting my own open source project. Restarting openHAB2 java takes several minutes on a raspberry pi which seems utterly ridiculous to me.

1 Like

I too am having trouble with my schlage lock. Is there any new developments here?

I just paired mine last night with some difficulty. “Eye of newt” solution:

  • Do NOT include using walk-around mode – keep z-stick inserted in Pi and use Paper (or Habmin) search for Z-wave devices
  • Put Paper/Habmin in Search mode and IMMEDIATELY put lock in pairing mode – you only have a few seconds to do this
  • The lock will include (INSECURELY) at a greater physical distance from the Pi-z-stick combo than it will include SECURELY. I literally moved my Pi-stick to about six feet from the lock to get it to include securely. (twenty-five feet and a wall away – no joy)
  • (N.B. if you get an INSECURE inclusion, be sure to delete it before retrying)

2.4 M7 Build

Has this continued to work for you? I had this unreliably working on openhab instance I had running on Windows, (Not work more often) Hoping to get more reliability on Raspberry Pi I moved my openhab setup to that. No problem with my other z-wave devices, but for the lock it doesn’t work at all now. It shows as online, but I do not get update from battery level nor am I able to lock it remotely. I tried a factory reset on th ock and re-enrolling, but no luck. Strange thing is openhab finds the lock in the Inbox before I initate the enroll on the lock (recently factory reset). I suspect something might be cached in openhab, but I don’t know how to start over.

I got it working again! The factory reset was not necessary. I previously attempted to unenroll using OH to no success.
What worked was:

  1. I took the z-wave stick physically to my lock and manually unenroll it (long press on z-stick button for a couple of seconds until it blinks yellow)
  2. plugged the stick back into the raspberry pi, and restarted.
  3. I verified the lock no longer appears in the openhabian Inbox.
  4. I then did the enrolling process on the lock and OH.

This time it works great! As I had hoped the lock is more reliable with the Raspberry Pi vs. my original Windows setup.

Z-Wave Stick: Aeotec Z-Stick Gen5
Openhabian v2.4.0

Just wrestled a second Schlage into submission.

“If at first you don’t succeed” voodoo formula for a reliable ground state between attempts:

  • delete lock from OH (paper UI or Habmin)
  • stop OH
  • sudo openhab-cli clean-cache
  • shutdown Pi
  • remove stick from Pi, take to lock and dis-enroll lock from stick as @Jason_H notes
  • reset the lock

retry enrollment as a new device with Pi (and stick) in close proximity to physical lock as per earlier note.

This thread is a lifesaver. I have been able to get one Schlage lock added, though there’s still some question for me as to what the undefined controller node is that’s associated with it. I’m assume it relays signals, but perhaps the discovery process just isn’t complete…

FWIW, in my case, I had to un-enroll the lock 3 times before it stopped showing up in PaperUI, per @bob_dickenson’s directions. It did, however, eventually give it up. One more to go… Thanks to the community on this one.