Optimización Brutal: Caching y Persistencia para Home Assistant en Almacenamiento Limitado

Gestión Crítica del Recorder de Home Assistant en Sistemas Embedidos

La sobrecarga del almacenamiento interno, típicamente tarjetas SD o eMMC en Single Board Computers (SBC) como Raspberry Pi, es la causa principal de fallos y degradación de rendimiento en instalaciones de Home Assistant. El componente recorder por defecto almacena cada evento y estado de entidad, generando una base de datos SQLite (home-assistant_v2.db) que crece exponencialmente.

Impacto de Datos No Optimizados

• Vida útil de almacenamiento: Las operaciones intensivas de escritura acortan drásticamente la vida útil de las tarjetas SD. Un ciclo de escritura/borrado limitado se agota rápidamente.
• Rendimiento: Consultas a bases de datos masivas ralentizan la interfaz de usuario y los automatismos, afectando la experiencia de usuario y la fiabilidad del sistema.
• Disponibilidad: El llenado completo del disco puede provocar fallos críticos en el sistema operativo o en Home Assistant, impidiendo el arranque o la operación.

Estrategias de Persistencia de Base de Datos

La elección y configuración de la base de datos es el pilar para la gestión de almacenamiento, impactando directamente la resiliencia y velocidad del sistema.

Optimización de SQLite (Opción por Defecto)

Por defecto, Home Assistant utiliza SQLite. Aunque es ligero, su rendimiento decae drásticamente con bases de datos grandes y en medios de almacenamiento lentos, como las tarjetas SD.

• Parámetro clave: purge_keep_days y exclude/include.

yaml

configuration.yaml

recorder: purge_keep_days: 7 # Reducir a 7 días (por defecto es 10) para limitar el tamaño del historial. commit_interval: 30 # Aumentar a 30 segundos (por defecto es 5) para reducir la frecuencia de escrituras en disco. exclude: domains: - automation - script - binary_sensor # Excluir sensores de movimiento ruidosos si su historial no es crítico. - sun # El estado del sol rara vez es útil en el historial. entities: - sensor.uptime # No crítico almacenar historial. - sensor.temperatura_cpu # Alto volumen, si solo interesa el valor actual para dashboards. - sensor.potencia_solar_actual # Si ya se exporta a InfluxDB o similar. include: domains: - switch # Incluir solo lo que sea realmente útil para el historial. - light entities: - sensor.temperatura_ambiente_salon

⚠️ ADVERTENCIA TÉCNICA: Excluir automation o script del recorder significa que no se visualizará el historial de cuándo se ejecutaron en el logbook. Evalúe la necesidad de esta información antes de la exclusión.

Migración a Bases de Datos Externas (MariaDB/PostgreSQL)

Para setups con mayores exigencias de rendimiento, concurrencia o donde la fiabilidad del almacenamiento es primordial, migrar la base de datos a un servidor externo (otro SBC, NAS, VM) es la solución robusta. Esto libera recursos de E/S del dispositivo principal de Home Assistant.

Característica	SQLite (Interno, SD/eMMC)	MariaDB/PostgreSQL (Externo)
Rendimiento I/O	Bajo	Alto/Muy Alto
Fiabilidad	Baja (corrupción SD)	Alta (HDD/SSD dedicados)
Complejidad Setup	Baja	Media/Alta
Recursos SBC (HA)	Alto uso CPU/RAM	Bajo uso CPU/RAM (solo cliente)
Integridad datos	Vulnerable a cortes	Robusta (transacciones ACID)

yaml

configuration.yaml

recorder: db_url: mysql://homeassistant:TU_PASSWORD_DB@IP_DEL_SERVIDOR_DB:3306/homeassistant?charset=utf8mb4 # Para MariaDB

db_url: postgresql://homeassistant:TU_PASSWORD_DB@IP_DEL_SERVIDOR_DB:5432/homeassistant # Para PostgreSQL

purge_keep_days: 30 # Una retención mayor es factible con almacenamiento externo de calidad.

💡 INGENIERO TIP: Si utilizas MariaDB/PostgreSQL externamente, asegúrate de que el servidor de la base de datos tiene una fuente de alimentación ininterrumpida (UPS) o está en un medio de almacenamiento con redundancia. Esto es crítico para la integridad de los datos.

Minimización de Datos del Recorder

La estrategia más efectiva en sistemas con almacenamiento limitado es evitar almacenar datos innecesarios desde el origen. Esto reduce tanto el tamaño de la base de datos como la carga de E/S.

Exclusión Selectiva de Entidades

