Industrial IoT projects often start with a simple question:
Can we collect this data and send it somewhere useful?
Maybe the data comes from a Modbus device. Maybe it is a machine status signal. Maybe it is a sensor reading that needs to be sent to an MQTT broker or cloud endpoint.
Not every early-stage project needs a full custom application from day one. Sometimes the team first needs a practical way to build, test, and adjust the data flow close to the equipment.
That is where Node-RED becomes interesting.
Node-RED is not an industrial edge gateway. It is a flow-based, low-code tool for connecting data sources, transforming values, applying simple logic, and routing messages to other systems.
When it runs on an industrial edge gateway, Node-RED can become part of the edge-side workflow layer. A gateway such as Robustel EG5120 can provide the industrial platform around it: field-side interfaces, local computing resources, network connectivity, security functions, and remote management.
The useful point is not that Node-RED makes every factory “smart.” The useful point is that it can help turn selected field-side data into a working IoT data flow without building everything from scratch.
Where Node-RED fits in the architecture
An industrial edge gateway usually sits between factory-floor equipment and upper-layer systems.
It may connect to:
●PLC-side devices
●meters
●sensors
●machine controllers
●serial equipment
●Ethernet networks
●MQTT brokers
●cloud systems
●APIs or databases
Node-RED fits into this architecture as an application layer running on the gateway. It helps define what happens to selected data after it becomes available at the edge.
A simple view might look like this:
field device or PLC-side equipment
↓
industrial edge gateway
↓
Node-RED flow
↓
MQTT broker, cloud API, database, or monitoring system
The gateway provides the industrial base.
Node-RED helps build the data flow.
That distinction matters. Node-RED does not remove the need for correct wiring, protocol settings, register maps, network design, or security controls. It simply gives teams a flexible way to connect the steps inside a data workflow.
Why run Node-RED close to factory equipment?
Running data flows at the edge can be useful when the data needs some local handling before it moves upstream.
For example, a project may need to:
●read selected Modbus values
●parse serial data
●format raw values into JSON
●add equipment names or timestamps
●filter repeated readings
●trigger a simple alert when a value changes
●publish selected data to MQTT
●send prepared data to an HTTP API or database
These are common factory IoT tasks, especially in brownfield environments.
Older machines, meters, or PLC-side devices may not have a modern cloud connector. But they may expose useful values through Modbus, serial data, Ethernet, digital signals, or added sensors.
Node-RED can help project teams build a bridge between available field-side data and the systems that need visibility.
It is especially useful in proof-of-concept work, pilot projects, and application-specific workflows where the team needs to test whether a data path is practical before committing to a larger software build.
A simple Modbus-to-MQTT flow
One common example is Modbus to MQTT.
A field device may expose values through Modbus RTU or Modbus TCP. The edge gateway provides the physical and network connection. Node-RED can then help read or receive the selected data, transform it, and publish it to an MQTT broker.
A simplified flow may look like this:
Modbus device
↓
edge gateway connection
↓
Node-RED reads selected values
↓
values are scaled, renamed, or formatted
↓
message is published to MQTT
For example, a raw value from an energy meter may become a structured MQTT message with an equipment ID, measurement name, unit, timestamp, and reading.
A machine status input may become something like:
machine_02/status = running
line_01/fault = active
This is where Node-RED is useful. It helps move from raw data to readable messages.
But again, the quality of the result depends on the project setup. The Modbus address, register map, polling interval, tag naming, payload format, MQTT topic structure, and security configuration all still need to be designed properly.
What Node-RED is good for
Node-RED is often a good fit for lightweight edge-side data workflows.
It can be useful for:
●Modbus-to-MQTT workflows
●serial-to-JSON parsing
●machine status monitoring
●sensor data forwarding
●simple edge-side filtering
●MQTT, HTTP, API, or database integration
●proof-of-concept validation
●non-safety-critical alerting or notification flows
This is why many industrial IoT teams like it. It gives them a visual way to build and modify data flows without starting from a blank codebase.
But it should not be used without boundaries.
Node-RED should not be treated as a replacement for:
●PLC control logic
●deterministic real-time control
●safety-critical automation functions
●SCADA or MES platforms
●proper cybersecurity architecture
●long-term maintenance planning
The better question is not simply:
Can Node-RED do this?
A better question is:
Is Node-RED the right layer for this workflow, and can the flow be secured, monitored, updated, and maintained properly?
That second question is less exciting, but much more useful in production.
Where Robustel EG5120 fits
In Node-RED-based industrial IoT workflows, Robustel EG5120 fits into the site-side industrial edge gateway layer.
Its role is to provide the platform around the workflow: field-side connectivity, local application support, upstream communication, security functions, and remote gateway management.
For example, it may be relevant when teams need to:
●run Node-RED or other local applications at the edge
●connect supported serial or Ethernet-side equipment
●collect selected machine, sensor, meter, or PLC-side data
●publish prepared data to MQTT brokers or cloud systems
●use cellular connectivity for remote or backup communication
●manage deployed gateways over time
This does not mean EG5120 automatically makes a Node-RED flow production-ready.
The Node-RED logic still depends on the installed nodes, data source, protocol configuration, credentials, network settings, and maintenance process.
The gateway provides the industrial platform. The flow still needs to be designed responsibly.
Closing thought
Node-RED can be valuable on an industrial edge gateway when it is used for the right layer of the architecture.
It is not a replacement for PLCs, SCADA, MES, or safety-critical automation. It is better understood as a flexible workflow tool for collecting, transforming, and routing selected factory-floor data.
For many industrial IoT projects, that is already useful. It can shorten the path from available machine-side data to a working data flow, especially when teams are testing Modbus-to-MQTT, serial parsing, sensor forwarding, or simple cloud integration.
A product such as Robustel EG5120 can support this kind of site-side edge platform for local data flows, secure communication, and remote gateway management. The actual Node-RED workflows still need to be tested, documented, secured, and maintained over time.
For readers who want a concrete product reference, the Robustel EG5120 page gives more detail on its gateway capabilities and deployment options.
If you have used Node-RED in an industrial IoT project, I’d be curious to hear where things usually get tricky first: Modbus setup, serial parsing, MQTT topic design, flow maintenance, security, or scaling beyond the first pilot?
FAQs
Q1: Can Node-RED run on an industrial edge gateway?
Yes, Node-RED can run on an industrial edge gateway when the gateway provides the required software environment, runtime support, and computing resources. In this setup, Node-RED works as an application layer on the gateway, helping teams build data flows close to factory equipment.
Q2: What is Node-RED used for in industrial IoT?
In industrial IoT, Node-RED is often used for lightweight data flow tasks such as Modbus-to-MQTT workflows, serial data parsing, sensor data forwarding, MQTT publishing, HTTP API integration, and non-safety-critical monitoring logic. It is strongest in data collection, transformation, and routing rather than deterministic machine control.
Q3: Where does Robustel EG5120 fit in Node-RED edge workflows?
Robustel EG5120 fits into the industrial edge gateway layer. It can provide the site-side platform for running selected edge applications such as Node-RED, connecting supported field-side equipment, forwarding data to MQTT or cloud systems, and managing gateway deployments remotely. The final workflow still depends on project configuration, installed nodes, data sources, security settings, and maintenance planning.
Top comments (0)