@mike.maxwell Any chance we could see the SecurityKeypad capability drop the duplicate features provided by the lockCodes capability? Or maybe add a new capability with arm/disarm and then just make SecurityKeypad be a combo of those two capabilities?
Point is that I have devices which can provide arm/disarm/etc which don't have lock code management. I don't mind having 1-2 buttons on the driver which don't work, but 5-6 buttons that don't function is a bit much.
So to break into your house.. All I have to do is hit a button to disarm?
There are exactly 4 "buttons" that won't do anything. But as I have pointed out to you on other threads, you are talking about the Admin Gui. Not the normal, everyday, user interface. And asking them to take functionality away is asking them to break other people's systems. That's not very practical. Do you expect every other driver that uses that capability to be re-written?
Plus, it's security KEYPAD. Wouldn't be very keypadish without the codes, would it?
Go back and read what I wrote, as my statements covered both of the cases you threw out here.
That's not how capabilities work.
Ah, let's start with the assumption that someone is incompetent/stupid... 
Actually, no, after a year+ of trying to get Abode to allow tighter choices, I've given up and removed all codes from Abode. There are no codes which can disable the alarm, and the Abode keypad has no batteries in it. The only way to change the Abode mode is from my ToTP 2-factor authentication login to their portal.
Using the driver I wrote, I authenticate Hubitat to Abode and get a token valid for a few days. And yes, if I was stupid, I could configure Rule Machine to disable the Abode alarm from a switch. But since I'm not stupid--and the reason I don't use Abode's security controls-- is that we can now have true multi-factor authentication at the house. Your alarm key code only disarms the alarm if combined with your presence from both the Abode geofence and the Hubitat combined presence, for example.
There's a variety of multifactor ways to authenticate, none of which are capable on the native Abode platform. So it's just a dumb slave to the smarts possible in Hubitat.
I see numerous overlaps in abilities in this list: Driver Capability List - Hubitat Documentation
Bulb, Light, and Switch are identical really. Clearly multiple capabilities can implement the same features. So what are you trying to say?
And to return to your original question:
I've been response for alarms from a dozen different vendors in my life, and more than 40 different keypads, and not a single keypad unit validated or stored pin codes locally. Every one of them transmitted the pin code (or a hash and a seed) to the central alarm system for comparison.
The only "keypad" unit I've ever worked with in my life that validated locally was the old HandPunch scanners which required Lenel to presync all the hand codes down to them.
If you look at the packets coming from the Centralite scanners which is all that is really supported right now, they simply accept and transmit the code. They don't know which codes are valid.
So no... managing lockcodes isn't very keypad-ish at all. It's entirely unlike a keypad.
Well, find me a security keypad compatible with Hubitat that works that way, then we'll talk. Now you're not just talking changing capabilities, now you're inventing devices that don't exist to validate your assumptions!! Are we just going to make it up as we go along?
I've been nothing but factual. Centralite keypads transmit the keycode used back to Hubitat to validate. Again, I have no idea what you think you're trying to say--because everything you say demonstrates you don't even read the debug, nevermind use a scanner to watch how these operate.
Abode keypads, and every other keypad on the market do the same thing. Other than units where the keypad is physically attached to the central alarm (e.g. 199x-era ADT systems) no keypad has control of the alarm system. It's just an entry point. In fact, when I disassembled my 2005-era ADT system it appears to be a single unit but the keypad was actually separate with a wire running back to the central main.
If you're going to imply I'm wrong, put up your facts.
But really, your entire argument is a distraction from the topic. There are many alarms which don't use pin codes at all. So all of your noise is doing nothing at all to explain why you think alarm mode management shouldn't be available as a separate capability -- which is what this topic is about.
We're talking about the security keypad capability. If you aren't going to have the codes as part of the "device" where else in Hubitat would you put them? Now you're redesigning how codes are stored in Hubitat? Dude, you are just painting yourself deeper and deeper into that corner.
Yes....in the DRIVER. Which means the codes have to be in the driver. Which means that the codes need to be part of the security keypad capability. Or are you proposing changing that too? Where else would you want to store the lock codes for the keypad?
Seriously, please stop trying to argue with me. You want to help, then stop trying so hard to land punches. All that is happening is that you're showing that you apparently can't read or consider anything that doesn't exist today.
Here's a hint for you-- lockCodes exists as a separate capability. So a device could have lockCodes without having arm/disarm. Why is it so hard for you to consider a device that arms and disarms, but does not use a pin code? There are dozens in the home market, and thousands in the commercial market. They're not common in residential, but they're hardly rare.
I'll spell it out real slow for you.
My entire proposed change was either to split keypad (require explicit use of both capabilities), or if that was problematic to create a new capability. Anything using SecurityKeypad keeps the same functionality (I said this right in my first post), but it allows support for drivers to offer arm/disarm without hiding it 4 levels deep under Custom Actions.
Now that I've explained it real slow and spelled out for you, can you possibly manage a reply that doesn't spend more than 80% of the words insulting and berating me for something you didn't bother to even explain? Because it's still a mystery to me what you find so objectionable about this really simple proposal. It has none of the impacts you've claimed, not a single one.
I misunderstood what your original intent was.. I thought you were talking about a physical device with arm/disarm/etc without a keypad.
And yes there are overlaps in some capabilities... Just look at the thermostat bits for an example Ryan..
But for them to go and create a new capability and add that functionality to HSM would be a lot for a low use case...
I'm not the one saying that there shouldn't be overlap. He is. Try reading the whole thing before jumping in the middle of something.
Not practical.
Also, maybe you should change the title of the thread. You keep changing your mind.
It's very disruptive to remove capability components once published, since this will always break things.
The same applies to changing a formally monolithic capability into a composite one.
Understood, and I assumed you'd know the right way to do this. Which is why my next question was:
I should perhaps have been more explicit with "a combo of these two capabilities in whatever mechanism is the safest?", which of course you would know.
Sorry about that, my day-job bias slipped into my assumptions here. When you're working with someone else's objects, you are never telling them how to do it, you're talking about the visible impact ("appears to be a combo") and knowing that they'll determine the best implementation.
Is creating a capability a lot of work? Capabilities read like includes. And they've posted in the past about how they build components with multiple pieces of the same code without duplication.
I'm not following that logic. When I go look at the market today, pins are pretty much gone from commercial installations (which tend to lead consumer). And yes, every consumer alarm panel does offer a keypad, but a non-trivial amount don't ship with it in their base product or even their big kits. Abode for example ships all kits with presence tokens, and has focused their market on presence detection and automation around that. None of their kits include a keypad last time I looked. Even a classic alarm panel with a Noonlight integration could be completely driven from Hubitat without pins.
Notably Ring doesn't have any package without a keypad so I'm not arguing that anything goes away.
I'm not saying drop support for pins. I'm saying these are distinct functionality that should be covered by distinct capabilities. Leave the historic combo in place, sure...
Given the feedback so far that makes a lot of sense.
I don't own any ring alarm components.. Just doorbells and 1 floodlight cam..
My keypads are iris v2
Download the Hubitat app
