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:
I don’t know what device properties to use for those in Reactor. Any help would be appreciated!
Thanks - I did a quick search, but didn’t find this post. I appreciate it.
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)
Outstanding. Thanks!
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"”?
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.
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. 
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:
So, if you want to check for user code 6, put two conditions in an AND group:
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?
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules
