The token call is synchronous, for HASS to not block the main event loop it needs to be async.
I have your code ported into a direct hass integration with support for multiple locks but I can’t figure out how to make the token request async. I tried aioboto3 but it doesn’t support cognito.
Ahh, yeah that part is… Hmmm. I’ll put some thought into how to deal with that. Shouldn’t be TOO hard to make happen.
I solved the AsyncIO issue, but it seems like there is some weirdness with the lock/unlock commands. There isn’t an instant result sent to the lock, instead its a minute or so later… does the app api send the same request over and over or something to wake the lock up?
Also, first version of the hass integration here: GitHub - mcnutter1/homeasssitant-schlage: Schlage Encode implementation for Home Assistant… Supports multiple locks, lock/unlock (with the observed delay)… Setup through the UI… no error checking / handling so check logs and post if anything doesn’t work.
Also,
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.
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.
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.
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.
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 
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.
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.