Un panel en vivo se convierte en un pequeño gemelo digital cuando representa un activo real, su configuración, condición medida e historial reciente para apoyar una decisión. Un ESP32 y algunos sensores aportan evidencias, pero el modelo no debe fingir que sabe más de lo que mide el hardware.
Para un ventilador de invernadero, el primer modelo puede incluir ID del activo, sala, estado del ventilador, temperatura objetivo y medida, revisión de calibración, hora del evento y de recepción en el servidor y estado de fallo. No necesita un modelo 3D. Lo útil es saber si funciona como se espera, si la lectura está actualizada y qué acción segura puede tomar el operador.
| Clase | Ejemplo | Responsable y significado |
|---|---|---|
| Identidad y modelo | ID, sala, revisión de placa y sensor | Registro o despliegue; cambia poco. |
| Estado observado | Temperatura, retorno del relé, batería, fallo y horas | El dispositivo reporta evidencias; un dato viejo no es actual. |
| Estado deseado | Consigna, revisión del horario, modo permitido | Un operador solicita el cambio; el dispositivo confirma el resultado. |
No sobrescribas el estado deseado con telemetría. Solicitar un comando no es medir, y recibir un acuse del broker no demuestra que se moviera el relé. Guarda ID del comando, actor, motivo, emisión, vencimiento, confirmación del dispositivo y resultado observado. Los enclavamientos y límites físicos deben permanecer en el firmware para que perder Wi-Fi o recibir un mensaje malformado no eluda la seguridad.
Publica ID del dispositivo, ID del evento o secuencia monotónica, versión del esquema, métrica, valor numérico, unidad, hora del evento, estado del sensor y firmware. El servidor añade su hora de recepción. UTC facilita el análisis, pero el reloj del dispositivo puede desviarse; usa secuencia y hora de recepción para mostrar incertidumbre. Relaciona calibración y revisión de hardware con el modelo temporal del activo.
Envía lotes cuando la latencia lo permita, usa búfer local limitado, reintentos con espera incremental e ingesta idempotente. Valida rangos y unidades en la API. Una temperatura de 2300 puede representar 23,00 °C en un protocolo de punto fijo o una sonda averiada: el esquema debe distinguir ambas situaciones.
Cada propiedad debe incluir hora de actualización y calidad. Diferencia “normal”, “obsoleto”, “fallo del sensor”, “fuera de rango” y “desconocido”. Una línea plana puede ser temperatura estable, sensor desconectado o pipeline detenido; muestra muestras recibidas, última recepción y huecos. Indica unidad, zona horaria y cambios de firmware o mantenimiento que alteren la lectura.
Una instalación pequeña puede usar ingesta MQTT o HTTPS, un registro relacional de activos/configuración y una tabla o servicio temporal para lecturas. Una pasarela almacena durante cortes. El panel consulta una API que aplica permisos por cliente y rol; el navegador no debe recibir credenciales del dispositivo ni acceso irrestricto al broker. Separa el historial frecuente de la proyección del estado más reciente para no recorrer todo el log.
El primer “gemelo” puede ser un documento JSON versionado, no una plataforma 3D costosa. Si luego hacen falta relaciones entre activos, simulación, contexto espacial o federación entre sitios, evoluciona el modelo con intención. Empieza con pocos activos representativos y registra qué decisiones operativas mejora.
Usa lista permitida de comandos, autorización por rol, límites de consigna, vencimiento, ID único y acuse explícito. Rechaza revisiones de configuración obsoletas. El firmware debe imponer límites locales de temperatura, funcionamiento en seco y tiempo máximo para ventilador o bomba, incluso sin nube. Añade parada de emergencia o control manual cuando el proceso lo requiera. El gemelo coordina la intención; no es el controlador de seguridad.
Registra vigencia, muestras ausentes, fallos de sensor, acuses y finalización de comandos, precisión de alertas, respuesta y tiempo de diagnóstico. Compara periodos equivalentes antes y después. Un modelo vistoso no compensa datos obsoletos, calibración deficiente o recuperación sin probar.
Un gemelo asequible y útil combina un modelo del activo, observaciones fechadas, estado deseado explícito, vigencia visible y comandos acotados. El ESP32 aporta telemetría; identidad, esquema, búfer y reglas de seguridad la vuelven operativa. Empieza por la pregunta que necesita responder el equipo y añade solo el detalle que mejora esa decisión.