Integration is causing HA to become overloaded

[drewdah]

HA Version: HAOS 2026.2.2
Integration Version: V1.7.0-4

I installed the integration into my HA instance today and got it set up with the auth & secrets.json, but shortly afterwards my HA instances disconnected and became unreachable and it would only stay up for ~5 minutes before becoming overloaded and requiring a hard restart. I removed the integration for now, but I checked the HA logs I'm seeing a lot of this message s like this with different event data:

[140516680928768] Supervisor from 172.30.32.2 (HomeAssistantSupervisor/2026.02.2 aiohttp/3.13.3 Python/3.13): Client unable to keep up with pending messages. Reached 4096 pending messages. The system's load is too high or an integration is misbehaving; Last message was: b'{ "type": "event", "event": {"c": {"device_tracker.suitcase": {"+": {"lc": 100,"c": "xxxxxxxxxx"}}}}, "id": 4 }'

For context, my HA instance is running on a pretty beefy mini PC. Happy to share more logs or debug information if it helps.

[jleinenbach]

Yes, please provide logs that show a connection with GoogleFindMy-HA, so this is unfortunately not comprehensible.

[markuswizard]

I’m experiencing a similar issue that may be related. I have 15 trackers configured to be polled every 300 seconds. However, when I check the states table in the database, I see more than 70,000 entries per device (with a purge interval of 8 days).

That corresponds to roughly one poll per device every 10 seconds instead of every 300 seconds, which has caused the database to grow rapidly. Could this maybe be the reason to the performance issues?

[DioVayne]

Confirming Issue with Additional Impact Analysis

Environment

• Home Assistant: 2026.2.3 on Raspberry Pi 4 (4GB RAM)
• GoogleFindMy Version: v1.7.0+ (experiencing issue)
• Storage: SD card (57GB)
• Tracked Devices: 4 devices
• Configuration: location_poll_interval: 300 (5 minutes)

Symptoms

Experiencing the same FCM crash loop described in this issue, which is causing system-wide instability leading to complete system crashes.

Error Pattern

The FCM client crashes continuously with base64 padding errors and immediately restarts:

ERROR [custom_components.googlefindmy.Auth.firebase_messaging.fcmpushclient.FcmPushClient] Unknown error in listener: Incorrect padding
Traceback (most recent call last):
File "/config/custom_components/googlefindmy/Auth/firebase_messaging/fcmpushclient.py", line 748, in _listen
await self._handle_message(msg)
File "/config/custom_components/googlefindmy/Auth/firebase_messaging/fcmpushclient.py", line 655, in _handle_message
self._handle_data_message(msg)
File "/config/custom_components/googlefindmy/Auth/firebase_messaging/fcmpushclient.py", line 508, in _handle_data_message
decrypted = self._decrypt_raw_data(
self.credentials, crypto_key, salt, msg.raw_data
)
File "/config/custom_components/googlefindmy/Auth/firebase_messaging/fcmpushclient.py", line 438, in _decrypt_raw_data
crypto_key = urlsafe_b64decode(crypto_key_str.encode("ascii"))
binascii.Error: Incorrect padding

INFO [custom_components.googlefindmy.Auth.fcm_receiver_ha] FCM client stopped; scheduling restart
INFO [custom_components.googlefindmy.Auth.fcm_receiver_ha] Restarting FCM client in 1.2s

This pattern repeats every 1-2 seconds continuously.

System Impact

This issue is causing severe system instability:

1. Rate limiting triggered: Module custom_components.googlefindmy.Auth.fcm_receiver_ha is logging too frequently. 200 messages since last count

2. I/O saturation: The continuous crash-restart loop generates massive logging I/O, especially problematic on SD card storage

3. System crashes: In my case, this contributed to a complete system freeze requiring hardware watchdog reset:

   • Timeline: System became unresponsive at 15:28
   • Watchdog timeout: 15 seconds
   • Hardware reset triggered at ~15:37 (9 minutes downtime)
   • Both port 8123 (Core) and 4357 (Supervisor) were unreachable
   • Ping to host IP still worked (kernel alive, but userspace frozen)

4. Combined effect: When paired with frequent database commits (recorder.commit_interval), the excessive logging I/O from this crash loop can saturate SD card I/O capacity, leading to filesystem freezes.

Root Cause Analysis

The error occurs in _decrypt_raw_data() when attempting to base64-decode the crypto_key from FCM messages. The padding error suggests:

1. Malformed crypto_key in FCM push messages: The incoming message doesn't have properly padded base64
2. Missing padding normalization: The code doesn't handle base64 strings that need padding adjustment before decode
3. No error recovery: The FCM client crashes completely on any decode error instead of gracefully handling/skipping malformed messages

Suggested Fix Areas

1. Add base64 padding normalization before decode:

# Add padding if needed                                           
missing_padding = len(crypto_key_str) % 4                         
if missing_padding:                                               
    crypto_key_str += '=' * (4 - missing_padding)

2. Implement error handling to skip malformed messages instead of crashing:
   try:
   crypto_key = urlsafe_b64decode(crypto_key_str.encode("ascii"))
   except binascii.Error as e:
   _LOGGER.warning(f"Skipping FCM message with invalid crypto_key: {e}")
   return # Skip this message instead of crashing

3. Add exponential backoff for restart attempts to prevent log spam and I/O saturation

4. Add circuit breaker: After N consecutive failures, disable FCM push for X minutes

Workaround

Disabling the integration completely resolves the system instability. After disabling:

• No more crash loops
• System stable with proper uptime
• No watchdog resets

This issue makes the integration completely unusable on resource-constrained systems (Raspberry Pi) and can cause critical system failures requiring hardware resets. Priority fix recommended.