Thanks @mcnutter1
I uploaded it and then restarted HASS.
Upon restart I was able to find the new integration and add it.
Then it had a prompt (no words, just two empty blanks) where i put Login/Password for the Schlage lock.
Then I could see it under devices, but it did not work to control lock and lock was not responding from Schlage app either.
Pulled battery from lock and put it back in.
All seems well now!
Thanks a lot for all your work on this.
Not to sound greedy, but I would also love to get it out of the cloud if there was any way to do that too.
I had a think about this a bit today, and whilst we know the API calls the app is making we don’t how the lock is communicating.
So I set up a mitm proxy and connected the lock to the network, but unfortunaly I cannot see the https calls as the lock must be validating the certificate.
I am not sure how to get around this without modifying the firmware, unless anyone has any ideas?
Even if we were to redirect the DNS traffic as I suggested earlier, we need a way for the lock to trust the certificate we are using.
From memory when I first started looking at this, I don’t think the lock speaks HTTPS at all. I BELIEVE it was SSL/MQTT. I’ll have to take a moment to double check that though.
What is the motivation to hijack the cloud connectivity and do local control? I don’t think there is a real concern with the would-be burglar being sophisticated enough to undermine the authentication. Mostly everything IoT is cloud based because its easier to deploy fleets of devices to consumers and much easier to provide patches / software updates. Just curious as it seems the effort to override the cloud control would like be feature inhibiting.
Depending on the cloud means that our access could be revoked at any moment. See TP Link/ Kasa circa 2021.
They realized their mistake after public backlash but they still took away our access.
Same with Govee recently. There are threads on this forum with same outrage but then they realized their mistake and created a local API.
Not having to go through the cloud means you can still access your door through HA when your ISP is down but your local Wi-Fi is still up.
I personally wrote an email to Schlage and asked for a local API or an update and they said they had no interest at this time. I replied that if that were the case I had zero interest in purchasing more of their equipment in the future.
I urge anyone else to do the same to let them know it is a feature we want. The easiest way we can vote as hobbyists and enthusiasts are with our wallets.
I was able to redirect the mqtt calls to my local mosquitto server using this guide: Homewizard climate local MQTT control! but I cant get past the certificates unfortunately.
Thats assuming that the device actually validates it’s certs. I’ve found its semi common on embedded devices that they don’t. Its likely possible we could just generate a self-signed with the same info and it MIGHT work.
Well… Took a moment to play with it and it DOES seem to validate certs, or do some other form of validation. So no MITM on the MQTT connection until that can be sorted out.
I did notice that every once in a while the lock makes a plain http request to api.allegionengage.com. It seems to be looking for certificate updates. Did you see this? Might be a way to get a cert on the device…
Huh, interesting. So it does… A quick google suggests thats a access control product that supports multiple vendor’s doors for big building access. I’ll have to pcap what it’s doing and see if there’s any worth there.
Schlage is owned by a bigger company which also owns commercial lock companies… They are likely trying to move towards a single platform api and distinct product apis for individual apps / products.
Considering this lock is fairly new in the world of IoT/OT devices, I’d assume it uses off the shelf protocols which have SSL/TLS validation built in. The fact that they chose to use AWS Cognito for their auth vs rolling their own tells me their development teams are adept in securing access to their locks. They also use AWS IoT Core for the MQTT messaging which is TLS 1.2/1.3 by default.
From a business perspective, Schlage is looking to corner the market on rental share access (AirBNB) which is why they made this lock to begin with… so I think a cloud exclusive offering is all they will ever consider. Also from a business perspective, the market loves SaaS type companies and gives them a much higher multiple on valuation… Schlage doesn’t charge for any subscriptions as of now but they do sell a SaaS product which is set up for value add ons in the future which investors love. I think even if someone is able to figure it out, they would likely see it as a security concern and remediate whatever loophole was found very quickly.
@mcnutter1 Really appreciate the integration work. It installed perfectly for me and the locks now show up for use in scenes and everything else. Top notch!
Working great for me! Thank you for this! Question, I added it to my google home (assistant) for voice command functionality and it asked for a PIN. Where do I set this at?
The pin has to be setup in the Schlage app, under the “Works With” > menu. Then in Home app, you have to add Schlage in it’s Set up a device > “Work With Google” menu. May end up with duplicate locks, one from Nabu Casa (if you use that service) and one from Schlage directly.
I will say I don’t think this capability to unlock with Google Assistant has been around all that long, perhaps a recent Schlage update.
The pin doesn’t flow from Schlage app through the Home Assistant integration to Google Assistant currently, and doubt that’s even possible but the developer would have to chime in.
Can we add your repository via HACS and do it that way, does anybody know? I also thank all of you who got us this far. I’ve been checking back in for years. Come to think of it I wonder if my lock is actually compatible. I’ll go back and read some more. Mine is the schlage encode WiFi. I don’t think mine is the home kit compatible version. I was going to try and do something with Amazon key but it wasn’t clear if it was possible.
Yep, the Schlage Encode Wifi is what this is for… It PROBABLY works with any other Schlage locks that use the same app but I’ve not tested with anything other than the Encode Wifi.
Alright yep works pretty darn good. Thanks for this! Wish I could safeguard the functionality. I will add here b/c I had to look around a bit to get the instructions in this thread. Cant install with HACS so just place in custom_components folder in your config folder. Restart HA. Add integration…search schlage and add, then its a little rough around the edges but first space for your name and second your password. Played around with the entities that it created to for me as they were generic and hard to find. At long last! though this lock is integrated into home assistant. I feel so naive looking back thinking this lock was the way to go after the rough ride with an August lock which was bluetooth with the junkiest wifi bridge you have ever seen. Thanks again …hope schlage doesnt screw us around some more.
Hello! Is there a way to get the “jammed” status into home assistant? I’m currently using mcnutters home assistant integration for the schlage encode plus. I see that HomeKit shows when the door lock is jammed but home assistant only has locked or unlocked
That would be SUPER easy with my MQTT version, so it should be easy to do on Mcnutter’s version as well… I’m on vacation for Thanksgiving but I’ll see if I can get some pull requests in to add that to both versions.