Node-RED on Industrial Edge Gateways: Building Low-Code Data Flows for Factory-Floor IoT

Industrial IoT projects often start with a practical question: how can field-side data be collected, transformed, and forwarded without building a complete custom software application from the beginning?

In many factories, project teams may need to read selected Modbus values, convert serial data into a structured format, publish machine status to an MQTT broker, send sensor readings to a cloud endpoint, or test whether a brownfield machine can provide useful monitoring data. These tasks do not always require a large software platform during the early stage of a project. They often require a practical way to build and adjust data flows close to the equipment.

This is where Node-RED often becomes relevant.

Node-RED is not an industrial edge gateway by itself. It is a flow-based, low-code tool that can help teams connect data sources, transform values, apply simple logic, and route messages to other systems. When it runs on an industrial edge gateway, it can become part of the edge-side workflow layer for factory-floor IoT projects.

The gateway provides the industrial platform: field-side interfaces, network connectivity, local computing resources, security functions, and remote management. Node-RED provides the visual data flow environment that can help project teams build application-specific logic more quickly.

Used with clear boundaries, this combination can be useful for factory-floor data collection, Modbus-to-MQTT workflows, machine status monitoring, proof-of-concept projects, and lightweight edge-side data processing. It should not be treated as a replacement for PLCs, SCADA systems, MES platforms, or safety-critical automation logic.

The Role of Node-RED in an Edge Gateway Architecture

An industrial edge gateway usually sits between field-side equipment and upper-layer systems. It may connect to PLC-side devices, meters, sensors, machine controllers, serial equipment, Ethernet networks, cloud platforms, or remote monitoring systems.

Node-RED fits into this architecture as a workflow tool running on the gateway. It can help define what happens to selected data after it becomes available at the edge.

Layer	Role in the Architecture
Field-side equipment	Generates machine, sensor, meter, PLC-side, or process data
Industrial edge gateway	Provides field interfaces, compute environment, network connectivity, security functions, and deployment base
Node-RED	Builds flow-based logic for collecting, transforming, routing, and publishing selected data
MQTT broker, cloud, SCADA, database, or API	Receives prepared data for dashboards, alerts, reporting, or integration

This distinction matters. The edge gateway is the industrial platform. Node-RED is an application layer that can run on that platform when the environment is properly configured.

For example, a gateway may provide RS-485 connectivity to a field device and Ethernet or cellular connectivity upstream. Node-RED may then help build a flow that receives data, parses it, converts it into JSON, and publishes it to an MQTT broker or HTTP endpoint.

In this sense, Node-RED is useful because it helps connect the steps inside a data workflow. It does not remove the need for correct device configuration, protocol settings, data mapping, network design, or security control.

Running Data Flows Closer to Factory Equipment

Running Node-RED on an industrial edge gateway can make sense when the data flow benefits from being close to the source.

If every raw value must first be sent to a remote cloud system before it is filtered, formatted, or routed, the project may depend heavily on upstream connectivity and cloud-side processing. In some deployments, that is acceptable. In others, it is more practical to handle part of the workflow locally.

Edge-side data flows can help with several tasks:

• Reading or receiving selected field-side data
• Formatting raw values into structured messages
• Adding labels, timestamps, or equipment context
• Filtering repetitive values before sending them upstream
• Triggering simple event-based logic
• Publishing prepared data to MQTT, HTTP, database, or cloud services
• Testing a data path before building a larger application

This is especially useful in brownfield environments. Older machines, meters, or PLC-side devices may not provide modern cloud integration by default. A gateway with a local runtime environment can provide a practical place to build a bridge between field-side data and upper-layer systems.

The value is not that Node-RED makes every machine “smart.” The value is that it can help project teams build, test, and adjust selected data flows without starting from a full custom application every time.

Typical Factory-Floor Data Flows Built with Node-RED

Node-RED is often useful when a project needs lightweight data handling rather than deterministic machine control. The exact workflow depends on the installed nodes, the available interfaces, the gateway environment, and the project configuration.

Industrial Workflow	How Node-RED Can Help
Modbus to MQTT	Read or receive selected Modbus values, format payloads, and publish to an MQTT broker
Serial data parsing	Convert serial-side data into structured messages
Machine status monitoring	Turn run, stop, fault, or event signals into readable monitoring data
Sensor data forwarding	Collect local readings and send them periodically or by event
Local alert workflow	Trigger a message or notification when selected conditions are met
API integration	Send prepared data to HTTP endpoints, databases, or cloud services
Proof-of-concept validation	Test whether field-side data can support a larger industrial IoT project

These workflows are common because many industrial IoT projects begin with a narrow operational goal. A team may want to monitor whether a machine is running, track energy readings, send an alarm event, or validate whether Modbus data can be published to MQTT.

Node-RED can help build these flows visually, which is useful for system integrators, technical support teams, and project engineers who need to test data paths quickly. However, a visual flow does not automatically make the application production-ready. Data quality, access control, network security, failure handling, and maintenance ownership still need to be planned.

A Modbus-to-MQTT Flow Example at the Edge

