[RELEASE] golang smartthings library

Hello,

As part of a personal project to interface some custom devices to SmartThings, I wrote a golang library to simplify the task of logging in to SmartThings (using OAuth2) and using its API.

The resulting library is called “gosmart” and available under the Apache License at its Github page: http://github.com/marcopaganini/gosmart

The code is still in its early stages, but can already:

  • Painlessly log in to SmartThings using OAuth2 and retrieve a token.
  • Cache the token locally, so further attempts don’t require user interaction.
  • Fetch the endpoints URI, and produce an authenticated http.client that can be used to perform actions.

I’ve used it to quickly write a program to read the temperature of all my temperature capable sensors and upload the data to ThingSpeak. I’m also writing a collectd plugin to keep an eye on the state of my batteries, temperature, find out how many times sensors trigger and all sorts of interesting things.

There’s still a lot of stuff to do, such as:

  • Add unit testing.
  • Expand the Groovy “webservices” app to treat all sorts of capabilities.
  • Add matching Go handlers for each capability, returning native Go types.
  • Add support to change the state of devices (this is trivial, but for now the library only reads information).

Those will come soon (and working on them, time permitting.)

Your comments, ideas, and pull requests are welcome. :slight_smile:

Regards,
MP

2 Likes

I have a pretty extensive API smart app published on github. Just updated it to add more capabilities.

3 Likes

Ohh, this is pretty awesome Jody! Mind if I bundle your groovy file with my library?

1 Like

Not at all. That’s what it’s there for.

Awesome, thanks. Also, I see that instead of fetching information by capability like I’m doing, you prefer to fetch all devices, is that correct? So, in my case, I’d always fetch all devices and then parse whatever capability is required. Is that the expected usage?

You could get it to return devices by capability fairly easily. A previous version of the code had it that way. Just having one devices endpoint makes it easier to send commands/query. I store all of the devices and look for capabilities on my local server using the current code.

Here is the old code. (Still checks out :slight_smile:)

Nice!

I’m trying to run the new code in the simulator (allowing all sources) and I get an error:

groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method script14785461214331029880089#subscribe. Cannot resolve which method to invoke for [null, class java.lang.String, null] due to overlapping prototypes between: [interface java.util.Collection, class java.lang.String, class java.lang.String] [class physicalgraph.app.InstalledSmartAppWrapper, class java.lang.String, interface java.util.Map] [class physicalgraph.app.LocationWrapper, class java.lang.String, interface java.util.Map] @ line 85

Did you manage to “simulate” it without problems? I tried chaging my lib to get “/devices” but I can’t pass the OAuth2 page (a vague error asking me to try again later.)

Regards

Update: I discovered what is causing the problem, and a workaround, but it’s not clear to me why.

If we remove or comment the line:

subscribe(colorTemperatures, "colorTemperature", handleColorTemperaturesEvent)

In the original source code, everything works fine. Of course, we lose the capability of checking colorTemperatures. :slight_smile: Note that with this line, things fail both in the simulator and when trying to authenticate, so it does not appear to be a simulator problem.