Skip to Content

← All functionalities

Geotechnical slope monitoringESP32 PLC 14 (×4, Ethernet)HTTPCommunication

Polling multiple PLC stations and classifying alerts in Node-RED

When a central server must watch several remote PLCs, HTTP polling from Node-RED is the simplest reliable pattern. In this example a concentrator on a Raspberry Pi queries four ESP32 PLC 14 Ethernet stations every minute, parses each JSON reply and routes it through a 5-output switch by alert level, 0 (normal) to 4 (critical). It is the exact mechanism we run in a real slope monitoring deployment, where each level triggers a different action: dashboard, log or email.

One inject, four requests

A single inject node fires the "preparar polling" function, which builds one message per station with msg.url pointing to POST /esp32plc14_XX/status. The http request node takes its URL from the message, so one node serves the whole fleet. Requests go out staggered by 200 ms to keep the network and the event loop relaxed.

Silence is a level-4 alert

The classifier does more than read the status field. If a station returns no JSON or a non-200 code, the function forces msg.alerta = 4 — a station that stops answering on a slope is treated as critical, not as missing data. Every valid reading is also cached in flow context for the dashboard.

Five outputs, five reactions

The switch node evaluates msg.alerta with five equality rules. Levels 0-2 only refresh the dashboard and the log; levels 3 and 4 also feed a function that formats subject and body for the SMTP alert script. Adding a fifth station means adding one line to a constant — the flow does not change.

A snippet from the implementation

Straight from the example as deployed on the ESP32 PLC 14 (×4, Ethernet) — copy it freely:

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;
View the full working example Get the full project pack

The full example is a complete program — wiring header, setup and main loop — ready to adapt to your application.

Frequently asked questions

Why polling instead of having the PLCs push their data?

We actually do both. Polling gives the concentrator control of the measurement interval, while a periodic push from each station acts as a watchdog. Either side can detect that the other has gone silent.

How many stations can one Node-RED instance poll?

Dozens without trouble. The http request node processes messages sequentially, so 4 stations at 60 s intervals is a tiny load even on a Raspberry Pi. Stagger the requests if you grow past 20-30 stations.

What happens if a request times out?

The classifier function treats timeouts and bad JSON as level 4, so the failure follows the same path as a critical sensor reading and ends in an email to the support inbox.

Related functionalities