I have the Schlage Connect lock. I created 6 different users and codes for each of them. First step I took was to delete all existing codes, then changed to the code length from 4 to 6 digits. I’m keeping getting Code x is not set and the codes won’t work. I can lock and unlock using the Smartthings which tells me the lock is talking to the hub.
UPDATE: never mind, it is working now
Yeah, I’m learning to be patient with Z-Wave
Yes that’s what we’ve been spending considerable time planning and trying to implement in the simplest/easiest manner possible.
Both Schlage and Yale have two modes of operations:
The new Z-Wave Enhanced Lock DH now support both these modes and this smartapp can process both modes. Depending on how you’re configured your lock you can correspondingly configure your SmartApp.
If the SmartApp detects from the DH that a code was used to lock it’ll look for the user specific routine if configured or fall back to the generic whole app routine for external lock.
If the SmartApp detects that no code was used (One Touch/Lock & Leave) then it looks for the generic whole app routine to run.
Does that help? Is the functionality confusing, we’re open to feedback on how to make it easier.
EDIT: I know many folks prefer to use the stock DH but since the stock DH has a few bugs in this area they will need to update to the custom DH to use these features, however we’ll work with ST to reverse integrate some of these bug fixes and features back into the stock DH so that the basic functionality of user codes lock and external lock events can be used.
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?
Thanks will be improved in 4.6.1
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…
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)
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 
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:
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.
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.
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.
For locking / unlocking procedures why don’t you use a simpler code like:
locks?.each
{
it?.lock()
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.