Announcement - Changes to Legacy SmartThings Platform

#46

There is a thread on the ST forum in regards to th tools that developers will use to convert their Smartapps and device handlers for the new app. Right now it looks like rough going but I would imagine in time everything will be worked out and developers will be successful in the migration of their code :slight_smile:

#47

Everybody else refers to that thread as a train wreck.

#48

That thread is just about getting the new app to display richer capabilities that were intrinsic in the Classic app. There’s been very little (if any) success reported in there to date.

And that’s not about rewriting all those DTHs and SmartApps to use the new API for accessing the SmartThings cloud, nor about developers of SmartApps figuring out how to host their code or in what form it’s going to take. That’s still a massive undertaking.

I suspect any SmartApp or DTH without an active developer will simply disappear when Groovy is turned off next year.

#49

Yuk! I predicted this in the past:

#50

Now that it’s 2021, and the new SmartThings backend/APIs have somewhat matured and gained a few more features, do we know any better the future of webcore on SmartThings? This is a frequent concern for SmartThings users with the current turmoil going on. And now standard features like button capabilities don’t work well with webcore due to ST capabilities changing. So should we be telling new users to not use webcore since it may die in less than a year?.

#51

Just posted.

#52

This was addressed to some extent in the announcement that @GRClark linked, but a more detailed discussion is OT in this thread.

First, while the new API platform is quite nice to work with and allows a lot more flexibility for apps that want to integrate with it, it requires a completely different development approach. In order to accomplish what webCoRE is today with the current SmartThings API we would have to carefully architect a cloud-based platform to manage your accounts and piston logic, receive and respond to all events from all devices, and secure your data. It would not only be absurdly expensive to build and operate but would also place an extreme liability on a small number of open source programmers.

The SmartThings Rules API was the answer to this. Essentially SmartThings handles all security, device interaction, and logic processing similar to the Groovy platform but in a more restricted scope. The intent is to simplify implementation of your complex rules and improve scalability of the platform as a whole. SmartThings even announced a stretch goal of being able to run simple rules offline directly on the hub.

Completion of the Rules API could provide awesome power and interoperability between apps using the SmartThings API with webCoRE-like rules easier to configure than ever before. A new webCoRE dashboard would serve as an interface to view and update your rules - much like the current dashboard it would be a static site, affordable to host and easy to maintain. The Rules API may still become something that can operate much of what we depend on in webCoRE, but it does not seem to be a priority yet for ST.

Meanwhile we are at the whim of the hobbled Groovy platform. It will probably stay online as long as it takes to not lose all webCoRE users from the ST ecosystem but we’ve already seen that remaining online does not necessarily mean remaining full-featured. I wish we had better news.

#53

I agree that it seems to be progressing very slowly and currently shows no sign of the twiddly bits that give webCoRE such power (the TCP sort of thing), but it should be pointed out that Automations and Scenes now use the Rules API and that local execution of that is already in test internally to ST. So it isn’t just a sideshow, it is key functionality.

#54

Thanks for the update @ipaterson. The reality for all of us is Groovy is going away this year (assuming ST sticks to timelines for once), so webCoRE is at a bit of a fork in the road. While ST staff may be nice and allow webCoRE to operate on Groovy past public deprecation, something needs to be done sooner than later so we all don’t end up like Echo Speaks users with no path forward. It’s hard to recommend new ST users even install and use webCoRE since there is no future path.

As I understand it, based on your update, there’s two options for a post-Groovy webCoRE:

  1. re-build webCoRE as an endpoint app using the SmartThings API. WebCoRE handles the automation logic and only gets device states and posts device commands via the API. It would cost money to host/run, which inevitably means you have to charge users a recurring fee. But it would closer match the current feature set of Groovy webCoRE.
  2. re-build webCoRE as a UI for the Rules API. Would probably remain a free/donation based app, will run local (given device constraints), but will lose a lot of features of Groovy webCoRE.

No matter what the future path is, all of us should probably prepare ourselves that future webCoRE will most likely not have the same feature set. Whether that’s by choice #1 or 2 above, limitations of the ST API (à la SHM control) or a combination of the two, that’s the reality being painted by Samsung. But I would rather have a minimum (maybe bare bones minimum) viable webCoRE than no webCoRE at all.

#55

Wouldn’t option 3 be move to hubitat?

#56

This thread is about SmartThings changes. To your point, I suppose option 3 is webCoRE does nothing and if a user wants to keep using it then they go to Hubitat.

#57

Understood. Just pointing out that there is another option to continue using wc

#58
#59

That’s huge news…including and especially this (emphasis added):

This is also in the works and will be made available before anything happens to WebCore. There will likely be some manual work involved for users (i.e. post the converted JSON to Rule API using the rule builder) but it is planned to be minimal and straightforward.

#60

It is a welcome, if perhaps belated, clarification of what is going on. It was originally suggested that the intended result was to have webCoRE running on the Rules API, with there being some uncertainty (particularly from me) over whether ST would be developing their proof of concept or whether the community would be expected to finish the job.

It now seems ST are looking towards having their own GUI for the Rules API, together with a rules generator for converting existing webCoRE pistons. They can then turn webCoRE off. I’m happy with that, but I am sure it won’t suit everyone.

#61

Reviving an old thread….

Anyone notice Adrian has left SmartThings?

#62

Interesting.

#63

Well that certainly doesn’t offer much hope there’ll ever be a new webCoRE now does it? Hate being in this position where it’s either I give up the main driver of 99% of all my automations on SmartThings or I endure the pain of moving all my devices and automations over to Hubitat.

#64

May I ask how you heard this?

If true, for some strange reason, I find this positively liberating… I’m going to bet that Adrian can do much more while unaffiliated, than he could with going thru management or red tape at SmartThings…

Let’s just hope his interest still lies with SmartHome logic…

#65

https://community.smartthings.com/t/rational-for-the-rules-api-language-syntax/236221/5