ST or Alexa ignoring SHM arm/disarm

Hey folks, I’m having issues with SHM disarming and arming when using both Alexa and the Classic app together. I’m curious how others have theirs setup.

My problem is that Alexa won’t trigger if it thinks it’s already in that state. For example, SHM is Armed through Alexa… Then I disarm through the ST app… Then ask Alexa to turn on security and it won’t because it thinks it’s already on. I have to ask to turn off security (even though it’s already off) then ask to turn it on and then it’ll actually turn it on.

I’ve tried two things…

A Simulated Switch that I have an Alexa routine turn on and off, and that switch is connected to a webcore piston to turn on and off security.

Two Scenes, one to turn on the Simulated Switch and one to turn off the Simulated Switch… Then created two Alexa routines, one to run each scene.

I can’t really tell if it’s Alexa or ST that are ignoring the action, as I would think the Scene route would would always execute.

So the way I have it work is by using a virtual momentary switch from [Release] Virtual Alexa Switch/Button so when I say, for example, Alexa, goodnight, all that Alexa does it pushes the button. The button triggers the goodnight routine in ST, setting SHM and the like. The button defaults back to off in it’s own so there’s no need to have to rely on a routine or scene to do it. The good morning routine to disable SHM can be achieved the same way, except I just have it automatically done when the coffee maker turn on. And coming home is done presence or simply the door unlocking (in case presence hasn’t updated yet).

Do you not have trouble when you use both Alexa and the app to change SHM? I can get it to turn on and off from Alexa, it’s just when I use one to turn on/off and then the other to turn off/on. When Alexa thinks the button is still in that state, it doesn’t want to trigger again.

Why would you use them both at the same time? You only need to use one or the other at any one time. Using Alexa would not preclude you being able to use Alexa though. Both will work.

My scenario is that I go to my detached garage and turn off SHM from the app (say I forgot to have Alexa do it when I leave). When I’m done and back in the house I might ask Alexa to turn it on, but it doesn’t because Alexa isn’t aware I turned SHM off from the app. I don’t use them at the same time, but want to use them interchangably.

Alexa isn’t aware of SHM at all. It’s all how you set it up to be managed. How do you have it connected to Alexa? Via a virtual Switch? Well, then the switch has to follow SHM as well as SHM following the switch. It is much easier to to make it stateless. Have two virtual “auto-off” switches, one to arm HSM one to Disarm it. Asking Alexa to arm HSM turns on the arm switch, which in turn arms HSM and asking alexa to disarm HSM in turn turns on the disarm switch. And both switches turn themselves back off automatically after a second or two to allow them to be used the next time. Then, you don’t have to worry about Alexa “knowing” about SHM, which it never does…ever.

Yeah, I know it doesn’t know about SHM. I was trying to do it with one virtual switch and having that turn on and off SHM… I haven’t thought to have one switch for on and one for off. I’ll give that a try.

With only one switch, you would have to have some automation set up so that the switch would follow HSM status as well as lead it. Otherwise you can’t control it from both places. That’s because both places aren’t being updated every time one of them changes.

1 Like

Ah! I got it. I was missing something that would toggle the switch when SHM changed modes… So it wasn’t Alexa ignoring it, it was the virtual switch… Thanks for that input… made a huge difference!

1 Like

Be careful…this is going to create a loop. One is going to drive the other will drive the first again. That’s why 2 momentary switches is easier. Either that or you have to add a restriction to the actions in your piston.

I set them to only trigger when “physically” turned on… it seems to work when I try different combos between the app and Alexa. Webcore doesn’t show a loop. I’ll keep an eye on it though.

It’s a virtual button…it can’t be physically turned on.

Seems to be working as expected. I figure even simulated switches can simulate physical vs programmatic triggers. I’ll keep an eye on it though. So far so good.

You are likely getting some looping occuring, especially on the SHM side.

If you can only change them programmitcally, how would they do that?

I created a simulated switch for this sample Piston:

Then I used the ST Classic app to turn it on. Here’s the output:

+1ms ╔Received event [test-switch].switch = on with a delay of 51ms
+76ms ║RunTime Analysis CS > 15ms > PS > 50ms > PE > 11ms > CE
+79ms ║Runtime (38178 bytes) successfully initialized in 50ms (v0.3.110.20191009) (76ms)
+79ms ║╔Execution stage started
+86ms ║║Comparison (enum) on changes_to (string) on = true (1ms)
+87ms ║║Cancelling condition #2’s schedules…
+88ms ║║Condition #2 evaluated true (5ms)
+89ms ║║Cancelling condition #1’s schedules…
+90ms ║║Condition group #1 evaluated true (state changed) (7ms)
+92ms ║║Cancelling statement #3’s schedules…
+97ms ║║Physical interaction ON
+98ms ║║Executed virtual command log (2ms)
+103ms ║║Comparison (enum) on changes_to (string) on = true (0ms)
+105ms ║║Cancelling condition #6’s schedules…
+106ms ║║Condition #6 evaluated true (4ms)
+106ms ║║Cancelling condition #5’s schedules…
+107ms ║║Condition group #5 evaluated true (state changed) (7ms)
+109ms ║║Cancelling statement #7’s schedules…
+114ms ║║Programmatic interaction ON
+115ms ║║Executed virtual command log (2ms)
+117ms ║╚Execution stage complete. (38ms)
+118ms ╚Event processed successfully (118ms)

So, to your point… it treated it as both a Physical and a Programmatic interaction.

Oh…it isn’t specified by the device, which would mean the type of change was blank, which would be caught by both. :slight_smile: i’ts not like I haven’t already done this all before.

:+1: Hopefully the detail helps someone else that stumbles upon the thread. I’ll poke at it some more and see if I have any issues with it causing a loop.

You could eliminate the possibility by adding a restriction to the action…but it seems you want to investigate before fixing the issue I know you’re going to have. :slight_smile:

I’m not sure what restriction to add. I’ve never been able to get restrictions to work how I would expect them to.

Well, the restriction here is simple. Above the on action, you put a restriction that it is off. Above the off action, you put a restriction that it is…I’ll let you guess. :wink:

So, it would look like this:

image