# ha-google-home: reading and controlling Google Home alarms from Home Assistant

> The ha-google-home custom component surfaces the alarms, timers, Do Not Disturb state and alarm volume of Google Home and Nest speakers in Home Assistant, and can delete, mute and reboot them, using Google's local device tokens through the glocaltokens package. It suits a Home Assistant user whose household routines live in Google's speakers, and it deliberately stops short of the rest of the Google Home device set.

**leikoilja/ha-google-home** — Home Assistant Google Home custom component 

- Repository: https://github.com/leikoilja/ha-google-home
- Website: ha-google-home.pages.dev
- Stars: 568 · Forks: 110
- Language: Python
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/leikoilja-ha-google-home

## What the integration actually exposes

ha-google-home is a Home Assistant Google Home community integration, and the one-line summary in the documentation is alarms, timers and more from your Google Home and Nest speakers and displays.

The About section is precise about the scope. The integration brings your Google Home and Nest speakers and displays into Home Assistant, and you can see and delete their alarms and timers, turn Do Not Disturb on or off, change the alarm volume and reboot them. It does not add the other devices in your Google Home app, such as lights or thermostats, and there is a separate documentation section for those.

That limitation is stated in the same breath as the feature list rather than buried, and it is the first thing to read, because a user who expects a full Google Home bridge will be disappointed and a user who wants the alarm surface will not.

The entity documentation page lists what is actually exposed: alarms, timers, Do Not Disturb, alarm volume and reboot. The actions page lists what you can do: delete alarms and timers, reboot and refresh devices. So the read side and the write side are different sizes, and the asymmetry is reasonable, because reading a timer list is a query while deleting one is a mutation of a device you do not own.

The project started from a community discussion about reading Google Home alarms and timers in Home Assistant, and it grew from there. That origin explains the shape of it, because the discussion was about tracking alarms and timers and triggering different Home Assistant events, which is exactly the use case the component serves: a household routine that depends on a Google speaker's timer should be able to react to it in Home Assistant.

The licence is MIT, the primary language is Python, the default branch is master, and the recent releases are v1.14.0 from 2026-10-17, v1.13.3 from 2026-01-24 and v1.13.2 from 2026-01-23, with the last push to the repository on 2026-10-19.

## Installation through HACS, and what the sign-in involves

The integration is distributed through HACS, the Home Assistant Community Store, and the installation is short. You find it in the default HACS repo and search for Google Home.

The manual installation and setup path is documented separately, in the Getting Started page, which covers prerequisites, installation and sign-in. The sign-in is the part worth reading before you start, because the integration needs credentials for your Google account and there is no way to expose Google Home alarms to Home Assistant without it.

The mechanics underneath are described in the credits. Under the hood the integration uses the glocaltokens Python package, which is the author's own project, and the integration's own dependency list requires glocaltokens at 0.11.0 or newer. The token approach is what makes a local, LAN-oriented integration possible: the devices are on your network, and the tokens are what let the integration talk to them as the account that owns them.

That has an operational consequence that a user should think about before installing. The integration is talking to devices on your network using tokens derived from a Google account, so the security posture is the union of two things: the Home Assistant instance's own exposure, and the tokens' exposure. An integration of this kind is a reason to keep Home Assistant on a trusted network, and to treat the account whose tokens are used as an account whose access you would not publish.

The community documentation page is worth a mention too, because it covers dashboard cards and Node-RED flows, which tells you that the intended use goes beyond the default entity list, with people building their own visualisations and automations on top of the exposed alarms and timers.

## The packaging tells you how a custom component is actually built

The pyproject.toml is small and has a few comments that explain the whole arrangement better than any prose would.

```toml
requires-python = ">=3.14.2"
dependencies = [
    "glocaltokens>=0.11.0",
    "homeassistant==2026.10.0",
]
```

The homeassistant dependency is an exact pin, and that is the single most important line in the file for anyone planning to install this. A custom component is not a package Home Assistant resolves for you, it is code that runs inside Home Assistant's process, so it is tied to the internals of a specific core release, and the integration is developed against one version at a time.

The project comment above the tool.uv section explains the rest: not an installable package, because Home Assistant loads custom_components/ directly, with package = false set for that reason. So the version field in the pyproject is 0.0.0 with a comment saying the release version lives in manifest.json, set by script/publish_release.py. The version a user sees on the release page comes from a different file from the one a developer reads, and the script is what keeps them in step.

The tooling is thorough. The development dependencies cover codespell, dprint-py, mypy, pylint, pytest, ruff and types-requests, and there is a separate docs group with zensical for the documentation site. The repository has a .pre-commit-config.yaml, a .devcontainer/ directory for a prepared development environment, a dprint.json for formatting, a hacs.json for the store metadata, a .kodiak.toml which is the configuration for GitHub's issue triage bot, and a tests/ directory.

The ruff configuration is the most revealing part. The rules follow Home Assistant core's own pyproject.toml at the pinned version, with a required-version of at least 0.16.9 and a target version of py314. Preview rules are on but restricted with explicit-preview-rules, so the project opts into individual preview rules rather than the whole set, and the select list names the families it enforces, from the builtins shadowing check and the async and bugbear families through complexity, docstrings, the three datetime rules that forbid the naive UTC calls, pycodestyle and pyflakes. The comment in the file says to re-sync when bumping homeassistant, which tells you the rule set is treated as tied to the core version rather than as a personal preference list.

