[RELEASE] Lock User Management (LUM)

@gjanes this would be a very cool idea as well. I agree, adding a very complex feature into what is already a large smartapp in ST might be overdoing it.

I was so pleased with the performance of my front door lock in conjunction with this @RBoy Door Lock User Code Management I got a second. I just installed a second BE469 Schlage lock and the smartapp did a flawless job in programming the codes. All I did was add the new lock and smile as I watched the Notifications just start rolling in showing each step it was taking to setup the codes. The third code got hung up and it just continued on with the remaining codes. It then went back and retried code three which was then successful. Nice app @RBoy


Is anyone successfully using the disarm Home Monitor Security feature within the smartapp? ST seems to always run the intrusion before the disarm is activated, even if the notifications say otherwise. I even have it set to turn off the Sirens at the same time but again the ST intrusion seems to take priority. Any suggestions? The only way I seem to be able to disarm the security is to use my phone as part of the I’m back settings to disable before I even get to the door.

I’m familiar with the auto-relock function, but is it possible to program this app (or another) to automatically re-unlock the door lock between certain times? We use connected door locks for our commercial locations and customers often tend to accidentally press the lock but while closing the door behind them.

There’s already an option to retract the deadbolt (unlock) the door if the door is locked while it’s still open (you need a sensor for it)

I do this. It drove me nuts that SmartThings Smart Home Monitor appdoesn’t come with basic Exit/Entry delays on configurable zones.

I ended up switching to @geko SmartAlarms which can do that easily and works well with Door lock user code management so when I enter in a successful code it executes “I’m Back!” I also use @kevintierney New Zigbee Device (Securifi Key Fob) and programmed in the buttons to be able to Arm/Disarm the system from outside the house and that works well too if you want to keep SHM. I am still playing with both but so far the Key fob is more of a backup because the family likes just entering the code at the door lock.

Is there a option to disable reverifciation my lock keep on doing it and won’t stop it’s getting annoying. I don’t need. It to reverify code can you add that option to disable it. It say optional but I don’t see where I can disable it.

Make sure you’re using the latest version of the app Version 4.1.1
First page at the bottom:

Enable incremental updates only and disable re-verification

@RBoy I keep seeing in my messages “Requesting Front Door Lock to delete expired user 3 because it is scheduled to work between Tuesday 9am EST to 17:00 EST”. It’s been happening I believe since your 4.0 or 4.1 update. I updated to 4.1.1 and enabled incremental updates only and disable re-verification and I still see these messages. They seem to happen every 5 minutes or so on all of my locks.

In the IDE, it shows this as a debug message as well.

Are you on the v2 hub and the stock device handler? If so update to the custom device handler and it should fix your issue. I had submitted a patch to the stock handler a few weeks (exact same code used in my custom) but it appears to be behaving differently if run locally on the v2 (stock handlers run locally). As an experiment it would great if you can try something.
Create a new custom device handler using this Stock ST Code: https://github.com/SmartThingsCommunity/SmartThingsPublic/tree/master/devicetypes/smartthings/zwave-lock.src

This is supposed to the same code that’s in the ST stock handler but installing it manually as a new device handler through the IDE forces it to run on the cloud vs locally. If that fixes the issues then you’ve help uncover a very big firmware issue that ST needs to fix. Please feel free to ping me if you need help with this. Thanks (I really want to nail this issue)

A couple of things:

  1. I am on V1 and I was using the “zWave Lock Reporting” device type. I believe that’s a built in device type, but not 100% positive.

  2. I upgraded to your 4.1.1 code at around 6am and I noticed around 8:30am, these messages stopped. Is it possible these were queued up and 4.1.1 fixed it?

  3. I changed over to the device type handler you recommended and modified 2 of my 3 locks to use this and will report back my findings.

That’s your problem, you’re using a third party custom handler. This has a bug in it because it’s based on a very old ST stock code. Either use the Stock ST device handler or the customer handler published on the first post. We pushed the bug fix to the Stock ST handler a few weeks ago and other custom handlers still have the bug in it.

This SmartApp is only tested and designed to work with the ST Stock Handler and the custom handlers published here.

So just a note for users (thanks to @Tyler for the clarification). If you’re on the v2 hubs please use the custom device handler for now. The bugfixes to the ST Stock Handler will only be pushed to folks on the v1 hub automatically (since they run on the cloud). v2 hub users will get the patch with the next firmware update (the device handlers are bundled into the firmware so cloud patches aren’t automatically pushed) (not sure when the next firmware will be pushed yet), until the next v2 firmware update please use the custom device handler or manually install the Stock ST Device handler from the ST github page.

Thanks, this makes sense and glad we figured it out. So far so good. Although, I am not home to do any testing.

1 Like

I’ve just installed the Door lock user code management SmartApp for the first time and it errors when I run it at the 2 lines ‘log.trace “The date/time on the hub now is ${(new Date(now())).format(“EEE MMM dd yyyy HH:mm z”, location.timeZone)}”’ (these are lines 892 and 1049 in the code). The error is “java.lang.NullPointerException”.

If I comment out the 2 lines, the code runs ok and i can install the SmartApp on a Schlage lock… Presumably it’s a problem with the date or timeZone functions.

Running on a V2 hub.

Very odd and yes I would agree, maybe it a temporary glitch in the platform. Try again after a while and it’s still showing the error I would report it to ST support (with the line of code).
It’s working fine with the v1 hub here.

I just installed the multi-user version and custom device handler yesterday, and I have one issue. I didn’t find any reports of it from searching, so I apologize if it’s been covered.

I have four users set up. When I select “Click here to define unlock actions for {User1,2,3,4}” it shows “Setup unlock actions for each door for user {4}” and “Define specific unlock actions for {User4}”. Basically, no matter which user I select to define unlock actions for, in the define screen it always populates with user 4. Furthermore, it seems that the settings for the user unlock actions are only being applied to user 4, so when users 1,2,3 unlock the actions are not taken. Hopefully this makes sense, let me know if more explanation is needed.

Yes that’s a bug with the ST Android App . It works fine with the iOS app. Please report it to ST and let them know it’s an Android specific issue. If they want more details from you can point them to this page How to pass parameters in href?

Reported, thanks. Now I just need to see if I can get my hands on an iOS device to get things set up until it’s fixed. I wish they gave us a way to modify installed SmartApp parameters directly through the IDE…

EDIT: As a workaround I changed number of users to 1, and set up the user overrides for user1, then opened the SmartApp again and set users to 2, then set up the user overrides for user2, etc. Looking in the SmartApp info in the IDE, this appears to have worked, but I won’t know for sure until I get home after work.

1 Like

That’s absolutely correct, Android’s bug is when you click the link it passes the details of the last user on the page, so that’s an awesome work around.

1 Like