-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Out of order pairing steps when using HomeSpan (async race condition?) #343
Comments
It sounds like pairing worked once and then you reset the esp but not the home assistant integration. So the existing pairing in ha is trying to establish a connection, but now you are trying to pair it again. So the device sees the results of 2 concurrent tasks - one trying to use the previous (stale) pairing, and one trying to make a new one. |
That would make sense but I also tested it after removing the HA
integration and even restarting HA, along with totally wiping the ESP and
starting "from scratch" with completely different device IDs etc. Even when
doing that process multiple times it still produces these random results.
The "already paired" issue is only one of the ways it fails. The other main
one is the issue shown here
![image](https://github.com/Jc2k/aiohomekit/assets/1985132/f098a451-d575-4ec8-acdf-dc3f2c6df20b)
Again, this can happen after resetting, rebooting, removing the integration
and starting over etc.
…On Sat, Nov 11, 2023 at 10:56 AM Jc2k ***@***.***> wrote:
It sounds like pairing worked once and then you reset the esp but not the
home assistant integration. So the existing pairing in ha is trying to
establish a connection, but now you are trying to pair it again. So the
device sees the results of 2 concurrent tasks - one trying to use the
previous (stale) pairing, and one trying to make a new one.
—
Reply to this email directly, view it on GitHub
<#343 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPEU3FYQN7S3F2O3CX3FM3YD6NZJAVCNFSM6AAAAAA7HKZIDKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWHA2TAOBUGQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Incidentally I did also try it on a completely different instance of HA on a different network at a different house and got the same issue the very first time trying to pair it. Just to be sure, what are the steps you would suggest going through to get the HA integration to stop trying to contact the device after removing it from the integrations page? |
The pair verify code path only happens when there is a pairing. It loads secrets from a config entry, and there is no config entry until pairing has happened. It would probably fill your logs with exceptions if it tried. That should mean that it'd be impossible to see pair verifys from ha if you removed the integration and then restarted ha to make sure it was gone. The restart shouldn't be needed but it's possible you've discovered an edge case where a faulty pairing can't be cleanly unloaded. |
We know there are ~28k installs of this integration, and this is the first time I can remember this behaviour coming up, and you can recreate it in 2 distinct environments. That makes me wonder if there is an environmental variable (eg we have had trouble with mdns repeaters in the past, and that's how paired/unpaired status is relayed, rather than via the api). We might want to examine logs from the zeroconf integration to make sure it's getting the right data there. Duplicate device ids could also be a problem and cause this kind of confusion. Hopefully they are automated by homespan and fully random so I wouldn't expect that to be a problem. |
Thanks for all this info. I also suspected network weirdness, which is why I tried it somewhere else with a super normal wifi/networking situation. And now that I'm thinking back maybe it did work fine the very first time in that environment and then had issues subsequent times.... hmm. I'll go away and try to do a more scientific set of tests and let you know! |
I tried just un-pairing and re-pairing from within HA a few times. When unpairing, it all works well, the HomeSpan devices sets itself back to unpaired etc, the integration disappears from HA. The device is immediately re-discovered by HA and I can re-pair no problem (MOST of the time), however it does put two things into the HA logs:
and
But as I said, the device is configured fine, and everything works as it should MOST of the time. Occasionally it will give the One intersting thing I noticed while looking at HomeSpan's debug logs is that even after I un-pair the device, and the integration vanishes from HA, the device is still receiving HTTP requests periodically like this:
Almost like HA is still doing things in the background even though the integration is gone. This still happens after I reboot the ESP device also. It wakes up and starts getting these requests. The IP ending If I restart HA in this situation, the HTTP requests stop, and they don't start again once HA is back up. After HA is back up, I try to pair and almost always get the "device is already paired", and I can see in HomeSpan's logs that HA is requesting to pair, pairing, and then requesting to pair a second time, resulting in the error. The second set of tests I did also involved wiping the ESP device and having it re-generate a new unique device ID. Each time I did this, I also restarted my HA instance to get rid of any cached zeroconf discovery things. This seemed most successful when I wiped the ESP and also powered it totally off during the HA restart. Even then, sometimes there was a device "detected" by HA. Definitely seems like some mdns/zeroconf things maybe? A couple of times I got this, if that helps.
|
It looks like HA isn't fully shutting down the connection when its unpaired. |
Is there anything I can do to confirm that @bdraco ? |
If it's still doing pair verify after removing the integration and stopping after a restart then it's pretty much confirmed. It's probably not been a problem before because most users add it once and don't need to remove it and add it again. |
OK should I report this to HA then? What's the next thing to do for this issue? |
No reporting it there would just ping the same people that you are speaking to here :) Just need to wait for someone to have time to look into it. |
Haha ok no problem! Thanks for all your responses |
Hey there! I have definitively confirmed that this can happen if the device is brand new and has never been paired with HA. Also this was on a completely fresh HA that has never paired any devices before. So it seems like it's not just pair-unpair scenario from above. |
To be clear I think that HA DOES continue to send messages to the device after unpairing it (sometimes), but it can ALSO fail on totally fresh pairing. I think they are related but separate bugs. The logs from the "fresh" scenario are identical to the ones I provided already - seems like multiple threads both trying to pair at the same time for some reason. I've never had to debug anything this deep in HA before, but I'm going to try the dev env set up locally and see if I can do anything. |
HomeSpan is a library for ESP32 devices to enable them to speak HomeKit. After a huge amount of tests, it seems that when pairing these devices with Home Assistant via the HomeKit Device integration, pairing intermittently fails in a variety of ways.
04
I've included a massive amount of logs in my original HomeSpan bug report, but the description of what's happening from the devs makes it sound like there's some sort of race condition in aiohomekit which is causing the pairing steps to happen in a random order (nondeterministically).
The HomeSpan issue link is here: HomeSpan/HomeSpan#680
but the important part I think is here:
Could this be a bug in aiohomekit? Or maybe the Home Assistant integration itself? HomeSpan devices always pair flawlessly with "real" HomeKit controllers (e.g. via the Home app) and claim to be fully compliant with the spec, so I'm not sure what's going on
The text was updated successfully, but these errors were encountered: