[RELEASE] Lock User Management (LUM)

Try using version 4.0.2, I’ve added the option to report the slot number of the user is unknown (i.e the slot is not managed by the lock but it is used to unlock the door)

1 Like

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

I’m going to give Rboy a solid pat on the back. As a fellow developer for other projects, simply asking for donations never works. I’ve got a Wordpress plugin that has thousands of users, and I have received 2 donations.

So as you can imagine, guess how much time I spend working on it now? None. It isn’t worth all of the time.

I’ve never seen a developer as responsive on a project as Rboy is, and I greatly appreciate that. He is accepting of suggestions, feedback and ideas, and turns the good ones around very quickly.

You can complain all you want, but the fact is that people don’t generally develop for free, unless they are using it themselves. And those developers using it themselves aren’t generally open to feedback and ideas, unless they are features they would use themselves.

I have no complaints, and some of the most recent ideas that we’ve discussed, if we can find a way to develop, I will happily contribute again. That’s how users can say thank you, and how they can continue to encourage development and improvement of the project.


I don’t know much about the ST framework, and haven’t ever messed with groovy. However, I’m wondering if the ST framework would allow using a Java library like one of the following for parsing the ICS?

Yes I did look into those and would be a great start but I’m not aware of anyway to use custom libraries with ST. Something that’s warrants further exploration.

In regards to my test case, I have completed as follows:

1-) I reset all local codes ;
2-) Used RBOY smartApp to set the codes;
3-) All othe rcoes have indeed disappeared and expiry is yet to be tested in a real case. I will update soon but it looks veyr good.

For reference, SCHLAGE BE469, the command to reset all codes is to be used fisrt prior to instgalling the App ( part of the procedure) :

1-) press SCHLAGE + Programming CODE + 6 + Programming CODE ==> Thtat’s it
2-) Let the App do the magic ;

Great job man !!

Dear Craig,

I am new to this community with a neutral attitude. Maybe not everything is to be painted with a single brush. 15 USD contribution for all code is absolutely not significat considering the round the clock efforts made by RBOY. It probably only pays a webserver sharing the code. I have had a flawless support so far offline or during the forum and this effort from this chap really needs respect.

If you are able to write code, then I suggest you guys raw in the same direction. In my opinion it would be fair to have a “free” version and a “pro” version, to which peple get the necessary support and specific features.

I have not seen this level of support and committment so far. Keep up the good work


I still have problems with codes that expired. They are still operational in the lock after their expiry date ( despite resetting the gateway as advised).

@hakem it’s working fine here on all 4 of our test locks. If the code is still operational after expiry then your lock didn’t process the delete command or the ST timer didn’t fire on time. Unfortunately the app doesn’t verify delete commands it only tracks and retries programming commands at this point. I will look into adding support for tracking delete commands but the root cause if you problems is that the lock and hub aren’t communicating reliably. I would focus efforts I getting that fixed. The app is just a simple set of rules and timers. If the other codes are working then your platform timer is working (you can verify by looking at the logs and you should see the app do a health check verification every 5 minutes). If you see the health check happening then it’s your lock and hub communication. If however you aren’t seeing the health check running every 5 minutes then your instance has timer issues and you should contact ST support with the timer not firing issue. This was reportedly fixed by ST last week but some users are still facing issues, see the forum thread here for more details

Hi Rboy,

I did another test and suddenly codes that were expired but opened lock one day ago no longer open the lock. I will try to isolate the problem and come back with some scenario that can be reproduced. Thanks,

Version 4.1.0
Added support for tracking deleted codes confirmation from lock and retrying if lock doesn’t confirm code deletions

@RBoy, any more consideration for our airbnb/homeaway idea? Would another donation help?

It’s on my list. A fairly complex task given I can’t import modules. It will take some time.

Everything seems to be working just awesome! However I tried to enable the smartapp autolock function based on the door sensor and that doesn’t seem to do anything? It seems the Schlage autolock will lock it after 30 seconds but not the smartapp. So if I turn off the Schlage autolock function the smartapp is not automatically locking the door when I close it and the door contact indicates closed. Or if I have the door open and manually extend the deadbolt the app doesn’t retract the deadbolt nor prevent the Schlage autolock from opening the deadbolt even though the door contact indicates open.