Identifica y excluye proactivamente entidades que cambian de estado frecuentemente o que no aportan valor histórico crítico. Ejemplos:

• Sensores de consumo energético (power, current, voltage): Si ya utilizas un sistema externo como Prometheus/Grafana o InfluxDB para estos datos (ver RECURSOS RELACIONADOS: solarstack).
• Sensores de movimiento (binary_sensor.motion_xxx): Su historial es a menudo redundante para el logbook, a menos que sea para auditoría específica de seguridad (ver RECURSOS RELACIONADOS: securitynode).
• Lecturas de temperatura/humedad muy granulares: Si cambian cada pocos segundos y un muestreo menor es suficiente para el análisis.

Retención Agresiva

Reducir purge_keep_days directamente limita el tamaño físico de la base de datos, ya que Home Assistant eliminará los registros más antiguos.

• purge_keep_days: Configura este valor entre 3 y 7 días para sistemas críticos en espacio. Para auditoría o analíticas complejas que requieran mayor retención, se recomienda exportar datos a un stack de monitorización dedicado, no confiar en el recorder de Home Assistant.
• auto_purge: Mantenerlo en true (por defecto) es crítico para que Home Assistant realice automáticamente la limpieza de la base de datos. Asegúrate de que no está desactivado accidentalmente.

yaml

Ejemplo de configuración para recorder extremadamente restrictivo y eficiente

recorder: purge_keep_days: 3 exclude: domains: - automation # Excluir historiales de ejecución de automatizaciones - script # Excluir historiales de ejecución de scripts - zone # Las zonas no requieren historial detallado - weather # Datos meteorológicos pueden ser externos - updater # Notificaciones de actualización no críticas para el historial - camera # Historial de cámaras, si no se usa para visualización en HA - media_player # Cambios de estado de reproductores multimedia - group # Cambios de estado de grupos entity_globs: # Usar globs para exclusiones amplias - sensor.temperatura_* - sensor._power - binary_sensor. - sensor.last_boot - sensor.memory_free - sensor.disk_use_percent - sensor.wifi_signal_*

Implementación de Almacenamiento Externo y de Alto Rendimiento

Superar las limitaciones de las tarjetas SD es fundamental para la fiabilidad y el rendimiento a largo plazo de cualquier instalación de Home Assistant en un SBC.

USB SSD (Solid State Drive)

La opción más común, costo-efectiva y de mayor impacto para mejorar drásticamente el rendimiento y la fiabilidad de la E/S en SBCs. Las SSD ofrecen velocidades de lectura/escritura significativamente superiores y una vida útil mucho mayor que las tarjetas SD.

• Configuración: Clona el sistema operativo a la SSD y configura el SBC para arrancar desde USB, o usa la SSD exclusivamente para alojar la base de datos de Home Assistant (montaje /config o un subdirectorio).
• Controladores: Asegúrate de que tu SBC (ej. Raspberry Pi 4/5) tiene el firmware actualizado para arrancar desde USB. Utiliza una carcasa USB 3.0 para SSD UASP compatible para maximizar el rendimiento.

NVMe via HAT (Hardware Attached on Top)

Para Raspberry Pi 5 y modelos compatibles con HATs NVMe, esta opción ofrece el máximo rendimiento de almacenamiento, comparable a un PC de escritorio, utilizando la interfaz PCIe.

• Ventajas: Velocidades de lectura/escritura muy superiores (hasta 800MB/s), menor latencia, ideal para sistemas con cargas de E/S intensivas (ej. grabación continua de cámaras de seguridad, ver RECURSOS RELACIONADOS: securitynode).

Montaje de Network File System (NFS) o SMB/CIFS

Offload la base de datos, los logs o incluso el directorio /config completo a un NAS o servidor de archivos en red.

• Ventajas: Centralización de almacenamiento, redundancia si el NAS lo ofrece, no consume recursos del SBC para el almacenamiento físico.
• Desventajas: Dependencia de la red (mayor latencia, punto único de fallo si el NAS se cae), requiere una red local robusta (Gigabit Ethernet).

Técnicas de Caching Volátil (RAM-Disk)

Para datos altamente volátiles que no requieren persistencia entre reinicios o para reducir escrituras innecesarias en el almacenamiento permanente, un RAM-disk es una solución eficiente.

`tmpfs` para Registros y Directorios Temporales

Un tmpfs es un sistema de archivos en memoria RAM que se borra al reiniciar. Es ideal para almacenar logs (/var/log) o directorios temporales utilizados por Home Assistant para cachés volátiles de integración o snapshots temporales.

• Creación de tmpfs (ejemplo en /etc/fstab en el host del SBC):

bash

Montar /var/log en RAM para reducir escrituras en el almacenamiento principal

tmpfs /var/log tmpfs nodev,nosuid,size=50M 0 0

Montar un directorio temporal para Home Assistant (ej. para snapshots o caches de integración)

tmpfs /usr/share/hassio/tmp tmpfs nodev,nosuid,size=256M 0 0

⚠️ ADVERTENCIA TÉCNICA: Los datos almacenados en tmpfs se pierden con cada reinicio del sistema. No uses tmpfs para datos críticos o cualquier información que necesite persistencia.

Mantenimiento y Monitorización Proactiva

Una gestión proactiva es tan importante como la configuración inicial para asegurar la salud y longevidad del sistema.

Compresión y Mantenimiento de Bases de Datos

La base de datos SQLite no libera el espacio en disco inmediatamente después de purgar entradas; solo marca el espacio como disponible. Esto puede llevar a archivos de base de datos (home-assistant_v2.db) que, aunque tienen pocos días de historial, ocupan un tamaño considerable.

• Comando de SQLite VACUUM: Este comando reescribe la base de datos de manera compacta, liberando el espacio no utilizado en el disco.

bash

Desde la terminal del Home Assistant o servidor host:Detener Home Assistant Core antes de ejecutar VACUUM para evitar corrupción

sudo systemctl stop home-assistant@homeassistant.service # Si usas systemd

O detener el add-on Home Assistant Core en Home Assistant OS

sqlite3 /config/home-assistant_v2.db 'VACUUM;'

sudo systemctl start home-assistant@homeassistant.service # Reiniciar Home Assistant

💡 INGENIERO TIP: Automatiza el VACUUM semanalmente durante horas de baja actividad del sistema. Puedes usar un automatismo de Home Assistant con el complemento Shell Command o un cron job en el sistema operativo del host. Asegúrate de detener Home Assistant antes de VACUUM y reiniciarlo después para evitar corrupción.

Monitorización del Uso de Disco

Es crucial tener visibilidad en tiempo real sobre el espacio de almacenamiento disponible para prevenir fallos. La integración System Monitor es ideal para esto.

• Sensores de Home Assistant: Utiliza la integración System Monitor para exponer sensores de uso de disco y porcentajes de espacio libre. Configura alertas para umbrales críticos.

yaml

configuration.yaml

sensor:

• platform: systemmonitor resources:
  • type: disk_use_percent # Porcentaje de uso del disco arg: /config # Ruta a monitorizar (donde está HA config y DB)
  • type: disk_free # Espacio libre en GB arg: /config
  • type: disk_use # Espacio usado en GB arg: /config

RECURSOS RELACIONADOS

• Optimización Energética con Home Assistant (solarstack): Aprende a gestionar datos de sensores de energía (consumo, producción solar) para evitar la sobrecarga del recorder, utilizando stacks de monitorización externos como InfluxDB y Grafana para el historial a largo plazo.
• Hardening de Sistemas para la Seguridad Domótica (securitynode): Técnicas avanzadas de almacenamiento para grabaciones de cámaras de seguridad y registros de eventos críticos, incluyendo la configuración de NVMe o NFS para reducir el impacto en el almacenamiento principal del SBC.
• Automatización Domótica Inteligente con Low-Power Devices (livingsmart): Guía sobre cómo optimizar Home Assistant en dispositivos de bajo consumo (SBCs), incluyendo la gestión de persistencia de datos para asegurar una larga vida útil y un rendimiento óptimo del hardware.

Veredicto de Ingeniería

La gestión del almacenamiento para Home Assistant en sistemas con recursos limitados no es opcional, es una necesidad crítica para la estabilidad y longevidad del despliegue. Para la mayoría de los usuarios smartfrugal operando en SBCs, la prioridad es la migración a un SSD USB externo para el sistema operativo completo, complementada con la implementación agresiva de reglas exclude y purge_keep_days en el componente recorder. Solo para setups de alta exigencia, con múltiples usuarios o un volumen de datos masivo, y con una infraestructura de red robusta, se justifica la migración de la base de datos a MariaDB/PostgreSQL en un servidor externo. El uso de tmpfs es una optimización de nicho útil para logs o cachés temporales, nunca para datos persistentes. La monitorización constante del uso de disco y la automatización del VACUUM periódico son vitales para la sostenibilidad del sistema. Ignorar estas prácticas resultará en fallos prematuros del hardware, corrupción de datos y una experiencia de usuario degradada. La inversión en un SSD de calidad es el retorno más alto en estabilidad, rendimiento y tranquilidad operativa.