Ir al contenido

← Todas las funcionalidades

Monitorización textil (tejeduría)Servidor (Node-RED)MQTTHTTPInfraestructura

El lado servidor: un concentrador Node-RED multiplanta

Un concentrador MQTT en Node-RED es donde una flota de PLC ESP32 se convierte en un sistema: un servidor por planta que recibe cada snapshot y cada evento, lo valida, lo respalda y vigila quién se ha quedado en silencio. Estos cuatro nodos función — validación, endpoint de recuperación de ficheros, backup a disco y chequeo de flota — son el lado servidor destilado de un despliegue real de monitorización de máquinas textiles que ejecuta el mismo flujo en dos plantas de producción.

Validar y deduplicar en la puerta

El primer nodo función parsea cada payload MQTT entrante, dirige el JSON malformado a una salida de descarte dedicada en lugar de tirarlo en silencio, y deduplica por el id_msg único que el firmware estampa en cada mensaje. La deduplicación aquí es esencial, porque los PLC reenvían deliberadamente los datos almacenados tras cada reconexión y, de lo contrario, la producción se contaría dos veces. Los mensajes válidos se enriquecen después con el nombre de la planta, un timestamp de servidor y el topic de origen antes de que nada aguas abajo — backup en fichero, base de datos, dashboard — llegue a verlos.

Todo acaba en disco, dos veces

Un nodo función de backup añade cada mensaje recibido — y cada descarte, junto con el motivo del error — a ficheros diarios por planta, replicando en el servidor lo que las tarjetas SD hacen en el lado del PLC. Un endpoint HTTP-in separado, /get_data protegido con basic auth, recibe los ficheros diarios que los PLC suben tras un corte y los guarda en una carpeta de recuperación por planta, saneando antes la cabecera con el nombre del fichero.

Saber quién se ha quedado callado

Una telemetría que se detiene en silencio es una alarma que nadie oye, y un PLC muerto se ve exactamente igual que uno sano parado salvo que alguien lo compruebe. El nodo de chequeo de flota, disparado por un inject cada cinco minutos, compara el último timestamp visto de cada PLC esperado contra un umbral de silencio de dos minutos y emite un objeto de estado con los nombres de los dispositivos que se han apagado. El mismo flujo exacto sirve a las dos plantas de producción — lo único que cambia entre despliegues es una variable de entorno con el nombre de la planta.

Un fragmento de la implementación

Tal cual del ejemplo desplegado en el Servidor (Node-RED) — cópialo libremente:

const PLANT = env.get("PLANT") || "plant1";      // same logic in both plants

let data;
try {
  data = (typeof msg.payload === "string") ? JSON.parse(msg.payload) : msg.payload;
} catch (e) {
  msg.error = "invalid JSON: " + e.message;
  return [null, msg];                            // output 2: discards
}

// Minimum fields sent by the firmware
if (data.id === undefined) {
  msg.error = "missing PLC id";
  return [null, msg];
}

// Deduplication by id_msg (the PLC re-sends after reconnection / SD replay)
if (data.id_msg) {
  const seen = context.get("seen") || {};
  if (seen[data.id_msg]) {
    msg.error = "duplicate: " + data.id_msg;
    return [null, msg];
  }
  seen[data.id_msg] = Date.now();
  // Purge: keep only the last hour of IDs so the map does not grow unbounded
  const oneHourAgo = Date.now() - 3600 * 1000;
  for (const k in seen) if (seen[k] < oneHourAgo) delete seen[k];
  context.set("seen", seen);
}
Ver el ejemplo completo funcionando Consigue el pack del proyecto

El ejemplo completo es un programa entero — cabecera de conexionado, setup y bucle principal — listo para adaptar a tu aplicación.

Preguntas frecuentes

¿Por qué deduplicar en el servidor y no en el PLC?

El PLC favorece deliberadamente la entrega at-least-once — prefiere enviar dos veces antes que perder datos tras una reconexión. El concentrador mantiene el conjunto reciente de id_msg de forma centralizada, algo barato en el contexto de Node-RED e imposible de hacer entre reinicios en el dispositivo.

¿Debe cada planta tener su propio concentrador?

En este despliegue, sí — un broker más Node-RED por planta mantiene el flujo de datos durante fallos del enlace entre sedes. Los flujos son idénticos; una variable de entorno fija el nombre de la planta, y un sistema central puede consumir ambos.

¿Cómo llegan los datos a una base de datos desde aquí?

Añade un nodo de base de datos tras la salida de validación — los mensajes ya son JSON limpio, deduplicado y enriquecido. Los backups en fichero quedan como pista de auditoría y fuente de replay si la base de datos hubiera que reconstruirla algún día.

Funcionalidades relacionadas