True, I have one.
When the A&B keys are simultaneously pressed, it beeps twice, creates a light show on the mode icon buttons, hardware sends nothing.
Sorry, it’s acrually a V2. I could swear I ordered a V3 but guess not. The V2 plays nicely with HSM and my V1 keypad.
Hopefully they’ll get all the functions on the newest keypad working soon.
No update on this issue yet?
@mike.maxwell or @bravenel, no news on the issues with the Iris keypad? This is affecting both the gen2 and gen3.
In my testing last week with the Iris gen 3, the only issue I noticed was that exit delay count down beeps didn't work correctly on the V3, the arming however did respect the exit delay.
Is there some other issue that I'm unaware of?
When arming from the keypad HSM doesn't ever go into arm-delay. If you look at the status in HE it goes directly from disarmed to armed-away. I thought it should go to arm-delay. Is that not true?
Also, with 2 keypads connected and the system is armed from keypad #1, the arm-delay countdown on keypad #2 begins after the arm-delay count-down on #1 is complete and the system is in fact, completely armed.
Also, can you tell me why the "securityKeypad" attribute is showing up as a number when it's actually text? It shows up as armed away or disarmed but when I was trying to subscribe to that through another method it was reporting back that it was actually a number. That doesn't seem right to me either.
I think I see whats going on here, though there isn't a simple fix actually.
Having multiple keypads:
-
if you change modes from HSM, or command HSM to change modes
- All the keypads should arm disarm at about the same time, irrespective of the sounds they do, or do not make.
-
If you change modes from an individual keypad the following happens
- The activated keypad begins it's countdown (using it's local settings)
- At the end of that delay, the keypad mode changes, and HSM mode is updated
- HSM finds other keypads, and updates them with the new mode, if they have delays set, they begin their own countdown, then change mode at the end of that timeout.
To get around the latter issue, a new event would need to be created that indicates a mode change is pending, which would include the local keypads timeout setting, HSM would subscribe to this, and notify any other keypads of the pending mode and the configured timeout...
Sounds very complicated. Let me ask you this, is there a way to subscribe to the keypad being armed away via rule machine? The iris V3 doesn't have a countdown timer anyway. So, I I was able to subscribe to its alarm status (armed away, armed home/partial and disarmed) I could just have HSM mirror it. That's really all I need at this point. If I remove it from HSM and set the exit delay to zero and mirror it with RM, it should use the default HSM exit and all would be right with the world.
I tried to use @bangali's WATO to subscribe to the alarm status but it appears the driver has it defined as a number but the status is a text string. Short of getting the status in RM, can we at least fix that? Either get it to be a number or get it defined as a string? That would work fine for me... Then you guys can decide if you want to change HSM to address the 2 keypad thing.
Not true, the delays work just fine, what doesn't work are the count down beeps.
The arm modes are strings, and they are defined in our capability documentation
https://docs.hubitat.com/index.php?title=Driver_Capability_List#SecurityKeypad
I think we're missing one, arm night, which will be added in the next capability update.
This includes the night mode for Centralite 3400?
Thanks
I'm sorry, I'm confused then. I thought you said that if you armed from a keypad it would use its countdown, then when the system was armed and the other keypad would start its countdown. That isn't right is it? You have a keypad doing an exit delay when the system is already armed.
Also, during that "limbo" where the system is armed but keypad 2 is counting down, if you disarm the system, it rearms when it hits the end of keypad 2s exit delay. It is very possible to get into a loop with this.
I will look at the keypads armed status again but it was not matching. I will report back one way or the other.
To summarize, Is HSM working the way you intend it to as far as dual keypads goes?
If no, are you planning on making a change or is this just the way its going to be? I don't mean to sound flippant, I just want to know if this is that way it's going to work so I can decide how I want to set my system up. I also don't want to burn a whole lot of time of a tough work around if it's going to change at some point. And if you are going to make a change, no, I'm not going to ask when. I know you guys well enough by now not to bother with that question.
And thank you for looking into this further. It does sound like you are seeing what I am seeing.
We didn't foresee this situation. It would be reasonable to expect both keypads to timeout at the same time when triggered by a keypad. I dont know how much attention this will receive in the immediate future, it's not on the adjenda for 2.0.5 at this point.
It's actually rather simple to do this, in my humble opinion.
-
When any keypad arms with an exit delay, issue the keypad hardware exit delay command to all keypads, so all beep.
-
Issue the away mode/status command with the exit delay associated with the issuing keypad or system exit delay time if no keypad delay time available for keypad.
-
When mode/status changes, cancel delayed arming command. Issue off hardware command to all keypads to stop beeping. When status changes to disarmed optionally issue TTS 'Arming cancelled''
I'm guessing much of this logic is already in place and just needs some minor tweaking. Obviously I can't see the code in HE, but this is how It is done in my ST SHM Delay smartapp.
1 Like
Does the keypad report back when it is starting to arm or when it's complete?
1 Like
Neither, Centralite models including Iris V2 and Xfinity report user arm/disarm requests that may include a pin, and panic requests on Iris V2 and Centralite V3.
Keypad exit/enty tones are sent to the device as a hardware command including the duration in seconds.
Okay. So, I'm confused.
When the keypad is armed physically by pressing the arm away button, is that sent to the hub at the beginning of the arm delay or the end? Or Both?
The issue I'm seeing is not when the arm away comes from somewhere else in HE, like a rule. But instead when the keypad in armed physically on the keypad.
At the end as that is when the state changes to armed
Just thought I'd tag to the end of this thread on my keypads. I have two v2 and one v3, and the v3 does exactly what was discovered by Mike through testing.
I'm actually not bothered too much by the fact all keypads that did not initiate the arm-away mode don't start their countdown until after the initiating keypad counts down to zero, by then I'm halfway down my driveway and on my marry way. As long as they all are in sync for intrusion delay (when I open the door coming home), I'm good.
However if there's any option to get on Hubitat's agenda to see if the no-beep (both on the arming and intrusion delays) is fixable that would be very nice. Thanks, Dennis
But the V3 keypad doesn't beep for intrusion delay. At least not after about 10 seconds.
