Connection is successful, but Apple always returns "0 reports"

[lequan2909]

Bug Description

• App Version: 1.0.4
• ZIP Export Method: Docker-OSX with macOS Sonoma 14
  After a complete and clean setup, the app authenticates successfully but is unable to display any locations for my AirTags. The logs consistently show that the app successfully fetches reports from Apple's servers, but the result is always "Got 0 reports".

This happens even after creating a fresh .zip export and ensuring the AirTag's location is visible and up-to-date in the official Find My app on an iPhone.

Key Findings

• There are NO authentication, DNS, or other connection errors in the logs.
• The self-hosted Anisette server (via Docker and Cloudflare Tunnel) is working correctly. This has been verified by accessing the server via its public URL and its direct local IP address.
• The app successfully authenticates, fetches, but receives an empty data set from Apple.

This suggests the issue may be a change in the Apple API that the underlying findmy.py library is not currently handling, rather than a setup or user error.

Relevant Log Snippet

`log
D/MapsActivity: Preparing to fetch location reports for the last 24 hours!
I/python.stdout: num_items is 2
I/python.stdout: Fetching report for 48B8216B-4849-4CCF-BA75-877483CA1446 for the last 24 hours...
I/python.stdout: Got 0 reports for 48B8216B-4849-4CCF-BA75-877483CA1446
I/python.stdout: Fetching report for 050ACADF-DB12-47F1-A251-8B76EAEE88AE for the last 24 hours...
I/python.stdout: Got 0 reports for 050ACADF-DB12-47F1-A251-8B76EAEE88AE
D/MapsActivity: Did not get any location reports for beacon device with id 48B8216B-4849-4CCF-BA75-877483CA1446. This device will not be shown in the UI.
D/MapsActivity: Did not get any location reports for beacon device with id 050ACADF-DB12-47F1-A251-8B76EAEE88AE. This device will not be shown in the UI.
W/MapsActivity: Fond a beacon (48B8216B-4849-4CCF-BA75-877483CA1446) with no location history items! We can't draw such a beacon. Skipping...
W/MapsActivity: Fond a beacon (050ACADF-DB12-47F1-A251-8B76EAEE88AE) with no location history items! We can't draw such a beacon. Skipping...
I/MapsActivity: Finished visualising new location reports!

[parawanderer]

Hi @lequan2909, thanks for the thorough report and investigation!

I think one more possibility is related to this:
#30

This rotation mechanism in the current version of the FindMy.py library used in the app makes it so that some location updates end up not being locateable for tags that had their internal timer start to drift.

One thing you could do to deal with this for now is disconnect and reconnect the tags via your iOS device, which should reset any drift issue.

That task and subsequent fix (which is now pending on somebody else releasing a related tool, see that issue's page for details) might address this problem entirely

[lequan2909]

Hi @lequan2909, thanks for the thorough report and investigation!

I think one more possibility is related to this: #30

This rotation mechanism in the current version of the FindMy.py library used in the app makes it so that some location updates end up not being locateable for tags that had their internal timer start to drift.

One thing you could do to deal with this for now is disconnect and reconnect the tags via your iOS device, which should reset any drift issue.

That task and subsequent fix (which is now pending on somebody else releasing a related tool, see that issue's page for details) might address this problem entirely

[lequan2909]

Hi, I've followed the suggestion to remove and re-add the AirTag on my iPhone. This generated a new
beacon ID (D6869BCE-...).

I then created a fresh .zip export, cleared the app data, and imported the new file.

Unfortunately, the result is the same. The log shows a successful connection, but Apple's servers still
return '0 reports' for the new beacon ID. This seems to confirm the issue is with the underlying
library's ability to fetch reports, not a timer drift issue.

Please see the new log attached.

OpenTagViewer-1758707774602.log.txt

[parawanderer]

Interestingly enough, on my side I am still receiving updates to my tags. @malmeloo do you have any idea if your recent changes to FindMy.py might fix this type of issue? The app is currently still running a pretty old version of the library

[malmeloo]

I'm 90% certain that this is the known key drift issue, in which case the new version of the library will fix it. To test if that is indeed the problem you can re-pair your airtag and then re-export it, if it works then it's a key drift problem.

[parawanderer]

Okay so I do remember one more thing that might be affecting you here.

The app currently only shows you reports from the Apple FindMy network itself, not actually anything from the local area Bluetooth scan. However, you will only get new reports in the Apple FindMy network when your tag ends up in the "disconnected from parent device" state and starts broadcasting this fact to any nearby Apple device passing by. It will not do that if it stays in the "connected to parent device" state.

The reason the Bluetooth scan was not implemented in the version of the app that you currently have -- 1.0.4 -- is that at the time there was this bug which is the same as this bug that is now fixed in the newer version of FindMy.py (thanks again @malmeloo 🙏). It's issue 1 in this list of issues on the README of this project. The main reason I didn't implement it at all is because I had no tag that seemed to work with the library at all out of 4 of them, and hence couldn't test it, and subsequently couldn't easily implement and validate any UI logic around possible logic/outputs.

So I think that basically you'll have to wait on this chunk of work to get done: #30 and once that is done the app will be fully functional. And that chunk of work is semi-blocked by OpenBubbles/rustpush#18 . I could work on it without that tooling being available, but that would require some thinking of how to handle all this moving forward.

I will come back to this in a week or two and see where the status of that is at, and if it hasn't moved yet consider next steps (either learn enough rust to make that tool usable myself or deal with the options that are currently supported).

For now, I think that you should get some FindMy network reports added to the UI eventually, whenever your tags end up hitting that disconnected state and you pass by an Apple device probably. But you'll just end up missing quite a lot of local-area details.

[lequan2909]

Hi, thank you for the detailed explanation about the 'disconnected state' and the limitations of local
Bluetooth scanning in v1.0.4. It was very helpful.

Following your advice, I performed the full reset process (re-pairing the AirTag, creating a new ZIP,
clearing app data). Initially, this was successful and I could finally see the AirTag's location in
OpenTagViewer!

However, I have discovered a new, more specific issue. I tested this further:

1. I took the "working" AirTag outside, leaving its parent iPhone at home. The AirTag was now in a
   'disconnected' state and should be broadcasting to the Find My network.
2. I used a different iPhone with a different Apple ID to view the area. The official Find My app on
   this second iPhone could see the AirTag's updated location correctly. This proves the AirTag was
   broadcasting and its location was available on the Find My network.
3. At the same time, I refreshed OpenTagViewer. The app connected successfully (no errors in the log),
   but it returned "0 reports" and the location did not update.

This seems to confirm that even when a fresh "Network Location" report is available on Apple's servers
(and visible to the official Find My app), the findmy.py library is unable to retrieve it and receives
an empty data set instead.

This confirms the issue is likely with the library's interaction with the API, as you suspected. Thanks
for looking into this, I'll be waiting for future updates on issue #30.