And there are a few really big ones out there, all written in Groovy and completely running on the Legacy ST Cloud. The two big ones that come to mind right away are webCoRE and Echo Speaks. I wonder how these SmartApps are going to do during the transition process?
At least things like ActionTiles and SharpTools are already hosted on a separate cloud infrastructure. Hopefully these apps can be modified to use the new API versus the Classic Groovy OAuth Endpoint API (if they havenāt already been migrated.) Something like webCoRE could be hosted in a similar manner, however cloud computing is not free, and for it to work for the masses, it has to be very simple to set up. I could see someone hosting webCoRE and charging some sort of fee to help offset the costs of the cloud infrastructure.
However, perhaps something like Node-Red, hosted locally on a RPi or similar, will eventually replace webCoRE for the power users. If ST makes good on the ability to access the new API directly on the ST Hub, this might be a pretty powerful combination. Node-Red also opens up a ton of other integration options.
Samsung is very different from those other examples. It is a huge multinational conglomerate, and SmartThings is in its consumer electronics category. It sells literally millions more televisions every year than it does hubs. And most of the people who use its hubs donāt use any custom code at all.
This change is the equivalent of Honda discontinuing butterfly doors on its crossover vehicles. A major impact on a very small sliver of the customer base.
If you need the abandoned features verbatim, move on to Hubitat (again, sharptools offers a nice UI if you miss that).
If you want a friendlier dev environment, home assistant and MQTT are both good candidates.
Myself, I am going to wait and see what happens, and evaluate the new system as a new candidate when it does finally arrive. (Although if it doesnāt have a voice-navigable app, it wonāt be high on my list.)
Hubitatās Dashboards all run locally on the Hub. They are just web pages, similar to ActionTiles, but all local. The Hubitat mobile app looks at what network your phone is connected to, and if local it connects directly over the LAN. If remote, it connects via the cloud.
As @JDRoberts mentioned, HomeKit is a pretty nice solution and provides a nice UI as well as local automations (if you have an Apple TV or always on iPad.) With HomeKit on my phone, I can control all of my Lutron switches/dimmers/fan controllers, my two Ecobee3 thermostats, and my Hubitat hub devices - all locally. I have HomeKit integration for all of my Hubitat devices via HomeBridge running locally on a Raspberry Pi.
Problem is HomeKit doesnāt have nearly the power as options like webCoRE when it comes to creating automations. I know Shortcuts has made progress but still nothing like what some of us are accustomed to using. Also not a fan of the remote options - $300+ iPad or $150-200 Apple TV when itās not even one of the better streaming options. Just my two cents of course.
True As far as the official app. If you combine it with homebridge, you can Get as complex as you want on the logic side but you have to do your own programming. Basically you use Homebridge to create the equivalent of virtual switches and then use it like you would IFTTT: have the virtual device coming on trigger a simple automation in HomeKit.
For myself, I never used Webcore and I donāt need super complex automations, so Iām fine with Home+ 4 as a HomeKit rules engine. (Itās a third party app from Matthias Hochgatterer, with lots of power user features including conditional rules and the ability to duplicate and merge scenes)
My personal priorities put reliability at the top of the list, and Iām willing to give up some complexity to get that. But different things work for different people.
Iāve got some DTHs and apps from 3rd parts, and to be honest, itās those that make the ST platform worthwhile. Before installing webCoRE, ST was pretty dire. I have Xiaomi curtains and a few custom blind openers that I donāt want to lose.
ST could use improvement, but if it goes the wrong way, my hub is going in the bin.
Custom devices are a staple of the SmartThings platform. We have recently released tools that make it easier for developers to integrate their custom device type handlers into the ecosystem and gain full functionality with the SmartThings App. Going forward we are working on new and exciting ways to integrate your local and lan connected devices into the ecosystem with a focus on running locally and more reliably.
@JDRoberts, you might think that this corporate 50 list and Smasungās SmartThings division are very different, but I see it differently. Thatās the beauty of our divergent āopinionsā and I appreciate your opinionā¦ itās what makes these threads worthwhile. Time will tell, and I hope that SmartThings can deliver a hardware and software platform that is stable, profitable, flexible, efficient and responsive for local processing.
That long list of 50 corporations and/or their divisions are those failed to innovate {successfully}. IMHO, in that same group, there are some companies who attempted what they thought was innovation but was just different. They failed, in the end, fatally to sell/migrate new and their user base to something they thought would be so much better (wait & see). Itās not that they did not have good reasons to make the innovative change, it was that their dedicated user base had repeatedly asked for features that were ignored for new shiny features that so many people stated that they did not prefer or would not re-purchase/useā¦ I worked for a very large corporation and I understand that Samsung is calling the shots for their business unit āSmartThingsā to deliver which serves Samsung and profitability. It is the way that mergers work, seen it, lived itā¦
Again, thanks for the options on moving forward when it becomes a forced choiceā¦ I too, am going to āwait and seeā what happens, and evaluate the new system as a new candidate when it does finally arrive.
Hmmmmā¦ When I read the topic of this thread, I see " Changes to the Legacy SmartThings Platform"
Ahh, okā¦ The new platform is mostly already here. I predict that there will be no major release that magically corrects all of the deficiencies power users have with the New SmartThings App. It will get better incrementally over time, but I doubt weāre going to get a brand new Mobile App/Platform any time soon.
IMHO, this thread is really about the demise of the Classic App, and later the Classic Groovy IDE.
Not based on the announcement in the first post of this thread, which says:
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.
No telling what exactly all of that is going to deliver until itās here, but itās definitely not here yet.
Once itās here, then I will be glad to consider it as a candidate for my home automation system. But for right now thatās all still pre-release and Iām not going try to guess what it means in terms of daily function or MFOP.
If there is some kind of system users can run on cloud, or their PC thatās on 24/7 or on a raspberry pi that allows for easy installation of smartapp (or whatever they are called in this new world) for users would go a long way. Some kind of system similar to docker (not necessarily an OS). The code needed can be hosted on github and the āsmartapp managerā could pull code and updates that way. Users can then add different developer repositories to pull from.
unRAID has this and I think it works well, and would be easy to walk someone through.
Iām personally going to wait to see how things turn out (doesnāt seem promising though honestly) , and maybe spin up a Home Assistant container to see how that looks.
In the new architecture, smartapps can be written in any language that the developer desires, they basically are just connecting to smartthings through an API. So there might be some that are written in python, some in groovy, some in Java, some in whatever language the developers want to use.
That means itās no longer really practical to imagine a single server box running everything.
Hence the idea that developers will host their own smartapps and allow access/distribution as they choose to.