[Deprecated as of Apr 8, 2018] Smart Home Monitor Exit and Entry Delays (Version1)

Just encountered a very strange and difficult to solve issue that caused the SmartHome intrusion monitor not to trigger and siren not to sound. Fixing it required resaving (with no changes) all SmartHome settings including: Security Away Intrusion sensors; Armed Home Intrusion Sensors, and all Alarm and Notifications settings. I encountered something similar with another Smartapp a few weeks ago where saving the settings with no changes fixed the issue. It feels like something is getting corrupted. I’m going to report this to ST but wanted to give everyone heads up if you are encountering sudden unusual behavior by any previously working SmartApp.

Whie attempting to find and fix this issue, a small reliability improvement was made to the Instant Night Mode Alarm logic and it is now truly instant, no longer subject to event scheduling. Module ‘SHM Delay Child’ was updated on the Github repo, please update your system.

Just wondering, are you using indoor stand alone keypads or outside keypad door locks? If you are using outside keypad door locks, please help me understand why delays are necessary?

I consider your “WebCore alarm system” a good personal accomplishement, but personally I would not use it because: All monitoring sensors are running in the cloud. The actual sensor may be local, but the code is in the cloud. You may wonder why does this matter? Usually it does not, except when the internet connection breaks, then you have no/nada/zilch alarm system. This same issue applies to my smartapp for sensors taken off SHM monitoring, but usually the bulk of a user’s sensors generally remain in local mode with SmartHome providing some backup when this occurs.

One other major issue with doing this in WebCore: Each new sensor requires a bunch of code versus an update to a SmartApp setting. There’s more, but I feel I’ve made my point.

I fully agree the most reilable alarm system is wired, has a UPS, is remote monitored, and uses at least two methods to communicate with the monitor service, but for folks like me who had no alarm system, and do not want to pay a monitor service, Smarthings is a good solution.

Kindly post further updates and code shots for your Pistons on a WebCore forum or your own thread.

3 Likes

Just one indoor stand alone keypad…reason for delay mostly? One word… our ten year old. He doesnt always have his phone, or its dead or its lost and at home and sometimes brings his house key. To buy a presence sensor or use mobile presence exclusively i cant rely on because of him thus the main reason for a keypad and delay. Yes there are the cloud cons of webcore of course…i realize that. My security camera system i just installed is hardwired/local with option to view remotely. I 100% wanted reduced failure of this so i opted out of a smarthings /wifi camera system. The security system is more of a deterrent with the camera system as a 100% backup. If I have no internet I can go to my DVR and always replay my motion alerts. This works for me. Good luck and still great app. Didnt really mean to party on your parade and thanks for being cordial in your request.

1 Like

He there.

I’m using the great project from Connect wired alarm system sensors to SmartThings with a NodeMCU ESP8266 [deprecated] to connect my old alarm to smarthings and it works great.

When I try to now use SmartHome Delay though the app says my sensor “is simulated. Please select a differant real contact sensor”… which I guess it is!

I modded the code to ignore this to get the profile completed but it does not work. Probably not a surprise but I wanted to ask the question as to why the app does not work with simulated sensors? Is there anything we could do do get this working?

Thanks in advance!

Sorry you are having an issue with the app. I have no idea why it is not working.

It should work as long as the monitored simulated contact sensor changes status from closed to open. The editing is there to help the user get a proper setup. I looked at the link in the post and it appears to be using Konnected which already has a workaround built into the editing logic.

Please go into the IDE → Devices, then forward a screen shot of the device you want to use as the “real” sensor. At a minimum I need the data in the Type field. The code changes should be minimal, and we can go from there.

I am having the same issue with the konnected alarm system showing the wired alarm contacts as simulated in your app. The above is a screenshot of my device that is having the issue. Thanks!

Please update SHM Delay Child, then retry and let me know if it works.

That fixed it. I was able to add the delay profiles now. Thanks so much!

1 Like

arnb, thanks for creating this app, I really appreciate it. I’ve also been having trouble getting the SHM Delay to allow me to add a delay to a Z-Wave Garage Door Opener, as it says it’s not allowed because the “Real Contact Sensor” is simulated. I have updated the app just a few minutes ago. If you have any suggestions, I would appreciate it.

Made a minor code modification, created this device in IDE, then successfully tested with it. Please update module SHM Delay Child from the repo or code, retry, then please let me know if it works for you.

That fixed it, thanks!

1 Like

Thanks for the quick reply on this. As per the poster below the issue is now fixed for me althought I’m using an older version of Konnected (must update) so my device type is “NodeMCU Connected Contact Sensor”. I manually updated your code to reflect this and working now.

Thanks so much. Great addition!

1 Like

I’m sure there are more folks without your programming skills running old Konnected versions that may show up here. So…

Changed the official app to accept either Konnect or Connect device as a “real” sensor. Please update module SHM Delay Child from the repo or code, retry, then kindly let me know if it works for you

Really excellent. Working now as stock. Thank you so much.

1 Like

Working great.
Thanks you!

Max

1 Like

[Updated] SHM Delay
Corrected an issue with IRIS keypads: when arming in “Partial” mode from the keypad the “Partial” button did not light.

Update the following modules but do not publish

SHM Delay Child in repository arnbme (in upper case that is ARNBME) / SHMDelay / Master or directly at https://github.com/arnbme/SHMDelay/blob/master/smartapps/arnbme/shm-delay-child.src/shm-delay-child.groovy

Keypad (if using my version) in repository arnbme / lock-manager / SHMDelay or directly at https://github.com/arnbme/lock-manager/tree/SHMDelay/smartapps/ethayer

2 Likes

I updated it and it looks like it’s now working properly for me and my Iris Keypad. Thanks!

2 Likes

I’ve been testing the App and the delay works great thanks. When using true Night and mode fix is changing mode supposed to arm/disarm or do you still have have to arm/disarm separately from mode changes?

So for example if I set the mode to night, the alarm would automatically be set to arm home.

True Night eliminates the entry delay in Armed (Home) mode
Mode Fix attempts to fix the mode when setting armed state from the Dashboard or a Smartapp that sets the AlarmState but does not set the mode

The answer is somewhat dependent upon how the system is being armed/disarmed, your hardware devices, and software settings. That said with everything properly set, arming/disarming from either the dashboard, executing a SHM routine, a keypad, or other device should set the entire system and all devices to their proper state.

Please let me know how your system is generally armed/disarmed, and which keypad if any you are using.

That is correct assuming this means executing the Good Night! routine, and Good Night! is set
Set SHM to: Armed (Home)
Change Mode to: Night

How the app understand when you are coming in or going out if you dont have a keypad but just a smart lock?