I originally figured you could just put in 0.0 then, but I now realize that's kind of stupid. In the next version it will be optional if there is no minimum.
3 Likes
@arnb Thank you for all your dev work - I to recently transitioned from ST to HE. I used the Delay DH from the get go on ST but really enjoy the local aspect of HE. That said I came across your extension and was curious to try for the panic feature on my v2 Iris. This was the only thing I was unable to 'port' over directly to date. I believe I got everything installed correctly, I've read through the forum here and don't see the same issue I'm experiencing. Essentially when I trigger the panic button press, the keypad sounds and I get log event that its triggered but it does not trigger the HSM status - specifically the house siren, nor Noonlight monitoring. Enter disarm PIN from HSM and all goes to normal. I've been testing from a disarmed state. I did read here that removing the NCKL-Panic Contact Sensor from earlier releases, as well as removing delay to the 'Night Arm" but it seemed subsequent updates removed that need, correct? I just installed a couple days ago so I am on the latest release in github. Oddly I see the Keypad not selected under the extension for siren, yet it is the only siren sounding when triggered. I only need the panic feature of the extension so not sure if that is possible with the base HE drivers code (Iris) and just Panic Rule in HSM?
Please read the documentation section 13 for setting up the Panic Rule. The base Nyckkelharpa and Modefix modules are required.
The keypad's siren sounds when the panic key is pressed, irregardless of what it's connected to or the arming state. Using standard HSM without Nyckelharpa, there is NO SYSTEM PANIC response when disarmed.
If you are using the Hubitat keypad drivers, specify the NCKL-Panic Contact, when using Centralitex driver, specify the keypad devices in the custom panic rule and or NCKL-Panic Contact.
Also make sure the panic rule is armed or no Panic response.
Thx for the reply Arn - I went through the README - all checks out as instructed. I've embedded screenshots of the areas of config from the README. I am confirming use of the HE drivers for the Iris, which works as intended for the HSM ARM/Disarm. I basically changed nothing at this point - I can confirm no alerts show in the History of HSM from panic press either.
Erase "For how long? (minutes) or set to 0, then retry.
You may want shut off all the logging reducing system overhead.
Update: Changed the documentation to hopefully prevent this in the future.
[Update] Jun 09, 2020 09:50EDT
Updated Temperature Settings
- Temperature may use 0, 1 or 2 decimals, default=1 (New Input setting)
- Temperature adjustment changed from integer to decimal for finer control
- Units, C or F displays on dashboard
How to Install
There is one (1) module associated with this update. Manually update, or use the Hubitat Package Manager. After installing: on each keypad device, verify and set "Temperature: number of decimals"
Driver Code
- Centalite Keypad (V1.0.3)
Source Code and Documentation
I think I found a bug in your hubitat package manager "packageManifest.json", it appears that you are specifying the "location" of the parent app be installed where you intended to have the "user" app's URL. This is resulting in the parent being installed twice and user not installed at all?
That was corrected. Thank you for letting me know.
1 Like
Thanks for the quick fix.
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 can show some examples of my rules if you wish?
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
One final rule that "re-secures" the door if it's unlocked and not opened within a timeout (accidental trigger or someone changed their mind).
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?
1 Like
Module: Nyckelharpa, beta version: 1.0.6 in use Module: Nyckelharpa ModeFix, beta version: 1.0.0 in use Module: 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.
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.