A common industrial example is a Modbus-to-MQTT data flow.

In this type of workflow, a field-side device may expose values through Modbus RTU or Modbus TCP. The edge gateway provides the connection point, and Node-RED may be used to build the logic that reads, receives, transforms, and forwards the data.

A simplified workflow may look like this:

1. A field device generates data
2. A PLC-side device, energy meter, sensor, controller, or Modbus-enabled machine provides selected values.The edge gateway connects to the field-side interface
3. Depending on the deployment, this may involve RS-485, RS-232, Ethernet, or another supported path.Node-RED reads or receives selected data
4. A configured flow may use Modbus nodes, serial input, TCP input, MQTT nodes, HTTP nodes, or other project-specific components.Node-RED transforms the data
5. Raw values may be renamed, scaled, filtered, converted into JSON, or enriched with equipment context.Node-RED forwards the prepared message

The data may be published to an MQTT broker, sent to an HTTP API, written to a database, or forwarded to another system. For example, a raw value from an energy meter may need to become a structured MQTT payload that includes the equipment ID, measurement name, unit, timestamp, and current reading. A machine status signal may need to become a readable message such as “machine_02/status = running or line_01/fault = active”.

This example shows why Node-RED is often discussed together with edge gateways. The gateway provides the field-side and upstream connectivity. Node-RED helps define the data flow between those points.

Practical Uses and Clear Boundaries

Node-RED can be useful in industrial IoT projects, but it should be used with realistic expectations.

It is well suited for:

• Lightweight data flow orchestration
• Proof-of-concept and pilot projects
• Modbus-to-MQTT or serial-to-JSON workflows
• Simple data filtering and formatting
• MQTT, HTTP, API, and database integration
• Local event handling for monitoring use cases
• Non-safety-critical alert or notification workflows

It should not be treated as a replacement for:

• PLC control logic
• Deterministic real-time control
• Safety-critical automation functions
• SCADA or MES platforms
• Full industrial software lifecycle management
• Proper security architecture
• Long-term maintenance planning

This boundary is important. Node-RED is strongest as an edge-side data flow tool. It can help teams move selected operational data from field-side sources toward monitoring or integration systems. It should not be used to take over core machine control or safety-related functions.

For production deployments, the question should not be “Can Node-RED do this?” alone. A better question is: “Is Node-RED the right layer for this workflow, and can the flow be deployed, secured, monitored, and maintained properly?”

Production Considerations for Node-RED on Edge Gateways

Installing Node-RED on an industrial edge gateway is only the beginning. Production use requires more careful planning than a quick demo or lab test.

When Node-RED is deployed through Docker on an EG Series gateway, teams need to consider the gateway firmware version, Docker environment, SSH access, user permissions, container configuration, port mapping, and network access. Access to the Node-RED editor also needs to be controlled carefully, especially when the gateway is connected to wider networks.

Several production questions are worth asking:

• Is the gateway software environment ready for Docker-based deployment?
• Who is responsible for creating and maintaining the Node-RED flows?
• How will flows, credentials, broker settings, and API keys be backed up?
• Is the Node-RED editor exposed only through a controlled network path?
• Are firewall rules and remote access policies clearly defined?
• What happens if the Node-RED container stops?
• How will the gateway and application be monitored over time?
• Are updates to flows reviewed before being applied to production systems?
• Does the workflow require deterministic control or safety logic? If so, Node-RED may not be the right layer.
• How will the project scale if more devices, lines, or sites are added later?

These questions help prevent a low-code workflow from becoming an unmanaged production risk. Node-RED can make data flow development faster, but it still needs responsible deployment practices.

For implementation-level guidance, this article “How to Install Node-RED on EG Series Devices via Docker” provides step-by-step deployment details for EG Series gateways.

EG5120 as an Industrial Platform for Node-RED-Based Workflows

For Node-RED-based edge data flow projects, the Robustel EG5120 can serve as an industrial edge gateway platform. Its role is not only to host an application, but also to provide the industrial interfaces, connectivity, local computing resources, security functions, and remote management features needed around that application.

Node-RED Edge Workflow Need	Relevant EG5120 Capability	Why It Matters
Running Node-RED on the gateway	RobustOS Pro, Debian-based environment, Docker support	Provides the software environment for containerized Node-RED deployment
Connecting field-side equipment	2 x software-configurable RS-232/RS-485 and 2 x Gigabit Ethernet ports	Supports serial-side or Ethernet-side equipment integration where project interfaces match
Capturing simple machine signals	2 x DI + 2 x DO wet contact interfaces	Supports selected status or event monitoring where only discrete signals are available
Local data handling	Quad-core Cortex-A53 CPU, up to 4 GB RAM, and 64 GB eMMC	Supports edge-side flow execution, parsing, formatting, and lightweight application logic
Upstream connectivity	5G/4G/3G/2G cellular support, dual SIM, and Ethernet connectivity	Supports data forwarding to MQTT brokers, cloud systems, or remote applications
Securing communication paths	VPN options, firewall functions, access control, and port mapping	Helps build controlled communication paths between field-side systems and upper-layer networks
Managing deployed gateways	RCMS, Web, CLI, and SMS remote management	Supports configuration, monitoring, updates, and long-term gateway management
Industrial installation	Metal housing, 9–60 VDC input, DIN rail, wall, or desktop mounting, and -40 to +70°C operating temperature	Supports deployment in factory cabinets, equipment rooms, or industrial environments

