Lockitron Community

SmartThings Integration


" I suspect as more developers have access to systems (Hue, Lockitron locks), we will begin to see a more complete integration across the board."

Hue, Yale, Schlage, Kwikset and the rest have reached out to Samsung and worked with them, hence being certified and native in their hub and show up as the if you want this sort of product this is what you should buy. They did not just wash their hands of it and say we have an API and maybe here is our IFTTT channel, have fun.

With supposedly so many Bolts being shipped in the US have yet to see much on the Internet from these owners. The last thing google shows is https://github.com/dkirker/smartthings-lockitron which was the original Lockitron and hasn’t been updated in 2 Years.

So it appears your “more complete integration” will more likely actually be go learn groovy, hack something together yourself, hopefully share it with others on github, and pray everything works. Of course this will only be useful to those of us whom are savvy enough to be able to get into our backends and add smartapps and device handlers on our own, but not savvy enough to code from scratch.

The only way you will see true more complete integration is if just like Hue, they work with other parties to ensure their hub to hub communications, apps and devices work the way they should.

But all of this is a rather moot point with the status of bridge being what it is.


@Rattay780 @josh.stuckey moving your discussion about SmartThings here where it’s more relevant.

To clarify, the other locks you mention support SmartThings because they are Zigbee or Z-Wave devices. They don’t have their own stand alone apps - which, depending on your use case may or may not matter. So their is really no active integration there, SmartThings supports the spec, and as such can very quickly “certify” them.

With half a dozen significant platforms to integrate we’ve started with IFTTT as that lets us see where the demand is. Based on that data a direct Alexa integration is our next priority.


Hi Cameron,
Good call on the thread move, got a little off the when will we see product over to and what if we see product there.

Ok, now to your points, and to Alexa, let’s start with architecture. Most individuals will have architecture as follows when they deep dive into IoT, and when more consumers get involved:

                                             Amazon Alexa / Google Home (Voice Layer)
                                        Samsung SmartThings / Wink / Vera (Control Layer)
                                                /                  |                     \
                                       Thing           3rd Party Hub       Thing
                                                            3rd Party Things

Now that this is out of the way, more to companies and integration.

While you are correct those locks are Zigbee or Z-Wave that makes their lives simpler, and they have gone the slightly extra step of being in the app so they can be added manually, have connection instructions, and buy now links. Other more generic Z-Wave devices like the Econet EBV105 valve I recently picked up are slightly different Z-Wave in that they just show up as . But these are both irrelevant here as Lockitron is not Z-Wave and not like any of these products.

As Lockitron will supposedly have it’s own bridge, this is where the integration would happen and not with the lock. When josh mentioned Hue, it is one example. SmartThings hub and the Hue bridge speak to each other over the LAN after button pairing, this is an approach, this was community developed. This same approach was that used by Chamerlain/Liftmaster where they have their own hub, but a clever coder made his own smart app and device handlers to allow tying into other things, https://github.com/brbeaird/SmartThings_MyQ this was also not developed by the manufacturer or Samsung. The Sonos integrations have actually been developed by the Samsung SmartThings folks with collaboration of Sonos, they allow limited usage outside of Sonos primary application, such as volume control play pause and track forward, offering limited control. This same approach was that used by Chamerlain/Liftmaster where they have their own hub, but a clever coder made his own smart app and device handlers to allow tying into other things, https://github.com/brbeaird/SmartThings_MyQ this is not by the manufacturer or Samsung.

My favorite, and the one that would be best equated with Lockitron would be like the folks of AlarmDecoder did for their AD2PI appliance. They created their raspberry pi based device, they created their API, and went the step further and also released https://github.com/nutechsoftware/alarmdecoder-smartthings on github which provides the device handler and smartapp for their product and their api they know intimately instead of making somebody off the street have to put it all together. It provides the ability to arm disarm, such as you would have lock / unlock. All of the fancy stuff would remain in the lockitron app and on your web page.

Perhaps the dkirker stuff still works, perhaps one of the folks that actually got a bridge will release something on github by the time the rest of us finally get our hubs. Or perhaps Lockitron can pick this up?

As for Alexa, or Google Home for that matter, those that make the home automation brains are already on that, wouldn’t it be more low hanging fruit dealing with the brains which will then achieve the harder integration with the voice services with their larger budgets/teams of coders?

Of course not having the Bolt, and even less likely to see the bridge any time soon I am not in a position to deep dive into the API to see what is required here, nor be able to perform the coding and testing required to get things going and then unleash it for all of your customers to use.


@Rattay780 thanks for the thoughts; I’m a bit wary of going through a partial measure of building an integration and releasing on Github without fully going down the path of “Works with SmartThings” (i.e. it’s still only for the most technically sophisticated folks and wouldn’t add to the existing dkirker work). That said, we aren’t ruling it out but can’t commit the resources to it today.

I should note that there is a recent, patched branch from the dkirker repo that might help folks looking to play around with this: https://github.com/annbob/smartthings-lockitron/tree/patch-2.

Agreed to comments above re latency; the native Alexa integration will be significantly faster than doing it through IFTTT (but you will be limited to the native commands, unlike IFTTT).


Thank you very much for the link to the updated code on github as a starting point. I understand your thoughts in regards to full works with smart things path, hopefully something can be done with that existing code to tide over both communities until such time as that can be done. Would have thought that at least some of those who have purchased and received product by this point would have fallen into the technically sophisticated bracket.

Now if only somebody outside of your organization that would be willing to work on this for the good of the many could actually get their hands on both products required for development and testing. :wink: :wink:


Has anyone had any luck with using that code from github?

When I try to use it, I go to set up the smartapp, and it says Lockitron required
When I tap there, it takes me to the lockitron api page and gives me a login screen.
After I enter my UN/PW, it says An error has occurred The redirect URI is included is not valid.


Sadly have not been able to try, seeing as bridges are like leprechauns, some have claimed to have seen them however could just be rumors.


So almost a year later, I decided to try again.

I figured out my issue. in the api.lockitron.com I had an incorrect redirect URI. It should be
https://graph-na02-useast1.api.smartthings.com/api/token/ not https://graph.api.smartthings.com/api/token/ like it says on the git.

I can now lock and unlock through smartthings, but SmartThings is always showing it as locked. I am guessing this is something to do with the device handler since the debug messages in smartthings show the correct state as “unlock”