Reports only returned for single key

[alfs]

I'm periodically (about every 30 minutes) collecting location for dozens of tags. I save the last found index of the key + date, and from there calculate key ranges for all tags and fetching all reports in one call.

This worked well for several months in the spring, until late May when it suddenly stopped and I got few, if any, reports.

I'm now investigating the issue, and it seems reports are gotten for a singular key.

To test this, I have isolated two keys that successfully return location reports individually.

I have an adapted script of examples/real_airtag.py, where the central part is:

    logging.debug(f"1: Keys to fetch: {list(kdict.keys())}") 
    reports = acc.fetch_last_reports(list(kdict.keys()))
    logging.debug(f"2: Actual reports: {reports} ")

First tag, fetch_last_reports for a single key:

DEBUG:root:1: Keys to fetch: [KeyPair(name="None", public_key="0y/hZ8LvS8i5z+xc6fYbO6Bdt1DuxIbheq70sA==", type=KeyType.SECONDARY)]
DEBUG:root:2: Actual reports: {KeyPair(name="None", public_key="0y/hZ8LvS8i5z+xc6fYbO6Bdt1DuxIbheq70sA==",
 type=KeyType.SECONDARY): [KeyReport(hashed_adv_key=XXX, timestamp=2025
-08-23 07:25:21+02:00, lat=XXX.3754753, lon=XXX.4790295),
...

20 reports received

Second tag, only fetching for one key:

DEBUG:root:1: Keys to fetch: [KeyPair(name="None", public_key="njEfiCm9Cdth9jJPwDiPTvyzFskGt8ZPXng0nw==", type=KeyType.SECONDARY)]
DEBUG:root:2: Actual reports: {KeyPair(name="None", public_key="njEfiCm9Cdth9jJPwDiPTvyzFskGt8ZPXng0nw==", 
type=KeyType.SECONDARY): [KeyReport(hashed_adv_key=YYY, timestamp=2025-08-23 03:09:38+02:00, lat=YY.3758003, lon=YY.4768694),
...

(again 20 reports received)

However when querying with both keys, one of them (0y...) has an empty set of reports:

DEBUG:root:1: Keys to fetch: [KeyPair(name="None", public_key="0y/hZ8LvS8i5z+xc6fYbO6Bdt1DuxIbheq70sA==", type=KeyType.SECONDARY), KeyPair(name="None", public_key="njEfiCm9Cdth9jJPwDiPTvyzFskGt8ZPXng0nw==", type=KeyType.SECONDARY)]
DEBUG:root:2: Actual reports: {KeyPair(name="None", public_key="0y/hZ8LvS8i5z+xc6fYbO6Bdt1DuxIbheq70sA==", 
type=KeyType.SECONDARY): [],
KeyPair(name="None", public_key="njEfiCm9Cdth9jJPwDiPTvyzFskGt8ZPXng0nw==", type=KeyType.SECONDARY): [KeyReport(hashed_adv_key=YYY, timestamp=2025-08-23 02:46:39+02:00, lat=YY.3758003, lon=YY.4768694),

I can work around this by iterating fetch_last_reports for each tag, but it increases the number of connections and, perhaps, increase the risk of account ban.

Another observation, before May I also received old location reports, for up to a week. Now it seems limited to the last 20 reports.

Have you noticed the above? Can you successfully get reports for multiple tags in the same report-fetch?

[malmeloo]

This is a known issue which should be fixed on the main branch. Apple changed it to only fetch up to 20 reports per tag, but their old API only allows fetching a single tag at a time (officially). The new API still only returns 20 reports per tag, but it should fix the issue with requesting multiple tags at once.

My plan is to release a new version soon ish (few weeks max), but you can also install the current version from the main branch. It should be pretty stable already.

[alfs]

Aha, thanks. I just got the latest main branch, tested real_airtag.py with one of the plist files, it worked almost (see * below) and returned 20 reports.

I also tested the integrated Anisette and it worked as intended, now I can skip the separate service running, great feature.

I'll refactor to the new branch and just iterate over the tags then, and see later how the new api will work for multiple requests.

• I had a small error:

 % python3 real_airtag.py ../../../run/tags/testtag.plist
Traceback (most recent call last):
  File "/Users/sa/dev/build/FindMy.py/examples/real_airtag.py", line 65, in <module>
    sys.exit(main(sys.argv[1]))
             ^^^^^^^^^^^^^^^^^
  File "/Users/sa/dev/build/FindMy.py/examples/real_airtag.py", line 36, in main
    airtag = FindMyAccessory.from_plist(f)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/sa/dev/build/FindMy.py/findmy/accessory.py", line 231, in from_plist
    master_key = device_data["privateKey"]["key"]["data"][-28:]
                 ~~~~~~~~~~~^^^^^^^^^^^^^^
TypeError: '_io.BufferedReader' object is not subscriptable
       0

Claude 4 proposed the following patch, which made reading the plist work for me.
I don't want to submit a pull request with possible AI-crap, but I think you can spot the real problem/fix better than me.

--- a/findmy/accessory.py
+++ b/findmy/accessory.py
@@ -222,9 +222,13 @@ class FindMyAccessory(RollingKeyPairSource, Serializable[FindMyAccessoryMapping]
             device_data = plistlib.loads(plist)
         elif isinstance(plist, (str, Path)):
             device_data = plistlib.loads(Path(plist).read_bytes())
-        elif isinstance(plist, IO):
+        elif hasattr(plist, 'read'):
+            # File-like object (more reliable than isinstance(plist, IO))
             device_data = plistlib.load(plist)
+        elif isinstance(plist, dict):
+            device_data = plist
         else:
+            # Last resort: assume it's already parsed data
             device_data = plist
 
         # PRIVATE master key. 28 (?) bytes.

[alfs]

... and now I see this plist problem was patched in #146 (but not yet merged :) )

[malmeloo]

Ah yes sorry, I almost forgot about that PR :^). Merged!