I don’t see the lock itself sending a random false trigger saying it just locked itself while the contact sensor simultaneously sends a false trigger saying it’s open (which is what would need to happen for the door to unlock itself).
But ultimately I’m more concerned with the auto-locking than the auto-unlocking so this isn’t really a huge issue either way.
Yes that is the design of the app, it triggers on door lock events
BIG assumption, you’ve no idea how flaky the whole setup is right now. With over 60 devices in our lab we’ve seen it ALL! I’ve seen multiple random events, mode not changing, commands not executing, phantom events, repeat events, missed events, wrong fired events, filter mismatches (please search the forum for the number of time I’ve reported these issues).
I would take @jnschemm serious on his point of this can happen. It should not happen if everything works like it should but I will point you to Schrodinger’s cat here 
But I still come back to my question - when would you be in a scenario when under the ideal working conditions you will end up with an lock extended with the door open? Have you seen it happen?
I couldn’t name the exactly scenario that led up to it happening but the deadbolt shaped indentions on my door frame will tell you that it has. But given the inherent risks with this based on your experiences I’ll yield that this may have to wait until ST is more reliable. 
Regarding the auto-lock issue. I can tell you that the logs are going to show ST sending the lock command to the door but the door not responding back that it’s locked. With the contact sensor being involved with the mesh network and the trigger for this event, is it possible that it can’t send out that it’s closed while simultaneously passing on the info to lock the door thus requiring the delay in the locking action for it to work?
Yes, I was infact just debugging another set of logs for a user and found this in their logs:
4:07:42 PM:debug"zw device: 37, command: 9881, payload: 00 22 01 0000 " parsed to [‘displayed’:true, ‘descriptionText’:Front Entry Lock is busy, try again later, ‘isStateChange’:false, linkText’:‘Front Entry Lock’]
That’s the reason why it wasn’t responding to lock immediately but did with a delay. In our labs however it’s working with all 3 locks (lock immediately, including Schlage locks) but we’re using a v1 hub.
You can try to remove the battery from your lock and reinsert it (reset the lock) and reboot your hub, if that doesn’t solve your problem just use a 1 minute delay. I’ll look into the app to see if I can provide a 3 second delay before sending the lock command when locking immediately.
Okay go ahead and try version 2.4.3 it adds a 3 second delay before sending any lock or unlock command for each door so it doesn’t overload the Z-Wave network. Hopefully this should resolve any issues with the v2 hub.
Yes @MichaelK it does and I had a look into it. You’re referring to the FE599 lock from Schlage. However your diagnosis may not be right. Try this, goto the web IDE, click on My Devices, click on your FE599 lock, scroll down and click on Events List. Now try to unlock using a code and see what pops up.
You’ll see something like this:
2015-11-29 8:07:55.743 PM EST
24 minutes ago DEVICE lock locked Deck Door Lock lock is locked
2015-11-29 8:07:37.015 PM EST
25 minutes ago DEVICE lock unlocked Deck Door Lock was unlocked with code 1
You will actually see an unlock event followed up a lock event, so the lock is reporting it correctly. The issue lies with the ST platform/SmartDevice which isn’t updating the lock device properly. Doing a poll just forces a state refresh on ST and gets the correct status. The downside of the poll is you’re going to reduce your lock battery life drastically. Poll is a very battery expensive task. Infact so intensive that in some of my custom SmartDevices, I give the user an option to reduce the polling frequency and I’ve seen battery life (e.g. Thermostat CT101) increase from 3 months to 1 year!
I would suggest you move this to my Schlage Lock with Notifications SmartDevice thread and we can pick it up there.
BTW in terms of this app, the solution is very simple, enable the relock after door is closed option. That way as soon as the user unlocks, open and then closes the door it will send a lock command and problem solved.
@MichaelK we’re putting a fix for it in the SmartDevice, please feel free to post your feedback on the appropriate thread.
Use the latest device 2.3.0 for your Schlage FE599 for the user code relock not reported. It’s a bug in the firmware of the lock which has been resolved through a fix in the SmartDevice.
Hey RBoy, do you have any updates regarding this ‘setCode is not supported’ issue? I have a BE468 Schlage lock, and I do believe it can be remotely managed but I keep getting this error,
It should work fine. Check the smart device you’re using for your lock. Maybe delete and re-pair and reinstall. Possibly didn’t detect it correctly.
The re-locking immediately feature is still not working. If you could give me the option of inputting seconds instead of minutes I think I could get it working.
I read the whole thread and don’t think i saw an answer- couple general questions-
First, from experimentation it SEEMS if i edit one code or setting that it wipes all the codes and rewrites them all. Am i following correctly? Is there anyway to set it up so it only messes with the slot that has changed and doesn’t do anything to the other slots? That would at least make it safer to fiddle with a pin code(s) remotely. I could delete/edit/whatever to slot X without effecting the other 6 codes. At worst i’d lock out one person and not my whole family or a random subset thereof.
Second, Is the app supposed to be confirming that codes got properly set up? It doesn’t appear to as at times it misses a random one of the 7 codes i have set. Pretty big issue since every time i make a change i’d need to be home to test all 7 codes to be sure none got fubared. Can things get updated anyway to confirm things? Seems it is possible from at least one other lock code app which does confirm and retry the faulty codes to correct any issues. It requires a few lines of codes to get added to the device type and then having the app ask for the codes to ‘get read back’ or something like that. I think reading this thread there’s a mention of no ability to read back but seems some changes to the device type code could fix that.
That did the trick, thanks!
Michael this SmartApp is designed to work with the stock ST Z-Wave Lock device, so no customizations to the device can be done. You can always tweak the app for your own installation.
The architecture is setup to resend all codes each time, this it the only reliable method after much experimentation since the base ST device type does not support read back yet.
The best solution to your issue, as mentioned in the 1st post, is to find the ideal programming delay for your lock and this varies for each person’s setup and configuration and layout for each lock. Some folks have success with 5 seconds and others 30. 15 was the most common hence the default.
Just to clarify for all users, there is NO connection between this SmartApp and any specific SmartDevice or any lock. It works with ANY SmartDevice/Lock that supports remote codes (currently ST ZigBee SmartDevice doesn’t support remote codes). The questions and solution above in relation to FE599 were related to a different thread and nothing to do with this SmartApp.
This SmartApp works with the stock ST Z-Wave SmartDevice which works for all Z-Wave locks that support remote codes.
A couple of users have reported that after a few days the code check/updates stop working, this is happening because of an issue with the ST platform where the scheduled timers stop working a some users (don’t know why some and not others). I’ve put a patch in the code to work around this ST bug, essentially everytime the mode changes (e.g. Home to night or away etc), the app kick starts the scheduled timers again.
However if you’re facing this issue please report it to the ST devs here:
Thanks. I read the the first posts and i’ve tweaked it to best suit my setup but it’s far from ideal in general to not confirm.
Networks change over time so the timing could constantly need to be changed. And if someone happens to flip a z-wave switch (locally or remotely) then the timing one picks can get imploded. Never mind if someone happens to use the lock in the middle for the 1-2 minutes of sending codes.
I’ve been using my lock for 5 years now- previously used vera and i regularly changed codes with that and never had a code get fubared in those 5 years. Sadly can’t say the same with ST. Much not your app’s fault obviously but still that’s the reality. Fingers crossed they address the issue when they roll out their official lock code manager.
Hi there RBoy! You told me today to make an account here and to update my progress.
I reinstalled your app, and the codes were resent. The issue that occurs is my Schalge lock and STv2 will work for a day or so when I resend the codes/schedules to my lock. Then it just stops sending the codes/schedule to my lock. It seems to happen overnight because it remembers to delete the codes the day before but does not write them back the next day (I codes to be send 8AM-5PM M-F).
I’ve noticed since the last ST update, the lock is sometimes slow, or doesn’t even tell me via the ‘messages’ on the ST app if the door was locked or unlock or who used their code. Sometimes it works and registers, but sometimes it doesn’t. It worked fine on Thanksgiving day, as I’d show my family how it would respond and how I could unlock from my phone. As of today, it does not unlock/lock from my app, or its very slow in doing so (more like 10% chance it will work).
Now we did have power shut off during a storm after Thanksgiving (when the lock became worse and worse in responding), so I did the following:
Unplugged my STv2 Hub for 5 or so minutes and waited until steady green to do the following:
Removed/Reinstalled the lock app
Removed/Reinstalled lock from my Z Network
Now for today, I reinstalled the app with the newest version, and the codes were sent and all is well. When I used one of the codes, it worked, but ST did not see it as it happened. It just unlocked the door and the activity did not show that it was unlocked, and in which, did not tell me via SMS that it was unlocked.
I just tried it again after a few minutes since the last time I tried, and it worked and show me via the app and SMS. But I tried to unlock the door from the app and it did not work. If I manually lock it, it thinks its still unlocked. I have the Schlage lock to auto-lock after 15 seconds, I’m not using any App to do so, could that be the cause?
I know I rambled on, but I’m fairly new to all HA, and don’t know the best way to explain myself.
Thoughts?
@SetGoose
This thread is related to the door user management app, please post comments related to the Schlage lock smartdevice here:
As for the door mgmt app quitting after a day or so as I had explained it’s related to the ST platform timers dying. While there’s a temporary patch I’ve put in the latest code that reboots the timers each time the mode changes please report the issue here to the ST devs so they can monitor/fix the issue: