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.
I listened to the podcast and here are my takeaways:
Smartthings/Samsung has big plans for the future of this platform - however for whatever reason they seem to not be sharing very much information besides the Phased approach above.
By getting rid of groovy and forcing you to use their own in house API – this will make it harder for newcomers to just jump right in and develop a functioning app and let them attract new application developers (eg big $$) to develop a brand that is “Developed by SmartThings”…
They don’t seem to initially want to tick off the development/user community, (since there are 62 million active monthly users) however I am not getting a lot of warm and fuzzies from their transparency.
I believe the reason they are doing this is because they are not making any reoccurring revenue from their current model besides the sales of the initial hub. Because unlike Google (a search company) or Amazon (a shopping platform) or Apple (a hardware company) they have no way to monetize the costs of their infrastructure – in its current form I do not think Smartthings can be a revenue generating product line can it? I mean back end servers cost $…
sure they do: sell more TVs and appliances. SmartTHings is basically an R&D division of Samsung that works to sell more of their phones, TVs, Fridges, Washing machines, etc.
Yes but does this make it harder for geeks who are just hackers and not actual coders to develop in the platform? I know a little python and a little java – however I could pretty easily have developed an app (even though I didn’t) because groovy was easy to understand…?
Yea but when you buy a fridge – do you say… i want it to work with smartthings? – I’m not sure…maybe us geeks do – but I am more likely to be like does it actually work right? Or is it a quality product… I see your point though
I will have to say… If I buy a fridge or dishwasher or dryer I am more likely to ask if it works with my echo show… I think everyone is creating silos here?
I mean a raspberry pi is capable of running different coding languages so that’s not really an issue. The “SmartApp manager” really would just be a front end for pulling down developer’s code and installing and running. Honestly, if smartapps were just docker containers it would probably be pretty simple and straightforward. Then people have the choice of local hosting, self cloud hosting, or developer hosted (if offered).
Developers aren’t going to want to developer if its hard to get users to install and run their projects. Having a simple, straightforward solution would show support for the developers, push additional development of features from the community, and probably draw more customers in. Today you can setup github integration in the IDE and its very easy to walk someone who doesn’t know how to code through the process of doing that to pull in device handlers or smart apps.
Right now with this new model it seems developers will have to pay for hosting their smart apps, which will mean they will have to start charging for it which will in turn cause less people to want to use them. This will then cause the developers to work on projects less / at all on the platform.
Maybe this is only for a small percentage of the user base, but I know the reason I recommend SmartThings to others when they ask for starting out is because of the flexibility and actual capability added by the community. Even to those who are just getting started and may not be the most tech savvy.
I’m perfectly fine with ST no longer hosting things. It makes sense, and it’s a cost to them but they really should provide the tools to allow the community to easily transition, continue to use, and help spread its growth to others.
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.
When I read the topic of this thread, I see " Changes to the Legacy SmartThings Platform" 
