¿Cuánta concurrencia de automatizaciones necesita Home Assistant para controlar toda la casa?

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

Home Assistant no necesita un número de concurrencia para toda la casa; cada automatización necesita suficiente solapamiento para su frecuencia de activación y duración de ejecución sin violar el orden.

Diez habitaciones y doscientas entidades no implican diez o doscientas ejecuciones de automatizaciones en paralelo. La cantidad útil es por flujo de trabajo: con qué frecuencia puede activarse, cuánto tiempo permanece activa una ejecución, si las ejecuciones posteriores reemplazan a las anteriores y cuánto trabajo paralelo puede aceptar el dispositivo o servicio de destino. Empieza con uno cuando el orden sea importante y añade concurrencia solo cuando el trabajo superpuesto real sea independiente y sensible a los plazos.

Estima el solapamiento necesario a partir de la frecuencia de activación y la duración de la ejecución

Una primera estimación de planificación es multiplicar la tasa de llegada por la duración activa media. Si una automatización se activa una vez cada diez segundos y normalmente termina en un segundo, su demanda de solapamiento habitual es muy inferior a uno. Si las ráfagas producen cinco activaciones por segundo mientras cada ejecución espera dos segundos, la demanda simultánea puede acercarse a diez, a menos que el flujo de trabajo combine, reinicie o ponga en cola esos eventos.

El análisis de la comunidad sobre los modos de automatización de Home Assistant muestra por qué la concurrencia es una decisión de comportamiento y no una fórmula basada en el número de dispositivos. Único, reinicio, en cola y paralelo representan respuestas distintas a la pregunta «¿qué debe ocurrir cuando llega otra activación antes de que termine esta ejecución?».

Usa la fórmula solo como estimación de carga de trabajo, no como recomendación de configuración. La intermitencia, las esperas prolongadas, las confirmaciones de los dispositivos y los tiempos de espera por errores pueden hacer que las ejecuciones más lentas duren mucho más que la media. Registra también la duración del percentil noventa y cinco o la peor duración normal, porque la concurrencia la consumen las ejecuciones que permanecen activas durante más tiempo.

El orden y la idempotencia establecen un límite más estricto que la CPU

Algunas acciones para toda la casa son lógicamente inseguras en paralelo incluso cuando el servidor tiene CPU de sobra. Las persianas motorizadas, las cerraduras, los cambios graduales de volumen multimedia, las válvulas de riego y los scripts con estado pueden recibir acciones contradictorias si se solapan varias ejecuciones independientes. En esos casos, el comportamiento en cola o de reinicio puede ser más correcto que la ejecución en paralelo.

Una explicación práctica de las automatizaciones de Home Assistant describe la cadena activador-condición-acción como un modelo de control determinista. La concurrencia debe preservar ese determinismo en lugar de maximizar el número de copias que el equipo puede programar técnicamente.

Pregunta si dos ejecuciones pueden realizarse en cualquier orden y aun así producir el mismo resultado seguro. Si no, no aumentes el paralelismo para solucionar la latencia: acorta la ejecución, combina las entradas o serializa en el destino. Más concurrencia no significa más rendimiento cuando el dispositivo posterior acepta una sola orden significativa cada vez.

Los servicios posteriores definen el límite útil

Incluso las ejecuciones independientes terminan convergiendo en recursos finitos: un coordinador Zigbee, un intermediario MQTT, una API de proveedor, un servicio de notificaciones, una base de datos, un canal Wi-Fi o un dispositivo físico. Un análisis independiente de la concurrencia de Home Assistant señala que las instancias de automatización son tareas y que las acciones de servicio pueden suspenderse durante la E/S externa, por lo que programar más ejecuciones no hace que el sistema posterior las procese más rápido. Las ejecuciones adicionales solo pueden crear reintentos, colas, límites de frecuencia o un tiempo de finalización más largo.

ZimaSpace describe el mismo límite en el escalado de trabajadores basado en eventos: la profundidad de la cola puede justificar más trabajadores solo hasta que la ruta posterior se convierta en el recurso limitante. La concurrencia de las automatizaciones de Home Assistant debe detenerse en ese mismo tipo de límite de servicio.

