(Enhanced) Z-Wave Schlage Touchscreen Lock

  1. Open “New Device Type” in dev page
  2. Copy code from github
  3. Pasted to New Device Type
  4. Saved -> that created new device type “Z-Wave Schlage Touchscreen Lock”.
  5. Published -> For Me … successfully
  6. Removed lock from Things, re-added it as new “Z-Wave Schlage Touchscreen Lock” type. so far so good…
  7. App shows green “Locked”… pushed the green “Locked” button, lock responds almost immediately, opens, and icon (tile) changes to grey “Unlocking”… thats it… it would not change state to “Unlocked” or respond to any other commands.

Sorry, i do not have live log, as I actually need it working, so I moved it back to default Z-Wave Lock driver that finds this lock by default. Lock responds almost immediately to that driver, open/close/battery… though unfortunately no other fancy details. I am ok for testing though, if you need that live log I would be able to re-create device driver and test next week. If you want to take it off-line, may be that would be easier to communicate… and again thank you so much for your work and support.

I’ve tried, but I’m unable to repeat your issue. I’m not even sure how things could have gone wrong, as the basic code for lock/unlock is nearly identical to the ST device type. If you can capture live logging of some breakage, I’ll be happy to look into it.

Take care

@garyd9, is this something you can add to your device type to enable communication with the Smart Alarm app when the lock senses tampering or forced entry?

I can, but I probably won’t. It’s a hack that I’m uncomfortable with.

I’ve been trying to get ST to add a standard mechanism to “alert” for critical events for more months than I can count. There’s been several discussions, suggestions, and everything seems to get completely ignored by ST in the end.

To be quite honest, I’m tired of banging my head against a brick wall.

Unless ST takes an interest in their own product (and visibly demonstrates that interest), I’m pretty much done trying to work around and force their system to do sensible things.

Oh, and adding @April. Perhaps she can get someone to look into this again.


@garyd9 I’m also fedup with ST, their platform is going from bad to worse. Not to jump the topic but when basic features don’t work (last few days the event filtering is no longer working, see this thread below) I don’t see how they can devote time to any new stuff.

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.)

Erik’s FREE lock code manager: [Depricated] Lock Code Manager

Current incompatibilities with that lock code manager:

1: When the Schlage lock is queried what user codes it has stored, it will only respond with asterisks for used slots. (Most likely a security measure from Schlage.) This only matters if the device type doesn’t already have the user codes cached (which it normally does.) This will cause Erik’s lock code manager to re-send the usercodes. No real impact here.

2: Erik’s code is designed to work with Kwikset locks which allow different user code slots to have different lock code lengths. For example, slot 1 might have a 6 digit code while slot 2 has a 5 digit code. With the Schlage locks, all the slots must use the same length, and that length must be configured on the lock ahead of time. (I can change the length in code, but the command for changing the length erases ALL existing user codes, so I don’t expose that to a user. My opinion is that it’s better to make the user perform that manually so they understand it’s destructive and don’t blame me.)

3: As of this message, Erik’s lock code manager will spit out errors in the IDE “live logging” when a user manually locks/unlocks the door. These errors are harmless and have NO impact. (As well, they’ll likely be going away in a day or two of this post.)


Hi Gary - so is it now Erik’s lock code manager (the link you published) that we should try with the Schlage Camelot touchpad lock? There are so many posts going back a long time on this, but this appears to be the latest and greatest, or whatever device you merged all this into. Thanks in advance, I haven’t tried anything with the lock other than the native ST device, but need remote pin control for a distance house. Thanks!

Yes, right now I’d suggest using @ethayer’s lock code manager with this device type (if you want any lock manager at all.) It’s a bit more robust than any other I’ve played with. There are a couple of issues that I’ve noted. As of right now, Erik hasn’t updated it, but issues that need an update are (in my opinion) minor issues that really don’t impact the use of the manager.

Take care

OK great, thank you. ST still has no official solution it seems, surprising


FYI - I just had the battery on my touchscreen lock jump from 70% to 0%. I’m posting this so that if someone see’s the battery level on their lock go to 70%, they can have fresh batteries ready to go…

Take care

1 Like

@garyd9 - Just installed the device type tonight, (Android App 2.0 + Hub 2.0) and the text on the secondary tiles is misaligned (too low, the second row falls off the bottom of the tile) Is there anything that will fix that or is it an issue with multiple lines of text on the buttons in Android?

