I'm having trouble identifying the exact cause of my issue... but I think it might be a bug. This previously worked (to my knowledge) in 3.0. Somewhere in the transfer to 4.0 it fails.
It errors out, and no longer is registering the trigger like it did in the previous version of the rule.
Actually, I said it previously worked in 3.0... but 3.0 didn't have locals. The general concept worked though. In my conversion to 4.0 I'm combining a few rules using locals.
We have already identified internally that Lock or Keypad Codes were not being put in %value%, so that subsequent tests were failing. A fix for this is in the next release.
You don't need to put it in a variable. You can just do this:
IF (Keypad code entered on Back Door Keypad = Andy) ...
That won't work now, but will in the next release.
Will this work subsequent to the trigger (in the next release)?
So the trigger is any keycode, then in the actions, I can test again for keypad code entered?
but Lockcode is not an attribute of a lock (ditto for keypads). So RM always had to treat lock/keypad codes as a special case, holding the most recently used code in state. Since it is in state, that allows Lock Code and Keypad Code to be used as a capability to define conditions.
Playing with it some more, I think I'll need the locals. But only because I have combined two rules that could be separate. I have 2 keypads, and am making decisions off the last keycode entered, not the current state of the keypads.
That said, maybe just some labeling changes:
When this is in an action, maybe it should say something more like "last code entered on Back Door Keypad"
Not even sure it is necessary. Now that I understand, it makes sense. But it didn't occur to me previously, so maybe different labeling would help others.
I mislead you. It's not keeping track on a per device basis, just on the most recently used. It doesn't lend itself to multiple different keypad code triggers, beyond knowing which one was the source of this instance running. But, yes, you can put it in a variable to use later...
Sorry - took a while to get to a test rule. But I think we are talking the same thing. The last lock code on each device can be called at any time (or so it seems)
I think you are right about "last" lock code in the description. That has also made me realize that there is no reason not to keep the last code used for each lock/keypad device used in a rule. Will work that into this next release.
Hi Bruce - I'm still having trouble with this. I believe you put out bug fixes for the issue, but it's still not working for me. I am on 2.1.5.120
I am using keypads - could the fixes have been applied to locks only?
The general idea is I have 2 keypads with the same lock codes on them. When a lock code is entered I need to know whose code it was to make decisions later in the rule. I don't care what keypad the code came in on.
This is the simplest way I can think of to do this. It works as shown below, storing the user to the variable:
I then tested removing the if-then from the actions to go back to the original state - the rule still failed. BUT then after removing the condition with the variable from "manage or create conditions" it started working again.
Side note: Since I couldn't get that working, I considered trying to switch to using lastCodeName - but I think that was only implemented for locks? If I could use it with a keypad, would it be possible to store that to a variable?
This is a bad bug in the way RM handles lock/keypad codes. It's from some leftover code from the change to add lastCodeName. A fix is on the way. Also coming are fixes for keypad drivers to include lastCodeName.
