openclaw - 💡(How to fix) Fix Feature: Google Home API bridge in Android app for native smart-home control [1 comments, 2 participants]

Summary

Add native Google Home API support to the OpenClaw Android app so OpenClaw Talk can control a user's Google Home devices directly, without requiring Home Assistant as the bridge.

Example user flow:

User opens Android Talk / realtime Talk and says: “Turn off the living room lights.”
OpenClaw routes the intent to a Google Home bridge in the Android app.
The Android app executes the command via Google Home APIs against the user's authorized structure/devices.

Motivation

Today, the most practical smart-home route seems to be:

OpenClaw → Home Assistant MCP → Home Assistant integrations → devices

That is powerful, but it is a big requirement for users who already have a small Google Home setup and only want basic commands like lights, plugs, thermostats, scenes, etc.

Google now exposes Home APIs for Android/iOS that can access devices already connected to Google Home, with explicit user consent. That makes the Android app a promising place to implement a local/user-consented bridge:

OpenClaw Gateway / Talk session → Android app bridge → Google Home APIs → user's devices

This could make OpenClaw much more useful as a phone-based voice assistant / Google Home companion.

Proposed behavior

In the Android app:

1. Add a “Connect Google Home” settings flow.
2. Request user permissions for Google Home structures/devices via the official Home APIs.
3. Expose a small capability surface to OpenClaw, for example:
   • list homes / rooms / devices / traits
   • read device state
   • execute supported commands such as OnOff.on(), OnOff.off(), brightness/color where supported, thermostat commands, etc.
4. Let Talk/realtime Talk call this capability when the user asks for home control.
5. Require confirmation for sensitive actions, e.g. locks, garage doors, security systems.

Why Android specifically?

The Google Home APIs are designed around mobile SDKs and user-granted access. A server-side OpenClaw Gateway does not appear to have a simple generic REST API for controlling arbitrary Google Home devices in a user's home.

So the Android app can act as the permissioned bridge while the Gateway remains the reasoning/orchestration layer.

Possible implementation shape

• Android native module using Google Home Device & Structure APIs.
• A local app-side tool/capability exposed to OpenClaw sessions connected to that Android node.
• A normalized smart-home schema returned to the model, e.g. devices with {id, name, room, type, traits, supportedCommands}.
• Guardrails:
  • read-only discovery by default
  • allowlist low-risk domains like lights/plugs initially
  • confirmation for safety/security domains
  • clear permission revocation path

Alternatives considered

• Home Assistant + ha-mcp: best current power-user path, but heavy for users with only a few Google Home devices.
• Home Graph API: seems oriented toward smart-home integrations/manufacturers, not direct end-user control of arbitrary devices.
• Nest SDM API: useful only for supported Nest devices, not generic Google Home lights/plugs.
• Vendor APIs: possible per-device-brand, but fragmented.

Open questions

• Are the Google Home APIs mature/available enough for OpenClaw Android distribution, or would this require certification / special project setup?
• Should this be implemented as a generic “Android local capabilities” bridge rather than Google Home-specific plumbing?
• How should realtime Talk route tool calls to Android-side capabilities when the Gateway is remote?
• What is the right safety policy for locks/security devices?