Schlage Encode Wifi

Feature Requests
61

Hello, All -

I am happy to say that I have some positive conversations open with Yonomi to allow this integration to happen officially, and without any reverse engineering. They provide a platform for integration between a growing number of cloud-connected devices, and they are also the people who actually developed the API and cloud platform for Schlage.

Later, Schlage’s parent company Allegion actually acquired Yonomi, so they are now under the corporate umbrella.

Please checkout my post here - Yonomi Integration (For devices such as the Schalge Encode WiFi) - #6 by dmrichards26

7 Likes
62

The whole cloud things is such a shame…the idea that my internet should be up to use my door lock is absurd (I know I’m preaching to the choir here).

I certainly empathize with the idea of ongoing costs for cloud but I would argue the reverse engineering of the protocol continue, why? Because they chose the cloud for this lock, and they chose some open ended unstated future agreement to continue to support it until when?

I didn’t sign up to have to pay at some point in the future due to their lack of understanding that cloud costs will continue to eat at them for every unit sold.

As we’ve already seen time and time again a vendor will support a cloud option until they either have to charge or are tired of the bleeding and then you have a brick.

Until there is a way to locally control this lock, I’d rate it as a “Don’t Buy” one executive can decide it’s too much and now I’m renting my lock from them just to unlock my door…

6 Likes
63

@dmrichards26 have you gotten any progress ?

64

I 100% agree. One of the biggest reasons why I chose to start an HA instance was to keep things off the cloud as much as possible. Hopefully, someone does end up completely reverse engineering the protocol.

3 Likes
65

I just wanted to chime in to say thanks for this thread! With the info provided, I reverse engineered the API to get this working… It logs in with Amazon Cognito user pools, which I’ve managed to fab up a roughly working app in Python to login with your creds from the Schlage app, get info from the lock, get lock state and toggle the lock. I’m currently cleaning it up to make sure I don’t have anything tied directly to my account before tossing it up on Github for anyone to tinker with.

5 Likes
66

Awesome work!

To add to this:

I’ve been following along the Thread integration through Homekit controller. And while I don’t have my system up and running yet, while sniffing through the HA logs, I confirmed that my Encode Plus was hitting my system via zeronconf broadcasts.

For those who have the Encode Plus version that works with WiFi and Thread, follow the post below for updates on the Thread front. They are making great progress and should have it working sometime in the September release ( at least that’s what I took from it)

So hopefully if what you are working on works out, there will be thread support for it as well.

67

@mrdj863 interesting, I was wondering if there were any devices besides Nanoleaf using HAP over Thread currently. What is it broadcasting? _hap._udp?

68

Wow surprised to see you on this thread lambda.

Actually in the code block that you were helping me troubleshoot that I posted on your thread, there is a cluster of Nanoleaf bulbs and in between it is Encode Plus, which is this lock.

I didn’t get a chance to work out my IPv6 settings on my ubiquity network but when I’m home next week, I plan on digging deeper.

Looks like hap.udp

