Hi, been a while since I've posted because most things have been working great! One things that has been bugging me for a bit but I haven't gotten around to it (it's annoying not critical) is some strange behavior I've seen with the keypads.
Has there any recent work been done (past few months) to get these to work better? I've reread some of the older threads mentioning somewhat similar things to what I am still observing but most of those are "we'll look at it at some point".
First:
a) if I hit one of the arm buttons from the keypad (partial), and there's an open contact, the keypad continues its arming countdown and eventually shows armed, but I get an almost immediate notification on my phone that HSM failed to arm due to open contact. The other two keypads in my home did not arm.
If I close the contact, I can now arm from either of the other two keypads or from the app, but not from the initial keypad. I need to go through a disarm sequence before it allows arming from that keypad again. So the keypad is out of sync with what HSM is actually doing.
b) again, the notification is not sent at the END of the countdown, it is sent immediately. That means, in order for me to arm and leave my home, all contacts must be closed, I need to hit arm, wait for HSM to receive the signal, THEN open the door and leave before the countdown is complete. I actually don't know what would happen if the contact remained open - I assume it would trigger the alarm. This might be ok (how it should work) except...
Second:
Arming from one keypad starts its countdown sequence. The other keypads do not start their beeping for a few seconds after the first one has started, and finish a few seconds after the first has finished (the other two keypads are also off from each other). All of them seem to be out of sync with HSM's countdown, and the beeps are too short in relation to what the timer is set to. So it's difficult to know how much time is left before the sirens come on.
Are these known issues? Any fixes or different settings I should try?
I have Iris V2, Iris V3, and Xfinity Keypads in use with my Nyckelharpa app and custom Centralite keypad driver. I've noticed the Iris V3 only seems to firmware lock during delayed arming, preventing a disarm prior to completion of arming.
There are two methods to handle the open contact sensor.
In HSM enter the sensor into the "Auto Bypass list"
Use the Nyckelharpa app. It optionally speaks/sends a message with all open sensors and stops arming, you must then rearm within a user defined number of seconds to force arming with the announced open sensors. (Note the app was developed prior to the Auto Bypass option, and I am unsure if all open Auto Bypass list sensors are announced by HSM).
In Nyckelharpa, when an open contact sensor closes after the system is armed, it becomes actively monitored. I assume this occurs with HSM Auto Bypass sensors, but never tested it and cannot be sure.
Regarding the keypad timing differences. Likely zigbee network delays or just maybe an overloaded hub. I've noticed similar behavior, but in my case active keypad countdowns are truncated when the system arms. I also use TTS arming countdown messages with my Fully Kiosk Browser tablets and old phones, and they are always a bit off.
If I remember correctly (it's been a while) it was related to audio issues. Some of them the sounds/beeps worked correctly (dis/arming, open door, etc) and some stopped beeping after they were armed. They were more buggy than the v3 I had, but this was over a year ago. I eventually swapped to all v3s. I'll try the nyckel app see if it helps. The beeps not being sync'd is the least of my issues with these, it's more the keypad showing as armed after an HSM arming fail.
I noticed this issue when I initially switched from ST to HE, prior to using my Centralite Keypad driver with Nyckelharpa. My keypad driver requires the Nyckelharpa app to function, but the beeps and sounds work.
I am using the Nyckelharpa app with the Centralitex driver. I have a UEI keypad and an Iris V3 keypad. They both work great using Nyckelharpa and I have not seen them go out of sync when a contact is open during arming.
Nor have I, and that's likely due to Nyckelharpa not arming, unless forced, with an open contact sensor. I have experienced the V3 refuse to accept a disarm during the arming exit delay time.
UPDATE: The V3 does disarm during exit delay, pin then Off, just tried it.
The Xfinity does not have an OFF key and disarms with a pin only, and for whatever reason the V3 remained silent when entering the disarm pin, although it usually makes key touch sounds. Unless you know better you may beleive it's not working.
So I tried using the custom driver, first difference is that with the default driver, it beeps 3 times when opening a door, and now it beeps 6 times. Second things is that once it beeps, it freezes until I hit refresh (the connectivity light goes off and the keypad buttons do nothing).
It did prevent the keypad from going into an armed state when a contact was open, so that's an improvement (did not thoroughly test this).
If I put it back to the default driver, the beeps go back to 3, it does not stop responding, but it will arm if a contact is open.
I'm having deja vu here, I think part of what I'm remembering with audio problems was having tried this in the past.
I've not experienced the excess beeping issues with the V3, don't use that function, and it's been a long time since I tested it. I use TTS for open/closed with device name messages.
Set the following Nyckelharpa app setting to an Iris V2 Keypad device
The following were already set for the V2 Keypad's in device settings
Opened and closed a monitored window a few times.
Result: Selected keypad beeped 3 or 4 times during the 1 second beep on time, no device freezes.
There are at least 2 respective firmware versions for the V2 and V3, and both devices may need a bit of experimentation to get them working in an acceptable manner. AFAIK it's no longer possible to update either keypad's firmware.
Hope this helps
BTW did you remove the Keypads from HSM monitoring and usage when testing Nyckelharpa and the user device driver?
Ran same tests with the Iris V3 with identical Nyckelharpa and Keypad settings.
Result:
Iris V3 keypad beeped 4 short high pitched tones when door opened, then when I attempted to arm Away the keypad beeped perhaps 12 times and locked. Arming then disarming from another device unlocked the keypad.
Turned off keypad beeping and retried arming with door open. Keypad beeps 12 times then locked.
The V3 was a nightmare to code for, locking on all sorts of conditions that I thought were handled, I'm surprised I never encountered this error. I will take a look at the code when I get the opportunity.
@oldcomputerwiz does your V3 also fail with an open contact? Hopefully all it needs is to receive a disarm command.
I tried it again, removed them from HSM as dis/arming devices, and as siren alerts for the various modes. I've left them as siren alerts for my smoke detector alerts.
I brought all my keypads together for testing. I set one of them to the custom driver and left the other two as the default driver. I am using Lock Manager for pins. I set up a virtual contact. When I open it, I get my voice notification on my Google mini, which is great, the default keypads beep about three times, and the custom beeps six times. I've set the timing to the lowest possible (1s). After they beep, the custom keypad starts having issues. The OFF button is red on the other two but none of the buttons are lit on the custom keypad, and/or it's followed up by all three blinking, then going back to no buttons being lit. It remains in this state until I do something from the UI, like refresh. However, it WILL beep again, even in this state, if I open the contact again. But the buttons do not do anything.
Your results are similar some testing I did earlier this evening. It's only when a V3 initiates the arming, and the arming is rejected, that V3 keypad locks. During the testing I confirmed a disarm command is sent to the V3 when there is an open contact so that is not the issue. When the arming is initiated from another keypad or non keypad device, the V3 works as expected.
I'm sure this was all tested back when, so I'm unsure what changed. The V3 uses no pin at arming, and ignores any pins that may be entered, so it just may be it is expecting a completed arming no matter what, or perhaps it's a timing issue. There are a lot of comments and warnings in my driver's logic regarding the v3 device locking. I was not expecting or wanting to remember this stuff
