SmartThings Platform Transition Completed

Last September we shared our plans for evolving and enhancing our platform to improve experience while also keeping focus on an open and interoperable smart home.

At that time, we began making changes to our platform, impacting some devices, SmartApps, and Routines. Many of you were able to come along on this journey with no known changes or interventions,

We’re excited to share with you that we officially completed the migration!

As you can imagine, retiring a legacy program takes time, and we intentionally took the time needed to ensure that the impact of this project was minimal to you.

We appreciate your continued support through the transition and are excited about the capabilities that these changes will bring as well as the immediate benefits to you including the following.

  • Moving the processing location of SmartThings hub connected device commands and Routines from the cloud to your hub
  • Driver sharing and new development options with the SmartThings CLI
  • An optimized backend allowing us to bring you new tools and features like the Advanced User App and the Rules API

We extend our heartfelt gratitude to you all for being loyal SmartThings users.

Please contact us at if you have questions or need assistance.

Thank you,

The SmartThings Team


It’s still just some routines, though. Not all. Right?

Just as one example, if you have two hubs in one location, like, maybe a V3 hub and a station, and you include devices from each hub in a single routine, that routine will still run in the cloud.

They’re all hub connected devices, just not all connected to the same hub.


Hey @SmartThings, peculiar you’ve decided to omit a small mention of gratitude to @Mariano_Colmenarejo, considering your transition wouldn’t of been the same without the staggering number of devices he converted for you.


I shall be pleased to see the back of the legacy platform, but …

I am not really feeling a sense of completion just yet, and this is exactly the sort of thing that I feel needs resolving before I do.

With the legacy platform we were able to point unsupported devices at a choice of device handlers and there was a good chance that one of them was close enough to use, if not actually fully functional. We could get that far ourselves.

Now, unless we get lucky with generic fingerprints and default handling we at best have to ask a developer to add a fingerprint and then publish a new version of the driver (why?). The developer might even need to change the code because that also uses fingerprints directly (why?).

So we have lost the ability to say ‘treat it like one of those’ and fend for ourselves.


So does this mean all signs of Groovy have been removed from all hubs with firmware 49.X? :thinking:

I don’t think, from my own experience and reading on the old forum post, that on the legacy platform switching to another dth published stock would make many more uncertified devices work fine.

The legacy platform had the ability to fend for ourselves only if:

  • You know how to program something in groovy. (10% 15% of the cases ?)
  • You know how to use custom codes made and shared by other developers, altruistically or working for manufacturers or by other users. (40%…60% of the cases?)
  • You were lucky that your device worked directly with a DTH’s stock or published in smartthings. 20%… 30% of the cases??

Almost like now with the generic pairings!. Although the solution is different now, but I don’t think it’s much more difficult.

Using too many generic pairing criteria would easily make the device pair directly with the driver you don’t want and hardly with the profile it would need.
When you later change it to another driver, its clusters and attributes are no longer configured again, an incomprehensible decision for my part of smartthing, which did not apply to groovy and which I reported 2 years ago, although it is true that there are devices that only accept the configuration when they are in pairing mode.
Therefore, for drivers that are used for so many different types of devices, generic pairing may not work and create other device performance problems.
Each DTH only had one profile and was used for almost identical devices.

Now also all the stock driver codes are published, many of the custom driver codes are also published, some are not.
For most standard devices with adding fingerprints, copying and pasting 5 lines is enough.
In others you need to add the fingerprints also in a subdriver, which usually have manufacturer names or self-explanatory functions, such as battery, temperature, motion-timeout, …

The same happened with many DTH’s, you had to modify the published code to adapt it to your device, for example almost all multicomponent devices, each manufacturer follows a different way of assigning endpoints, some are followed ascending, others followed but descending, other pairs, other odd, …

I think, that being self-sufficient in this for many users was and is a utopia

