I’ve experienced this as well from time to time. As far as I’ve seen so far the app doesn’t seem to repeat the request but I’ve not dug into it deeply. Weirdly I’ve noted that if I go pull the battery on the lock and put it back in it’ll respond instantly for some amount of time before slowing down to responses again. Its on my list to find a solution for since that could potentially be a security problem if you think the door has locked but it hasn’t.
OK Thanks, let me know what you find… feel free to try the integration i wrote and let me know.
1 Like
Now that 2022.10 has been released, HAP over Thread is enabled by default. If someone with a Thread-capable model + a border router + device is already paired to iOS Home (i.e., a functional Thread network) is interested in trying that route, simply unpair the device from the iOS Home app. If it doesn’t immediately show up as a discovered device in HA, you may need to power cycle (NOT factory reset) the device. I’d be very curious to know how it goes. You can DM me for help or comment in the HAP over Thread thread.
1 Like
Lamda,
I’m on the road this week but when I get back home next wednesday, if someone hasn’t beat me to it I will try this out and report.
1 Like
Not to sound too stupid, but is there a guide for installing this integration?
Download the zip from GitHub and put it in a folder in custom_components, restart hass and try and add it from the devices page.
1 Like
Thank you so much to everyone who has contributed to getting this working. It is the best progress we have had for this lock in over 2 years!
I am wondering the possibility (as the next step) of getting local control working? I think it would be very difficult to hack the firmware of the lock, so I am thinking you would need to redirect the API calls from the lock via DNS to a local mock API integration in HA.
Essentially you enable the Dnsmasq add-on and redirect api.allegion.yonomi.cloud to your local ip for the locks mac address only. Use Dnsmasq as your routers primary DNS.
Then the integration would need to respond to the locks api calls appropriately. Now that we know how the lock is making the calls, perhaps its possible? Eventually, the integration could also talk with the yonomi cloud, and relay to the lock, if you still wanted to use the main schlage app outside the house.
Has anyone seen this achieved with other HA integrations and devices?
In theory its possible, that would be fantastic as local control is always better than cloud… If I can find a moment I’ll poke at that as well since that would be super nice. I’ve got a to-do list for this app when I find my next block off free time to code 
2 Likes
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.
1 Like
You are correct, looks like it is communicating mqtt on port 8883 over TLS to xxxxxxxx.iot.us-west-2.amazonaws.com
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.
If anyone has any luck or ideas please share.
I think to get past the certificates you would somehow need to install a trusted root on the device itself and MITM every call…
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…
1 Like
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.
Here’s an article from 2 years ago from someone who poked around at getting in the middle of the MQTT: The current state of API access to your Schlage Encode Locks | by John Kinsella | There’s no m on .co
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.
1 Like