I would to evaluate the App before purchasing, or have the option to return the App and get reimbursed if I don’t find it works for me within the first 30 days. Is this an option?
Yes it tracks it internally. It is used for the Notify X times option for each user. Send us a request and we’ll add ticket to see how we can display it in the next release.
Sorry if this is a FAQ, but are there any keypad/RFID readers I can use this this? It looks like there are, but wanting a specific recommendation.
Interested in combining it with my August Pro (I really have the keypad they have).
Thanks in advance!
Still waiting to here if a trial version of the App is available… While I wait for that answer, would the App Unlock notifications for a Yale YRD226 lock include user identifying information?
I have not played with the apps yet as am constantly away from home but wanted to ask if there is any provision for them to work with different RFID tags. As the newer Yale Conexis L1 lock do not have a keypad is there any way to be able to differentiate between different tags/fobs being used etc.?
Apologies if this has already been covered.
Yes, it was confirmed by a user in the post above your question, and unfortunately, SmartThings isn’t setup for a trial model.
@chippie , The Conexis lock does report some RFID information over Z-Wave, however do keep in mind that that the standard ST z-wave lock device handler does not process these RFID tags. You will need to use the Enhanced Z-Wave Lock Device handler to process those RFID tags/fobs. How the tags are differentiated depend on your locks’ firmware. The DTH itself can recognize different types of tags, RFID, Bluetooth etc.
Also do keep in mind that the lock does not follow the standard Z-Wave user programming method. So it is recommended to follow the locks’ instructions to program your tag/fob’s with the lock and after programming them we have developed this app specifically for the purpose to using pre programmed tags/cards/users and then take actions when the lock is operated using those pre programmed users.
@maddie, What do the notifications look like? Would the name of the user be in the notification (SMS and SmartThings PUSH)?
What is the trick to keep the lock from locking while the door is open. I guess the only way the system knows the door open is buy the Samsung open/close sensor. So, if it reads open, how to keep it from locking?
I have Relock when closed on, Relock after minutes unset, and unlock while open set.
You’ll need a door sensor and under Door Open/Close Actions select the sensor and set option to unlock when left open. Sounds like you’ve done it.
If you are seeing that the lock sometimes unlocks/doesn’t unlock or doesn’t unlock in a timely manner it indicates an issue with the z wave mesh. The command is getting delayed or lost or the lock is having issues processing it (sometimes replacing the battery helps). Try to add a repeater within 20ft if the lock and do a z wave repair.
You can also look at other cheaper sensors like the Monoprice door sensor or the discrete Monoprice recessed door sensor:
They also have a version that runs on AAA batteries which can double as a mailbox sensor.
Yes. For e.g.:
Front Door Lock was unlocked by user Maddie via Keypad. You have separate notifications for locking, unlocking, manual, keypad etc which can enabled as desired and also set conditional events (like modes or presence etc). You can also set custom notification options for each user or for all users (individual options take preference over general options). It can send push and/or sms (to multiple numbers) depending on the options you’ve selected and how you’ve set it up in your ST address book (if you have one).
See the release notes above or the website for a full list of features:
Not sure if this may be possible or not but if so perhaps you could add it as a feature request.
Similar to using the app where we can assign a Door Sensor to the Lock I was wondering if something similar could be added to the DH so we could have a TILE showing if the Door is physically Open or Closed. Hope that makes sense.
With the User Unlock/Lock app and assume this one, there is the ability to set a notification if an associated door Sensor is left open “Notify if door has been left open”. This works fine however the notification itself states the name of the Lock as opposed to the name of the associated Door Sensor. Not sure how others feel but would not be more relevant and helpful if it actually gave the name of the associated Door Sensor as opposed to the Lock name in the Notification, after all it is the door that is open even though the lock is unlocked. Probably a very easy fix in the app. The same applies to the any other associations and notifications.
I programmed on use as a “Start/end date and time” user. The App didn’t save the date properly (it seemed to only save the year and month “2017-05”), so it expired the user. I have properly set the date now “2017-05-28” and time “12:01 AM” , but the App still shows the user as EXPIRED .
How do I fix that?
Also, how do you delete a user?
You’ve set the end date to 2017-05-28 instead of 2018 so it’s showing as expired. Unfortunately ST doesn’t have a date picker yet so users need to enter the date manually for now.
As for a deleting user, just leave the user code input blank.
If you want to keep the user settings/code and temporarily disable the user, select the type “Temporarily disabled”.E.g. you sibling visits and you want to keep her/his code in the app for the future, set it to temporarily disabled.
why would I want lock after closing unchecked? I want it to do that.
I’m having 2 issues with this device and I’m not sure if they’re related. These things started happening after I recently updated both the DTH and related smart apps (Lock User Management and Schlege Lock Alarm Mode and Sensitivity Change and Monitor). They are all current as of about 5/20/18).
The issues are:
1 - I get an error on the DTH just after the Schlege app runs: Contact Developer Is Alarm Sensitivity Not Supported, Mgr 003B-6341-5044. That fingerprint should is for my Camelot deadbolt tied to the DTH and should be supported. After this error the device appears to be unreachable until I perform a refresh, but log messages continue to be generated.
2 - I have 2 time restricted lock code users. Although I am notified that the lock codes were properly removed and re-applied, it doesn’t appear that they are actually registering on the lock (i.e., the physical lock doesn’t have the changes). This is the same lock as the first issue and the timing of the changes are the same - both are mode based. This is why I suspect there may be a cause/effect. One potentially related note: The lock times used to go past midnight (e.g., lock available from 6 am until 1:30 am). I suspected that this may be the problem so I broke those up into two seperate schedules (e.g., 6 - 11:59 and midnight - 1:30). This did not help.
I’ve tried tracing and other debugging techniques to no avail. Please let me know how to proceed.
All your issues seem to stem from the communication issue between your lock and hub. The sensitivity setting warning is being printed because the lock didn’t respond to the alarm setting request. The codes aren’t reaching the lock due the mesh issue, so the engine will try for about 10-15 minutes (you can configure how many times) and then will log an error and stop retrying.
The app supports times past midnight so you don’t need to split your times.
Make sure your lock is within 20ft of a z wave repeater (any mains powered z wave plus device like a switch or a plug). If you don’t have a repeater you should install atleast one repeater between the lock and the hub (requires to create a strong mesh). After adding the repeater do a z-wave repair. You may need to exclude and re pair your lock with the hub if it’s lost it’s connection otherwise a z wave repair with the repeater should fix all your issues.
Interesting - that’s something I didn’t expect. I do have a repeater in the middle (A go control siren) at about 20 feet.
Would the fact that the Schlage notice and the Zwave error are occurring almost instantaneously (based on logs) change this diagnosis?
In the interim I will see if I can identify issues with the mesh.
The opposite, it reinforces it as the Schlage message is a result of the zwave issues. It’s just a log message saying the lock isn’t responding. Someone reported an issue with the siren and the repeater functionality earlier this week somewhere on the forum.
If things are running and suddenly stop, a good rule of thumb is to check the mesh. Reboot the hub, z wave repair, check batteries, repeaters etc. it accounts for 99.9% of issues we see.
Thanks for your help. That fixed it.