As a general reflection for those who want to read it
I don’t think the perceived dissatisfaction problem is just of smartthings:

  • The manufacturers: who deliberately partially break the standards so that their device is not easily compatible and force you to use their platform.

  • The platforms: like smartthings, the invoice for certifying and/or developing device integrations so that they work on their platform, it is part of their business and they invest a lot of money in making it attractive to potential customers, another thing is that we like how and what what it does or not
    However, smartthings offers us for free all the tools and all the code of its drivers and libraries that make its platform work, free web space to host and share our custom drivers and access to its APIs, so that we use the information from our devices almost as we want. Others platform offer more and many others less or nothing.

  • The users: What about the users? … we want to buy the device that we want, knowing that it will not work with my in use platform or buy the cheapest or the most expensive or the one that we like the most, but we want it to work wherever and however I want and we are not aware that sometimes this requires many hours of work that someone else will have to do to satisfy our wishes and we are very demanding with those who are not to blame.

That is why all open source platforms have their forums and developers, some altruistic and others working for manufacturers to avoid certification and be able to adapt the devices to the platform.

Matter will fix it, hopefully!, but I doubt it

And very important, it is appreciated that smartthings makes people as attentive and valid as @nayelyz or @AlejandroPadilla available to all of us to address our doubts, problems and requests. Thank you very much to both of you and others who went through these tasks before.

Personally, I think that smartthings team normally pays little attention and in a rather distant and arrogant way to the suggestions, complaints, possible solutions that are made to them from the forum, some as I have told before I have done myself, and normally I have not received even the slightest no answer or explanation
I also understand that their work, concerns and ultimate goals are not ours.


It’s great that the migration has completed, and from my perspective I think the platform is in better shape now under this new architecture.

I do think this post is a bit tone deaf though… admitting it took longer than planned and comms were bad throughout would have been nice. Also recognising so many people have been reliant on the efforts of a small number of community members would have been good. This goes far beyond just loyalty.


For me yes the transition took forever but to me the loss of all the third party smart apps was a huge loss many of us depended on.
If ST would either develop those smart apps themselves or actually work with a developer program to get that back it would speak alot to Thier commitment to make this ecosystem usable by mere mortals.
Look at the iphone platform it was nothing without the apps.

Start with LUM and a smart app to simulate people are home when on vacation.

Any comments on smart apps?

If you have a Galaxy device the Labs section has a pre configured set of routines for away from home

I have tried that routine. It is not at all like the previous smart app.
For going on vacation we want the house to look lived in.
The previous app changed th times randomly with a range of hours and really made the house look lived in.
And there is no settings for how long after sunset for example .
Without random times and duration and ability to choose start x amount after sunset this app is not usable.
What is the plan from r smart apps?
Can we get a timeline and a description of what Smarthings plan is for bring back an eco system of smart apps?

They’ve already explained what the new platform offers. There is a publicly available “rest API“ which is a programming way of making requests to smartthings.

Individual developers can then write their own code in any language they want, host it themselves (either on a laptop they have at home or in one of the cloud hosting services like Amazon Web Services), and make the calls to the rest API from that.

These are called “endpoint smartapps” now because they connect to an endpoint in the rest API.

It works fine, it’s just more effort than the old system and it’s not possible to share the way we used to share custom smartapps because of the hosting issue.

There are a few community Developers who have created endpoints smartapps which they are sharing with other people. But so far only a handful. They are listed in the community-created wiki.

Beyond that, smartthings has expressed officially multiple times that they believe that the combination of the new routine features and the Rules API will provide most of the smartapp-like functionality that the majority of users need. With free hosting included.

From a community aspect, there are two other popular alternatives. First is to use the third-party app, SharpTools , which offers custom dashboards, a powerful rules engine, and an active community. They have a free tier for some simple stuff or as of the time of this writing it’s about $30 a year for the advanced version. It has a nice web UI and is a popular choice if you’re willing to pay the $3 a month or so to get the features.

Or, if you prefer a different approach, hubitat, a competing hub brand, is now including webcore in its official features. So there are community members here who have bought a hubitat hub just so they can use it to run webcore and then are using some community integrations to tie it back to their smartthings account.

So that’s four very different options that are available today for providing equivalent functionality to the old custom SmartApps. Different ones will work for different people.

  1. write your own code and host it yourself, communicating with smartthings through the REST API. (You may even be able to find another community member who has already created an endpoint smartapp with the functionality that you are looking for, but so far these are few and far between.)

  1. utilize the official features in routines and the Rules API. No extra costs required, but the learning curve for the rules API can be pretty steep. And you will need a laptop, not just a mobile device. There is a sub section in this forum for discussing the rules API:
  1. pay the license fee for Sharptools, and use their rules engine. You don’t need to be a programmer, you don’t need to pay for extra hosting, you can get a lot of help from their community and their official support. Nice web UI, so you don’t need a laptop, you can do everything from a mobile device. This is easy and powerful, But there is an annual license fee.
  1. set up hubitat, and run webcore over there. There is a significant upfront fee to buy the hubitat hub and it requires more technical skill than Sharptools, but for some people this feels like a shorter easier path then learning the rules API, especially if they’re already familiar with webcore.

So given that all of those options already exist and are working today, I don’t expect to hear anything more official from smartthings on replacements for groovy smartapps. They will probably continue to add some labs features, particularly for those with galaxy phones, that offer additional functionality in the future, but we’ll just have to wait and see on that.


I think the last time Groovy or a JVM ran on the hub in any form was probably 2017. When DTHs were marked to run locally they were handled by a software layer in the hub called “protocol handlers” rather than the actual DTH code. In any case, those are no longer in use in favor of using edge drivers for all protocols currently supported.


ah, interesting. So does this mean the memory limitations aren’t going to get any better by removing any legacy code?

I’ll chime in for myself and the team and offer a huge thanks to @Mariano_Colmenarejo, @ygerlovin, @TAustin and all the other community developers and members that have (and continue) to help each other out through this transition and beyond.

From the earliest proposals for what eventually become the edge drivers architecture (in its very earliest forms we called it “DTH 2.0”) support for securely sandboxed, efficient, local execution of community and first-party drivers to interact with devices and it is amazing to see how far we have come from those initial designs on paper to a platform running many drivers written by community members, SmartThings, and partners from that starting point. So, once again, thank you!


JD you are wonderful as always.
I am thinking that the ST platform and now expanded to be the matter platform, would be so much more accessible if there was a vibrant Application development community and a place to get those SmartApps.
Sure I can break out smart tools and DIY but , the usage of ST by more consumers will be accelerated with actual user grade apps for the top functions, right now its a toolkit and API.
If Apple had released iPhone and told users there are compilers build whatever you want , well you can see my POV.
If ST is to remain a paradise for DIY’s, home hackers, and enthusiasts then its fine as it is as you say.
WHy ST would not try to create a decent catalog of top apps , using the huge community of ST developers who could build them, is lost on me,
Unless the actual user base of ST is not large.

Today it may be true that Smartapps on ST had a small number of users, but with a real push , a catalog of 20 apps, and a CTA in the ST app to check them out, this could change.


“No worries while away” is available on all Android devices, not just Galaxy models.


I am optimistic that there might already be some toys around that we will be allowed to play with now the legacy platform is out of the way. For example, chase the rules implemented by ‘Smart lighting’ back through the API and you can find a ‘recipe creator’ underneath it that seems to have potential. I’d also like to think that the Developer Workspace will be replaced by something that you can login to without a constant battle with a labyrinth of confusing broken links and errors, and that will feel worth the journey.


I guess all ST users who want to manage their smart locks effectively can go to :
and we relegate ST as plumbing.

A post was split to a new topic: Managing Lock Codes Without Groovy?

This is like Comcast saying: “Please give a round of applause to your customer service representatives. You have internet that works most of the time and the 4 months of overcharges are resolved to OUR satisfaction. It only took 14 callbacks, 3 clueless technicians and 3 missed work days, but now you must be overjoyed knowing you have the BEST product we know you’ll tolerate. Now, we will await your messages of praise.”