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 https://1.2.3.4/ 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:
- The new way to code DTH (Device Handlers) is still coming (hub-connected devices)
- “cloud-connected devices” & “cloud-to-cloud devices” are for new scenarios, NOT a replacement of existing stuff.
- Current groovy code in graph IDE will continue to work for a long time, don’t worry.
