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.
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