Connecting to Schlage's New WiFi Locks Is Not Easy

I like Schlage’s smartlocks, and have used them for years. Built by a company with a long history of making reasonably secure, reliable locks, I’ve used several of their Z-Wave locks over the years, but Z-Wave is…Z-Wave. Proprietary until recently, a PIA to troubleshoot, and while the technology held a lot of promise on paper, in reality it’s been the cause for many a swear word to erupt from my mouth (I realize this is partially due to the controllers I’ve used over the years).

I recently moved to a new home (city, and state!) which gave a chance to
consider new home automation choices. Watching trends over the last year or so, WiFi seems to have become the wireless connection of choice for “smart” things in the home, when I saw Schlage now had WiFi-based versions of their locks in the Encode family, I decided to select that product.

If you’re relatively handy, they install easily. Setup is performed via an app on your phone via Bluetooth (Which makes it easy to reconnect to WiFi after you change your network and key, forgetting to move the lock first. Ahem.). Once setup, the locks respond pretty quickly to lock/unlock requests from the app, wherever you are. Next step: get them into my new home automation system of choice! They’re on WiFi already — should be easy, right?

Not so much. Googling around, I see just Amazon Key having support. I
couldn’t find any signs of a public API or development library, or development/partnership program for the Encode family. But it was on my network dammit, and I was caffeinated late one night while under covid-19 stay-at-home, so I dug further.

I’ve quickly become a UniFi convert…

I’m pretty anal about how I run my networks, so I already knew the IPs of the locks. And my gateway — a UniFi Dream Machine — is a choke point with a sniffer installed, so let’s see who these things are talking to:

OK — so it’s connecting to an IP block that looks familiar. Let’s see if I can verify that:

Yep — the lock’s talking to something in Amazon’s cloud. Not a bad thing by itself, but this could quickly lead to a dead end. It’s talking on TCP/8883 from Googling around, it looks like that’s a standard port used to communicate via the MQTT protocol over TLS. MQTT is a good choice for IoT communication, so this is a positive sign.

For brevity I’m leaving some steps out here, but if one googles around for “amazon tcp 8883” you’ll get a few more clues, but let’s fast forward. For $reasons I decided to try a https request from my browser. Nothing exciting was in the response itself, but the TLS certificate shed a little more light on things:

So we can confirm that the Schlage Encores communicate via secure MQTT to AWS IOT Core — a managed cloud service run by AWS for IoT devices to connect to the cloud. This is “good” as in they’re doing the Right Thing, but “bad” in that it’s a dead end for this research. An AWS customer can link that IOT Core endpoint to all sorts of different things, that IP address isn’t for a specific customer, so there’s little point in disturbing further.

But…

…the app on my phone can control this thing, somehow. So let’s see what’s going on there!

Back on my gateway I ran tcpdump again. But while the lock wasn’t doing anything besides phoning home, a modern smartphone is one hell of a chatterbox. So instead of trying to make sense of the capture directly, I have tcpdump write the capture to a pcap-format file, and bring it back to my desktop and pull it up in wireshark — a sniffer with a graphical UI and some great analytics tools.

Patting-head-belly-rub: the trick here is to kill the app, start the sniff, launch the app and toggle a lock unlocked/locked (to whatever state it’s not in), stop the sniff and take a look-see:

OK — Allegion owns Schlage. Progress! Who’s this yonomi guy, tho? Back to the jazz-hands…

Aaaaah. Yonomi is a startup that provides a services for others who want to get into this IoT game, where they’ll do all the cloudy/security/etc stuff, and then the company uses their software in their devices. So Schlage doesn’t have to become expert in cloud/IOT stuffs overnight, can focus on what they know how to do and Yonomi will do the rest.

Connecting a few dots, Yonomi’s hosted on AWS, uses AWS IoT Core, and a few other services that I filtered out. Glad to see they’re not building their own wheels.

Now What?

Browsing the Yonomi site, blog, and GitHub repo I don’t see anything yet available for individuals to interact with their service. I did find a way to sign up for API access eventually on the site, identified myself as an individual and not somebody waving Benjamins, and soon got an email saying thanks, but not quite yet:

Conclusion

So hopefully the above is useful and entertaining/educational to some folks. It took me way longer to do this writeup than the actual work, but hopefully there’s enough thought-process and links above to give others ideas on how to do some research like this themselves — and maybe even help me push this further!

This isn’t fully solved yet, but I managed to find some useful info that I think is new information to the home-automation community:

Schlage went with an experienced partner to get their new WiFi locks to market quickly. It sounds like this project happened really fast with solid success, and now both parties are taking a breath and working on building out the integrations and ecosystems.
I’m a little iffy on the “newness” of Yonomi — I’ve avoided other home security startups because a) They’re often pretty sloppy about the security part, and b) I don’t like being stuck with broken hardware when they fold. Yonomi seems to have decent bones — been around about 5 years, Series A funded in part by Allegion (so if something does happen, I’ll put my money on Allegion keeping the service going), and decent list of customers so far.
Not rolling things from scratch: This is good on both Schlage and Yonomi’s sides. Yonomi more than likely knows IoT and cloud way better than Schlage, and I’ll guarantee that AWS knows how to securely run cloud services at scale way better than either of them.

Hopefully a public API coming later this year. I don’t see any hostility towards open source/individuals from any of the projects, so this looks like if they’re given some time an open source solution will come out, probably following the standard process that a HomeSeer user either grants oAuth access or generates an API key, gives that to a plugin in HomeSeer, and then we have lock control.

Once one of these systems are done, the functionality should arrive on the others (Vera’s mios comes to mind, maybe ISY?) soon after.

As I hear more I’ll either update this post or write a followup, and if I
have the bandwidth whenever access is available, I’m happy to write or help write/test the HomeSeer Encode plugin!

Previously published at https://theresnomon.co/the-current-state-of-api-access-to-your-schlage-encode-locks-7e981f404501