Para una ráfaga de iluminación local, mide cuántas llamadas de servicio simultáneas puede absorber el coordinador sin confirmaciones retrasadas ni reintentos. Para las notificaciones, respeta los límites de frecuencia del proveedor. Para las acciones en la nube, ten en cuenta el comportamiento de los tiempos de espera. El máximo correcto es el menor límite impuesto por la corrección, la capacidad posterior y el objetivo de latencia, no el número más grande que la CPU pueda iniciar.

Usa umbrales en lugar de un número universal

Mantén la concurrencia en uno para los flujos de trabajo en los que una activación nueva reemplaza la intención anterior o debe preservarse el orden. Usa una cola pequeña cuando todos los eventos deban ejecutarse finalmente pero el destino sea secuencial. Usa ejecuciones paralelas solo para acciones independientes e idempotentes cuyo servicio posterior tenga margen medido. Aumenta el límite de una unidad cada vez mientras observas la antigüedad de la ejecución más antigua y la latencia de finalización.

Un caso del foro de Home Assistant sobre integraciones en la nube que ralentizan el sistema muestra por qué las esperas externas prolongadas pueden aumentar el trabajo activo. Es una advertencia clara contra calcular el máximo basándose únicamente en el comportamiento de una conexión WAN saludable cuando la misma automatización incluye llamadas a Internet.

Una regla práctica para detenerse es: ningún evento obligatorio perdido, ninguna cola más antigua que el plazo del hogar, ninguna violación del orden del destino y ningún aumento de la cola durante la peor ráfaga normal. Si se cumplen esas condiciones, una mayor concurrencia no aporta valor al usuario. Si fallan, primero acorta la etapa lenta o separa el trabajo independiente; aumenta el máximo solo cuando el solapamiento restante sea realmente seguro.

Realiza una prueba de ráfaga antes de cambiar el límite

Crea una ráfaga de eventos representativa en lugar de un bucle infinito sintético. Registra el número de activaciones, las ejecuciones activas, las ejecuciones en cola, la antigüedad de la ejecución más antigua, la duración de las acciones, la confirmación del dispositivo, la carga de CPU, el retraso del bucle de eventos si está disponible y los errores de la integración de destino. Repite la prueba con una configuración de concurrencia más alta y otra más baja, manteniendo la misma ráfaga de entrada.

Un artículo reciente sobre arquitectura local prioritaria destaca que la fiabilidad de Home Assistant depende de mantener acotadas las rutas de control críticas en lugar de añadir complejidad en todas partes. La concurrencia es uno de esos límites: debe absorber el solapamiento normal sin convertir una tormenta de eventos en una contención en toda la casa.

Elige la configuración más baja que complete el trabajo obligatorio dentro del plazo y sobreviva a la ráfaga sin que la cola crezca. Puede ser uno, una cola corta o un número paralelo moderado, según el flujo de trabajo. Repite la prueba después de añadir llamadas a la nube, esperas prolongadas o sensores de alta frecuencia, porque esos cambios modifican la duración y la tasa de llegada aunque el número de dispositivos siga siendo el mismo.

Preguntas frecuentes

¿El máximo predeterminado de 10 es un objetivo de concurrencia recomendado para todas las automatizaciones?

No. Un límite predeterminado es un mecanismo de seguridad, no una recomendación de dimensionamiento. Muchas automatizaciones funcionan correctamente con una sola ejecución, mientras que otras necesitan una cola acotada más pequeña o más grande según su carga de trabajo y el sistema posterior.

¿El modo paralelo hace que Home Assistant sea más rápido?

Solo cuando las ejecuciones son independientes y el cuello de botella puede procesarlas simultáneamente. Si el destino es secuencial, tiene límites de frecuencia o depende del orden, el modo paralelo puede aumentar la espera y los errores en lugar de reducir la latencia.

¿Cada habitación debería tener su propia automatización para reducir la concurrencia?

No necesariamente. Dividir la lógica puede mejorar la gestión, pero también puede crear más emisores independientes para el mismo dispositivo o asistente. La estructura debe seguir los límites de control y los requisitos de orden, no el objetivo de maximizar el número de automatizaciones.

Centro de Tecnología e IA

Más para leer

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.