Ir al contenido

← Todas las funcionalidades

Monitorización geotécnica de taludESP32 PLC 14 (×4, Ethernet)HTTPComunicación

Polling de varias estaciones PLC y clasificación de alertas en Node-RED

Cuando un servidor central debe vigilar varios PLC remotos, el polling HTTP desde Node-RED es el patrón fiable más sencillo. En este ejemplo, un concentrador en una Raspberry Pi consulta cuatro estaciones ESP32 PLC 14 Ethernet cada minuto, parsea cada respuesta JSON y la enruta por un switch de 5 salidas según el nivel de alerta, de 0 (normal) a 4 (crítico). Es el mecanismo exacto que ejecutamos en un despliegue real de monitorización de talud, donde cada nivel dispara una acción distinta: dashboard, log o email.

Un inject, cuatro peticiones

Un único nodo inject dispara la función "preparar polling", que construye un mensaje por estación con msg.url apuntando a POST /esp32plc14_XX/status. El nodo http request toma la URL del mensaje, así que un solo nodo sirve a toda la flota. Las peticiones salen escalonadas 200 ms para no estresar la red ni el event loop.

El silencio es una alerta de nivel 4

El clasificador hace algo más que leer el campo status. Si una estación no devuelve JSON o responde con un código distinto de 200, la función fuerza msg.alerta = 4 — una estación que deja de responder en un talud se trata como crítica, no como dato ausente. Cada lectura válida se cachea además en el contexto de flujo para el dashboard.

Cinco salidas, cinco reacciones

El nodo switch evalúa msg.alerta con cinco reglas de igualdad. Los niveles 0-2 solo refrescan el dashboard y el log; los niveles 3 y 4 alimentan además una función que formatea asunto y cuerpo para el script de alertas SMTP. Añadir una quinta estación es añadir una línea a una constante — el flujo no cambia.

Un fragmento de la implementación

Tal cual del ejemplo desplegado en el ESP32 PLC 14 (×4, Ethernet) — cópialo libremente:

const STATIONS = [
    { id: 31, ip: "10.10.10.31" },
    { id: 32, ip: "10.10.10.32" },
    { id: 33, ip: "10.10.10.33" },
    { id: 34, ip: "10.10.10.34" }
];

const msgs = STATIONS.map(sta => ({
    url: `http://${sta.ip}/esp32plc14_${sta.id}/status`,
    method: "POST",
    payload: {},                       // empty body: we only request status
    station: sta.id,                   // travels with the msg for traceability
    topic: `station/${sta.id}`
}));

// Send the 4 messages staggered (200 ms) to avoid flooding
msgs.forEach((m, i) => setTimeout(() => node.send(m), i * 200));
return null;

// ======================================================================
// FUNCTION NODE "classify alert"  (1 input, 1 output)
// Wire it to the http request output. Normalizes the response and computes
// msg.alert (0=normal ... 4=critical) feeding the 5-output switch.
// ======================================================================
/*
let data;
try {
    data = typeof msg.payload === "string" ? JSON.parse(msg.payload) : msg.payload;
} catch (e) {
    data = null;
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é polling en lugar de que los PLC empujen sus datos?

En realidad hacemos ambas cosas. El polling da al concentrador el control del intervalo de medida, mientras que un push periódico desde cada estación actúa como watchdog. Cualquiera de los dos lados puede detectar que el otro ha enmudecido.

¿Cuántas estaciones puede sondear una instancia de Node-RED?

Decenas sin problema. El nodo http request procesa los mensajes secuencialmente, así que 4 estaciones a intervalos de 60 s es una carga mínima incluso en una Raspberry Pi. Escalona las peticiones si pasas de 20-30 estaciones.

¿Qué ocurre si una petición supera el timeout?

La función clasificadora trata los timeouts y el JSON inválido como nivel 4, de modo que el fallo sigue el mismo camino que una lectura crítica de sensor y acaba en un email al buzón de soporte.

Funcionalidades relacionadas