SmartThings has announced they intend to completely shut down their classic Groovy developer platform. No word on timing. Let’s hope Hubitat gets their supply chain issues sorted soon to handle the eventual influx of new users.
13 Likes
Seems to me like the big changes are at least a few months out..probably closer to a year. Hubitat should be well stocked by then.
8 Likes
Knowing SmartThings, the changes will probably take longer than "the course of the next several months" to implement--but on the other hand, unlike some other platforms with major changes, we can't say they haven't been warning users for a long time! This does seem like they're finally accelerating the push to end the "classic" era, including the old app itself plus the free hosting of arbitrary user Groovy DTHs and SmartApps. Luckily, if anyone is particularly addicted to that model, Hubitat is pretty close to it while also working locally (something ST is really dragging their feet on, it seems), so better all-around IMHO--that's why I'm here. 
I do wonder if Hubitat will ever decide to adopt anything to make it easier to convert "new" SmartApps and DTHs to work with Hubitat. I'm not very familiar with the details of these models and suspect the answer is "no" because staff are unlikely to be either (unlike when Hubitat was created, they are not mostly all active developers on that platform...but we also know they aren't totally opposed to rethinking Hubitat's app or driver model, even if it's not a priority, so maybe this could factor into that if it ends up looking better). I wonder if/how that might be important in coercing new users into the platform from SmartThings. I know the "classic"-esque model is a draw for many people right now, though I also believe Hubitat has inherit strengths beyond "like ST but local!", including an excellent Z-Wave and Zigbee device support (and a library of built-in drivers to match), native apps, a wonderful community (thanks, y'all!), and staff who are both active in the community and fairly responsive to users.
Either way, I definitely also hope they get more hubs in stock soon so the people who want to can. 
3 Likes
For those of us that skipped the SmartThings platform, do you know the difference between current and Legacy?
I think the "classic" groovy developer is very close to that of Hubitat. But I don't know what the new one is.
My interest is; I use the smartthings documentation for help with many things Hubitat and would hope the documentation stays accessible. Unfortunately I believe its days are numbered.
1 Like
I have seen github copies of this .. I'll have to find it again
3 Likes
Please share links if you do find it. Thanks!
1 Like
I'm not as familiar with the "new" models, but it seems like the general idea is they work via web endpoints that you have to host yourself (e.g., AWS or your own server). Right now, they host all user code, sort of like how your hub hosts all your own, except they're doing that for everybody and it's all in the cloud (perhaps their well known server problems are akin to some people's hub slowdowns 
). You are correct that their "classic" models are very close matches for Hubitat's app and driver models, including a very similar Groovy runtime environment and the same distinction between apps/SmartApps and drivers/Device Type Handlers.
Their Classic docs implementation appears to be based on ReadTheDocs. Check the lower left corner, and you can download any revision in PDF, HTML, or other formats. Tagging @ogiewon since he asked about it too.
I should do this myself before they disappear. Hubitat's docs are getting better, but these are good resource for when you aren't sure.
4 Likes
Might want to create forks before they die off
3 Likes
I know ST had a bad reputation for non-up-to-date developer docs, but it looks like those haven't been modified in 6 years, and I think they've made changes since then (at least to the DTH side of things). Is that really the most current? 
1 Like
In my humble opinion, I believe that a large driver for this push is coming from the increasing costs of cloud control and storage. The storage costs and labour costs associated with their clouds must be enormous and are surely not paid for by the hardware cost of a hub.
The push for local on their part is not just because of reliability and dependability but also because of reduced costs!
The issue is the interaction of community based smartapps and drivers with the live product.
In the fast paced marketplace of Home Automation, new products and new services are raging forward at a torrents pace! If ST slows down the pace of adoption of new devices by this approach, the developers and technically savvy users will desert in droves (if they haven't left already).
This strategic move for them is risky - and they might not realize how risky it really is!
3 Likes
Thanks. I have downloaded a PDF version of the docs.
6 Likes
Truly sad. I have two groovy-based LOCAL web integrations still there and the deprecated TP-Link Integration. They will simply die. But, that is why I moved here over two years ago.
I think that the SmartThings actions are counter to their original covenants and also counter to the plans they had even two years ago. But, since I have Hubitat, I care less for myself - but the many people who used my integrations - I am sad.
Dave
5 Likes
2 Likes
So what's the difference between legacy groovy and (maybe) new groovy will it mean a re-write of all legacy apps and automations that people have created ?
SmartThings has allowed users to run their own custom groovy SmartApps and Device Handlers on the ST Cloud since the beginning. This is the legacy groovy IDE that is eventually going to be shut down.
The 'new ST platform' is more of a standard API to allow Applications you host on your own hardware/cloud platform to interact with your SmartThings account. How much direct integration via the ST Hub versus only the ST Cloud is yet to be determined. However, Samsung has been pretty clear that the cloud is their strategic direction for most integrations. The announcement mentions more 'local processing' - however, they have been promising that for 4-5 years now. To this day, only the ST Smart Lighting SmartApp, and some pieces of the original Smart Home Monitor SmartApp are eligible to run locally on a ST Hub. And even then, only if all of the devices used in those automations are running stock ST device handler code that is capable of running locally.
Local processing, data privacy, ability to choose if/when firmware is updated on my hub, ability to run my own code locally on my hub, and backup/restore are what instantly attracted me to Hubitat back in January 2018 when the first Hubitat hub was released to the public. That original C-3 hub is still faithfully 'elevating' my home automation! 
10 Likes
As well, I believe that the original founders of Hubitat, can look at this ST announcement, and say a big "I told you so!".
This whole business of the ST announcement of hosting your own Device handlers, and groovy code is nothing more than a complete justification and vindication of the correctness of the Hubitat approach!
2 Likes
Time to move. Any updates on when Hubs will be available? Waiting to get started.
Ok makes sense and thanks for the dumbed down version. So looks like I made the right decision and we may get a heap more developers and users jumping ship.... if they can sort out their stock problem.
I look forward to the new users. I do find it really strange it does not seem any update has been provided by hubitat staff regarding availability.
