Concerns about Direction of Developer Workspace

Since few weeks, I’m very perplex on the new road taken by Samsung & SmartThings.

Recent weeks are painful

Unlike before, in the recent weeks, the platform started to be very unstable. Pretty often I’m getting some annoying unexpected glitches like unresponsibe hub, smartapp doing nothing, big delays, etc… I know it’s probably due to the big migration to a whole new system and I understand it should come back to normal. I hope.

How to develop quick things?

But where I’m perplex is about the new developping model. I wasn’t fan of the groovy language and the very poor IDE of SmartThings, but it was doing the job pretty fine. I’m a C# developer and I want to use my expertise to develop things, so that’s why I was very excited by the new APIs of Samsung Connect.

Unable to find a quick way

I started reading the documentation and, after a while, I realize many pieces are missing to build something quick. In the previous version, few lines of groovy, you click publish and your can try it right now… In the new version, you need to write a device (not sure I inderstand how yet… see below), write a plug-in, sign the whole thing, get approved by ST and… you will publish on a portal totally unrelated with your current ST installation.

Maybe I’m too soon and I need to wait… but when I read the documentation, I realize it’s far more complicated than before to do custom things.

My sample project

Let me describe my project… I want to build something on top of a Raspberry Pi, using Windows IoT and some GPIO hardware. The hardware portion is working well, now I need to connect it to ST. In previous version of ST, we could just use UPNP and a controller smartapp and it’s working well. With the new interface ? I’m not sure it’s easy. Let me described what I tried…

Trying using “cloud-connected” devices

First I checked using the “cloud connected devices”. That means devices talking OCF language over a CoAP protocol. The documentation is clear:

To develop this app, you can use any platform that supports OCF.
If a platform doesn’t have OCF support built in, you need to create
the stack yourself. Use a platform like Tizen RT if you want to get
started quickly, as supports the OCF stack.

Ok… I read the CoAP RFCs and all the pertinent OCF documentation… wow. that’s huge. I don’t know where to begin… Specially I don’t even know how to start. Wwhen we develop something, we try few http calls using a tool like Fiddler or Postman… but here, I don’t even know where to start.

Since I’m strong with the http protocol and my devices and robust enough to use a heavier protocol, I told myself maybe CoAP is not the way to go… so I tried to find a way using the “Cloud-to-Cloud” integration.

Cloud-to-Cloud, maybe it’s the way?

Ok… that seems the way to go. I read the documentation… it’s all http-based. That’s cool. I could use a UPNP library to open a port so the “webhook” callback will come through this.

I started declaring an app on the new workspace site and I realized I need my app running before it can be set up. Fail… that’s definetly not the first step to do. But I saw at the same time there’s a requirement to use https for communications. Ooohhh that’s not the same game. Not only I have to find a library able to do http, but I also have to use TLS and, I suppose, a certificate emmitted by a well-known Certificate Authority… Outch. That’s painful. Maybe I can find an ACME library an implement Let’s Encrypt too… Not to mentiong I’ll have to register a dynamic DNS (not sure I can give a address to ST)…

Ok… So I’ll try using Azure Functions (very similar to AWS Lambdas). That would be great since they will manage the TLS for me. The device would report its status to a function on Azure and this one will serve for https webhooks. But there’s a catch : To be able to communicate back with the real device, I’ll need to 1) open a port or 2) using a constant connection to my Azure Function. The #2 would be too costly and #1 would be without any protection.

Finally no good solutions

So both “cloud-connected devices” and “cloud-to-cloud devices” are painful to use. And we have a hub in the network, it would be so nice to connect to it directly. Since it’s on a local network, http would be correct, simpler and pretty straighforward.

And it’s just half of the job

If my understanding is correct, once my device is done, I’ll need to write a plug-in in a totally different language, package it, sign it and publish it on the new portal. Ok, it’s HTML/javascript, but that’s a whole project just by itself.

Solution: wait for hub-connected device? … maybe?

So, my hope is now ST will implement a HTTP api directly using the local hub (UPNP/SSDP?). Without that, I’ll need to find another “more opened” platform.

Am I missing something??? What kind of integration are you planning to build with the new ST? Please give me some guidance!!!

[UPDATE] TL;DR if you don’t want to read the whole thread…

After many messages exchanged here, it seems it’s just too soon:

  1. The new way to code DTH (Device Handlers) is still coming (hub-connected devices)
  2. “cloud-connected devices” & “cloud-to-cloud devices” are for new scenarios, NOT a replacement of existing stuff.
  3. Current groovy code in graph IDE will continue to work for a long time, don’t worry.

