Evaluating various deadbolt conditions - user PIN, bad PIN

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…

Revisiting this… I wish I understood sl_UserCode. It’s very inconsistent with what the lock reports for this value. I currently have a dummy code set at slot 1, but the locks are both reporting back the codes set at slot 3. I don’t know why. They’re not even the last codes to be entered.

Still seeking a way to find out which user is unlocking the deadbolt via code.

I may have found a way to know when a user enters a PIN code.

The problem: If a user enters the PIN code in slot 1 for the first time, the value of sl_UserCode is set to a string associated with that PIN code… great. But if that user then enters that same PIN code again, the value of sl_UserCode doesn’t change and there’s no way I’ve found to evaluate that action, or at least differentiate it from a generic unlock. I’ve tried creating a Condition that checks the lock status and sl_UserCode within some number of seconds, but it hasn’t worked out.

In the posts above, I tried “moving” (through iterations of deletion and creation) the PIN codes to slots 2, 3, and so on… and creating a dummy PIN code in slot 1. My hope was that sl_UserCode would revert to the string associated with the PIN in slot 1 automatically, but that doesn’t happen… although having a dummy PIN becomes important in what seems to be working so far.

Possible Workaround: What I realized was that when I modify the validity period of the dummy PIN code, it will set sl_UserCode to the string associated with it. So what I decided to try was to use Reactor to set SetPinValidityDate for the deadbolt every time it’s locked. That way, sl_UserCode for that deadbolt is assigned the dummy value–effectively “reset” from a PIN perspective–each time it’s locked. The next time a valid PIN code other than the dummy PIN is entered, the value of sl_UserCode changes, which is a Condition that Reactor can successfully evaluate.

We’ll see if this sticks. I had to try a few things to get the format of SetPinValidityDate right. This works, although I don’t know whether it’s setting the validity for this period or turning it off:

That’s a fixed date range. It would be nice for robustness if instead I could write a value that’s today plus a year, for example. There’s probably a way to do that with an Expression.

This is exactly what the updates operator tests for. The updates operator will be true when the state variable is written, even if the value does not change (this is what distinguishes it from the changes operator). The sl_ variables are unique in this respect.

EDIT: BTW, the true from updates is a short pulse, so you probably need to add a “delay reset” to see it on the UI, as the pulse is shorter than UI7’s refresh cycle.

Mm, I haven’t used that operator for anything. The only trouble with using it here is that I’m not only checking for an update; I’m checking for an update OR a new valid PIN. I’ll see if what I have works and go from there.

OK, here’s the thing… a new valid PIN is one of two conditions:

  1. The new value written to the user code variable is different from the old value;
  2. The new value written is the same as the old value, but it is nonetheless re-written.

So, if you want to check for user code 6, put two conditions in an AND group:

  • Device state lock sl_UserCode contains UserID=“6”
  • Device state lock sl_UserCode updates

The first test will ensure that the user code matches user #6. The second test goes true when any value is written to sl_UserCode, even if it is the same value it already has. This combination will cause the group to go true on a new valid user code, even if the last user code and the new user code were the same (i.e. same user unlocks the door twice).

This exact behavior, the problem you are trying to solve, is the entire reason for the existence of the updates operator.

That makes sense. I was trying to do the same thing by checking if the PIN was entered AND the lock unlocks, but it never quite worked right.

Did the updates operator exist in Reactor when I started this thread?

It is new for 3.3, so released July 14. I made this announcement.

1 Like

I know this is a little off topic, but I’m curious if Reactor can detect when *Any pin is entered. This is possible with a scene, but there is a slight delay in my action and I’m hoping that Reactor would be faster.

Right now, I have a Smart Handle with the pin codes. I also have a Smart Deadbolt, but no pin codes. It requires the HA hub to send the lock/unlock. My scene now is if Any Valid Pin is entered in the handle, unlock the deadbolt. And vice versa if the lock button is pressed.

Can Reactor detect Any Pin entered?

EDIT: I see from other threads that this could be done via sl_PinFailed = FALSE, for a valid pin. However I don’t have that variable.
2019-09-24_192240

The variable to watch is sl_UserCode, which is written each time a correct PIN is entered. Since you don’t care what the value (PIN) is, just use a single device state condition with the “updates” operator. It takes no operands. It goes true briefly every time sl_UserCode is written. The pulse is shorter than the UI refresh time, so for your comfort during testing you may want to add a “delay reset” option (or change the output mode to “pulse”) to stretch it out long enough that the UI refresh picks it up and displays it.

Thank you.
Is there a way to define a condition using a PIN with restrictions? I would like to restrict the door to unlock only during a certain time frame. The PIN is accepted in the door handle, and updates the sl_UserCode, but the lock itself doesn’t unlock. However it sends the command to the Deadbolt to unlock since the PIN was a valid one, but ignores the time restrictions.

Logically, would this work?
If sl_UserCode Updates AND Door Handle goes from locked to unlocked, unlock deadbolt.

EDIT: My logic was correct. The deadbolt only unlocks if a valid PIN is entered AND the lock goes from Locked to Unlocked. Thanks Rigpapa for your assistance. Coming from PLEG to Reactor is pretty easy, but I have had a few questions along the way. I’m liking Reactor more and more.

1 Like

Good job figuring that out. You seem to be adapting quickly!

Thanks again. The last one I need to test, unless you know off the top of your head, is the sl_LockButton. I know in Vera native, and Pleg, it treats it only when the Lock Button is pressed. Last night though, when I had sl_LockButton defined as a condition, it was showing true when the lock was manually locked. I only want it to show true when the physical exterior button is pressed and not when the lock is manually locked on the inside.

I think there’s a Vera implementation bug here; has been for a long time, AFAIK. At least on my lock (Schlage), sl_LockButton is never anything but “1”. Doesn’t matter how I unlock, whether through Luup action, knob, or lock button, it’s always “1” and has been forever. But, like the other variables on these devices, it is written “1” when it happens using the lock button (only), even when already “1”, and you can detect that with updates. Just use an AND group with two conditions: sl_LockButton is TRUE, and sl_LockButton updates. That will ensure that if it ever does get fixed and changes to false, you only trigger in the correct (true) state.

1 Like

I’ve recently come back to this. While my “update PIN validity date” workaround worked, I wanted to get this updates function to work because it represents what I actually want this Reactor to do.

It seems to be working fine with a 5-second pulse on the update:

I haven’t run into issues with these Conditions kicking off the wrong Activities, but I’m wondering if some sequence should be put in place to prevent it. Right now, the only restriction or output control is that pulse on the updates function.

You should not need any pulse (or delay reset if you use “follow” mode) at all. The only reason to mess with the timing is so that you can see the event on the status display. Vera’s UI refresh rate is otherwise too slow to catch it. So as long as you understand that the pulse/delay isn’t adding any functionality, just your comfort on the display end, you’re fine.

1 Like

Ah, it’s the UI refresh only… well, I’ll test without the pulse and see how it goes.

EDIT: no pulse, works just fine.

1 Like