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?
Andrew
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.
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.
I may have found it. I find there are two ways to send push messages and in a webCore post I found, if the message isn’t stored it doesn’t push on the new app. I’ll get with Arn and see if this is it. Thanks @Mavrrick58 for the push in the right direction.
This is the notification routine from SHM Delay Child. The issue that must be resolved is how to determine if it’s running in the V2, the V3 app, or both? Should sendPush() work in both environments, then this is moot, however the message will also show in in the Notification Log.
tag: @Maverick@oldcomputerwiz
// log, send notification, SMS message
def doNotifications(message)
{
def localmsg=message+" at ${location.name}"
if (theLog)
{
sendNotificationEvent(localmsg)
}
if (location.contactBookEnabled && recipients)
{
sendNotificationToContacts(localmsg, recipients, [event: false]) //Nov 11, 2017 send to selected contacts no log
}
if (thesendPush)
{
sendPushMessage(localmsg)
}
if (phone)
{
def phones = phone.split(";")
// log.debug "$phones"
for (def i = 0; i < phones.size(); i++)
{
sendSmsMessage(phones[i], localmsg)
}
}
}
This is what I gathered from another pose I found in the webCore forum. In the new app, unless the message is being saved in the notification feed, it wont push. So if I’m reading the code correctly, which I probably am not, the sendPushMessage is sending the push message without saving it in the feed, thus the V3 app won’t push it. I’m probably wrong though as I usually am. The screenshot I attached is from the classic developer site so it will work in both.
I use SMS so it really is a moot point for me too. I don’t like to spam my wife with a bunch of messages.
I made this change a good while ago, for that reason i dont think it will have any issue regurdless of what version of Smartthings app is being run. Ofcourse this is a different app so.
If I’m reading this correctly the only difference for Classic is that it will now store the push message in the notification feed whereas previously, it didn’t.
Here is the link to the portal where I found this information.
