The ssl business happens on delete as well, it's slow, because that's how long the lock takes to process the request.
Some are faster than others.
Oddly my two YRD256 locks show different model and manufacturer data in the device status page.
One, on which getCodes does not work shows:
- endpointId: 01
- application: 05
- model: YRD256-TSDB
- manufacturer: Yale:8002:0600
The other where it does work shows
- endpointId: 01
- application: FF
- model: YRD256 TSDB
- manufacturer: Yale
Is there a way to set up door lock schedules per day, such as having no codes work between hours of 1p and 3p? I didn't see that option in the Lock Code Manager 1.0.0 app.
Not yet.
Does that mean that this is a feature that is being planned for the new version? Any update on when that version is due?
They don’t comment on when they’ll release, but have commented that it is planned for a future release.
Pure speculation, but based on my interpretation of Mike's posts, this is a particularly complex solve, involving physically deleting the codes and adding them back cyclically, for most locks. I wouldn't expect it to be incorporated soon.
Based on that post by Mike and the fact that it is not feature of the lock itself. updating codes on the lock multiple times a day would really kill battery life.
1 Like
Worked fine in SmartThings using the RBoy app. My Yale lock is around a year old. It has spent half of it's life in ST with the RBoy app, and the second half in Hubitat. It's still using the initial set of batteries from when I first installed the lock.
The Yale YRD216 lock says that it supports up to 250 codes with the network module. Doesn't the module authenticate with the Hubitat wirelessly though? Shouldn't that mean it should be able to support however many codes the Lock Code Manager can support?
On that note, what's the limit to the number of code that can be assigned through the Lock Code Manager?
Don't know if there's a hard limit to the number of codes supported in Lock Code Manager, but if you click on the retrieve code button in LCM, it scans through all 250 code slots ... at least it did for me for all seven of my YRD240 deadbolts (two locations, all with Z-Wave modules).
Thanks for all the helpful replies everyone. How difficult would it be to implement a system that kept a log/history of which code was used at which time?
I believe LCM has this option already?
1 Like
@oranjoose Chris is correct. This exists in LCM. Just click the Reports button.
You could even use RM to send a per user IFTTT trigger to enter it into a google spreadsheet if you wanted a log you could view remotely.
Few comments on how locks work.
All of them, and I mean all of them do not allow codes to be edited, the relevent slot is deleted, then a new code is added.
This is a function of the lock, and is not dependent on the platform, the protocol, the driver, or the app.
There is always going to be a risk in this process such that the new code never gets commited to the lock for one reason or another.
The main and only reason daily scheduling hasn't been added to LCM yet it time.
1 Like
Good point I was forgetting. When you consider a lock like August where that type of thing is a big part of their marketing, that access management is all in the cloud, not the lock.
Now I'm confused. if @mike.maxwell says that every lock possess the same technical limitation which ultimately leads to problems implementing a daily schedule feature, then how are the August locks doing it "in the cloud", as @SmartHomePrimer mentions? Isn't the Hubitat analogous to the cloud from a technical standpoint?
Yes. Sorry to confuse the subject. Let's say for example, you use something like RBoy on SmartThings to schedule a weekly entry time for every Tuesday at noon, with the access period ending the same day at 3pm, and repeating the next week. Every Tuesday at noon, RBoy in this example would have to write the valid code to the lock, and then at 3pm it would have to delete the code from the lock. There's risk in doing this if something goes wrong in that process. It's up to the connection signal, the batteries of the lock, the processor in the lock and the locks memory to get everything right, every time, every week.
Contrast that to a cloud based lock like August. Access it all between the users app and their cloud server. Using this same example schedule as above, when the cloud server authenticates the user based on the schedule and their credentials, it then just tells the lock to open. At the expiration of that access period, their cloud server then denies entry, so the users app effectively loses access privileges until the following week.
Is it possible for Hubitat to do the same thing? Actually yes, but then it's a cloud-based lock management solution, and this platform strives to be as local as possible. Having said that, it is an idea I would be open to as an optional lock manager. Might be just the kind of thing that would be suitable in an app as well.
With all the zigbee/zwave locks I've dealt with to date it is not possible to prevent unlocking the lock with a given code unless the code is deleted from the lock.
These locks do not have a disable code feature.
Denying access requires deleting the given code.
Granting access requires adding the given code.
Sure. Understood. What I was suggesting is a remote access via app only for certain people like housekeepers. Similar to what August is doing with the Yale Assure upgrade, just not that exact solution obviously. This could be an HE version that works with any lock that HE is compatible with.
In fact, as I'm writing this, it occurs to me that HSM could be made to handle lock access control. It would just need an invite and user control mechanism.
