Pocas cosas generan tanta frustración inicial como escribir una automatización, convencido de que está bien, y comprobar que simplemente no pasa nada cuando debería activarse. Nos ha ocurrido decenas de veces a lo largo de los años, con automatizaciones de todo tipo: desde las más simples, como encender una luz al detectar movimiento, hasta las más complejas, como las que coordinan varias zonas de climatización. En este artículo no vamos a darte una lista de errores comunes sin más: vamos a recorrer, exactamente en el orden en que lo hacemos nosotros mismos, el proceso completo de depuración de una automatización que no funciona, desde el primer vistazo hasta la causa raíz.
Paso uno: confirmar que la automatización está activada
Suena obvio, y precisamente por eso es el primer error que descartamos siempre antes de sospechar de nada más complejo. Es muy fácil desactivar una automatización sin querer al editarla, o dejarla desactivada después de una prueba puntual y olvidarse de reactivarla. Desde la lista general de automatizaciones, comprueba que el interruptor de esa automatización concreta está en posición activada, no solo que el archivo de configuración parece correcto.
Paso dos: revisar el trigger (disparador) de forma aislada
El error más habitual que hemos visto, tanto en nuestras propias automatizaciones como ayudando a otras personas, está en el disparador: una condición que nunca llega a cumplirse exactamente como se espera. Un ejemplo típico es esperar que un sensor pase a un estado concreto cuando, en realidad, ese sensor nunca reporta exactamente ese valor textual, sino uno ligeramente distinto en mayúsculas, con espacios, o con un formato numérico diferente al que imaginabas.
La forma más fiable de comprobar esto es ir a las Herramientas de desarrollador de Home Assistant, a la pestaña de Estados, y buscar la entidad en cuestión para ver exactamente qué valor reporta en este momento, tal cual, sin dar nada por supuesto. Si tu automatización espera el estado «on» y la entidad en realidad reporta «true», «open» u otro valor distinto, por mucho que la lógica del resto de la automatización sea perfecta, nunca llegará a dispararse.
Paso tres: usar la pestaña de trazas para ver qué ocurrió realmente
Esta es, con diferencia, la herramienta que más tiempo nos ha ahorrado a la hora de depurar automatizaciones complejas. Dentro de cada automatización, existe una pestaña de «Trazas» (Traces) que muestra, de forma visual, cada vez que la automatización se ha evaluado: si el disparador llegó a activarse, si las condiciones se cumplieron o no, y en qué paso exacto de las acciones se quedó, si es que llegó a ejecutarse alguna.
Si la traza muestra que la automatización nunca se evaluó, el problema está en el trigger, tal y como explicábamos en el paso anterior. Si en cambio sí se evaluó pero se detuvo antes de ejecutar ninguna acción, casi con toda seguridad el problema está en las condiciones, que vamos a revisar a continuación.
Paso cuatro: las condiciones silenciosas
Las condiciones son, en nuestra experiencia, la causa número dos de automatizaciones que «no funcionan» a pesar de que el disparador sí se active correctamente. Una condición que compara una temperatura usando un tipo de dato incorrecto (comparando un texto con un número, por ejemplo), o una condición de franja horaria mal definida que excluye sin querer el momento exacto en el que esperabas que se ejecutara, son errores extremadamente comunes y, a la vez, muy silenciosos: Home Assistant no muestra ningún error visible, simplemente detiene la ejecución sin más explicación en la interfaz básica.
De nuevo, la pestaña de trazas es tu mejor aliada aquí: te muestra exactamente qué condición ha fallado y qué valor tenía en ese momento, lo que suele ser suficiente para identificar el problema sin necesidad de añadir notificaciones de depuración manuales por todas partes.
Paso cinco: revisar el formato de las plantillas (templates)
Si tu automatización usa plantillas Jinja2 para calcular valores dinámicos, un error de sintaxis en la plantilla puede hacer que toda la automatización falle silenciosamente, o que se ejecute con un valor por defecto que no es el que esperabas. Las Herramientas de desarrollador incluyen una pestaña específica de «Plantilla», donde puedes pegar y probar cualquier fragmento de código Jinja2 de forma aislada, viendo el resultado exacto que generaría en ese momento, antes de usarlo dentro de una automatización real. Recomendamos probar siempre las plantillas complejas ahí primero, en lugar de depurarlas directamente dentro de la automatización en producción.
Paso seis: comprobar los registros (logs) del sistema
Si después de revisar trigger, condiciones y plantillas la automatización sigue sin comportarse como esperas, el siguiente paso es revisar el registro general de Home Assistant, accesible desde Ajustes > Sistema > Registros. Ahí aparecen errores más técnicos, como fallos de comunicación con una integración concreta, servicios que ya no existen porque se han renombrado en una actualización reciente, o entidades que, simplemente, ya no están disponibles en el sistema aunque sigan apareciendo en tu configuración.
Este paso es especialmente relevante después de haber actualizado Home Assistant a una versión nueva: los nombres de ciertos servicios y la forma de escribir algunas acciones han ido evolucionando con el tiempo, y una automatización que funcionaba perfectamente en una versión anterior puede dejar de hacerlo tras una actualización, sin que hayas tocado nada tú mismo.
Paso siete: aislar el problema simplificando la automatización
Si la automatización es compleja, con varias condiciones encadenadas y múltiples acciones, a veces la forma más rápida de encontrar el fallo no es seguir analizando la versión completa, sino crear una copia temporal simplificada al máximo: solo el trigger, sin condiciones, con una única acción de notificación de prueba. Si esa versión mínima funciona, el problema está en algo que has quitado; vas añadiendo piezas una a una hasta que vuelve a fallar, y ahí tienes exactamente el elemento problemático aislado, sin tener que revisar toda la lógica de golpe.
Un caso particular: automatizaciones que dependen de otras integraciones externas
Si tu automatización depende de datos externos, como el sensor de precios de la tarifa eléctrica que explicamos en nuestra guía de automatización según la tarifa PVPC, o de la previsión meteorológica que usamos en nuestra guía de riego inteligente según previsión, conviene comprobar primero que esa integración externa está funcionando y devolviendo datos actualizados, antes de asumir que el problema está en tu propia automatización. Un servicio externo caído, una clave de API caducada o un cambio en el formato de respuesta de una integración de terceros pueden parecer, desde fuera, un fallo de tu lógica cuando en realidad el problema está río arriba.
Prevenir en lugar de depurar: buenas prácticas para el futuro
Una vez resuelto el problema concreto que te ha traído hasta este artículo, merece la pena incorporar un par de hábitos que reducen drásticamente la cantidad de tiempo que tendrás que dedicar a depurar automatizaciones en el futuro. El primero es nombrar tus entidades de forma consistente y predecible, algo que además facilita mucho escribir automatizaciones genéricas que recorren varias zonas a la vez, como explicamos en algunas de nuestras guías de climatización. El segundo es probar siempre cualquier plantilla compleja en la pestaña de Plantilla de las Herramientas de desarrollador antes de usarla en producción, en lugar de depurarla directamente sobre una automatización que ya debería estar funcionando de verdad.
Documentación oficial
El proyecto Home Assistant mantiene documentación detallada sobre la sintaxis de automatizaciones, triggers, condiciones y acciones en home-assistant.io, así como una guía específica sobre cómo formular bien una pregunta de ayuda en su foro comunitario, que recomendamos revisar si después de este proceso de depuración sigues sin encontrar la causa y decides pedir ayuda a la comunidad.
Conclusión
Depurar una automatización que no funciona no tiene por qué ser un proceso de prueba y error a ciegas. Siguiendo un orden claro —activación, trigger, trazas, condiciones, plantillas, registros del sistema y, si hace falta, simplificación progresiva— casi siempre es posible llegar a la causa exacta en pocos minutos, en lugar de pasar horas cambiando cosas al azar con la esperanza de que algo funcione. Es, literalmente, el mismo proceso que seguimos nosotros cada vez que una automatización nueva no se comporta como esperábamos, y rara vez falla.