## The templates it was built from, and what that tells you about it

The credits section is short and names the scaffolding.

The project was generated from @oncleben31's Home Assistant Custom Component Cookiecutter template, and the code template was mainly taken from @Ludeeus' integration_blueprint template. The integration_blueprint is the framework the wider custom component community uses, and it is what gives a project like this its file layout, its config flow scaffolding and its test setup.

That is worth understanding for two reasons. The first is that the quality of the project is bounded by the blueprint in the ways the blueprint is bounded, so anything the blueprint leaves out, such as rigorous typing or a complete translation workflow, this project also leaves out unless it adds it. The second is that the blueprint is a well-trodden path, so a contributor does not have to invent the structure, and a user reading the code is reading something that looks like every other custom component they have seen.

The project then adds the parts that matter for a custom component: the glocaltokens dependency for talking to the Google devices, the entity and action surfaces, and the release tooling that keeps manifest.json and the published version aligned.

The documentation structure is also worth noting, because it is organised around the questions a user actually has rather than around the code. There is a Getting Started page covering prerequisites, installation and sign-in, an Entities page, an Actions page, a Troubleshooting page, a Community page for dashboard cards and Node-RED flows, and a Contributing page covering questions, bug reports, translations and development.

The contribution routes match that structure. Questions go to GitHub Discussions, bugs and feature suggestions go to issues, and the contributing page covers translating the integration and changing its code, which tells you that translations are treated as a contribution in their own right, which for an integration used in more than one language is a reasonable thing to ask for.

## Where ha-google-home is the wrong tool

The first limit is the device coverage, and the documentation is honest about it. Lights, thermostats and the rest of the Google Home device set are not brought in, and there is a separate page for those devices that explains what is and is not possible. A household that wants a single place to control everything Google has, with Google Home as the hub, will find this integration to be one narrow corner of that.

The second is the fragility of a custom component, and it is a structural property rather than a quality problem with this project. A custom component runs inside the Home Assistant process and is written against one core release, and the dependency here is an exact pin of homeassistant 2026.10.0. Every Home Assistant update is therefore a moment when this integration either works or does not, and the answer is usually that it needs a rebuild against the new core. The releases show a v1.13.3 in January 2026 and a v1.14.0 in October 2026, so the project is maintained, and the cost of that maintenance lands on whoever runs the integration.

The third is the account and token story. Talking to Google devices locally requires tokens tied to a Google account, and the sign-in step is part of the installation. For a household that is fine. For an office that has moved away from Google deliberately, or for a security-conscious user, the integration is a component that has to hold credentials for a third-party account inside the home automation system, and that is a decision rather than a detail.

The fourth is that the read side and the write side are thin. Alarms, timers, Do Not Disturb and volume is a short list, and there is no notion of routines, scenes, speakers groups or the wider Google Home account. The integration solves a specific problem well, and a user who wants more of Google Home in Home Assistant will find the boundary.

And the fifth is the Python floor. The project requires Python 3.14.2 or newer, which is a very recent interpreter, and it follows from pinning a specific Home Assistant release. A Home Assistant installation on an older Python, which is common on a stable distribution or an appliance-style install, cannot run this version of the integration, and the project does not offer a line that does.

## Conclusion

ha-google-home is worth installing if your household's alarms and timers live on Google Home or Nest speakers, because it makes them first-class entities you can script against rather than something you have to ask a speaker about, and because the actions go the other way too, so you can delete a timer or reboot a stuck device from an automation. It is the wrong tool if you want the lights and thermostats, and the wrong tool if you do not want Google credentials in your network. Before you install it, check three things: that the component pins the Home Assistant version it was written against, because the dependency is an exact pin of homeassistant 2026.10.0 and a custom component that is not rebuilt against a new core release will break on the next Home Assistant update; that you understand the sign-in step is not optional, since the integration talks to your Google devices through Google's local device tokens, and the getting started page covers the sign-in; and that the scope is what you expect, because the documentation is explicit that it does not add the other devices in your Google Home app, such as lights or thermostats.

## FAQ

### What does the ha-google-home integration expose to Home Assistant?

It brings Google Home and Nest speakers and displays into Home Assistant so you can see and delete their alarms and timers, turn Do Not Disturb on or off, change the alarm volume and reboot them. It deliberately does not add the other devices in your Google Home app, such as lights or thermostats.

### How do I install ha-google-home?

It is available in the default HACS repository, so you add HACS to Home Assistant and search for Google Home. The manual installation route and the sign-in step are documented on the Getting Started page of the project documentation site, and the integration uses Google's local device tokens through the glocaltokens package.

### Why does ha-google-home pin a specific Home Assistant version?

A custom component runs inside the Home Assistant process and is written against one core release, so the project pins homeassistant to an exact version, 2026.10.0, and requires Python 3.14.2 or newer. The lint rules in the pyproject follow Home Assistant core's own configuration at the pinned version, and the project comment says to re-sync them when the pin is bumped.

## Sources

- [Issues](https://github.com/leikoilja/ha-google-home/issues)
- [leikoilja/ha-google-home on GitHub](https://github.com/leikoilja/ha-google-home)
- [License: MIT](https://github.com/leikoilja/ha-google-home/blob/master/LICENSE)
- [README](https://github.com/leikoilja/ha-google-home/blob/master/README.md)
- [Releases](https://github.com/leikoilja/ha-google-home/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/leikoilja-ha-google-home