Tracking last used pin on locks

Plugins & Plugin Development openHAB MiOS Binding
#1

Has anyone found a way to get the last used pin on a door lock (Specifically, in my case, i’m using a Schlage BE469)?

Vera reports this as sl_UserCode service ID. For instance:
<state id=“80” service=“urn:micasaverde-com:serviceId:DoorLock1” variable=“sl_UserCode” value=“UserID=“1” UserName=“John””/>

Using the item file generator out of the box, the sl_UserCode is set as a number by default, which is the wrong datatype in my case. Updating the item to string is the first step. However, after taking this first step, some transformation still needs to be done since the default output is not really usable. With the preceding example, the item value would look like this:

UserID=“1” UserName=“John”

Any suggestions on capturing either just the UserID or Username?

Thanks!

#2

If you declare it as a String, then you should be able to apply an “in” filter in the MiOS binding to REGEX the bit of data you need before its value if put into the openHAB Item.

Can you file a tracking issue in github for the issue? I’m slammed at work for the next week or so, but this’ll will give me the reminder to really fix it.

#3

I also just sent you an invite for the openHAB forum. If you post there using @guessed, then I’ll get a specific email notification of the discussion. It’s easy to lose posts here in the mess.

#4

Yes, good idea, I’ve just filed a new issue on github: MiOS Binding - Tracking last used pin on locks · Issue #3317 · openhab/openhab1-addons · GitHub

I’ve been lurking on the openhab forum, but haven’t had a chance to actively post just yet. Would it be helpful to move this sort of discussion there in the future?

I’ll play around with your filtering suggestion. I think that points me in the right direction and hopefully I can get it to work. I’ll update the git request if i do.

Thanks as always!

#5

Here’s what I do to get the code name:

[code]
rule “Back door unlock by code”
when
Item BackDoorLockslUserCode received update
then
if (BackDoorLockslUserCode.state != Undefined && BackDoorLockslUserCode.state != Uninitialized) {
val Pattern pattern = Pattern::compile(“UserID="(\d+)" UserName="(.+)"”)
val Matcher matcher = pattern.matcher(BackDoorLockslUserCode.state.toString())

	var msg = "Back door unlocked by"
	if ( matcher.matches() ) {
		msg = msg + " code " + matcher.group(2)
	} else {
		msg = msg + " unspecified code"
	        }
        pushover(msg)
}

end[/code]

#6

Wow, that’s a great suggestion. I’ll try that until I have time to patch the binding. Looks like it’ll work great. Thanks!

#7

For [tt]UserCode[/tt], which one do you want to be the default that’ returned, the “UserID” (Integer) or the “UserName” (String)

I can make either the internal default [tt]in:[/tt] Transform for [tt]sl_UserCode[/tt], or I can leave it as the original string (and just have it as a String that the user has to decode themselves.

BTW, if you only want one of the sub-fields in a Rule, you can also just openHAB’s built-in [tt]transform[/tt] method, since it’s wrapping the relevant [tt]Pattern[/tt]/[tt]Matcher[/tt] code:

rule "REGEX Test 2" when Time cron "0/10 * * * * ?" then val VAL1 = BackDoorLockslUserCode.state.toString() logInfo("regex", 'VAL1: ' + transform("REGEX", "^UserID=.(.+). UserName=..*.$", VAL1)) end

(The REGEX isn’t correct, but it’s near-enough)

Anyhow, I have a prototype of this, but it involves tweaking some of my MiOS binding code, in addition to having the generator emit the default [tt]in:REGEX(…)[/tt] transform so users can tweak it directly (to either [tt]UserID[/tt] or [tt]UserName[/tt], or none (the default, so far))

#8

I submitted a PR for this as:
MiOS Binding: Issue #3317 Tracking last used pin on locks. by mrguessed · Pull Request #3377 · openhab/openhab1-addons · GitHub

Once it’s in the main code I’ll update the doc to include the details but, in short, for every lock I now build a set of “UserCode” Items:
a) [tt]String xxxxxxUserCode[/tt] - the original source value from MiOS.
b) [tt]String xxxxxxUserCode_username …[/tt] - the [tt]UserName[/tt] sub-field, decoded.
c) [tt]Number xxxxxxUserCode_userid …[/tt] - the [tt]UserID[/tt] sub-field, decoded.

These have an [tt],in:REGEX(…)[/tt] construct on the binding that’ll peel out the relevant parts for scripting. I also fixed another bug along the way, relating to multiple Bound Items attached to the same MiOS UPnP StateVariable. Probably didn’t really hit anyone, but it surfaced when I write the extra

#9

[quote=“silencery, post:4, topic:189079”]I’ve been lurking on the openhab forum, but haven’t had a chance to actively post just yet. Would it be helpful to move this sort of discussion there in the future?
Thanks as always![/quote]

Yeah, I’m more likely to see it when posted there, since I get Email (etc) when I’m tagged… which sets the reminder that I need to do something :wink:

#10

[quote=“guessed, post:7, topic:189079”]For [tt]UserCode[/tt], which one do you want to be the default that’ returned, the “UserID” (Integer) or the “UserName” (String)

I can make either the internal default [tt]in:[/tt] Transform for [tt]sl_UserCode[/tt], or I can leave it as the original string (and just have it as a String that the user has to decode themselves.

BTW, if you only want one of the sub-fields in a Rule, you can also just openHAB’s built-in [tt]transform[/tt] method, since it’s wrapping the relevant [tt]Pattern[/tt]/[tt]Matcher[/tt] code:

rule "REGEX Test 2" when Time cron "0/10 * * * * ?" then val VAL1 = BackDoorLockslUserCode.state.toString() logInfo("regex", 'VAL1: ' + transform("REGEX", "^UserID=.(.+). UserName=..*.$", VAL1)) end

(The REGEX isn’t correct, but it’s near-enough)

Anyhow, I have a prototype of this, but it involves tweaking some of my MiOS binding code, in addition to having the generator emit the default [tt]in:REGEX(…)[/tt] transform so users can tweak it directly (to either [tt]UserID[/tt] or [tt]UserName[/tt], or none (the default, so far))[/quote]

Good question. I was thinking about the same thing.

For me personally, I’d prefer username as the default value since I have several locks and not all codes were programmed in the same order, which means the UID will not always be consistent across locks. This means having access to the name is more useful in my case.

I believe many others may have similar situations, but of course, I can’t speak for everyone.

#11

I decided to publish all three values (as above) instead of picking one to use. Then the consumer can use whichever makes most sense to them, and I don’t break compat for anyone using the original sub-encoded value.