Home Assistant en escuelas: sensores, roles y copia probada
Caso anonimizado para ordenar sensores de aula técnica con Home Assistant, MQTT, recorder, permisos básicos y restauración antes de depender del tablero.
Antes, la escuela anotaba temperaturas de aula, bombas y tablero eléctrico en una planilla que viajaba con el preceptor. Después, cada sensor tuvo nombre, aula, horario y responsable visible. Home Assistant permite reunir datos locales, reglas de automatización y copias probadas en una instalación chica. Este caso anonimizado muestra qué se configura primero, quién toca cada dato y cómo se restaura antes de confiar en el tablero.
Dónde aparece el sensor sin dueño
El caso nace en una escuela técnica agrotécnica del este provincial: invernadero, taller, sala de servidores y cámara de frío generaban mediciones separadas. Home Assistant publicó la versión 2026.10.1 el 10 de octubre, con correcciones de integraciones y dependencias. La fecha sirve para una regla simple: cada actualización se prueba con sensores reales antes de cambiar el equipo del aula. El dato global viene del propio proyecto. Home Assistant Analytics mostró 698.966 instalaciones activas al momento de esta corrida y la integración Backup aparece con 526.458 instalaciones reportadas en el tablero de integraciones. La escala no convierte una escuela en laboratorio global; sí muestra que backup, sensores y uso local ya tienen una comunidad grande detrás. La escena útil es concreta: una caja plástica DIN, una fuente de 12 V y dos cables rotulados con cinta blanca. Si el rótulo dice "invernadero norte" y el tablero dice "sensor_14", la próxima alarma va a llegar sin dueño. El antagonista es la lectura manual de última hora.
Cómo funciona por dentro
El flujo tiene seis pasos. Primero, el sensor envía temperatura, humedad, consumo o estado por MQTT, Zigbee, Wi-Fi o integración local. Segundo, Home Assistant recibe la entidad y la muestra con nombre, área y dispositivo. Tercero, Recorder guarda cambios de estado y eventos en una base; por defecto usa SQLite en /config/home-assistant_v2.db, y también admite PostgreSQL. Cuarto, una automatización compara umbral, horario y condición. Quinto, un usuario con permiso operativo ve tablero o recibe aviso. Sexto, backup copia configuración, base, apps y secretos, y una restauración valida que el tablero vuelva. La documentación de Recorder explica que cada cambio de estado se escribe en una base y que historial, actividad, gráficos y estadísticas leen desde ahí. También indica retención por defecto de 10 días y purga automática. Ese dato define una decisión: una escuela que necesita revisar un mes de heladas debe cambiar retención o exportar series. La integración MQTT recibe mensajes de sensores y dispositivos. La automatización toma esa entrada y entrega una acción: aviso, relé, registro o cambio de estado. Si MQTT cae, la señal visible es un sensor sin actualización; si Recorder cae, el tablero puede mostrar presente sin historial confiable.
Qué se instala o configura primero
El primer entregable verificable es un tablero de diez sensores: tres de temperatura, dos de humedad, dos de energía, un estado de bomba, un estado de puerta y un aviso de cámara de frío. Cada entidad necesita nombre humano, ubicación, responsable, unidad, frecuencia esperada y acción ante alarma. La pila mínima usa Home Assistant 2026.10.1 en Linux o Home Assistant OS, broker MQTT, Recorder, usuarios locales, backup automático y una copia fuera del equipo. La instalación en Linux sirve para equipos pequeños con administración local. La documentación de automatizaciones cubre disparadores, condiciones y acciones. El costo de un piloto chico ronda USD 80 a USD 180 para mini PC, sensores y almacenamiento externo; con dólar oficial vendedor a ARS 1535, queda entre ARS 122.800 y ARS 276.300. El costo mensual posterior puede bajar a USD 10 a USD 30 si se suma una copia externa y monitoreo básico. El tiempo inicial es de una semana si el cableado ya está identificado. UMSA puede entrar cuando la escuela necesita convertir sensores en evidencia útil: nombres, áreas, usuarios, tablero, respaldo y prueba de restauración. El objetivo del piloto es humilde y medible: que un docente vea el estado, que sistemas pueda corregir el nombre y que dirección reciba una alerta entendible. La documentación de backups indica que las copias se guardan cifradas en archivos comprimidos y que un backup completo incluye directorios de configuración, apps, medios, SSL y recursos compartidos. Para una escuela, eso pide una copia fuera del equipo y una clave de recuperación guardada por más de una persona.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en nombres ambiguos. La señal es una alarma que dice "sensor_14" y nadie sabe si corresponde al invernadero o a la sala de servidores. La prueba revisa diez entidades y exige nombre, aula, unidad, dueño y acción. El segundo riesgo aparece en historial incompleto. La señal es un tablero que muestra temperatura actual y pierde la curva de la noche. La prueba corta energía del equipo, lo reinicia y revisa Recorder, último dato guardado y purga configurada. El tercer riesgo vive en permisos. La señal es que cualquier usuario puede cambiar automatizaciones o borrar una integración. La prueba crea usuarios de lectura, operación y administración; cada uno intenta ver, editar, reiniciar y descargar backup. El cuarto riesgo aparece al restaurar. La señal es una copia cifrada sin clave o guardada en el mismo disco dañado. La prueba restaura en otro equipo, abre el tablero, recupera dos automatizaciones y confirma que un sensor MQTT vuelve a publicar. La próxima alarma debería responder una pregunta simple: ¿qué aula, qué sensor y qué persona actúan ahora?
