After many happy years of Smartthings, Alexa and Webcore integration I have been forced to switch to the new app and it is basically a disaster which has brought my smarthome to it’s knees.
I understand that SHM is now STHM and not supported by Webcore. It also appears momentary buttons are not supported. These two things are the basis for much of my logic so Ive had to start over.
Here is where I need help please. It seems that automations setup within the new smartthings app do not consistently fire
I have 3 security modes : Disarmed, Armed (away) , Armed (home)
I have set up a new automation within smartthings app to turn on and off a different simulated Alexa Switch based on the security mode. This allows webcore to be able to determine the home’s security mode by looking at the simulated switchs to see which one is one.
My issues is that the automation’s do not run consistently. Sometimes Smartthings will turn the applicable virtual switch on or off accordingly with the STHM change, but sometimes it simply does nothing and the virtual switch is out of sync with the security mode, rendering webcore automation useless…
First, Momentary Buttons:
to replace any of those you need to change the device handler for those to Simulated Switch and either use SmartLighting Power Allowance or some automation to turn them off automatically after they’re turned on.
Now Alexa - that’s the toughest one. In the middle o fmigrating to NewApp SmartThings ALSO replaced the Alexa skill. I assume you moved to it. There’s LOTS of issues with it right now. I mean TONS. The best I can tell you is we’re all dealin gwith it and reporting lots of feedback to the team that’s on that component. For the latest see this thread: https://community.smartthings.com/t/new-smartthings-alexa-skill-2020/
Thanks for the quick reply. As for point two “SHM/STHM”, I’ve inadvertently built the exact same automation as recommended , just with the the simulated alexa switch - so should be good.
I’ll try following up with the alexa skill thread, perhaps as you say the issue is related to the alexa skill? I guess I could try building the same automations again using a traditional virtual switch to trouble shoot if it is the Alexa integration that is causing the issue?
ON a side note, one of my automatons keeps adding the “send notification” action whenever I change security modes as part of that automation. Even after I remove it and save, it comes back again the next time I view the automation. The other two automatons do not have this action . Any thoughts on how I can remove the unwanted action? Thanks!
Depends what you mean by a momentary button. The Momentary capability that lets you call a push() command via the app UI works fine but the Automations don’t seem to be able to work with it except when it is used with a switch, which is daft.
The momentary buttons you could create in the UI Classic app to run custom commands aren’t quite with us yet.
I had that experience.
I was using it bidirectionally with the switches acting as intermediaries between STHM and the SHM status in webCoRE so I assumed I’d overcomplicated things (there were too many triggers flying around). It could have just been broken though.
Ultimately though, I realised that I had no use for that approach anyway as it was no other apps business what the security status was, let alone should it be able to change it. I must be one of the few people who actually believe that only allowing Automations to work with the Security Mode is ‘a good thing’. Admittedly this is a recent realisation. None of which helps you.
This was a compromise they made to allow STHM control in Automations. For a while it couldn’t even be automated You should be able to delete the notification before you save the automation.
Yes, I deleted the action, it dissapears and I tap save. However, when I go back in it is still there and the notifications are still being sent. This seems to happen for the disarm automation only.
Nathancu I know you said this was likely an issue with Alexa skill, however I just changed the virtual switch type from simulated alexa switch to virtual Contact switch to try and trouble shoot. The issue is the same where-in Smartthings Automations do not consistently change the virtual switches to align with the Security mode. So I don’t think this matter is related to the Alex skill specifically. Would you agree? Are there any other suggestions? Thanks.
No, the automations are based on security modes set manually using the STHM buttons (ie. when I press security mode to “Armed (home)”, turn on Virtual Switch “Virtual Armed (home)”. I haven’t even begun to rebuild the presence based triggers… goodness knows how messed up that will be lol.
At this point these are just simple automations that should be working… Any other thoughts? I’m really surprised I don’t see others with this specific issue… it would seem to be pretty widely used.
They are and I’ve had similar ones in my app since day one, setup exactly like the ones described in the AT article (As I’m both an AT and WebCoRE user) Those have always been rock solid. Admittedly the difference between mine and what you described is mine use Simulated Switch v. Alexa virtual Switch. (But for the life of me I can’t see where that makes a bunch of difference)
The only thing I can think of is standard troubleshooting applies. Tear 'em down - rebuild 'em, see if maybe a different kind of automation like sending a notification instead of throwing a switch changes it. And of course - trouble ticket to ST.
I just tried changing my virtual switches to Simulated Switches. The same result, inconsistent automation that results in an eventual out of sync condition. It seems to be most prevalent when changes are made to the mode more rapidly, as in changing the mode and then changing it back within 20 seconds, not sure if that is pertinent.
‘Me too’ isn’t much help, but again that was my experience.
Different virtual and simulated switches can behave differently because of the way state changes are handled. Setting a switch to ‘on’ when it is already ‘on’, for example, is not considered a state change by default and so wouldn’t trigger automations. However that can be changed in the device handlers (whether deliberately or through misunderstanding).
This can have implications as security mode changes cause switch state changes, and switch state changes cause security mode changes.
Thanks. Yes I am aware of a switch that is already on not being considered a state change. In this case, I have 3 switches, one for each security mode so there is no circumstance where the automation could be trying to turn something on when it is already on, unless it has already fallen out of sync - which is the core of this initial issue. I guess I’ll open a ticket - unfortunate that I have to do this for such basic functionality.
Bump. Wondering if anyone else in the community has any suggestions? I’ve opened a ticket but am still waiting to hear back on a previous ticket for a separate issue opened 5 days ago with no reply. I remain less than optimistic that support will be able to solve the issue.
You should be able to delete the notification before you save the automation.