Get ready to make the switch!

One shouldnt have to go into a development interface to create a virtual switch to trigger an automation, Jody.

The way the UI choice has been described to end users is:
Scenes are collections of settings
Automations are calculations and decisions based on reactions to triggers.

It just makes sense that an external factor such as Alexa or GH with an official integration should be able to trigger the automations as well.


Scenes are fine for some things, but are limited in scope. Yes, I use virtual switches when necessary, but this is a kludge and an extra step that should not be necessary. Much cleaner to invoke an Automation directly, just like you can with a Routine today.

Can you explain your use case? I have some ideas, but it would help the developers what you really want to achieve.

1 Like

That to me is the real problem.

I see sense in splitting up the actions of a Routine, which can be directly activated, from the optional automatic triggering component, which could then be reusable for other purposes.

If all the actions available to an Automation were available in a Scene then it would be job done, and indeed game changing.

Instead the ability to directly activate the payload has been lost.

Routines have not been replaced by Automations and Scenes, which it is how it is presented. That would have been fine. Instead they’ve been replaced by Automations and lost functionality. Scenes remain as marginal as ever.


One of the decisions every framework developer has to make is what to do with filtered actions. :calendar: :alarm_clock:

For example, if someone has a routine/automation to unlock the garage cabinet which is set to run only when Michael comes home, it’s Friday, the time is between 7 am and 9 pm, and the garage light is on, which we’ll call Automation One, what should happen if that is automatically exposed to Alexa? That is, when someone says, “Alexa, turn on Automation One,” should the cabinet immediately unlock?

Should it unlock only if all the other conditions are met?

Will Alexa check the conditions or will the automation hub do so?

This is the standard home automation industry distinction between a “scene” and a “routine.” A scene is unfiltered, and therefore available to be actuated by routines or buttons or voice assistants.

A routine has filter options, and therefore typically is not exposed to voice assistants.

SmartThings history

SmartThings was unusual in that it developed routines before it developed scenes. So back in 2016, it exposed its routines to Alexa by identifying them as scenes. Which they weren’t, because they had filters, but they didn’t have many filters and it worked OK.

Then over the years SmartThings added true scenes and in 2018 introduced the new V3 app with much more complex automations (no longer called “routines,” although I don’t know why.)

So now SmartThings matches the industry in having actionable “scenes” and filtered “routines” (which SmartThings calls “automations”) and, as is typical, exposes ALL scenes to voice assistants, but not its automations. So far, so good. :sunglasses:

Not exposing automations avoids the question of what to do with the filters.

Going forward

If SmartThings changes it up and exposes automations to the voice assistants, that introduces two major safety issues,

  1. How will filters be handled?

  2. At the present time, ALL ST devices and scenes are exposed to both Alexa and Google Home. As of early 2020 you can no longer selectively enable voice authorization. So what happens when someone in the home misspeaks and unintentionally triggers an ST automation normally used only in emergencies? It’s going to get messy. :rotating_light:

The workaround for 1. Is typically similar to what SmartThings has done with the Logitech Harmony integration: have ST create virtual buttons to represent each automation and expose those to the voice assistants as devices, leaving all the filter processing on the ST side. This is the same as creating your own virtual switch, it just does it for you.

But right now there’s no workaround for 2 and, as I mentioned, it introduces a huge number of potential safety and parental control issues. :scream:

I don’t have a good design strategy to suggest. But I did just want to mention that there is a real reason why the industry generally distinguishes between IOT “scenes” and “routines.” And this distinction has become even more important with the introduction of voice assistants.


@Gwalker88 @orangebucket @jody.albritton @nathancu @GSzabados


I disagree. I have many automations and I don’t want all of them exposed to Alexa for the reasons JD outlined. Scenes makes it easy to differentiate the groups of actions i want available to both automations and voice control.


Understandable, and I totally get the fact it’s a design decision. Although, I would submit that the exact reason you point out (filterable) is the reason WHY Automations should be exposed… I also want the ability to filter what the Voice Assistants ‘see’ back, but that’s a completely different rant and feature request. In my case I’d almost always filter out all my scenes and only expose the automations if I were able.

If I say “Assistant, run Automation 1” It triggers- no questions asked. BUT the Automation Platform has the intelligence built in to determine if it SHOULD do the thing in Automation 1 or what conditions should be put on Automation 1 when it runs. …including safety concerns. (Which should always be applied closest to the common point of activation anyway.)