Your timers are dying. You can verify from the ide logging. Only ST support can fix that for your instance.

I have three locks. Is it possible to have a certain user code open two of the locks but not the third? If not possible, can I make a feature request for this? If this feature doesn’t exist, are there any issues with installing two instances of the app as a solution?

Also, is there an FAQ? This thread has gotten very long and I imagine the same questions are asked repeatedly. I tried searching the thread before I posted. Thanks.

1 Like

That’s a great idea. Thanks I’ll out up a FAQ in the first post.

As for your question. You can have multiple apps installed controlling one or more locks each. Just make sure that each lock is controlled by only one app. I.e. one app can control two locks but two apps cannot control one lock and you’re fine.

Version 4.1.1
Added option to enable incremental updates only. With this option enabled only codes which have changed will be programmed into the lock.
By default, for security purposes, every time any code is changed, all codes are reprogrammed into the lock and re-verified.

I have three locks. Is it possible to have a certain user code open two of the locks but not the third? If not possible, can I make a feature request for this? If this feature doesn’t exist, are there any issues with installing two instances of the app as a solution?

This is an excellent suggestion, and let me argue for the feature in the app rather than utilizing two (or more) different instances of the app. Here’s the use-case:

Rental property management. There’s two (and possibly 3) different types of locks on a rental property:

Exterior doors
Each door (if more than one) is programmed to the same set of codes.

  1. Some codes are permanent for the owner, manager, cleaning, etc.
  2. Some codes are one-time use or dated for maintenance, repair or renters.

Interior utility doors
A great example of this is a utility room door. But this could also fit garage entry doors, attic or cellar doors, etc.

We used to have a keyed lock on our utility, but have been burnt several times by 3rd party repair people coming over to correct a problem but not having the proper key. We are now using a Yale YRL-220-ZW-619 so we can program temporary codes for this door (and the same code for the entry doors).

So a few details:

  1. The codes for the utility door must be managed separately since renters should not be given access to the utility.
  2. The permanent owner, management and cleaning codes should be shared with these doors, since any of these groups would need access to let repair people in, check on things, etc.
  3. The renter codes should not be shared with these doors, as renters should not have access.

Owner storage doors
There are also doors that are used for owner or personal storage. These doors are typically off-limits to management, cleaning and renters.

So a few details:

  1. The codes for the storage doors must be managed separately since management, cleaning & renters should not be given access.
  2. The codes for the owner should be shared with these doors.

As you can see, with two (or more) apps, there is quite a bit of duplication of codes, copying and pasting, and a high likelihood of a mistake to occur.

A possible solution:

Configure “Code types” at the beginning with all other “default” / “across the board” configurations. These “Code types” would be used later when setting user slots. For example, I could setup the following “Code types” at the beginning:

  1. Owner
  2. Neighbor
  3. Management / Cleaning
  4. Maintenance / Repair
  5. Renter

I also like this solution because it could clean up the interface quite a bit, reducing similar / duplicate configuration on a user-slot basis, allowing me to set several settings by code type. For example, by each code type, I could assign:

  1. Actions when a user locks/unlocks the door
    a. Another UI improvement allows me to define the separate “Unlock actions” by type here rather than having to do it per-door or per-code and again having to repeat configuration.
    b. Use-cases here - I may have certain lights that turn on for renters after dark, and turn on the water heater when they arrive, but I may want to switch on the water heater when cleaning arrives (anytime) and then turn it back off when they leave and re-lock.
  2. Notify (Y/N)
  3. User type (Permanent / One time / Expire on / Scheduled)
    a. Based on the settings of the “Code type”, when I set that code type in the user slot it knows what additional questions to ask just for that user slot. Things like “Expire on”, etc.
  4. Lock(s)

There may be further ways to extend these “Code types” to help reduce configuration on a slot basis and instead wrap it all up in the “Code type” configuration. And if the user could define these types themselves, then assign different settings to them, it would create an incredibly flexible and user-friendly experience, while also decluttering the UI.


1 Like

Immediate locking sometimes does not work, I’ve had a few times where the door closes. I’ll even have activity showing the door switch closed but the door is not locked. It’s not consistent but It does happen enough that I do notice when it is closed but not locked. Let me know if you need anything to troubleshoot this.