Forgive me I misread the message thought it was an entry delay, but it is an exit delay. Please go to the first message in this thread (release notice) and check that your Lock Manager keypad settings agree with the suggested setup. It seems like there is no exit delay. I prefer the Lock Manager delay to the one in this app. If you are not using Lock Manager then use the delay from this app.
I am using lock manager, and I do have the exit delay set to 0 because lock manager is set to 30 seconds. still getting the same error. grrrr, its getting late, ill see if I can look at this better when Iâm more awake.
check to be sure the real front door sensor is not being monitored by Smart Home security.
the real front door isnât monitored, all other doors and windows are monitored. Getting the error that the simulated door is open seconds before the countdown from the keypad
Execution timing in ST is notoriously innacurate due to the way the server functions and delays caused by the internet. However, that should not cause the issue you described.
If I understand this correctly: You set your keypad into an armed mode, then the alarm immediately triggers an intrusion state with the âSImulated Sensorâ as the open triggering sensor. BTW what armed state are you setting and are the exit tones sounding on the keypad?
Not sure how this could occur because SH when armed will send a message after one minute about any open contact sensors rather than immediately trigger and alarm. My app takes over this function for the replaced real sensors.
Prior to the next attempt, go to the phone appâs âMy Homeâ device list, are any sensors used by the app open?.if yes, get them to a closed state. If the simulated sensor is open, tap it closed. Retry.
If it continues to fail:
Are there any other active Keypad routines or WebCore/Core pistons (besides Lock Manager and my app)? If true please remove or disable them and retry.
If that is false or the issue continues
Prior to making the next attempt go to the IDE Live Logging
Do what whatever you do to arm the system.
Send me a copy of the messages.
Note your keypad codes are unencrypted and show in the log, so if you have any concerns xxxx out the code numbers
ok, so I tried this again with eliminating every contact sensor except the simulated one, and its still giving me an intrusion. I forgot to do logs, but this isnât making sense
Does your system arm normally if this app is removed and Smarthomeâs security sensors set to previous settings?
If yes continue on with the folliowing:
-
In SmartHomeâs Security:
Sensors When home is unoccupied and When home is occupied
Use every open/close sensor: off/false
Open/Closed Sensors:
Set then select contact sensors including simulated sensor used by SHM Delay app; excluding any Sensors monitored by the SHM Delay App and be sure to exclude all keypads that show up as a sensor
Motion sensors: select for unoccupied mode, Set none in occupied mode -
This appâs code was recently updated, verify you are running with the latest versions of both modules. Set and verify global settings on the parent app, then verify all Profiles and settings
-
Arm the system in Away mode: Should get exit tone beeping when set, and entry tone beeps after system arms, then door is opened.
-
Arm the system in Stay Mode: Should give immediate arming, entry tone beeps when door opens
-
Night mode icon should work similarly to Stay icon mode. SmartHome has 2 armed modes, the Xfinity system has 3 armed modes. Due to this the âStayâ icon will light when âNightâ icon is used for arming. This is a side effect of using the keypad in SmartThings. In the Xfinity system, Night gives an immediate intrusion alert, Stay give an entry delay, but otherwise are identical. My app currently issues an entry delay in stay/night mode, however Iâm almost done with an option that allows a one time choice to run with or without a delay in Stay/Night mode.
Should you continue encountering issues, please send me a private messsage including: telephone number, time zone, and some good times to call.
.
I believe I have it all updated and running smoothly now! thank you kindly for your patience! keep up the good work!
Will you be supporting motion sensor delays as well?
No plans to delay motion sensors.
Iâm on step 5 of the Quick Setup Guide. I have a real contact sensor which is on my garage door. I have a simulated contact sensor called AlarmDelaySensor. I have removed the Garage Door sensor from SHM. In SHM Delay Child Iâm getting an error: The âReal Contact Sensorâ is simulated. Please select a different real contact sensor or tap âRemoveâ
The Real Contact Sensor is set to the garage door which IS a real contact sensor. Any suggestions?
Please go to the IDE devices and click on the device creating the error and send me screen shots for the device. Also please include the manufacturer and if it is wired or battery operated . After reviewing the information Iâll do what I can to create some code to allow the device.
Should you want to check it out
If Type contains the word âSimulatedâ (case insensitive)
or
Data Manufacturer is null and Model Name is null and Battery state is null
either condition assumes the device is simulated
Please update module SHM Delay Child via the repo or copy from github and let me know. Made a minor change to accept âKonnectâ type devices as real, but am unable to fully test it from my location.
Thanks for the update. That got me part of the way there, but not all the way. It appears that neither of my sirens support the âbeepâ command. Here is a screen shot of the SmartThings Log.
For now I suggest removing the failing sirens from any profile(s)
The Profile edit will be adjusted to reject sirens that donât support the command.
Still not working. I removed the Beep functionality from all sirens. I armed the system in SHM. Then opened the basement door which is tied to the AlarmDelaySensor and nothing happened. I didnât get a push notification or a text and the alarm didnât go off after 30 seconds.
The log varies from what was stated, perhaps it was truncated. From what I can see from the log
- The system was armed ( I canât determine the mode, likely away?), but a door was open(ed)
- the Open Door monitor was started, but terminated in 7 seconds when the door was closed
App appears to be operating normally. Wait for the exitDelay (if any) in the Basement Door profile to expire, then try opening the door.
Recheck Smarthome security
In Both: Sensors When home is unoccupied (away), and When home is occupied (stay/night)
Use every open/close sensor: off/false
Open/Closed Sensors: exclude Real Sensors monitored by this app, include Simulated contact sensor used by this app; include other real contact sensors not monitored by this app,
Ahh crap. I forgot about the exit delay. I bet thatâs my problem. Iâll test that again this evening. Thanks!
New SHM Delay version and Options â Released on Sep 5, 2017
Please go to first page of this thread for the latest documentation
Keypad module replacement
This is a forked version of E Thayerâs Lock Manager Keypad module. I urge everyone with keypads (not locks) running with Lock Manager to install the upgraded module, however there is a prerequisite, so please read the documentation that follows. Source code is at repo arnbme lock-manager SHMDelay or directly at https://github.com/arnbme/lock-manager/tree/SHMDelay/smartapps/ethayer
The changes are:
Modification: Comment out sendSHMEvent. Kills setting default AlarmState before running user routines that also set the AlarmState and Mode. One of those AlarmStates is âNightâ which is not recognized by ST and my code.
Modification: When AlarmState is âStayâ and Mode is âNightâ turns on the Keypad âSleep/Nightâ icon, otherwise lights the âStay/Standing Manâ icon
Modification: Issue ExitDelay only in AlarmState: Away. Original issues exitDelay when night icon is used
Prerequisite: Prior to installing this version in Lock Manager you must define SHM Routines by going to
-
Automation->SmartApps->Lock Manager
-
Scroll down to Keypad Routines. These routines run for all defined keypads and users when a keypad AlarmState and valid pincode is entered, setting the SHM AlarmState.
Arm/Away : Goodbye
Disarm: Iâm Back
Arm/Stay: Good Night
Arm/Night: Good Night -
Review all Keypad and User profiles: Remove redundant routines defined in KeyPad Routines to substantially reduce system overhead and improve reliability.
-
Should you decide to use the âWay Beyond The Basicsâ we will revisit the Arm/Stay setting
-
Note: when using custom routines for Keypads or Users, and you choose not to set default global Keypad Routines, insure a routine that sets both Alarm State and Mode executes for each of the four keypad modes.
To install with the SmartThings IDE go to SmartApps:
- Click 'âSettingsâ â Add new repository â enter: arnbme lock-manager SHMDelay->Save
- Click the edit icon to the left of the Keypad module name
- Click âSource Code Optionsâ change to lock-manager (SHMDelay)->click Update on bottom of page
- Click âUpdate From Repoâ â select lock-manager (SHMDelay)
- Select âKeypadâ->leave âpublishâ unchecked-> click âExecute Updateâ
- When 4 and 5 fail to update, click the magnifying glass icon
, the source for the updated module and the current version display, then click âOverwrite local versionâ, then click âSaveâ completing the install. - In Global Application Settings set âupgraded Keypad module is installedâ to On/True
True Night Mode Option
This option when On causes an immediate intrusion in AlarmState: Stay. When Off (default) the profile entry delay time is used. (A keypad is not required for this option)
Additionally, when using the Keypad module replacement with keypad, in Night mode the app lights the âNightâ icon on with Xfinity and Centralite keypads. When arming with True Night Mode, the âStayâ icon may light for a few seconds, then it shuts off and the âNightâ icon lights. Iris keypads have a single a âPartialâ button and I donât have one available for light testing, however the Night no entrydelay should work.
Mode Fix Option
Sets the SmartHome Mode when setting the AlarmState from the SmartThings Dashboard Home Solutions or anything that does not properly set the Mode. Itâs needed for âWay beyond the basicsâ, but you may find it useful on its own.
Activation requires two steps:
- In Global Application Settings set the Fix Mode option on/true
- Create A ModeFix Profile (default profile initially shows in the child app)
Have you ever wondered why Mode restricted Routines, SmartApps, and Pistons sometimes fail to execute, or execute when they should not? I gave up trying to use mode for Core Pistons, now I know why it did not work.
Perhaps like me you conflated AlarmState and Mode, however they are separate and independent SmartThings settings. When Alarm State is changed using the SmartThings Dashboard Home Solutionsâsurprise, Mode does not change!
SmartHome routines generally, but not always, have a defined SystemAlarm and Mode setting. Experienced SmartThings users seem to favor changing the AlarmState using SmartHome routines, avoiding use of the Dashboardâs Home Solutions.
If like me, you canât keep track of all this, or use the Dashboard for changing the AlarmState, the Mode Fix option may be helpful. For each AlarmState, set the Valid Mode states, and a Default Mode. Mode Fix attempts to correctly set the Mode by monitoring AlarmState for changes. When the current Mode is not defined as a Valid Mode for the new AlarmState, the app sets Mode to the respective stateâs Default Mode.
Please Note: This option does not, directly or (knowingly) indirectly, execute a SmartHome Routine
Way beyond the basics
For Xfinity and Centralite Keypads â now you can have fully functional Stay and Night icons and modes. (Not for use with Iris Keypads)
- Install my version of E Thayerâs Lock Manager Keypad routine, then in Global Application Settings set the Upgraded Keypad flag to On/True the (see above)
- Turn on True Night Mode in Global Application Settings
- Implement Mode Fix if there is the slightest chance you will set the AlarmState with the SmartThings - Dashboard Home or something that does not set Mode.
- In the IDE, My Locations, click the location, then create a new Mode âStayâ
- Then in the phone app âRoutinesâ, create a new routine named: Stay (or whatever you want). Set AlarmState to Stay, and Mode to Stay. Add other settings as desired
- In the Lock Manager, scroll to Keypad Routines (Optional), set the newly created Stay routine name for Armed/Home. This is required, the field is named âOptionalâ
- Update the SHMDelay Mode Fix profile Stay options to include âStayâ as a valid mode along with Night.
- Now when setting the alarm state from the keypad, the Stay or Night icon is immediately lit. Stay uses an EntryDelay, Night creates an immediate intrusion.
2 Likes