Announcement | Changes to our Legacy SmartThings Platform

Hi @brbeaird

This is a big opportunity to integrate SmartThings into the broader cloud ecosystem, either using hosting platforms (such as AWS, Glitch, etc.) or integrating third-party APIs to enhance our SmartApp solutions.

Also, our SDKs’ examples provide a a high level introduction - the coding skills needed to engage the platform will be reduced to the basics of any programming language. For example, the SmartApp NodeJS SDK example could be deployed as an AWS Lambda function easily with the help of something like the Claudia JS framework.

@erickv, please don’t understand me wrong, but people more and more sick about cloud solutions. Not everybody has a 1 GBit fiber optic connection with 2ms latency. And even if you have it, then you are relying on multiple hosts, and if they have an outage, then you are the single user, who will never be compensated even if it is a paid service. If the ISP screws up things, then again everything stops, again.
(Don’t be an Adam Orth…)

This is not following the KISS principle.

2 Likes

How long notice we had for the text messaging service? - I think it can happen again and again…

1 Like

Yes, it’s very much worth keeping in mind during all of these changes that using the new SmartThings App does not equate to using a SmartThings hub. With the classic app, the vast majority of the app users were also hub users. But many of the uses for the new SmartThings app do not require the hub.

2 Likes

And that includes several of the most recent devices from SmartThings, including the Wi-Fi smart plug and the camera.

2 Likes

@ogiewon OH WOW – thanks for the background. Maybe their second attempt they wouldnt derail it :wink:

For me, this sounds like it is going to be a lift and shift versus a migration with backwards capability. My sheer laziness to convert or try another system is what has let me deal with some of the nuance I have with SmartThings. Since this feels like it will be re-doing this from the ground up, its time for many of us to consider if this is what we would choose if we had to do it all over again - and guess what, we may very have to.

yes - we may be jumping the gun here, but it seems like for some it was just the final straw and not the catalyst for the change in itself.

3 Likes

@smartthings

I’m speaking to you not only as a user and developer on your platform, but as the CTO of a number of influential tech companies over the past 2 decades:

While I understand the need to push the product forward into more mainstream acceptance, you are endangering alienating the development community that allowed your company to prosper and catch the attention of Samsung, leading to your $200M+ acquisition. No one is denying your need to perform this clean-sweep activity, but I do caution you on one area:

SmartThings has never had a coherent strategy for migration from hub to hub. Most people have settled on v1 or v2 or v3 hubs because they are not willing to migrate over from scratch. The migration from v1 to v2, I believe we can all agree, was an unmitigated disaster. When v3 and the ADT partnership came along, most of us with 100s of devices did not think it was worth the weeks of pain.

I’ve spoken to engineers and management at your company, both before and after the acquisition. Migration paths for users is not anywhere on anyone’s lips. I don’t know if it’s because your platform can’t easily migrate, or because you aren’t interested.

I can, however, tell you from experience at other companies that if you force your customers to move hubs without migration aides or give up application integration they have come to rely on without giving them a very good reason to do so, they will leave. Not some, but most. Why would they remain if moving to another smartthings hub is the same amount of effort as moving to a completely different platform?

Google lost market share when they shut down Works With Nest, Sonos is shedding users left and right because they are forcing people to choose between older hardware and newer software.

SmartThings is not a gaming platform or a new tablet. These are people’s homes you are screwing around with… Health, safety, protection, convenience and a way of life. If you are making this change without a safety net, you better have a very very good reason or you will sink the business.

35 Likes

@uberrob AMEN!!!

1 Like

Sounds like Samsung could give two sh#ts about shedding smartthings in a heartbeat if the need arose. By shedding I mean discontinuing. Just sell a couple thousand more TVs to make up the difference. Kind of feel bad for the Smartthings employees. knowing corporate could pull the trigger any minute. Maybe I’m exaggerating but it feels that way to me. If these changes they are talking about disrupt my set up drastically I will look for other options such as Hubitat.

Lol, wut? They’ve just spent 2+ years consolidating every single one of the their IoT platforms under this new SmartThings cloud. And you think now would be a good time to shed it? I guess never say never, but I’d say the chances are slim to none.

11 Likes

Slim to none they may be.

I’d rather pay a monthly subscription fee to smartthings for continued groovy ide support than having to host an aws instance for each and every dth and smartapp, but maybe that’s just me.

I don’t think they’ve thought this through. It doesn’t offer any benefit to the end user to kill the groovy IDE since setting up a c2c integration is more difficult than just copy and pasting code, so if the issue really is just the company’s bottom line then charge an extra fee for groovy ide access instead of killing it and pissing everyone off. Unless they just want us to all leave for hubitat.

2 Likes

As I understand it, based on some ST staff comments and listening at SDC, Groovy doesn’t scale well at the size SmartThings is now. So it leads to latency and instability at this scale. Maybe some ST staff can clarify this, though.

2 Likes

I don’t see how running 20+ separate AWS instances would improve the stability of my setup.

1 Like

The stability of everyone’s setup sucks when the cloud is down.

3 Likes

And that is exactly why I need as much as possible running totally locally. Currently, ST has enough local control for my needs. I am still struggling to understand whether the changes proposed will lead to more local IFs and THENs and ONs and OFFs or fewer. Is there anyone here qualified to answer this simple “more or fewer?” question? Or are we all in the dark.

Edited to add: I am talking about using automations and controls set up via my app. ie consumer level.

2 Likes

AWS lambda is still ‘the cloud’ even if it’s technically serverless (only runs on execution)

You could run code locally using node.js

I’m going to try and port my still in development roomba dth to use the developer workspace and aws lambda and see how much needs to be changed to make it work.

2 Likes

I meant from simply using my android app and the controls and automations I can set up with it, not all that lower level coding stuff.

They say they want more to run locally. What that means is anyone’s guess

2 Likes