DynamicGroupController and attributes

[LibraSun]

You're absolutely right to acknowledge that MSR cannot "see" the [Update] of a particular parameter, only [Changes] (blame Vera, not MSR).

There are a couple of handy work-arounds, but I'll focus on Locks in particular.

First, use "Entities" to observe any other parameter(s) that may be changing on your door lock when a key code is entered. Even if "Mike" enters twice in succession, there's a strong chance you'll also see a 'timestamp' or 'lastChanged' type of variable at play. MSR can use such items as potential auxiliary triggers to watch.

Secondly, and this is how I handle my own lock responses... If you create a global reaction (I'll call this "Reset Lock") whose sole purpose is to set the Locks "userCode" to 0 after a Rule has run, and use a [Run Reaction] to call this routine every time your main Rule's Set Reaction runs, then you make it possible for MSR indeed to tell each and every time the Lock gets unlocked.

In this latter setup, you may feel like you're sacrificing the name of the last successful code to unlock the lock. Not really. Your main Rule can also contain a (blank) receiving variable, to which you can assign the then-current value of "userCode" prior to calling the "Reset Lock" helper reaction. I just don't know how important it is for you to have that information stored, so this is up to you.

Good luck!

[toggledbits]

In my lock management, I just set sl_UserCode to "none" (using the x_vera_device.set_variable entity action) as part of my Set reaction when detecting changes in the value (so my logic uses two conditions: sl_UserCode changes and sl_UserCode <> none). This is simple and effective and I haven't yet seen it not work (several months this way at this point).

[MikeReadington]

Thank you @LibraSun and @toggledbits

Resetting the lock sl_UserCode is where I ended last night, but I got tripped up on the proper field values of x_vera_device.set_variable within MSR. I will spend some time with it today and see if I can get this working.

[LibraSun]

This should help you pinpoint it... go back to Vera > Devices > find your lock > click the ► next to it > Advanced > click "Variables" tab > find sl_UserCode > click Edit > look at top of pop-up panel for exact serviceId::parameterName.

Those are the details that MSR will need to have you paste in under x_vera_device.set_variable. Sample screenshot shown here:

Hope this gets you one step further!

[MikeReadington]

Thank you Libra,

I had an incomplete value in "service" when I was testing. I was so close... damnit.

Works now, and thank you for teaching me something.

[LibraSun]

Ha, typos will often result in the creation of bogus (but harmless!) "extra" variables hanging off this or that Vera device.

Ask me how I know this. Glad you got situated!

[MikeReadington]

@librasun, I wish I could say it was a typo, but it was more of a lack of understanding of what I had to set. I had "service" set to "DoorLock1" instead of the full value.

I might have spoken a little too soon on everything working. I sent the command, and it worked, but then I got an alert for a Lua reload.

When I send the command through Vera>device>advanced>variables for sl_UserCode, it works fine, and I can change it to anything without causing a reload.

When I send the command through MSR, it does change the lock value as if I had done it through Vera, but it also causes a reload after about 10 seconds. After the reload, it returns to the last value physically entered into the lock.

Any ideas? I do not think it is formatting because the value sets properly when looking at the lock data.

So close!

[LibraSun]

Hmm, all I can forewarn you about is to check whether you have created circular logic, in which case MSR may be firing multiple copies of what looks to you and me like a single event. MSR is FAST!! Vera likes SLOW.

So, do check, for instance, whether you have a Rule reacting to [sl_UserCode] [changes]. It would naturally re-react when MSR itself changes that parameter on Vera! What you'd need in order to "throttle" that behavior is a Constraint (often used as a safeguard against multiple firing of a Rule).

If your workflow arbitrarily changes sl_UserCode to 0 or "none", then the Constraint could very well read (I'm paraphrasing of course):

[ sl_UserCode ]  [ <> ]  [ 0 ]

or

[ sl_UserCode ]  [ <> ]  [ none ]

so that MSR won't continue to run this Rule when the latest value in that parameter was the one MSR put there.

Hope this helps a bit more!

[MikeReadington]

I only have a condition that lets me see the code (no reactions set) and a global reaction to let me set the code. The lock is not referenced in any other MSR condition or reaction. I was testing by watching the variable on the lock and pushing the play button on the reaction that sets the variable.

I am assuming that the value of "0" works because I can set that value inside of Vera with no issue. I have also tried sending a string that matches another valid lock code. It also seems like if I send that lock (Schlage lever lock) any set variable command through MRS, I get a reload. (Armed, Tripped, whatever)

Here are the screenshots of both the global reaction I use to set the variable and the condition I use to monitor the status.

(I don't know what is up with the pictures, but I attach two and one duplicates)

[LibraSun]

Yeah, the screenshots are hard to see due to the Forum UI mixing them up somehow, but I can still read 'em.

I presume you'll eventually have the Trigger'ed rule call the Global Reaction once you're satisfied with things? Meanwhile, you seem to be saying that Vera restarts or otherwise spazzes in response to the Schlage Lock having one of its parameters set. How odd!

I see nothing overtly wrong here, as far as your MSR setup is concerned.

[MikeReadington]

I am wondering if this comes back to my particular Vera environment. I have another one of these locks, and I am going to set it up on the test Vera and see if the behavior is any different.

[LibraSun]

We'll only be guessing until you crank out the LuaUPnP log from your Vera (by calling <your_vera_ip>/cgi-bin/cmh/log.sh?Device=LuaUPnP) AND from your reactor.log file from your MSR setup, and inspect them both for clues. You need to know what's being sent immediately prior to these reboots.

[MikeReadington]

OK, I think I figured out what is going on.

I added the secondary controller to MSR, and this what I found testing two of the locks in my system.

Primary Controller with MSR interacting Vera Shop entities
Lock physically on controller: Shop back door (Device ID 134)
Lock bought in by bridged Vera: House back door (device ID 410 on primary and device ID 104 shown on primary as house back door 1)
Setting any variable on either lock, with any device ID, causes Lua to reload.

Secondary controller with MSR interacting Vera House entities
Lock physically on controller: House back door (Device ID 96, same device that as appears on bridged primary device IDs 410 and 104)
Setting any variable on the lock does not cause Lua to reload, and the value holds until a door pin code is entered.

I am 99% sure this is all due to bridging. This might not make total sense, but I did the best I could to describe this, and I AM NOT in any way requesting that @toggledbits should look into addressing an oddball problem of my own doing. When I did this, there was no MSR, and I believe MSR has effectively eliminated the need for IP Vera bridging.

[LibraSun]

+1 for un-bridging those controllers if it means you can use MSR as a pass-through instead.
Something in my gut tells me the rebooting Vera is somehow getting "ping-ponged" in such a manner that successive commands become stacked, time out, and trip the Luup engine's fight or flight response.

[MikeReadington]

I was going to dig into the issue further, but it would be a giant waste of time since MSR eliminates the need for Vera bridging.

[LibraSun]

I take it by now you read ezlo's list of "Known Issues" that include the specific issue you've reported? Seems to still be a problem, even with the second release of 7.32 beta firmware. Thus, I believe you're taking the smart route away from bridging.