Arming/disarming STHM and using virtual switches?

I’ve just implemented the valuable information contained in the post by MarkTr and JDRoberts, here (many credits to them):

It seems like I am walking through quicksand…

The problem I now have is that the hub will not respond to commands to ARM when requested via a routine using a switch (simulated or virtual). I also found this post which was quite disheartening:

Is there a fix for this or is STHM simply unable to support a simple intrusion detection system (with entry & exit delays)? :face_with_spiral_eyes:

The second post you reference is nearly six years old so probably not quite relevant today.

What is the specific use case you are trying to implement?

1 Like

I am trying to implement ARM/DISARM functionality, with an exit delay, using an Aeotec Quad Wallmote as a ‘key’. My hub is an Aeotec hub.

I can do these directly in the routine, but in order to implement a delay, I then found I need a switch (virtual or simulated). This is where the system seems to fail.

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. :thinking:


Dear Mr/Ms JDRoberts,

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 ! :blush:

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:

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.



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 ! :woozy_face:

Any/all critique would be welcomed, especially if it fixes the problem. Thanks in Advance.

Can anyone help me with this? I am a bit stuck for ideas and options with this one.

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. :thinking:

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 would think another vSwitch with an auto off after a few seconds could capture the single button press, basically holding it’s state. The the current routine is:
New vSwitch On
Button 2 Held

Just something to try.

Dear JDRoberts,

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 :thinking: )

Anyway… thanks again for the inspiration :clap: :clap:

1 Like

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.

Dear orangebucket,

In ‘Rules’ are you referring to the new Rules API or something else?

P.S. I am happy to share my new STHM routines if they are of interest to anyone ?

1 Like

Dear Rodd62,

I have started to experiment with your suggestion.

Thank you.

Routines, Scenes and Smart Lighting are all implemented using the Rules API.

So does that mean that the "Delay before alert " setting under “Set response” settings no longer works ?