Speakers in Home Assistant: Sonos, Google/Nest, AirPlay, DLNA, Bluetooth, MQTT, and Their Limits
Speakers in Home Assistant: Sonos, Google/Nest, AirPlay, DLNA, Bluetooth, MQTT, and Their Limits
"I'll buy some smart speaker" isn't enough information to plan an integration around. Every ecosystem integrates with HA differently, has a different level of locality, and comes with different limits. This lesson is a buying guide, not an ad for any one brand.
Budget around 70 minutes. This lesson is more comparative than code-heavy: a few short integration examples, mostly a decision table.
Ecosystem Comparison
| Ecosystem | Integration with HA | Limitation |
|---|---|---|
| Sonos | native integration, mostly local | high cost of entry into the ecosystem |
| Google/Nest | integration through Google's cloud | dependency on a Google account and the cloud, latency |
| AirPlay (Apple) | local integration through the AirPlay 2 protocol | limited feedback control (reading state) in some integrations |
| DLNA | local integration, an old universal standard | inconsistent implementation quality between manufacturers |
| Bluetooth | pairing with the HA host or a local device | range, no native multiroom, dropped connections |
| ESPHome speaker + MQTT/DAC | full local integration, self-built | requires tinkering, no manufacturer warranty |
Local Versus Cloud: Why It Matters
A speaker dependent on the manufacturer's cloud stops responding to HA commands the moment the internet goes down, even if the speaker and HA are on the same local network. For the critical announcements from Lesson 1 (flood, smoke), that's a serious risk: an alert meant to get through in an emergency shouldn't depend on whether the provider's internet happens to be working. If you're building a critical-announcement layer, prefer at least one speaker with a local integration (Sonos, AirPlay 2, or your own ESPHome build) as a reliable fallback point, regardless of what speakers you use for regular music.
Bluetooth: Why It's a Poor Choice for Automation
Bluetooth needs active pairing at the moment of playback
A Bluetooth speaker typically connects to one device at a time and requires that device to be in range and actively streaming. For an automation triggered by HA (say, running on a server or a Raspberry Pi), that's an unreliable setup: no multiroom, limited range, dropped connections when the band gets congested. Treat Bluetooth as a solution for a single, simple speaker, not the foundation for whole-house announcements.
An ESPHome Speaker as a Cheap, Fully Local Announcement Point
If you have ESPHome experience from Module 10, an audio module (a board with a DAC and amplifier, built around an ESP32, for example) configured as a media_player in ESPHome gives you a fully local, cheap announcement point for TTS, with no dependency on any cloud and none of Bluetooth's limits. This approach takes more work up front than a commercial speaker straight out of the box, but it eliminates an entire category of manufacturer-cloud risk.
Recommended Speaker Architecture for the House
Loud, comfortable music playback: whatever ecosystem you like, integrated through Music Assistant.
Critical announcements: at least one local speaker, independent of the internet, in a place you usually are.
Home announcements (less critical): can live on the same speaker as your music, since a missed reaction isn't critical.
Which Speaker Ecosystem to Choose: An Honest Comparison
| Ecosystem | Locality | Strengths | Weaknesses |
|---|---|---|---|
| Sonos | fully local, communicates directly over Wi-Fi with no Sonos cloud needed | grouping, queue, TV soundbar, considered the benchmark for HA integration | hardware price |
| Chromecast / Google Cast | needs the internet and Google's cloud when casting | wide availability, good Music Assistant integration | dependency on Google, latency on a poor connection |
| AirPlay 2 | local within the home network | very good time sync between speakers | Apple's ecosystem, limited control from Android |
| DLNA/UPnP | local, an old standard from the 2000s | lets you connect old stereo towers and hi-fi receivers | no new features, sometimes unstable device discovery |
| Bluetooth | local, but paired 1:1 | simplicity, no network needed | no grouping, dropped connections, a poor choice for automation |
For announcement points scattered around the house (garage, hallway, laundry room), a self-built option often turns out to be the most cost-effective: a speaker on an ESP32 board with an I2S DAC output costs under $15 in parts, runs fully locally through ESPHome, and is plenty for TTS announcements and doorbell chimes, though it won't replace a hi-fi setup for listening to music.
Bluetooth as the foundation of automation is a bad choice
A Bluetooth connection needs active pairing and tends to drop when the phone disconnects or goes to sleep. For announcement automation, pick Wi-Fi (Sonos, Cast, AirPlay, ESPHome) over Bluetooth.
A DIY ESPHome Speaker: Parts List and Rough Cost
| Component | Role | Rough cost |
|---|---|---|
| ESP32-S3 (with audio support) | a microcontroller with enough power for audio processing | around $6-10 |
| Audio amplifier (e.g., MAX98357A) | amplifies the digital signal to speaker level | around $4-5 |
| A 3-4W speaker | the actual sound transducer | around $3-5 |
| An I2S microphone (optional, for voice commands) | audio input for the local voice assistant from Lesson 13 | around $5-8 |
The whole thing, enclosure and wiring included, usually comes in around $15-25 per audio point, considerably cheaper than a commercial smart speaker with comparable local functionality, though it requires your own assembly work and flashing the ESPHome configuration.
Sound Quality: Mono Versus Stereo for Home Automation Purposes
For the voice announcements and alerts covered in later lessons of this module, mono audio from a single, cheap speaker is entirely sufficient: understanding a voice announcement doesn't depend on stereo. Investing in stereo or multi-speaker systems mainly makes sense where music playback quality is the priority (living room, bedroom), not where a speaker mainly serves an informational role (hallway, laundry room, garage).
AirPlay 2 Versus Chromecast: Latency and Sound Quality
| Protocol | Typical latency | Quality |
|---|---|---|
| AirPlay 2 | low, syncs well with picture | lossless with a suitable source, limited to Apple's ecosystem on the sending side |
| Chromecast (Google Cast) | slightly higher, usually unnoticeable for music alone | good, broad compatibility with Android and browsers |
For the voice announcements covered in this module, a delay on the order of a single second or two doesn't matter much, but when trying to sync audio with picture (say, TV sound through an external Chromecast speaker), the latency differences between protocols become noticeable, and it's worth factoring that in when planning your living room audio architecture.
Outdoor Speakers on the Patio in a Multimedia System
Tying back to Module 21 (outdoor), patio speakers need a weatherproof enclosure (like other devices from that module) and, if they're meant to be part of the same Music Assistant system, stable network range in that spot, which points directly back to the Wi-Fi and Zigbee range lesson from Module 21. Outdoor speakers often use PoE instead of Wi-Fi, for more reliable connectivity in outdoor conditions.
Room Acoustics and Speaker Placement
Even the best speaker, placed in a poor spot (a room corner, close to a hard, untreated wall), will sound worse than a cheaper speaker placed well. For the informational announcements this module covers, acoustics matter less than for listening to music, but it's worth avoiding placing a speaker right next to noise sources (a washer, a dishwasher) that could drown out an important announcement at the worst possible moment.
Volume Testing in Practice: Calibrating Against Other Sound Sources
After installing every new speaker in the system, it's worth calibrating its default volume against the other audio points you already have: a kitchen speaker set louder than a bedroom one, matching the natural background noise level of each room, makes announcements sound consistent throughout the house instead of disproportionately loud or quiet depending on each device's random factory defaults.
Backward Compatibility: Older Speakers With No Manufacturer Support
Speakers whose manufacturer has already dropped active support and software updates can still work correctly with Music Assistant, as long as they rely on open, standard protocols (like Chromecast or AirPlay), independent of whether the manufacturer still supports the device. That's one of the practical advantages of an architecture built on Music Assistant instead of relying solely on native integrations: the system stays functional even after manufacturer support for a specific model ends.
How to Test This Lesson
1. List your speakers and assign each an ecosystem from the table.
2. Turn off the internet for a moment (or your outbound access router) and check which speakers still respond to HA.
3. Decide which speaker will be your critical-announcement point.
Common Mistakes
All critical announcements through a cloud-dependent speaker: there's a flood at home, and the alert never arrives because the internet is down.
Bluetooth as the foundation of automation: unreliable connection, no multiroom.
No test of resilience to a lost internet connection: you find out about the problem during an actual outage.
Practical Task
☐ Classify your speakers by ecosystem and integration locality.
☐ Test each speaker's resilience to a lost internet connection.
☐ Choose one local speaker as your critical-announcement point.
Key Takeaways
Integration locality matters for critical announcements, not just for convenience.
Bluetooth is a fine choice for one simple speaker, a bad one for the foundation of automation.
At least one local speaker dedicated to critical announcements, independent of the internet.
What's Next
Next lesson: TTS and Voice Announcements: Methods, Engines, Language, Volume, Delay, and Quality. We return to the home_announcement script skeleton from Lesson 1 and build it out in full.
