Announcement - Changes to Legacy SmartThings Platform

#42

It would be good to share examples of this so it can be looked into.

#43

What other ST SApps have you used on both platforms and what has your assessment been?

#44

The only two ST that I use that were ported over are webcore and NST manager. Other apps I use are built in apps from hubitat or a few custom apps from developers over there. Do you want an assessment of those apps or hubitat itself?

#45

Just an overall assessment of the gap analysis of the two programs. I didnā€™t see a post on community.smartthings.co on which devs/SApps will be moved over to the new app. There are several I use that are vital to my setup so I have to see if those are on HE or will be written with the new API.

#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?