Ok, with SLGA back in action, I tried what you suggested and it resolved the issue. You must have attribute settings populated for the toggle to stay at the selected value. And setting the code length to the existing value did not delete my existing codes.
@philh30 In the Config for a lock using your drivers, I see “Lock Codes” defined in the Automations section along with Lock State, Tamper, and Battery Level. However, when I look at building routines in the ST App, I only see Lock State, Tamper Alert, and Battery Level. Is there a way to expose Lock Codes so that they can be used as conditions in routines?
The trouble with lockCodes is that it’s one of the many stock capabilities that doesn’t have a presentation defined, so there’s no way to display it anywhere in the app. There’s no way for me to change the presentation of a stock capability. What are you trying to do? Would lockCodes be on the If or Then side of the automation?
Was looking to see if there was a native way to evaluate which lock code was being returned from a door lock/unlock event and perform actions based on that. As it stands now, the only alternative is to use Sharptools but that requires using their Premium service to evaluate the attributes returned as variables in the event.
So, I’m looking for something on the “If” side of things that says something like:
If
Door unlocks
and
Lock code is 1
then
…do some stuff…
Does lockCodes has to have presentation to be available in IF (condition) part of Routines? Can capability be hidden, and still showing up in Conditions?
There has to be a presentation for the capability to show anywhere in the app, including any part of an Automation. I don’t think Rules have the same restriction, so more is probably possible there. lockCodes won’t help though - it’s just a list of the codes programmed into the lock. The data section of lock is where the codeId and codeName from the most recent lock action get populated. I’m not sure whether you can get to those with Rules though - everything I see makes me think Rules only deal with the value of the attribute, not the data.
One question: were your existing lock codes erased when you shifted to the edge driver?
Asking because I am planning to take the plunge today. I am still on groovy dth and do not have SLGA in my region.
Never has been available through the official routines in the app. No idea why, it’s been requested many times. . But it’s one of the main missing features that caused community members to go to third-party options like Rboy apps (not currently working with the new architecture) or sharptools.
I don’t know if there’s a way to do it with the new rules API, obviously, the information is available from the device.
Finally, took the plunge. Migrated my Schlage 469 from rboy’s dth to @philh30 edge driver.
Everything went smooth, lock took on the driver automatically when re-paired. All my lock codes and other settings remain unaffected. My Sharptools routines working perfectly as earlier announcing lock code ids (names), tamper alerts and jam alerts.
SLGA not available in my region. I am thinking about using lockmanager.io (already installed) or will wait for other options. I can wait as this is my home lock, already set few extra codes and for now can change codes on lock physically, if required.
I would also like to know or a way to identify who lock/unlock the door. I used to use webcore to identify who lock the door then based on that to activate sthm.