SmartThings Community

[Release] SHM Delay Version 2.0

Start out with using pin type User
Catching up with your posts
Use the dth specified in the smartapp documentation and the default routines specified in global settings

I got the IRIS working ok and I’ve got 2 users set up as USER so that part is good. Is there a way to make the IRIS pads show the indicator constant lights like green for unarmed/orange for armed or whatever they normally natively do? It would be nice to have a visual indicator as a reminder before opening a door or after unlocking to be sure it unlocked. The beep with the higher pitched 2nd tone when it accepts a command appears to be the only indicator right now unless I’m looking at a tablet with ActionTiles or the Samsung app on my phone, but guests wouldn’t have the Samsung app.

Also, I got my new Fire HD 8 and ran the scripts with ADB that you recommended. That all went well and I now have the LANNOUNCER app installed. I’m looking at the steps in the instructions and I’m a bit confused. When I’m in SHM Delay and go to create a new talker profile, it is greyed out for LanNouncer/DLNA TTS Devices and for Speaker Devices. Do I have to establish the devices as being available somewhere else? I haven’t found that.

You have to set up the lannoucer device Handler for each tablet or Android device you want to talk. Check out the lannouncer website for all the documentation. You may also want bigtalker along with the talk profiles in shm delay. Between keypads talking and delays it’s a lot of stuff you have to accomplish take your time.

There is no done to press anywhere…I have tried pretty much everything. Hmmm

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.