Un viejo teléfono Android parece perfecto para una casa inteligente: micrófonos, pantalla, Wi‑Fi, altavoz y batería ya están ahí. En una casa con Home Assistant, la idea sería decir “Okay Nabu” y controlar luces o persianas de forma local, sin un altavoz en la nube.

Teléfono Android antiguo como panel de voz local para casa inteligente

Hoy sigue siendo incómodo. Assist en Android existe, pero el always‑on wake word no depende sólo de una opción en Home Assistant. Depende del acceso al camino de bajo consumo del sistema operativo. Ese camino suele usar un DSP, y durante años no estuvo disponible en igualdad de condiciones para asistentes de terceros.

Open Home Foundation explicó el 31 de julio por qué la decisión europea sobre Android interoperability importa en la vida diaria. La página oficial de la Comisión Europea confirma una decisión final del 16 de julio de 2026 bajo el DMA: Alphabet debe abrir 11 capacidades de Android para servicios de IA. Android 18 debe implementar las medidas principales antes del 1 de agosto de 2027; concurrent hotword detection llegará como máximo con Android 19 antes del 1 de agosto de 2028.

El problema doméstico

Un dashboard funciona para quien construyó el sistema. Para familia, invitados, niños, personas mayores o cuidadores, la voz puede ser el interfaz más natural. “Enciende la cocina”, “baja las persianas”, “modo noche” no deberían depender necesariamente de una nube.

Home Assistant Assist quiere mover ese control de vuelta a casa con pipelines locales y entidades expuestas de forma explícita. Pero un asistente local necesita oír su frase de activación.

Por qué importa el DSP

Un wake word eficiente suele usar dos etapas: un DSP de bajo consumo escucha primero; si detecta una posibilidad, la CPU despierta para validar y procesar la orden. Si una app no puede usar ese camino, debe mantener más trabajo en la CPU y parecer una grabación continua normal.

OHF dice que su workaround con microWakeWord en CPU funcionaba, pero con costes: batería mucho mayor, indicador verde de micrófono permanente y necesidad de convertir Home Assistant en default assistant para sobrevivir a reinicios. Eso no es una solución doméstica limpia.

Qué exige la decisión

La Comisión habla de interoperabilidad igualmente efectiva, sin fricción innecesaria y sin condicionar el acceso al default assistant role. También exige hotwords concurrentes para que varios servicios puedan activarse por voz.

Para una casa, eso cambia el diseño: el teléfono podría seguir usando Gemini para tareas generales y escuchar una frase local para Home Assistant. Nadie debería elegir entre el asistente del teléfono y el asistente de la casa.

Riesgos y límites

Google advierte que estas capacidades son sensibles: micrófonos, sensores, contexto de apps y screen automation pueden ser peligrosos si se entregan mal. Es una preocupación real. La respuesta no debería ser acceso indiscriminado, sino permisos claros, consentimiento, logs, revocación y documentación.

Tampoco conviene comprar hardware hoy por una promesa. El soporte dependerá de Android 18/19, de OEMs, de regiones y de cómo Google implemente la decisión.

Qué hacer ahora

Use Assist con push‑to‑talk, dashboards, botones físicos y NFC tags. Si necesita voz local ya, mire ESPHome satellites, ESP32‑S3, Home Assistant Voice Preview Edition o proyectos tipo Atom Echo. Use viejos Android como paneles primero y como experimento de voz después.

Mantenga fallbacks físicos para cerraduras, alarmas, calefacción y rutinas importantes. Un micrófono local puede fallar; una casa práctica no debe depender sólo de hablar.

Conclusión

La decisión puede convertir un Android viejo en un buen voice satellite local. Todavía no es un producto listo. Pero sí señala algo importante: la casa inteligente no será realmente local mientras la entrada de voz eficiente dependa de un gatekeeper de la nube.