[OBSOLETE] Lock User Management (LUM)

I figured it was this way…which is why I thought it was so freaking sweet!

I do not find it confusing; however, might I propose a verbiage change within the app so that both scenarios don’t state that the code is required?

1 Like

Thanks will be improved in 4.6.1

1 Like


I am a brand new lifetime subscriber!

Thank you for the awesome work. The option “Unlock door if locked while open” does not work for me…

I am using this lock:


Please advise…

1 Like

That’s usually due to a z-wave communication issue or platform issue. It uses a 3 second timer to relock the door, you would need to look at your smartapp logs to see if the timer was executed by the platform and if so (likely) then did the lock respond to it (possibly the issue). Try to reboot your ST hub and do a Z-Wave Repair and most of the time that fixes the communication issue (assuming your lock is within good range of the hub)

1 Like

Here is my log:

905417b5-d24e-42dc-8d28-26cfd3a153f7 2:37:01 PM: trace Pending immediate door locks []
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: trace Added Entry Lock id 531f04e3-495f-4b5d-bfb9-4a698d79b895 back to unprocessed locks list [531f04e3-495f-4b5d-bfb9-4a698d79b895]
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: trace Entry Lock id 531f04e3-495f-4b5d-bfb9-4a698d79b895 code check complete, unprocessed locks [], reset next code update to 1
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: debug Entry Lock Scheduled user 2 Devon is already active, not adding again
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: debug Within operating schedule
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: debug Operating DOW(s): [All Week]
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: debug Operating 2016-07-09T10:00:51.000-0400 10:00 EDT, 2016-07-09T17:00:51.000-0400 17:00 EDT
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: debug Current time: Thu Jul 14 2016 14:36 EDT
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: debug Checking operating schedule A for user 2
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: trace ST Cloud status for code 2 on Entry Lock
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: debug Entry Lock User 1 Arnaud is a permanent code and is already active
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: trace ST Cloud status for code 1 on Entry Lock
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: trace If you’re seeing this every few minutes, then ST is alive and kicking - ST cloud codes status for Entry Lock
905417b5-d24e-42dc-8d28-26cfd3a153f7 2:36:57 PM: trace The date/time on the hub now is Thu Jul 14 2016 14:36 EDT

Unlock does not execute properly…

I don’t recommend posting logs on the forum due to security issues. Please PM to me.

I don’t see any door open sensor event. Have you installed a door sensor and configured it with the app? If so PM me the logs when you open the door.

How do i “PM” you?

Click on my name and hit message :slight_smile:


Hello again, i am using 2 different Z-Wave locks with your:
Universal Z-Wave Lock With Alarms for Schlage, Yale and Kwikset latest version

I am using this device handler in conjunction with:
Lock multi user code management with notifications and automatic relock latest version

After rebooting my hub an repairing my zwave network, I get the 2 following problems:

  • Locks don’t automatically re-lock X minutes after the door closes
  • Locks don’t unlock when the doors are open and the locks unlock

Also, i want **Lock multi user code management with notifications and automatic re-lock ** to manage the locking of my locks and not the device itself.

Please let me know…

I too have sporadic issues with relock after x amount of minutes.

I have solved the issue using CoRE to setup redundancy lock after x amount of minutes when door is closed and door is unlocked.

I’m not sure why this is but it doesn’t appear to be distance or a communication issue if the app native solution will not work but CoRE does.

1 Like

Unfortunately as I mentioned above these are beyond the SmartApp, either the platform isn’t calling the timer function or more likely when it is called the hub doesn’t complete the command with lock. Mostly it’s the second. It’s all about timing since if you manually increase the delay in the code is often starts working. The hub unfortunately doesn’t retry command or say if commands have succeeded or failed hence there is now way to confirm if the lock or unlock command succeeded.
All I can suggest is moving the hub or changing the delay in the code from 3 to say 5 seconds.

I understand and didn’t wish to imply that it was fault of your coding as I’ve also had both fail lol.

My delay is 5 minutes…is that possibly too much?

None taken these are two sore points with ST which have been open for a very long time.

  1. Reliability of the runIn API
  2. Hub not verifying communication with the devices

As for 5 min yes it could be that it all depends upon your server instance. For some users it works fine and others it doesn’t. It’s a combination of the app and server instance. Within the same instance the scheduler may call the same API fine for another app but not for some apps. In the labs here the unlocks works perfectly on some days and then it just won’t work at all on some for both reasons above. Sometime rebooting the hub helps but it depends on what’s going on that’s day with the platform/hub.

All I can suggest is try moving the hub if it’s a COMM issue and if not then try changing the timeout.


Your work is fantastic and your ideas genius.
However, I think that there is a code issue somewhere…

For example when I use a simple Piston with CoRE to unlock my lock automatically when i lock it and my door is opened, I get the result expected, the door opens.

My coding skills are limited but let me know if i can help…

Thank you for the support.

It’s not the code, like I mentioned earlier it’s a platform/hub issue. If you open live logging you’ll see that it’s sending the commands to the lock (if the platform timer is working fine). After that it’s up to the hub/platform.

1 Like


For locking / unlocking procedures why don’t you use a simpler code like:

		log.info ("${locks} locked")

Also, could you please confirm that the “AUTOLOCK” option from your custom device if OFF does not interfere with “Relock after (minutes)” in your smartapp?

Thank you

Because of the infamous z-wave network. It needs time to complete each command before sending another one, when there are multiple locks the commands gets lost.

Yes, infact we’re putting a check the next version NOT to allow for Auto unlock if Auto Lock is enabled in the DH.

1 Like


I don’t see these command lines failing:

	log.info ("${locks} locked")

It will list all the devices and send individual requests to each device rather than sending one request to all the devices.
Did you try?

Also, as today, if I have “AUTOLOCK OFF” on my DH, can your smartapp lock the lock X minutes after closing the door and if the lock is unlocked and the door is closed?


Yes it does when you have multiple locks. We’re tried a lot of combinations here in the lab and what you’ve written doesn’t work 90% of the time with multiple locks and repeaters across a large space. Don’t under estimate the issues with a Z-Wave network and the ST hub when you’re trying send lots of commands in a short span.

Yes it can and again it’s subject to the same Z-Wave network and platform rules as unlock.

###Multi User Lock Code Management with Notifications and Actions - Version 4.6.3

  • Improved reliability of auto unlock and auto relock
  • Bugfix for notifying user if codes are being reused for multiple users
  • Now the App checks if the device lock has the AutoLock feature enabled and if so it will not Unlock the door when open to avoid an infinite lock/unlock loop
  • Clear all codes from the lock before programming when installing for the first time to avoid conflicts

Recommend the use of the [Universal Enhanced Z-Wave Lock] ([RELEASE] Universal Enhanced Z-Wave Lock Driver for Schlage, Yale, Kwikset, IDLock, Popp, Danalock, August Pro, Keywe, Philia, Samsung) device handler version 2.10.1 or later for full SmartApp functionality

Thanks to DnCCrew for this step:

To set the hub Location, from smartphone app:

  1. Clicked on the 3 lines (top right corner)
  1. Clicked on gear icon (top right)
  2. Click area that says “Tap to set where home is on the map” and zoom in to correct location on map.

EDIT: Please note this version has simplified the user interface, so please CHECK and VERIFY your notification settings. These are now on the first page under door lock/unlock actions.