Una demostración de IoT no termina cuando un valor aparece en una consola. Un pipeline sostenible identifica cada dispositivo, transporta mediciones por redes inestables, revela datos obsoletos o ausentes y separa la confirmación del broker del almacenamiento duradero de la aplicación. Mantén pequeño el primer diseño, pero haz visibles sus fallos.
El componente ESP-MQTT de ESP-IDF implementa un cliente MQTT; el broker distribuye publicaciones a suscriptores. Ninguno completa por sí solo un pipeline de datos. El servicio de ingesta debe validar el contenido y confirmar la escritura en la base antes de que los paneles consideren duradera la observación.
Asigna a cada dispositivo un client ID estable y único y credenciales limitadas a ese nodo. Una familia sencilla puede ser site/{siteId}/device/{deviceId}/telemetry, .../state y .../command. Separa permisos de publicación y suscripción: el sensor suele publicar telemetría y suscribirse solo a sus propios comandos. No incluyas secretos ni datos personales en los temas.
Elige un contenido compacto y versionado con hora de medición, secuencia monotónica, firmware, unidades e indicadores de calidad. La versión del esquema permite evolucionar la ingesta sin adivinar. Guarda por separado la hora de recepción del servidor; el reloj del dispositivo puede estar desajustado, derivar o reiniciarse.
MQTT QoS 0 entrega como máximo una vez; QoS 1, al menos una vez y puede duplicar; QoS 2 añade un intercambio para entrega exactamente una vez entre pares MQTT. QoS no garantiza una única inserción en la base ni un único procesamiento del panel. Para muchas cargas de telemetría, QoS 1 con una clave idempotente como deviceId + sequence equilibra fiabilidad y costo. Mide si el intercambio adicional de otro nivel compensa.
Un evento de publicación exitosa o una confirmación del broker indica que el intercambio alcanzó su etapa MQTT, no que se confirmó una transacción SQL. Si importa el procesamiento duradero, confirma desde el consumidor después de persistir o emite un recibo de ingesta. Al reconectar, reenvía las lecturas con sus IDs originales para deduplicar.
Un mensaje retenido guarda en el broker el último valor de un tema y se entrega a futuros suscriptores. Sirve para un estado actual compacto o disponibilidad, no para conservar un historial sin límite. Last Will puede publicar estado offline tras una desconexión inesperada; combínalo con el anuncio online y una política de hora/expiración para no presentar estado viejo como actual. En MQTT 5, la expiración de sesión y mensaje es distinta del ciclo de vida del mensaje retenido.
Perder Wi-Fi es normal. Limita la cola del dispositivo por bytes y antigüedad, decide qué mediciones se pueden agregar y define qué ocurre al llenarse. Separa alarmas críticas de muestras habituales si su latencia es distinta. Usa backoff exponencial con jitter y demora máxima para evitar que toda la flota se reconecte a la vez tras una caída del broker. Persiste solo lo que requiera el presupuesto de pérdida: flash y almacenamiento son finitos.
| Señal | Qué revela | Alerta útil |
|---|---|---|
| Edad de la última muestra | Si el nodo envía datos recientes | Supera el contrato de reporte |
| Huecos de secuencia | Pérdida entre generación e ingesta | La tasa sube sobre la línea base |
| Reconexiones al broker | Inestabilidad de red o autenticación | Ráfagas o fallos repetidos de acceso |
| Cola y antigüedad del dato más viejo | Acumulación y capacidad de recuperación | Se acerca al límite establecido |
| Rechazos de ingesta | Errores de esquema, permiso o calidad | Aumento por versión de firmware |
Usa TLS con validación de certificados; cifrar sin autenticar el broker aún permite conectar el dispositivo al destino equivocado. Protege credenciales almacenadas, aprovisiona identidades únicas, permite rotación y revocación, y no registres tokens. Las ACL del broker deben denegar por defecto. Los comandos requieren autorización, frescura y validación segura en el dispositivo; el acceso al panel no protege por sí solo el canal.
Empieza con inventario de flota, último contacto, firmware, batería o señal si están disponibles, huecos de secuencia y errores de ingesta. Los gráficos deben indicar unidades y mostrar intervalos faltantes, no dibujar una continuidad engañosa. Añade una traza por dispositivo desde el ID de muestra hasta su recepción y fila en base de datos. Así se distingue entre sensor inactivo, red degradada y backend que descarta mensajes válidos.
El pipeline MQTT mínimo útil combina identidad, evento versionado, transporte cifrado, comportamiento offline acotado, temas autorizados, ingesta idempotente y paneles centrados en vigencia. Elige QoS para el tramo MQTT y demuestra almacenamiento y procesamiento aparte. Esa distinción convierte una demo en un sistema operable.