SHM was a previous generation of the SmartThings security feature and was discontinued in 2019. It was replaced by STHM, which is the current version and has different internal architecture. You should ignore anything discussing SHM, as @h0ckeysk8er mentioned.
(Also, “simulated” switches were part of the old architecture and are no longer available. Now there are only virtual devices, but there are different kinds of those. )
If you are in fact asking about the current feature, STHM, could you be more specific about what you are trying to do? What steps exactly do you want to take and what outcome do you want to see?
And could you post a screenshot of the routine that isn’t working the way you want?
My guess would be that once we clear away the confusion from the many changes in ST over the years there will likely be a fairly easy way to do what you want, but it all comes down to the details.
Thanks for the helpful advice. Please forgive my mistakes (everyone !) as I am suffering from Acronym Ignorance and Confusion (AIAC). It is possible to be infected with this affliction anywhere in the tech. sector !
My problem is:
I want to incorporate delays into the function of arming and disarming the system from my Aeotec Quad WallMote.
I devised the following, which were created on the new STMH application and platform:
ARM the SYSTEM
Routine 1a. This was to arm the system, using button press & hold, after a 45 second delay (enough time to get out the door with my usual stuff). It simply switches ON vEdge Switch 1.
Routine 1b. This monitors the arm/disarm switch (vEdge Switch 1) for the ON state to execute the arming.
For DISARMing the SYSTEM
Routine 2a. This was to disarm the system upon entry to the house. It simply switches OFF vEdge Switch 1.
Routine 2b. This monitors the arm/disarm switch (vEdge Switch 1) for the OFF state to execute the disarming.
So… have I missed something, or should I not do this stuff after midnight !
Any/all critique would be welcomed, especially if it fixes the problem. Thanks in Advance.
You’re trying to capture the actions of two different buttons on the same device as your “if“? I’m not sure that’s going to work. Particularly since the wallmote is stateless. I don’t know that they would ever be recognized as both happening at the same time.
Have you tried testing by using just one button for the IF and seeing if that works? If so, you may need to rethink your trigger condition.
I thank you for your reply and a very solid JOLT into my past with the word stateless. It immediately sent me hurtling back into the days of programming ‘State Machines’ in C, in the world of SCADA and fault tolerant communications. (Sadly many years ago and, no, I don’t really want to go back there).
So, I reimagined the platform through that lens, and I believe I am a lot closer to a real solution. My only obstacles are lack of time (isn’t that true of us all?) and finding what is needed within the constrains of the design and GUI. (If only there was a generic ‘wait/sleep’ timing object )
The mobile apps create the illusion that buttons (by which I mean those using the button capability specifically) have a ‘standby’ state. They don’t. If you push a button the button attribute will remain pushed indefinitely. Only if it supports other states like held will it ever change.
This has always made handling more than one button event problematic. WebCoRE had the ability to be pick out the button events that caused the piston to fire so it was possible to jump through a few hoops and determine that a couple of button events had happened within a very short space of time, hoping there weren’t any delays in the system.
SmartThings Rules work a bit differently. When I created my button Rules a few years ago I found I had to work on a one button per Rule basis. That is not to say that Rules might not have a few features that didn’t exist and/or weren’t documented at the time, which is why I will be interested to look at the source of the Routines to see if they do something clever. I am not optimistic though.