Why only 8 SmartApps (2020)

Why are there only 8 SmartApps to choose from? (Android SmartThings App)

This doesn’t give the impression that there’s much focus on this area. Should we be looking at something else?

That list is mostly the Samsung provided ones and a few really old ones that have been listed forever.
Most community created smartapps (including the most popular, WebCore, Echo Speaks, etc.) aren’t listed in the store - you have to install them yourself. There’s tons of them - just have to go look.

Individual smartapps are no longer needed for most use cases since the new V3 app provides multiple features for creating rules which are much more sophisticated than the older generations, as well as easier to use.

These include:

  1. The official “smart lighting“ feature. These are the automations which are eligible to run locally.

  2. The official “SmartThings home monitor“ feature. These automations can trigger security notifications.


  1. Custom automations. This is what you create when you use the + in the new V3 to “add an automation.” These allow for multiple triggers in a single rule, timers, delays, different types of notifications, etc. At the time of this writing, these automations run in the smartthings cloud.


These first three are all that most smartthings customers will need to set up the rules for their system. :white_check_mark:

In addition, there are two more options for people with a strong technical background or who have a particular very complex need.

  1. the official “Rules API.” Still in development, this feature is a full-fledged rules engine with variables and other programming features.

  2. Webcore. This is a highly sophisticated community – created rules engine which has been around for a couple of years. It’s essentially a scripting language for the smartthings groovy platform. Very powerful. shortly after its introduction, Most developers stopped writing individual smartapps as webcore just provided them With a much more effective way to do the same thing. Individual rules in Webcore rules are called “pistons,” and community members do share them with each other, usually through the webcore forum, which is very active. See the FAQ (The topic title is a clickable link).

So the short answer is that we don’t need a lot of smartapps anymore. The rules engines options listed above are much more powerful, easier to use, and quicker to set up. :sunglasses:

This process began in 2016 and is now close to complete except for the continuing work being done on the rules API. If you check the following page from a couple of years ago you can see where many individual smartapps were being retired and the functionality moved to the official features. (‘Routines” are no longer used in the new V3 app, but have been replaced by the built-in rules engine for automations.)



Look where? Do you mean github and install the webhooks?

No here in the community site - there isn’t an application catalog except for the community installer. (Which is a good one by the way, it lists a lot of the most popular ones.)

But generally speaking you will have a need and look for an app to fill a need, rather than look at a lost of apps and pick.

1 Like

There’s the quick browse lists in the community-created wiki. But again, a lot of the items listed are no longer needed if you use one of the rules engine options instead. But the big complex ones like echo speaks are both listed there and have their own sections in the wiki. :sunglasses:


1 Like

Most of the older SmartApps were just simple “If this then that” rules. As others have said, you can replicate 80 percent of the functionality with an Automation or Smart Lighting Rule

The Rules API that was mentioned will allow even more complex behaviors than the automation tab and we are working with third party developers to build solutions on top of this new technology (Let me know if you are developer interested in doing this :slight_smile: )

In the future SmartApps will be complex solutions that cannot be satisfied by rules/automations.


Thanks everyone for responding to my question! I’m quite new to Home Auto so it’s really helpful to catch up with how far things have come. Forgive the following summary, it probably comes across as quite harsh and negative, but hopefully it will be responded to with encouragement for the future rather than laurels for our bums.

So in reply to (paraphrase) “Where have all the SmartApps gone?”, we have had:

  1. @nathancu Here at the Smartthings Community

Essentially this was where I was coming from. That there are only 8 consumer selectable SmartApps. The rest are scripts/programs (mostly hosted on Github). Presumably the consumer community is where the success of Smartthings rests, not the developer community. It’s a bit like Google saying “Well we only have 8 apps in Google Play, but hey look at all these Android Studio projects in Github! You only have to look!”

    1. “Smart Lighting”, “Smarthings Home Monitor” - These are 2 of the 8, aren’t they? More on this later.
  1. Custom Automations. Similarly more on this later

  2. “Rules API”. Still in development

  3. Webcore. Haven’t looked at this yet, but thanks I’ll check it out.

I’ve had a look at Smart Lighting: It allows me to select multiple Lights/Scenes/Devices. It allows me to select one trigger. I like the sunset trigger (because that happens to be mostly when I use lights). It allows me to choose a time offset too! (Will wonders never cease?) What’s more, having selected multiple lights it even allows me to choose a dim level ( :+1:), but it has to be the same level for all lights ( :thinking:)? Personally in 2020 I would hesitate to describe this as “Smart”.

