Skip to content

Add option to align FindMyAccessories key generation#125

Merged
malmeloo merged 3 commits intomalmeloo:fix/accessory-key-driftfrom
pajowu:pajowu/aligment
Aug 7, 2025
Merged

Add option to align FindMyAccessories key generation#125
malmeloo merged 3 commits intomalmeloo:fix/accessory-key-driftfrom
pajowu:pajowu/aligment

Conversation

@pajowu
Copy link
Contributor

@pajowu pajowu commented Apr 15, 2025

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

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
@malmeloo
Copy link
Owner

That's really cool, thank you for taking the time to implement this! I had no idea Apple made it so easy to retrieve sync data.

To what extent did you test this? My own setup is a bit flaky at the moment, but if you tested it extensively then I'm happy to merge it. Fetching reports before the lastIndexObservationDate still works, correct?

@pajowu
Copy link
Contributor Author

pajowu commented May 23, 2025

I only tested it a bit and not with reports before the lastIndexObservationDate. I'm unsure what the behaviour here should be. Should it just assume that for all dates before that, the calculation is done relative to the sync date? Or should it use the paired_at timestamp for dates before the sync? Or use the one that is closer? Or both? The code currently calculates relative to lastIndexObservationDate, which IMHO is the right choice, as this is the latest known correct (timestamp, index)-mapping we have

@malmeloo
Copy link
Owner

Yeah I think you're right, the index doesn't just "jump" on its own so the last known good mapping is probably the best reference point. As long as it's roughly correct it should be fine anyway, since that ~12hr margin is still used when making requests.

I'll merge this once I find some time to work on the library again, the changes should be backwards compatible anyway so no existing features should break because of it.

@malmeloo malmeloo changed the base branch from main to fix/accessory-key-drift August 7, 2025 18:35
@malmeloo malmeloo merged commit 64347b9 into malmeloo:fix/accessory-key-drift Aug 7, 2025
8 checks passed
@malmeloo
Copy link
Owner

malmeloo commented Aug 7, 2025

Sorry for taking a while to review this. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants