
Este artículo puede contener enlaces de afiliado. Si compras desde estos enlaces, el precio para ti es el mismo y la tienda me paga una pequeña comisión que ayuda a mantener Tecnoyfoto.
En casa tengo decenas de avisos por voz en Home Assistant: lavadora, secadora, lavaplatos, consumo alto, puertas abiertas, lluvia, timbre, recordatorios y avisos varios. Durante años cada automatización llamaba directamente a uno o varios servicios tipo notify.papi_hablar, notify.echo_show_8_hablar, tts.google_say o similares.
El problema es sencillo: eso funciona, hasta que deja de funcionar.
- Durante una temporada me falló Alexa Media Player y lo estable era Alexa Devices.
- Después pasó al revés: Alexa Devices empezó a fallar y volvió a funcionar Alexa Media Player.
- Y en alguna actualización de Home Assistant, como la beta 2026.7.0b1, me fallaron las dos vías de Alexa y los avisos acabaron saliendo por Google Home.
Ese último caso fue la prueba definitiva: la centralita hizo exactamente lo que tenía que hacer. Alexa no hablaba, así que Home Assistant mandó los mensajes a Google. Cuando en la siguiente beta Alexa volvió a funcionar, los avisos volvieron automáticamente a Alexa.
La solución que uso es una centralita de mensajes: todas las automatizaciones llaman a un único script, y ese script decide por dónde hablar. Si cambia el backend, no tengo que tocar decenas de automatizaciones. Toco un sitio, o directamente dejo que el modo automático decida.
0. Qué vas a conseguir
Con esta centralita tendrás:
- Un único script para todos los avisos:
script.anunciar_por_voz_alexa_google_2. - Un selector
input_select.voz_backendcon cuatro modos:auto,alexa_media,alexa_devicesygoogle. - Un selector
input_select.voz_modopara elegir entrehablaryanunciar. - Un booleano
input_boolean.no_molestarpara silenciar la casa salvo avisos urgentes. - Un fallback real por estado de integración: primero Alexa Media Player, luego Alexa Devices, y si no hay Alexa disponible, Google Home.
- Una regla personal para mi caso: si estoy en Turno noche, el altavoz lógico
papino habla entre las 06:00 y las 12:00.
La idea clave: tus automatizaciones no llaman directamente a Alexa ni a Google. Llaman a un script. El script decide el backend.
Limitación importante: el modo auto elige el backend antes de enviar el mensaje. No es un sistema de reintento por mensaje. Si Alexa Media Player está marcada como OK pero una llamada concreta falla justo en ese momento, ese mensaje no salta automáticamente a Google dentro de la misma ejecución. Lo que sí hace muy bien es evitar depender de una integración cuando ya está caída o marcada como no disponible.
1. Mis altavoces lógicos
El script no trabaja directamente con nombres de entidades en cada automatización. Usa tres nombres lógicos:
papishowpop
Luego el script traduce esos nombres al backend que toque.
| Lógico | Alexa Media Player | Alexa Devices | |
|---|---|---|---|
papi | notify.alexa_media_papi | notify.papi_hablar / notify.papi_anunciar | media_player.nesthub81f6_2 |
show | notify.alexa_media_echo_show_8 | notify.echo_show_8_hablar / notify.echo_show_8_anunciar | media_player.googlehome6398 |
pop | notify.alexa_media_echo_pop_de_albert | notify.echo_pop_de_albert_hablar / notify.echo_pop_de_albert_anunciar | media_player.nestaudio5858 |
Esto es importante: si una automatización manda devices: salon y el script no conoce salon, no sonará nada. Yo he preferido estandarizar y usar siempre papi, show y pop.
2. Integraciones que uso
Mi centralita usa tres caminos:
- Alexa Media Player, integración de HACS. Funciona muy bien, pero usa una API no oficial de Amazon. Su propio repositorio avisa de que imita la app de Alexa y que Amazon puede cortar el acceso en cualquier momento: alexa_media_player en GitHub.
- Alexa Devices, integración oficial de Home Assistant. Crea entidades
notifyde tipo hablar/anunciar y se usan connotify.send_message. Requiere doble factor con app autenticadora, no SMS, y puede sufrir límites de Amazon comoToo many requests: documentación oficial de Alexa Devices. - Google Home, usando
tts.google_saycon Google Translate TTS. En instalaciones nuevas Home Assistant recomiendatts.speak, pero en mi instalación actualtts.google_sayfunciona y por eso no lo he cambiado: documentación de Google Translate TTS.
Mi consejo: no confíes tus avisos críticos a una sola integración de voz. Alexa Media Player y Alexa Devices pueden fallar por motivos distintos, y Google es una salida de emergencia muy práctica.
Nota sobre packages: mi Home Assistant ya tiene activado homeassistant: packages: !include_dir_named packages, así que técnicamente podría meter toda esta centralita en un único archivo tipo /config/packages/centralita_voz.yaml. No lo he movido porque mi instalación ya está organizada por archivos separados y así evito duplicar helpers o scripts. Para este artículo sigo mi estructura real: helpers en sus YAML, sensores en templates.yaml, servicios en configuration.yaml y el script en scripts.yaml.
3. Helpers necesarios
Dónde guardarlo en mi estructura: los input_boolean van en /config/input_booleans.yaml y los input_select van en /config/input_selects.yaml. En configuration.yaml ya tengo estas inclusiones: input_boolean: !include input_booleans.yaml e input_select: !include input_selects.yaml.
Estos son los helpers que uso en YAML.
input_boolean:
no_molestar:
name: No molestar
icon: mdi:minus-circle
alexa_devices_ok:
name: Alexa Devices OK
icon: mdi:amazon-alexainput_select:
voz_backend:
name: Backend de voz
options:
- auto
- alexa_media
- alexa_devices
- google
initial: auto
icon: mdi:account-voice
voz_modo:
name: Modo de voz
options:
- hablar
- anunciar
initial: hablarEn mi caso voz_backend arranca en auto. Si fuerzas manualmente alexa_media, alexa_devices o google, el script respeta tu elección aunque ese backend esté caído. Eso es intencionado: manual significa manual.
4. Sensores de salud para el modo auto
Dónde guardarlo en mi estructura: este bloque está en /config/templates.yaml. Mi Home Assistant lo carga porque /config/templates_migrated/00-existing.yaml incluye ../templates.yaml, y configuration.yaml carga template: !include_dir_merge_list templates_migrated.
El modo auto necesita saber si Alexa Media Player y Alexa Devices están disponibles. En mi instalación uso estos dos sensores.
template:
- binary_sensor:
- name: "Alexa Media Player - Integración OK"
unique_id: alexa_media_player_ok
device_class: connectivity
state: >
{% set entidades = [
'media_player.papi',
'media_player.echo_show_8',
'media_player.echo_pop_de_albert'
] %}
{% set ns = namespace(caidas=0) %}
{% for e in entidades %}
{% if is_state(e, 'unavailable') or is_state(e, 'unknown') %}
{% set ns.caidas = ns.caidas + 1 %}
{% endif %}
{% endfor %}
{{ ns.caidas < entidades | count }}
attributes:
resumen: >
{% set entidades = [
'media_player.papi',
'media_player.echo_show_8',
'media_player.echo_pop_de_albert'
] %}
{% set ns = namespace(caidas=0) %}
{% for e in entidades %}
{% if is_state(e, 'unavailable') or is_state(e, 'unknown') %}
{% set ns.caidas = ns.caidas + 1 %}
{% endif %}
{% endfor %}
{% if ns.caidas == entidades | count %}
Todas las entidades están unavailable/unknown, Alexa Media Player probablemente caído
{% elif ns.caidas > 0 %}
Algunas entidades están unavailable/unknown, pero otras siguen respondiendo
{% else %}
Todas las entidades responden con normalidad
{% endif %}
- name: "Alexa Devices - Integración OK"
unique_id: alexa_devices_ok_sensor
device_class: connectivity
state: >
{{ is_state('input_boolean.alexa_devices_ok', 'on') }}
attributes:
detalle: >
{% if is_state('input_boolean.alexa_devices_ok', 'on') %}
Última prueba de Alexa Devices correcta.
{% else %}
Última prueba de Alexa Devices fallida o no ejecutada.
{% endif %}Alexa Media Player lo considero OK si al menos uno de mis tres media_player principales está disponible. Alexa Devices lo controlo con input_boolean.alexa_devices_ok, porque a veces las entidades pueden existir aunque el backend no esté realmente sano.
En mi configuración estos sensores están en templates.yaml, incluido desde templates_migrated/00-existing.yaml, y Home Assistant carga templates_migrated desde configuration.yaml.
5. Notify y TTS en mi configuration.yaml
Dónde guardarlo en mi estructura: este bloque va directamente en /config/configuration.yaml, dentro de las secciones notify: y tts:.
En mi instalación tengo grupos notify para los nombres de Alexa Media Player que usa el script, y Google TTS con el servicio google_say.
notify:
- platform: group
name: alexa_media_papi
services:
- service: papi_hablar
- platform: group
name: alexa_media_echo_show_8
services:
- service: echo_show_8_hablar
- platform: group
name: alexa_media_echo_pop_de_albert
services:
- service: echo_pop_de_albert_hablar
tts:
- platform: google_translate
service_name: google_say
language: 'es'Si partes de cero, adapta esta parte a tus entidades reales. Lo importante es que el script pueda llamar a los servicios o entidades que aparecen en cada backend.
6. Ajustar volumen al activar No molestar
En mi instalación, No molestar no solo bloquea avisos normales. También lo uso para cambiar volúmenes.
Cuando input_boolean.no_molestar pasa a on, aplico volumen de noche. Cuando pasa a off, aplico volumen de día.
Para eso uso dos scripts muy simples: uno para volumen de día y otro para volumen de noche. En mi caso, el de día deja los altavoces al 60% y el de noche al 15%.
volumen_de_dia:
alias: Volumen de día
mode: single
sequence:
- service: media_player.volume_set
target:
entity_id:
- media_player.echo_dot_de_albert
- media_player.echo_dot_estudio
data:
volume_level: 0.6
volumen_de_noche:
alias: Volumen de noche
mode: single
sequence:
- service: media_player.volume_set
target:
entity_id:
- media_player.echo_dot_de_albert
- media_player.echo_dot_estudio
data:
volume_level: 0.15Estos nombres de entidades son los míos. En tu instalación tendrás que cambiarlos por tus propios media_player. También puedes ajustar los valores de volumen: 0.6 significa 60% y 0.15 significa 15%.
Una vez creados los scripts, uso una automatización que escucha los cambios de input_boolean.no_molestar. Si se activa, lanza el volumen de noche. Si se desactiva, lanza el volumen de día.
- id: no_molestar_ajuste_volumen
alias: "No molestar: ajustar volumen al activar/desactivar"
trigger:
- platform: state
entity_id: input_boolean.no_molestar
to: "on"
id: activado
- platform: state
entity_id: input_boolean.no_molestar
to: "off"
id: desactivado
action:
- choose:
- conditions:
- condition: trigger
id: activado
sequence:
- service: script.turn_on
target:
entity_id: script.volumen_de_noche
- conditions:
- condition: trigger
id: desactivado
sequence:
- service: script.turn_on
target:
entity_id: script.volumen_de_dia
mode: singleEsto ya depende mucho de cada casa. Puedes tener scripts de volumen, escenas, automatizaciones por habitación o simplemente no tocar el volumen. Lo importante es entender que el booleano puede servir como disparador para otras acciones.
7. El script maestro
Dónde guardarlo en mi estructura: este bloque va en /config/scripts.yaml. Como en configuration.yaml tengo script: !include scripts.yaml, Home Assistant lo cargará como script.anunciar_por_voz_alexa_google_2.
Este es el corazón de la centralita. Es el script que llaman todas mis automatizaciones.
anunciar_por_voz_alexa_google_2:
alias: Anunciar por voz (Alexa / Google)
mode: queued
max: 10
fields:
message:
description: Texto que los altavoces dirán
example: "Prueba de voz"
devices:
description: "Lista de altavoces lógicos: papi, show, pop."
example: "['papi', 'show']"
urgent:
description: "Si es true, ignora el modo No molestar."
example: "false"
modo:
description: "Cómo hablar: 'hablar' (normal) o 'anunciar' (broadcast)."
example: "hablar"
sequence:
- condition: template
value_template: >
{{ (urgent | default(false)) or not is_state('input_boolean.no_molestar', 'on') }}
- variables:
devs: >
{% set d = devices | default('papi') %}
{% if d is string %}
{{ [d] }}
{% else %}
{{ d }}
{% endif %}
modo_local: "{{ (modo | default('hablar')) | lower }}"
backend_config: "{{ states('input_select.voz_backend') }}"
backend_efectivo: >
{% if backend_config != 'auto' and backend_config in ['alexa_media', 'alexa_devices', 'google'] %}
{{ backend_config }}
{% else %}
{% if is_state('binary_sensor.alexa_media_player_integracion_ok', 'on') %}
alexa_media
{% elif is_state('binary_sensor.alexa_devices_integracion_ok', 'on') %}
alexa_devices
{% else %}
google
{% endif %}
{% endif %}
silenciar_papi_noche: >
{{ is_state('input_select.jornada_laboral', 'Turno noche')
and now().hour >= 6
and now().hour < 12 }}
- service: logbook.log
data:
name: Centralita voz
entity_id: input_select.voz_backend
message: >-
Backend {{ backend_efectivo | trim }} (selector {{ backend_config | trim }}) -> {{ devs }}
- choose:
- conditions:
- condition: template
value_template: "{{ backend_efectivo == 'alexa_media' }}"
sequence:
- repeat:
for_each: "{{ devs }}"
sequence:
- choose:
- conditions:
- condition: template
value_template: >
{{ repeat.item == 'papi' and not silenciar_papi_noche }}
sequence:
- service: notify.alexa_media_papi
data:
message: "{{ message }}"
data:
type: >
{% if modo_local == 'anunciar' %}
announce
{% else %}
tts
{% endif %}
- conditions:
- condition: template
value_template: "{{ repeat.item == 'show' }}"
sequence:
- service: notify.alexa_media_echo_show_8
data:
message: "{{ message }}"
data:
type: >
{% if modo_local == 'anunciar' %}
announce
{% else %}
tts
{% endif %}
- conditions:
- condition: template
value_template: "{{ repeat.item == 'pop' }}"
sequence:
- service: notify.alexa_media_echo_pop_de_albert
data:
message: "{{ message }}"
data:
type: >
{% if modo_local == 'anunciar' %}
announce
{% else %}
tts
{% endif %}
- conditions:
- condition: template
value_template: "{{ backend_efectivo == 'alexa_devices' }}"
sequence:
- repeat:
for_each: "{{ devs }}"
sequence:
- choose:
- conditions:
- condition: template
value_template: >
{{ repeat.item == 'papi' and not silenciar_papi_noche }}
sequence:
- service: notify.send_message
target:
entity_id: >
{% if modo_local == 'anunciar' %}
notify.papi_anunciar
{% else %}
notify.papi_hablar
{% endif %}
data:
message: "{{ message }}"
- conditions:
- condition: template
value_template: "{{ repeat.item == 'show' }}"
sequence:
- service: notify.send_message
target:
entity_id: >
{% if modo_local == 'anunciar' %}
notify.echo_show_8_anunciar
{% else %}
notify.echo_show_8_hablar
{% endif %}
data:
message: "{{ message }}"
- conditions:
- condition: template
value_template: "{{ repeat.item == 'pop' }}"
sequence:
- service: notify.send_message
target:
entity_id: >
{% if modo_local == 'anunciar' %}
notify.echo_pop_de_albert_anunciar
{% else %}
notify.echo_pop_de_albert_hablar
{% endif %}
data:
message: "{{ message }}"
- conditions:
- condition: template
value_template: "{{ backend_efectivo == 'google' }}"
sequence:
- repeat:
for_each: "{{ devs }}"
sequence:
- choose:
- conditions:
- condition: template
value_template: >
{{ repeat.item == 'papi' and not silenciar_papi_noche }}
sequence:
- service: tts.google_say
data:
entity_id: media_player.nesthub81f6_2
message: "{{ message }}"
- conditions:
- condition: template
value_template: "{{ repeat.item == 'show' }}"
sequence:
- service: tts.google_say
data:
entity_id: media_player.googlehome6398
message: "{{ message }}"
- conditions:
- condition: template
value_template: "{{ repeat.item == 'pop' }}"
sequence:
- service: tts.google_say
data:
entity_id: media_player.nestaudio5858
message: "{{ message }}"La llamada a logbook.log no envía ningún aviso. Solo deja una pista en el Logbook con el backend elegido. Cuando algo no suena, esto ayuda mucho: puedes ver si el mensaje se intentó por Alexa Media, Alexa Devices o Google.
8. Cómo llamar al script
Dónde guardarlo en mi estructura: estos ejemplos van dentro de tus automatizaciones, por ejemplo en archivos de /config/automations/ o en el archivo donde ya tengas el aviso de lavadora, lluvia, timbre, etc. No van dentro del script maestro.
Desde este momento, las automatizaciones no llaman directamente a notify.xxx. Llaman al script.
- service: script.anunciar_por_voz_alexa_google_2
data:
message: "La lavadora ya terminó. Acuérdate de tender la ropa."
devices:
- papi
- show
urgent: false
modo: "{{ states('input_select.voz_modo') }}"Para un aviso importante:
- service: script.anunciar_por_voz_alexa_google_2
data:
message: "Atención. El consumo de la casa es muy elevado."
devices:
- papi
- show
- pop
urgent: true
modo: "anunciar"También puedes mandar un único dispositivo como texto, porque el script lo convierte en lista:
- service: script.anunciar_por_voz_alexa_google_2
data:
message: "Tocan el telefonillo."
devices: show
urgent: false
modo: "{{ states('input_select.voz_modo') }}"9. Modo automático: orden real de prioridad
Cuando input_select.voz_backend está en auto, el orden es:
- Si
binary_sensor.alexa_media_player_integracion_okestá enon, usaalexa_media. - Si Alexa Media no está OK pero
binary_sensor.alexa_devices_integracion_okestá enon, usaalexa_devices. - Si ninguna de las dos está OK, usa
google.
Este orden fue el que me salvó en la beta 2026.7: Alexa falló, Google habló, y cuando Alexa volvió a estar disponible el sistema volvió a Alexa sin tocar automatizaciones.
10. Alexa Devices: qué mirar si se queda inicializando
Alexa Devices es oficial y sigue activa en Home Assistant, pero depende de Amazon. Si se queda en “Inicializando” o aparecen entidades no disponibles, yo miraría los registros antes de borrar y crear la integración muchas veces.
- Busca
alexa_devicesoaioamazondevicesen Configuración > Sistema > Registros. - Si ves
Too many requests, probablemente Amazon está limitando peticiones. Mejor esperar y no insistir. - Si ves errores tipo
CannotAuthenticate, revisa usuario, contraseña y que el 2FA preferido sea una app autenticadora, no SMS. - Si ves errores de recuperación de datos después de autenticar, puede ser un problema temporal de Amazon o de la librería.
Por eso Alexa Devices está en mi centralita como segundo backend, pero no lo uso como única vía crítica. Si falla, Google sigue ahí.
11. Migración de automatizaciones
Este es, probablemente, el punto más delicado de todo el proyecto. Crear la centralita es relativamente fácil; lo que da respeto es actualizar automatizaciones existentes sin romper avisos que ya funcionan.
Mi recomendación es hacerlo con calma y, si puedes, con ayuda de una IA de programación como Codex. No porque sea imposible hacerlo a mano, sino porque Codex puede revisar todos tus YAML, encontrar llamadas antiguas a notify., tts., Alexa o Google, y cambiarlas siguiendo un patrón común.
Antes de tocar muchas automatizaciones, te recomiendo leer también estos dos artículos:
- Cómo limpiar el log de Home Assistant, porque revisar errores después de la migración ayuda muchísimo.
- IA para tu hogar digital, donde explico cómo uso la IA para mantener y mejorar mi instalación.
El proceso que yo seguiría es este:
- Haz copia de seguridad antes de tocar nada.
- Migra primero 2 o 3 automatizaciones sencillas, por ejemplo lavadora, lluvia o un aviso no crítico.
- Comprueba que suenan por la centralita y que aparece la entrada
Centralita vozen el Logbook. - Después migra el resto por grupos, no todo a ciegas.
Este sería un buen prompt para darle a Codex:
Estoy trabajando en mi configuración de Home Assistant.
Quiero migrar mis avisos por voz antiguos para que dejen de llamar directamente a notify.*, tts.google_say, Alexa Media Player, Alexa Devices o Google Home, y pasen a usar este script central:
script.anunciar_por_voz_alexa_google_2
El patrón nuevo debe ser:
- service: script.anunciar_por_voz_alexa_google_2
data:
message: "Texto del aviso"
devices:
- papi
- show
urgent: false
modo: "{{ states('input_select.voz_modo') }}"
Antes de modificar nada:
1. Revisa los archivos YAML de automatizaciones y scripts.
2. Localiza llamadas directas relacionadas con avisos por voz: notify.*, tts.*, alexa_media, alexa_devices, google_say o servicios similares.
3. No toques notificaciones que NO sean avisos por voz, por ejemplo Telegram, móvil, persistent_notification o logs, salvo que esté clarísimo que forman parte del mismo aviso y deban quedarse como acción adicional.
4. Haz copia de seguridad de cada archivo que vayas a modificar.
Al migrar:
1. Mantén el texto original del mensaje.
2. Convierte el destino al campo devices usando estos nombres lógicos:
- papi para el altavoz principal del estudio
- show para Echo Show 8 / Google Home estancia
- pop para Echo Pop de Albert / Nest Audio cocina
3. Si no puedes deducir con seguridad el destino, no inventes: deja un comentario o avísame.
4. Usa urgent: false por defecto.
5. Usa urgent: true solo en avisos claramente importantes o de riesgo, como consumo eléctrico peligroso, alarmas, puertas críticas o seguridad.
6. Usa modo: "{{ states('input_select.voz_modo') }}" salvo que la automatización tenga sentido claramente como anuncio fijo.
7. Conserva otras acciones existentes, como notify.telegram, esperas, condiciones o cambios de estado.
Después de modificar:
1. Enséñame un resumen de los cambios.
2. Dime qué automatizaciones has migrado.
3. Dime cuáles no has tocado porque había dudas.
4. Valida que el YAML siga siendo correcto.
5. No reinicies Home Assistant ni borres nada sin pedírmelo.Una vez migrado, cambiar de backend o de modo de voz es cuestión de tocar un desplegable, no decenas de automatizaciones. Y si una integración de Alexa cae, la centralita puede mandar los avisos por otra vía sin que tengas que reescribir media casa.
12. Errores típicos
- Nombres lógicos mal escritos: si mandas
salonpero el script solo conocepapi,showypop, no sonará. - No molestar activo: si pruebas y no suena, prueba con
urgent: truepara descartar el bloqueo. - Backend manual roto: si fuerzas
alexa_devicesy Alexa Devices está mal, el script lo respetará. Para fallback automático, usaauto. - Google no reproduce TTS: revisa la URL interna de Home Assistant. Los dispositivos Cast pueden fallar si no pueden resolver o descargar el audio generado por TTS.
13. Resumen final
Esta centralita me ha permitido pasar de avisos repartidos por toda la configuración a un sistema mucho más limpio:
- Un único script para todos los avisos.
- Prioridad automática: Alexa Media Player, Alexa Devices y Google.
- Modo manual cuando quiero forzar un backend concreto.
no_molestaryurgentpara controlar cuándo habla la casa.voz_modopara cambiar entre hablar y anunciar.- Una salida de emergencia real por Google cuando Alexa falla.
No es magia ni hace reintentos infinitos. Pero en la práctica evita lo peor: que una caída de Alexa te deje sin avisos por voz en casa. Y en mi caso ya lo ha demostrado en una actualización beta real de Home Assistant.
12. Anexo: otros altavoces y backends posibles
Todo el artículo está basado en mi instalación real: Alexa Media Player, Alexa Devices y Google Home. Es lo que tengo en casa, lo que he probado y lo que puedo decir que funciona.
Pero la idea de la centralita no está limitada a Alexa ni a Google. Lo importante no es el backend concreto, sino la arquitectura:
Las automatizaciones no hablan directamente con un altavoz. Hablan con un script central, y ese script decide por dónde sale el mensaje.
Eso significa que, en teoría, se podrían añadir otros sistemas de voz como backend adicional. No los meto en el código principal porque no los uso en mi casa y no quiero publicar una receta que no haya probado personalmente, pero sí merece la pena comentarlos.
12.1 Home Assistant, TTS local, Piper y Assist
Home Assistant tiene su propio sistema de Text-to-speech. Dicho de forma simple: Home Assistant puede generar una frase hablada y enviarla a un media_player compatible.
Además, existen opciones como Piper, que permite usar voces locales mediante el protocolo Wyoming. Piper no es “un altavoz” como tal: es el motor que genera la voz. Luego necesitas un dispositivo capaz de reproducir ese audio, por ejemplo un altavoz integrado como media_player o algún dispositivo preparado para voz.
También está todo el ecosistema de Assist, los satélites de voz y dispositivos tipo Home Assistant Voice. Aquí la idea ya no es solo que Home Assistant hable, sino que también pueda escuchar y responder. Para esta centralita, lo interesante sería la parte de salida de voz: si ese dispositivo puede reproducir mensajes desde Home Assistant, podría convertirse en otro backend más.
Un ejemplo genérico de TTS moderno en Home Assistant sería algo parecido a esto:
- action: tts.speak
target:
entity_id: tts.piper
data:
media_player_entity_id: media_player.altavoz_salon
message: "Prueba de aviso desde Home Assistant."Ojo: esto es solo un ejemplo de concepto. Los nombres reales tts.piper y media_player.altavoz_salon tendrías que cambiarlos por los de tu instalación.
Si algún día quisiera añadirlo a mi centralita, probablemente crearía un backend nuevo llamado algo como homeassistant_tts o piper. Pero lo dejaría como ampliación avanzada, no como parte del montaje base.
12.2 HomePod y HomePod mini
En el ecosistema Apple, los altavoces se llaman HomePod y HomePod mini. En Home Assistant pueden aparecer relacionados con integraciones como Apple TV, AirPlay o dispositivos multimedia, según la instalación.
Aquí sería prudente no prometer demasiado. Apple suele ser un ecosistema más cerrado y el comportamiento puede variar bastante según la red, las versiones, el emparejamiento y cómo aparezca el dispositivo dentro de Home Assistant.
La regla práctica sería esta:
Si tu HomePod aparece en Home Assistant como un
media_playercapaz de reproducir audio o recibir TTS, en teoría se podría integrar en una centralita como esta.
Pero como yo no uso HomePod en casa, no lo pondría dentro del código principal del artículo. Lo correcto sería que quien tenga altavoces Apple pruebe primero si puede hacerlos hablar desde una acción normal de Home Assistant. Si eso funciona, entonces se podría plantear añadir un backend específico para Apple.
12.3 Mi recomendación práctica
La ventaja de este sistema es precisamente esa: no estás construyendo una solución “de Alexa”. Estás construyendo una capa intermedia para que tus automatizaciones no dependan de ningún altavoz concreto.