2022-08-23 20:27:52.102 DEBUG (MainThread) [homeassistant.components.zeroconf] service_update: type=_hap._udp.local. name=Encode Plus._hap._udp.local. state_change=ServiceStateChange.Updated
2022-08-23 20:27:52.103 DEBUG (MainThread) [homeassistant.components.zeroconf] service_update: type=_hap._udp.local. name=Nanoleaf A19 7BSK._hap._udp.local. state_change=ServiceStateChange.Updated
2022-08-23 20:27:52.103 DEBUG (MainThread) [homeassistant.components.zeroconf] Discovered new device Encode Plus._hap._udp.local. ZeroconfServiceInfo(host='fd54:6e34:1e50:0:ecc5:dea1:f1c9:609d', addresses=['fd54:6e34:1e50:0:ecc5:dea1:f1c9:609d'], port=5683, hostname='Encode-Plus.local.', type='_hap._udp.local.', name='Encode Plus._hap._udp.local.', properties={'_raw': {'c#': b'1', 'ff': b'1', 'id': b'C8:15:DD:9E:F2:31', 'md': b'be499WB', 'pv': b'1.2', 's#': b'7', 'sf': b'0', 'ci': b'6', 'sh': b'VYYK3A=='}, 'c#': '1', 'ff': '1', 'id': 'C8:15:DD:9E:F2:31', 'md': 'be499WB', 'pv': '1.2', 's#': '7', 'sf': '0', 'ci': '6', 'sh': 'VYYK3A=='})
2022-08-23 20:27:52.104 DEBUG (MainThread) [homeassistant.components.zeroconf] Discovered new device Nanoleaf A19 7BSK._hap._udp.local. ZeroconfServiceInfo(host='fd54:6e34:1e50:0:d179:d25a:4f37:5d36', addresses=['fd54:6e34:1e50:0:d179:d25a:4f37:5d36'], port=5683, hostname='Nanoleaf-A19-7BSK.local.', type='_hap._udp.local.', name='Nanoleaf A19 7BSK._hap._udp.local.', properties={'_raw': {'c#': b'2', 'ff': b'2', 'id': b'35:F9:9C:95:D5:B9', 'md': b'NL45', 'pv': b'1.2', 's#': b'91', 'sf': b'0', 'ci': b'5', 'sh': b'vW6VBA=='}, 'c#': '2', 'ff': '2', 'id': '35:F9:9C:95:D5:B9', 'md': 'NL45', 'pv': '1.2', 's#': '91', 'sf': '0', 'ci': '5', 'sh': 'vW6VBA=='})
69

Yep, that should work with my HAP/Thread code. The tricky part is getting HAP devices on a Thread network without pairing them. If the ZC property sf is 0, the device is already paired and cannot be added to HA. HAP/BLE was also released in 2022.8 which may be worth a try.

EDIT: Someone should try removing the device from the Apple Home app & see if the lock sticks around on Thread (advertising _hap._udp but with a new ID). If so, congrats, it is now pairable with HA.

70

@punk-kaos Great news, I got stuck on the auth and gave up… Happy to test, I have 5 Encodes and would love to have them in HASS.

71

Yeah, that Cognito auth is kinda rough, but thats good for security. And it doesn’t help that some of the data is hard coded in the APK, luckily it all was there when I de-ODEXed the APK.

I’m leaning towards making it an MQTT bridge, as that’ll work for lots of automation platforms. I’ll toss something out fairly soon if my day is slow today.

72

Ok, this is really dirty right now but it does work… Most of the time.
Put your app username and pass in at the top, then run.
It will output the current lock state to the console, then attempt to lock the door(You can change it from lock/unlock in the call near the bottom) then it will sleep 10 seconds and query the state again.
It does work, it toggles the lock HOWEVER it doesn’t always seem to do it consistently and I’ve not yet figured out why that is yet…
Once I do I plan to wrap it in an MQTT lib so it’ll talk nicely to anything you like via MQTT but I have to sort out why its being cranky first. I’m open to suggestions!

3 Likes
73

Well… After powercycling my lock it seems to be working perfectly. I’m gonna test a bit more but that intermittent issue might have been totally with the lock itself.

74

Just tested, worked to lock my lock without any changes to the code (just creds).

I have multiple locks so will likely have to iterate through the device list and sort each lock into an object.

75

Awesome! Nice to see confirmation I’m not crazy!

Yeah, it assumes right now that there’s only one lock for simplicity. Once I flesh it out a bit I’ll have it check for multiple locks. Its already pulling the first lock ID so it has the tools needed.

76

Had a couple more minutes to play with code, I wrapped it in an MQTT wrapper, it now will connect to an MQTT broker and provide lock status updates every 30 seconds as well as accept lock/unlock commands via MQTT. That should be enough to get it working in most home automation frameworks!

1 Like
77

Any plans to make it a full on integration in HASS?

78

Truthfully I don’t use HASS. I’m on OpenHAB, I just stumbled in here looking for info on the Schlage API via Google when I got frustrated with how little ability to integrate with it there was. This was just the only source of bread crumbs on what it was doing internally that I could find so when that was enough for me to crack the code I wanted to pay that info back with some working code.

All that to say, probably not because I’d have to learn HASS. But you never know…

1 Like
79

Thats fine, I can build it… didnt want to do double the work.

1 Like
80

Works for me! I’m happy to provide any support I can, just let me know!

1 Like