[OBSOLETE] SHM Delay Version 2.0

Thanks. I set STHM to Away mode, open door to leave, close. I wait for re-entry to test it and when I open door, the Door sensor opens and no alarm. I keep the door open for a bit and nothing. I think I am expecting the Simulated Sensor to open to issue Intrusion - Is this correct?

I also tested Simulated Sensor by Arming system and opening it and the Alarm shows Intrusion Alert.

Thanks for your help.

I am going to try to leave Simulated Sensor as Open and try it that way.

I experienced the same thing. It worked flawlessly for a long time and then I started seeing exactly this. One of the many reasons why I finally left the Smartthings platform. I hope you can get it to work. I didn’t find an acceptable solution.

It should, however the system provided simulated sensor fails to function as expected in the new app. Please follow these directions for the simulated sensor DTH that is found by following the links in the Documentation section 8.

1 Like

Honestly I have yet to find a solution. I thought about Rboy app but you have to pay for that upfront and I would be pissed if it did not work. They should have like a 10 day trial period for example. I assume also that ActionTiles would not help as I delayed that too after this issue. I have to have the delay for the kids. I was planning to use Noonlight for remote monitor and assume they get notified as soon as the Intrusion Alerts. So that’s delayed too. It seems like a very basic thing for ST to fix. Blows my mind. I am getting closer and closer to abandoning ship too…

Thanks I’ll try that too…

1 Like

It’s a miracle !!! ST finally added a true delay to STHM. There is now a Delay Time to use under Set Response that works !! Just thought you would like to know.

1 Like

I’m trying to comprehend the STHM delay settings.

Exactly how do ‘both’ delays available in the STHM work together? Under the Sirens section, there is a delay settable to 15, 30, 45, and 1m. Then there’s the Response Delay, Delay Time settable to just 30, and 1m. I don’t understand why the Response Delay doesn’t have the same 15 second intervals too. Anyway, if I set the Response Delay Time to 30, and the Siren delay to 15, I’m guessing that means the sirens won’t go off until 45 seconds after the intrusion event occurred then?

In my case, I arm/disarm the STHM using the arrival sensors and geolocation so I don’t really need a delay for leaving and arriving. I would prefer having 5 second intervals, or allowing them to be user customizable since I would just need a 5-10 second delay to push a remote control button or issue a voice command (I have a virtual switch) to disarm STHM in case of a false positive. I’m just afraid to use these settings since a lot can happen in 30 seconds compared to just being annoyed because of a false positive.

Hi Arn: thanks again for all your work on SHM Delay. Having said that, I’m having a problem that I can’t seem to get around.

I was using SHM Delay and an Iris 3405-L Keypad with the Smartthings Classic app with no problems. Then, I migrated to the new Smartthings app. Problems begin.

At the same time of the migration, I also converted to the Rboy Enhanced Zigbee Keypad Device Handler. I have added the six Automations that you have suggested above and was able to get the 3405-L to pair. I believe all things are set properly in SHM Delay, including the SCS1 sensor, the flag for Rboy handler, etc. I have added three 4-digit security codes for users, including one for a user 0000 as before (Classic Smartthings App).

Now the problem. No matter what I press at the keypad, I get an invalid pin code error. Needless to say, the keypad isn’t controlling the SHM. As near as I can tell, when Arming, Disarming, etc. SHM from the app, the correct lights are being set at the keypad. I am unable to Arm/Disarm SHM from the keypad.

As always, any help is appreciated. Thanks again.

If you check back on this thread there was a post detailing how to use SHM Delay with the new app. Although at this point it may all be out of date. It’s been about a year since I have used Smartthings, and am now 100% on Hubitat.

Thanks to @arnb and @oldcomputerwiz for getting the changes to make it work with new STHM.

I have got it working with one exception, the “SHM Delay BuzzerSwitch” smartapp appears to only react to the SHM status and not Modes. Is there an easy way to fix this or another method to flip a switch when the entry and exit delay are active?

I’m glad I was able to help you get this far. Unfortunately, I’ve never used the “BuzzerSwitch” smart app and I have moved 100% of my devices and rules over to Hubitat about 5 months ago.

I wish I could be of more assistance. I hope you get it figured out.

1 Like

I’m 100% on Hubitat for almost one year. However, looking at the Buzzer Switch source it reacts to alarm status changes, not mode changes.

def initialize() {
	subscribe(location, "shmdelaytalk", BuzzerHandler)
	subscribe(location, "alarmSystemStatus", AlarmStatusHandler)

I believe I misspoke. It’s working–for now. I assume once ST removes the old SHM, it will need changed to subscribe to mode changes (I almost had that working), but for now it works the old way. When I switched from Konnected’s smartapp to their cloud, SHM Delay sees the contact as simulated…I didn’t realize that was preventing a full save.

Ugh. Updated to the new app and my delay is broken. Simulated switch doesnt seam to be triggering anything.

@7becker7

I had the exact same issue and could never get it to work. I even worked with the developer.

I thought I had it working, too. Still not working right. Ugh.

now that STHM has a delay capability, I’ve decided to give that a shot so since migrating I’ve completely remove SHM Delay and I’m waiting to see if I run across specific scenarios where that native delay isn’t working.

I’m also switching to the new app and seeing if I can eliminate SHM Delay. I see two delay options in the new STHM, but it’s unclear what their differences are. I think one may be to delay STHM in its entirety from responding to an intrusion, and the other merely delays the siren (so lights and notifications wouldn’t be delayed by the latter). I don’t know if they act as exit delays in addition to entry delays.

For me, I used ‘response delay’ set to 30 seconds and that seems to have had a the desired effect of not triggering an I intrusion in STHM with my alarms native entry/exit delay.