google-home-notifier: speaking to a Nest speaker from Node

Why an unofficial path still exists in 2026

The README opens with a section titled why this still exists in 2026, and the answer is the most useful thing in the document.

Google never shipped an official API for making a speaker say a specific thing. The Google Assistant SDK is experimental and non-commercial, and it explicitly cannot broadcast voice messages. The newer Google Home APIs are for device control, automations and Matter, not media or text-to-speech. So casting a generated text-to-speech clip to the speaker, which is what this library does and what Home Assistant does under the hood, is still the way to do it.

The framing is honest about the alternative. A tiny dependency-light package is a different proposition from running an entire home-automation stack, and for a script that only needs to announce a delivery, that difference is the whole argument.

What the library actually does is send text-to-speech notifications, or play an MP3, on Google Home and Nest speakers. The homepage of the package is on GitHub and the author is Noel Portugal.

The audience is a developer with a speaker on their network and a small need: say this, or play this, from a script. It is not a home platform, and it does not try to be one.

Discovery that stopped needing a native build

The version 1.3.0 notes describe the change that made this package pleasant to install again, and the change is architectural.

Device discovery is now pure JavaScript via the bonjour-service package. There is no more native mdns build, no avahi system packages, and no patching of node_modules. That is a meaningful improvement on Unix, where the previous approach required a system daemon to be present and often meant a compile step or a vendored binary in the install tree.

The dependencies in package.json tell the whole story. There are three runtime dependencies: bonjour-service at 1.4.1 for discovery, castv2-client at 1.2.0 for the Cast protocol itself, and google-tts-api at 2.0.2 for the text-to-speech synthesis, which was upgraded to version 2.x in the same release. The dev dependencies are express and ngrok, which exist only for the example server.

The engines field requires Node 14 or later, and the README says it installs and runs cross-platform on macOS, Linux, Raspberry Pi and Windows with no compilation step. The repository also ships a TypeScript declaration file, google-home-notifier.d.ts, and the package manifest points at src/index.js for the entry point with types at src/index.d.ts, and it also keeps google-home-notifier.js and its declaration file at the top level in the published files list for compatibility with older resolution.

The test script is a single command, node --test, which is the built-in Node test runner, so the project has no test framework dependency at all.

Targeting a speaker by name, by IP, or all of them

The API is a chainable set of methods, and the target selection has three levels.

The first is a single device by fuzzy name, and the alternative is a single device by IP address, which skips discovery entirely. The README gives both forms, with the IP variant commented out as the option for when you already know the address.

The second is a set of devices, by names or by IP addresses, and the notify or play call then fans out to all of them. The documented result shape shows what that means in practice: an array of objects with a device and a result, and a device that failed carries an error instead. The comment on that example makes the design intent explicit, that one offline speaker won't block the rest.

The third is discovery of everything on the network. getDevices takes an optional timeout in milliseconds, browses the network for that window, and returns every Google Cast device it sees, deduped, with a name, an address and a port. The example shows the composition of that with the other calls: map the discovered addresses into ips, then notify, or loop over the list yourself and call ip(d.address).notify with a per-device message.

So the API covers the three real situations: one known speaker, several known speakers, and whatever happens to be on the network right now. The chainable design is what makes that readable, since device, accent, volume and slow are all setters that return the same object.

Language, accent, volume and the 200 character wall

Two settings affect how the message sounds. The language code is the second argument to device or ip, and the accent is a separate chainable call that takes a TTS host such as us, which is the default, co.uk, com.au, ca, and others, or a full URL.

The example shows them working together, a device call with a language argument, then an accent call, then the notify.

The volume and slow controls are newer. The volume takes a level from 0.0 to 1.0, and the important behaviour is that the device's prior volume is restored afterwards, so a notification does not permanently change how loud the speaker is. The slow control produces slower text-to-speech, with normal speed as the default.

There is one hard limit worth knowing before you design around it: text-to-speech notifications are limited to about 200 characters per request, and the README attributes this to a Google TTS limit rather than to a choice in the library. A message longer than that is not truncated gracefully, it is refused by the service.

The play method takes the same shape for audio, accepting a URL to an MP3 and following the same return and callback contract as notify. The example is a single line, and the URL is a plain http one rather than https, which is worth noticing because the Cast channel fetches it directly from the speaker.

The HTTP listener, and what it exposes to the network

The example directory ships a small server that lets you trigger a notification over HTTP, which the README describes as handy with IFTTT, webhooks or home automation. It uses ngrok to expose the endpoint outside your network.

Running it is three commands:

git clone https://github.com/noelportugal/google-home-notifier
cd google-home-notifier
npm install
node example/example.js

The endpoint list shows two forms of the same path, one on the local network address and one on the ngrok address, and both a GET with a text query parameter and a POST with a text form field. There is one behaviour worth noting: if the text starts with http(s):// it is played as an MP3, otherwise it is spoken. The same parameter therefore carries either a message or a media URL.

The security picture is the weak point of this whole example, and it is worth being blunt about it. There is no authentication on the endpoint, and the README's own suggestion is to put it on the public internet through ngrok. A URL that anyone can reach can therefore make your speakers say anything, and can be used to make them fetch and play an arbitrary audio file.

The service listens on port 8091, and the documented endpoints use a path of /google-home-notifier. If you run this, it belongs on a trusted network or behind something that authenticates requests. The library itself is fine; the example is a demonstration, and demonstrations get deployed.

Where google-home-notifier is the wrong tool

The first limitation is the dependency on an unofficial service, and the README does not soften it. The text-to-speech synthesis goes through google-tts-api, and the whole reason the package exists is that Google offers no supported alternative. That means the upstream can change, and when it does the failure will look like a network error rather than a policy change, which is a bad way to find out.

The second limitation is the speaker model. This talks to Google Home and Nest devices as Cast devices on the local network. It does not manage routines, it does not read the state of the home, it does not work with a non-Google speaker, and it does not give you a proper API contract with error types and status codes. It announces things. If you want home automation rather than announcements, the platform route is the right one.

The third is the 200 character limit on speech, combined with the fact that a spoken message is audible to everyone in the room. A notification system that announces a package is fine. A notification system that announces a name, a meeting title or anything else personal is a privacy decision, and this library makes no attempt to restrict what you say.

The alternative worth comparing is running a local text-to-speech engine and streaming the audio to the speaker, which you can also do with a Cast client, or using the Home Assistant Google Cast integration if you already run Home Assistant, since the README itself names Home Assistant as doing the same casting under the hood. The difference in approach is where the synthesis happens. This package asks Google for the audio and plays the result, which gives natural voices for free and no setup, and it depends on a service you do not control. A local engine gives you an offline system and a voice that sounds synthetic unless you configure one, and it costs you a model and some work. For a script that runs on a machine that already has internet and simply wants to say something, the trade in this package's favour is obvious. For a home that must keep working when the internet does not, it is the wrong shape of solution.

Editorial conclusion

google-home-notifier fits a home automation script or a small service that needs to say one thing out loud on a speaker, since it is a single npm install with three runtime dependencies and no compilation, and it will accept a message and a device name and get on with it. It is the wrong choice for anything that needs a supported API contract, since the README is candid that Google shipped no official make-my-speaker-say-this API, and the wrong choice for a house with several people in it where everyone hears the announcements. Before adopting it, confirm the target speakers are reachable as Cast devices on your network, and decide whether you want the device found by name or pinned by IP, because the name lookup is a fuzzy network search and the IP route skips discovery entirely.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. noelportugal/google-home-notifier on GitHub
4. README
5. Releases