Integration · Integration

Connect OPC UA to Node-RED

ProductNode-RED
CategoryIntegration
OPC UA roleClient

Node-RED talks OPC UA through community nodes rather than a built-in capability, which makes it excellent for prototyping a client in an afternoon and risky as a production collector. The two recurring problems are certificate handling, which the nodes expose only partially, and the single-threaded runtime, which high-rate subscriptions will overwhelm.

Before you start

  • A Node-RED installation with a supported Node.js runtime, and permission to install palette nodes on it. In an OT network that permission is often the actual blocker.
  • An OPC UA client node set installed from the palette. Several competing community packages exist with different node names, different configuration and different maintenance states; pick one and be consistent across your flows.
  • A working endpoint URL and a clear decision about security. If you intend to run signed and encrypted, verify that your chosen node package supports the policy the server offers before you build the flow.
  • Somewhere for the data to go that is not Node-RED. It has no durable buffer of its own.

Setting it up

  1. Install one OPC UA node package and stay on itInstall from the palette manager, then note the package name and version in your project notes. Mixing two OPC UA packages in one Node-RED instance produces confusing duplicate node types and conflicting certificate directories.
  2. Prove the endpoint with security None firstConfigure the client node with the endpoint URL and no security, and read a single known node. This separates network and endpoint problems from certificate problems, and it takes a minute.
  3. Do the certificate work explicitlyFind where your node package stores its client certificate and its trusted and rejected folders on disk, then complete the exchange in both directions: the server must trust the Node-RED client certificate, and the client must trust the server certificate. This is the step that turns a demo into something that survives a security review.
  4. Address nodes by namespace URI where the package allows itMost community nodes take a NodeId string with a literal namespace index, often carried in the message topic. If the package supports resolving by namespace URI, use it. If it does not, read the NamespaceArray in a function node at flow start and build the NodeId strings from that, rather than pasting indexes into every node.
  5. Subscribe rather than poll, and rate-limit before anything downstreamUse the package's subscription or listener node with a publishing interval matched to what the consumer needs. Then put a rate limiter or an aggregation node between the subscription and any node that does real work, because every message runs on the same event loop as the rest of your flows.
  6. Handle reconnection as a first-class caseWire the client node's status output to something that logs and alerts. Test by blocking the endpoint at the firewall and watching whether the flow recovers on its own or needs a redeploy, because the answer differs by package and version.
  7. Get the data out to durable storage immediatelySend messages straight to an MQTT broker, a time-series database or a file, and keep transformations after that hop. Node-RED restarts on every deploy, and anything held only in flow context at that moment is gone.

What the address space looks like

Node-RED does not build a model. Each message carries one value, or a small batch, with whatever the node package chose to expose of the DataValue: usually the value itself, sometimes the StatusCode and the timestamps, and often not the type information. Address-space structure is something you rediscover per flow with a browse node, and it is not retained. That is acceptable for prototyping and for glue work, but it means the semantics of your data live in the flow layout and in node names, which are not queryable, not versioned by default and not portable to the next machine. If the same mapping is going to be used twice, generate the NodeId list from a browse and keep it as a file the flow reads.

The traps

  • The community nodes are not uniform in quality or maintenance. Node names, message formats and certificate directory layouts vary between packages and between versions of the same package, so record which package and version a flow was built against.
  • A literal namespace index pasted into every node is the standard Node-RED failure mode. After a PLC program download the whole flow returns BadNodeIdUnknown at once, and there is no single place to fix it.
  • Certificate handling is the weakest part of most packages, which is why so many production Node-RED collectors quietly run with security None. That is a decision someone should make consciously, not a default to inherit.
  • Node-RED is single-threaded. A subscription with a 50 ms publishing interval on a few hundred items will starve the event loop and make the editor itself unresponsive, and the symptom looks like a network problem.
  • A deploy restarts flows, which drops sessions and subscriptions. Deploying a small dashboard change interrupts collection, so a Node-RED instance doing collection should not also be the instance people edit during a shift.
  • There is no store-and-forward. If the downstream sink is unavailable, the messages are simply lost unless you built a buffer yourself.
  • Server-side session limits are consumed per client node, and a flow with several client nodes against one embedded PLC server can exhaust them.

Getting OEE data out of it

Node-RED is a good place to explore what a machine exposes and a poor place to compute OEE. It can read a state variable, a counter and a reason code and forward them, which is genuinely useful for a proof of concept or for a machine that nothing else can reach. What it will not give you is the reliability the calculation needs: no durable buffer, collection interrupted by every deploy, and timing that depends on an event loop shared with everything else in the instance. If a Node-RED collector is going to production, keep it to one job, get values to a broker or database immediately with the server timestamps intact, and compute availability, performance and quality downstream where a gap is visible and reprocessable. Planned production time, shift calendars and standard cycle times are not in the machine and should not be hardcoded into a flow.

Verify before you rely on this: Which community OPC UA package is currently maintained, what node types and message formats it provides, which security policies it supports and where it keeps its certificate stores all change with the package and with Node-RED itself, and no third-party page including this one is a safe source for it. Check the package's own current documentation and issue tracker for the version you install, and confirm supported Node.js versions before deploying on an OT host.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.

Free download
OPC UA Machine Data → OEE Mapping Kit
Which nodes to subscribe to, how they become Availability, Performance and Quality, and which companion specification already gives you the answer, so you stop inventing tags.
Get the free mapping kit →
Free, no course, no login