Cómo dimensionar un servidor doméstico para Home Assistant y cortes de Internet

En un hogar donde la iluminación, la climatización, la respuesta ante fugas o las automatizaciones de acceso sean importantes durante una interrupción, el servidor solo cumple una función. La conmutación local, los coordinadores Wi‑Fi o de radio, el almacenamiento persistente, la alimentación mediante batería y una configuración recuperable deben permanecer coordinados. El diseño deja de estar preparado para interrupciones cuando una API en la nube necesaria, un router sin protección o un comportamiento de reinicio desconocido interrumpe el flujo de trabajo antes de que lo haga la capacidad de cálculo.

Define el objetivo de tolerancia ante interrupciones

Separa una interrupción del ISP de una interrupción eléctrica. Durante la pérdida del ISP, la LAN puede seguir funcionando y los dispositivos locales pueden continuar comunicándose. Durante un corte eléctrico, el host, el router, los switches, los puntos de acceso, los coordinadores, el NAS y los actuadores pueden fallar a la vez. Asigna a cada evento su propia duración y degradación aceptable.

Una conversación de la comunidad sobre la planificación ante cortes eléctricos distingue el control de dispositivos locales de la cuestión más amplia de qué elementos permanecen alimentados. Esa incertidumbre es el punto de partida correcto: inventaría las acciones críticas, sus dependencias de red y de la nube, y la alternativa manual. Un requisito genérico de «mantener Home Assistant en línea» es demasiado limitado para dimensionar la topología.

Clasifica cada flujo de trabajo como imprescindible, susceptible de degradarse o capaz de detenerse de forma segura. Una válvula contra fugas y una protección de la calefacción pueden tener prioridad sobre los gráficos históricos, las notificaciones remotas y las consultas por voz. La configuración protegida solo necesita capacidad para el conjunto imprescindible más un margen de recuperación; el trabajo opcional puede pausarse o trasladarse fuera del host crítico.

Dimensiona el cálculo a partir de la carga de trabajo crítica

Mide la carga de trabajo principal de automatización con la WAN desconectada y ejecutando la secuencia de eventos locales más exigente. Registra la CPU sostenida y máxima, la presión de memoria, la espera de almacenamiento y la latencia de respuesta. Incluye la base de datos y solo los complementos necesarios para las acciones protegidas. Así obtendrás una referencia del servidor vinculada al servicio, no al número de dispositivos.

Mantén los modelos de voz locales, la inferencia de cámaras, el procesamiento multimedia y la compresión de copias de seguridad fuera de la ruta protegida, a menos que el requisito de interrupción los incluya explícitamente. Si comparten el host, utiliza límites de recursos o programación y reproduce su peor solapamiento. Divide un servicio solo cuando su pico haga que una acción crítica incumpla el objetivo de aceptación.

Añade margen para actualizaciones, mantenimiento del grabador y crecimiento, pero no conviertas ese margen en una categoría arbitraria de procesador. Un host tiene el tamaño adecuado cuando la secuencia crítica medida sigue respondiendo y el comportamiento de reinicio es predecible. Es demasiado grande para su función actual cuando la capacidad sin utilizar aumenta el consumo en reposo y la carga del SAI sin reducir un fallo concreto.

Construye una única ruta protegida de alimentación y red

Dibuja una ruta desde el sensor o el panel, pasando por la radio o el Wi‑Fi, la conmutación local, Home Assistant y el actuador. Coloca todos los componentes de red necesarios y el host en un circuito protegido por un SAI y medido. Una batería solo en el servidor no puede mantener el control si el router, el switch, el punto de acceso o el coordinador pierde la alimentación.

Un operador describe la protección del equipo de red, el almacenamiento y el servidor de Home Assistant con pequeños SAI, apagando los servidores en cuestión de minutos y manteniendo los equipos de red disponibles durante más tiempo. Los tiempos dependen de cada instalación, pero la separación de funciones resulta valiosa: el cálculo puede apagarse de forma segura mientras la ruta de comunicación local sigue siendo útil.

Mide la carga completa de las tomas, selecciona una autonomía objetivo y pruébala con la actividad máxima normal. Define si el host seguirá funcionando, se apagará correctamente o se reiniciará cuando vuelva la electricidad. Rechaza un diseño que no pueda recuperarse si la electricidad regresa mientras el SAI todavía tiene carga, porque ese caso límite puede dejar una batería en buen estado protegiendo un servicio desconectado.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separa el estado activo de las copias de recuperación

Mantén la configuración y la base de datos activa del grabador en un almacenamiento persistente supervisado que se inicie con el host protegido. Coloca las copias de recuperación en un destino independiente cuya pérdida no impida que la automatización local arranque. Un NAS puede ser un destino de copias de seguridad eficaz, pero no debe convertirse accidentalmente en un requisito previo para el servicio principal.

Una secuencia de interrupción documentada con Home Assistant y Synology muestra que ambos sistemas se apagan ante un evento del SAI, pero no vuelven a encenderse automáticamente cuando la electricidad regresa antes de que el SAI se agote por completo. El caso demuestra por qué la recuperación del almacenamiento, el host y la alimentación debe probarse como una única secuencia; unos componentes correctos por separado aún pueden producir un servicio no disponible.

Define la frecuencia de las copias de seguridad según la pérdida de datos aceptable y restaura una copia reciente en un medio alternativo o en una máquina de repuesto. Guarda las credenciales y los pasos en un lugar al que pueda acceder otro administrador del hogar. RAID, el almacenamiento duplicado o una segunda partición no sustituyen a la copia fuera del host, porque conservan el mismo dominio de fallo del operador y del sistema.

Valida la topología y establece criterios de ampliación

Realiza cuatro pruebas de aceptación: desconecta la WAN, deja fuera de servicio el destino de copias de seguridad, simula la acción de batería baja del SAI y restaura en otro hardware. Cronometra las automatizaciones críticas, el apagado, el reinicio y la restauración. Registra los fallos por cada enlace de la topología para que una actualización modifique la función que falla en lugar de añadir capacidad en todas partes.

La guía de ZimaSpace sobre la medición del rendimiento de Home Assistant más allá de la caché precalentada explica por qué las pruebas repetidas con la caché precalentada pueden ocultar los límites de arranque en frío o de carga máxima. Aplica ese método a la carga de trabajo protegida y compara el resultado con el consumo del SAI y el comportamiento de recuperación, en lugar de ampliar el host basándote en una ejecución cómoda con la caché ya cargada.

Amplía el cálculo cuando la latencia crítica medida falle después de descartar otros cuellos de botella. Amplía la capacidad de la batería cuando la autonomía de la ruta completa no alcance el objetivo. Divide los servicios pesados cuando el aislamiento resuelva el fallo. Deja de comprar hardware de servidor cuando un dispositivo que depende exclusivamente de la nube, un componente de red sin protección o una restauración no probada siga siendo el primer límite.

Regla final de configuración

El tamaño preparado para interrupciones es el de la topología protegida más pequeña que supere las pruebas de pérdida de WAN, autonomía eléctrica, reinicio y restauración del hogar. Aumenta el cálculo, la batería o el aislamiento solo cuando falle su límite medido. Si las dependencias de la nube o las carencias de control manual siguen dominando, soluciónalas antes de ampliar el servidor de Home Assistant.