Case study 01 / 22Data Engineering

Plant calculations rebuilt as reusable n8n nodes, checked 1:1

Rebuilt a plant's sensor score and leak model as tested n8n nodes, matched them 1:1 to the originals, then improved them beside the copy.

Stack

n8n
TypeScript
Node.js
OPC UA
Three.js
InfluxDB
MongoDB

01 · How it works

TodaytoChanged in this work
Data flow

What it does

An app built on n8n, with n8n's own code untouched, where plant calculations are nodes an engineer chains in the editor: my read-only node reads an industrial OPC UA server and gives one output per signal, and calculation and UI nodes turn those signals into scores, alarms and pages. I rebuilt two existing calculations node for node and checked each against its original, a sensor-quality score and a 57-node leak-detection model from a desktop application, then built an improved model beside the 1:1 copy, a test bench that scores both against known leaks, and a plan to run the same nodes in memory to test a thousand cases an hour.

7 connections· select a part to trace it

OPC UA server to Read-only n8n node: polled, never written
Read-only n8n node to 1:1 workflows: one item per tag
Read-only n8n node to Improved, in lanes: the same readings
1:1 workflows to Compare node: the reference
Improved, in lanes to Compare node: the candidate
1:1 workflows to Pages from UI nodes: scores and alarms
Compare node to Pages from UI nodes: where they part, and why

02Results

R01Higher is better
Automated tests, desktop application vs n8n node kit
Before 1, after 1,278, 1,278× higher. Higher is better.
Before
After
R02Lower is better
CPU per pipeline, % of a core (different machines)
Before 163%, after 2.1%, 78× lower. Lower is better.
Before
After
R03Higher is better
Mean score on 48 bench runs, 1:1 copy vs improved
Before 75.4, after 85, +13%. Higher is better.
Before
After

What it achieved

Sensor-quality score: a hand-written graph in a collector → a 13-node n8n workflow with the same score for 241 of 242 sensors over a recorded hour, and 0 new requests to the existing application
Leak-detection model: only inside a desktop application → 57 of 57 nodes in n8n, with the same leak state on every recorded minute, 0 false alarms and 99.2 % of alarm rows equal
Proof of the copy: 1 automated test → 1,278, plus an oracle that runs the original's own library beside the nodes: 10,039 of 10,039 cases equal bit for bit

CPU per pipeline: 163 % of a core for the desktop application → 2.1 % for its 1:1 copy and 7.4 % for the improved model, measured on different machines
Pages: hand-written screens → pages assembled from 7 UI nodes in the same flow, from a monitoring page to live 3D views
Changing the model: argued by opinion → 12 of 25 proposed changes kept after a review against code and data; on 48 bench runs the improved model scored 85.0 to the copy's 75.4

The challenge

The logic lived in a desktop application and a hand-written collector: changing a threshold meant code, a build and a deploy per server, and the application already answered 61 requests a minute against a budget of 60, so nothing new could poll it. A copy is only worth something if it is exact, and the original had one automated test.

Its quirks had to be found and copied on purpose, 27 in the sensor score alone, listed one by one, so the copy could serve as the reference. The development signals barely moved: in the recorded hour only one system's sensors changed, so agreement had to be shown on recordings and by running the original's own library beside the nodes, not on live behaviour.

What I learned

Copy first, improve second. Rebuilding the logic 1:1 before changing it gave every later change a reference: the improved model runs beside the copy on the same readings, and a node that compares the two branches shows where and why they part. Copying faithfully meant copying the original's mistakes on purpose and listing each one, so fixing one became a decision with a number. n8n carried the plumbing, from triggers and item lists to the editor and its execution history, but at about 120 ms per execution it is too slow for mass testing: the next step runs the same nodes in memory, identical byte for byte or not used at all.