Alexa Media Player

Announcement output is a separate path from voice commands

Alexa Media Player is a community custom integration that uses Amazon's unofficial Alexa API. It exposes supported Echo controls in Home Assistant. My announcement path therefore depends on Amazon account access and the cloud service, even when the automation's original input comes from a local device.

Home Assistant input → automation and message → Alexa Media Player → Amazon service → Echo

I also use Alexa as a voice interface for the home, but exposing Home Assistant devices to Alexa is a separate connection. This page describes how Home Assistant controls Echo outputs. Installing Alexa Media Player alone does not establish the Alexa smart-home exposure path or a Home Assistant Assist voice pipeline.

My build also runs the separate Alexa Devices integration, which is built into Home Assistant and has its own Speak and Announce entities. Their entities and actions are not interchangeable. I use Alexa Media Player because it gives me more customizable features and more options for custom automations and device integration. My announcement automations and response script use its notification actions, so that is the path described here. For new, basic announcements, Alexa Devices is the simpler place to start because it needs no HACS install.

The inputs and outputs I use together

Scroll the table horizontally to compare all four columns.

Turning existing Home Assistant inputs into speech

A sensor input with more than one output

One configured automation evaluates a Z-Wave sensor state, requests an Alexa announcement and changes Hue lighting. The speaker and the light serve different purposes within the same response. Neither output requires the sensor to connect directly to an Echo or a Hue bridge.

Home Assistant is the connection between those systems. The Z-Wave JS guide covers the input network, and the Hue guide covers the lighting action. The Alexa output adds a cloud dependency to that part of the response.

An MQTT input with weather context

Another configured automation starts from an MQTT message, evaluates its conditions, requests forecast information and prepares an announcement. It also uses a helper to track whether the relevant action has already been handled. I describe those roles without publishing the message topic, personal content or household schedule.

MQTT carries the incoming event, not the speech itself. The forecast action obtains context from a different integration, and Alexa Media Player delivers the announcement request. When investigating missing or incomplete speech, those are separate places to check.

This arrangement lets the message reflect information Home Assistant already coordinates. It does not make an upstream forecast authoritative or guarantee that cloud-delivered audio begins immediately.

Volume and announcements inside a shared response

A wider response script includes selected Echo targets and volume changes alongside lighting, notifications and other media actions. It records volume information and contains a later restoration path. That gives the routine a way to request an appropriate temporary level while retaining information about the earlier setting.

Restoration remains an action that must execute successfully. A stored value is not a guarantee that every interrupted run restores every device. If a routine stops early, I check the actual resulting volume instead of assuming that its cleanup completed.

Keep the media integrations distinct

The same script also contains source selection, playback and pause actions aimed at Spotify. Those actions should not be attributed to Alexa Media Player simply because Echo targets appear elsewhere in the script. Each target follows the integration responsible for that entity.

Likewise, an Alarmo state can govern a shared response without Alexa Media Player becoming an alarm engine. The Alarmo guide explains how that state connects to the response. Alexa Media Player remains an output path.

Account access and audible playback are different checks

The project's README identifies the API as unofficial. Amazon can change it, so a working configuration today is not a promise of uninterrupted support. Authentication problems can affect this output even while local sensors and lights continue working.

The configuration guide covers account setup and authenticator-based two-step verification. Those credentials and authentication material belong in the private Home Assistant configuration and backups, not in a published automation example.

For announcements, the project documents that Communications must be enabled and Do Not Disturb can suppress playback without an obvious Home Assistant error. It also distinguishes announcements from text-to-speech behavior. See the notification reference when choosing the output type.

A successful action return is therefore insufficient evidence that a message was audible. Device volume, the selected target, account availability and the chosen output behavior all matter. I do not treat the presence of an announcement action as a verified delivery record.

Follow the message from its trigger to the speaker

I first check whether the original event arrived and whether the automation's conditions allowed it to continue. For the weather-based path, I also check the forecast response and how the message was constructed. Reauthenticating Alexa will not repair an automation that never reached its notification step.

Next I inspect the target and action type, then check integration availability and any authentication prompt. If the request was made but the speaker remained silent, I check its settings and volume before changing the upstream trigger.

For a shared routine, I inspect each output separately. A light changing proves that its lighting action worked, not that the announcement played. A restored volume proves nothing about whether an earlier message was heard. These distinctions keep troubleshooting grounded in the part of the system that actually produced the evidence.