Announcement | Changes to our Legacy SmartThings Platform

Announcements
1

Changes to the Legacy SmartThings Platform

The explosive growth of our community and platform over the past few years has been an amazing experience for all of us at SmartThings. We have you to thank for building, innovating and growing with us as we push the envelope to what is possible in the connected home. Today, we wanted to let you know about the next evolution in our journey.

We are making some important shifts in our strategy to best position our platform for the future and investing more deeply in improving the stability and security of our platform. With these changes, we will empower a broad ecosystem of developers to integrate and innovate with SmartThings using technologies of their choice.

Over the course of the next several months, we plan to focus on the development of a flexible, API-based ecosystem with improved device integration methods. We will transition to new services and integrations that offer lower latency, higher reliability, and local execution. These new tools will simplify the user experience into a single mobile app with an intuitive and powerful design.

As part of this transition, we will also retire select legacy features, apps and products, rolling out in three phases over the next several months. Don’t worry, you will have plenty of time to make adjustments, if needed.

Phase 1

  • Complete the migration from the SmartThings Classic app to the new SmartThings app that was announced earlier this year.
  • Transition to a local (Hub-first) device health solution, with a focus on reliability.
  • Begin the wind-down of select legacy systems, SmartApps, and cloud-based device status monitoring.

Phase 2

  • Optimize SmartThings Core API SDK for JavaScript and the CLI for device manufacturers to implement custom capabilities.
  • Rollout additional features to help us grow toward an API-first platform.
  • Retire select legacy hubs – Don’t worry, affected users will have plenty of time to move to a newer version of Hub.

Phase 3

  • Complete the shutdown of our legacy developer tools including the Groovy IDE, in favor of a simplified, more robust developer toolset.

As we look to our future beyond the current Groovy-based SmartApp and DTH infrastructure, we also know that it’s vital to maintain critical functionality for our community in order to make this a smooth transition. This is a top priority for us.

SmartThings has always been about innovating to build the best experiences possible through home automation and beyond. Many of you have grown with us since the Kickstarter days as we changed the world through your creativity and innovation. Together, again, we’ll build what’s next.

Thank you for being our reason for coming to work each day.

The SmartThings team

22 Likes
2

Will my existing hardware (specifically the fibaros (ubs, double-switch, dimmer2, and smart implant) continue to function ? Some of these rely on community-written DTH’s.

If so, great, if not, time to plan for replacing the hub.

Also, what about webcore ?

Cheers!

=)

8 Likes
3

Is this good or bad news? :stuck_out_tongue_closed_eyes:

5 Likes
4

For Phase 2… please have a migration tool ready so we don’t have to set up any required new hubs from scratch!!

35 Likes
5

With regard to changes to device health, please could we actually be given some information about it this time around?

8 Likes
6

What about local automations then? I see you’re planning to phase out SmartApps, so are you working on taking native automations local?

5 Likes
7

Second this, it would be great to have a backup/switchover tool - it’s currently a huge barrier when considering a hardware upgrade.

Also, what about WebCore? -Surely this key app is being transitioned over?

13 Likes
8

It’s big news, with some good and some bad parts. The biggest loss for me is the shutdown of the IDE. Groovy is not perfect, but it has made sharing community apps pretty easy for most anyone who know hows to follow instructions and copy/paste code from GitHub. The new developer tools are quite good but are definitely geared more towards people who have experience coding and setting up web endpoints because a big part of the new API tools means you have to host the code either in a cloud service or out of your own home setup. I imagine that will discourage many people from using custom SmartApps, which does make me sad. I am still holding out for a future hub that can host custom code locally that includes a way to share it with other users.

On the other hand, this frees up the ST team from having to spend time and resources hosting everyone’s custom code logic (including all that really bad performing code that many of us have written), so hopefully that will give us innovation and better performance in other areas.

Overall, I am personally optimistic but also sad to see some of this stuff going away.

20 Likes
9

This all sounds well and good, but I’m just gonna put my money on this taking 2-3 years to get implemented (and even then, probably not everything on the list will be done or will have changed in some way).

While there has been some progress come from the thread about the app migration, there’s still a lot to go just in that one area. So all of these other large infrastructure changes will likely take a long time.

6 Likes
10

Any info on WebCore @brbeaird?

Also, maybe some estimations on timelines for implementing these changes?

Thanks in advance.

3 Likes
11

@blake.arnold, is it the new spin-off topic after the long-long Get ready to make the switch?

I still see missing pieces and bits, and cannot see how this would be at the end a more local execution environment. It is more and more depends on cloud based solutions and it is all depends on the users’ setup now.

  1. Some integration from local LAN access has been moved to C2C, like the LIFX integration. Now if a bulb cannot connect to the LIFX cloud then it fails to work in the SmartThings environment and physically has to be power cycled. But meanwhile the bulb is working in the LAN environment from the phone and LIFX app.
    Really great to be dependent on two clouds.

  2. SmartApps, the new methods are great and gives access to different languages to subscribe to events and trigger things, but again, all connected through cloud solutions. SmartThings has passed things to glitch or ngrok and the users with computers running 24/7 at home to host their own SmartApps. No problem, but it makes really a privacy nightmare which service has access to what and how. And all is cloud connected to each other.

  3. Some services provided in the IDE by the Groovy platform, for me, is unknown in the new API. But please excuse me, if I am wrong.
    How anyone is able to access any weather data through the new API?
    How anyone is able to access TTS through the new API?
    Just two examples, Severe Weather Alert and Notify Me When SmartApps (BigTalker2 as well).
    Someone will jump in and going to tell there are audio notification options in the new SmartThings app, and yes, I am aware of it, but the textToSpeech() is able to use Amazon’s Polly’s all languages, meanwhile the new app supports only English and Korean. And here to mention that might be using Samsung’s Bixby, what is not limited to two languages. Actually it has more TTS languages than Amazon’s Polly or Google’s TTS services.

  4. Still no way to implement custom cameras for feed or for images.