1 Like

Nor do I. I don’t want any of them exposed.

My point is that the only reason you might want Alexa to run an Automation is to ignore the conditions and just execute the actions, as you could do with Routines. The only reason you might need to do that is because you can’t currently put all the actions an Automation can execute into a Scene.

Yes, I agree. My point is that, if you can only use Scenes to control devices and set the location mode, you can only do that with a subset of actions.


So, I’m still missing it . How can I migrate?

Ugh… apparently this is not ready for prime time. Needs pushed back… a lot. If this is pushed out too soon, your support team is going to crash…like the new app.

Think I’ve found a bug… Trying to create an automation in the New App to turn a switch off after 10 minutes following the trigger. So I set it up, switch the Delay This Action to 10 minutes, the delay is set and when you go back to the edit screen the delay is shown as 10 minutes. However, if you then go to change the delay, the delay is no longer set. If you set to come on after 10 minutes it all works fine. BTW, this is iOS only. Seems to work fine on Android…


This means that you’re using features that were still being worked on/tested. You should see the banner soon, but I can’t give exact timing. Just know that it’s hard to miss once it’s showing. :slight_smile:


What is really needed is a way to choose what ST notifications are ment to who. As You suddenly took SMS capability away from us there is no other way than send all push notifications to all users. Now my kids are getting notifications that are ment to parents. Now my wife is getting multiple notifications per day which for her… are useless.
Also I’m loving the idea that if somebody brakes to my house we are all getting information about it. I’m not loving the idea where I’m alone in home and my wife and kids are other side on planet. They are getting infomation about that door has been open more than 15minutes.
Is there any chance to add possibility to choose which push notifications are sent and who they are sent?


Like other useful features this used to be a capability of smart things but they removed the “my contacts” feature some time ago…


I would like to see a popup saying what it holding me up from migrating. Maybe I have old stuff I can get rid of that is marking me as not ready yet. Or I could find a new way with the new app that accomplishes what the hold up is. If I saw the list in the popup shrink, it would give me give me insight as things are fixed and could provide feedback into how those things operate. Unfortunately, it is a combination of backend changes and app updates, which either are never announced, or summed up in an announcement as “bugfixes and whatnot”.

I understand where you’re coming from and this is a great idea, but in full transparency, building something like this would distract from the development efforts to get everything working properly and migration completed.

As I mentioned WAY back in this thread, the main things that the migration tool will help with are converting routines to scenes and automations, and porting over your lock code management and SHM settings. You’re welcome to make those changes yourself and start using the new app. Either way, the team here appreciates your enthusiasm :slight_smile:


I figured. I use the new app for most things now, but would rather wait for the migration to change my routines over. That’s a fair amount of work I don’t want to replicate :slight_smile:

I’m at a loss when trying to make my custom (Window Shade) DTH work in the new app. All of the functions are triggering actions (eg. shade moves and displays battery status etc) but every button press in the new SmartThings app results in a “A network or server error occurred. Try again later” error message after a timeout (despite it actually working just fine!)

As a test I have simplified my on() and off() functions to the following (so that they don’t make HubAction calls etc) and I still get the error message in the new SmartThings app. This error does not occur in the classic SmartThings app!

Here is the simplified on() and off() methods I’m testing with:

def on() {
    log.debug "Device ID: $device.deviceNetworkId on() was triggered"
    sendEvent(name: "switch", value: "on", isStateChange: true)
def off() {
    log.debug "Device ID: $device.deviceNetworkId off() was triggered"
    sendEvent(name: "switch", value: "off", isStateChange: true)

Does anyone know what could be causing this as I’m at wits end!

probably that weird glitch in the app/appserver that’s come up in the last several days. I am still hoping an official smartthings rep will notice the posts about it. Mine all work fine, in spite of showing as offline lol

I have noticed that the error appears when, for example, the ‘on()’ command doesn’t result in the attribute eventually changing to ‘on’ within a timeout period. Where the Classic app would get stuck in ‘turning on’ (if used), the new app gives the error.

However your test would seem to destroy that line of thinking, unless the ‘on()’ and ‘off()’ commands are being used for other attributes.

1 Like