Similar restrictions apply to the Automations feature, IMO.

I’ll give an example of what I think is a reasonable expectation for a new consumer. I have a dimmable night light and a motion sensor on my stairs. I would like it to brighten continuously (I don’t like lights that suddenly go from 0 to 100, in case you are wondering) from off, to 1% starting at sunset±X and reach 100% by sunset±. I’d like it to darken continuously from whatever level it happens to be from the previous rule at T local time to 1% at T2 and remain there till sunset. (It may be assumed I live south of the Arctic and north of the Antarctic) Notwithstanding these rules, if motion is detected, I would like the light to brighten to say 20% for a short while. Ideally if I “manually” turned the light on/off, these rules shouldn’t interfere with that choice.

I don’t think this is an unreasonable requirement. So, can you point me to a ready made solution?

A customer of 2020 probably ought to expect this to be out of the box as a Starter App.

Where I think this use-case challenges the Smartthings model is that it is specifying how I want the device settings to be when certain conditions hold, while Smarthings development talks about what to do to devices when certain triggers/events happen. Sometimes we live in world with an integration sign in front, rather than a differentiation sign.

I’m a retired developer and getting quite interested in Home Automation, so I’d certainly be interested in contributing to effort. However as a third party developer, I can’t say I’m experiencing too much receptiveness to “suggestions”. From my perspective it looks more like it starts with “we have developed this API, and we will show you how to use it” but then my experience has been there is still some work in progress and documentation that needs to be fixed, let alone a Getting Started link that fails to get you started.

I’m actually early-retired, which means I have a bit of life in me yet with some development energy to spend. However, I’m loathe to spend too much of that energy utilising a /schedules API that unleashes 80% of the power of cron, and a /rules API that unleashes 80% of the power of boolean algebra. But yeah, @jody.albritton, I’d love to DM to discuss some thoughts. I’m not a professional developer any more (though the fact that I’m retired early might be a claim to being a reasonably good one in the past) and the home automation area has become a new interest. I’m going to spend more time on Home Assistant soon, as I only recently discovered this.

Custom automations do allow you to select multiple triggers, but not to handle the use case you described.

I would respectfully disagree that most customers would expect that “out of the box” because other simple and very popular home automation systems don’t offer it either. For example, Amazon Echo routines, Apple HomeKit, Phillips hue and Xioami each have literally millions of customers and very high satisfaction ratings, but offer only simple if/then rule structures.

But that’s where smartthings does have an advantage in creating rules for home automation— It could certainly be done with webcore, which is essentially a scripting language for smartthings. :sunglasses: So I suggest you start exploring that. It should have everything you’re looking for. See the FAQ. (The topic title is a clickable link.)

It’s not “readymade,” But there are many people in the webcore forum who would be glad to help you create the rule that you would need.

Home Assistant is another good option as well, and may be a better fit for you. Different things work for different people. The trick is to find the one that works best for you. :sunglasses:

There are over 55 SmartApps and Device Handlers available here as part of the rboy apps subscription (and more on the way).

Also, it appears you may not yet have discovered “scenes,“ which do allow you to set different dim levels for different devices, but as you point out, only as an actuated event, not as a target with a delta change. But again, webcore can do that part. :wink:

I have indeed discovered scenes, but as you say, they are actually activated events. Use of nouns to mean a verb - always misleading :thinking:

Webcore does look very interesting, and I’ll split some time between Home Assistant and that.

Going back to the 8 consumer selectable SmartApps, it does seem me all the other roads lead to github? Maybe the user of 2020 ought to expect something more than a ctrl-A, ctrl-C, ctrl-V mechanism for software installation. Or maybe they have just gotten too used to App stores and certification, and package signing, and versioning and compatibility maintenance and all that :sunglasses:

1 Like

I did notice while browsing through the github repos, that many/most are written in groovy?

I think I’m missing some history here since I’ve only been looking at for a couple of months, but as I understand it there was an older version of Smartthings and now there’s a new world. So I’ve heard of two Android Apps (Classic and errr…not Classic). And there apps written in groovy in an old IDE, but in the new workspace it’s just webhooks and AWS lambdas.

So my question is: Is there a migration plan for all this? Is the way ahead webhooks and AWS, and will groovy be going away? Actually is there a picture of where everything sits, everything seems to be Smart and an App or a Automation. But where does the classical world end and the modern one begin?

