Using the SmartThings API


(Liam) #1

Hello all, I am getting started on diving into the  SmartThings API and have hit a snag in successfully authenticating. Has anyone been successful in connecting via the API to SmartThings?

I have taken a look online to see if there were any examples and haven’t found one that I can emulate. The closest is the SmartThings Titanium App on Github (https://github.com/alanleard/SmartThings/blob/master/Resources/smart.js) but haven’t been able to translate what they are doing to a simple CURL command that successfully connects via the API. In their fetch method (line 80) they create a HTTPClient and add a username and password to it for every request to the API. I’ve tried adding this to the header of the request and not been successful.

When I run this:
curl -H “username: USERNAME” -H “password: PASSWORD” -v https://graph.api.smartthings.com/api/accounts

My result is this:
{“error”:“true”, “type” : “Unauthorized”,“message” : “Full authentication is required to access this resource”}

According to the API overview (http://build.smartthings.com/smartapps-overview/#RestAPIs) is restricted “Based on a revocable security token that is associated with a specific user account.” If this is a better method of authenticating where I can access that token from within my account? I’m also lead to believe that tokens are the way to do this since in the verbose response from the CURL request I see “WWW-Authenticate: Bearer” as the authentication method. Unfortunately after re-re-reading the API doc I am not able to find the authentication route.

Any help would be appreciated, as I’ve hit a bit of a wall.

Thanks,
liam m-


(J Foshee) #2

I would be interested in this too on getting the API up and workable on this. Anyone at Smartthings working on a API document or have a rough draft?


(J Foshee) #3

I found this which helped me.

https://docs.google.com/document/d/14F5CnjIbI8Ru4-MrjHXhnBGGQngUevVEe7H3cqoGHKA/edit?pli=1

Its the “SmartThings Web Services Developers Guide”


(Liam) #4

Hi @JFoshee, that is the document I’m referring to but I didn’t link to it. Using the straight API I have not been able to authenticate to the API just yet. I did note that it is a SmartApp that exposes the API and will look into this tonight to see if there was something I missed there.

When you say that this helped you, does this mean that you have successfully authenticated? And if so would you mind sharing here how you were able to do this? My ideal scenario is to utilize this in a mobile application (native code for a device) that and not just as a SmartApp.


(J Foshee) #5

, No what I meant by helped me was use a API to devices.No what I meant by helped me was use a API to get to devices.


(Liam) #6

Sorry, I’m not quite sure if you’re referring to the SmartApps or the API. I’ve been able to use and create SmartApps with no difficulties. There are a couple that may be made public shortly as they are kind of useful.

Are you saying that you have been able to use the API (not SmartApps), and if so could you please share your findings? I have tried a few things and cannot get the token I need to authenticate against the API. Or if that token is not required, what did you use to utilize the API?


(Jeff Hagins) #7

So here’s the deal. The “Core” SmartThings API is not authorized for use or accessible to general SmartThings developers. The Core API is only for authorized SmartThings partners. This is because the Core API provides full unrestricted access to the “Physical Graph” for a specific user (using OAUTH2).

The integration approach for general SmartThings developers is to write a SmartApp that exposes it’s own APIs. This approach ensure that the SmartApp has it’s own unique Security Context (determined by the user at the time of installation).

The document that was referenced is the correct document - though it is not yet complete:

We are working actively to get this document finished to include some sample SmartApps that expose their own web services so that everyone  can see how this is done.

 


(Snoopbuild) #8

@hagins - Please let us developers know as soon as OAuth2 for a SmartApp is working, and also please let us know when a sample SmartApp is available for us to model. Also, please update the reference document as soon as you have info! :slight_smile:

I assume the protocol will go like this:

  1. create SmartApp having exposed APIs, enable OAuth for the SmartApp, and get client_secret and client_id for SmartApp
  2. on third-party service, perform OAuth dance with SmartThings API using client_id and client_secret:
    (user authenticates with SmartThings, approves SmartApp, specifies devices that SmartApp can control. code is returned to third-party, which is exchanged for token.)
  3. third-party can now access SmartApp’s APIs, which will be able to control devices allowed by user, etc.

Something like that?
Anxious to see some examples!


(Bazaarsoft) #9

@hagins - so, to summarize:

  1. The REST APIs described on the overview page aren’t available to developers.
  2. Every external app that wants access to SmartThings will have to write their own API as a smart app.

So much for open access “internet of things” unless of course you mean a bunch of proprietary APIs.

Very disappointed.


(Tom) #10

So I dove into it today a bit. Here’s what I’ve found out over the past few hours. https://github.com/tmaiaroto/smartthings-unofficial-docs/blob/master/Documentation.md

Hopefully it helps some people!

Basically you will need to get yourself setup using an iOS device…But after that I see no reason why you couldn’t build your own applications (web based even!) to read from all of this wonderful data. I can’t make any promises here as I’m sure things will change, but I’ll try to keep things up to date since they are for my own notes as well. If it falls behind it’s because satisfactory official documentation was released or because I’ve lost interest with SmartThings (or lack of time).

I’m still digging around.


(Donald Kirker) #11

Ultimately, my goal is to develop a SmartThings client for webOS (and open webOS). Which means I intend to be able to not involve an iOS or Android app at any stage during the usage of the SmartThings platform. The “Method 2 - OAUTH-Integrated App Installation” option seems closest to what I will need… but the impression that I am getting is that I won’t be able to add or remove devices or other SmartApps, and that I will need to define supported devices during set up? Or is it that the docs aren’t complete, so I am missing the part that will tell me that I can do what I intend? :slight_smile:


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #12

@bazaarsoft : I echo your disappointment and am following this discussion closely.

Why is the full API published if it is not open to any accessor? Well… obviously there is proprietary control issues involved. Remember, this is a for-profit enterprise; entire SmartCloud, not just the hardware.

I question the long term security model architecture:

Certain information about devices (and all of the other objects) will not be available through the API in the interest of privacy and security. Nuff said.

“Nuff said” is very concerning.


(Endoplasmic) #13

Bumping this thread as a new wave of people are coming in via invite codes (doc hasn’t been updated since April)


(James Yong) #14

Gave up on writing clunky groovy code. Dug around for a nice REST api and found this thread. Doesn’t seem to sound good :confused:


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #15

@jamesyong:

With an intentional overly cynical tone, I will say: At this time, SmartThings’s priority is on the uninformed consumer, not on small developers.

There are many features that were promised that have not been released to the Build (Developer) community (e.g., local LAN IP connectivity, Bluetooth, API documentation, etc.).

Physical Graph Corporation is presumably doing what they need to in order to obtain and retain funding, and increase revenue and margins.

They are certainly working on LARGE partnerships, but us little folk are going to have to fend for ourselves … indefinitely.

Luckily there are many competitive products entering the marketplace. While it can be a waste-of-time to learn multiple interfaces, hopefully in the long term, this will help create a community that demands stronger standards.

…CP.


(James Yong) #16

I guess so. Good for having a remote on the phone, but anything more its pretty much painful.

The IDE is so slow I spend more time waiting than coding. Fortunately its fine enough to work on simple systems, I find it hard to scale it to anything larger.

So now after bouncing around vera (I’d say meets 70% of my requirements, but have concerns with being pretty closed-box and a so-so ui), smartthings (almost nonexistent ui, proprietary zigbee, online service) and a few other opensource alternatives, I think I feel pretty confident with ST but theres a need for us devs to work out the missing parts.

For a start, I actually need an energy control dashboard, having a dozen energy monitors theres no way out of the box to graph the data.

Two ways I could go about this, relay all events to and fro my own server via a SmartApp, or to create some form of external service to create a UI that integrates properly with ST.


(Toejough) #17

@hagins:

Is there a timeline or a prioritized feature list that we developers can go look at? I see a lot of documentation that says things like “this is our vision, but we’re not there yet” and “we’re actively working on this”, but those kinds of remarks are vague and it’s difficult for me to understand what is really going on.

If I spend the next two weeks writing my own web API app and web page, is SmartThings going to roll out an official one a day later?
If I spend the next month hacking into the hub to enable real LAN control so I can securely use my foscam, is SmartThings going to flip the switch to enable that officially the day before I get that to work?
If I decide I really do want code control on my deadbolt, and go buy a Vera system tomorrow, is SmartThings going to enable that next week?

I’m being optimistic with those timelines. Frankly, I’ve already bought your hub and several of your devices, so I’d really like things to be awesome and confirm my decision to buy.

Don’t get me wrong - I’m loving the stuff I’ve been able to do so far…it’s just that I also see a lot of potential for more, and right now I’m having a hard time figuring out if I will actually be able to achieve that with SmartThings or not.

I feel like some transparency behind what is being worked on and prioritized would help a lot to alleviate many of the frustrations expressed in this thread, too.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #18

@toejough:

I have been asking this EXACT question (well… for a “product Roadmap” and … transparency), over and over again, literally since Day 1 (well, the day that I became a Kickstarter Developer level Backer).

There has never been a response firmer than the consistency of honey.

@hagins’s 3-week old blog post is meaningless, as it contains no timeframes, and there isn’t anything in the strategy he describes that is a commitment.

I can’t speak for SmartThings, but I’ll repeat my view:

SmartThings does not have a published strategic plan for many reasons …

(a) they don’t know, care, or have the resources to document,

(b) they are more investor (VC) driven than customer focused,

© mass-market consumers are a higher priority than us small developers,

(d) like COUNTLESS companies over the past few years (and beyond), above all else, SmartThings has only one goal: To establish a sufficiently growing revenue stream and strategic major corporate partnerships (e.g., NEST and other device manufacturers?, home monitoring services?) such that they will be attractive to a buyout/merger that will make the founders rich, and provide a nice rewards for the early employees granted equity options. (Keep in mind that the buyout MAY occur with the SOLE purpose of KILLING the product-line in order to eliminate SmartThings as a competitor to the buying party.),

and (e) they cannot publish any internal strategies/plans because this will give the competition an advantage and reduced the necessity of a buyout for intellectual property purposes.

There are a LOT of competitors entering this market, most with very similar strategies (i.e., hub & cloud, and Z-Wave/Zigbee/BLE/IP, and cloud-to-cloud APIs): However, the degree of openness already/will/may vary greatly.

  • Webee (currently in campaign on Indiegogo) claims that their hub is Android based and they WILL allow developers to completely “root” the hub and hack it. http://www.indiegogo.com/projects/webee-the-real-smart-home

  • Ninja Blocks already is completely hackage, and perhaps the NinjaSphere also will be: http://www.kickstarter.com/projects/ninja/ninja-sphere-next-generation-control-of-your-envir?ref=live

  • WigWag is in refinement and production after successful Kickstarter, but is likely far behind schedule). Public commented discussions with them have implied that they will allow a great deal of hacking, though I don’t think they are fully open hardware like Ninja: http://www.wigwag.com/

  • And there are various other systems … most of which seem even more “closed” than ST, and variations (webcam centric, voice control (Ivee and The Ubi…).

  • Big vendors are ramping up their offerings (Lowes, Comcast, AT&T, … ummm… GE?).

My conclusion at this moment in time?

SmartThings is first-to-market and that has expected advantages. Their campaign fundraiser did well due to being first, not because they were the “best” – backers has not much to compare against!

As the competitors “catch-up” to SmartThings, we consumers will see the benefits of market-competition: i.e., there will be pressure to excel… Except, the market is not efficient: Poor products often beat better ones due to non-technical factors (flashier marketing, first-to-market advantage, bigger behind-the-scenes funders, mergers). It’s Beta vs. VHS, perhaps … though hopefully the use of open standards will minimize the possibility of a horribly fragmented marketplace.

This is actually a fascinating real-live case-study. Remember when Edison put immense pressure on Tesla by claiming AC power was far too dangerous to use, in order to promote and profit from his costly DC distribution system? Edison was a real donkey-hole. I’m not, in any way, implying that SmartThings has any nefarious intent … just that history will look back at this time with a VERY different perspective.

Happy New Year!
…CP.


(James Yong) #19

Paying the initial upfront pain/time/effort to relay events and commands to and fro my own server. I don’t see any existing project on that, so I’ll put up a project once I’ve got things sorted out. From this point on it’ll open up opportunities to develop our own UI for consoles like tablets mounted on the wall, integrate with other devices and services, etc :smiley:


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #21

Throwback Tuesday

All three of the crowdfunding projects I referenced in December 2013 failed.

So… SmartThings is doing infinitely better in any comparison whatsoever!