Evaluating various deadbolt conditions - user PIN, bad PIN


I’m brand-new to Reactor, and to UI7. I’m returning to Vera because I bought a house recently. The last time I played with it, I had UI5 and used PLEG extensively.

I’m trying to do a few things with my deadbolts, mainly set up notifications when:

  • a specific PIN code is entered
  • a bad PIN code is entered
  • I’m sure I’ll think of others as I go…

I don’t know what device properties to use for those in Reactor. Any help would be appreciated!



See this reply on a similar recent topic.

1 Like


Thanks - I did a quick search, but didn’t find this post. I appreciate it.

1 Like


Odd - my Kwikset deadbolts don’t have the same service variables… e.g., sl_LowBattery and sl_VeryLowBattery are available on neither of my deadbolts.

Odder - they’re both the same model but they don’t share the same set of service variables… e.g., sl_LockFailure is available on one, but not the other.



Some of the variables won’t exist until they are needed, so for sl_Failure, for example, at some point somebody fat-fingered the PIN on the one lock, but that has never happened on the other. And some will not be implemented at all, depending on the capabilities of the lock and the extent of Vera’s integration.

Reactor v3 will handle the missing variables more tidily and easily for you, but until then, just use this code snippet (paste into Apps > Develop apps > Test Luup code (Lua) and edit in the device number where indicated) to create those variables in your device(s):

-- replace XXX w/the device number of the lock, shown in parens with the device name in Reactor
devicenum = XXX 
luup.variable_set( "urn:micasaverde-com:serviceId:DoorLock1", "sl_LowBattery", "0", devicenum)
luup.variable_set( "urn:micasaverde-com:serviceId:DoorLock1", "sl_VeryLowBattery", "0", devicenum)
luup.variable_set( "urn:micasaverde-com:serviceId:DoorLock1", "sl_LockFailure", "0", devicenum)
1 Like


Outstanding. Thanks!

1 Like


Unfortunately, these conditions aren’t working as expected, and my suspicion is that it’s related to the variables or the variable states I’m using.

Here are the conditions I’m using to receive notification of a specific user code:

I’m attaching one of the deadbolt Control screens just to show there actually is a PIN code at index 2:

I’ve also got some weird behavior coming from some of the other Reactor sensors I set up… again, likely related to what’s in the Condition tab. My front door lock notification was coming in whenever Vera reboots. It was originally set to send when sl_LockButton equals “1”, but I’ve just changed it to send when sl_LockButton changes from “0” to “1”. Need to test further.

sl_PINFailed evaluating a change from 0 to 1 doesn’t work at all.

I’ve browsed the Reactor Wiki. I think I need to spend some real time with it to figure out what’s going on. That, and I don’t recall how to see Vera logs live to see some of these variables in action… is it http://ip-address/cgi-bin/cmh/log.sh?Device=LuaUPnP ?



You can see in your screen shot of your conditions that the “Current value” of sl_Usercode is not just an index/slot as the documentation suggests, it’s a string with more data. So the docs for locks are incorrect. You’re going to need to figure out how to work with what it’s actually giving you. You don’t need the logs to see the actual values you are getting; they can be seen in the Status view of your conditions, as well as here on the editing view. The Status view is more dynamic, so I would tend to use that. Adjust your condition operators and values accordingly.



So, for example, if I want the condition to become true when the PIN code at index 2 (assuming the username is “wifesname”) is entered… I need the condition to Equal the full string “UserID="2" UserName="wifesname"”? Or maybe just when it Contains “"wifesname"”?

1 Like


Yes, I think that would be the best solution. In fact, I think that’s far preferable to thinking about slot/user/index numbers.



Thanks–I found that this approach works great.

1 Like


Here’s an odd behavior: my sl_UserCode maintains the value Current value: UserID="1" UserName="xxxx" even after my wife enters her code in index 2. It’s as if that is the default value. The Reactor sensor that uses my wife’s code as a Condition works fine, but at some point after that, both deadbolts revert to the value above for sl_userCode. The result is that the Reactor sensor that uses my PIN code for a Condition is always tripped. Weird.

I wonder if there’s something safe that I could write to that variable as a Trip Action.



Sadly, there may not be at the moment. We are completely reliant on what firmware writes to these variables. If we’re not getting the expected values, about all we can do is open bug reports and hope for a change in future firmware.

Let me suggest, however, that you continue to experiment. Is it possible that operating the lock through the Vera UI or by hand is causing this value to be inserted as a default? If so, can you switch all “live” user codes away from slot 1?



It looks like that happens even without operating the lock. I deleted my own code and inserted a random number sequence into the code at slot 1, with the user name “Default.” Then I entered my code back in at slot 3, with my own name. Both deadbolts updated their sl_UserCode values immediately to that Default user:

I added restrictions to allow the code 1 minute of validity, but if I’m honest, setting the validity period for PIN codes in Vera’s UI7 is unclear to me. I set a daily validity starting today at some time, and ending one minute later. I don’t know if that means the code will be valid daily at that time… and if so, what’s the point of setting an end time and date? Eh, that’s unrelated, I’ll come back to it.

Point is, your suggestion seems to have worked. Although, I am not home and haven’t manually entered my own code (now slot 3) yet. I’ll try it later. :+1:t2:

Now… on to figuring out how to know when the deadbolts are locked from the outside…