[Depricated] Lock Code Manager

I don’t understand. Did you change your input type to ‘text’ by any chance?

Somehow, you were able to set one or more of your codes to a String(text) variable type instead of an Integer(‘number’) type. I’m not able to get this error to pop unless I royally mess up the settings and set the code to a string. Do you have an older android phone? Maybe a custom keyboard?

I might change the code input type to string so I can test support for codes with leading zeros… this should fix your issue, though I’m not sure how you managed to get that in as a string!

As far as missing codes, My tests have all come back to work. I just tried sending 5 codes to my 3 doors and all 15 worked. It’s disappointing to hear that it doesn’t always work in your case, but it may have to do with that pesky string variable you ended up with.

And I’m not even sure how to check for variable types within ST. I tried getClass and class but looks like those methods are blocked.

Thank you so much! I should have thought of this in the first place. This is a great app and I really appreciate your quick response in helping me.

Thanks again.

1 Like

It is the keyboard, I have an iphone and the swype keyboard, when I switched to the standard keyboard the problem disappeared, with the swype keyboard, when I try to enter the numbers, I don’t get the numeric phone keys that I get with the standard keyboard, Instead I get the normal alphanumeric keys and I have to switch to numbers manually, that’s why it is treated as strings then.
May be you need to forcibly transform the entry to integer to cater for all keyboards, thanks

Unfortunately that’s a little outside of the scope that ST allows developers to do. The thing is, the command actually requires a string variable type as opposed to an integer. I can’t safely detect what type the variable is before sending it to a convert method.

I’m actually converting the integer to a string before sending it to the setCode method. The reason I choose to do it this way is because the code entry being alphanumeric for must keyboards is a major convenience for me, and I thought for most people.

I’ll look into changing the entry to a string. We may be able to get leading zeros to work this way too.

I thought that I could support both strings and integer, but ST groovy doesn’t allow getClass methods. Not sure why.

This sounds like some great work. Would love to see compatibility expanded to include Schlage. Have the touch screen deadbolt and really like the aesthetic/functionality. The features you’ve implemented here are the dream. Excellent contribution in any case.

1 Like

Thanks Joe!

Bummer it doesn’t work.

Locks that typically support the 30 user codes and 4-8 digits seem to be supported. Not sure, maybe those all use the same specs for code transmission.

Anything else other than that configuration doesn’t seem to be supported by SmartThings at this time. Not sure why. Perhaps a brilliant mind with one of these 19 slot 4 pin systems can come up with a custom device type that would support it.

The Camelot Style Schlage Connect looks like it should work with SmartThings but I haven’t seen anyone say it does, so I have’t added it to the list…

##Another large update!##

In order to support leading zeros, I had to change the code input field to a string. If you’re updating from version 1, you must either re-save all of the code fields or start over fresh. this should also assist people with custom keyboards.

I removed the need for a push button to activate the app. The app now activates on save, and respects all schedules.

More robust scheduler.

Now with an enabled toggle so that you may disable a user without deleting their code from the app.

This update was large, so let me know if you run into any issues. Especially with the scheduler.

If you notice that a code did not get sent correctly, enter the app settings and click ‘done’ to initialize.

Awesome! This is getting better and better! I have three more ideas for this…

  • Ability to not run the hello home actions when certain presence sensors are present. We leave our doors locked most of the time, even when we are home. So, no reason to run the hello home action if we are already there! Also, if we manually unlock from the inside, wouldn’t that trigger a hello home action?

  • This seems like the harder one - add the ability for codes to trigger specific actions? Perhaps set it up so a code either triggers the default hello home action or it can be overridden to trigger a specific action. For example, a code assigned to home sitters or cleaners might trigger a different action. The same would apply for a manual (keyed) unlock - perhaps that would indicate this is someone that is different.

  • To take it even a step further, different schedules based on user code. Same as above - either apply the default schedule or apply a custom (or no) schedule to a specific code.

I really like the interface to this app.

@ethayer Thanks for the App; Though plenty of ideas for additional functionality I like that it does 1 function as described. For me that is all I wanted.

I confirm the Camelot Style Schlage Connect (BE469NXCAM716) does work. Though the lock does support 30 codes I recommend limiting the app to the # you expect to realistically use. When the app does execute it will report “Send Deletecode Command to Door” for each pin that is empty leaving the activity log filled with up to 30 of these commands.

A question @ethayer What is the difference in the log between Code X was Added vs Code X was Set? This may be specific to my lock but not sure.

An idea that would be nice is to make the access to the “user settings” password enabled. Though unlikely anyone that gets ahold of my phone can see the codes from this view.

I will let you know if I run into any bugs as I have used it for longer periods.


Awesome feedback, thanks!

  • a. Ability to not run hello home when particular presence sensors are home - Doable!, I’ll look into this.
    b. Manually turn from the inside to not run hello home- Not possible. The lock does not physically know the difference, and does not report if a KEY was used, or if a manual turn from the inside happened.

  • I can separate hello home actions for specific users. I’ll look into this.

  • Unfortunately I can’t make multiple schedules. ST limits each app install to four(4) schedule calls. While I’m only using two, theoretically the other two could be used as a buffer in case unschedule doesn’t run in time for the actual schedule to be set. The solution would be to use multiple instances of the app if you require more than one schedule. Sorry! I can probably add a toggle to users so that they don’t respect the schedule and are a kind of an ALWAYS ON user. I can look into that in a later version.

This is completely right, and that’s the way I intended it to be used. The number you enter in the users screen should only be the number of users you’re using, not the total number of users your lock supports. I could have possibly worded the prompts to make that more apparent.

This is great to point out! Yes, the password page would be completely open. I would suggest keeping a password on your smart device to protect it from even the SmartThings app itself. I have a password on all of my devices, so this isn’t as large as a concern for me.

I may be able to accomplish a hacky way to protect a page, not really supported by ST and not 100% compliment, but kind of a child’s password lock to the users page. I’ll look into it for the next version.

Thanks again for the feedback! I appreciate you using, and testing, my app.

Or at least this is the case for my kwikset lock. Maybe other locks report this event in a more meaningful manner. I don’t have one of those locks, so I wouldn’t feel comfortable writing this into the app without being able to test it locally, and gracefully fallback for those locks that don’t support this report… if it exists in the first place.

That’s fine. The manual unlock from the inside would be solved by the presence sensors being added. Also, just having that different action for keyed/manual unlock would be great as well for the reasons I stated before.

BTW - I love the icon. Stands out nicely!

Hi Erik
When I enter 5 users, users 1, 3 and 5 only gets updated, while users 2 and 4 are skipped.
When I enter 3 users, users 1 and 3 only gets updated and user 2 is skipped.
I have the Yale lock, may be it needs some time to process the command, a delay between commands may solve this.

Hi, Erik,

Fantastic app!! I’ve been using it for almost a week now, both v1.2 and v2 with a Kwikset 914 and a 910. Version 1.2 was a little wonky with firing the scheduled start and stop times, but v2 is FLAWLESS, at least so far. I also really love the added ability to start a user code with zeroes, since I run vacation rentals and I often use the last four of a guest’s cell and often that number starts with a zero. I also really appreciate the “dial” for start/stop times; I’ve been dreaming of an app that could set code expiry since I started with ST a few years ago. There are some really cool apps that can manage door codes, and I’ve used and use a few of them, but with your Lock Manager I think I’ve found the Grail!

So, a few questions on use, if you don’t mind:

Suppose I need to set a door code to allow access at 4pm on a Thursday, and to then deny/wipe access/code at 12pm noon the following Sunday, how would I go about setting up the app for a code to last over several days? I’ve managed to make this scenario work with v2 by installing two separate installs of the app; one for granting access, and one for denying access; I set the access install with day of week, time, user name, user slot, code, enabled, and then I set the second install with the deny day of week, time, the same user name, same slot, code left blank to burn, enabled. Whew! But so far, it works perfectly! Start was on the minute, and so was Deny. I can work with this, but is there a way to combine functionality of the two app installs into one? Believe me, not complaining … just explaining! I realize that you’d have to implement some sort of calendar functionality, date and time, but it would make this app Magic! Even if only at a week at a time!

Thank you for this wonderful app! Can’t wait to see what you do with it, and so should ST, just saying.


1 Like

That’s Awesome,

Part of the reason I moved from v1.2 to v2, was because inputs in v1 would be incompatible with v2. Also, I spent almost an entire day re-factoring the code for the scheduler and UI, so I thought that warranted a bump. Glad the bugs got worked out!

I’ll put that into my TODO list and see if it’s possible! I think it should be.

Schlage FE599 not working properly yet. New codes “take” intermittently when updated. Timing issue?

@ethayer thanks for your work on this. Great to see progress with lock codes on this platform.

Same problem as Kevin here but with Kwikset 914 locks. Using only the latest code version v2, I had all sorts of problems. Codes not taking on any given lock. Did several deletes and reset. Finally got it to take on 3 of 4 locks. Each time a different lock wouldn’t take. Finally a 4th lock keyboard started blinking red for many seconds and lost all codes. Ultimately I uninstalled the app. It left the codes on 3 locks that took, I had to manually reprogram the 4th lock.

In tests, it would fail on different locks at different times. Couldn’t get all 4 to update together. And when I tried only one lock, still had to try a few times with one of the codes often failing to take. Unlike what someone else posted, my experience was that the app slot 1 overwrites the pre-programmed slot 1 for example.

Also, on Android, I had to change the “required = true” for user setting page within the smartapp. It prevented me from getting “Done” to go through on the parent page. I checked the logs and the command to change codes did go to the locks in all cases, they just didn’t stick within the lock memory intermittently. So the changing “required = true” to false is not what caused the inconsistency.

