OK it seems this is because the original device holds the encryption keys for the tracker tags.
@sven
What I don't know yet is how to change the interval or stop the entire process I started with curl... :D Does anyone know?
You can re-send the cURL command with a new period. You can also use Traccar 6.8 with the built in support for commands, and there are three commands:
I don't yet know the format for the cURL for immediate reporting, or stop reporting. It will be in the python code.
OK for single reporting it is:
curl -X POST -H "Authorization: Bearer API_KEY" "http://localhost:5500/devices/DEVICE_ID/position-single"
And for stopping:
curl -X POST -H "Authorization: Bearer API_KEY" "http://localhost:5500/devices/DEVICE_ID/position-stop"
The "Periodic Reporting" command in Traccar 6.8.1 seems to be not sending the trailing "interval=XXX".
Extract from Wireshark:
POST /devices/68806064-0000-218f-b4c8-34c7e920e6d3/position-periodic HTTP/1.1
Accept: application/json
Authorization: Bearer FOOBLAH
User-Agent: Jersey/3.1.10 (HttpUrlConnection 21.0.7)
Host: 192.168.0.72:5500
Connection: keep-alive
When using cURL, this is the request format:
POST /devices/68806064-0000-218f-b4c8-34c7e920e6d3/position-periodic?interval=300 HTTP/1.1
Host: 192.168.0.72:5500
User-Agent: curl/8.5.0
Accept: */*
Authorization: Bearer FOOBLAH
Apologies, I should have added the error shown in the microservice:
192.168.0.83 - - [04/Aug/2025 12:03:38] "POST /devices/68806064-0000-218f-b4c8-34c7e920e6d3/position-periodic HTTP/1.1" 400 -
This should fix the problem:
https://github.com/traccar/traccar/commit/8985376cd6719e087d5492363f9284feb5d4758f
Confirmed as fixed Anton, thanks.
Now that I'm actively testing this, there is some extra context required on whether something will be trackable. The relevant article from Google is here and I recommend reading it: https://support.google.com/android/answer/14796936
Let's say that you have tracker tags out there in the wild. Whether they will be detected and reported back to the Google Find My Device network depends on the settings on the phones which pass within range of your tags. The default setting on Android phones is "With network in high traffic areas only". Here is a description of that:
By default, your Android device helps others find their items in higher-traffic areas. If you have a PIN, pattern, or password set on your Android device, you’ll also receive help finding your items in higher-traffic areas.
When the owner of a lost item requests its location, the Find Hub network will — by default — aggregate the location sent by your device with locations sent from other Android devices that also detected the lost item.
What is aggregation?
With aggregation, the Find Hub network waits until multiple Android devices have detected a lost item. Find Hub then shows the owner of the lost item an aggregated location calculated from the multiple location reports. This helps people, including you, find items in higher-traffic areas where items are most often lost, like airports or busy footpaths, while helping protect the privacy of everyone whose Android devices share location info to the network.
For your devices to be detected even when there is only one phone nearby, that phone must be configured to use the setting "With network in all areas". Here is a description of that:
If you want the Find Hub network to help you find your lost items in lower-traffic areas, you can opt in to sharing location info through the network to help others find lost items even when your device is the only one that has detected and shared a location for the item. Users who turn on this option help each other find items in both higher-traffic and lower-traffic areas. This option may help you find your lost items more quickly.
You are therefore relying on individuals to have actively done this to their phone, which will, frankly, be rare.
This is not to say that the service is of low utility. For what we're planning to consider offering to customers, it will probably work well. It just needs the right caveats to be known and understood.
Yeah, by default you need at least two nearby devices to report location. I don't believe that it needs to be at the same time though. So it is almost never a problem even in not very densely populated areas. It might have problems in rural or some remote places.
Oddly enough I took my dog for a walk today with our test tracker and it never updated, but that's what prompted me to investigate. I live in Suburbia but encountered only a handful of people on the walk. For all I know, they had iPhones.
Tested further by setting my phone to not take part in the network, then went to the local supermarket. Sure enough, location updated as per the periodic schedule.
It's definitely not intended for live tracking. I also noticed that it wouldn't always provide a new location when you request it. It just reports last known location from a few hours ago.
It's fine for what we intend to do with it (assuming we don't get nerfed or Shadowbanned by Google), but customers ask some bizarre questions, so I like to have all the answers.
Hi! After start main.py I received
Loading...
--------------------------------------------------
Welcome to GoogleFindMyTools!
--------------------------------------------------
The following trackers are available:
If you want to see locations of a tracker, type the number of the tracker and press 'Enter'.
If you want to register a new ESP32- or Zephyr-based tracker, type 'r' and press 'Enter': 2
Traceback (most recent call last):
File "/home/ap/google-find-hub-sync/main.py", line 10, in <module>
list_devices()
File "/home/ap/google-find-hub-sync/NovaApi/ListDevices/nbe_list_devices.py", line 69, in list_devices
selected_device_name = canonic_ids[selected_idx][0]
~~~~~~~~~~~^^^^^^^^^^^^^^
IndexError: list index out of range
and I doesn't find deviceid in secrests.json
Adding some of my own experiences here, my test account (new google account) only had two devices, a Pixel 7 and a tracker. I kept receiving the "Your encryption data is locked on your device" message in Chrome until I first selected the Pixel 7 device. When I finally did that, the chrome browser refreshed with the info on that device, and after this point I could then get the location data for the tracker.