As I said previously. You can get most functionality from the the built in apps and the automation builder. Just try hitting + and then clicking on Automation.

For more advanced functionality there will be the rules engine and and endpoint/aws SmartApps. There is some history to all of the legacy groovy stuff but that is a post for another time.

1 Like

As I said previously, I had looked at what’s already there. SmartApps, Automations, Scenes. Do any of them give me the kind of “appliance like” utility that I get from my 25 year old heating timer controller (with battery backup for the internal clock), which is aware of when on/off times are, and, were it to be interrupted by a power cut, or have it’s routine slightly augmented by a request for an extra hour. And when things return to normal, it knows what state the heating should be in. My mum has a 45 year old electro-mechanical timer-controller: when her power goes off for a minute, it performs almost as well, it just loses a minute! It doesn’t wait until the hour hand comes round again at the same time tomorrow!

You seem to feel happy that SmartApps and Automations cater for 80% of all use cases. But in terms of simplicity, I would suggest that the simple nightlight example I described earlier with the movement sensor brightness boost, would belong to the first 10% of essential use cases. Is this supported with similar simplicity to my and my mum’s vintage heating controllers? That was a question I had asked earlier. I believe the answer is “not out of the box, but it’s in github”.

Imagine what the reaction would been if the typewriter had been invented to cater for 80% of all letters. Perhaps you would then suggest that, since we support 80% of the digits too, we can always type the octal ASCII code for the letters that aren’t supported! :sunglasses:

Where am I going with this? I think it’s valid to put out there a requirement which I think is reasonable. Which is that the Consumer’s mobile app should expose something that is more akin to an “appliance” than a flowchart starting with cron and event triggers.

What do I think the response has been so far? What we have done so far ought to be good enough for you, and what we haven’t done yet will address what you currently want. Are those really :sunglasses: or are they complete blackout glasses?

I was hoping that, instead of pushing the ctrl-A, ctrl-C, ctrl-V method of software distribution, or at attempting to unleashing through encapsulation 80% of the capabilities of cron (/schedules) and boolean algebra (/rules, Automations), you might want to tell us how life in front of the integral by dt might be supported as well as life in front of the differential by dt.

For those of us who were born after the schism of classic and modern, would it be possible to describe what the future of groovy is, without leaving it for another time? Similarly, with device type handlers. The “history”, however bloody or not it might have been, surely shouldn’t still enslave and prevent us from making a clear statement about the future. For example, “it’s deprecated but no firm timescales have been set, and new development should take place with the endpoint/AWS style.” (“Deprecated” meaning the way I’ve come across it before, i.e. it still works, it’s not supported though, and in the future it will probably become non-functional). It might not even stay that way, but I think it should be made clear. It’s only very late on that I became even slightly sure that I should look at endpoint/AWS rather than groovy, because everywhere I looked on github it was almost all groovy, the Classic IDE looks like a proper developer tool, unlike the Smartthings Workspace with it’s enormous screen estate and 2 enormous links to get started (and that really is for another post…)

Apologies if that is how my statement came across, here is how I see the current state of the world.

Automations and Rules can cover at least 80% of what was done with “Groovy SmartApps” in the past. When everything was a groovy app we did not a have a rule builder and we did not have an open API.

The new endpoint SmartApps will bridge that extra 20%.

Ready made solutions for the situation you described are coming and will not require you to copy and paste code.

Let me see what I can do.


If you are referring to my frequent use of that emoticon, it’s sunglasses because I have vision challenges and use voice recognition and voice reader software. Just as many people who are blind wear sunglasses in real life, many of us online use the sunglasses icon as an indicator that voice reader software is being used. :sunglasses:


Thanks for telling me that. I really did not know that was how that emoji was used! :flushed: I thought it was just to mean “happy with that”, because that was the only context I’d seen it used before. I am slightly more enlightened that I was this morning :grinning:. I hope no offence was taken, and none was intended with regard to your condition.

1 Like

No offense taken. It’s sort of an in joke. :wink:

You may see some odd things in some of my posts, random capitalizations, strange word choices, even entire paragraphs repeated. We call those “voice artifacts“ because they’re caused by the dictation software. Usually I go back and fix them, but not if I’m too tired.


o offense taken. It’s sort of an in joke. :wink:

You may see some odd things in some of my posts, random capitalizations, strange word choices, even entire paragraphs repeated. We call those “voice artifacts“ because they’re caused by the dictation software. Usually I go back and fix them, but not if I’m too tired.