Mosquitto en bodegas: sensores, ACL y respaldo

Un caso de bodega muestra cómo ordenar sensores MQTT con Mosquitto: tópicos, permisos, persistencia, tablero y prueba de recuperación ante corte.

ULTIMA MILLA · Proyectos · 13 de jun de 2026 · 4 min de lectura

Antes, cada cámara de frío tenía una pantalla local y una libreta con lecturas; después, cada sensor publicó temperatura, humedad y hora en un tópico MQTT con permiso propio. En una bodega de Luján de Cuyo, Mosquitto ordena mensajes de bajo peso sin cambiar todo el sistema de planta. Esta nota muestra cómo viaja el dato y cómo se prueba el respaldo.

Dónde aparece el desorden

El síntoma se ve en recepción de uva y en cámaras de frío: lecturas repetidas, sensores con nombres distintos y alertas que llegan tarde. Un encargado de logística puede tener una etiqueta térmica pegada en la puerta, pero si el dato no llega a un registro común, la trazabilidad depende de fotos y llamados. MQTT resuelve transporte liviano. La especificación MQTT 5.0 de OASIS define un protocolo de publicación y suscripción entre clientes y servidor. La documentación de Eclipse Mosquitto lo ubica como broker: recibe mensajes de sensores y los reparte a quienes están suscriptos. La cifra que corrige el plan está fuera de la bodega. En la encuesta Stack Overflow 2025, Docker aparece con 71,1 % de uso entre los encuestados y SQL con 58,6 %. El caso local no necesita una plataforma rara: necesita un broker pequeño, una base para histórico y un flujo que alguien pueda restaurar. La etiqueta del sensor dejó de ser decoración.

Cómo funciona por dentro

El flujo tiene seis pasos. El sensor mide temperatura o humedad y publica un mensaje en un tópico, por ejemplo bodega/cámara-03/temperatura. Mosquitto recibe el mensaje y revisa usuario, contraseña o certificado. La ACL decide si ese sensor puede escribir en ese tópico y si una pantalla puede leerlo. Node-RED puede suscribirse al tópico, limpiar el dato y mandarlo a PostgreSQL o InfluxDB. La receta oficial de Node-RED para conectar con MQTT usa nodos de entrada y salida con un broker definido. La base guarda fecha, sensor, valor, lote, cámara y estado de lectura. El tablero muestra valores actuales y un histórico por cámara. Mosquitto también puede persistir sesiones y mensajes retenidos según configuración. El manual mosquitto.conf lista opciones de persistencia, listeners, tamaño máximo de payload, archivos de contraseña y ACL. El permiso de borrado queda reservado al administrador; soporte puede ver estado de conexión y último mensaje. El payload conviene dejarlo chico y repetible: identificador del sensor, timestamp del equipo, timestamp del servidor, valor, unidad y batería si existe. El timestamp del servidor manda cuando el sensor pierde hora. Una regla descarta duplicados por sensor y minuto; otra marca valores fuera de rango para revisión manual. El backup copia configuración, archivo de seguridad dinámica, flujos de Node-RED y base histórica. La prueba restaura esos cuatro elementos en otra máquina y exige que una lectura simulada vuelva a entrar con el mismo tópico y el mismo permiso.

Qué se instala o configura primero

La pila inicial tiene Mosquitto 2, Node-RED, PostgreSQL o InfluxDB, un tablero Grafana y backup con copia fuera del servidor. El primer entregable verificable es una tabla con diez sensores, tópico, permiso de escritura, último dato, alarma mínima y responsable. Con la cotización vendedora del Banco Nación al 12 de junio de 2026, USD 1 equivale a ARS 1.450. Un equipo industrial pequeño o mini servidor puede quedar entre USD 180 y 350, de ARS 261.000 a ARS 507.500, sin sensores. La implementación base pide 25 a 45 horas: inventario, tópicos, ACL, tablero, retención y prueba de corte. UMSA puede encarar un piloto con una cámara, una sala de bombas o una línea de frío. El entregable útil es una lectura qué se pueda seguir de punta a punta: sensor, tópico, broker, base, tablero y restauración.

Dónde se rompe y cómo probarlo

El primer riesgo es el tópico libre. La señal aparece cuando dos sensores publican en nombres parecidos y el tablero mezcla lecturas. La prueba crea dos sensores con tópicos casi iguales y verifica que la ACL acepte uno y rechace el otro. El segundo riesgo es el mensaje retenido mal usado. Una pantalla puede mostrar un valor viejo si nadie etiqueta hora y sensor. La prueba apaga el sensor, conserva el último mensaje y exige que el tablero pinte edad del dato antes de mostrarlo como lectura actual. El tercer riesgo es la contraseña compartida. El plugin de seguridad dinámica de Mosquitto permite roles y control de acceso actualizables con el broker en marcha. La prueba revoca un sensor y confirma que no pueda publicar aunque conserve la red. El cuarto riesgo es una alarma sin responsable. La señal aparece cuando el tablero marca temperatura alta y nadie cierra el incidente. La prueba fuerza una lectura fuera de rango, crea una tarea y exige usuario, hora de cierre y comentario. El quinto riesgo es creer que el broker es histórico. Mosquitto mueve mensajes; la base conserva la serie. La prueba borra el broker, restaura configuración y confirma que el histórico siga en la base. Una cámara de frío con sensores conectados todavía puede fallar; lo qué cambia es que la falla queda fechada y alguien sabe qué recuperar.