"SmartThings Classic" vs "SmartThings (Samsung Connect)"

Samsung Connect is completely unusable for me, as it won’t even start up if you don’t give it “Contacts” permission. That’s ludicrous. Samsung doesn’t need all my contacts to control my lights.


We have an ActionTiles customer reporting that they cannot create Routine(s) in the new SmartThings App.

  • Does this sound correct? Has anyone else experienced this?

  • The customer was having problems with sunrise/sunset, so SmartThings Support deleted all of their existing Routines. Perhaps this had the unfortunate side effect?

1 Like

The new app has no concept/Smart app called routines. But it does have a unique rule builder that accepts multiple conditions and multiple
Actions. But I don’t think they get exposed in the same way as routines.


The new app doesn’t call them routines, but automations. You get to them by clicking on the Automations button on the bottom and then clicking on ADD at the top. You will be prompted to select your location if you have multiple. When you do that you will need to scroll to the bottm and then click on on custom automation. In here you have the option for Conditions and actions and this is where you setup your automation.
If you click on condition and then based on time of day there is actually a time to select Sunrise and sunset. If you select that then you get the option to select modify it some by adjusting for time before and after sunset.

I haven’t been impressed with the options here there are some combinations of conditions and actions that don’t work. Like if i try to set the action to change SHM mode i can only do set it by time of daym, not by presense. that makes no sense.

1 Like


Really appreciate that SmartThings to informed us of this non-trivial difference. Though, mea culpa if this obvious from any published documentation. Remember: We were all told repeatedly that the “old” (Groovy) API would remain available and functioning for a “some time while we maintain both the new system and legacy systems”.

Lots of existing SmartApps (including ActionTiles) use Routines. So … available, but not compatible with the 100% recommend “new mobile App” is problematic; even if, technically, no promises were made to the contrary.

The Big Questions:

  • Will the ability to create and run “classic” Routines be added to the new App?

  • and/or How will new “Automation” routines and Scenes be exposed to execution by “new” (and “old”?) SmartApps?

1 Like

I would say for now there is a decent chance of that. They already added support for smart apps to the new application. It wasn’t long ago i didn’t see anything on that automation screen. Now i can see all of the apps i have installed including apps i have loaded from repos, and things like action tiles. That only happened after the last update I noticed.

one thing i have noticed though is that it appears some stuff created or installed from the new app doesn’t show logging in the IDE so i wonder if they are using some new backed server for some of the new apps. The new SHM is one that is completely absent from the IDE as far as i can tell even though i have it installed


Since we probably won’t officially know until it happens, let’s speculate :slight_smile:

Currently in the new app, you can create a scene and said scene can be activated by the Custom Automation smart app. Both of these are unique to the enw app and don’t show up in the classic app or the IDE.

But at the same time, custom smart apps installed in the legacy IDE and classic app, DO show up in the new app. So there is your continuing support of the legacy IDE. There are also marketplace apps from the classic app that have been migrated over (both SmartThings written and outside dev written)

But some solutions/apps aren’t in the new app (routines, smart locks, etc.). There’s another (Smart Home Monitor) that IS in the new app, but is a total re-write using the new API and has some new features. I have a feeling we will see more of this.

1 Like

I don’t think we’ll see classic Routines in the new app. The custom automation builder can do (or is shaping up to do) the same thing as routines and more.

1 Like

I kind of agree, but that doesn’t mean they shouldn’t have a way to migrate what is in the Classic app and then also make them avaliable to apps like Action Tiles.

I hardly use them, but i do see there value. Before i started using some of the smart apps i have i did several things in routines.

Hopefully they just really the new rule egine powerful enough to do whatever we like

1 Like

Which is great… except that I can’t find any method (new API or old…) to directly execute an Automation from a “SmartApp”, and thus, from ActionTiles (or WebCoRE, custom Alexa integrations, etc…).

They should, but SmartThings history of migration tools isn’t very good :wink:


Yea… I have heard that. I haven’t been here long enough to really deal with that yet, and though i have kind of taken the plung with the ADT Security panel on using smart things my usage is far less then most.

I’ll start off by saying that none of this is finalized yet and things may be different when actually released in production but… I can offer you what the current thinking is in regards to how Routines will be handled in the new app.

