Con unos pocos dispositivos, una hoja de cálculo parece suficiente. Con cientos, la operación debe saber: qué unidad física es, quién responde por ella, qué firmware debería ejecutar, qué comunicó por última vez y si sigue siendo confiable. Un registry no es una lista de direcciones MAC, sino el registro operativo que une identidad, ciclo de vida, configuración deseada y salud observada.
Mantén un ID lógico estable e independiente de la dirección de red. MAC, IP y nombre visible son atributos, no credenciales de autorización. El alta debe vincular la unidad física con responsable, sitio y revisión de hardware; la emisión de credenciales requiere un proceso controlado. Nunca reutilices una identidad retirada en otra placa.
Un registry normalizado guarda identidad, modelo/revisión, ubicación, responsable, referencia de credencial, soporte y etapa del ciclo. La telemetría detallada va a eventos o series temporales; el registry conserva el resumen necesario para localizar y operar. Separa configuración deseada y reportada, con versión y hora para ambas. Su diferencia es evidencia de desvío, no algo que deba sobrescribirse.
Incluye alta, último contacto autenticado, firmware y bootloader, revisión de configuración, salud de sensores, último error, cohorte OTA y responsable de mantenimiento. Mantén secretos fuera de las filas de inventario: guarda solo una referencia al servicio de credenciales.
Incluye ID, secuencia monotónica, firmware, uptime o causa de reinicio e indicadores compactos de salud. El servidor añade su hora de recepción. Define intervalo esperado por clase y estados como sano, tardío, obsoleto, aislado o retirado. “Conectado” no demuestra que el sensor esté muestreando ni que la configuración sea actual.
Usa claves idempotentes y acepta eventos tardíos. Separa hora del evento de recepción por la deriva del reloj. El panel de flota debería filtrar por sitio, revisión, cohorte, demora e incidentes abiertos, no mostrar miles de tarjetas.
Registra firmware/configuración deseados aparte de lo que confirma cada equipo. Un despliegue incluye artefacto, firma o digest, cohorte, autorización, inicio, resultado y rollback. OTA de ESP-IDF puede volver a una aplicación funcional tras fallar la nueva; el registry debe diferenciar “descargada”, “arrancó pendiente de verificación” y “confirmada sana”. Enviar el comando no prueba que se actualizó.
| Campo o evento | Por qué importa | Control de acceso |
|---|---|---|
| ID lógico y revisión | Relaciones estables tras reparar o cambiar red | Alta y soporte |
| Referencia/estado de credencial | Rotación, revocación e incidentes | No mostrar claves privadas |
| Estado deseado/reportado | Detecta desvíos de firmware/configuración | Cambios autorizados |
| Último contacto y salud | Identifica segmentos atrasados o fallidos | Alcance por sitio y rol |
| Ciclo de vida | Controla activación, aislamiento y retirada | Transiciones auditadas |
Separa lectura, operación de sitio, administración de credenciales y aprobación de firmware. Soporte puede revisar salud sin consultar secretos ni emitir comandos de actuación. Limita cada consulta y comando a sitios y dispositivos autorizados. Registra actor, motivo, ID de solicitud y estado anterior/nuevo para transiciones sensibles.
Aísla un dispositivo perdido, comprometido o devuelto antes de reasignarlo. Revoca credenciales, bloquea comandos, conserva evidencia necesaria y registra destino físico. Una unidad de reemplazo recibe identidad nueva vinculada al ticket, sin copiar la anterior. Los dispositivos sin soporte necesitan política explícita de actualización, acceso y retención de datos.
Un registry útil vincula identidad única con ciclo, acceso, configuración deseada y salud observada. Mantén secretos aparte, diferencia estado deseado del reportado, explicita resultados OTA y audita desde el alta hasta la retirada. Así la flota se puede operar en vez de limitarse a contar equipos.