Understanding the contents/structure of the export zipfile?

[victorhooi]

I ran the Export Tool successfully, and I was able to download the zipfile.

However, I was just curious about the structure of the exported zipfile

At the root, there are two directories, and a YAML file:

• BeaconNamingRecord (directory)
• OwnedBeacons (directory)
• OPENTAGVIEWER.yml

Under OwnedBeacons, there are plist files (e.g. 02F97F84-6B05-4CCD-8DDC-8FE1D48ABA05.plist) - these are I believe the output that you want to use (e.g. for using with FindMy.py's plist_to_json.py).

However, there's doesn't appear to be any human-friendly identifiers in the .plist file - just the UUID in the filename. Is that the only unique identifier?

There's also the BeaconNamingRecord, which seems to have one sub-directory for each UUID, then a .plist file in each of those directories. And there is a friendly name in these files 😁.

How are the BeaconNamingREcord files related to the OwnedBeacon ones? As in, are they obtained differently? And is there a reason they're separated out like that?

And what's the OPENTAGVIEWER.yml file used for?

[parawanderer]

Hi so this tool is specific to my app "OpenTagViewer", rather than to FindMy.py, FindMy.py only used the OwnedBeacon files. I'm not really sure what exactly the latest version of FindMy.py uses as I know it does some kind of conversion step and needs more data for determining the "alignment" for the key circulation mechanism. That's where that JSON format comes in that you mentioned.

The output format of this OpenTagViewer export tool was not really designed for FindMy.py specifically and contains files irrelevant to FindMy.py, that's probably where confusion might be coming from.

The other non-OwnedBeacon files are used in this app and contain metadata about export dates and UI-data like the names of the tags. This is stuff that my app is interested in. A file in BeaconNamingRecord is currently meant to be one-to-one to a file in OwnedBeacons. BeaconNamingRecord contains actual human-defined UI identifiers, OwnedBeacons indeed only contains machine information.

The weird nested structure comes from Apple, that's how they're stored on the MacOS disk while they are encoded. I decided not to touch that.

[parawanderer]

I think for your use case you might be more interested in the CLI tool, if you haven't seen that already. You can get it to just decode all the files that way and not do any renaming magic or include any extra metadata for this app.

But long term I'd refer you to this solution:
#30 (comment)

Which should just make everything less bad for everybody including app users here and FindMy.py library users who have no interest in this app

[victorhooi]

Oh neat! I didn't know about the CLI version.

Is that CLI version essentially equivalent to the GUI-based export wizard then?

And about the alignment stuff - when I used FindMy.py, it did seem to spend a lot of time trying to figure out the indexes - do you know what in your export is meant to be used to figure out that alignment, or is there some special step you need to do to speed it up?

[parawanderer]

So the GUI tool only exports what my android app needs, which is what an older version of FindMy.py needed, which excludes any alignment info. It basically misses a bunch of folders among which the alignment one. The CLI with the example options from the readme is equivalent-ish to the GUI tool in terms of which files it decodes and which files it skips.

The CLI tool happens to have a flag --all that just makes it decode all files and not just the ones my android app needs, which should include the alignment stuff probably. I haven't tested the new version of FindMy.py with that, though. But I think that maybe you can use that to provide the input files for the current version of FindMy.py?