Iāve seen a last code name on locks, but donāt recall it ever being on the keypadsā¦
It was there!
Update to 2.2.8.141 (136) and it's not there?
What driver is this?
Stock Centralite
Hit Configure on the device page, and see if it shows up again.
It did not.
Looks like the old ST Driver had Last Code Nameā¦
Last keypad code was never an attribute with any of our stock drivers.
Further it is not part of hubitats keypad capability, so unless it is declared as a custom attribute it will not persist on the driver details page.
Ok, the rule worked.
I updated.
The rule stopped working beyond the exit.
Thank all who has looked at this.
Not a problem, just confusing as to timing.
It used to be there!
I have no clue, and in the greater scheme of this GREAT HE system, no big deal.
Please go back to your terrific work on improving HE !!!!!!
And thank you for your efforts.
Or, may I make this a feature request?
It's probably not the best idea to display pin codes that prominantly, one should use the lastCodeName attribute which displays the alias name assigned to the code, not the actual code.
Not entirely sure what you mean.
I think the effect/loss I experienced may have been an artifact of attempting to use HSM, Nyckelharpa, and it's associated driver and then going back to the stock driver.
NBD
I lost 'lastCodeName' recently as well. I had a reliable means of triggering based on my Centralite keypad, but poof, now it's gone.
If anyone is trying to use the keypad as a trigger, I did have really good luck with the following.
Missing from drop-down:
I use this because the "touch screen" on my kwikset is the worst thing I've ever used. Might as well smash it off the door. Trigger is useful for other things as well. Works 90% of the time on the first try.
Is there a way to parse the device log and trigger based on that? without being an official attribute that shows up on the device page? There's definitely plenty of data to use for a trigger.
Just wanted to point out that I was definitely using the stock driver "Centralite Keypad" and had lastCodeName -- and able to run rules against it per the screenshots. The driver still reports this, but RM cannot use it.
I can't get this to work on Webcore either, but that's nothing new. I was surprised to get it working previously in RM. Any way we can get this back? It's clearly placing a disarm (with code name) in the logs.
I guess I could try to build individual RM rules that trigger for each code, and forget about doing any matching in the rule itself...except that has never worked. This is why I had to build a complicated mixture of triggers, then evaluate the 'lastCodeName.' On top of that, the ability to set variables seems to be missing now in the new version of RM.
So maybe the real bug here is that the keypad code trigger doesn't work right.
See the 2.2.8 release notes about Hub Variables and their use, here: New App Features in 2.2.8
What do you mean, specifically. Please show what you're trying to do.
@bravenel all I am trying to do is take a keypad code entry as a trigger to do something. In my initial testing many months ago, I realized that the actual trigger on Keypad code entry does not work. I built the various triggers above in my screenshot, and that worked about 90% of the time. It was okay.. but then it died completely with a recent software upgrade. This appears to be a known bug, and Mike commented on it here.
Looks like that capability was accidentally damaged and it does continue to impact the keypad code trigger. I attempted to build rules that were as simple as [trigger on keypad code] then [announce device/value] -- no dice.
If the actual keypad code trigger can be fixed, that would be slick. I'd build a case/switch style rule like I had before, and use that to unlock/lock/alert/whatever I want. The reliability of a rule like that would be pretty nice. On my keypad with the default driver, I can enter codes all day and they appear as disarm events, with name. Updates the lastCodeName. I just want to trigger on name change or disarm... read name variable and perform action. boom
Thank you for the link on variables. I'll give it a look. I would just note that RM still lists variables on the category portion, but it was removed in the next level drop-down.
2 Likes
Subscribing to this too.
Rule Machine does not seem to ātriggerā when ālisteningā for codes:
This, for instance doesnāt trigger at all.
This is a known issue, to be fixed in the next release:
1 Like
I don't see any mention of keypad fixes, and this issue doesn't seem to be off any concern to the devs.
Keypads should be the same as lock codes (as far as this is concerned), and I'm not sure why you consider it not to be of concern when it's listed in the document I linked to as something that they are fixing.
The keypad device behavior is different. Lock code has worked this entire time. This is very specific to the keypad device driver. Look at the age of this thread and lack of conversation, and you can make your own educated assumption on priority of this problem.
I have tons of per-lock-code automations, so I know for sure that has always worked.