These capabilities make the EG5120 relevant to Node-RED workflows because the gateway can combine edge-side application hosting with industrial connectivity and device management.

Still, the final application depends on the project design. EG5120 provides the platform and interfaces, but the Node-RED flow itself depends on the installed nodes, data source, protocol configuration, credentials, security settings, and maintenance process.

Project Scenarios Where Node-RED Can Add Value

Node-RED is often most valuable when a project needs a flexible data flow before a larger system is fully defined.

It may be a good fit when:

• A system integrator needs to validate data from a Modbus device
• A factory wants to test machine status monitoring from an older production line
• A project team needs to convert selected sensor readings into MQTT messages
• A remote site needs lightweight alert logic before data is sent upstream
• A brownfield machine provides useful signals, but not a ready-made cloud connector
• A pilot project needs to prove that field-side data can support reporting or maintenance workflows
• A team wants to prototype an API or MQTT integration before developing a custom application

It may be less suitable when:

• The application requires deterministic control
• The workflow affects safety-critical operations
• The project requires strict validation, version control, or regulated software processes
• The data flow becomes too complex to maintain visually
• The team lacks a plan for security, backups, updates, and long-term support

This does not mean Node-RED should be avoided in production. It means it should be used for the right layer of the architecture. For many industrial IoT projects, that layer is edge-side data collection, transformation, and forwarding — not core automation control.

Closing Perspective

Node-RED becomes valuable on an industrial edge gateway when it is used as a practical workflow layer for selected data collection, transformation, and forwarding tasks.

The edge gateway provides the industrial platform. Node-RED helps project teams build and adjust the data flow. Together, they can support factory-floor IoT projects where teams need to connect field-side data to MQTT brokers, cloud systems, dashboards, APIs, or monitoring platforms without building a full custom application from the beginning.

The important point is to keep the boundary clear. Node-RED can help turn raw field-side data into more usable industrial IoT information, but it should not replace PLC control logic, SCADA systems, or safety-critical automation functions.

For factories, system integrators, and industrial IoT teams, the value of running Node-RED at the edge is practical: it can shorten the path from available machine-side data to a working data flow, while still keeping the gateway close to the equipment and under industrial deployment control.

FAQs

Q1. Can Node-RED run on an industrial edge gateway?

A1: Yes, Node-RED can run on an industrial edge gateway when the gateway provides the required software environment, such as Linux, Docker support, and sufficient computing resources. In this type of setup, Node-RED runs as an application layer on the gateway, helping teams build data flows close to factory equipment. The exact deployment depends on the gateway model, firmware version, container configuration, network access, and project requirements.

Q2. What is Node-RED used for in industrial IoT?

A2: In industrial IoT, Node-RED is often used to build lightweight data flows between field-side equipment and upper-layer systems. It can help collect selected data, parse serial or protocol-based values, format messages, apply simple logic, publish data to MQTT brokers, send data to HTTP APIs, or trigger basic monitoring alerts. Its value is strongest in data collection, transformation, integration, and proof-of-concept workflows, rather than real-time machine control.

Q3. Can Node-RED be used for Modbus-to-MQTT workflows?

A3: Yes, Node-RED can be used in Modbus-to-MQTT workflows when the required nodes, device configuration, and network settings are properly set up. A typical flow may read selected Modbus values, map raw register data into meaningful tags, format the data as JSON, and publish it to an MQTT broker. However, the workflow still depends on correct Modbus addressing, register maps, polling settings, topic design, payload structure, and security configuration.

Q4. Is Node-RED reliable enough for industrial production use?

A4: Node-RED can be used in industrial production environments for suitable tasks, especially monitoring, data forwarding, simple integration, and non-safety-critical workflows. However, production use requires proper planning. Teams should consider flow backup, credential management, access control, container monitoring, failure handling, update procedures, and ownership of flow changes. Node-RED should not be treated as a shortcut around industrial software governance, especially in critical operations.

Q5. Can Node-RED replace a PLC, SCADA system, or MES platform?

A5: No. Node-RED should not be used as a replacement for PLCs, SCADA systems, MES platforms, or safety-critical automation logic. PLCs remain responsible for deterministic machine control and local automation. SCADA and MES systems provide broader supervision, production management, and operational functions. Node-RED is better understood as a flexible edge-side workflow tool for collecting, transforming, and routing selected data between systems.

About the Author

Robert Liao | Technical Support Engineer

Robert is an IoT Technical Support Engineer at Robustel, specializing in industrial networking and edge connectivity. A certified Networking Engineer, Robert focuses on the deployment and troubleshooting of large-scale IIoT infrastructures. His work centers on architecting reliable, scalable system performance for complex industrial applications, bridging the gap between field hardware and cloud-side data management.