Google Find Hub devices in Traccar

https://github.com/leonboe1/GoogleFindMyTools/issues/90

I got traccar/google-find-hub-sync working, but I had to make a few adjustments.

What worked for me:

1. Use a clean virtual environment with Python 3.11.
   This repo works more reliably with Python 3.11 than with older macOS system Python versions.

2. Make sure Google Chrome is updated to the latest version.
   The first authentication flow requires Chrome, and Chrome/ChromeDriver version mismatches can break the login process.

3. Delete the local undetected_chromedriver cache before retrying.
   This helps when the wrong cached ChromeDriver version is reused.

4. Patch a few files in the repository:

   chrome_driver.py

   • Force the correct Chrome major version in both uc.Chrome(...) calls
     (example: if Chrome is version 145, use version_main=145)

   • Add a dedicated Chrome profile in get_options() using:

     • --user-data-dir=...
     • --profile-directory=Default

   Why: this fixes ChromeDriver version mismatches and makes the browser-based auth/key flows more stable.

   Auth/firebase_messaging/fcmregister.py
   Add these Android identification headers to the Firebase / FCM requests:

   • X-Android-Package: com.google.android.apps.adm
   • X-Android-Cert: 38918a453d07199354f8b19af05ec6562ced5788

   Why: without these headers, FCM registration failed with API_KEY_ANDROID_APP_BLOCKED.

   Auth/secrets.json

   • Remove stale fcm_credentials once, then let the tool regenerate them

   Why: after failed registration attempts, cached credentials may remain in an invalid state.

5. Complete the first authentication on a machine with a GUI, then copy Auth/secrets.json to the headless server.

   Why: the browser-based login/key retrieval is much easier on a desktop machine, while the headless server can reuse the generated auth data afterward.

After these changes, I was able to:

• complete authentication successfully
• retrieve the shared_key
• run the microservice on a headless Ubuntu server
• push positions into Traccar successfully

If the tracker appears online but no position data is shown, also check filter.static in Traccar. It can block location updates from slow-moving or stationary trackers, making it look like no data is being received.

We have a new Android app that you can use instead of hosting this service. You can sign in directly in the app, so no need to worry about copying tokens. More info here:

https://www.traccar.org/forums/topic/relay-app-for-google-find-hub-devices/

I'm having a problem and need help.

The situation is as follows: my Google server key expires automatically periodically, and I always have to generate a new key. This causes several problems.

Has anyone solved this problem or something similar?

Hi derenrich,

I think I found a file descriptor leak in Trachs that eventually causes the polling service to stop working.

I'm running:

• Docker image: ghcr.io/derenrich/trachs:latest
• Python 3.13.13
• 7 Google Find My Device devices
• Traccar integration enabled
• Poll interval initially set to 3600 seconds

After about 20 hours, Trachs stopped sending location data. The container was still running and reported as healthy, but every polling cycle failed with:

ERROR - Failed to poll device locations: [Errno 24] Too many open files: '/app/secrets.json'

Inside the container I found:

Max open files            1024                 524288
FDSize: 1024

and:

ls /proc/1/fd | wc -l
1024

Restarting the container immediately fixed the problem.

I then temporarily reduced the polling interval to 60 seconds to investigate. After restarting the container, the number of file descriptors was initially only 7, but increased during subsequent polling cycles:

7
33
56
49
70
98
91
115
...

The number fluctuates but clearly keeps increasing over time.

I also noticed that every device location request creates/starts an FCM listener and then calls stop_listening() afterwards.

The relevant code appears to be in Auth/fcm_receiver.py:

self._loop = asyncio.new_event_loop()
self._loop_thread = threading.Thread(
    target=self._run_event_loop_in_thread,
    daemon=True
)
self._loop_thread.start()

and:

asyncio.run_coroutine_threadsafe(self.pc.start(), self._loop)

while stop_listening() only does:

asyncio.run_coroutine_threadsafe(self.pc.stop(), self._loop)
self._listening = False

The event loop itself is never stopped and the background thread is never joined.

There also seems to be a related issue in FcmPushClient.stop(): it cancels the asyncio tasks but does not wait for them to finish.

I haven't modified the application code yet. I wanted to report this first rather than create a local workaround.

If useful, I can provide the relevant source code sections and additional diagnostics.

Thanks!

@heini

Oh, wow I didn't know anyone else even used it. Yeah the code isn't the best. I'm not surprised there are issues. Though I've been running it for a long time now continuously and it doesn't break. Feel free to open a PR at https://github.com/derenrich/trachs or else I may be able to take a look in a few days.

@derenrich

I tried to put this to github, but cant`t it plac there because a Issue Report is restricted. So I tried this Way

ok. I pushed some fixes. seem to work for me. see if pulling the latest container fixes the situation.

Thank You, I will try it