That’s how I feel as well. They are going away from their core community and gearing it up to play only with the big boys - who BTW have their own game and ST doesn’t stand a chance - Alexa already has a zigbee radio and if it adds z-wave, why would my cousin want to buy ST; she just wants things to work. Point being their new strategy is neither here or there. It’s not in the big leagues and they will lose their base by making life difficult.

Has been the OAuth method implemented yet? I’m really curious about how long it will take to release a version for doing this.

Also can you please explain the way to submit an app available for all smartthing users?

Oauth in is currently the active item under development so it’s release should not be in the too distant future.

Depends on the kind of app/device/integration. For simple API apps the current thinking is that it will be instantly available to everyone. For things that push code into the mobile app or add/change UI there will be a review process. For devices we have rebuilt the certification process from the ground up. If you intend to publish a device or solution visit this page to get started

1 Like

doesnt sound very promising for home users like me… only companies that want to publish device types for their products… no more open api with anyone pushing code?

No. It’s not limited only to companies. If you want to have a device certified to Work With SmartThings (WWST), you will need to go through a certification process and you don’t need to be a company. Anyone can submit a device for publication and you will still be able to self-publish your own custom stuff without any sort of approval. The API is open and fully documented.

  1. What if someone wants to publish a “Virtual Device” (to be used with a publishable SmartApp)… e.g., TrendSetter, or Weather, or various types of Virtual Switches and so on?

  2. Will one brand / model of device be allowed to have different DH’s provided by different developers? (e.g., Ecobee, Nest, …)


Simple API apps seem to have the same issue. In the new platform when you submit an Automation the status is “self-published” so I assume that it’s not accesible for everyone. Am I missing something?

What about the rest of us that are not developers, or basic programmers that benefit from other members hard work? Are we going to be left with out these benefits that others so nicely provide? Who is SamrtThings going to be for? I for one choose SmartThings just because of the great community that helps so many.


Correct. Self published means that it is not available to anyone but you. See my previous comment about different types of apps needing different types of review.

Virtual Devices are supported.

Custom device profiles will still be possible. There is also the concept of a device plugin that extends/enhances and existing device.

I guess it’s almost time for the SmartThings to Connect to Samsung Account to SmartThings migration to be completed? :grinning:

SmartThings is full of makers, hobbyists, and tinkerers. I might be doing this full time but I still “tinker” around with SmartThings in my spare time. It’s not about pushing hobbyist old timers out the back door at all. There is a problem that needed to be addressed, while our original tools were great for a weekend hobby project, they were never going to scale into a solution capable of service millions of people.

I fully believe that our new API will open doors to people who could never have developed for SmartThings before.

You can now develop a SmartApp that runs at your home on a raspberry pi and do it in javascript, or java, or groovy, or any language you want. All you need is a basic understanding of how restful API’s work and you are off to the races. This is a big win for developers of every skill level, not a step back.

What about the rest of us that are not developers, or basic programmers that benefit from other members hard work? Are we going to be left with out these benefits that others so nicely provide? Who is SamrtThings going to be for? I for one choose SmartThings just because of the great community that helps so many.


Absolutely…the community here was a key reason I bought into SmartThings, and a key source of some of the best experiences that are available on this platform.


I tried this some time back. I use a dyndns service to know my home IP address. But if I tried to enter **** in the ST development it kept telling me it was an invalid IP address. Maybe that’s been fixed by now. I haven’t tried it lately.

I agree with @anon36505037. Something needs to be done to maintain accessibility to smartapps (Webcore and others) and custom DTH’s or I’m out!


And those of us not using a Raspberry Pi? What then?

1 Like

I am a pretty new ST-user and I must say I’m concerned about what I have read here. The reason I bought ST is because of all different custom device handlers. Also, I am using webcore for all my automations.

Will my user experience be affected? Will my devices and automations stop working or have I missed something?

1 Like

Absolutely Not.

Raspberry pi was just one example. When you publish code via the IDE today it’s being “hosted” by someone (SmartThings). We need to stop looking at this through the lenses of how this worked in the past. For the non-coders, we are trying to build a platform that does not force you to use code. For the developers we are trying to build a platform that will allow you reach more people in a published and controlled way without needing to pass around the source code.

And lastly, No. We aren’t throwing anything in the bin overnight. There is going to be a long transition period before all of the new stuff is even fully in “production”. Then there will be some time while we main both the new system and legacy systems.

1 Like

It is required to be HTTPS