Have you considered adding what I also believe to be an important "missing" feature of HSM to your app, the ability to temporarily bypass a contact while HSM is armed home? With my prior Nest Secure system I was able to press a button on the contact sensor that caused the system to ignore the sensor temporarily (30 seconds or if the sensor was opened and closed). I really like this feature as it allows someone to exit the home without actually disarming the system. Once the door was opened and closed the sensor became active again or after a timeout if someone pressed it and then didn't actually exit.
In HSM I have achieved something similar using rule machine, some virtual switches, and virtual contact sensors. It's a little complex as it requires several rules to do everything I wanted, but I like the results.
I have a rule that triggers off of a manual operation of my lock (Yale locks with no outside key cylinder) that turns on a virtual switch that another rule uses as a condition determine if it should open a virtual contact when the real contact is opened when armed home. I then use that virtual contact sensor as the trigger in HSM for armed home.
I started off with a simple bypass, but then it got more complex so I actually do a lot more than I'm describing here, but it's pretty slick. I think others would find just the ability to temporarily bypass a sensor using either a switch or button a benefit?
I understand what you want, and how to code it. However, this is the first I've heard about contact sensors with an "ignore" button. Assuming Nest contacts have this option, does Hubitat support it as a button?
i'm no longer using the nest secure system, so i'm not using their contact sensors anymore. I'm just using zigbee contact sensors and a combination of HSM and RM to "duplicate" what nest called "silent exit" feature. It's a bit complex, but it works really well and has a high WAF. The manual unlock trigger is some code I found that monitors the lock events for manual thumb turn operation.
RM rule that triggers the virtual contact if "bypass" isn't ON
RM rule that re-enables normal operation after the door is closed
RM rule that activates the "bypass" switch using various triggers (notice it's restricted to only work when HSM isn't armed away) I have the button and virtual lock trigger so that it can be bypassed if someone comes to the door and we want to let them in "remotely" without hiking down two flights of stairs to operate it manually (townhouse style home) Nest door bell with camera to confirm who it is
I do realize that some of this is way to "user specific" to include in your app, but my point is that being able to bypass a sensor temporarily has benefits, especially if you have "ground level" windows that you would want to open while HSM is armed home.
I agree, your RM code is very user and hardware device specific.
You can do this with Nyckelharpa by disarming, opening any monitored contacts, then force rearming. Not as elegant as tapping a button or many buttons associated with each window.
One idea I've considered is installing a second magnet at a sash window's security stop point. It does not solve wanting to open a window while armed, but allows the system to properly arm with a partially open window, and with some code would allow for closing it.
Hmm maybe an extra long magnet solves this problem?
Module: Nyckelharpa, beta version: 1.0.6 in useModule: Nyckelharpa ModeFix, beta version: 1.0.0 in useModule: Nyckelharpa Talker, beta version: 1.0.2 in use
I have these apps installed everything except force arming works. If I delete the warning on open contact alert HSM will arm even if the contact is opened. If I keep the alert I get an Alert from HSM & sonos saying warning and nothing else from this app. I've tried it out with Sonos One and with Sonos Ports same results. I've tried only selecting 1 virtual contact sensor and all of them with the same result no force arming. DO I need to install any of the other modules if I'm not using a keypad? This is what I get from the debug logs when attempting to arm.
Please update using the Nyckelharpa master repository, or update with the Hubitat Package Manager app. However, the version numbers appear current.
Please let me know how HSM is armed. I just tried the following on my system:
works 100% from the keypad
works if I am fast enough using the dashboard's HSM Status button
does not work using the dashboard's Modes button This is because the mode is always changed on the first attempt, and does not react on subsequent attempts.
After updating your system:
Please retry forced arming
if its a timing issue do the following, then retry
In Nyckelharpa.groovy module, modify line 1742 from
if (duration > 15000 || duration < 3000)
to
if (duration > 30000 || duration < 3000)
It will still say you have 15 seconds but you have 30
Let me know. If necessary I can add an input parameter for the amount of time allowed for forced arming.
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.
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.
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.
How to install
There is one (1) module associated with this update. Manually update, or use the Hubitat Package Manager. Perform post installation instructions.
App Code
Nyckelharpa (V1.0.9)
REQUIRED Post installation instructions
Click/tap on the Nyckelharpa app
Click/tap "Done", establishing an additional system event subscription.
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?
TIA
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?
For comparison
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.
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
