[Release] SHM Delay Version 2.0

Hello,
Thanks for creating this SmartApp. It’s great. I’m having one issue with the entry delay. When entering as soon as I step in front of the motion sensor, the alarm goes off. I have taken the sensor out of SHM and the only item SHM is monitoring is the virtual sensor I created called SHM Contact Sensor. Looking in the history of the sensor, I can see the attached. Am I missing something in the setup? It seems that the contact opens and then SHM Delay closes it, but that’s after it’s already tripped the alarm.

My Iris keypad has been falsely reporting 0% battery for about a week now. According to the post at the link below, ST support says that back end changes to the platform caused this, and that some custom DTHs would need to be updated. I’m using the DTH recommended by arnb in his instructions for SHM Delay 2. Does anyone know who to contact for this to be updated, since it’s not supported by ST?
https://community.smartthings.com/t/release-lowes-iris-and-xfinity-centralite-keypad-dth-apps/58630/764?u=grillmouster

I believe it was @zcorneli that updated @mitchp’s original DH.

I am using the Iris Keypad (3405-L) and trying to get the chime for sensor exits to work.

It looks like smart things is sending the notification to the keypad but I do not hear anything. I saw in the instructions to hold down 8 but that does not seem to change the outcome. Any ideas?

Hi! Thanks for making this SmartApp @arnb !

I have set everything up and am satisfied with the exception of one issue. I have 2 Iris Keypads. When I only had one keypad set up the door chime was working. When I now have two set up, I do not get any door chimes on the second keypad. In the delay profile I have set up, I have specified for both keypads to chime when a real contact sensor opens. I am not sure what else to do. Can you please help?

The 0% issue was also reported on the CenterCode beta testing list. Oddly, my Iris and Centralite both report 100% battery.

Here is the respone. However before you apply the change read the thread below.


Tom Manley

4 Days ago

Hi Sunny,

This was actually related to a Groovy upgrade we did on the cloud side. The Centralite Keypad DTH contains the following code on line 387:

result.value = Math.min(100, (int) pct * 100)

That needs to be changed to:

result.value = Math.min(100, (int) (pct * 100))

After you publish that change the next battery report should be correct. A similar issue was reported on the community about some the ST published DTHs:

Hope this helps,
Tom

2 Likes

When SHM Delay creates an intrusion alert a message with the real sensor causing the problem is displayed in the Notification Log and optionally as a Push or SMS message. Additionally, the delay profile allows for motion sensors to be both delayed and ignored in the delay profile.

The need for a delayed motion sensor occurs when a physical door opens, the contact sensor does not register as open, but the motion sensor sees the door’s motion, causing an alert. In the Delay profile this is the time set by “When arming in away mode optional motion entry delay time…”

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