I have been using SmartThings since early 2017 and I have really enjoyed the experience. I am a professional developer and IoT hobbyist. I have written a couple Device Handlers to integrate a few random devices into my home automation setup. Nothing super crazy. But it’s been a while (mainly due to everything just working) and I’m just now jumping back into the eco system.
My dog ate my home audio receiver remote and a new one is $$$, so I thought, “Why don’t I add my AVR into my SmartThings app?!” That’s when I logged in and saw that things are changing. I’ve been reading as many announcements as I can, I logged into the new developer portal and created a new Work Space, and I’m still a little confused on a few areas. I have a few questions that I hope are simple enough to answer:
Is the Groovy IDE going away, and if so…
Is it worth developing new Device Type Handlers and Apps in the Groovy IDE>
Is ST transitioning from Groovy to JavaScript? (I really hope so!! That would be fantastic!)
Is local execution coming to ST apps? I read something about “Local Execution” and I haven’t found if that applies to only Z-Wave/Zigbee functions, or if it will extend to custom apps
The new Work Spaces concept looks more SaaS based than IDE based, am I still going to be able to write code in the new Work Spaces? If so, where does one put it? Is there GitHub integration?
What are DTH and custom SmartApps called in the new Work Spaces? Is there a way to handle custom IoT devices from the new Work Spaces portal?
If I have any more questions as I go about, I’ll come back and add them here.
Others will be able to answer more technically, but the short answer is that the smartthings cloud will no longer be open to custom code sometime within 2021.
You’ll still be able to write custom code, even in groovy, but you will have to host it yourself and then communicate with the SmartThings account via webhooks.
In addition, while they keep talking about local processing, and they have provided more DTHs that run locally, you still can’t run any automations locally except for some of the ones created through the official smartlighting feature.
It looks like eventually they may make the new “rules API“ so some of it can run locally, but we will have to wait and see on that.
Thanks for the reply. That is the sense I’m getting. That is unfortunate. If I’m going to create custom services that I am hosting, I may as well run a local hub as well. I figure, this is better for the long term sustainability of SmartThings. I’d rather have this change than a total shutdown. Blah, I really don’t want to have to migrate.
Yes, because it is part of the legacy system that is being turned off. Something will replace it. No clues have been offered up yet.
I’m going to say no for apps, and only to use DTH for hub connected devices as there isn’t a replacement yet. Otherwise use the new style integrations.
Much community development will be outside the ST environment so you can use what you want. I haven’t seen what the replacement for Groovy DTH will be. Personally it wouldn’t surprise me if it were TypeScript or JavaScript based if it has to be limited.
Local execution is proposed for device handlers and the Rules API but I’d imagine anything beyond that would be for ST stock stuff. I don’t know though.
The current Developer Workspace is not a development environment as such. It is more about guiding you through interactions with the API to get your stuff into ST. As time goes by and the REST API and the CLI become more prominent, it is becoming more obvious what it is doing and less worrying.
DTHs are buried under Hub Connected Devices. You basically get pointed to the IDE for those at the moment. SmartApps get called various things in the DevWS and its documentation as a consistent terminology still seems to be evolving. Personally I think they need a thesaurus and a mass arm wrestling competition to sort it out once and for all.
We are all just as confused.
Samsung seems to want to move this to an api first business, but I’m not sure how they will convince people to buy a hub etc. If there exist superior api-only alternatives (alexa and google home).
If we get rid of the ease of developing smartapps and device handlers what’s really left? Alexa can do similar automations.
If it’s just a platform for Samsung appliances that you can add some other c2c integrations to it’s basically not any better than LG thinq.
Probably most of home automation people will leave the platform. Developers don’t seem interested in developing for the new apis, and the lack of transparency and documentation from ST, plus the fact that things are constantly changing or being broken, would turn any off who would otherwise be interested.
So if you’re a consumer looking to buy into this platform, I would say don’t, but maybe Samsung will wow us with something in 2021 when they announce their plans for hub connected devices (which is what custom dths act as)
So far literally dozens of device manufacturers have been adding integrations, though. And again remember those 500 million installations of the app with a rating over four stars.
It does seem true that many people who were developing for the old platform don’t seem that interested in developing for the new platform, but that may not be what those hundreds of millions of customers are looking for.
What I’m saying is none of the community is interested, the device manufacturers are a different story.
If like many of the forum users you were using smartthings for its robust community support, those days are over. Hence why I would hesitate to recommend it.
I’m hoping the bridge application for hubitat will be ported to the new api, so I can run everything in hubitat and just use ST as a nicer app front end. I’m not really interested in working with their new API to port things especially for smartapps, as it’s needlessly more complicated. It’s Samsung first user second design. The original smartthings was user first.
So if I’m getting this straight, the “new” integration is I build an API in my personal (corporate) cloud space and I receive events from and post/put changes into the new Samsung ST REST endpoints?
As a specific example, I have a Denon receiver. There is a well documented set of HTTP commands I can send to my receiver to make it do stuff. e.g. If I want to turn on the Main Zone, I can GET http://192.168.1.229:8080/goform/formiPhoneAppPower.xml?1+PowerOn and that zone will power on.
The old DTH and SmartApp combo would have required me to write a Groovy class that invokes the specific Denon HTTP commands, calling my public IP, routing the command to that internal IP (probably NAT?) or used ngrok or something similar, in order for those Groovy methods to affect my local Denon receiver, right? But all the execution was done in the SmartThings cloud using SmartThings compute.
With the new API model, I would need to run an API in my cloud (I use a lot of Azure, so I’ll use that for this example) and since I have a VPN with a VNet in my Azure subscription, I could allow the public API to reach back into my private network and turn on my AVR?
To @mvevitsis point, I see where hobbyists would be turned off by this model. I personally use a lot of cloud, so it would be fine for me. If I didn’t have access to MSDN and had $150 a month to spend on this stuff, I would be completely turned off.
If I were a corporation and I was providing a service to customers, this would give me a lot more control over what is delivered to the end user. To me, this move strengthens the corporate relationship, which should in turn strengthen the end-user experience, all at the detriment of the hobbyist prosumer.
Is that a pretty good summary of what’s being changed?
Yes. The prosumers will move to hubitat.
It’s not a huge deal though because you can run groovy code on hubitat, and if the device is paired with hubitat you can use an app to sync that device back with st. Just needs to be ported to the new api for ST.
Then you can run your custom devices’ code in hubitat and use the beautiful ST app as the front end.
Or you can use HomeKit (via HomeBridge) as the UI, or SharpTools, or very soon -ActionTiles. Hubitat also has their own dashboard. And you can also use The Home Remote which is a native iOS or Android app. There are lots of Hubitat UI options these days.
Well for that particular example you might typically have treated the receiver as a hub connected device using ‘hubActions’ in the device handler to have the hub handle communication with the receiver directly over the LAN. Hopefully that will remain possible and better still extended to support https as that is missing at the moment.
The real change is that custom SmartApps will be need to be implemented either as AWS Lambdas or as Webhook type apps outside of the ST cloud. Nothing to stop the server being local if the appropriate hoops are jumped through.
However with the Rules API proposed to be capable of webCoRE levels of complexity there is a clear intent to reduce the need for custom SmartApps.
I’ll need to look up ‘hubActions’. I treated my device handlers like basic interfaces. I didn’t really look into much more than object descriptions. I just figured put the execution logic in the SmartApp and the device translation in the DTH.
If the new “Rules API” includes a user interface and capabilities set equal to or greater than WebCoRE, I might stay on. Especially if they are executed locally. 90% of my routines are WebCoRE, and while the latency is sometimes very noticeable, it gets the job done.