Hi! Fairly new to setting up all this, but have been very happy with my new ST2 hub, and its use with my Schlage Deadbolt (keypad, motorized deadbolt)… I have Erik’s code manager installed as well, which is working well also, but I have one issue when trying to set sensitivity in Alarm_tamper mode. I get the following error: “Backdoor Deadbolt unable to set alarm sensitivity while alarm mode in unknown state” Any suggestions, or info I can provide to help resolve?


[quote=“Toasty, post:46, topic:10034, full:true”]
the text on the secondary tiles is misaligned (too low, the second row falls off the bottom of the tile) Is there anything that will fix that or is it an issue with multiple lines of text on the buttons in Android?
[/quote]I don’t see any problem with my android device:

On the other hand, if lines end up wrapping, it probably does look wonky… There isn’t much I can do about that. I supply the text and ST’s android app renders it.

[quote=“Andrew_W, post:47, topic:10034”]
I have one issue when trying to set sensitivity in Alarm_tamper mode. I get the following error: “Backdoor Deadbolt unable to set alarm sensitivity while alarm mode in unknown state”
[/quote]Take a look at the screenshot I posted immediately previous to this reply. See the tile with speaker icon and the text “kick alarm”? On your device, is that showing as a question mark? If so, tap the icon and wait a few seconds. It should (eventually) update to show which type of alarm is active. Once the device type has that info, you’ll be able to adjust the sensitivity of it.

I got it figured out. When you first load this device type, and the Alarm Mode, Auto Lock and Lock & Leave have not been pushed, the labels are followed by “Loading” but the font size is increased for all of the label on the button, and lower on the button. Pressing each one so that it communicates with the lock gets the label right, but the button icon was not rendering in the right location, it was still lower than where it should be, and the text label was getting cut off by the white ring around the button. Closed out of the device and went back in, and it’s showing up like it’s supposed to now.

Any future plans to change it’s layout to the new 2.0 style? Not super important, just curious!

I’ve considered it, but I’m in the “Keep It Simple, Stupid” camp. I didn’t see anything in the new layout that would enhance the functionality or make it easier to use. There might be some things coming up that I could make use of, but I want to wait until I’m sure that they are going to keep working before I mess with the device type. I’m kind of paranoid about my door lock not working anymore because I got fancy with a device type UI.

I hear ya. KISS is good advice, always. I just sometimes have a bit of OCD and one of my device types appearing different than the others triggers it! ROFL :smiley:

[quote=“garyd9, post:49, topic:10034, full:true”]

The button shows (and showed) “Tamper Alarm” in green, pressing it yesterday changed to “Alarm Mode Loading” which stayed that way (did not load). Exiting the application and returning, “Tamper Mode” again showed in green, and sensitivity changed to 0. Yesterday, pressing the “locked” button, or the “unlock” button did not unlock the deadbolt either…

Today, pressing it changes through the modes as it should (albeit very slowly), but once I am back to “Tamper Alarm”, setting sensitivity does not do anything… Though now it is “stuck” at 0 instead of 50, my goal was to set it to 25 for less sensitivity.

I’m not really sure what’s up, I’ll try again later today.

[quote=“Andrew_W, post:53, topic:10034”]
I’m not really sure what’s up, I’ll try again later today.
[/quote]This sounds like an issue I had around the time I changed over to v2. In my case, the device type just stopped working properly for anything. There was no reason whatsoever for it. What I had to do was kind of brutal, but nothing else worked (and this stumped the ST support folks as well.)

Change your lock back to the basic z-wave lock device type. Then DELETE the custom device type. Completely. Then re-create it from git source. Save the newly created device type and reset your lock to use the custom device type.

I know that this sounds like some support script jockey telling you to unplug and re-plug in your computer. It’s not. I had an experience VERY similar to yours when I switched to v2 and had to completely recreate the device type to resolve it.

(Actually, those aren’t the exact steps I followed. For me, I had two different device types… one a recreation of the old… identical code. One worked and one didn’t. I left both intact in my account for a few days while asking ST to look at them and try to understand why one worked and one didn’t. They couldn’t figure it out. My best guess is that some times, a device type goes wonky in ST. It probably doesn’t help that the schlage lock type is more extensive than most device types.)

So how much does this enhanced code cost? It looks like $10 on the website. Do people feel the upgrade is worth the price?