I watched your video. It’s functioning exactly as designed. The 30 second delay is for you to get out your phone and clear the intrusion and disarm the system.
Also, The rule will stop the siren. The automation is ALWAYS active. If the siren is activated while STHM is disarmed, it will turn off. It will look to see if the siren is turned on 24/7. Not just when you come home. It works, I use it.
Though what you have setup seems to work so I would stick with it if it works for you.
Why not create a virtual sensor/switch that follows your entry points. Turn it ON when ANY of your doors are open after 30 seconds and OFF when ALL your doors are closed. Then only use that in your STHM Monitoring routine. This way, you should have enough time to Disarm the system before the switch turns on to activate the siren. You can then remove the delay on the siren part of STHM.
I apologize for my ignorance regarding the absolutely stupid lack of an Entry Delay in STHM. I thought they would have learned after the SHM debacle.
I moved 100% to Hubitat a bit after I modified and tested SHM Delay with STHM and the new app sometime around early December. From my experience with helping users get SHM Delay working, I find most problems are the user deciding to avoid reading and following the detailed directions, although with the new ST app it may be something else. SHM Delay is a giant hack to SHM, nothing much changed using STHM.
While testing the app with STHM I found many of the child app (profiles) created with the new app have the INCOMPLETE status, making them unusable with SHM Delay. The solution is to create the profiles with the Classic app. My suggestion was to stick with the Classic app.
However, without warning, ST silently removed Routines and SHM from new installations of the Classic app. So at this moment it appears things are a mess and as @oldcomputerwiz says “something is wrong with new SHM Installs in the new app”. As far as I know he may be the only current install of SHM Delay working with STHM.
My bride is sick today but when I get the chance, I’m going to create a delay profile using a different door and see if it works for me. I think that is the only way we are going to know if there are issues with the newly created delay profiles.
if you are using Fully with a display device, I just documented how to do a exit delay countdown using SSML with the FKBC
Seems like we have the same problem.
I’ve got no Google thing, but a hidden button that can be pushed disarming the STHM.
My plan is that when the door is opened (and STHM activated), I will switch the entrance light to red and play some sounds. That should be enough for us to remember that we forgot to disarm.
Then, after some seconds, I want the whole circus to start playing. Currently 2 sirens in parallell. But as you, I haven’t found any way to stop them except running over and unplug them. Your solution of smart plugs is clever, but looks a bit bulky in the end 
I hope Samsung realize that it’s normal to be able to shut down an alarm without having to find the phone deep down a purse or something.
Create this automation. I only have one siren but you would add both of yours. Anytime the system is disarmed and the siren turns on, this automation will immediately turn it off. No smart plug needed. It’s still a “workaround” but it does the job.
Test post, couldn’t post for a while as it was my first time and I posted 20 replies @oldcomputerwiz I don’t know why but it just doesn’t work for me it would be great if it did but @Paul_DeFeo has the right idea, if we could get a real contact sensor to trigger the simulated one 30 seconds after its open and use the simulated one in the SHM this would solve a few people’s issues here as technically we are disarming the system before it has been triggered therefore doesn’t give us an intrusion alert within the app meaning we don’t have to dismiss the alert to reset the system every time, if only I could code it in webcore I’ve tried but can’t get it to work, the problem I have is that the real contact sensor has to remain open for over 30 seconds before the simulated one will open, this is not good as anyone could circumvent the system just by closing the door within 30 seconds of entering, people please you are all geniuses and we are so close to solving this very cleanly and simply, I know we can do this, anyone?
I think this only works if the siren is already on…not during your 30 second window as the siren hasn’t turned on yet.
If you mean the automation then that’s why I think it doesn’t work for me but oldcomputerwiz says he uses it himself, but your idea of the simulated contact sensor opening 30 seconds after the real one does will work, it also means we all don’t have to dismiss the intrusion alert to re arm the system every time, because technically we are disarming the SHM before we’ve triggered the simulated sensor
I tested this extensively here when I discovered that STHM no longer stops the siren from sounding. Not sure what is different for you guys but it works here. Maybe it’s a difference in sirens or maybe it’s because I’m running SHM Delay too. Which I know you can’t get working. I guess you will have to use the outlet bypass.
i went back and looked at SHM Delay and then followed the logic and what caused me to need that automation.
When I was testing this a few weeks back my siren was sounding. What I discovered is unlike the classic app, the new app does not silence the alarm if you disarm the system while the siren is sounding. Creating the Automation will silence the alarm if it is sounding.
I never tried to do what you guys are doing, a preemptive silence. So @HALOHARRY2K9 & @Paul_DeFeo are right, it won’t work in this scenario.
The only alternative is the outlet to preemptively cut power to the siren.
Sorry for the confusion, it’s been a bit since I worked on this problem. 
Guys I have news I’ve been on the webcore community thing and a couple of guys had some suggestions now I’m unable to test until I get home Saturday night but this should work they said,
The simulated contact sensor will always open 30 seconds after the real one does but it won’t matter unless your SHM is armed, if it’s disarmed then it’ll have no effect, tell me what you guys think and if you think any issues will arise from this also @Odd_S I love your idea and I believe this would be good for your system too
Also I forgot to tell you, I got SHM delay to work but only in the classic app, and I can’t make routines (automations) in the classic app as it seems they’ve removed the ability to create any unless you already have some, but I’m setting this up for the foreseeable future anyway so I want to use this in the new app, by using SHM delay in the classic app I won’t be able to arm or disarm the system using Google therefore requiring to use my phone anyway, making this whole venture pointless haha, once I’m back home if this works I’d love to post a longer video explaining things and show you it working
If you have SHM delay working in Classic, I can walk you through getting it to work in the new app. It’s super easy. I’m going to be busy this weekend but we can catch up the first of the week.
Glad you got it working. 
. That means anyone else can too.
Hi HALOHARRY2k9,
This is a good idea. However, I have one question.
Why do you need the logic for closed for 35 seconds then set the simulated contact sensor to close?
Why not just when the real contact sensor is closed then set the simulated one to close?
I have used the same idea for a motion sensor before since that sensor detects lights to trigger wrong alarm too much.
Thank you
Hi, Because if someone breaks into my home and decides to close the door behind them. If the Virtual sensor closed immediately once the real one did, and this all happened in under 30 seconds, then the (door closed) would always be true, meaning the alarm would never alert, by having it be 5 seconds longer it then guarantees the virtual sensor is going to open, and as long as I enter my code and change my home status from “away” then the virtual is going to open, but after the alarm is deactivated
