UPDATED August 22nd, 2015 (see below)
As promised elsewhere, here’s my device type for the Schlage touchscreen door lock/deadbolt.
This enables querying and setting the door alarm (off/alert/tamper/kick), door alarm sensitivity, and auto-lock modes. (There’s also support for lock/leave and vacation mode, but I don’t have them on the config panel yet.)
One thing about this lock is that it’s a SLOW device in z-wave terms. The turnaround time for sending a command and getting a response can be several seconds. So, if you are using this, you’ll notice that trying to change, for example, the alarm mode, will result in the tile going blank with the word “loading…” in it… and then it populating a few seconds later.
When changing the alarm MODE, the alarm sensitivity must be re-queried (as the lock has a different sensitivity for each alarm mode.) So, tap “alarm mode”, and it’ll take a good 10 seconds before both tiles are fully updated on the config panel.
The alarm sensitivity is implemented as a “Slider” control… which leads to some oddities. (The slider requires a range between 0 and 99. The sensitivity is a number between 1 and 5. I did some scaling…)
The “refresh” button will refresh the lock state, alarm mode, and sensitivity, but not any other new titles. If you have a tile showing “loading…” and you want a real value, tap the tile and it should refresh that config setting in a few seconds.
TODO:
pfft… read the code. Around line 523 you can see where the config values are parsed. Each of them can be implemented (but some don’t make sense, and others aren’t really useful.) You can see where I was testing the various config values if you just to the refresh command implementation (around line 834)
One other thing I’ve done here is to pass events with an “eventType” of “ALERT” in the case of important alarms. You know, like someone trying to break into your house, or a lock being jammed. The idea is that some smartApp can subscribe to those events (subscribe(door, “eventType”, evtHandler)) to push notifications. (I have it working on mine, but that code is embarrassing… )
This isn’t done by any means. It’s just the start of what I’m doing.
So, before you install this, remember that YOU are installing it. I’m not installing it on your stuff. If anything undesirable happens as a direct or indirect result of this stuff, you take FULL responsibility and won’t blame me in any way.
Pay attention to the licensing terms at the top of the file. I’m giving this stuff out freely - don’t return the favor by spitting in my face.
I’m testing and developing this with a Schlage touchscreen deadbolt. Most of the stuff won’t work with anything that isn’t Schlage. I dont’ even know if it would work with a non-touchscreen device. Let me know if it does.
So… how to plug it in…
Go to the github link above, and click the “raw” button (next to “blame” and “history”.) That’s the raw code that you want to copy.
Go to your ST dev account at ide.smartthings.com. Login (or create your account and login.)
Go to “my device types.”
Click the green button on the right that says “New SmartDevice.” (I know someone at ST is going to change the layout of the website now… just to make me edit this.)
Click on “From Code.”
PASTE the stuff you copied from my github account (the raw code!) into this big empty text editor, and then click “Create”
Now you can “save”, and “publish”->“For Me”
Now, all you need to do is go to “my devices”, click on your existing z-wave door lock, click “edit”, and change the device type to this new “z-wave schlage touchscreen lock”.
After that, you might have to kill and restart the mobile app for the changes to be visible.
Update: 2015-02-02 : changed state values to prevent UI confusion. (Previously, when setting one item to ‘unknown’, the UI might show ALL the items as ‘unknown’.) Also added beeper toggle.
Update: 2015-03-07: Just in time for DST! When the lock gets locked/unlocked manually, automatically, or from the keypad (with no keycode - such as locking via the schlage button), include information in the usedCode data indicating the source of the event. The only time this won’t be populated is when the locking/unlocking from a z-wave command.
Update 2015-08-22: I merged all the changes from the ST “z-wave lock” device type back into this device type. This seems to add a couple bug fixes as well as changes to security related stuff. The device type is also mostly compatible with Erik Thayer’s “lock code manager” smart app. (However, there are a few change requests I’ve made to Erik that would make the compatibility a bit better.)