Request: Custom attributes for Schlage locks in RM 4.0

The event log for the Schlage BE469 shows when it is locked/unlocked by thumb turn, and when it locked digitally, as shown below:

dev:1893 2019-09-14 22:23:17.823 info Front Door Lock was locked [digital]

dev:1893 2019-09-14 22:16:43.751 info Front Door Lock was unlocked by thumb turn [physical]

dev:1893 2019-09-14 20:31:01.565 info Front Door Lock was locked by thumb turn [physical]

dev:1893 2019-09-14 20:28:28.306 info Front Door Lock was unlocked by thumb turn [physical]

Will it be possible to get "unlocked by thumb turn [physical]", "locked by thumb turn [physical]", and "locked [digital]" as custom attributes for triggers?



I get your request, but if you make a rule where the lock is changed (trigger), and it wasn’t unlocked by one of the codes, then it was physically unlocked by thumb turn or key.

Wouldn’t work for locked by thumb turn, but I also can’t think of how that would be valuable to know, vs if it was locked by pressing the Schlage button. Seems for locked, it’s most important to just know that it is indeed locked.

I'll give you a use case. If it's locked by thumb turn, then the person doing the locking is on one side of the door. If it is locked by keypad, then they're on the other side of the door.

So I guess "locked by thumb turn" and "locked by keypad" would be the custom attributes I'd like to use for triggers.

1 Like

While I’m not disagreeing that it would be valuable attributes to have available, you could use a motion sensor and the door locking to make that determination.

Having custom attributes that are supported by the lock would be heck of a lot less work for me ....

RM does support custom attribute triggers and conditions. But they have to be attributes that the device reports.

1 Like

So, am I correct in assuming that although "locked by keypad" etc show up in the event log, they are not reported by the lock for use by RM?

That's a shame. Oh well.

I don't know, not familiar with this lock. Show the lock device status from the right side of the device page. That shows all of its attributes.

Or start to create a custom attribute trigger, and show the pull down list of attributes that are available.

1 Like

The custom attributes correctly show exactly what is under lock device status.

And "locked by thumb turn" and "locked by keypad" are not among them. So that's a good reason why they can't be used with RM. Maybe if there was a different device driver available .... but that's a whole different story :slight_smile:

Please show the screenshot of the device page.

Yep, nothing there to go on. Let me think about this one, as there may be a simple way to add this ability by offering the last event description text, which is where you are seeing the details of how the lock was unlocked.


It would be awesome if that turned out to be possible.



Be aware that triggering events from description text is risky. Description text is an optional attribute for an event, and the text itself isn't guaranteed to be the same across different devices and drivers for the same type of event since it's not defined nor constrained by any schema, this also means it could change in the future...

Would it be better just to add an attribute like lastLockType or lastUnlockType (physical or digital)? Maybe I'm thinking too specifically about this issue, but that was my initial thought, otherwise the only thing that seems reliable enough to me would be to awkwardly search the description text rather than triggering off an exact string.

1 Like

@aaiyar :point_up:t2:What @mike.maxwellsaid, so...

A motion sensor at the front door is quite handy for other things too. Auto porch lights ON, extra trigger for Auto Unlock and arrival status, security, etc. since you’re in a warm climate, battery drain in Winter does not exist like it does for me, so you just stick a sensor outside your front door, write the rule and you are done.

Alternately you trigger from the inside with a Xiaomi motion sensor. Even easier and cheaper, but your arrival and added security benefits that and outdoor motion sensor offers are reduced.

Yeah, formalizing would be the way to go, this howerer requires a minimum across the board attribute set applicable to all devices of a given class, and with locks this is difficult.

Fair enough, with the caveat that there's already a specific driver for BE468/BE469 locks.

Sure, but my point is that defined capabilities and attributes only are appropriate to implement when they are applicapable to entire device class.

1 Like

Fair enough.