-
Notifications
You must be signed in to change notification settings - Fork 104
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
Decryption error/Connection lost on ESP32 with multiple Apple devices running Home #14
Comments
@Brawrdon , can you give some more information about your network, specifically with regards to number of iOS devices linked to the same Apple account? I see multiple socket fd numbers in the log (51, 52, 53) and so was wondering which session is getting closed. Please also apply this small patch which would also indicate the session being closed and check again
|
@shahpiyushv I currently have four which are signed into my account with access to Home. When I pair it with my iPhone it sends: I've attached the full log. |
If I disconnect every other device and just have my iPhone connected it appears to work (doesn't go unresponsive after about a minute). It does however, throw the error the minute I reconnect any other device to the network. There's no log of the second device pairing or creating a socket session, just |
@shahpiyushv Thanks for the help!
Nothing seems to change, the error still occurs when I have multiple devices connected. |
I think I discovered the issue and a potential solution! I stumbled upon an issue with a HomeKit library for the ESP8266 (Mixiaoxiao/Arduino-HomeKit-ESP8266#9) that seemed to be identical to mine; the mDNS services were being removed just before the device disconnects. I hacked in the solution proposed on the issue, which was to re-announce the mDNS service every five seconds, by calling I'm assuming by adding a timed function to just call I'm not that experience with mDNS or the HomeKit Accessory Protocol so I can't think as to why this is a thing... Though, the owner of the library for the ESP8266 did mention two cases they found for when the iOS device disconnects. |
@Brawrdon , since reachability of HomeKit accessories depends on mDNS, which is a UDP based protocol, there is indeed a high chance of accessory seeming unreachable just because of a few missed packets in a noisy environment. The solution you have mentioned could indeed work. However, Apple's Bonjour Conformance Test does not allow unsolicited mDNS announcements. In fact there is a specific test just to ensure that the accessory does not make any mDNS announcements for at least a couple of hours, if there is no query. Of course, the solution could still be fine for hobby projects, but not something we can add ourselves, since we want to keep this SDK in sync with the MFi variant of the SDK. Meanwhile, the purpose of state number (s#) is to let controllers in the network know that something has changed on the accessory. This triggers a GET request from the controllers or a session re-establishment (in case it was broken for some reason). |
@shahpiyushv Thanks for the explanation! My solution seems to only slightly increase the time until the error occurs, the device lasts about half an hour before the same error shows up. Guess I'll have to leave it up to you to see if a proper solution can be found 😭 |
@Brawrdon Do not forget that there is another side of the issue - iOS controller / HomeKit hub (or especially in case there is more than one hub). This side is still in evolving stage. I am pretty sure that some of the answers behind “No response” issues are hidden there. |
Which issues are you referring to exactly? |
As far as I understood “Decryption error/Connection lost” you have mentioned is followed by accessory unavailability or famous “No response” status, that has million reasons to appear. |
@AramVartanyan I think I've pinpointed the cause of the issue to having multiple devices connected to the ESP32 via iCloud. The demos appear to work fine when I turn all the other devices onto aeroplane mode and disconnect them from the network. Three devices are on the latest version of their respective OS whilst one isn't. I'm gonna see if it has something to do with that by disabling the device running Catalina. They may have changed something, like you said, which the Catalina device doesn't understand and so causes a panic! If that doesn't work I'm gonna try take a look at the packets via Wireshark. I've been having an issue sniffing packets from my ESP32 via my Mac but that's an entirely separate problem. Also might be worth mentioning that I have my iPad enabled as a hub but I don't think that's an issue since the devices have always been on the same network. The main controller is an iPhone XR running iOS 14.3.
I'm assuming you used Wireshark to do this or does this info show up on the logs? |
I think I've solved it! Tldr: I had to reboot my router... 😖 Basically, whilst trying to setup Wireshark to sniff packets between my ESP32, I noticed that I couldn't access machines in my LAN when connected to certain SSIDs (I have multiple SSIDs on one router to separate my IoT stuff). I have no idea why but certain hosts, such as when trying to access my Raspberry Pi, weren't being forwarded. I assume that included ones to my ESP32, which probably caused my devices to go "well I can't see this host guess I'll shut it off". Simply rebooting my router to fix whatever went astray has stopped the ESP32 from disconnected even with multiple devices connected via iCloud. I'm gonna close this issue now, thanks for the support guys! Moral of the story, always try turning things off and on again 😅 |
You can understand much better the issues if you just activate the debugging messages. |
For "Decryption error/Connection lost on ESP32 with multiple Apple devices running Home" , espressif/esp-homekit-sdk#14
I'm getting a similar issue as with issue #4 when trying to run the fan example on my ESP32 DevKit v1. It works for about a minute before the accessory becomes unavailable and it returns an error marking the session as invalid. It also doesn't seem to automatically restart (I'm assuming it did in the linked issue because of how their logs looked).
I've tried the recommendation of adding
CONFIG_NEWLIB_NANO_FORMAT=n
to the sdkconfig.defaults file with no luck.The text was updated successfully, but these errors were encountered: