Thanks, so I have that sensor included in the delay and I’ve also included updated the setting to add motion sensor entry delay time to 5 on page 2 of the delay profile. I’m still getting an alarm with the motion sensor triggering during the delay period after opening the door.
Assuming the motion sensor is not being monitored in SHM for unoccupied and or occupied. If it is not monitored, try saving the SHM settings again.
What is showing in the Phoneapp’s Notification Logs. It should show the actual device creating the intrusion from SHM Delay.
If you only see the Simulated Contact sensor from SHM, go to global settings and be sure “Issue Intrusion Message with name of triggering real sensor” is on/true
I was able to recreate this issue on my system and am reviewing and retesting the logic. Should work but it does not. Only one device chimes.
According to the trace it’s working, but in reality it is not. There was a recent silent Groovy update. I’m going to have to contact support. Wish me good luck, the keypad is not a ST supported device.
Added some debug logic around line 828 of module SHM Delay Child. Code and Results follow:
> if (alarmstatus == "off")
> {
> thebeepers?.each
> {
> def beepDevice = it?.getDevice()
> log.debug "process ${beepDevice.displayName} armMode: ${it?.currentValue('armMode')}"
> if (it?.currentValue("armMode")=="exitDelay") //bypass keypads beeping exit delay tones
> {
> log.debug "Skipping ${beepDevice.displayName} armMode: ${it?.currentValue('armMode')}"
> // log.debug "skipped device on exit delay ${beepDevice.displayName} armMode: ${it?.currentValue('armMode')}"
> }
> else
> {
> log.debug "Beeping ${beepDevice.displayName} armMode: ${it?.currentValue('armMode')}"
> it.beep()
> }
> }
ae0adf40-2646-42ca-b1ed-5fa1afd80d31 10:09:31 AM: debug Beeping Xfinity 3400-X Keypad armMode: disarmed
ae0adf40-2646-42ca-b1ed-5fa1afd80d31 10:09:31 AM: debug process Xfinity 3400-X Keypad armMode: disarmed
ae0adf40-2646-42ca-b1ed-5fa1afd80d31 10:09:30 AM: debug Beeping Iris 3405-L Keypad armMode: disarmed
ae0adf40-2646-42ca-b1ed-5fa1afd80d31 10:09:30 AM: debug process Iris 3405-L Keypad armMode: disarmed
Thanks for this, arnb! I read through that thread, as you sugggested, before making any changes to my DTH. In my DTH it was line 391 that I had to change. I just had to put a set of parenthesis around “pct * 100”. This fixed the battery reporting on my Iris keypad.
Again, thanks for the info!
I wrote some workaround code, that should have sounded the beeps on all keypads, but for some odd reason it’s failing. Sounds on only one device but debug message shows in log. I have no idea what is wrong. Code follows:
def makeabeep=true;
// log.debug "doorOpensHandler ${alarm} ${alarmstatus}"
if (alarmstatus == "off")
{
thebeepers?.each
{
if (it?.currentValue("armMode")=="exitDelay") //bypass keypads beeping exit delay tones
{
makeabeep=false;
// def beepDevice = it?.getDevice()
// log.debug "skipped device on exit delay ${beepDevice.displayName} armMode: ${it?.currentValue('armMode')}"
}
}
if (settings.thebeepers && makeabeep)
{
thebeepers.beep()
log.debug "all beepers sounded"
}
return false
}The motion detector in the dining room is the one that is detecting motion. It is excluded from SHM. The notifications are below along with the screenshot from SHM. I changed the delay in the motion sensor entry delay time to 10 and that didn’t help either. I re-saved everything before I tried it again.
The Dining Room Motion sensor is being triggerd and timing out prior to the system recognizing the door contact is open. Then SHM Delay triggers an alarm. I have a similar situation that is mitigated by the motion delay time parameter, so I know it generally does (or did) work.
When the system is OFF, and you open the door, does the door sensor show as Open?
I notice the DR sensor says it is wired, perhaps this is somehow a part of or the cause the issue?
BTW is this a system that previously worked and is now failing?
Edit
Also check out this thread. Both Zwave and Zigbee failing.
I’ve been experiencing the exact same issue as jmallentn for months. A motion sensor is causing the simulated contact sensor for SHM Delay to trigger SHM alarm. I’ve confirmed that the contact and motion sensor are not monitored by SHM, and the motion sensor is set to be ignored in the profile for the delay profile. It also has a 10 second delay in case it reads motion before the door’s contact sensor is recognized as being open. I’ve tested and verified that the door opening and closing doesn’t trigger the motion sensor, because the sensor is mounted to the wall, right next to the door. The motion sensor only gets triggered when I walk inside.
I look at ST, and it does recognize that the door is open before the motion sensor detects motion. The motion sensor is triggering the SHM alarm before the 10 second motion delay on the 2nd page of the profile. Both the motion and contact sensors are ST. This happens on all three doors of my home.
I deleted all delay profiles, then re-created them, and this problem is no longer happening on one door, but it happens on the others.
To get around the above, I enabled “True Entry Delay” in the global settings, but I wish I didn’t have to do that.
Ahhh! I believe this is “crosstalk” caused by having a motion sensor defined in multiple delay profiles. You open contact1, but the motion sensor is also defined in delay profile for contact2, which is not open-bam intrusion alert.
Solution:
Go into global settings: set “Check other delay profiles when motion sensor is defined in multiple delay profiles” to On/True. It adds bit of overhead so the default is off/false.
And please turn off True Entry Delay
You can probably also set the motion sensor delay back to 0
I had “check other delay profiles” enabled, too. I had true delay off while I was testing this today. I’ll try again.
I might be understand it wrong before so tonight I just triggered the crazy siren!
I have all my contact sensors in armed away Mode since I don’t need any delay. All these sensors will be used to create delay profiles with one virtual contact sensor. The virtual sensor is used in armed stay. I thought the SHM delay can ignore intruder detect if I close the contact sensor in the time period we set. However, it seems like it provides the delay time for you to disarm, not just auto ignore to stay in green.
Is there a way I can delay the siren and can close the contact sensors to stop the alarm?
Thank you
Smart Home Monitor (SHM) has no delays when using the Classic phone app. SHM Delay provides the delays many people want and need using an alarm system.
There are two basic delay times, exit and entry, set in a delay profile. Delay profiles are needed only for doors used for home access and egress.
When the system arms in Away mode there is an exit delay. Arming In partial/stay/night mode the system is instantly armed, no delay.
When a contact opens in Away mode, the system triggers the alarm in “Entry Delay” seconds, by opening the Virtual Contact sensor which must be monitored by SHM, thus giving you time to turn off the alarm in any way you choose. in partial/stay/night mode you may choose to delay or set an instant alarm when a SHM Delay monitored contact opens.
When the alarm triggers it may be turned off in any way you choose including the phone app.
There are very detailed intructions at the beginning of this thread.
1 Like
Thank you very much.
I think I now understand.
If the motion sensor is defined in multiple delay profiles turn on the global setting for “Check other delay profiles when motion sensor is defined in multiple delay profiles” to On/True. It adds bit of overhead so the default is off/false.
If that does not fix it, insure the contact sensor is working and actually showing it’s open and closed.
If that does not fix it, send me a private message with your phone number and a good time to call.
Arnb,
I ran into something unexpected today and wanted to get clarity on the situation and a possible solution. I have SHMD installed in a house using Konnected and an Android tablet for input with ActionTiles. I also have Tasker setup to play media when entering while the alarm is on (a cool replacement for simple beeps – in my case the theme song from Mission Impossible).
So today I set SHM to Armed: Away and walked out the door. I then realized I’d forgotten my wallet. I brought up SmartThings and on the dashboard I hit Disarmed to shut down the alarm. All good I assumed. I then opened the door and immediately my phone received a text and notification tell me, “Front Door is open, system Armed at Home.” As I just pointed out, the system wasn’t armed.
I wonder if I came back in while the delay (set to 60 seconds) was still in the process. The text came from “844647”.
Can you offer any insight on this? Is SHMD involved?
The door open message occurs when the system arms and a monitored contact sensor remain open.
This entire process is running in the cloud and subject to both internet and processing delays, also things process in parallel, not serially. So it’s likely the door open processed prior to the completion of the disarm processing.
Thanks to @zcorneli for recently updating the Keypad DTH with the following changes
- Fixed the battery percentage calculation. Issue: Was showing zero
- Changed the the beep command. Issue: when attempting to use multiple keypads as a door chimes, only the first keypad would beep.
If you are using the suggested keypad dth at github repo: miriad Centralite-Keypad master, it is available for update in the IDE
[Update] SHM Delay Version 2.0, Sep 23, 2018 10:45 EDT
Enhancements and Changes
- Changed code reducing overhead when verifying a user pin code
- Corrected issue with pin 0000 usage
How to Install
There is one (1) module associated with this update. When updating from Github, in the IDE change for each module shown below, insure you are using the arnbme SHMDelay Version2 repo for all modules
- SHM Delay (v2.1.7). Module must be Saved, then Published
- Install via the repository (preferred), from the following repo.
Owner: arnbme (in upper case that is ARNBME)
Name: SHMDelay
Branch: Version2