You guys are correct in thinking that Routines won’t exist in their current form in the new app. We are looking to have a migration process that will convert existing Routines into a combination of DIY Rules and Scenes. We are currently in discussions on how the migration would actually happen (what the UX would be of the migration itself). This is still a ways off - so I wouldn’t expect this to happen soon. Given our history, I’m always hesitant to speak about the future especially when the word “migration” is involved but I do think this one will happen.

In regards to APIs, these are currently being built. You should expect to see the Scene API released publicly before the Routine migration happens. (and remember, by API I mean REST/HTTP, not Groovy)

EDIT: I haven’t read far back into this thread but if you have a question feel free to ask - I’ll try and give an answer if possible ( as long as its information I am allowed to share).


Hi @vlad, I’ve got a question that I know concerns many other users too.
Why does the new app need access to all my phone contacts? Just to turn lights on?
I’m sure Samsung is a morally upstanding company, will keep this information safe and not let it be used for nefarious purposes but the risk is always there, but I still feel it’s unnecessary.
So the question is why is this permission necessary for you?


Will try and track it down - my iPhone doesn’t require it but Android does and the “official” reason is:
• Contacts: Verify user information that will be delivered while transferring files.

I’m not sure what that means and don’t know of any feature that transfers files, will see if any of the mobile devs can provide a response that makes a little more sense.


Hi @vlad ,

Will custom device handlers be migrated? I’m using a modified DH for Aeotec multisensor 6 to make it report lux every minute (this is not possible in the standard DH where 4 mins is lowest it can be set; no good for control of my lighting automation)

Also, how about smartapps? I’ve got Advanced Button Controller to provide dimming commands to an Aeotec remote controller.



Why has there been resistance from Samsung/St to adding a new section on the forum for NEW smartthings? Why is there no information in the Announcement section about new smartthings

The inclusion of any or both would surely help confused users and developers alike


It would go a long way if you guys “ST Staff” created an Announcement in the Announcements section, even if it was locked from replying to and it contained everything that everyone needs to know (and is actively updated on a regular basis):

  1. Why it’s there
  2. Who should use it (Samsung Connect Pro customers for iniial Configuration)
  3. What capability it has (growing list).
  4. Shares same IDE so anything you do here, affects ST Classic (example if you turn off Location services, it will remove your mobile phone in Classic and remove Location and impact you if you are trying to use both apps)
  5. Comes pre-loaded on these devices
  6. The plan for migration (still being worked out)
  7. Account Migration beta users have tested functionality and differences between both (their accounts are prime candidates to beta the new app).
  8. Have an active beta (official customer, not internal) for the new app as you introduce new functionality.
  9. Equivalent of everything in Classic will eventually be available (when we go live for real) in the new app.
  10. Etc.

Explain everything and anything about it:

This little email that went out, obviously did nothing to minimize how much pandemonium and issues this has created by having both apps available and who should mess with it and who shouldn’t.


When you go through account migration all smartapps and dths (including custom) will be migrated as well. My understanding is that custom smartapps should already work in the new app. The Custom DTHs are a different matter and will not immediately show up after migration, the reason is that the new app displays DTH tiles differently and we need to figure out how we will move forward there - here is the latest info on this, again, this is all subject to change because this is all currently in design/planning:

  1. DTHs available in ST Classic (community written ones that are published by ST) will be the first to start working in the new app - the work to enable this is in progress.
  2. Support Custom DTHs published in the IDE will be next, we know our options here but have yet to decide which implementation path to follow
  3. Support for Custom DTHs published in the IDE WITH custom attributes/commands - we don’t have a clear strategy for this quite yet

Also remember that we are in tandem working on the new platform api, check out Samsung developer docs for this.


I agree that there should be better communication in regards to what’s available or not - unfortunately I don’t have much visibility into that on the engineering side (official channels of communication). I can bring this up but I doubt it will get traction, apart from engineering and occasionally a few select support staff the rest of the company doesn’t actively use the forums as a means of communication. I walk a fine line here and sometimes overstep in regards to transparency because this isn’t an “official” channel - the second product management and communications gets involved its a completely different beast (not just within ST, we are working VERY closely with samsung on the app and the dynamics change when HQ is involved) and to be honest, i don’t think anyone in engineering has the bandwidth to maintain something like that. But yea - I’ll ask Product, maybe a table somewhere public of feature parity gaps between the apps would be enough or something and we can update it as feature releases go out.