Connect OPC UA to Grafana

Before you start

• A time-series store that already holds the data, in the normal architecture. Grafana is the last hop, and the collection decisions that determine whether a dashboard can be correct were made upstream.
• If you intend to use an OPC UA plugin instead, its current maintenance state, its licence, and whether it is signed. Grafana restricts unsigned plugins by default and allowing them is a deliberate configuration change with security consequences.
• A clear statement of which timestamp the stored data carries, source or collection time, because every dashboard calculation inherits it.
• Agreement on the dashboard timezone and on shift boundaries, before anyone builds a panel that aggregates by day.

Setting it up

1. Decide where OPC UA stopsIn almost every production deployment the chain is OPC UA client to database to Grafana, with a collector such as Telegraf or a publisher in the middle. Draw that chain before building panels, and be able to say which component holds which responsibility.
2. Point Grafana at the store, not at the plantAdd the time-series database as a data source with a read-only account. This keeps Grafana off the industrial network entirely, which is both the simplest security answer and the reason this architecture is the common one.
3. If you must use an OPC UA plugin, treat it as an OPC UA clientIt needs an application instance certificate, a place to keep trusted and rejected certificates, and the server must trust it. It also opens a session and consumes server capacity per Grafana instance, so an embedded PLC server may refuse a second dashboard user.
4. Build panels on the right aggregation for the signalState signals want last value or a state timeline, counters want a difference or increase function rather than a mean, and analogs want an average over the panel interval. Using a mean on a monotonic counter produces a plausible line that means nothing, and it is the most common OEE dashboard error.
5. Make bad quality visibleIf the collector stored StatusCode alongside the value, filter or colour on it. A dashboard that plots the last known value through a communication outage as a flat line will be believed, and it will be wrong.
6. Pin the timezone and align windows to shiftsSet the dashboard timezone explicitly rather than leaving it to the browser, and build shift windows as explicit ranges. Availability computed over a browser-local calendar day will disagree with production's own numbers, and the disagreement will be blamed on the data.
7. Alert on collection health, not only on process valuesAdd an alert on data staleness per machine. A silent collector looks exactly like a machine running steadily, and this single alert prevents most of the trust damage a machine-data dashboard can do.

What the address space looks like

Grafana sees rows, not an address space. Whatever structure the OPC UA server had, browse hierarchy, type definitions, engineering units, is either flattened into measurement and tag names by the collector or lost. That means the semantic work has to happen upstream: if the collector wrote each node as an opaque series name, no Grafana configuration can recover which machine a value belongs to or what it means. The practical rule is to make the collector emit a small, stable set of dimensions, machine identity, signal name, unit, and to keep the OPC UA namespace URI and identifier stored alongside as metadata, so a panel can be traced back to a node when someone disputes a number.

The traps

• Expecting a first-party OPC UA data source is the first mistake. There is not one, and adopting a third-party plugin means accepting its maintenance state, its licence and its security posture as part of your architecture.
• Allowing unsigned plugins is a server-wide configuration change on the Grafana instance, not a per-plugin one. Understand what else that permits before enabling it.
• A mean or average applied to a monotonic counter is the classic OEE dashboard bug. Counter series need a difference or increase function and explicit handling of resets and rollovers.
• Grafana interpolates and downsamples for display. A panel showing a smooth line at a one-hour window can be hiding the short stops that the whole OEE analysis depends on, so build the downtime analysis on stored events, not on a resampled trend.
• Browser-local timezones make dashboards disagree with each other and with the plant's own shift reports. Pin the timezone on the dashboard.
• A dashboard that plots held or last-known values without quality is actively misleading during an outage, and it undermines confidence in every other panel once someone notices.
• If a plugin is doing the OPC UA connection, each Grafana instance or refresh may open a session against an embedded server with a very low session ceiling.

Getting OEE data out of it

Grafana can display availability, performance and quality, and can compute them from stored data with reasonable honesty, provided the upstream collection gave it state transitions rather than sampled snapshots, counters rather than inferred edges, and downtime reasons as timestamped records. What it cannot do is manufacture the resolution it was not given: a state stored once a minute cannot support micro-stop analysis, no matter how the panel is written. Shift calendars, planned production time and standard cycle times are not in the machine and are not in the time-series store either unless someone put them there, so they usually arrive as a static table or a second data source, and they need an owner. Treat every OEE panel as a claim that has to reconcile with production's own figures, and expect the first reconciliation to expose a collection problem rather than a dashboard problem.

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.