SmartThings as "Open Platform"


(Geko) #1

In another thread @Ben said:

SmartThings doesn’t need to convince OEMs to play by any rules, we are building a platform that allows all those connections to happen without the OEM’s involvement.

Also, from http://blog.smartthings.com/news/smartthings-updates/new-smartthings-experience/:

SmartThings app experience establishes a single destination for smart home enthusiasts to create and customize a connected home that matches their needs. By embracing the innovative third-party applications and products on our open Platform, we hope to offer consumers greater flexibility and make it as easy as possible for anyone to create a smart home.

So here’s my silly question. To what extent SmartThings is open? To me “open” implies that I should be able to create a device (e.g. a temperature / humidity sensor) that can connect to the SmartThings cloud without requiring a proprietary piece of hardware (an ST hub). This is how other open device cloud services operate, for example ThingSpeak, Xively, Carriots and others. Also, this device must be a “first class citizen”, i.e. be able to send/receive all events without restriction.

Based on available documentation and forum discussions this does not seem to be the case. The only way a custom device can communicate with the SmartThings cloud is via REST end-point that have far too many restrictions imposed on it.

Any thoughts or comments?


(Bob Florian) #2

The SmartWeather Station Tile is an example of a device type that provides temperature, relative humidity, and other data using the Weather Underground API. It generates the same temperature events as a hub-connected temperature sensor and can be connected to any SmartApp that uses the temperature measurement capability.

The SmartThings/IFTTT channel is another example of cloud-to-cloud integration. It’s built using the same REST endpoint and OAuth features that are available to any SmartApp or device type developer.

Can you expand a little on the REST endpoint restrictions you refer to? If there are limitations preventing you from integrating with the platform we’d like to understand what they are.


(Geko) #3

@bflorian, thank you for your reply. The examples you’ve mentioned are fairly trivial. Lets consider a more demanding application. Do you know what is the most active thread in this forum? It’s this one: http://community.smartthings.com/t/dsc-alarm-integration-and-alarms-in-general/ - 127 posts as of today. Why? Because an alarm system is the most crucial part of any serious home automation setup. It requires real-time response and 100% reliability, both areas where SmartThings is rather weak, to put it gently.

While ST lists “Home Security” as #1 benefit (http://www.smartthings.com/benefits/) and tries to mimic some features of the traditional alarm panel, it cannot come even close in terms of reliability and responsiveness. I wrote a “virtual alarm panel” app and while it works on a good day, it’s no more than a “toy” due to unpredictable latencies in the cloud service.

On the other hand, integrating traditional alarm panels into SmartThinds proved to be difficult. Current solution (https://github.com/kholloway/smartthings-dsc-alarm) is a kludge, including a REST endpoint app and multiple virtual device types, requiring lots of manual configuration and setup. Particularly nasty is a requirement to authenticate the app using cumbersome manual procedure. It’s not something I’d even try to explain to mom how to do. :smile:

I’m sorry if I sound critical, but this is the most unintuitive environment for installing third-party apps I’ve ever experienced.


(Justroach) #4

Not to pile on, but this is exactly why I am pursuing using other/additional platforms. I was actively working with the Ademco Integration project to find it deleted one day.

As kludgey as it was I was OK with it given there was an active forum/users/developers. Opening the platform would certainly go a lot further in achieving this goal.


(esung) #5

I think the ‘open’ aspect of ST is not about the hub or lack thereof, but the fact that a developer can add device to ST on their own. For example Quirky connected device was added to ST thanks to @twack’s hard work, using their API but without much involvement from them.
Apple’s HK approach would be different I presume. Apple and device maker should work out together and officially certify HK compatible device so that we can use them via HK.

I like the flexibility that ST’s model provides, but at the same time I see the price you pay. Quirky stuff is not perfectly functional because their device/cloud service is quite unreliable. On HK we would have to wait much longer to use Quirky stuff until they iron out all the kinks, but when it is certified it’d be more reliable.

I see both model’s pros and cons, and I think it’s good to have both. (Kinda like it’s good to have both iOS and Android to exist in the market) And I hope Apple’s entry into this field will put some more pressure on device makers like Qurky to get their act together and not make their customers beta testers. I hope ST would find a way to fully take advantage of both approaches and not be tied to the ‘open wins’ mantra.