I’m having trouble getting my Yale Touchscreen Lock to pair with OpenHAB2 and could use some pointers.
The documentation on this references using HABmin to do the secure join. However it seems this is no longer in HABmin 2 and pairing is instead handled by the discovery process. Does item discovery handle the secure inclusion or is there another method to do this?
Whenever I pair it currently, it just comes up as an unknown item.
You might check this thread and if you don’t get a good response here post your question to that thread. Lock support is in development and I’m not sure it is complete or reliable yet.
Hi Jeremy, the zwave binding will put the serial controller into inclusion
mode anytime you ask it to discover devices. So in the paper UI this is
clicking the big plus button in the inbox and selecting zwave, or the
little search/magnify glass button in Habmin. Once it is in discovery
mode, go and click the include button on your lock. Couple things, first
make sure the controller is really close to your lock when you include it (
mine was inches), also make sure the lock is not included in another
network (clear it first), finally it can take anywhere from 1 to 5 minutes
for the key exchange to finish so leave it alone until you see something
about it being done (check the thread mentioned above). I have two locks
paired, works great.
Thanks for the help. I believe I’ve tried all the steps outlined above and in the various documentation.
I’ve tried one more time just to be certain. While getting a little further, can’t get OH2 to recognize it as a lock in the UI. I’m assuming this lock is in the OH2 Z-Wave database? Or perhaps that’s the issue I’m running into?
I’m using OH2 Beta 2 on a RPI 2. Zwave is through an Aeron Labs Z-Stick Gen 5. Lock is a Yale Real Living Touchscreen
Steps taken
0. Excluded lock using Open Zwave Control Panel
The logs are fairly long so I’ve linked them here (I hope that’s ok): http://pastebin.com/3esjBwt8
Fundimentally, it looks ok. The device included and completed all the security steps -:
NODE 9: Secure inclusion complete, continuing with inclusion
I think the main (maybe only) issue is that the device isn’t in the database -:
NODE 9: Device could not be resolved to a thingType! 0129:0002:AA00::33.32
You should find an XML file in /userdata/zwave/node9.xml. We need to get this into the database…
Thanks Chris. I realize I made a mistake in not checking the database to verify if the lock was even listed. Thanks for helping a newcomer.
I have node9.xml available (http://pastebin.com/PKzutqgp) and happy to add it to the database. I created account, but looks like perhaps I don’t have permission to submit? I don’t see the add button listed in the instructions.
I’ve updated this, so you should be good to go… Any problems, let me know…
I loaded your XML already since I wanted to make sure it worked ok as it’s one of the first secure devices since I added support for this… It’s created this device and it would be great if you could at least give it a name 
- and add anything else (manuals etc would be good).
Great. I’ve updated the device details, filled in what I could, and uploaded a manual.
Another beginner question (and hopefully my last) what steps are next to get my instance to recognize the new database? I see I can generate an xml file for OH2, but am unsure where it goes? And to I need to do a full re-inclusion?
I’ll need to update the binding. So, if you want to compile a version yourself, then you can take the file from the website - otherwise you’ll need to wait for the next release. It might not be tonight though as I need to run some more tests before I push another change…
This should be in tomorrows binding…
Perfect – Thanks for the update.
When the updated binding is released where does it go? /addons? or /runtime/karaf/system/org/openhab/binding/org.openhab.binding.zwave/2.0.0-SNAPSHOT?
I tried compiling via MVN and placing the new jar file in both locations and it didn’t seem to pick it up the new device. I didn’t do an exclude/include. Just delete thing and re-add. Am I missing a step?
Is there documentation I should reference on this? If it doesn’t existing, happy to write something up for other beginners.
If you are compiling a new jar, you will want to put it in the addons directory. Note that the other version may still be cached in maven though when you start up.
Run these steps at the openhab console to clear it out:
bundle:list|grep -i zwave
If this shows only one bundle (binding) you should be good to go. If there are two (or more), keep going. Each bundle has a bundle ID, which is a sequential number of the order they were loaded. This ID is the number you can use to control them.
bundle:stop ID
where ID is the bundle ID of the older bundle that you want to remove.
bundle:uninstall ID
At this point, I would recommend a restart. You should be able to just do the uninstall without the stop, but I have found it works better to stop the binding before removing it. If you do not it hangs some times. The restart of openHAB is just to make sure everything is cleaned up and only elements of the new jar are used.
If you are waiting for the new binding in the normal SNAPSHOT, that build can be downloaded after it is built. The build kicks off in about 1/2 hour as I am writing this. You can watch its progress here: Cloudbees Jenkins
You can either grab the jar out of the artifacts of the openHAB2-addons project, or re-install the whole of OH2. If you do the re-install, I would recommend cleaning up the maven cache and downloads to ensure you are using the new stuff. I wrote a script that I try to keep up to date to help with that. You can view/fork/download/hack/point/whatever here: OpenHAB2-Tools
Hope that helps
Perfect – I used the script and am now up and running. For some reason compiling my own bundle didn’t work (it finally recognized the lock, but none of the commands worked).
So now that I’ve been playing with it, I’ve noticed an issue that perhaps is specific to these locks.
OH2 doesn’t get lock status updates. Other sources online indicate that the Yale locks uses an alarm notice to report a lock change instead of the “correct” method. When that lock states change, entries such as the following show up in the log:
NODE 9: Device message contained nonce that is unknown to us, id=0x05, table={}, expiredList=[], usedList=[-67, 99, -78, -126, -30, 0, 104]
NODE 9: Unknown Alarm Type = 24, ignoring report.
NODE 9: Timed out waiting on response for encapsulated message Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=9, payload=09 17 98 81 08 B7 5D CA BC 56 22 44 FD 91 7F 40 BB 51 9B B7 33 C0 BB 12 AD encapsulates: Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=9, payload=09 03 62 01 FF
NODE 9: Unknown Alarm Type = 22, ignoring report.
2016-03-27 03:58:11.981 [ERROR] [col.security.ZWaveSecureNonceTracker] - NODE 9: Device message contained nonce that is unknown to us, id=0xFE, table={}, expiredList=[], usedList=[-118, -88, -87, -21, -115, -56, 26, 74, -29, -123]
I see other alarm types such as 21 (Lock?), 22 (Unlocked?), 24 (??), and 25 (??).
Should I open an issue on GitHub?
The alarms need updating both in the binding and database - feel free to open an issue.
@chris - I’ve managed to find an online reference for all the device alarm types. Does this get added to the Z-Wave Database? I saw the alarms section of the command classes, but wasn’t sure how to enter it in using the fields provided. For example, alarm type 112 is Code Changed and the Alarm Level indicates which code was changed.
I’ve updated the binding already to include the extra alarms, but there’s a bit more to it than just adding the alarms… I need to have a think about how to add these - probably we’ll add separate channels for each alarm, but there’s potentially a lot, so it needs a bit of thought…
I’ve also implemented the lock logging command class today (untested)… There’s still a bit to do with the security classes 
.
I’m working on pairing several of these. The first one came up as “unknown” but the second one paired correctly, so I deleted my post asking about the first one. I’ll exclude it and re-pair and post better logs if I run into more trouble. Let me know if there’s any specific testing that would help with these locks – I have three of them and when using SmartThings, one was mostly reliable and one was mostly unreliable, despite appropriate use of range extenders.
@mishakim Glad you got it working. I too had an issue where even once the device was in the database it came up as unknown. Re-pairing did the trick.
I think the biggest issue is what was mentioned previously in the thread. Since OpenHAB doesn’t see the current state you can’t do to much with it. Seems like it’s a complex change to support it.
I paired the third lock with no trouble, then tried again with the first one. It took a few tries to get it to exclude at all, and then to pair, but eventually did. It again came up unknown, with this:
2016-04-09 12:25:23.911 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 12: Device could not be resolved to a thingType! 0129:0002:0000::33.32
after I rescanned the inbox. Comparing the logs of the pairing process, it looks exactly the same as the ones that worked (but I don’t have debug on).
Comparing the .xml, I see the problem: the one that isn’t working has deviceId 0x0, while the two that are working is 0xaa00. Tried excluding and re-including, didn’t help. Tried changing that manually, which didn’t work (not that I really expected it to)
Never mind - went to PaperUI in a different browser (was using Chrome), and it did have the correct name. Added as thing, assigned channels, and it works.
Not sure what you mean by this - for the two that work (until I moved one of them back to it’s location too far from the controller), I accurately got lock state, and I get battery state for the one that’s still in-range.
When I lock/unlock it from the device itself, that change is not registered in OpenHAB (perhaps it eventually would, but I haven’t monitored it closely). Instead of sending a lock state change, this model lock sends an alarm condition which I can see in the logs is instantly is sent. OpenHAB just doesn’t know what to do with that info.
If you unlock it from the handset, are you seeing that change reflected in OpenHAB right away?