Request: Custom attributes for Schlage locks in RM 4.0

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.


1 Like

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.

Are they any updates on support for this functionality?
Determine if Lock Unlocked “Physical” or “Digital” I would like RM to know if my August lock was unlocked "digital" or "physical".

I have August auto-unlock when I arrive home (August feature) or via HomeKit. It would be nice to have it automatically run the "Home mode" when it was unlock "digital" but not physical.

Sounds like they don't plan to implement this. Below is a post with a solution to make this work. A few posts down is a Yale version of the app.


Thanks for sharing this. I never programmed in Groovy before but after looking at the code I think I just need to modify the "evt.descriptionText.endsWith" & "evt.type" statement to match the August lock reply.

Here are the changes I made; I haven't tested this yet (will post an update after I do). But basically this is what I want the code to do (If lock is locked turn on the virtual switch. If lock is unlocked digital turn off the the virtual switch).

    name: "August Lock Events",
    namespace: "rvrolyk",
    author: "Russ Vrolyk",
    description: "Tracks if August Lock was unlocked digitally. Modified by K-MTG",
    category: "Convenience",
	iconUrl: "",
    iconX2Url: "",
    iconX3Url: "")

def lock = [
    name: "lock",
    type: "capability.lock",
    title: "Lock",
    description: "Select the lock to monitor.",
    required: true,
    multiple: false

def virtualLockedSwitch = [
    name: "virtualLockedSwitch",
    type: "capability.switch",
    title: "Virtual Lock Switch",
    description: "Virtual switch that should be turned on when lock is locked and off only when digitally unlocked.",
    required: true,
    multiple: false

def enableLogging = [
    name:				"enableLogging",
    type:				"bool",
    title:				"Enable debug Logging?",
    defaultValue:		false,
    required:			true

preferences {
	page(name: "mainPage", title: "<b>Lock to monitor:</b>", install: true, uninstall: true) {
		section("") {
			input lock
			input virtualLockedSwitch
			label title: "Assign an app name", required: false
		section ("<b>Advanced Settings</b>") {
			input enableLogging

def installed() { "Installed with settings: ${settings}"

def updated() { "Updated with settings: ${settings}"

def initialize() {
    log "Lock status: ${lock.displayName} " + lockStatus()
	subscribe(lock, "lock.locked", lockHandler)
	subscribe(lock, "lock.unlocked", unlockHandler)

def lockStatus() {
	return lock.currentValue("lock")

def lockHandler(evt) {
	log "${lock.displayName} was locked"

def unlockHandler(evt) {
	log("Unlock event: ${} : ${evt.descriptionText}")
	if (evt.type == 'digital' && evt.descriptionText.endsWith('is unlocked [digital]')) {
		log "${lock.displayName} was unlocked inside"
	} else {
		log "${lock.displayName} was unlocked"

def log(msg) {
    if (enableLogging) {
        log.debug msg

If someone can confirm the changes I made won't preform an unexpected action that would be much appreciated!

Btw is their sample code on how to get the current mode and change mode on a UserApp? Might as well have it change the mode directly instead of having RM act on the virtual switch.

Very useful to know, actually.

A "keypad" lock means the device was locked from the outside.

A "physical thumb" lock is most likely from the inside (and, since we're writing our own "rules" to automate things, it's very easy to make that assumption).

So, "keypad lock" means you just left--and should do an "Arm Away".

A "Thumb knob" turn lock means you're in the house and either shouldn't do anything--or should lock "stay" (if all the doors in the house are locked).

That makes for some very helpful automated routines--and a whole lot more straightforward than kludging together a variety of motion sensors and building a full-blow AI engine to determine where the person is. :slight_smile: