I’ve posted some comparisons that we did of the various locks features, see is that helps you decide.
Are you using this app to arm your security system or how are you using you “arming” your system?
If you’re using the above SmartApp it has a configurable delay to arm the system.
I’m trying to use the ‘Lock User Management v5.1.4’ to arm the system by defining the ‘user locks the door successfully’ action to run a routine (“Goodbye!”) which then arms my system, turns our lights, etc.
I was using presence control to automatically run the routine which works great for me when I leave for work in the morning, but if I have say, someone come in to walk my dog and they use a code which I have set to disarm the system, when they leave (no presence sensor) they are just locking the door (Schlage) on their way out which doesn’t arm the security system again. I’d like to set the ‘lock’ action to run the Goodbye routine but only after a delay so that the camera motion trigger isn’t tripped.
I understand but that would overly complicate the User Managment app UI. I would recommend looking at the Intruder App I posted above or using CoRE to create a custom command to arm your camera with a delay when it detects a change of mode event.
Ok, thanks for the tip. I will try that out tonight.
###Multi User Lock Code Management with Notifications and Actions - Version 5.1.5
- Minor bug fix, when controlling multiple doors and one or more doors doesn’t have an assigned sensor, when the mode changes the door may not relock itself if configured to do so
Recommend use the [Universal Enhanced Z-Wave Lock] ([RELEASE] Universal Enhanced Z-Wave Lock, Schlage Lock, Yale Lock, Kwikset Lock, IDLock, DanaLock, August Pro and Samsung Lock Device Handler with Alarm Control, Notification, RFID, Door Sensor and advanced features) device handler version 3.0.1 or newer for full SmartApp functionality
Thanks to DnCCrew for this step:
Set the hub Location for scheduled/expiry codes to work correctly, from smartphone app:
- Clicked on the 3 lines (top right corner)
- Clicked on gear icon (top right)
- Click area that says “Tap to set where home is on the map” and zoom in to correct location on map.
I’m having problems with “expire on” codes not taking effect on my Yale YRD110. What’s the best way to troubleshoot why that’s happening?
I have a good line of sight between the hub and the lock of about 30 feet. There are actually no other z-wave devices on this hub and network repair takes just seconds to complete. I have set the location correctly in the ST app. I’m using the custom device handler. Commands issued for permanent lock code changes go into effect immediately. Manual lock and unlock requests perform immediately and notifications are prompt.
The only problem is when I schedule a code to go active at some future time and I’m not interacting with the app, it always fails to activate. During testing, I can get scheduled codes to work, assuming I’m active on the ST app.
Any ideas? Are there any logs that indicate if the code is being pushed to the lock and not being received or what?
The problem I’m having noted above with “expire on” codes made me think of a useful feature: I’d love to have the option of a notification or sms issued when a scheduled/expire on code gets activated or deactivated. We are using the app to manage an AirBnb property so it’s essential that our expire on codes are working for unattended access of guests. A notification would put us at ease that it’s working as expected.
It could be one of two issues
- If you have a no other z wave repeaters and its 30 ft away the problem is that the codes don’t reach the lock. The app will keep trying to program it but the chances of are low. In our labs and experience you should have a few repeaters (active devices) around to form a “strong” mesh. 90% of the trouble is usually with a weak mesh (and z wave repairs to strengthen a mesh)
- Your ST scheduler has stopped working. This one is easy to debug, open your IDE live logging and if you see a message about housekeeping pop up every 5 minutes or so then the scheduler is working fine. If not then you had a problem with a dead scheduler and you should report it to ST support (you can manually restart it by opening and clicking done on the app but likely it’ll happen again)
Meanwhile also try to reboot your hub and repair your zwave network. Very often that gives your network a boost in connectivity.
As for notifications on when a code goes active sure that can be built in but that won’t solve your problem as then the complaint would become I don’t get messages that my code has been activated (because the lock won’t respond hence the app won’t confirm it)
EDIT: it does log it in notifications when the lock responds with a confirmation and when the smart app sends a request to program the lock. It just doesn’t push it to the user but you can see it in notifications. So if you’re seeing the request but not the confirmation you know it’s the communication and not the scheduler. If you don’t see either then it’s the scheduler
Just grabbed a lifetime membership with your apps, and love the concept of them.
I am, however, having a hard time getting it to work.
I was using another app that allowed me to remotely change passcodes, but it didn’t offer scheduling, which is something I need for my rental properties.
I’ve installed the advanced DH you provided, no issues.
I’m now trying to install the SmartApp, but for whatever reason, the codes aren’t taking to my lock.
When I add a code, it seems to “hang” when I am punching in the #s, and occasionally it will “save” the user name with no passcode. I will then go back in and edit and add it. Unfortunately, it doesn’t seem to enter into the lock, even after going back and editing. I have two hubs, and two instances of the app, one controlling each lock. This is happening for both, as I can’t unlock either lock.
I am using a Schlage Touchscreen Deadbolt Camelot lock, brand new (I am new to this, but computer apt). I have followed the troubleshooting (I reset the hub etc). Still having issues.
I doubt it is a range thing as the old app worked in changing the lock codes. Any ideas?
UPDATE*** : I uninstalled the app, and reinstalled it. It now won’t even save the codes to the app. /em banging head against wall. (Gives me a red “There was a problem processing your request. Try again” message, doesn’t save the passcode, but gives me a green message to let me know the name has been saved). I go back, sure enough the name is saved and the passcode is blank.
It sounds like you’re having trouble with the ST SmartApp with the hanging and not saving issues. First I would suggest find a way to resolve the ST SmartApp and sorry to say buy you may have to contact ST for that. I’m guessing you’re using an Android phone. Just a point to note in the Android phone make sure you press “Done” on the keyboard after each entry otherwise the ST app doesn’t save the entry. It’s been reported to ST but who knows when they’ll fix that. The more folks who report it the faster they’ll fix it. It could be an issue with your account/ST server shard since it’s happening with both the apps, again ST would need to investigate it. Sorry I can’t help more that this only thing I can suggest is wait for a while and try again. Sometime the server is just running slow/has issues and fixes itself after a while.
It is saving now on the other lock. With the Schalge do I need to turn on the OAuth or whatever?
The other app I was using (which didn’t allow time scheduling) wasn’t having an issue with inputs. Seems unique since I began using this app/DH. HAve you tested it with the camelot locks? maybe I’m overlooking something simple which I didn’t switch on?
It’ll be there in the next version a details notifications option which you can turn on for additional notifications along with some new features we’re bringing in.
BTW, so here’ a great examples of what just happened in our lab, while testing suddenly the ST platform went too slow and timed out during a send notification option which also ended up killing the scheduler and the rest of the codes weren’t programmed.
Thankfully we have a backup scheduler (heartbeat) that runs but it runs every 10 minutes, so in this case after 10 minutes the backup scheduler detected that the main scheduler has been killed by ST and restarted it and it picked up the remaining codes and programmed them. Just that it took 10 minutes to pick up on it.
EDIT: Also noticed that some confirmations from the lock arrive as late as after 5 minutes. So it’s a pretty complex environment that the SmartApp is dealing with
Ok, I’ve been watching the logs roll for a couple hours and testing at my second location to eliminate the possibility this is a z-wave connection issue. There is a much closer proximity from the hub to the lock and z-wave network weakness is highly unlikely here. All other aspects of the lock are working as expected with no latency.
This is the setup:
I have 5 user slots active.
Users 1-4 are permanent, active codes, and #5 is expire on.
In the Events List for the lock device, I see the app regularly doing it’s code maintenance routine about every 20 minutes with
codeReport for the permanent/active users 1-4, and
deleteCode for user 5 when it’s scheduled as inactive.
At the time user 5 is scheduled to be activated, I see no indications in the device events list that it’s actually received any command to be activated. During the timeframe that user 5 is scheduled to be active and the app does it’s checkup, it simply logs no information about that user.
Over on Live Logging, when it gets time to check up on an “expire on” user that should be active, I see this:
trace - ST Cloud status for code 5 on Front Door debug - user 5 Test is already tracked as start added
I thought perhaps the problem was with user 5’s slot being reused repeatedly so I created a user 6 and set it up from scratch. But still the same problem, no
setCode command happening at the scheduled time but it does report a
deleteCode when the user is unscheduled.
So in summary, the app is not sending a
setCode for “expire on” events when it’s supposed to.
I really feel like this is a bug. Are there any known incompatibilities? only other smart apps I have installed are AlexaHelper, AskAlexa, and JSON complete API.
That means the lock has confirmed that the user has been added. Once the lock confirm there’s not reason for the SmartApp to retry it. If the lock doesn’t have the code it’s possible the lock firmware has an issue. Best way it to reset the lock, delete the SmartApp or remove all codes and start over.
EDIT: With the latest SmartApp you can enabled detailed notifications to get push notifications when each programming is successful
The issue is fixed.
Seems it was two fold:
The problem was definitely with the Android OS in that I had to hit “done” on the keypad (and not just in the upper right corner of the SmartApp) in order for the system to remember the passcode
Patience. If I gave the lock a minute to chill, instead of running to the lock to check if the code transferred in five seconds, it loaded it with no problem.
Just going to test the scheduling and I’m a happy camper! I love that I can get text messages on whether someone uses a key to get in. I don’t trust my property manager one bit! lol
I will give that a try. This was working when I first installed your app. I later updated to the latest version as well as the latest device handler and I think that’s when it stopped working.
Got everything working perfectly except the scheduling.
I set up a code to start working 20 minutes ago, and it still hasn’t kicked in. The only issue I think that might be happening is a disconnect in the times of the hub vs. the real time.
Unless I’m missing something else.
I’ve tried most places to find the time zone of the hub but can’t seem to locate it. Any help would be appreciated.
It’s in every release notification:
Set the hub Location for scheduled/expiry codes to work correctly, from smartphone app:
Clicked on the 3 lines (top right corner)
Clicked on gear icon (top right)
Click area that says “Tap to set where home is on the map” and zoom in to correct location on map.
Yup that was all already done.
Still seems to delay the “disable/enable” by 15ish minutes.
Not sure why…