Wouldn’t be easier to introduce a monthly service fee to manage the things better/together, than letting the whole setup fragmented?

Or just provide a way to access a LAN based server without the cloud background and all developer will buy RaspberryPis in bulk. What the latest model is not enough for that is over complicated for home automation.

8 Likes
12

I don’t know why companies like SmartThings don’t release a home server hub, for more money than the basic hub, to save those who don’t want to spend a year soldering a raspberry the task. After all with for instance Reolink you can choose to run your cameras on their cloud or get one of their NVRs which is like a server.

4 Likes
13

This is gonna be interesting.

2 Likes
14

Echoing this question: I have a number of devices that rely on community-written DTH’s. Will these continue to work? Or are they going to die on cutover day unless the community steps up and re-writes them for the new system?

9 Likes
15

I assume that doesn’t include the ADT SmartThings hub (even though it doesn’t get any updates) since there is no replacement available for it?

5 Likes
16

Do you think Smartthings will actually be answering and as these questions? OR do you think they’re just throwing this out there and then ignore it and pretend we have not asked for more info. And get back to us at a year with more info.

12 Likes
17

This is the question I keep asking myself. Why not?

We know this is not rocket science.
Philips hue has been doing this forever: local API plus remote access through their cloud.
If you are in the same network, even your mobile app will access the hub directly.

Ok, but with SmartThings we have cloud connected devices such as ecobee, what would happen if automation is running locally and it needs to interact with a cloud based device? “Simple”:

Communication to all cloud based devices runs through SmartThings cloud.
When creating an automation that will change the temperature on my ecobee (or any cloud based device handler) I should be presented with an option:

If offline:

  • Queue latest command.
  • Ignore action.

It would optionally queue a user notification informing it couldn’t perform the required action due to connectivity issues and it has been queued or ignored.

Being offline could mean:

  • Hub cannot connect to SmartThings cloud.
  • SmartThings cloud cannot connect to ecobee cloud.

As mentioned, I don’t see the “complication”.
They already have everything they need and they would be saving money with this implementation so… why not?

Samsung could change the DIY home automation market and basically “own it globally” if they want to.

If only SmartThings could be used as described above: completely local access and execution for those without cloud based devices or local execution with support to cloud devices…

If only the hub had a local rest api (such as Philips hue does)…

If only “every single Samsung appliance and Smart TV” had a local rest API…

And if only Samsung would open source the appliances and TV “local endpoints” to standardize it and encourage those less known manufactures to implement it on their devices and be compatible with SmartThings right out of the box without the manufacturer creating or maintaining their clouds (because it connect and runs locally)…

Samsung would be selling a ton of additional tvs and appliances (think of all the enthusiasts plus Creston, Savant and Control4 dealers - just to mention a few who would buy or recommend them). It would become the brand of choice for appliances and TVs on any smart home.

Just think of all the possibilities… even new business emerging to compete with the big names on professional home automation because now we have a “home automation hub” that rises to to the challenge and is accessible to everyone.

And then you will be leaving on a perfect and magic world :sunglasses:

But… what do I know, I’m just a guy coding from my bedroom :thinking:

4 Likes
18

To be perfectly honest, they currently have 65 million users. I doubt having a LAN based hub that acts as a server really would draw enough users to make the juice worth the squeeze. Especially when you consider SmartThings branded hardware is doing to become a thing of the past. https://www.businessinsider.com/exclusive-why-samsungs-smartthings-is-going-all-in-on-software-2020-6

7 Likes
19

I believe you summarized it all when you said: make the juice worth the squeeze.
When it comes to big corporations there are always a lot of politics involved.

We usually see a brand name as whole while in reality these big companies sometimes are a bunch of divisions that operates independently of each other and don’t communicate well with with each other.

Something this broad could mean some divisions loosing so others could win.
Could it exponentially grow the already large number of SmartThings users out there?

Well, if it continues to add value to existing users while at the same time bringing professional users and become a replacement to pretty much all other hub out there that are trying to fill SmartThings gaps… not to mention all Openbab and Home Assistant users… definitely. It would grow by a lot.

But… if you have 65 million users and the money is flowing… your retirement is already guaranteed… you probably want to stay quite instead of starting a revolution. Unless you own the thing like what we experienced with ours old friends from MS and Apple who kind of changed the world.

The visionary guy has to be the “one” in charge and I’ve seeing this happening at tech companies only so far.

Anyway… enough corporate stuff.
Can’t wait to see this new changes. I hope several months means: before the end of 2020.
Waiting for the good stuff is always a torture :slightly_smiling_face:

2 Likes
20

My biggest concerns are not all custom handlers Work in new app, speed of new app is drastically slower than classic, what about services like Logitech Harmony - shows up in classic app but for some reason you can’t add a new hub in the new app, compared to classic app the new app barely shows as many attributes and features - Echo Speaks devices are a great example of this. Automations aren’t as full featured - last I knew you couldn’t use the same device as a trigger and in the action in the same automation nor could you use the same device twice as a trigger and condition.

I know we’ve known for a while this was coming but one thing I really want to know is an exact date for classic app retirement.

3 Likes