SmartThings Community

Concerns about Direction of Developer Workspace


(Carl) #1

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.

Is SmartThings dead?
Example using new SmartThings Cloud API!
SmartThings/Samsung Account Migration Beta
Groovy apps future support?
SmartThings/Samsung Account Migration Beta
“Device Integration Coding for Dummies” ? [2018 New Platform Nongroovy Edition]
Should I wait for v3 hub? (STH-ETH-300)
A few questions about Sonoff switches, Fibaro dimmers and stuff most of you will know
Sylvania Lightify dimming Switch Device Handler?
Why Apple will kill Smartthings
(yet another) Hue integration solution
(Enis Hoca) #2

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.

(Luis Pinto) #3

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?

(Jody) #4

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

(Larry) #5

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?

(Jody) #6

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.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #7
  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, …)

(Luis Pinto) #8

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?

(Joel W) #9

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.

(Jody) #10

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.

(Robin) #11

@jody.albritton This new model seems to be pushing us basic hobbyist coders out the back door… from what I’ve seen so far, only hard core coders will be able to contribute in the near future and all the hosting will have to be done by developers, not ST.

All seems like a step in the wrong direction that’s going to break everything I’ve worked hard on the past few years!

You guys could at least maintain a legacy version for us oldies!

(Amauri Viguera) #12

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

(Jody) #13

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.

Example using new SmartThings Cloud API!
(Joel W) #14

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.

(Dana ) #15

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.

(JIm) #16

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.

(Robin) #17

That’s all very well but what if I don’t want to run it at home on a pi? Will I still be able to take a smartapp created by a developer and run it in the ST cloud? Or will our alternative be a reliance on 3rd party servers managed by the developers of new apps?

What about all our existing automations on apps like webCoRE which are just going to disappear overnight?

What about device handlers? Will all my devices suddenly stop working unless someone has created a new API device handler before the switchover?

The default device handlers ST currently provide don’t even expose the most basic of functions such as parameter settings… if we’re going back to that level of control it’ll be a sad day for us all!

We, the community, and in particular the awesome community developers, made ST great! Is ST seriously going to throw hundreds and thousands of hours of community developer work in the bin? And break everyone’s existing setups?

Surely a legacy system could be retained, at least for existing users? And we can slowly switch over when we see things are ready for our individual device collections.

(might be my fake name?) #18

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

(Gene Clark) #19

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

(Robin) #20

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?