Trying to get this to work with the new app but I’m not sure how as (unless I’m mistaken) the new app doesn’t have routines? It has “scenes” but I can’t find a way to change SHM status through scenes or use them with SHM Delay.
I did not even tried to configure it. New app includes alarm delay on intrusion so that was the only thing that I needed from SHM delay too.
Does it? How do you set a delay on intrusion? I have the new app but must have missed that setting as this is what I wanted from SHM too.
The only reason you would probably need/want to try and use SHM Delay in the new app is if you are trying to keep using a keypad without purchasing RBoy apps.
What you would have to do is have SHM Delay change the mode and then use mode to change STHM in the new app. You would ignore routines or create routines that did absolutely nothing if SHM Delay is insistent on having them specified.
It’s a delay of siren in my case. Choose sirens and under that you can choose delay.
UPDATE 03/24/2020 - I GIVEN UP TRYING TO GET THIS TO WORK WITH THE NEW APP. STHM IS JUST NOT RELIABLE WITH SHM Delay. IT’S ONE ISSUE AFTER ANOTHER. BECAUSE OF THIS AND ALL OF THE OTHER ISSUES WITH THE NEW APP, I HAVE MOVED BACK TO CLASSIC.
I HAVE SHM DELAY 2.0 CONTROLLING STHM IN THE NEW V3 APP!
I was able to control STHM because SHM Delay interrogate SmartThings for the current LOCATI0N MODE and then having SHM Delay change the current LOCATION MODE using the 4 routines that we have used all along. I also had to create 6 rules in the AUTOMATION CREATOR in the new V3 app.
HERE IS THE REST OF THE GOOD NEWS!
I spoke with Arn today, the creator of SHM DELAY and being that SmartThings is pushing for all of us to stop using routines, he is going to review the code and, more than likely, be able to eliminate the need for them to control STHM. If he is able to make this happen, SHM Delay should continue to run until SmartThings finally pulls support for groovy smart apps, barring any other unanticipated backend platform changes.
We are also still exploring an issue that comes up when you have more than the 4 basic modes (home, away, night, stay). I have found a work around but am looking to see if I can find an easier way to handle this.
One of us will post with an update when we have some additional information for all of the SHM Delay users.
User profiles (child apps) created in the New phone app do not work with this smatapp, and do not show up in the Classic app. Until this is resolved create all profiles in Classic phone app.
Update Apr 20, 2020
Corrections and Updates
Support for STHM in new ST App while maintaining all functionality with SHM in Classic app
Added global Modes or Routines flag that determines how STHM/SHM Alarm Status is set.
*Default: On/True: Sets Location Mode, triggering Automation Rules that change SHTM Status in new ST app, or triggering SHM Delay Modefix in Classic.
*Off/False: Use Routines (deprecated in Classic and not available New ST app if not set in Classic) triggering SHM Delay Modefix in Classic"
If you are using the Classic app with SHM, and not planning to move to new St app, do not install this change
Installation module changes
Update module SHM Delay (V2.4.0) from github arnbme / SHMDelay / Version2 Save, Publish, For Me
See documentation section 28 at top of this thread for instructions on how to change a module’s source repo
Other modules are unchanged and should load from the Version2 repo
Post Installation Setup with new ST app and STHM
Set Global settings switch for Modes Or Routines to On/True to use Modes (Only shows when global using Keypads setting is true)
*set the various Modes in global settings, tap Next,then Save
Install the new Smarthings app from Android or Apple app store
Use the ST app’s SmartApps function to install Smart Things Home Monitor, then setup all devices including the simulated contact sensor exactly as set in SHM; or if this is a new installation, as defined in the documentation.
Create the following six Automation Rules
*If location mode Away: Change security mode to Armed (away)
*If location mode Home: Change security mode to Disarmed
*If location mode Night (and Stay if defined): Change security mode to Armed (stay)
*If security mode Armed (away): Change location mode Away (set wait flag off)
*If security mode Disarmed: Change location mode Home (set wait flag off)
*If security mode Armed (stay): Change location mode Night or Stay if defined (set wait flag off)
When additional location modes are defined, adjust or add rules as needed
Enable SHM Delay Modefix
Set global setting “Mode Fix when system armed from non keypad source” to ON/TRUE
Update Feb 07, 2020 issue Sirens continue to sound when system is disarmed
Solution add rule: When system is disarmed issue command off to sirens defined in STHM
Post Installation Setup with Classic app and SHM
Should you want to use Routines (currently standard in Classic): Set Global settings switch for Modes Or Routines to Off/False (Only shows when global using Keypads setting is true)
Should you want to use Modes: Set global settings switch for Modes Or Routines to On/True, set various Modes in global settings. (Only shows when global using Keypads setting is true)
Set global setting “Mode Fix when system armed from non keypad source” to On/True
Tap Next, tap Save (global settings)
Verify and or update Active Mode Fix settings
- It is suggested that you run either SHM or STHM, but not both simultaneously.
- However, should you want to run both with SHM Delay, there may be an issue with the Modefix settings
- Suggest not using any STHM defined device delays with devices used with SHM Delay
Issues or Errors?
Post questions on this thread.
For code errors: Set “Log debugging messages?” to true. In IDE turn on Live Logging; rerun the test, then forward the debug messages in a private message to me.
My thanks and appreciation to Steve Jackson, @oldcomputerwiz, for helping me quickly get up to speed on the new ST app, developing the concept and use of automation rules to set STHM alarm status with SHM Delay, and for being an alpha tester.
Dec 20, 2019 15:33EST Beta Release
Feb 06, 2020 11:30EST STHM support moved to production github repo
Is the new STHM delay option just for entry? It seems a little odd to me. I guess it’s nice to see they are somewhat trying.
I wonder if there is a way that this could be used with SMH Delay to eliminate the need for the simulated contact sensors? Couldn’t I just set the delay to 30 seconds in both apps and allow STHM to do the alerts but let SHM Delay still control the audio beeps and talker that announces that the system needs to be disarmed?
Then we have the exit delay. Would this need to be setup differently?
All delays: entry, exit, and motion available with SHM Delay used in the Classic app function in the V3 app without using STHM’s builtin delays.
Perhaps the release notice was not sufficiently clear. This is the SHM Delay smartapp modified to work with the new V3 phoneapp in conjunction with STHM, while continuing to function in the Classic app.
For anyone who has not installed the new V3 phone app, you get the same user Smartapps in both V3 and Classic phone app. However, you get SHM on Classic, and STHM on V3, they are separate and unique applications.
This statement really annoys me!
Who is they? Samsung? No. I modified my smartapp, SHM Delay, to function with V3 and STHM. I am not “somewhat trying”. Another community member asked me to update SHM Delay for V3 and gave me information about how to do it. I wrote code to make this happen, tested the system, then dedicated a few hours documenting how to use it. That’s work even if I do it for free as a service to the ST community.
Not that I know of.
Not at this time. Currently (AFAIK) no STHM application settings are exposed in Groovy, nor is there any known method to set the STHM alarm status, although it must exist since it can be done with Automation Rules.
Additionally, V3 does not natively support Centralite, Iris and other similar keypad
For a fully integrated security app take a look at Nyckelharpa that runs on Hubitat Elevation’s Home Security Monitor. Nyckelharpa used SHM Delay as a base.
Shm Delay’s source is freely and easily available on Github for anyone wanting to change it.
Arn, I wasn’t referring to you in that statement. I appreciate your work on SHM Delay. I was referring to Samsung adding the 30 second delay option in the new STHM. Although the setting is not explained well by them and I have no idea if it is an entry delay, exit delay or both, it’s nice to see they are working towards something better.
I am currently using both Classic and new ST apps mostly because of SHM and the lack of routines in the new app. With STHM and some of the improvements in custom automations I am much closer to getting rid of classic for good. Is there a good guide you can point to for setting up SHM delay exclusively with the new app and an Iris v2 keypad? I had it mostly working on the classic SHM but the iris keypad was acting a bit flakey (freezing up, no delay beeps at times, etc). The alarm I had through LANnouncer was also a little buggy. It would only sound the alarm sound once and then stop
Correct me if I am wrong here. I’m just throwing out some ideas.
The reason for the simulated sensor is because STHM gets armed immediately from the keypad and SHM delay only activates the simulated sensors when something opens after the set delay, right? If STHM already has a Delay option now can’t SHM delay work in conjunction with it and just provide the audio cues?
For exit delay we already know that we can set an automation to set STHM based on the the home mode. Is there a way for the keypad to trigger a scene to change the home mode only after the set delay?
Appreciate you letting me know that statement was not directed at me. I apologize for my strong statements directed at you.
Most of my system is now on Hubitat, with a small portion on ST. My plan was to get off ST before they killed Classic, and abandon SHM Delay. However, when I read they may kill Classic in the near future, I became concerned and then Steve Jackson asked me to get it working, explained the ST app now runs Groovy, and he figured out how to set STHM status, so I gave it a try. It was a relatively simple fix, although documenting it was a challenge.
A day into it Steve found the issue with profiles.
The simulated contact sensor is used to trigger an intrusion in STHM and SHM. When converting SHM to work with STHM my main goal was to get it done quickly and painlessly. Additionally as far as I know STHM does not expose any of its settings to Groovy, or have any methods to set an intrusion.
I did what you suggest, with the Nycelharpa app in Hubitat, where most all the HSM settings are available.
The documentation at the beginning of this thread is excruciatingly detailed. I have an Iris V2 working with my system. Sometimes this device’s firmware is flakey, there is not much you can do about that.
Other than using modes with SHM Delay and needing automation rules for STHM , and leaving Modefix for SHM it seems to work on my system in both STHM and SHM as documented in the Beta release information.
Lannouncer is a good product, however I prefer and use [OBSOLETE] Fully Kiosk Browser Controller (DTH) if you can use it. Works on ST and Hubitat.
Oh wow. Thanks. I am already using a fire tablet with Fully Kiosk so I will give this a try. LANnouncer was good but it stopped responding every once in a while
I have two Fires and one old Android phone using the Fully Kiosk Browser Controller DTH in ST and in Hubitat. Messages work from both apps with my setup.
Every once in while, perhaps monthly, one of the Fires stops talking until it is rebooted. However, this setup is still much more reliable and usable than using Lannnouncer on the Fires.
BTW Lannouncer worked well on the Android, except for the message clipping when a new message arrived while it was speaking. My guess is Fully has a FIFO message queue.
While working on the STHM project @oldcomputerwiz advised me, and I found some code from May 2019 for Xfinity branded UEI keypads, that never made it from the Beta repo to Version 2 production.
Anyone using the UEI keypad must use Beta repo modules: SHM Delay, SHM Delay Child, and SHM Delay Modefix.
This will be corrected soon by installing the updated code (minus any STHM changes) to the Version 2 repo.
For the record I burned out in mid May from coding SHM Delay, Nyckelharpa in Hubitat, and my website www.arnb.org , and have been happily playing with my acting avocation. Not sure what changed, but I am able to code again.
Hopefully I am stronger than whatever the new ST app can and will throw at me.
I have also discovered that ALL push messages from SHM Delay are ONLY being pushed out of the classic app. So, if you want to receive push messages, you will have to leave the classic app installed and continue to allow it to send you notifications. Your other choice, if you reside in the USA, is to use text messages.
Also, ONLY use the classic app to set up SHM Delay at this time. If you create profiles using the new V3 app they WILL NOT WORK. There appears to be some kind of difference (bug?) between the way classic and the V3 app handles data entry for child apps (which the profiles are).
The SMS notification issue were they are only going out the classic app is related to the command being used to send them. A while back i had the same issues in some of my apps. I just had to update the command to send the notification.