Need to better understand all the ways of creating controlling algorithms

I already read a number of topics in this regard but still struggling to understand what options I have to create a controlling algorithm and what are the advantages and disadvantages of each.

I see there are at least two ways in the Android SmartThings application: SmartApps and Automations. Both look similar in terms of what they are for. Both implemented in a similar way, sort of a wizard asking you questions what to compare and what to do if the result of comparison is true or false and using this building blocks you create an algorithm what to do. Now the questions.

  1. In accordance to what I read SmartApps run locally, I assume in the hub and Automations in the cloud. Is this true?
  2. I, also, remember seeing somebody mentioned that SmartApps have more capabilities that Automations. Is this true?
  3. Is it possible to write one or the other as an expression or script instead of using the wizard-like UI?
  4. Is it possible to convert one or the other into a script and save it separately?
  5. Is it possible to export one or the other in any form and then import into another account or share them between accounts?

Then, there is another type of SmartApps which can be written as groovy scripts on

  1. How this SmartApp are similar or different with the SmartApps or Automations in the Android SmartThings application?

Then, there is yet another type of automation mentioned on this page SmartThings Developers ( You can click on Create an Automation (Learn More) and it will lead you to SmartThings Developers | Documentation ( with the title “Create a SmartApp”. And if you go to “SmartApp examples” you’ll end up on the github with examples written with NodeJS. It looks like this type is somewhat related to AWS Lambda.

  1. How this SmartApp is related to other SmartApps and Automations?
  2. I, as an engineer, mostly interested only in which one will give you the most control over the algorithm and I would prefer to be able to run the algorithm on the hub. So, which one to chose for that?
  1. No. Legacy SmartApps run in the SmartThings cloud and those for the current environment are user hosted, AWS Lambdas being an option. There is a minor exception involving the legacy Smart Lighting app. Automations are implemented as Rules. Parts of these Rules are implemented in the hubs. If the Automation only uses those, and only works with device handlers that are also implemented in the same hub, then they can run in the hub.
  2. SmartApps are custom code. You can implement whatever logic you like. Legacy apps are written in Groovy and run in a sandbox in the ST cloud so there are constraints. Current SmartApps are implemented by users and third parties and have no real restrictions. Automations are a simple ‘if these things happen or are true then do these things’ type structure.
  3. Automations are created with the UI given. However they are converted into Rules which are expressed in JSON. You can create that JSON however you like.
  4. I’ll say no. It may be that in future the Rules implementing the Automations get exposed.
  5. Automations, not at the moment. Stock SmartApps are already in each account. Others are installed in each account as you require.
  6. That is the development environment for legacy device handlers and SmartApps. SmartApps you create and publish there will be listed in the app alongside stock apps created by SmartThings.
  7. That is describing the current platform where user created apps are self-hosted or use AWS Lambdas.
  8. If you want things to run on the hub then your only real option is to use the Rules API which is still evolving at the moment.

When you talk of a ‘wizard-like UI’, you are seeing two different things. For Automations you are seeing the mobile app itself running code to build Rules in JSON that are then submitted using the SmartThings API. For SmartApps what you are doing is launching a remote application (in the ST cloud for legacy apps or third party/AWS hosted for current ones) and those apps are returning a request for configuration information. The mobile app handles that interaction and sends the information off to the app. The apps are essentially event handlers so you generally only interact with them in the app for configuration purposes. There are some exceptions for stock apps like SmartThings Home Monitor that can have a UI in the app itself but that functionality isn’t generally available.

If you use something like Smart Lighting, you are initially interacting with a parent app and each Smart Lighting automation is a separate SmartApp in its own right.


Different accounts are in different “shards” in the SmartThings cloud, and so have different URLs.

When posting to the forum, it is best to use the universal sign-on link,

Which will work for anyone since it automatically redirects you to the correct shard for your account.

Otherwise people can get very confused and even cause some problems for themselves if they start working on a shard which is not associated with their account.

See the community FAQ:

@orangebucket has given you a very good answer, I’ll just add a bit of history And a few resource links. :sunglasses:

Back in 2014, smartthings hosted a groovy cloud and customers were allowed to write their own custom code and run it there. That’s also where most of the officially provided smartapps ran.

Over time, some of the officially provided smartapps were moved to local operations on the customer’s hub, Particularly “smartlighting.” To this day, Customer-created code still ran in the cloud.

As smartthings scaled up, Samsung wanted to get rid of the groovy cloud, and it is scheduled to go away by the end of 2021. In Its place, Samsung offered two things: a quite robust scripting language called “the rules API,“ which is still in development, and a new integration API which allows customers to write code in any language they want, host it themselves, and integrate with smartthings through that cloud-based API. There is also still a simpler rules engine built into the smartthings app, which is what you find when you just hit the + in the app and add an “automation.” The built-in rules engine is a lot more sophisticated than the one in the 2014 version of the smartthings app, but the rules API can still do much more.

So right at this moment, the summer of 2021, we are teetering on the edge of a major major transition, which is when the groovy cloud will go away. We don’t have an exact date for this, but it’s pretty clear that a lot of things are going to stop working on that day, and not all community developers are creating replacements.

Most recommendations are that if you are just getting started now, you should start with the rules API or with your own hosted code using the integration API since the Samsung-hosted groovy cloud will be going away soon.

The Terminology keeps changing, but it does sound like they are going to keep the “smartapp“ name for customer written code in the future, but it’s going to mean something very different. Instead of being groovy code hosted by Samsung in the smartthings cloud And added to your account through the IDE, it’s going to be code that you host yourself and integrate with smartthings through the integration API. Many people are using MQTT for this now, and that will continue to work, but you do have other options as well.

Whether it’s the old architecture or the new architecture, you do not have the option to run your own custom code on the smartthings hub.

So… if you are reading threads about coding from anywhere except the new developers section of the forum or the new developers website, it’s going to be referring to the old groovy cloud and that’s not going to do you much good in a few months. So that’s where a lot of the confusion probably arises.

If you’re just starting out now And you want to do more than what the built-in rules engine in the app provides, probably the best thing is to start with the rules API, see if it will do what you want it to do, and if so, move forward with that. Because that code will continue to be hosted by smartthings, and some of it may even run locally on the smartthings hub.

If you need features not supported by the rules API, then it’s probably best to go with the future direction and write your own code, host it yourself, and integrate through the integration API.

There are a lot of links that might be relevant on all this. I’m just going to put a few here and then if you have specific questions we can pull up some of the others that might help. Also note that both the rules API and the integration API are still in development and documentation is not complete. :disappointed_relieved:


  1. Official announcement of the coming changes, including the termination of the groovy cloud
  1. Developer section of this forum. This is where you’ll see a lot of questions and some answers on what the changes mean for custom development. There are some staff members who regularly post in the section.
  1. The rules API subsection. There seems to be an attempt to call the individual rules that people create through the wizard “recipes,” But that hasn’t really caught on with the general community yet.
  1. The new developer website. You’ll need to set up a developer account here in order to use the integration API. Documentation is not yet complete. This particular site uses the term “automation“ for what other smartthings materials still call “custom smartapps.“ (Inconsistency in terminology is a long-standing smartthings tradition. :face_with_hand_over_mouth:) Also although that site makes it it look like signup is only available to device manufacturer companies, individual customers can also register for a developer account.

That’s probably enough to start with for now. :sunglasses:

Everything is much clearer now, however taking into account all the information above and if I understood it right I should be able to create an automation item in the Android SmartThings application and then read that rule via the Rules API, right?

  1. I created a few automation items via the app.
  2. I obtained my personal access token in accordance with SmartThings Developers | Documentation
  3. I run this request to get a list of locations and that worked fine, I found the location that I created in the app

Accept-Encoding: gzip,deflate
Authorization: Bearer: [Personal Token]
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)

  1. Finally I run the request to get a list of rules but that request returned an empty JSON

GET[LocationId returned from the previous request] HTTP/1.1
Accept-Encoding: gzip,deflate
Authorization: Bearer: [Personal Token]
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)

It is a nice thought, and it would be really useful to be able to see what Rules the Automations create, but no. I don’t know what the exact mechanism is. It might simply be that the rules created via the Automation are owned by the application, whereas the ones created by the CLI are owned by the Location (*). They probably don’t want the Automations to be visible yet as they use Rules that aren’t publicly documented.

(*) I use a Personal Access Token with the CLI. I don’t know if it makes any difference if you ‘login’ with the CLI instead. I don’t really understand how the various tokens work.