Outage Affecting STHM and some automations (19 Jan 2021)

Yep, this is ridiculous! This last issue is making me consider migrating to another hub. Please share you thoughts. Considering Hubitat.

1 Like

Status page said this was sorted but it surely isn’t and the support doesn’t seem to reply to emails?
I can’t use the STHM feature as any change in mode triggers an infinite loop och Goodbye and I’m back until I disable the automations in the app.

1 Like

Same here. I am disappointed the Status page has no issues the last two days since the STHM problem is on-going and I have a couple of lights not turning off on schedule in Automations and in the Smart Lighting App and I have seen a few post here stating same.


I agree - I just received a notification that supposedly the issues are resolved, but I am still getting the 36-302 error when trying to activate my new wifi/hub. I looked at Hubify too - I chatted with the manufacturer about functionality and it looks like it will work, though it is a fairly complex setup. It also functions as a locally stored config with a cloud interface. A feature that has good and bad implications. Either way, my return window for this Samsung device is up in a few days, so I guess it either works this weekend or back it goes!

Has anyone got any replies from the support regarding this?
I can’t use the STHM automations anymore and have to do each step manually?

I have virtual switches that are supposed to Arm and Disarm the STHM and they are still not functioning. I have recreated them as well as removed and reinstalled STHM. The only way to change the status of STHM is to manually click the status on the STHM. @vlad can you look into this, the STHM is useless if you can’t automate changing it based on presence (which also has been flaky lately). I am seriously about to throw in the towel on this platform.


Change them to a Simulated Switch. That worked for me.

I just found one thing that might be a solution to the looping… Unfortunately I run my phone in Swedish so the screenshots are not English but I think you’ll get the point.
The mode has been changed from a “first” parameter to just a parameter in the if statement on all automations using them. I changed all mine back to be the first parameter as they’ve always been using the little switch at the bottom. Then it seems to stop the looping… Not celebrating yet but it would explain the irratic behavior of all my other automations.

1 Like

Not sure what the difference between the 2 are as they mean the same thing. However, I changed them to Simulated Switches as there was an option to do so. The behavior stayed the same, the status does not change on STHM. Webcore is not able to modify the STHM status directly even though you can code to do so. To work around that, I set up the virtual switches to make the change which was working fine until a few days ago. There seems to be no current way to programmatically change the status in STHM.

I see what you mean. The ‘precondition’ setting for the location mode had been turned off in all my Automations.


Although the words mean the same thing, technically the two DTHs do have some significant differences. One of them checks the state, the other does not. One of them runs locally, the other runs in the cloud. So it happens that some people have found that the looping problem was apparently caused by the state issue, and switching to the other DTH fixed it for them.

Exactly…! All of a sudden I could run the Goodnight automation without the house looping into I’m back och Goodbye routines…

I’m still having issues with SHM and virtual switches which change alarm states

Been over a week.


Same here. STHM either shows no sensors, or when it is there it loops many times from armed to disarmed and it you never know how many times. Please help.

1 Like

I had the same issue with the infinite loop and the app showing no sensors. If you are using Virtual switches to Arm and Disarm STHM, log into the IDE and change them to Simulated switches. Immediately corrected my issue.


I am trying this as well and hopefully better

That worked for me. Thanks.

I guess I want to know why? It will probably make me fell better understand this. The Virtual switch type was working before and now it doesn’t. What got changed? Are we going to deal with this again when something prevents Simulated switches from working with STHM?

I can tell you what I had in mind when I suggested in another thread that I could see a failure mechanism that Virtual Switches have that Simulated Switches wouldn’t have. It’ll be a bit wordy as I want to cater for a broad audience.

Legacy Groovy device handlers (which the stock Virtual Switches and Simulated Switches are) set device attributes by sending an event. These events then get propagated to apps that have subscribed to them. The apps can choose to subscribe to certain values, e.g. on or off in the case of switches, but it is arguably more common to take what comes. Apps are often particularly interested in changes of state, so for a switch they want to know about changes from on to off or off to on. The legacy SmartThings platform agrees and by default only propagates the state changes, so apps only see on, off, on, off etc. That is how the Simulated Switch works.

Sometimes it is useful for apps to see every event regardless if it is a change or not. For example you might have a button used to turn a switch on and you might want to see every press on it. So you want to see on, on, on etc. This can be achieved with the isStateChange: true flag when sending events. This means that the event should be considered as a change of state regardless of whether the value has changed. Apps can see off, on, on, off, on, off, off, on etc. For whatever reason, this is how the Virtual Switch was written.

Now let us consider the particular example of the using six automations and three virtual switches to expose the STHM status (Security Mode) to third party apps. It basically distills down to three pairs of Automations that say, for example:

  Security Mode is disarmed
  turn Disarmed switch on
  turn Armed (Stay) switch off
  turn Armed (Away) switch off


  Disarmed switch is on
  Set Security Mode to disarmed

Bearing in mind that automations (however implemented) typically get triggered by changes of attribute state, what you have there is a potential infinite loop. Turning on a switch changes the mode, which turns on a switch, which changes the mode etc.

The user is entirely dependent on SmartThings stopping that infinite loop happening and we know it can do it as it has been doing so for a long time. So how does it do it?

Well if the user chose to use the Simulated Switch, or other custom handlers that behave the same, they have a result because if, for example, you set the Disarmed switch to on when it was already on you aren’t going to have the event propagated and it won’t start another Automation.

However lots of people use the Virtual Switch handler and that will happily pass on continuous on events. So now we are relying on SmartThings helping us out in other ways. For example, maybe you can’t repeatedly set the Security Mode to disarmed. Well anyone who has seen repeated notifications from the app knows that you can so that can’t be it.

So what is it? Well to be honest I don’t know for sure. However the Automations aren’t legacy apps, and new integrations are working with a different API. I seem to remember seeing the state change flag on subscriptions. So maybe they can choose to only subscribe to state changes. That would explain why things worked OK.

So what has changed? Well apparently Automations and Scenes have been reengineered as front ends for the Rules API rules in the Rules API. So is the new implementation of Automations also only subscribing to state changes, or is it seeing everything? I don’t know, but if it has changed it would explain some apparent infinite looping issues with Virtual Switches.

Update: I had it in my head that the Automations and Scenes would still be entities in their own right that were effectively a front end for the Rules API. Things make more sense if they ARE rules and that what we see in the apps is derived back from the rules. Indeed ST have already pretty much said that is what they are, I just didn’t completely grasp it.

All I know for sure is that a mechanism like I describe above could explain certain reported issues. It could be correct, it could be broadly along the right lines, or it could be complete nonsense. It was where I was coming from though.


Thanks, Graham.

Very clear explanation of a possible mechanism for the recent changes in behavior, thank you! :sunglasses: