-
-
Notifications
You must be signed in to change notification settings - Fork 86
Fix accessory key drift #160
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
Conversation
Sometimes the key generation diverges for example if the accessory has no power. FindMy solves this be re-aligning the key generation if a btle connection is established. FindMy.app stores there alignment records in the `KeyAlignmentRecord` directory. This PR extends the FindMyAccessory class to read those records during `from_plist`-generation and re-sync the key generation by this
Add option to align FindMyAccessories key generation
1bdd4cd
to
f771ad9
Compare
dfa8fff
to
e992df7
Compare
BREAKING: due to fundamental issues with Apple's API, this commit also DEPRECATES the `fetch_[last_]reports` methods on Apple account instances. It has been replaced by a method named `fetch_location`, which only returns a single location report (the latest one) and does not support setting a date range.
Current status: a key alignment algorithm has been implemented that will automatically find correct alignment parameters when attempting to fetch the location of an accessory. If your accessory is unaligned, the first fetch might take some time, as the library will iterate through a bunch of different indices in order to find the correct values. After the first fetch, the values will be stored in the accessory object, and the next fetch after that will immediately use the correct values, meaning that only ~3 API requests are necessary in order to obtain a location. It is possible to further optimize this number in the future. Additionally, the in-library accessory importer has been updated to synchronize its initial alignment values with the ones that MacOS is keeping track of, meaning that 'new' accessories will immediately benefit from the aforementioned speed boost. This will also survive restarts, but only if the accessory object is properly (de)serialized to and from disk. New example code will show how to do that. This change comes with several API changes and deprecations, so it is currently not recommended to be used (yet). I will work on fixing any issues and updating the example scripts soon. |
closes #90