I've dealt with this exact issue in production IoT deployments using Google IoT Core and Atmel MCUs, so let's break down what's happening and how to resolve it.

Why This Error Happens #

Google IoT Core enforces a single active connection per device ID by default. When your device loses power abruptly (without sending an MQTT DISCONNECT packet), the server doesn't immediately know the connection is dead—it'll keep the session alive for a period based on TCP timeouts and MQTT keepalive settings. When your device boots back up and tries to connect, the server detects the duplicate device ID, closes the stale old connection, and allows the new one to proceed. That's why your connection/subscription/publishing still works, but you get that annoying ALREADY_EXISTS disconnect log.

Practical Solutions for Production #

Here are the most effective fixes, ordered by ease of implementation:

1. Tune MQTT Keepalive Settings

This is the simplest and most reliable fix for most cases:

• On your Atmel MCU, set the MQTT keepalive interval to a reasonable value (30-60 seconds works well). This tells the server to expect a ping from the device every X seconds; if it doesn't get one after 2x the keepalive interval, it'll mark the connection as dead and clean up the session.
• Match this with Google IoT Core's device configuration:
  • Via Cloud Console: Go to your device's settings, under "Connection settings", set the Connection keepalive interval to match (or slightly exceed) your device's keepalive value.
  • Via gcloud command:

    gcloud iot devices update DEVICE_ID \
      --registry=REGISTRY_NAME \
      --region=REGION \
      --connection-keepalive-interval=60s
    

This ensures the server detects stale connections quickly, so when your device reboots, there's no active session left to conflict with.

2. Use MQTT Clean Session (If Offline Messages Aren't Needed)

If your device doesn't rely on receiving offline messages while disconnected:

• When initializing the MQTT connection on your MCU, set cleanSession=true. This tells the server to discard any existing session for the device ID when a new connection is established, eliminating the conflict entirely.
• Note: Avoid this if you need persistent sessions (to receive queued messages after reconnection).

3. Add Graceful Disconnect for Planned Reboots

While you can't handle unexpected power loss, you can handle planned restarts (like software updates or watchdog resets):

• Before triggering a reboot in your firmware, explicitly send an MQTT DISCONNECT packet. This lets the server immediately clean up the session, so the next connection won't trigger the error.
• For watchdog-triggered resets, some MCUs let you run a short cleanup routine before resetting—use this window to send the disconnect.

4. Pre-Check and Kill Stale Connections via API (Advanced)

If you need strict control over connection states (e.g., in high-reliability deployments):

• When your device boots up, first call the Google IoT Core API to check if there's an active connection for your device ID. You can use the projects.locations.registries.devices.get endpoint to retrieve device status.
• If an active connection exists, call projects.locations.registries.devices.disconnect to terminate it before initiating the MQTT connection.
• Note: This requires your device to authenticate with Google Cloud (using JWT tokens, same as MQTT) and have the cloudiot.devices.disconnect IAM permission. It's more complex but gives you full control.

Why Your Connection Still Works #

As you noticed, the error doesn't break functionality because Google IoT Core prioritizes the new connection—it automatically drops the stale one when a duplicate device ID connects. The log is just a record of that cleanup action. In production, though, frequent logs can clutter monitoring and might indicate underlying session management issues, so fixing it is a good practice.

内容的提问来源于stack exchange，提问作者Edoardo Lobbiani