The locks that failed to take would sometimes log some extra payload data and occasional Java exception errors. Hope that helps.

Can you post the Java error?

Sorry it was last night and I didn’t save log output. It may have been same/similar as Nagui_Anis posted above. I won’t have a chance to test again for about a week.

Just to confirm, I am using default ST device type “Z-Wave Lock”

Here is the log, as you can see, setcode sent for the 5 users but only 1,3 and 5 got a codechange

09118c68-c292-41ad-9a60-f235e3e8eb4f 12:58:24 PM: debug "zw device: 02, command: 9881, payload: 00 63 03 05 01 36 32 37 37 " parsed to [[‘name’:‘codeReport’, ‘value’:5, ‘data’:[‘code’:‘6277’], ‘descriptionText’:Floor 1 Lock code 5 is set, ‘displayed’:true, ‘isStateChange’:false, ‘linkText’:‘Floor 1 Lock’]]
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:58:24 PM: debug code report parsed to [[‘name’:‘codeReport’, ‘value’:5, ‘data’:[‘code’:‘6277’], ‘descriptionText’:Floor 1 Lock code 5 is set, ‘displayed’:true, ‘isStateChange’:false, ‘linkText’:‘Floor 1 Lock’]]
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:58:15 PM: debug "zw device: 02, command: 9881, payload: 00 63 03 05 01 36 32 37 37 " parsed to [[‘name’:‘codeReport’, ‘value’:5, ‘data’:[‘code’:‘6277’], ‘descriptionText’:Floor 1 Lock code 5 is set, ‘displayed’:true, ‘isStateChange’:false, ‘linkText’:‘Floor 1 Lock’]]
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:58:15 PM: debug code report parsed to [[‘name’:‘codeReport’, ‘value’:5, ‘data’:[‘code’:‘6277’], ‘descriptionText’:Floor 1 Lock code 5 is set, ‘displayed’:true, ‘isStateChange’:false, ‘linkText’:‘Floor 1 Lock’]]
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:58:06 PM: debug "zw device: 02, command: 9881, payload: 00 63 03 03 01 39 39 38 38 " parsed to [[‘name’:‘codeReport’, ‘value’:3, ‘data’:[‘code’:‘9988’], ‘descriptionText’:Floor 1 Lock code 3 is set, ‘displayed’:true, ‘isStateChange’:false, ‘linkText’:‘Floor 1 Lock’]]
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:58:06 PM: debug code report parsed to [[‘name’:‘codeReport’, ‘value’:3, ‘data’:[‘code’:‘9988’], ‘descriptionText’:Floor 1 Lock code 3 is set, ‘displayed’:true, ‘isStateChange’:false, ‘linkText’:‘Floor 1 Lock’]]
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:57:56 PM: debug "zw device: 02, command: 9881, payload: 00 63 03 01 01 37 31 39 35 36 " parsed to [[‘name’:‘codeReport’, ‘value’:1, ‘data’:[‘code’:‘71956’], ‘descriptionText’:Floor 1 Lock code 1 is set, ‘displayed’:true, ‘isStateChange’:false, ‘linkText’:‘Floor 1 Lock’]]
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:57:56 PM: debug code report parsed to [[‘name’:‘codeReport’, ‘value’:1, ‘data’:[‘code’:‘71956’], ‘descriptionText’:Floor 1 Lock code 1 is set, ‘displayed’:true, ‘isStateChange’:false, ‘linkText’:‘Floor 1 Lock’]]
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:57:46 PM: debug "zw device: 02, command: 9881, payload: 00 71 05 70 05 " parsed to [[‘name’:‘codeChanged’, ‘value’:5, ‘descriptionText’:Floor 1 Lock code 5 changed, ‘displayed’:true, ‘isStateChange’:true, ‘linkText’:‘Floor 1 Lock’], 988100630205]
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:57:37 PM: debug "zw device: 02, command: 9881, payload: 00 71 05 70 03 " parsed to [[‘name’:‘codeChanged’, ‘value’:3, ‘descriptionText’:Floor 1 Lock code 3 changed, ‘displayed’:true, ‘isStateChange’:true, ‘linkText’:‘Floor 1 Lock’], 988100630203]
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:57:28 PM: debug "zw device: 02, command: 9881, payload: 00 71 05 70 01 " parsed to [[‘name’:‘codeChanged’, ‘value’:1, ‘descriptionText’:Floor 1 Lock code 1 changed, ‘displayed’:true, ‘isStateChange’:true, ‘linkText’:‘Floor 1 Lock’], 988100630201]
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:57:22 PM: debug setting code 5 to 6277
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:57:22 PM: debug setting code 4 to 3570
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:57:22 PM: debug setting code 3 to 9988
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:57:22 PM: debug setting code 2 to 1956
09118c68-c292-41ad-9a60-f235e3e8eb4f 12:57:22 PM: debug setting code 1 to 71956