Hi Arnb, I went ahead and uninstalled/reinstalled it's working fine with armed away without even putting an alert for opened contacts. Any other then that same problem, I'll have to quadruple check my settings for arming home/arming night but I'm pretty sure arming night is exactly the same. I'm arming the system with HSM Dashboard & Buttons. Same results I'll try out those entries also.
My apologies the Beta module message was caused by an out of date Version check file, now corrected.
I was able to reproduce the issue by attempting to arm from the dashboard HSM status. I'm attempting to figure this out.
lol yeah this is funny if a go into HSM and enter alerts for arming failures and just select the sonos for audio alerts without inputting something to say I end up getting the warning alert from this extension when arming still can't force arm it though just get a repeat of the waring alert.
I appears HSM issues an immediate Cancel on the second and subsequent arming attempts from the dashboard after the first arming is canceled.
Thanks for looking into it I'll just use it without open contact alert notifications. I'm using HSM with a Konnect board so I doubt any of my sensors are going to fail anytime soon.
[Update] Jun 20, 2020 13:50EDT
What Changed, Nyckelharpa module updated
- Fixed force arming failure when arming from Dashboard HSM status or other non-keypad source
- Reduced system overhead
- Documented a revised method for establishing an HSM arming alert, eliminating possible lost messages with some TTS devices.
How to install
There is one (1) module associated with this update. Manually update, or use the Hubitat Package Manager. Perform post installation instructions.
- Nyckelharpa (V1.0.9)
REQUIRED Post installation instructions
- Click/tap on the Nyckelharpa app
- Click/tap "Done", establishing an additional system event subscription.
Source Code and Documentation
Although my system is working great,, I have 1 of my 2 iris V3 keypads eating batteries like mad. Lost 14% capacity in 2 days, and steadily declining, whereas the "good" keypad is on the same set of batteries for almost 8 months, and that's the one we use mostly.
Both keypads are using the centralitex driver. With the problem one I have paired, factory reset, moved it 5 feet from hub, it just won't stop eating batteries. It does the triple beep each time I re-pair it and connects no problem, and the lights on front respond correctly and are not on all the time.
It uses the old style beep if that's relevant.
Anyone have any ideas?
My totally unscientific guess is either:
- Firmware, but as we both know, updating the V3's firmware is likely never to occur.
- Zigbee mesh, although at 5ft from the hub that should not be an issue.
I prefer the more accurate Volts to %. Also which battery types are in use with your V3s?
Alkaline, Lithium, Rechargeable?
On 2020-05-19 four fresh Duracell AA alkaline batteries were installed on my mostly unused V3, and the device reported 6.4 volts. Four days later it reported 6.0 volts, today it's reporting 5.6 volts. My device seems to work down to perhaps 3.0 volts.
One other thought. Is motion frequently triggering the lights on the unused V3?
Thanks Arn, my mesh is solid, in about 1200 sq ft I have 5 xbees, 2 tradfri repeaters & 2 tradfri bulbs, 1 samsung plug & 1 lightify plug, plus xbee scans report good signal.
Great thought about the motion, I will move the keypad, even tho mostly unused, it was in the breezeway with a lot of foot traffic , setting off the motion sensors.
I am using the same alkaline batteries in all my v3 keypads. If/when things settle down, I'm going to try cycling through 2 sets of eneloop rechargeables. I did switch to voltage display
Thanks again for all your work on the driver & app, it's really great.
I got sick of feeding my iris keypad with batteries and hardwired it into a LI-ion power pack. Highly recommended it !
Thanks for the suggestion, but for me that's a solution that seems like giving up. due to the fact I have 2 other keypads working fine.
I do notice a difference in the state variables from the devices' page, and it leads me to believe the issue is related to pairing somehow, as problem keypad has motion timeout, but good one does not
That looks more like different firmware on the device or different driver.
Try switching the device to the system provided Iris V3 driver, then use the Configure button, switch the device back to Centralitex driver.
Many of the state variables are set by the system driver, but not used by the Centralitex driver.
I thought that, but have had this experience before. My guess is that during paring something is not identified or picked up correctly and I think it has to do with the drivers present in my system, as I believe they are referenced when the hub tries to pair the device, to figure its capabilities. I'm a bit of a hoarder, I have 4 different versions of the centralitex driver, plus the native HE drivers and another random driver for the v3 keypad. Going to clean them all out and try again
I use the Centralitex driver, and switch between them when testing without an issue.
I hardwired mine with a 3v transformer for 2 of them that were near outlets anyway.
A good solution for any Centralite/Xfinity and Iris V2 keypad eating batteries. The Iris V3 and EUI both use 4 AA batteries, reporting 6 Volts as 100%. I'm sure there is a 6v transformer out there should someone want to do this.
updated to latest driver. I noticed that when I hit "beep" from the device page, motion immediately goes to active with the 1.03 driver and a V3 keypad
Is this expected behavior?
No. However, the beep code is unchanged from 1.02. Tried a Beep on my Iris V2, it beeped without lighting up.
I have no idea why the V3 lights up.
I just stumbled across your work a few minutes ago and I really like it. Very similar to Smartthings. One question: I created a rule to try to beep the keypads when doors were opened (didn't work well -- keypad volume) . Do I need this rule when using your driver?