Google Find Hub devices in Traccar

Anton Tananaev 8 months ago

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

Massimo 7 months ago

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.

Anton Tananaev 7 months ago

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/

Monkey D. Luffy 3 months ago

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?

heini last month

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!

derenrich last month

@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.

heini last month

@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

derenrich last month

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

heini last month

Thank You, I will try it

francis3 3 days ago

Just a quick update from my side.

I first tested the Traccar Android Relay app on my Android phone, and it worked well. However, I don't really like having the Relay running continuously on my phone, so I looked for a headless/server-side solution.

I managed to get google-find-hub-sync running successfully headless on Debian Trixie, integrated with Traccar 6.16.

1. Initial authentication — desktop

I used a Linux desktop machine with Chrome for the initial Google authentication.

After authentication, google-find-hub-sync generated:

Auth/secrets.json

I then copied this file to the headless server.

No permanent service is required on the desktop.

2. Headless server

The actual service runs on the Debian Trixie server where Traccar 6.16 is installed.

I initially ran into:

PHONE_REGISTRATION_ERROR
API_KEY_ANDROID_APP_BLOCKED
androidPackage: "<empty>"

The changes from PR #7 fixed the FCM registration problem.

I then found a small compatibility issue in the microservice: the newer FCM receiver uses a background event loop/thread, while the microservice was waiting on an asyncio.Event from another loop. Switching that wait to a threading.Event fixed it.

After that, everything worked end-to-end:

  • FCM registration ✓
  • Find Hub authentication ✓
  • device discovery ✓
  • E2EE location decryption ✓
  • Traccar upload ✓
  • multiple devices ✓
  • periodic updates ✓

The service is now managed by systemd, with two devices configured for a 30-minute update interval.

So far it has been working very well.

I'll leave it running for a few days and report back if anything changes.

Anton Tananaev 3 days ago

Relay doesn't run continuously. It does not run or use any resources until you send a command.

francis3 3 days ago

Thanks for the clarification — that's good to know.

In that case, my main reason for looking at the headless approach was simply to avoid having the phone involved at all, rather than concerns about the Relay continuously using resources.

The Relay worked well in my testing, so it's good to know that it remains idle until Traccar actually requests a location.