FlowFuse

FlowFuse 2.29: FlowFuse Expert Comes to Self-Hosted Enterprise

2026-04-09T00:00:00Z

FlowFuse 2.29 gives teams more control over how flows move through their stack, makes it easier to understand what changed between versions, and brings FlowFuse Expert to self-hosted enterprise customers.

FlowFuse Expert, Available to More Teams and More Capable

FlowFuse Expert is our integrated AI assistant — one consistent surface across the FlowFuse website, platform, and immersive Node-RED editor for troubleshooting, building, and getting targeted help.

Self-Hosted Enterprise

FlowFuse Expert was previously only available to cloud customers. Self-hosted enterprise teams had no equivalent surface for in-context troubleshooting and guidance.

Expert is now available for self-hosted enterprise FlowFuse instances. Your team gets the same contextual guidance and targeted help as cloud customers, with your operational data staying on your own infrastructure.

Take Action Directly from Expert Responses

Expert responses previously surfaced information and suggestions. Acting on them — importing a flow, selecting relevant nodes, opening a new tab — required switching out of the conversation and doing it manually.

Expert responses can now include clickable action links. Click one and Expert performs the action directly in your editor: opening a new flow tab, selecting the nodes it just mentioned, or importing a flow from the conversation.

Expert responses can now act on your behalf — click a link and Expert opens a tab, selects nodes, or imports a flow directly in your editor.

Coming next: spinning up Node-RED instances directly from Expert, letting you go from idea to running flow without leaving the chat.

In practice

You act on Expert suggestions in one click instead of manually applying them
You stay in the conversation while Expert works in your editor

More Visibility and Control Across Your Deployment Workflow

Managing flows across environments means tracking what changed, when, and by whom. When tooling gaps introduce friction here — or leave your version control workflow fragmented — they slow teams down at exactly the wrong moment.

Azure DevOps Git Integration

FlowFuse's GitOps support previously required GitHub. Teams standardised on Azure DevOps had no native way to include Node-RED flows in their existing version control workflow.

FlowFuse 2.29 adds Azure DevOps as a supported Git provider. You can now push and pull snapshots directly from Azure DevOps repositories using Personal Access Tokens, configured under Team Settings → Integrations.

In practice

You connect Azure DevOps repos alongside or instead of GitHub
Your Node-RED flows participate in the same version control workflow as the rest of your stack
You authenticate with Azure Personal Access Tokens, with no secondary tooling required

See Exactly What Changed in a Snapshot

FlowFuse's snapshot comparison view showed flows side by side, but the visual alone doesn't always tell the whole story. You could see that a node was different, but not which specific property changed. When a function node's code changed, you couldn't identify which lines were different without manually diffing two code blocks outside of FlowFuse.

The compare dialog now shows exactly which properties changed and highlights line-level differences in function code, templates, and JSON — no manual diffing required.

The compare dialog now includes a property-level diff sidebar: structural property changes old to new at a glance, and git-style line diffs for function code, template HTML, and JSON. A navigation bar steps through every changed, added, or deleted node with arrow key shortcuts. The canvas highlights and scrolls to the current node as you navigate.

In practice

You review what changed between dev and production without leaving FlowFuse
You validate a teammate's update at the property level, not just the node level
You debug why a flow changed after a deploy with the same tooling you use to promote it

What else is new?

Expert opens by default: FlowFuse Expert now opens automatically when you visit the editor for the first time. If you close it, that preference is remembered across browser sessions.
Embedded editor tab titles: Hosted and Remote Instance editor tabs now show the actual Node-RED flow name rather than a generic title.
Instance URL env var: Hosted Node-RED instances now expose an FF_INSTANCE_URL environment variable containing the instance's URL (default or custom hostname). Useful for flows that need to know their own address, like webhook callbacks or OAuth redirects.
Blueprint markdown rendering: Blueprint descriptions now support markdown rendering, so formatting like headers and lists display as intended.

Fixes

MCP server discoverability: Older MCP servers that were registered on your instances were not showing up in Expert Insights mode. All registered MCP servers are now discoverable again.
Snapshot detail in the immersive editor: Reviewing a snapshot from inside the immersive editor now opens it in a modal, so you can inspect snapshots without leaving the editor.
Developer Mode tab restored in the immersive editor: The Developer Mode tab is back in the immersive editor drawer, letting you toggle Auto Snapshots and create snapshots without opening a second window.

Node-RED

Node-RED 4.1.8 is now available as a stack option in FlowFuse. Highlights include function node tab badges (see at a glance which tabs contain code), theme plugin overrides for settings and menu options, configurable palette categories via theme plugins, and show-first/last-tab keyboard actions.

Looking ahead, Node-RED 5.0 is in beta. It's a modernization and UI re-architecture that readies Node-RED for better AI-guided development and brings more clarity to manual editing. FlowFuse will ship 5.0 once it reaches stable release.

For detailed breakdowns of each feature with additional visuals, visit our changelog. For the complete list of everything included in FlowFuse 2.29, check out the release notes.

If something in this release improves your workflow, or if there is still friction we can remove, please share feedback or report issues regarding this release to us.

The Real Cost of Over-Engineered Industrial Systems

2026-04-08T00:00:00Z

There is a system in your facility that your best engineer knows not to touch.

Not because it's dangerous. Because the last time someone touched it, a three-hour troubleshooting session ended with a call to an integrator who no longer works at the company that built it. The system came back up. Nobody knows exactly what fixed it. The incident report says "configuration restored" and leaves it there.

That system was delivered on time. It passed commissioning. The project manager closed it as a success. What it delivered, along with the data integration it was scoped to provide, was a permanent dependency on knowledge that exists nowhere formally and in fewer heads every year.

This is what over-engineering looks like from inside a facility that didn't make bad decisions. It looks like a system that works, that everyone is quietly glad isn't their responsibility, and that will eventually fail in a way nobody can diagnose quickly. The complexity that created it didn't arrive as a mistake. It arrived as a series of reasonable choices made by people who weren't going to be there when the choices compounded.

What Complexity Actually Costs You

The cost shows up in three places. None of them are in the project budget.

Downtime that should take minutes takes hours.

A simple system fails in a way that matches its architecture. A Modbus timeout is diagnosable by anyone who understands the protocol. A failure inside a multi-layer stack, where data moves through a gateway, a middleware service, a message broker, and a cloud connector before it reaches its destination, has no obvious entry point. Every layer is a candidate. Every layer requires different tooling to inspect. And while the team works through them one at a time, production waits.

The failure itself is often minor. The diagnostic time is what costs. And diagnostic time scales directly with architectural complexity, not with the severity of the fault.

The person who understands it becomes the system.

Every complex system eventually concentrates its operational knowledge in one or two people. Not by design. By attrition. The team that inherited the system learned the parts they needed to. The parts nobody needed to touch, nobody learned. Over time, the person who has touched the most parts becomes the single point of failure the system never documented.

When that person leaves, the system doesn't fail immediately. It just becomes untouchable. Problems get worked around. Upgrades get deferred. The system runs in a state of managed risk that everyone acknowledges privately and nobody escalates formally, because escalating it means admitting how fragile something critical has become.

Modernization stops at the layer nobody understands.

Every facility has a modernization initiative. Cloud connectivity. Real-time analytics. Unified namespace. The vocabulary changes but the ambition is consistent. What doesn't change is the conversation that happens six weeks into the scoping exercise, when the architect traces the data path and hits the layer nobody has documentation for.

That layer doesn't get modernized. It gets routed around. The new system gets built on top of the old one, inheriting its limitations and adding its own. The budget meant to move the facility forward ends up funding infrastructure that looks new from the outside and runs on assumptions from 2017 underneath.

Simple Systems Outlive Sophisticated Ones

Industrial systems are not software products. They don't get refactored on a two-week sprint cycle. They run. For years. Sometimes decades. Through shift changes, workforce turnover, firmware updates that nobody planned for, and organizational restructures that change who owns them without changing what they do.

That timeline is what makes complexity so expensive in operational technology. A sophisticated architecture in a software product gets maintained by the team that built it, updated continuously, and replaced when it no longer fits. A sophisticated architecture in a plant gets handed to whoever is there three years later, maintained defensively, and never replaced, because replacement means downtime and downtime means a conversation nobody wants to have.

The systems that survive this timeline are not the most capable ones. They're the most understood ones. The ones where the logic is visible, the failure modes are predictable, and the next engineer can read the configuration and understand what it does without needing to call the person who wrote it.

That property, legibility, is not a soft preference. It's a hard operational requirement that almost never appears in a project specification and almost always determines whether a system ages well or becomes the thing nobody touches.

Workforce turnover alone makes the case. The average tenure of an industrial automation engineer is somewhere between three and five years. The systems they build are expected to run for fifteen to twenty. Every system will be operated, maintained, and eventually modified by people who had no part in designing it. The question is whether it was built with that reality in mind, or whether it was built to impress the people in the room on the day it was commissioned.

Simplicity Is an Engineering Decision

Consider Modbus. It has been declared obsolete for thirty years. Richer protocols have been developed, standardized, and backed by industry consortia with considerably more resources than the original Modbus specification ever had. Modbus keeps running. Not because the industry failed to move on, but because for a significant class of problems, Modbus is exactly as capable as the problem requires and no more. That match between problem and solution is not a limitation. It's the definition of good engineering.

The instinct is to treat simplicity as the absence of something — less capability, less sophistication, the option you choose when budget runs out or when the team isn't skilled enough to operate something better. That instinct is wrong.

Simplicity in engineering is not what you start with. It's what you arrive at. It's the outcome of understanding a problem well enough to know what it doesn't require. That's a harder position to reach than adding another integration layer, and it's a harder position to defend in a project meeting where the vendor is presenting a roadmap. But facilities that get there build systems that outlast the people who designed them — systems that new engineers can inherit without a month of archaeology, and that fail in ways the overnight technician can diagnose without calling anyone.

If you're a plant manager or engineering lead looking at your current architecture, the useful question isn't "what could this system do." It's "what does this system need to do, and what is the simplest architecture that does it reliably." That question doesn't produce primitive infrastructure. It produces infrastructure your whole team can own, where new requirements can be added without excavating the past, and where five years from now the design looks like a deliberate decision rather than something that just accumulated.

The facilities with the best operational track records made a specific tradeoff early. They accepted less capability at design time in exchange for more resilience over time. They built systems their whole team could own, not systems only their best engineer could explain. That tradeoff looks conservative in a project meeting. It looks correct every year after.

What a Well-Matched Architecture Actually Looks Like

A well-matched architecture is not a polite term for cheap. It is not a consolation for teams that couldn't get the budget for something better. It is a specific outcome, a system where every component earns its place, the stack matches the actual problem, and the team that operates it has complete visibility into how it works and why.

In practice it looks like this.

A facility has forty legacy devices on the floor. PLCs, drives, meters, sensors — most of them speaking Modbus, some speaking older serial protocols, none of them going anywhere soon because they're running processes that haven't changed and won't change. The facility needs that data upstream: a cloud historian, a SCADA system, an analytics platform the operations team has been waiting two years to get real data into.

The over-engineered answer replaces the devices, or layers a complex middleware platform across all of them, or implements a protocol migration that requires specialist involvement at every stage and produces an architecture the in-house team can monitor but not truly operate.

The right answer puts an edge gateway between the floor and everything above it. The gateway reads Modbus from the devices that have always spoken Modbus. It normalizes the data, applies context, and publishes it upstream over MQTT or OPC UA to whatever system needs it. The field devices keep running exactly as they always have. The modern infrastructure gets clean, structured data. The in-house team owns the entire stack because the entire stack is visible and configurable without a specialist on call.

That is not a compromise. It is the correct answer for that problem. It connects legacy infrastructure to modern systems without introducing dependencies the team can't manage, without requiring production downtime to implement, and without creating a layer that becomes untouchable eighteen months after the integrator leaves.

How FlowFuse Keeps It Simple

The gateway architecture described above is not a new idea. Facilities have been running edge gateways for years. The problem has never been the concept. It has been the execution: gateways that are simple to deploy and complex to manage, that work correctly in isolation and become coordination problems at scale, that solve the connectivity challenge and create a new one around visibility, consistency, and control.

FlowFuse is an Industrial Application Platform built around Node-RED at the edge. The FlowFuse Device Agent connects to the devices that have always been on the floor — Modbus, MQTT, OPC UA, serial protocols — and publishes structured data upstream to whatever system needs it. The flow is visible. The logic is readable. An engineer who has never touched the system before can open it and understand what it does without documentation that may or may not exist.

That last part matters more than any feature list. The single most expensive property of an industrial system is whether the team that inherits it can operate it confidently. FlowFuse is designed around that property. Flows are managed centrally, deployed consistently across every edge device in the facility using DevOps Pipelines, and monitored from a single place. When something changes, DevOps Pipelines push it across every device it needs to reach, with Snapshots providing version control and rollback, not through a manual process that depends on someone remembering which devices were updated and which weren't.

Where teams need to build faster or debug more confidently, FlowFuse Expert, the AI built into FlowFuse and the Node-RED editor, reduces friction at the design stage, before complexity has a chance to accumulate. It works in two ways. The Chat Interface, accessible directly within the Node-RED editor, supports flow-building assistance and live operational data queries via MCP tools. The AI in Node-RED works inside the editor itself: inline code completions, flow autocomplete, a function builder, a flow explainer, JSON generation, and CSS and HTML generation for FlowFuse Dashboard. It doesn't generate complete flows from scratch, but it assists meaningfully at each step, suggesting the next node, completing a function, explaining logic that was written by someone who's no longer there. The result is less time spent on archaeology and more time spent on the work that actually moves the facility forward.

The result is an architecture that connects legacy infrastructure to modern systems without adding the complexity that makes those connections fragile. The Modbus devices on the floor keep running. The cloud historian, the SCADA system, the analytics platform get the data they need in the format they expect. The in-house team owns the stack end to end because the stack was designed to be owned, not just operated.

The system nobody wants to touch is built by engineers who won't be there to maintain it. The system the next engineer is glad to inherit is built by engineers who understood the difference. That's the decision FlowFuse is designed to support.

Most Modbus Polling Setups Are Wrong — Here's How to Fix Yours

2026-04-03T00:00:00Z

Modbus polling looks simple. It is simple. That's the problem.

You set a scan rate, point it at a device, start reading registers, and data flows. It works. So nobody looks at it again.

Except "working" and "working correctly" are different things in Modbus polling, and the gap between them is where most engineers quietly lose data, burn network bandwidth, and cause the intermittent device dropouts that get blamed on hardware.

The mistakes aren't exotic. They're the same ones across almost every installation: polling everything at the same rate, ignoring timeouts, stacking too many registers into single requests, or hammering slow devices with back-to-back queries they were never designed to handle. None of these are obvious from the outside because Modbus doesn't complain. It just silently drops a frame or lets the device go quiet — and your polling stack fills in the gap by returning the last successfully read value, making the problem invisible until someone notices the data has stopped changing.

This article isn't about the basics of how Modbus works. If you need that, start here. This is about the specific configuration decisions that separate a polling setup that stays stable for years from one that causes problems at the worst possible time. Part 1 covers the three mistakes made at commissioning. Part 2 covers what happens after the system is running.

The Myth of the Universal Scan Rate

Every Modbus polling setup has a scan rate. Most setups have one scan rate. That's where the trouble starts.

The default in most SCADA systems, Node-RED flows, and industrial gateways is to configure a single polling interval and apply it uniformly across every register on every device. 500ms. 1 second. 5 seconds. Pick a number, apply it everywhere, call it done. It's the configuration decision that takes thirty seconds and then gets inherited by every engineer who touches the system after you.

The problem isn't the interval you picked. The problem is that one interval is the wrong answer for almost every real installation.

Consider what's actually living in a typical Modbus device: a temperature reading that changes slowly over minutes, a motor running-hours counter that increments once per hour, an alarm status bit that can flip in under a second, and a setpoint register that only changes when an operator touches it. These are not the same kind of data. Polling all of them at the same rate means you've optimized for nothing and made tradeoffs you never consciously chose.

Polling too fast punishes your bus and your devices. RS-485 is a shared medium. Every query you send to one device occupies the bus for the duration of that transaction: the request frame, the device processing time, and the response frame. On a 9600 baud network with 20 devices, a 500ms scan rate across all of them isn't 500ms per device. It's a queue. If each transaction takes 50ms, your 20-device poll cycle takes a full second to complete, which means the data you're getting from device 20 is already a second stale before you even start the next cycle. Slow sensors get polled ten times before their value could possibly have changed. Fast-changing signals still get missed.

Polling too slow loses events. A motor fault flag that goes high for 800ms and then clears on its own will be completely invisible to a 1-second polling interval. Not occasionally invisible, reliably invisible. The bit flipped, the motor logged an internal fault, the fault self-cleared, and your polling cycle saw nothing but normal values on both sides of the event. You'll hear about that fault months later when the motor fails completely and maintenance pulls the device logs.

The fix isn't complicated, but it requires making a deliberate decision you've probably been deferring: categorize your data by how fast it actually changes, then assign poll rates to match.

A practical starting framework for most industrial installations:

Fast (100 to 500ms): Alarm and fault status bits, safety interlocks, process variables driving closed-loop control. These are registers where a missed state change has operational or safety consequences.
Normal (1 to 5 seconds): Running process values such as flow rates, pressures, temperatures, and current draws. These change continuously but not instantaneously. A 2-second poll captures meaningful trends without hammering the bus.
Slow (30 seconds to 5 minutes): Accumulated counters, runtime hours, setpoints, device configuration registers. These either change by operator action only or accumulate so slowly that polling them fast is pure waste.
On-demand only: Nameplate data, firmware versions, serial numbers, calibration constants. Poll once at startup and cache. Never poll again during normal operation.

This tiered approach does something important beyond just reducing bus load: it aligns your polling architecture with the operational reality of the process you're monitoring. An engineer reading your configuration can look at the scan rates and immediately understand which signals the system treats as critical and which it treats as background. That's information that doesn't exist in a flat 1-second-everything setup.

The pushback you'll hear is that tiered polling is harder to configure and harder to document. That's true. A single scan rate is simple to explain and simple to hand off. But simple to configure and correct are different things, and a polling architecture that silently misses events or saturates a serial bus isn't simple. It's a problem that hasn't surfaced yet.

One more thing worth stating plainly: your scan rate has to account for the device's actual response capability, not just the rate you want data. Some field devices, including older PLCs, low-cost sensors, and anything running on an 8-bit microcontroller with slow UART handling, need 50 to 150ms just to process a request and formulate a response. If your fast-tier scan rate is 100ms and your device needs 120ms to respond, you're not getting 100ms data. You're getting collisions, timeouts, and a maintenance headache. Measure actual device response times before setting your fast-tier interval. The device datasheet will give you a starting point; a protocol analyzer will give you the truth.

How Timeout Misconfiguration Kills Stability

Timeouts are the most quietly destructive configuration parameter in a Modbus polling setup. Set them wrong and your system doesn't fail loudly. It just becomes unreliable in ways that are genuinely difficult to trace back to the source.

Here's what actually happens when a Modbus master sends a request: it waits. There's no explicit acknowledgment mechanism beyond the response itself, no "I got your request, give me a moment." The master sends the frame and sits in silence until either a valid response arrives or the timeout expires. What happens after that expiry, whether retry, skip, error, or log, is entirely up to whatever stack you're using. Modbus itself has no opinion.

That silence is where most setups go wrong.

The too-tight timeout problem

The instinct when configuring timeouts is to set them aggressively short. Short timeouts mean fast failure detection. Fast failure detection means the polling cycle doesn't stall when a device goes quiet. That logic is correct in theory and damaging in practice.

The issue is that "device response time" isn't a fixed number. It varies. A device that normally responds in 40ms might take 90ms when its processor is busy handling an internal alarm condition. It might take 130ms during a firmware-driven self-diagnostic that runs every few hours. It will almost certainly take longer under electrical noise conditions where the first frame gets corrupted and the device is waiting for a valid request that never arrives cleanly.

If your timeout is 100ms and your device occasionally needs 130ms, you get a spurious timeout. The master marks the request as failed and moves on to the next poll. The device, meanwhile, finishes processing and transmits a perfectly valid response — but the master has already abandoned that transaction. Those late bytes now sit in the master's receive buffer. When the next legitimate response arrives, those orphaned bytes are still there, and the master's parser reads a combined stream of garbage from both, corrupting the next response and producing another error. On RS-485 networks this compounds faster than on TCP because there's no underlying transport layer to absorb or sequence the damage. One misconfigured timeout on one device can introduce intermittent errors across the entire bus segment.

Calculating a timeout that actually makes sense

Timeout values aren't arbitrary. They have a floor set by physics and firmware, and your configured value needs to sit above that floor with enough margin to absorb real-world variation. The floor has three components:

Transmission time is how long it takes to physically clock the request frame onto the wire. At 9600 baud, each bit takes roughly 104 microseconds. A typical Modbus RTU request runs 8 bytes, which at 11 bits per byte (1 start bit, 8 data bits, 1 stop bit, plus parity) comes to roughly 88 bits, so about 9ms just to transmit at 9600 baud. At 19200 baud it halves. At 115200 baud it becomes negligible.

Device processing time is how long the device takes to receive the complete request, validate the CRC, look up the register values, and build the response. Budget 20 to 50ms for most industrial devices, 50 to 100ms for older PLCs and slower microcontrollers, and up to 150ms for devices known to have slow UART handling.

Response transmission time is the time to clock the response frame back. A read response for 10 registers runs about 25 bytes, roughly 25ms at 9600 baud.

Add those up for a 9600 baud network reading 10 registers from a moderately slow device: 8ms transmit + 75ms processing + 25ms response = 108ms minimum. A 100ms timeout fails this transaction every time. A 150ms timeout passes it usually but fails it when the device is under load. A 250ms timeout gives you real margin.

The general rule: calculate your floor, then multiply by 1.5 to 2 as a stability margin. That margin isn't wasted time. It's the difference between a system that runs cleanly for years and one that produces unexplained errors every few days. For Modbus TCP the math changes but the principle doesn't. TCP eliminates the baud rate component, but device processing time still dominates, and now you've added network latency and TCP stack overhead on both ends. A 500ms timeout is reasonable for most TCP deployments. Anything under 200ms can lead to intermittent failures depending on device response time and network conditions.

The too-loose timeout problem

The other failure mode gets less attention because it doesn't cause errors. It causes slowness, which is easier to ignore.

A timeout set at 5 seconds on a serial network means every unresponsive device costs you 5 seconds of dead time per poll cycle. If you have 3 offline devices on a 20-device bus, you're burning 15 seconds per cycle waiting for responses that will never come. This is particularly common in systems that were built to poll 20 devices and are now down to 12 because equipment was removed without anyone updating the polling configuration. The device list grows stale, the timeouts fire on phantom addresses, and the cycle time balloons silently.

Retries: the configuration that multiplies your problems

Most Modbus stacks let you configure a retry count. The default in many tools is 3. That sounds conservative. It isn't.

Three retries at a 250ms timeout means a single unresponsive device costs you 1 full second per poll cycle before the master gives up and moves on. On a fast-tier signal you're trying to poll at 500ms, one bad device makes your entire fast-tier effectively useless. The right retry count for most industrial installations is 1, sometimes 2. A single retry catches genuine transient errors. Multiple retries on a serial bus create the congestion that causes the errors you're trying to catch. Set your timeout correctly and you need fewer retries. Set your timeout too tight and no retry count will save you.

Register Batching: Do It Right or Don't Do It

Register batching is the Modbus optimization that every engineer knows about and most engineers get half right. The concept is simple: instead of sending ten separate read requests for ten individual registers, send one request that reads a contiguous block covering all ten. One transaction instead of ten. One round-trip instead of ten. The bus thanks you.

What gets left out of that explanation is the word contiguous, and that omission is where batching goes from optimization to problem.

Every Modbus transaction carries fixed overhead regardless of how many registers you're reading. On a 9600 baud RS-485 network, a single-register read transaction takes roughly 10ms in transmission time alone. Reading 50 registers one at a time: potentially 500ms or more in wire time. Reading those same 50 registers in one batched request: one transaction, maybe 30ms. The efficiency difference isn't marginal. It's an order of magnitude.

The advice to batch your reads is correct. The problem is what happens when engineers apply it without reading the register map first.

The contiguous register requirement

Modbus function code 03 reads a starting address plus a quantity, that block, sequentially, with no gaps. If you want registers 40001, 40050, and 40099, you cannot batch those in one request. You need three separate requests, or you read the entire range from 40001 to 40099 and discard the 96 registers you don't need.

That second option is where the mistake happens. Engineers conclude that reading a larger block is always better than reading a smaller one. So they batch aggressively: read registers 40001 through 40200 in one shot and parse out the handful of values they actually need.

This works fine until you hit a gap in the register map containing a reserved or unimplemented register. Modbus devices are not required to return valid data for registers that aren't defined in their implementation. Many return zero. A significant number return an exception response, Modbus error code 02 (illegal data address), which terminates the entire read request and returns nothing. Your aggressive batch that was supposed to read 50 useful values returns an exception because register 40047 isn't implemented on this firmware version, and now you have no data from any of those 50 registers until the next poll cycle.

This is one of the most common sources of intermittent data gaps in Modbus installations. The polling works fine during commissioning on a bench setup, then produces sporadic errors in the field when devices from a different firmware revision have slightly different register implementations.

How to batch correctly

Start with the device register map from the vendor documentation. Read it to understand the layout, not just to find the registers you want. Where are the gaps? Which registers are reserved? Which are only valid in certain operating modes?

Then group registers into contiguous or near-contiguous clusters where the gap between any two consecutive needed registers is small, using 10 registers or fewer as a starting heuristic. Each cluster becomes one batch request. Clusters separated by larger gaps become separate requests.

For a device where you need registers 40001–40010, 40015–40020, and 40100–40110: the first two clusters are close enough that one request covering 40001 to 40020, reading 20 registers and wasting 5, is acceptable. The third cluster at 40100 is 80 registers away. That's a separate request.

Batching and your poll rate tiers

If your fast-tier registers are scattered through the same address space as your slow-tier registers, batching them together means polling slow registers at your fast rate, which defeats the tiering entirely. Design your batches per tier. Fast-tier batch: only fast-tier registers, polled at your fast interval. Slow-tier batch: only slow-tier registers, polled at your slow interval. If registers from different tiers happen to be contiguous in the address map, resist the temptation to merge them. A slightly less efficient batch that preserves your polling architecture is better than an efficient batch that collapses your scan rate strategy.

A note on writes

Function code 16 allows batching writes the same way FC03 batches reads. But write batching carries a risk read batching doesn't: a single malformed batch can corrupt multiple independent settings simultaneously. For writes, err toward smaller, focused transactions even at the cost of bus efficiency. When you're writing to a live device controlling an active process, the reliability argument outweighs the performance argument.

Where This Leaves You

The three problems this article covers, scan rate uniformity, timeout miscalculation, and aggressive batching, share a common trait: none of them produce an immediate, obvious failure. They produce a system that works, mostly, until it doesn't. The errors they cause get blamed on hardware, on electrical noise, on the device vendor. The actual cause sits in a configuration file that nobody has looked at since commissioning.

The fix for all three is the same kind of work: deliberate, once, documented. Tier your scan rates to match how fast your data actually changes. Calculate your timeouts from the physics of your network rather than accepting defaults. Read the register map before you batch. None of this takes long. None of it requires downtime. It just requires treating these as decisions rather than defaults.

If you've made these changes and your installation is still misbehaving, the problem is in the operational layer: how your polling architecture handles the network and devices once they're running. That's what Part 2 covers: serial versus TCP failure modes, unresponsive device handling, live diagnostics, and how to fix what you find without taking production down.

Why OPC UA Is Not Replacing Modbus (Yet)

2026-03-30T00:00:00Z

Everyone in industrial automation agrees: OPC UA is the future. The specs are richer. The security is real. The semantic modeling is genuinely elegant. The industry consortia say so. The whitepapers say so. Vendors say so constantly, especially the ones selling OPC UA stacks.

Modbus is still winning.

Not in keynotes. Not in roadmaps. On the factory floor, in new device datasheets, in RFQs sent out this quarter, Modbus keeps showing up where OPC UA was supposed to have taken over by now.

In January, we wrote about why Modbus refuses to die — the installed base, the zero-cost implementation, the vendor neutrality, the brutal simplicity that makes it work at 3 AM when nothing else will. That piece hit a nerve. The responses fell into two camps: engineers who nodded along because they live this every day, and architects who pushed back insisting OPC UA adoption is accelerating.

Both camps are right. And that's exactly the problem.

OPC UA isn't losing because it's a bad protocol. It's losing ground in places it should dominate because the gap between what OPC UA can do and what most facilities need done remains wider than the standards bodies want to admit. Capability isn't the same as adoption. A Ferrari doesn't win in a parking lot.

This isn't a eulogy for OPC UA. It's a sober look at the structural reasons why a protocol with every technical advantage on paper hasn't delivered the displacement its advocates have been predicting for fifteen years, and what would actually need to change for the "yet" in that title to disappear.

The Promise vs. The Reality

OPC UA was ratified in 2008. That's eighteen years ago. The pitch was compelling: a unified, secure, semantically rich protocol that would finally bring industrial automation into the modern era. The OPC Foundation had vendor backing. The specification was thorough. The vision was clear.

Optimistic predictions followed. The expectation in many quarters was that by the mid-2010s OPC UA would be the dominant machine-level protocol, that Modbus would be a legacy concern by 2020, and that the transition would be essentially complete by the middle of this decade. Those expectations reflected genuine enthusiasm for the protocol's capabilities, not sourced forecasts — but they shaped investment decisions and roadmaps across the industry nonetheless.

None of that happened.

The Modbus TCP market was valued at $1.35 billion in 2024 and is projected to reach $2.55 billion by 2032. That isn't legacy drag. That's active investment. New Modbus devices are being designed, manufactured, purchased, and installed in 2026, not as fallback options, but as deliberate first choices. Meanwhile, OPC UA adoption, while genuinely growing, remains concentrated in specific layers of the automation stack: SCADA systems, MES integrations, and IT/OT gateways. At the field device level, Modbus still dominates.

The gap between expectation and reality isn't a failure of OPC UA's design. The protocol does what it promises. The gap exists because adoption in industrial automation doesn't follow software industry timelines. A protocol doesn't win by being technically superior. It wins by becoming the path of least resistance across every layer of the ecosystem simultaneously: device manufacturers, integrators, maintenance teams, procurement departments, and plant managers all have to move together. That has never happened with OPC UA, and understanding why requires looking at each layer honestly.

The Complexity Tax Nobody Talks About

OPC UA's biggest competitor isn't Modbus. It's its own specification.

The full OPC UA specification runs across fourteen separate documents. A developer picking up Modbus for the first time can read the entire protocol specification over a weekend and ship a working implementation by Monday. A developer picking up OPC UA faces months of study before they can confidently build something production-ready.

This isn't an unfair criticism. It's the honest cost of doing more. Modbus reads and writes registers. OPC UA models information, manages sessions, handles subscriptions, enforces security policies, and describes data with rich metadata. That capability has a price, paid in implementation time, developer hours, and operational complexity.

For device manufacturers, the math is punishing. A Modbus RTU interface costs roughly $5 to $10 in silicon and a few days of firmware work. A proper OPC UA server, implemented correctly with certificate management, secure channels, and a meaningful information model, requires a capable processor, sufficient memory, and weeks of engineering time. For a sensor company shipping into a price-sensitive market, that difference doesn't show up as a line item in the spec sheet. It shows up in whether the product gets built at all.

Certificate management alone has quietly killed more OPC UA deployments than any technical limitation. Certificates expire. They need to be provisioned, rotated, and trusted across every client and server. In an IT environment with dedicated security teams, this is manageable. In a plant where the automation engineer also handles PLC programming, HMI design, and network troubleshooting, it becomes an ongoing burden that nobody budgeted for and nobody wants to own.

The OPC Foundation recognized this. Companion specifications like OPC UA FX and the Field Level Communications initiative are genuine attempts to bring the protocol closer to the field device layer. Progress is real but slow, and in the meantime, device manufacturers continue defaulting to Modbus because it ships today without a compliance checklist.

Complexity isn't a dealbreaker when the problem demands it. Nobody complains that OPC UA is too complex when it's modeling an entire production line in a SCADA system. The complexity tax only becomes fatal when the problem is simple and a simpler tool is sitting right there, already understood by the team, already working.

The Skills Gap on the Floor

Protocols don't run themselves. People configure them, troubleshoot them, and fix them at 2 AM when production is down. And the people doing that work in most manufacturing facilities today learned Modbus, not OPC UA.

This isn't a generational complaint. It's a workforce reality with direct operational consequences. The automation technician who has spent fifteen years on a plant floor can read a Modbus register map the way a mechanic reads an engine. They know register 40023 on device 12 is the motor temperature. They know what value triggers an alarm. They know how to pull up a protocol analyzer and spot the problem in minutes.

Ask that same technician to troubleshoot an OPC UA subscription that stopped delivering updates and the confidence evaporates. Is it a certificate issue? A session timeout? A misconfigured sampling interval? A namespace problem? The diagnostic path is longer, the tooling is more complex, and the required knowledge base is fundamentally different. The problem gets escalated, production stays down longer, and the experience gets filed away as evidence that OPC UA is unreliable. The protocol isn't unreliable. The skills to operate it confidently just aren't evenly distributed yet.

Training helps but doesn't solve the structural problem. OPC UA expertise is concentrated in system integrators and automation vendors, not in the maintenance teams who keep plants running day to day. Facilities that have gone deep on OPC UA often find themselves dependent on a small number of people who truly understand the stack, creating exactly the kind of single point of failure that conservative plant managers spend their careers avoiding.

The skills gap will close eventually. Engineering curricula are adding industrial networking content. Younger engineers are entering the field with broader protocol exposure. But eventually in industrial automation means a decade, not a release cycle. The plants being designed today will be maintained by the workforce that exists today, and that workforce is fluent in Modbus in a way it simply isn't in OPC UA yet.

The Hardware Reality

Modbus RTU was designed in 1979 for the hardware constraints of 1979 — worth noting that Modbus TCP, the networked variant that dominates modern installations, didn't arrive until 1999. But the original serial protocol's frugality is what set the expectation, and the ecosystem never abandoned it.

A bare-minimum Modbus RTU slave implementation can run on an 8-bit microcontroller with around 10KB of flash and 1.5KB of RAM. A robust, production-grade implementation with full error handling and edge-case coverage needs more — typically several times that — but the floor is still extremely low compared to almost any alternative. Device manufacturers building sensors, meters, drives, and actuators work within tight BOM constraints where every dollar multiplies across thousands of units. Modbus fits inside the microcontroller they were already using. It adds no hardware cost and minimal firmware complexity.

OPC UA has a different story. A properly implemented OPC UA server needs a real processor capable of running a TCP/IP stack, handling cryptographic operations, and managing runtime memory requirements. Lightweight stacks like open62541 have brought the floor down meaningfully — a constrained OPC UA server can run in under 100KB of flash with careful implementation — but that still represents a significant step up from a Modbus RTU slave, and a full-featured server with a rich information model typically requires several hundred kilobytes of RAM or more.

The OPC Foundation's work on OPC UA FX targets exactly this problem, aiming to bring the protocol down to devices with 256KB of flash and 64KB of RAM. That's genuine progress. It's also still an order of magnitude more resource-intensive than a minimal Modbus implementation on equivalent hardware, and FX-capable devices are only beginning to reach the market.

For established device categories the cost difference compounds quickly. A manufacturer selling thousands of flow meters into water treatment, oil and gas, and chemical processing isn't just buying components. They're buying tooling, certifications, and support infrastructure built around specific hardware platforms. Changing the processor family to support OPC UA means requalifying the entire product, retesting for environmental and EMC compliance, and retraining field service teams. The protocol upgrade triggers a full product redesign, and the business case rarely pencils out when the existing Modbus version is selling reliably into a market that hasn't asked for OPC UA.

Until OPC UA can run comfortably on the same class of hardware Modbus runs on today, at comparable cost and without requiring a platform redesign, the field device market will continue defaulting to Modbus. Not because engineers prefer old technology, but because the economics of building physical hardware into conservative industrial markets leave very little room for protocol idealism.

Where OPC UA Actually Wins

This isn't a one-sided argument. OPC UA dominates in specific contexts and deserves the credit it gets there. Conflating the two is how bad architecture decisions get made in both directions.

At the SCADA and MES layer, OPC UA is the right answer. When you need to aggregate data from hundreds of heterogeneous devices and feed it into manufacturing execution systems, historian databases, and enterprise analytics platforms, Modbus gives you registers with no context. OPC UA gives you structured, self-describing data with units, ranges, relationships, and meaning baked in. At scale, that semantic layer saves thousands of engineering hours.

Security requirements close the conversation quickly. The moment a system needs to be accessible from outside the plant network, Modbus is disqualified. Not because it can't be hardened with compensating controls, but because its security model is nonexistent by design. OPC UA with TLS encryption, certificate-based authentication, and role-based access control provides the foundation connected industrial systems actually need.

Large equipment builders and machine OEMs increasingly ship with OPC UA as the primary integration interface, for good reason. A packaging line, CNC machining center, or industrial robot is a complex asset with hundreds of meaningful data points. OPC UA companion specifications from industry groups like OMAC, EUROMAP, and the VDMA define standardized information models for entire equipment categories. A machine built to the PackML OPC UA companion spec integrates with any PackML-aware SCADA system without custom mapping work. That interoperability has real commercial value.

Greenfield installations with modern hardware and no legacy constraints are where arguments for Modbus at the field level are weakest. When the BOM can absorb the hardware cost and the team has OPC UA skills, there is no compelling reason to default to a register-based polling protocol from 1979.

The pattern is consistent. OPC UA wins where complexity is justified by the problem, where security is non-negotiable, and where people and hardware resources exist to implement it properly. Those conditions describe the upper layers of the automation stack and modern greenfield projects. They do not yet describe the majority of the field device layer, and that distinction is exactly why the "yet" still belongs in this article's title.

The Gateway Middle Ground

The industry didn't wait for OPC UA to win. It built a workaround and quietly made it the standard architecture.

Edge gateways now sit at the boundary between the field device layer and everything above it, speaking Modbus to the equipment that has always spoken Modbus and presenting OPC UA, MQTT, or REST to the systems that need structured, secure data. It isn't a temporary fix pending full OPC UA adoption. For most facilities, it is the architecture, and it works well enough that the pressure to replace Modbus at the source has largely evaporated.

This reflects how industrial modernization actually happens. Plants don't replace working equipment to adopt better protocols. They add intelligence at the edge and leave the field devices alone. A Modbus temperature transmitter installed in 2008 keeps transmitting exactly as it always has. The gateway reads its registers, maps the raw value to a properly typed OPC UA node with engineering units and metadata attached, and publishes it upstream. The transmitter never knows the difference. The SCADA system gets clean, contextualized data. Nobody touched the wiring.

The business case is straightforward. Replacing field devices across a large facility to gain native OPC UA at the source costs millions of dollars, requires production downtime, and delivers no improvement in the process being controlled. Adding an edge gateway costs thousands, takes days to deploy, and delivers the same data quality improvement. The ROI calculation ends quickly.

FlowFuse is built around exactly this architecture. Node-RED flows running on the edge read Modbus registers from legacy field devices, apply context and normalization, and publish structured data over MQTT or OPC UA to cloud systems, historians, and analytics platforms. The Modbus equipment keeps running. The modern data infrastructure gets what it needs. The migration happens at the connectivity layer rather than the device layer, which is the only migration path that makes economic sense for most operational facilities.

The gateway middle ground isn't a compromise born of failure. It's a pragmatic recognition that the automation stack has always been heterogeneous and always will be. New protocols don't replace old ones in industrial environments. They get added on top, and the translation layer between them becomes the most important piece of architecture in the building.

What Would Actually Accelerate OPC UA Adoption

Diagnosing why OPC UA hasn't replaced Modbus is useful. Identifying what would actually change the trajectory is more useful. Not wishlist thinking, but a realistic assessment of the specific friction points that, if addressed, would move the needle in ways that eighteen years of industry advocacy has not.

The most immediate lever is simplification at the implementation level. Device manufacturers make platform decisions years before products ship. Every year that lightweight OPC UA profiles remain incomplete or poorly supported by silicon vendors is another product generation that defaults to Modbus. Finalizing FX profiles, getting them supported in major embedded toolchains, and making reference implementations genuinely production-ready would lower the barrier in ways that specification documents alone cannot.

Certificate management needs to be solved, not documented. The current approach requires automation engineers to operate like IT security professionals in environments where that expertise simply does not exist. Automated certificate lifecycle management, built into OPC UA servers and clients by default, would remove one of the most common reasons deployments stall or fail after going live. Several vendors are working on this. It needs to become a baseline expectation, not a premium feature.

Open source needs to catch up. Modbus has dozens of mature, well-documented stacks across every embedded platform imaginable. OPC UA open source options have improved — open62541 in particular has become a credible foundation — but the ecosystem remains thinner and less consistent in quality and maintenance overall. A developer evaluating both protocols reaches for the option with better community support and lower risk of hitting an undocumented edge case six months before launch. Closing that gap requires sustained investment from the OPC Foundation, major vendors, and the broader industrial open source community.

Interoperability between vendor implementations remains more aspirational than actual. Passing certification does not guarantee seamless interoperability across every feature combination two products might use together. Tightening conformance requirements and expanding interoperability testing infrastructure would give integrators the confidence that OPC UA devices from different manufacturers actually work together reliably, the way Modbus devices have for forty years.

Finally, the total cost of ownership narrative needs to be addressed honestly. OPC UA advocates often present the protocol's benefits without fully accounting for implementation costs, support burden, and skills investment. Facilities that have been oversold and then struggled become skeptics who push back on the next modernization proposal. Engineers trust data and specifics. Give them that.

None of these changes are impossible. Some are already in progress. But progress in industrial standards moves at the pace of the least motivated stakeholder, and the least motivated stakeholders are the ones who have something that works today.

Conclusion: The "Yet" Has a Deadline — But Nobody Knows It

OPC UA will win. That part isn't in dispute.

The semantic modeling is too useful to ignore forever. The security requirements of connected industrial systems are too real to patch around indefinitely. The demand for self-describing, context-rich data will only grow as analytics, AI, and remote operations become standard expectations. The protocol that delivers all of that is OPC UA, not Modbus.

But winning eventually and winning now are two entirely different things. Fieldbus was supposed to replace 4-20mA. It did, mostly, over thirty years. Industrial Ethernet was supposed to eliminate serial communication. Serial communication is still everywhere. Better technology wins in industrial automation on a timeline set by depreciation schedules, workforce transitions, and the risk tolerance of people whose primary job is keeping production running. Those timelines are measured in decades and they do not compress because a standards body publishes a roadmap.

The "yet" in this article's title has a deadline. The honest answer, based on everything the industry has demonstrated about how protocol transitions actually unfold, is that it is further away than the whitepapers suggest and closer than the Modbus installed base makes it feel.

Plan accordingly. Build the gateway layer. Invest in OPC UA skills before you need them urgently. Specify OPC UA where the problem justifies it today. And stop expecting the field device layer to look like the SCADA layer anytime soon.

Modbus will be there when you get back.

How to Parse Binary Data from Serial Devices

2026-03-27T00:00:00Z

Your device is sending bytes. You don't know what they mean. The device manual is a 40-page PDF from 2003, and page 12 has a table of numbers with no explanation of what to do with them.

This is the situation most engineers hit when they connect a legacy serial device for the first time. The serial connection works. The bytes arrive. But nothing tells you what those bytes represent, and there is no standard to fall back on the way there is with Modbus.

This article gives you a repeatable method for decoding binary output from any serial device. We'll use an industrial weighing scale as the example. By the end, you'll know exactly how to approach your own device, regardless of what it sends.

The Method

Every binary parsing problem follows the same four steps.

Read the manual. Find the communication protocol section, not the installation guide. You are looking for the frame structure, the byte order, and the data types for each field. If the manual calls it a "data format" or "output format" section, that is the one. Everything else depends on this.

Identify the frame type. Frames from serial devices arrive in one of three structures. Fixed length frames are the simplest — every message is always the same number of bytes. Delimiter terminated frames end with a specific byte or sequence. Length prefixed frames include a byte early in the message that tells you how many bytes follow. Knowing which type your device uses determines how you validate and reassemble frames before parsing.

Validate before you parse. Every frame should pass a basic sanity check before your parsing logic runs. At minimum, verify the frame length and any start or end markers your device includes. If your device provides a checksum, verify that too. A frame that fails validation gets dropped. A corrupted value that passes through and ends up on a dashboard or in a database is far more damaging.

Map the bytes. Once a frame passes validation, assign every byte a meaning based on the manual. Name, type, offset, endianness, scale. This is where FlowFuse's Buffer Parser node does its work, visually, without code, with every field visible at a glance.

The rest of this article walks through all four steps using a concrete example.

The Example: Industrial Weighing Scale

We'll use a common industrial weighing scale that outputs data over RS-232. You'll find this type of device in packaging lines, logistics warehouses, and food processing plants. It has no Modbus support. It sends its own fixed binary frame every time a stable reading is available.

The manual specifies a fixed-length frame of exactly 10 bytes:

Byte	Value	Description
0	`0x02`	STX, start of frame
1–4	32-bit float	Weight value, little-endian
5	`0x01` or `0x02`	Unit indicator, 1 = kg, 2 = lb
6	Bitfield	Status flags
7	—	Reserved
8	Byte	Checksum, sum of bytes 1–7 truncated to one byte
9	`0x03`	ETX, end of frame

Byte 0 is always 0x02. Byte 9 is always 0x03. These are your frame markers. Bytes 1 through 4 carry the weight as a 32-bit IEEE 754 float in little-endian order, meaning the least significant byte comes first. Byte 5 tells you whether the scale is set to kilograms or pounds. Byte 6 is a status bitfield where individual bits carry meaning — bit 0 is stable, bit 1 is overload, bit 2 is zero.

This is the raw buffer the scale sends for a 23.5 kg stable reading:

<Buffer 02 00 00 bb 41 01 03 00 5f 03>

By the end of this article, that buffer becomes:

{
  "weight": 23.5,
  "unit": "kg",
  "stable": true,
  "overload": false,
  "zero": false
}

Building the Flow in FlowFuse

We'll simulate the device output using an Inject node so you can follow along without hardware. In a real deployment, the Inject node is replaced by a Serial In node receiving bytes directly from the device. The parsing logic, the validation, the Buffer Parser configuration — all of it stays identical. The only difference is where the bytes come from. If you want to set up the actual serial connection, this article covers that.

The flow is: Inject node connected to a Function node connected to a Buffer Parser node connected to a Switch node, each output of the Switch connected to its own Change node, both Change nodes connected to a Debug node.

Step 1: Install the Buffer Parser Node

The Buffer Parser node is not included in Node-RED by default. To install it:

Open your Node-RED editor
Click the hamburger menu (top right)
Go to Manage palette → Install tab
Search for node-red-contrib-buffer-parser
Click Install

Once installed, the node will appear in your palette and you can proceed with building the flow. If you're on FlowFuse, your administrator may have already added it to your shared palette — check before installing.

Step 2: Simulate the Device

Drag an Inject node onto the canvas and double-click it
Set msg.payload type to Buffer from the dropdown
Enter: [2,0,0,188,65,1,3,0,1,3]
Click Done

Every time you click the Inject button, the flow receives these 10 bytes exactly as it would from a live serial connection.

Step 3: Validate the Frame

Add a Function node and paste in the following. This is the only JavaScript in the entire flow.

const buf = msg.payload;

// Check frame length
if (buf.length !== 10) {
    return null;
}

// Check start and end markers
if (buf[0] !== 0x02 || buf[9] !== 0x03) {
    return null;
}

// Validate checksum
let sum = 0;
for (let i = 1; i <= 7; i++) {
    sum += buf[i];
}
if ((sum & 0xFF) !== buf[8]) {
    return null;
}

return msg;

Three checks: frame length, start and end markers, checksum. If any fail, the message is dropped. Only clean, verified frames reach the Buffer Parser.

Step 4: Parse the Bytes

Add a Buffer Parser node and double-click it. Set Output to key/value. Then add one row for each field.

Weight

Name: weight
Type: floatle (32-bit IEEE 754 float, little-endian)
Offset: 1
Length: 1

Unit

Name: unit
Type: uint8
Offset: 5
Length: 1

Status flag — stable

Name: stable
Type: bool
Offset: 6
Bit Offset: 0

Status flag — overload

Name: overload
Type: bool
Offset: 6
Bit Offset: 1

Status flag — zero

Name: zero
Type: bool
Offset: 6
Bit Offset: 2

Configuring the Buffer Parser node to extract weight, unit, and status flags from the 10-byte frame

The float conversion, the byte reading, the individual bit extraction — all handled visually without code. The bool type with Bit Offset is what makes bitfield parsing possible here. Each status flag is packed into a single byte, and the Buffer Parser pulls them out one bit at a time. If you want a deeper walkthrough of every Buffer Parser field and configuration option, this article covers it in full.

Step 5: Map the Unit Value

The Buffer Parser gives you 1 or 2 for the unit byte. A Switch node routes the message based on that value, and a Change node on each route sets the correct label.

Configure the Switch node:

Property: msg.payload.unit
Rule 1: equals 1 → output 1
Rule 2: equals 2 → output 2

Connect each output to its own Change node:

Output 1 Change node: set msg.payload.unit to the string "kg"
Output 2 Change node: set msg.payload.unit to the string "lb"

Connect both Change nodes to the Debug node. Click Deploy, then click the Inject button. Your debug panel will show:

{
  "weight": 23.5,
  "unit": "kg",
  "stable": true,
  "overload": true,
  "zero": false
}

When Things Get Harder

The weighing scale had a clean, fixed-length frame. Not every device will.

Frames Arriving Split Across Multiple Messages

Depending on baud rate and buffer size, a single frame can arrive as two or more separate messages. If you try to parse a partial frame, you get garbage. The fix is a reassembly Function node placed before the validation step, using node context to accumulate bytes until a full frame is available:

let buffer = context.get("buffer") || Buffer.alloc(0);
buffer = Buffer.concat([buffer, msg.payload]);

if (buffer.length < 10) {
    context.set("buffer", buffer);
    return null;
}

msg.payload = buffer.slice(0, 10);
context.set("buffer", buffer.slice(10));

return msg;

For delimiter-terminated frames, replace the length check with a search for your end byte. For length-prefixed frames, read the length byte first and use that as your target size.

When Buffer Parser Is Not Enough

Buffer Parser handles fixed-structure protocols well. Two situations require a Function node instead.

The first is conditional structure — where the layout of later bytes depends on the value of an earlier byte. Buffer Parser parses a fixed specification every time. If your frame changes shape based on its own content, you need code.

The second is complex computed fields. If your device sends a raw ADC value that requires a multi-step calibration formula, Buffer Parser's scale field won't cover it. Add a Function node after Buffer Parser to handle only that calculation.

In both cases: let Buffer Parser do what it can, and add a Function node only for the parts it cannot.

If you're on FlowFuse, you don't need to write that JavaScript yourself. Describe what you need to the FlowFuse Expert in plain English and paste the relevant section of your device manual. It will generate the Function node directly on your canvas.

Example prompt you can use:
I have a serial device sending binary data with this frame structure:
- Byte 0: 0x02 (start)
- Byte 1: message type
- Bytes 2–5: 32-bit float (little-endian)
- Byte 6: status bitfield
- Last byte: checksum (sum of bytes)

The frame structure changes based on the message type.

Generate a Node-RED Function node that:
1. Validates the frame (start, length, checksum)
2. Parses fields based on message type
3. Extracts bitfield values into booleans
Paste your device manual section along with the prompt for best results.

Applying This to Your Own Device

The weighing scale is one device. To show the method transfers, here is how it applies to a completely different device — an industrial barcode scanner.

The scanner sends a variable-length frame every time it reads a label. The manual specifies a delimiter-terminated structure ending with 0x0D (carriage return). Here is the frame layout:

Byte	Value	Description
0	`0x02`	STX, start of frame
1	uint8	Scanner ID
2–N	ASCII bytes	Barcode data, variable length
N+1	`0x0D`	CR, end of frame

The device and the frame look nothing like the weighing scale. The method is identical.

Read the manual. Frame structure: delimiter terminated, ends with 0x0D. Data types: ASCII bytes for the barcode value, uint8 for the scanner ID.

Identify the frame type. Delimiter terminated. Your reassembly logic searches for 0x0D instead of checking a fixed length.

Validate before you parse. Check for the STX start byte at position 0 and the 0x0D end byte at the last position. No checksum on this device, so those two markers are your full validation.

Map the bytes. In the Buffer Parser, one row for the scanner ID at offset 1 as uint8. The barcode data is ASCII from offset 2 to the end of the frame, which you read as a string type with the appropriate length.

Four steps. Different device, different frame structure, same process. The Buffer Parser configuration looks different because the bytes are different. The thinking behind it is the same.

This is what the method gives you. Not a recipe for one specific device, but a way of reading any device manual and turning what you find there into a working flow.

If you are managing flows across multiple edge devices, FlowFuse deploys the same configuration everywhere through its remote deployment pipeline, with snapshots to roll back if anything changes on the device side.

Final Thoughts

Modbus made binary parsing approachable because someone defined the rules in advance. Raw serial devices hand you a PDF instead. That is the real difficulty, not the parsing itself.

The method in this article works for weighing scales, barcode scanners, RFID readers, CNC machines, and whatever proprietary hardware is sitting on your factory floor with no documentation beyond a table of hex values. Once you have applied it once, you will recognize the pattern in every device you connect after it.

The factories with the most valuable operational data are often the ones running the oldest hardware. That data is accessible. It just requires knowing how to read it.

Rethinking Edge AI's Core Orchestration

2026-03-27T00:00:00Z

Every week, another vendor promises "AI on the edge" with glossy demos and yet another dashboard. With FlowFuse customers though, in real factories, the hard part is not the model; it is getting trustworthy, contextual data from all machines to the right AI, at the right time.The real competitive advantage will not come from who has the flashiest model, but from who owns the most reliable connecting tissue between hardware, IT systems, AI agents, and the cloud. This tissue empowers better model accuracy and creates an operational advantage for our customers.

Why AI Deployments Fail When You Forget About Connectivity

Manufacturers that have already modernized their SCADA or rolled out cloud data lakes, lake houses, and other lake-based properties, are often surprised by how fragile their "AI initiative" becomes once it touches the factory floor. It is no secret that data is trapped in proprietary PLCs and vendor‑locked SCADA systems, with IT and OT speaking different languages or protocols, and every site maintaining its own patchwork of scripts, gateways, and one‑off integrations. So what happens? You end up with predictable problems: fragile, one-off connections, IT changes that take half a year, OT changes that have impact on data semantics but go unnoticed and AI projects that look great on paper but never actually run in the real world at scale. The fundamental issue lies in the deep divide between Information Technology (IT) and Operational Technology (OT). Shop floor teams are often left in the dark about how their data is leveraged by upstream systems, while IT teams struggle to grasp the operational significance underlying the tags and signals they process. This unbridged gap ensures that every AI initiative remains an expensive, custom-built, and inherently brittle undertaking.

The new stack: AI‑driven edge connectivity

A different architecture is emerging: a unified, future-proof connectivity layer that sits between machines, plant networks, enterprise systems, and AI services. This layer becomes the common ground where IT and OT share a unified model of metrics from assets, other events, and decisions made, ensuring that neither side operates in a vacuum. And I have to say that I’m proud of stating that FlowFuse is at the forefront of this innovation. In this new paradigm we’re facing, edge devices run a consistent runtime, such as open-source Node‑RED, so that connectivity, transformation, and control logic look the same on every line, every site, and every device family. AI is then wired directly into this connective tissue via emerging AI standards like Model Context Protocol (MCP) and other native AI nodes, turning the connectivity fabric into a living "nerve system" where agents can safely read, reason, and act on live operational data.

OK but… what "Future-Proof" means at the edge?

Getting AI, especially large language models (LLMs), to work with the edge isn't just about sticking them onto your existing middleware. It means that AI is embedded into how connectivity is designed, deployed, and operated: models and agents that turn natural‑language descriptions into flows, blueprints that spin up AI chat agents over plant data, and smart suggestions that propose the next node or transformation in context. The main thing is, it also means that AI agents can run close to the process, on a gateway or industrial PC, using ONNX models for things like spotting defective parts produced, and predicting maintenance and downtime, while the cloud handles the rules, oversight, and updates for the whole fleet. That split (smart procedures happening at the edge, and the cloud just keeping things organized) is precisely what makes the IT and OT worlds finally click. OT gets to be fast and independent, and IT still has the main view and control over the whole shebang.

We can finally say goodbye to the IT/OT gap.

FlowFuse was built on a simple belief: industrial teams need one platform that can connect any machine, move data across any protocol, model it in any data platform, and run applications wherever they create the most value. Both IT and OT get the tools they need, from a wide connectivity suite, to Git integration, and a platform to scale it to hundreds or thousands of different devices.It hooks up to things like PLCs, sensors, and existing Operational Technology (OT) gear using standard protocols like Modbus, OPC UA, and MQTT. This lets you securely stream data to the cloud or your own premises without messing around with complicated firewalls or VPNs. You name it, FlowFuse will connect everything. At the enterprise level, FlowFuse Cloud provides the central "control tower" to standardize blueprints, ensure version consistency, enforce security policies, and roll out changes across hundreds or thousands of devices with a single action.

On top of this connectivity fabric, FlowFuse Expert acts as the AI assistant tuned for industrial teams that will make your life easier as you never imagined. Grounded via MCP in your actual machines, brokers, and databases, it does much more than chat: it generates live Node‑RED flows, data mappings, dashboards, and even queries that are directly deployable into your environment. Because it connects to both OT sources (PLCs, industrial brokers, historians) and IT systems (data lakes, CMDBs, corporate apps), Expert sees, understands and manages both halves of the map. 100% control of both IT and OT. It translates plant-floor requirements into IT-compliant flows and ensures that security and governance policies are automatically applied to edge configurations. It acts as the structural bridge that finally closes the IT/OT gap. For OT engineers, this means months‑long projects compress into days or minutes; for IT, it means governance and security controls stay intact even as more of the work shifts closer to the plant floor.

IT/OT Gap Diagram

From pilots to a scalable "AI nerve system"

Here’s the thing - Most companies will not win by building the most sophisticated individual model, but by institutionalizing a repeatable pattern: connect, contextualize, and act on data at the edge, with AI embedded at every step. If you’ve followed FlowFuse’s history you’ve probably seen how our tagline and our storytelling has been evolving following that logic. “Connect, Collect, Build and Scale with FlowFuse” - This is what this is about. FlowFuse gives manufacturers that pattern in a form they can actually operate: open‑source at the core with Node‑RED, industrial‑grade features for deployment and observability, and a layer of proprietary Artificial Intelligence that actually understands the realities of plant networks, not just cloud APIs. The result is a new kind of infrastructure: a persistent "AI nerve system" that spans hardware, IT, AI, and cloud, so that when the next model, vendor, or use case arrives, your connectivity is already in place, deployed and ready to scale. This structural bridge ensures that the historical friction between IT and OT becomes a foundation for collaboration. If the last decade was about moving workloads to the cloud, the next decade in manufacturing will be about bringing intelligence to the edge. And how this must be done? Safely, consistently, and fast enough to matter. The companies that treat AI‑driven edge connectivity as a strategic foundation, not a side project, will be the ones that turn experiments into durable competitive advantage.

5 Places Smart Factories Are Already Using AI

2026-03-24T00:00:00Z

The factory floor wasn't exactly an early adopter of artificial intelligence.

It's a world built around physical processes: tolerances, throughput, shift schedules. The automation that arrived decades ago was powerful but rigid. Machines that did exactly what you programmed them to do, nothing more.

That's changed.

AI is now embedded in manufacturing operations in ways that are easy to miss. Not in the headline-grabbing robots, but in the systems quietly running underneath: predicting failures, catching defects, optimizing energy loads, and compressing deployment timelines.

The question isn't whether AI has reached the factory floor. It has. The question is where it's actually doing useful work.

Here are five answers.

Predictive Maintenance on CNC Machines

Manufacturers lose $50 billion a year to unplanned downtime. Here's what that actually looks like: a CNC machine goes down at 2am, the part isn't in stock, the order misses its window, and the schedule takes three days to recover.

The problem was never detection. Factories have had sensors for decades. It was interpretation. A temperature spike means nothing without knowing what's normal for that machine, on that material, at that feed rate. Threshold-based alarms can't know that. A model trained on months of operational data from that specific machine can.

Predictive maintenance learns the baseline and watches for drift. Bearing wear shows up as a frequency shift in vibration data. Spindle imbalance leaves a signature in motor current. None of these are visible on the floor, but all of them are readable in the data, 24 to 72 hours before failure.

Harley-Davidson has been running vibration-based predictive maintenance on plant equipment for longer than most manufacturers realize. But you don't need that scale. We built an AI vibration anomaly detector for industrial motors using an autoencoder trained on healthy vibration data, running inference directly in Node-RED. The model learns what normal looks like. When that changes, you get a warning with time to act.

That's the shift. Not better alarms, but a system that knows the difference between a machine running hard and a machine running out of time.

Visual Quality Inspection

Manual inspection has a hard ceiling. Put someone at a line running 200 units a minute for four hours and their defect detection rate drops. That's not a training problem. It's physiology.

Computer vision doesn't have that ceiling. A camera at the inspection station sees every unit, not a sample, at full line speed, catching surface defects, dimensional drift, solder bridges, and weld inconsistencies. In semiconductor fabrication, where a particle smaller than a human hair destroys yield, vision-based inspection isn't an upgrade. It's the only option that makes sense at volume.

BMW's AIQX platform runs camera and sensor-based AI quality checks across every plant globally. At Spartanburg, it monitors roughly half a million weld studs daily. At Regensburg, the GenAI4Q system generates a custom inspection checklist for each of 1,400 vehicles built daily, adapting to every model variant in real time.

There's a compounding effect worth noting: every defect caught becomes labeled training data. The model improves continuously. The longer it runs, the harder it is to beat.

Human inspectors still matter for root cause and edge cases. But the first pass, the one that runs on every unit at line speed, is not a job for human eyes anymore.

Shorter Path from Pilot to Production

Manufacturers consistently underestimate integration time. The technology decisions get made, the use case is clear, and then the project stalls for months. The pilot ran on clean exported data. Production means live data from PLCs running proprietary protocols, historians not designed for real-time access, and network segments that exist for good reasons. Most IIoT initiatives don't fail at the algorithm layer. They fail at the plumbing.

That gap is expensive. A deployment that takes six months to reach production has a very different ROI profile than one that takes six weeks. And it's precisely here that AI is changing the economics of development. Engineers are generating integration flows from plain language descriptions, tracing protocol mismatches that would have previously burned days, and producing documentation as they build rather than long after. The unglamorous middle work moves faster.

FlowFuse Expert is built for exactly this. AI assistance embedded directly in the Node-RED editor: inline code completions as you write, next-node predictions as you build, and a chat interface that understands your actual flows and live debug output. Describe the logic you need and it writes the function node. Something behaving unexpectedly? Load your flow and debug logs as context and work through it together. Fewer hours lost to problems that have already been solved a hundred times before.

Energy and HVAC Optimization

Most smart factory conversations never get to the building itself. That's a mistake.

HVAC is one of the largest energy costs in a manufacturing facility and one of the least optimized. A factory's thermal load shifts constantly: which lines are running, what materials are being processed, outdoor temperature, occupancy. Rule-based systems deal with that complexity by setting conservative margins everywhere and leaving them there. It works, but you pay for it on every energy bill.

AI learns the actual behavior of the facility and stops defending against conditions that aren't happening. Yokogawa deployed reinforcement learning for HVAC in its semiconductor plant in Japan. In that facility, cleanroom HVAC accounted for roughly 30 percent of total energy consumption — a figure consistent with, though on the lower end of, what's reported across the semiconductor industry. The result was a 3.6 percent reduction in total consumption. Modest on paper, significant at scale, and it improves as the model keeps learning.

DeepMind's data center work gets more attention, but that's a controlled, single-purpose environment. A factory is harder. Yokogawa is the more relevant proof of concept.

Worker Safety and Ergonomics Monitoring

Musculoskeletal disorders are the most common workplace injury in manufacturing. A bad lift, an awkward reach, a sustained bent posture on a repetitive task: the injury doesn't happen dramatically. It accumulates over weeks, then shows up as a compensation claim and a gap on the line.

Traditional ergonomics assessment catches this late. A consultant observes a workstation, writes a report, and by the time recommendations are implemented, workers have been loading their joints wrong for months.

Pose-estimation AI runs overhead cameras continuously and scores every movement in real time against established ergonomic risk frameworks, flagging a bend angle that will cause a back injury long before it materializes. In one manufacturing pilot study, researchers reported roughly a 25 percent reduction in workplace injuries, with posture compliance improving once workers received real-time feedback. Results will vary by facility, workstation type, and baseline injury rates.

The privacy question deserves a direct answer: these systems track skeletal keypoints, not faces or identities. What gets logged is joint angle data, not footage of individuals.

What makes this different from a safety poster is that it doesn't rely on the worker remembering. The system watches every repetition, on every shift.

Where to Start

The five use cases covered here aren't experiments. They're running in production facilities today, on real lines, delivering measurable results. The gap between manufacturers who've deployed AI and those still evaluating it is growing, and it compounds.

But starting doesn't require a complete digital transformation. Pick one problem that's costing you money right now: unplanned downtime on a critical machine, a defect rate you can't get below, an energy bill that doesn't reflect how efficiently you actually run. That's your first use case.

The common thread across all five use cases is the same bottleneck: getting operational data to a model reliably and acting on what it returns. That's the integration problem most deployments stall on. FlowFuse is built around solving exactly that. You connect to your PLCs, deploy your AI model, and trigger actions all within the same flow, which is why it's where most manufacturers start and where they keep building.

The manufacturers seeing results didn't wait for the perfect conditions. They started with one line, proved the value, and expanded. That's still the fastest route from where you are to where you want to be.

FlowFuse Enterprise: More Power, More Confidence

2026-03-23T00:00:00Z

Manufacturing teams using FlowFuse are running industrial applications at scale — across plants, teams, and environments. As that scale grows, so do the expectations: faster deployments, tighter security, smarter tooling.

Today we're announcing updates to our Enterprise tier that reflect where our customers are headed and the kind of platform they need to get there.

FlowFuse Enterprise now includes Certified Nodes and AI Insights.

What's new in Enterprise

Certified Nodes

One of the most consistent questions we hear from IT and security teams evaluating FlowFuse is: "Is FlowFuse secure and compliant enough for production?"

Certified Nodes are our answer. Every node in the catalogue has been security-scanned, battle-tested, and comes with a clear support owner, along with enterprise level response times. That means your team gets the flexibility of the Node-RED ecosystem with the accountability that enterprise production environments demand.

This isn't just a compliance checkbox. It's the foundation for trusting your infrastructure with the dependencies — and for IT and Operations to standardize on FlowFuse with confidence across sites.

AI Insights

Building and iterating on flows takes time — time your team doesn't always have. AI Insights brings AI-assisted solution building directly into FlowFuse, reducing the effort required to go from idea to production.

Whether you're onboarding a new site, adapting an existing flow, or troubleshooting a process, AI Insights helps your team do more with less — and get to value faster.

Our goal is simple: the first week of value should come faster than ever before.

Built around three things that matter at scale

These additions aren't standalone features — they reflect a deliberate focus on the three capabilities manufacturing enterprises need as they move from pilot to production to fleet.

Operational Scaling

Deploy and manage Node-RED reliably across sites, teams, and environments — without the configuration drift and version inconsistency that comes with growth.

System Agility

Build, iterate, and adapt faster with AI-assisted tooling. Certified Nodes and AI Insights together mean your team spends less time on asset modeling and more time on outcomes.

Event-Driven Data Bridge

Connect your systems with operational responsiveness — not just bulk data collection. FlowFuse is built for the workflow-centric, event-driven logic that manufacturing operations actually run on.

What this means for your team

FlowFuse has always been built on Node-RED — but Enterprise customers need more than a great open-source foundation. They need a platform they can stake production operations on.

Certified Nodes and AI Insights are the next step in making FlowFuse that platform: more accountable, more capable, and faster to value than ever.

Get started at flowfuse.com/pricing.

How to Monitor Industrial Network Health Using SNMP

2026-03-20T00:00:00Z

Industrial networks fail quietly. A saturated uplink, a flapping interface, or a device nearing its resource ceiling degrades silently until a line goes down or a control loop breaks.

SNMP exists precisely to prevent that. Decades proven, it remains the most reliable protocol for extracting health telemetry from switches, routers, PLCs, and RTUs. No agents, no overhead, runs on everything.

The gap has always been implementation. Most teams either over-engineer it with heavyweight NMS platforms or under-engineer it with brittle scripts. Neither is acceptable when network visibility is an uptime and safety concern.

This guide walks through building a production-grade SNMP monitoring pipeline with FlowFuse, polling device metrics, discovering interfaces, and feeding telemetry into a FlowFuse Dashboard where your team can act on it.

Prerequisites

Before getting started, make sure you have the following in place:

FlowFuse: A running FlowFuse instance on your edge device. If you do not have an account yet, sign up to get started and follow this guide to get Node-RED running.
An SNMP-enabled device: Any managed switch, router, PLC, or RTU with SNMP enabled and UDP port 161 accessible from your FlowFuse instance. If you do not have a real device available, you can run a local SNMP agent for testing — see net-snmp.org for installation instructions for your platform.
UDP port 161 access: Confirm your community string and ensure firewall rules permit SNMP polling from your FlowFuse host to the target device.

Understanding SNMP

SNMP operates on a simple manager-agent model. The manager (your FlowFuse instance) sends requests to the agent (a network device or server running an SNMP daemon) and the agent responds with the requested data. All communication happens over UDP port 161.

Data on the agent is organized in a Management Information Base (MIB) — a hierarchical tree of objects, each identified by an Object Identifier (OID). Every piece of information you can query from a device, its uptime, interface status, traffic counters, CPU load, has a unique OID.

There are three operations you will use in this guide:

GET: Fetch the value of a specific OID from a device.
WALK: Traverse an entire OID subtree and return all values beneath it. Useful for querying all interfaces at once.
SUBTREE: Fetch a specific OID subtree and everything beneath it. More targeted than a full walk.

SNMP also has versions. SNMPv1 and v2c use a plain-text community string as authentication. SNMPv3 adds user-based authentication and encryption. For production industrial environments, v3 is the right choice. For this guide, we use v2c to keep the focus on the implementation.

Installing SNMP Package in FlowFuse

The node-red-node-snmp package provides a set of nodes for communicating with SNMP-enabled devices directly from your flows. Before building the monitoring pipeline, install it into your FlowFuse instance.

Open your FlowFuse instance and navigate to the Node-RED editor.
Click the hamburger menu in the top-right corner and select Manage Palette.
Go to the Install tab.
Search for node-red-node-snmp.
Click Install and wait for the installation to complete.

Once installed, you will see the following nodes available in your palette under the network category:

snmp — fetch one or more specific OIDs
snmp walker — walk from a given OID to the end of the MIB tree
snmp subtree — fetch a specific OID subtree and everything beneath it
snmp table — fetch structured SNMP table data
snmp set — write values back to a device

SNMP nodes available in the Node-RED palette after installing node-red-node-snmp

For this guide we will be working with snmp, snmp walker, and snmp subtree. These three cover the core read operations needed for network health monitoring.

Polling Device Metrics with SNMP GET

The snmp node sends a GET request to the agent and returns the values of the OIDs you specify. You can pass a single OID or a comma-separated list — the node fetches all of them in one request and returns the results as an array. This is the right operation when you know exactly what you want to fetch — system uptime, device name, description.

We will poll three key system OIDs in a single GET request every five seconds. All three sit under the system group (1.3.6.1.2.1.1), which is part of MIB-II — the standard MIB supported by virtually every SNMP-enabled device. Standard OIDs are consistent across vendors, so the same OID returns sysUpTime whether you are querying a Cisco switch, a Siemens PLC, or a Linux server. Vendor-specific metrics live under 1.3.6.1.4.1 and vary by device — you will need the vendor's MIB file for those. For browsing standard OIDs, see the OID reference for the system group.

OID	Name	What it returns
`1.3.6.1.2.1.1.3.0`	sysUpTime	How long the device has been running, in timeticks
`1.3.6.1.2.1.1.5.0`	sysName	The configured hostname of the device
`1.3.6.1.2.1.1.1.0`	sysDescr	A full description of the hardware and OS

Drag an inject node onto the canvas and double click it. Set the repeat interval to every 5 seconds and click Done.
Drag an snmp node onto the canvas and double click it to configure:

Field	Value
Host	IP address of your target device, e.g. `192.168.1.1`
Community	`public`
Version	`v2c`
OIDs	`1.3.6.1.2.1.1.3.0,1.3.6.1.2.1.1.5.0,1.3.6.1.2.1.1.1.0`

Note: OIDs in the list must be comma-separated with no spaces between them.

Click Done.
Drag a debug node onto the canvas, connect it to the snmp node output, and click Deploy to verify the raw response first.

You will notice the response is not immediately human-readable. OctetString values such as sysName and sysDescr come back as byte arrays, and sysUpTime arrives as a raw TimeTicks integer:

[
  { "oid": "1.3.6.1.2.1.1.3.0", "type": 67, "value": 317537, "tstr": "TimeTicks" },
  { "oid": "1.3.6.1.2.1.1.5.0", "type": 4, "value": [34, 116, 101, 115, 116, ...], "tstr": "OctetString" },
  { "oid": "1.3.6.1.2.1.1.1.0", "type": 4, "value": [68, 97, 114, 119, 105, ...], "tstr": "OctetString" }
]

We need a function node to convert byte arrays to strings and TimeTicks to a readable uptime format.

Drag a function node onto the canvas and insert it between the snmp node and the debug node.
Double click it and add the following code:

const parsed = msg.payload.map(item => {
    let value = item.value;

    if (item.tstr === "OctetString") {
        value = Buffer.from(value).toString("utf8").replace(/"/g, "");
    }

    if (item.tstr === "TimeTicks") {
        const totalSeconds = Math.floor(value / 100);
        const days = Math.floor(totalSeconds / 86400);
        const hours = Math.floor((totalSeconds % 86400) / 3600);
        const minutes = Math.floor((totalSeconds % 3600) / 60);
        const seconds = totalSeconds % 60;
        value = `${days}d ${hours}h ${minutes}m ${seconds}s`;
    }

    return { oid: item.oid, name: item.tstr, value };
});

msg.payload = parsed;
return msg;

Tip: If you need different parsing logic for additional OID types or want to transform the output differently, you do not have to write it from scratch. FlowFuse's AI-powered function generation lets you describe what you need in plain English and generates the function node code for you directly inside the editor.

Click Done and click Deploy.

The debug panel will now show clean, readable output:

[
  { "oid": "1.3.6.1.2.1.1.3.0", "name": "TimeTicks", "value": "0d 0h 52m 55s" },
  { "oid": "1.3.6.1.2.1.1.5.0", "name": "OctetString", "value": "test-device" },
  { "oid": "1.3.6.1.2.1.1.1.0", "name": "OctetString", "value": "Linux core-switch-01 5.15.0 #1 SMP x86_64" }
]

With system metrics polling cleanly, the next section covers using the snmp walker node to discover and monitor all network interfaces on the device.

Discovering Interfaces with SNMP Walker

The snmp walker node traverses the MIB tree starting from a given OID and returns every object beneath it. Unlike GET where you specify exact OIDs, walker is useful when you do not know the full OID path in advance — for example, discovering all network interfaces on a device without knowing how many exist or what their index numbers are.

Network interfaces on any SNMP device live under the ifTable (1.3.6.1.2.1.2.2). Walking this subtree returns every interface along with its name, operational status, speed, and traffic counters — one entry per interface regardless of how many the device has.

OID	Name	What it returns
`1.3.6.1.2.1.2.2.1.1`	ifIndex	Unique index number for each interface
`1.3.6.1.2.1.2.2.1.2`	ifDescr	Interface name, e.g. `eth0`, `GigabitEthernet0/1`
`1.3.6.1.2.1.2.2.1.8`	ifOperStatus	Operational status — `1` = up, `2` = down
`1.3.6.1.2.1.2.2.1.10`	ifInOctets	Total inbound bytes on the interface
`1.3.6.1.2.1.2.2.1.16`	ifOutOctets	Total outbound bytes on the interface

Walking from 1.3.6.1.2.1.2.2 returns all of the above for every interface in one request. For the full ifTable OID reference see alvestrand.no/objectid/1.3.6.1.2.1.2.2.

Note: The walker node requires a device with a populated interface table. If you are using a lightweight test agent, increase the timeout in the walker node configuration to at least 30 seconds. On resource-constrained devices that cannot handle bulk requests, use the snmp subtree node instead.

Drag an inject node onto the canvas and double click it. Set the repeat interval to every 10 seconds and click Done.
Drag an snmp walker node onto the canvas and double click it to configure:

Field	Value
Host	IP address of your target device, e.g. `192.168.1.1`
Community	`public`
Version	`v2c`
OID	`1.3.6.1.2.1.2.2`
Timeout	`30`

Click Done.
Drag a function node onto the canvas and insert it between the walker node and a debug node. Double click it and add the following code to parse the response into a readable structure:

const interfaces = {};

msg.payload.forEach(item => {
    if (!item.oid.startsWith("1.3.6.1.2.1.2.2.1.")) return;

    const parts = item.oid.split(".");
    const ifIndex = parts[parts.length - 1];
    const subOid = parts.slice(0, -1).join(".");

    if (!interfaces[ifIndex]) interfaces[ifIndex] = { index: ifIndex };

    let value = item.value;

    const oidMap = {
        "1.3.6.1.2.1.2.2.1.1": "ifIndex",
        "1.3.6.1.2.1.2.2.1.2": "ifDescr",
        "1.3.6.1.2.1.2.2.1.8": "ifOperStatus",
        "1.3.6.1.2.1.2.2.1.10": "ifInOctets",
        "1.3.6.1.2.1.2.2.1.16": "ifOutOctets"
    };

    if (oidMap[subOid]) {
        if (subOid === "1.3.6.1.2.1.2.2.1.2") {
            const data = value.data || value;
            value = Buffer.from(data).toString("utf8").replace(/"/g, "").trim();
        } else if (subOid === "1.3.6.1.2.1.2.2.1.8") {
            value = value === 1 ? "up" : "down";
        }
        interfaces[ifIndex][oidMap[subOid]] = value;
    }
});

msg.payload = Object.values(interfaces).filter(i => i.ifDescr);
return msg;

Click Done.
Drag a debug node onto the canvas and connect it to the function node output.
Connect the inject node output to the walker node input, and the walker node output to the function node input.
Click Deploy.

The debug panel will show a clean array of interface objects like this:

[
  {
    "index": "1",
    "ifIndex": 1,
    "ifDescr": "lo",
    "ifOperStatus": "up",
    "ifInOctets": 20526,
    "ifOutOctets": 20526
  },
  {
    "index": "2",
    "ifIndex": 2,
    "ifDescr": "enp0s1",
    "ifOperStatus": "up",
    "ifInOctets": 48159944,
    "ifOutOctets": 4263495
  }
]

Each entry represents one interface with its current operational status and traffic counters. In the next section we will use the snmp subtree node to fetch interface data more precisely by targeting a specific OID subtree.

Fetching Interface Data with SNMP Subtree

The snmp subtree node is similar to walker but more targeted. Where walker reads from a given OID to the end of the entire MIB tree, subtree fetches everything beneath a specific OID and stops there. This makes it more predictable and efficient when you know the exact branch you want.

For network health monitoring, a practical use of subtree is pulling all operational status values for every interface in one shot by targeting ifOperStatus directly at 1.3.6.1.2.1.2.2.1.8. This gives you a clean up/down status for every interface on the device without pulling traffic counters or other data you do not need at that moment.

Drag an inject node onto the canvas and double click it. Set the repeat interval to every 10 seconds and click Done.
Drag an snmp subtree node onto the canvas and double click it to configure:

Field	Value
Host	IP address of your target device, e.g. `192.168.1.1`
Community	`public`
Version	`v2c`
OID	`1.3.6.1.2.1.2.2.1.8`

Click Done.
Drag a function node onto the canvas and insert it between the subtree node and a debug node. Double click it and add the following code to parse the interface status values:

const statuses = msg.payload.map(item => {
    const parts = item.oid.split(".");
    const ifIndex = parts[parts.length - 1];
    return {
        ifIndex: ifIndex,
        ifOperStatus: item.value === 1 ? "up" : "down"
    };
});

msg.payload = statuses;
return msg;

Tip: If you need different parsing logic for additional OID types or want to transform the output differently, you do not have to write it from scratch. FlowFuse's AI-powered function generation lets you describe what you need in plain English and generates the function node code for you directly inside the editor.

Click Done.
Connect the inject node to the subtree node, the subtree node to the function node, and the function node to a debug node.
Click Deploy.

The debug panel will show a concise status array for every interface:

[
  { "ifIndex": "1", "ifOperStatus": "up" },
  { "ifIndex": "2", "ifOperStatus": "down" }
]

This is the most efficient way to run a continuous interface health check, one subtree poll every 10 seconds tells you the operational state of every interface on the device without fetching data you do not need.

With all three polling operations in place, the next step is wiring this data into a FlowFuse Dashboard so the information is visible at a glance.

Wrapping Up

Industrial networks don't announce their problems. They accumulate them silently until a line goes down, a control loop breaks, or production stops.

The pipeline you've built here changes that. GET, Walker, and Subtree give you precise, continuous visibility into every device on your network. FlowFuse delivers it without the infrastructure overhead of a full NMS platform or the maintenance burden of hand-rolled scripts.

Wire the telemetry into a FlowFuse Dashboard. Set threshold-based alerts. Extend your OID coverage to vendor-specific metrics as your requirements grow. The foundation is in place. Everything else is iteration.

Unmonitored networks are a liability. Now yours isn't.

Edge vs Cloud AI in Manufacturing: Where Each Actually Belongs

2026-03-16T00:00:00Z

Most industrial AI deployments are built around the wrong question. "Edge or cloud?" treats a deployment decision as a binary choice, when the real question is simpler and more useful: what does this specific workload actually require?

Edge AI offers real-time inference with no network dependency. Cloud AI offers the depth of compute and data that builds models worth deploying in the first place. Both are genuinely necessary. Neither is universally correct. And the architecture that works is almost always a hierarchy of both, not a choice between them.

This piece looks at where each layer performs, where each fails, and how to place workloads correctly across the hierarchy. The goal is not a verdict. It is a framework for making the decision well, every time.

What Edge AI and Cloud AI Actually Mean on the Plant Floor

Edge AI processes data where it is generated. The model runs locally on a gateway or industrial PC, directly on the factory floor. Data from sensors, cameras, and machines is analyzed on the spot, and the result is immediate.

Cloud AI processes data in a remote data center. Information travels over a network to where the compute lives. The infrastructure scales to meet demand, and the same models can serve every site in an operation.

Both are real approaches to industrial AI, built for different problems and different scales.

Where Edge AI Works Best

Think about what happens in the seconds after a sensor detects something abnormal on a running line. There is no time to package that data, send it to a remote server, wait for a response, and act. The machine has already moved on.

This is the environment edge AI was built for. Manufacturing lines running at speed, assets in remote locations, facilities where network connectivity is inconsistent or restricted. In these situations, the model needs to live close to the source, processing data as it arrives and producing a result before the next event occurs.

Quality inspection is one of the clearest examples. A vision system identifying surface defects, dimensional errors, or assembly faults on a fast-moving line has a window measured in milliseconds. The same logic applies to condition monitoring on rotating equipment, anomaly detection on process instrumentation, and real-time control adjustments based on live sensor feeds.

Edge AI also matters where data cannot easily leave the facility. Regulatory requirements, network constraints, or simple operational practicality all create situations where keeping data local is not optional. Running the model at the edge removes the dependency entirely.

The use cases are varied but the underlying condition is consistent. When speed, proximity, or data locality is non-negotiable, the architecture decision is straightforward.

Where Cloud AI Works Best

Edge AI handles the moment. What it cannot handle is everything that happens before that moment becomes possible.

A single facility sees a fraction of the picture. One site running one set of machines accumulates useful data. But an organization running fifty sites, each generating operational data around the clock, is sitting on something far more valuable. The patterns that predict failure, the process conditions that drive quality, the anomalies that precede downtime. These only become visible when data is brought together at scale.

That is the problem cloud AI was built to solve. Not speed, but depth. Not real-time response, but the kind of learning that takes weeks of data, hundreds of assets, and serious compute to produce. A predictive model that has seen ten thousand failure events across a global fleet will always outperform one trained on a single site. The cloud is where that model gets built.

It is also where industrial organizations manage AI at scale. Retraining models as conditions change, pushing updates across distributed deployments, monitoring performance across every site from a single place. Doing that at the edge, independently, across dozens of locations, is not a realistic proposition.

The workloads that belong in the cloud share a common characteristic. They are not time-critical, but they are data-hungry and compute-intensive. And the value they produce, better models, broader visibility, smarter operations, flows back down to the plant floor where it matters.

The Trade-offs

Every architecture decision in industrial AI comes down to the same five factors. Get them right and the deployment works. Get them wrong and the problems compound quietly until they become expensive.

Latency determines whether cloud is even an option for a given workload. Bandwidth determines what it costs to run it. Data ownership determines what is permissible. Model complexity determines what is technically feasible. And operational overhead determines what the true long-term cost looks like, not just the build cost.

Factor	Edge	Cloud
Latency	Real-time, no network dependency	Adds network round-trip, not suitable for time-critical decisions
Bandwidth	Data stays local, minimal transfer costs	High volumes must travel, costs and infrastructure scale with data
Data Ownership	Stays on site, no external exposure	Requires a deliberate strategy on what leaves and where it lives
Model Complexity	Constrained by local hardware	No practical ceiling, runs the largest and most complex models
Operational Overhead	Multiplies with every site added	Centralized but dependent on connectivity and third-party uptime

The factors rarely pull in the same direction. A workload that demands low latency often generates high data volumes, making cloud impractical on two counts at once. A model complex enough to require cloud compute may involve data that cannot leave the facility. These tensions are where most architecture decisions get made, and where getting the balance right matters most.

The Hierarchy and Where Each Workload Belongs

The architecture that resolves the edge-vs-cloud question is a five-level hierarchy, one the manufacturing industry already knows. It maps directly to the ISA-95 functional model that has guided industrial operations for decades.

Each level handles a different class of decisions, at a different speed, with a different scope of data.

Level 0–1 (On-Device): Inference runs directly on the sensor, camera, or actuator. Models are small and fast, operating in microseconds with no network involved.
Level 2 (Edge Compute Node): Pulls data from multiple machines and runs more capable models across a production cell or line. Keeps working during network outages and syncs upstream when connectivity returns. This level is the most commonly skipped in early planning and the most expensive to add later.
Level 3 (Plant-Level Server): Handles facility-wide analytics, MES integration, and the data historian that feeds both local reporting and cloud synchronization.
Level 4–5 (Enterprise and Cloud): Where models are trained, retrained, and managed across every site. Latency is not a concern here. Compute depth is.

Data flows up through this hierarchy for aggregation and learning. Model updates, detection thresholds, and configurations flow back down. An architecture that flips this, sending time-sensitive decisions to the cloud while the edge just passes data along, will run into the same problems as a cloud-only deployment, regardless of what it is called.

Placing workloads correctly is where most industrial AI projects go wrong. The starting point is always the decision itself: what is the AI being asked to do, and what happens if the answer is late? Three questions settle most cases:

What response time is acceptable? Milliseconds point to Level 0–2. Seconds to minutes allow Level 3. Hours or longer can go to the cloud.

Can the data leave the facility? Regulatory constraints, network limitations, or operational policy may make cloud processing impermissible regardless of latency.

How much context does the model need? Single-asset inference fits at the edge. Cross-site pattern recognition belongs in the cloud.

In most real deployments, the same asset feeds multiple levels simultaneously: a Level 2 anomaly detection model acting in real time, a Level 3 shift performance report running every few hours, and a Level 4–5 fleet-wide predictive model retrained monthly. These are three different problems running at three different speeds, not one problem waiting for one answer.

Conclusion

The edge-vs-cloud question has a straightforward answer once the right question is being asked. Not "where should we run our AI?" but "what does this specific workload require, and which level of the hierarchy delivers it?"

Edge and cloud are not competing philosophies. They are complementary layers of a single architecture that the manufacturing industry already understands. What industrial AI adds is the requirement to place intelligence deliberately at each level, not just data collection at the bottom and reporting at the top, but active inference, model management, and continuous learning distributed across the hierarchy in proportion to where the decisions actually happen.

The technology to do this exists. The frameworks are mature, the hardware is proven, and the use cases are well established. What separates deployments that deliver sustained operational value from the ones that stall after the pilot is not the sophistication of the models. It is the clarity of the architecture and the discipline to build it in the right order.

Define the decision. Map it to the hierarchy. Build the infrastructure that decision requires. Then train the model.

That sequence is what industrial AI at scale actually looks like, and FlowFuse is the platform built to run it. From connecting machines and collecting data, to transforming and visualizing it in real time, to running model inference directly in the flow with ONNX nodes, wiring live plant data into AI agents with MCP, and letting operators query their operations in plain language with Expert Insights. One platform. Every level of the hierarchy.

How to Connect to Beckhoff TwinCAT PLC Using ADS (2026)

2026-03-13T00:00:00Z

Beckhoff TwinCAT is one of the most widely deployed PLC platforms in industrial automation. ADS, its native communication protocol, gives you direct read and write access to PLC variables without additional licensing or middleware, and connecting from FlowFuse means tapping into that same channel TwinCAT uses internally.

The challenge is usually not the tooling. It is the routing layer. AMS Net IDs, route tables, firewall rules. Get any of those wrong and ADS fails without telling you why. This guide covers the routing first, before touching a single FlowFuse node, because that is where most people get stuck.

By the end you will have live TwinCAT variables flowing into FlowFuse.

Prerequisites

Before you begin, make sure you have the following in place:

TwinCAT 3.1 runtime running on a Beckhoff IPC
FlowFuse running on an edge device with network access to the TwinCAT machine. If you don't have an account yet, sign up to get started, then follow this guide to quickly run a FlowFuse instance on your edge device.
Both devices on the same network
Port 48898 open between the two devices
Symbol creation enabled on PlcTask so variables are accessible by name over ADS
PLC logged in and deployed on port 851
PLC in Run mode — the TwinCAT system tray icon must be green
Symbol paths of the variables you want to read or write, available from whoever wrote the PLC program

If you don't have a real PLC available and want to follow along with a test setup, see Setting Up a Test PLC at the end of this guide before continuing.

What is ADS and Why It Matters

ADS, Automation Device Specification, is not an integration layer Beckhoff added for external tools. It is the internal communication backbone of the TwinCAT runtime itself. The same protocol TwinCAT XAE uses when you go online with a PLC, the same one the HMI uses to read variables, the same one the NC task uses to talk to the PLC task. When you connect from FlowFuse, you are using that same channel.

Every TwinCAT device has an AMS Net ID. It looks like an IP address with two extra octets: 10.68.82.232.1.1. The first four typically match the device IP, the last two are almost always 1.1 by convention. This is how the ADS router identifies devices on the network, and it is what you will configure in every connection you make from FlowFuse.

Within a device, different TwinCAT components are reachable on different ADS ports. The PLC runtime listens on port 851 by default. If your machine runs multiple PLC tasks, each task gets its own port: the first task is 851, the second is 852, and so on. Check with the controls engineer which port corresponds to the task containing your variables.

Three things cause silent failures: wrong AMS Net ID, missing route, blocked port 48898. ADS gives you nothing when any of these are wrong. No error, no timeout message, just silence. That is why we cover routing before touching a single FlowFuse node.

Configuring ADS Routes

TwinCAT will not accept an ADS connection from an unknown host. Every external device that needs to connect must be explicitly trusted in TwinCAT's route table. This is stored in a file called StaticRoutes.xml on the TwinCAT machine.

TwinCAT provides a route manager in the system tray under Router > Edit Routes. However it does not expose the Flags setting, which defaults to 64 and will silently block connections from non-Windows devices such as Linux or Mac based edge devices. Editing StaticRoutes.xml directly is the only way to set Flags to 0, which allows connections from any trusted device on your network.

Before adding the route you need two pieces of information:

The IP address of your FlowFuse edge device
The AMS Net ID you will assign to it, which is the IP address with .1.1 appended

For example if your FlowFuse device IP is 10.68.82.101, its AMS Net ID is 10.68.82.101.1.1.

Important: Your FlowFuse edge device must be on the same network as the interface TwinCAT's AMS Net ID is bound to. TwinCAT binds its AMS Net ID to a specific network interface on startup. If your machine has multiple network interfaces, confirm which IP the AMS Net ID uses — you can find it by right clicking the TwinCAT tray icon and selecting About TwinCAT System. Your FlowFuse device must be reachable on that same network, otherwise the ADS handshake will fail even if port 48898 is open.

Edit StaticRoutes.xml:

If you do not have direct access to the TwinCAT machine, ask the controls engineer or machine builder to make this change. Share this section with them so they know exactly what needs to be set, particularly the Flags value of 0.

Warning: The PowerShell command below overwrites the entire StaticRoutes.xml file. If the TwinCAT machine already has existing routes configured, back up the file before running this command or add your route entry manually inside the existing <RemoteConnections> block instead.

On the TwinCAT machine open PowerShell as administrator
Run the following command, replacing YOUR_EDGE_DEVICE_IP with the actual IP of your FlowFuse device:

$xml = @"
<?xml version="1.0"?>
<TcConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <RemoteConnections>
    <Route>
      <Name>flowfuse-edge</Name>
      <Address>YOUR_EDGE_DEVICE_IP</Address>
      <NetId>YOUR_EDGE_DEVICE_IP.1.1</NetId>
      <Type>TCP_IP</Type>
      <Flags>0</Flags>
    </Route>
  </RemoteConnections>
</TcConfig>
"@
$xml | Set-Content "C:\Program Files (x86)\Beckhoff\TwinCAT\3.1\Target\StaticRoutes.xml"

Note: In this example, TwinCAT 3.1 is installed. If you are using a different version, replace 3.1 with the version installed on your system. The installation path may also vary depending on your TwinCAT setup.

Restart the TwinCAT router from the system tray by right clicking the TwinCAT icon and selecting Router > Restart.
Open the Windows Firewall and confirm that port 48898 is allowed for inbound TCP connections.

After the router restarts, verify that port 48898 is reachable from your FlowFuse edge device by running nc -zv <twincat-ip> 48898. If the connection is refused, confirm the firewall rule was saved and that both devices are on the same subnet.

Installing node-red-contrib-ads-client in FlowFuse

In your FlowFuse instance open the Node-RED editor
Click the hamburger menu in the top right and select Manage Palette
Go to the Install tab
Search for node-red-contrib-ads-client
Click Install and wait for it to complete
Click Close

Once the installation is complete, a few nodes will appear in the right-hand palette under the TwinCAT ADS category.

Connecting to TwinCAT

Add the connection node:

In Node-RED drag an ADS – Connection Status node onto the canvas
Double click it to open the configuration
Next to the Connection field click + to create a new connection
In the Required Settings tab fill in the Target AMS Net ID and Target ADS Port:

Field	Value
Target AMS Net ID	AMS Net ID of your TwinCAT machine, e.g. `10.68.82.232.1.1`
Target ADS Port	`851`

Switch to the Optional Settings tab and fill in the network settings:

Field	Value
Router Address	IP address of your TwinCAT machine, e.g. `10.68.82.232`
Router TCP Port	`48898`
Local AMS Net ID	AMS Net ID of your FlowFuse edge device, e.g. `10.68.82.101.1.1`
Local ADS Port	`32750`

The Router Address and Router TCP Port allow the ADS client to reach the TwinCAT router over the network. The Local AMS Net ID identifies your FlowFuse edge device inside the ADS routing system and must match the route configured in StaticRoutes.xml. The Local ADS Port defines the local ADS endpoint used by the client and normally does not need to be changed.

Note: If your TwinCAT system is in config mode or the PLC runtime takes time to initialize on startup, enable Allow Half Open in the connection settings. Without it the client performs a strict system state check on connect and will fail with ADS error 7 even if the router is reachable. With it enabled the client connects regardless and waits for the runtime to become ready.

Click Add to save the connection configuration
Click Done
Click Deploy

Within a few seconds the connection status node should show connected, indicating that FlowFuse successfully established an ADS session with the TwinCAT runtime.

Reading PLC Variables

With the connection working, reading a variable takes three nodes: an inject node to trigger the read, a read value node to fetch the value, and a debug node to see the output.

Drag an inject node onto the canvas
Double click it and leave the default settings so it triggers manually
Click Done
Drag an ADS - Read Value node onto the canvas
Double click it to configure
Select your TwinCAT connection from the Connection dropdown
Set the Variable name to the full symbol path of the variable you want to read. Symbol paths are always in the format ProgramName.VariableName. If you are following along with the test PLC, use MAIN.temperature. If you are connecting to a real PLC, use the symbol paths provided by the controls engineer.

Click Done
Drag a debug node onto the canvas
Connect the inject node output to the read value node input
Connect the read value node output to the debug node input
Click Deploy

Click the inject button. You should see the variable value appear in the debug panel.

Subscribing to Variable Changes

Polling on a fixed timer works but is inefficient. For live data the better approach is to subscribe to variable changes. TwinCAT sends a new value to FlowFuse only when the value actually changes, which reduces unnecessary network traffic and gives you lower latency updates.

Drag an ADS - Subscribe Value node onto the canvas
Double click it to configure
Select your TwinCAT connection from the Connection dropdown
Set the Variable name to the full symbol path of the variable you want to monitor. If you are following along with the test PLC, use MAIN.motorRunning — it toggles roughly once per second so you will see true and false values arriving in the debug panel without being overwhelmed.
Set the Subscription mode to On Change. This tells the TwinCAT runtime to notify FlowFuse only when the variable value has actually changed, rather than pushing the value on every cycle regardless of whether it changed. If you need a value delivered at a fixed interval even when unchanged, use Cyclic instead.
Set the Cycle time to 100 milliseconds. This is how frequently TwinCAT checks for changes on its side.

Click Done
Connect its output to a debug node
Click Deploy

The debug node will now receive a message every time the variable value changes in the PLC, with no polling required from FlowFuse.

Writing to PLC Variables

Writing back to the PLC closes the loop. This is useful for sending setpoints, commands, or reset signals from FlowFuse back to TwinCAT.

Drag an ADS - Write Value node onto the canvas
Double click it to configure
Select your TwinCAT connection
Set the Variable name to the full symbol path of the variable you want to write to. If you are following along with the test PLC, use MAIN.setpoint.
Leave Automatically fill missing properties (autoFill) unchecked. This setting only applies when writing complex types such as structs or function blocks — it reads the current value from the PLC first and merges your changes on top so unspecified fields are not zeroed out. For a simple variable like MAIN.setpoint it has no effect.

Click Done
Drag an inject node onto the canvas
Double click it and set the payload type to match the type of your PLC variable. The payload type must match what the PLC expects — a Number for INT or REAL, a boolean for BOOL, a string for STRING, and so on. If you are following along with the test PLC, setpoint is declared as INT so set the payload type to Number.
Click Done
Connect the inject node output to the write node input
Click Deploy
Click the inject button to trigger the write

To verify the write worked, add a read value node for the same variable and check that the value updated in the debug panel.

Troubleshooting

Connection fails silently with no error The FlowFuse device IP is not in StaticRoutes.xml or Flags is set to 64 instead of 0. Edit the file using the PowerShell command in the routing section, then restart the TwinCAT router.
ADS error 7: Target machine not found The most common cause is that your FlowFuse device and the TwinCAT machine are not on the same network as the interface TwinCAT's AMS Net ID is bound to. Check the AMS Net ID in About TwinCAT System on the TwinCAT machine and confirm your FlowFuse device has an IP on that same subnet. Also confirm the FlowFuse device IP is in StaticRoutes.xml with Flags set to 0, and that the router was restarted after any changes. If the PLC runtime takes time to initialize on startup, enable Allow Half Open in the connection node.
Error: Connection to 127.0.0.1:48898 failed The Router Address field in the connection node is empty or incorrect. Open the connection node, set the Router Address to the TwinCAT machine IP, and redeploy.
Error 1808: Symbol not found The variable name is wrong or does not exist in the PLC program. Double check the full symbol path including the program name prefix, for example MAIN.temperature. If you are using the test PLC, make sure symbol creation is enabled in PlcTask and the PLC is in Run mode.
Error 1804: Failed to get fingerprint The FlowFuse device IP is missing from StaticRoutes.xml or the TwinCAT router was not restarted after editing the file.
Port 48898 not reachable Port 48898 is blocked on the TwinCAT machine firewall or the two devices are not on the same network. Confirm the firewall rule is in place and test reachability with nc -zv <twincat-ip> 48898 from your FlowFuse device.
PLC variables not updating The PLC is not in Run mode. The TwinCAT system tray icon must be green. A blue icon means the runtime is stopped — right click the tray icon and select Restart TwinCAT (Run Mode).

Setting Up a Test PLC

This section is for readers who do not have a real TwinCAT PLC available and want to set up a minimal test environment to follow along with this guide. If you already have a PLC running, you do not need this section.

What You Need

A Windows machine or laptop
TwinCAT XAE Shell installed. Download it from the Beckhoff website

Important: If your Windows machine has Hyper-V enabled, TwinCAT will not run in KM mode and the system tray icon will stay blue instead of turning green. Make sure Hyper-V is disabled before proceeding. You may need to restart the machine after disabling it.

Create the Project

Open TwinCAT XAE Shell
Click File > New > Project
Select TwinCAT Projects then TwinCAT XAE Project
Give the project a name, for example AdsDemo, and click OK

Add a PLC Project

In Solution Explorer right click the project name and select Add New Item
Select Standard PLC Project, give it a name, and click Add

Write the PLC Program

In Solution Explorer expand PLC > your project > POUs and double click MAIN
In the declaration section (top panel) replace the existing content with:

PROGRAM MAIN
VAR
    temperature : REAL := 23.5;
    motorRunning : BOOL := FALSE;
    setpoint : INT := 100;
    cycleCount : INT := 0;
END_VAR

In the program body (bottom panel) add:

temperature := temperature + 0.1;
IF temperature > 100.0 THEN
    temperature := 0.0;
END_IF

cycleCount := cycleCount + 1;
IF cycleCount >= 1000 THEN
    motorRunning := NOT motorRunning;
    cycleCount := 0;
END_IF

This gives you three live variables to work with. temperature increments continuously every PLC cycle, motorRunning toggles roughly once per second, and setpoint stays static until you write to it from FlowFuse.

Enable Symbol Creation

Symbol creation must be enabled for ADS to access variables by name. Without this step the ADS client will connect successfully but fail to find any variables.

In Solution Explorer expand the project, then under Task double click PlcTask
Check Create symbols in the properties window that opens
Click OK

Build and Activate

Press Ctrl+Shift+B to build the project. Check the output window for any errors before continuing.
Right click the PLC instance in Solution Explorer and select Login

Note: If Login is not visible in the right click menu, find it in the top menu bar under PLC > Login.

When TwinCAT prompts you to create the application on port 851, click Yes. Do not skip this step or change the port.
Press F5 to start the PLC

The TwinCAT system tray icon must be green before you proceed. A blue icon means the runtime is not running and ADS connections will fail.

Your test PLC is now running. Go back to the Configuring ADS Routes section and continue from there. The variable paths you will use throughout this guide are MAIN.temperature, MAIN.motorRunning, and MAIN.setpoint.

Conclusion

You now have a working ADS connection between FlowFuse and TwinCAT, reading variables on demand, subscribing to live changes, and writing values back to the PLC. But this is just the starting point.

This guide covered the core nodes to get you connected and working. The node-red-contrib-ads-client package includes several other nodes worth exploring on your own, and future articles will cover more advanced use cases in depth.

With FlowFuse you can take this further. Build real-time dashboards that visualize live PLC data, connect TwinCAT to other systems like databases, ERP, or cloud platforms, set up alerts when variables go out of range, and create operator interfaces that let your team interact with the machine from anywhere. All of it built on the same connection you just configured, without writing a single line of custom integration code.

FlowFuse 2.28: Troubleshoot Faster, Manage Edge Devices Centrally, and More Self-Hosted Flexibility

2026-03-12T00:00:00Z

FlowFuse 2.28 focuses on making your day-to-day work faster and giving you more control — whether you are debugging a flow, managing edge devices, or running FlowFuse on your own infrastructure.

Troubleshoot Flows Faster with FlowFuse Expert

Tracking down issues in your flows usually means adding debug nodes, reading through log output, and then trying to describe the problem to get help. That back-and-forth slows you down.

Point Expert at Your Debug Logs

You can now select individual debug log entries and include them as context when asking FlowFuse Expert for help. Combined with your selected flows, Expert sees exactly what you see — the error, the flow that produced it, and the surrounding context.

Select specific log entries to give FlowFuse Expert focused troubleshooting context

Select individual log entries to focus Expert on the specific issue rather than everything in your log
Quick-add from the Resource Selector to pull in logs alongside your flows in one step
Get targeted answers because Expert reasons about your actual errors, not a description of them

Always Have the Latest Expert Capabilities

FlowFuse Expert is getting new capabilities regularly — like the debug log context above. But when you are deep in your flows, it is easy to miss that an update is available. Expert now shows a banner when a newer version is ready. One click and you are up to date, so you always have access to the latest troubleshooting and development features.

Expert lets you know when an update is available

New Device Agent Configuration Options

FlowFuse 2.28 combined with Device Agent v3.8.1 expands what you can configure on your edge devices, giving you more control over how Node-RED runs on Remote Instances.

Configure Node.js Runtime Options

The latest Device Agent lets you set Node.js command line arguments for Remote Instances — via your device.yml or the agent command line. Previously these options were not configurable at all. The full set of NodeJS (command line arguments)[https://nodejs.org/docs/latest-v22.x/api/cli.html] can be set. For example

Increase memory for flows that process large datasets (--max-old-space-size)

Set API Payload Limits from the UI

If your Remote Instances handle large file uploads, you may have hit the default API payload size limit. You can now configure the maximum API payload length directly in FlowFuse under Remote Instance → Settings → Editor.

More Flexibility for Self-Hosted Deployments

Migrate from Ingress Nginx to Traefik

With the retirement of Ingress Nginx, many self-hosted Kubernetes users need to move to a supported ingress controller. To help with this transition, we have prepared a blueprint for migrating from Ingress Nginx to Traefik. The Helm chart now includes the required job resources and RBAC for the migration tool, and we have published a step-by-step ingress controller migration guide to walk you through the process.

As part of this work, you can now also set a separate ingress class name for Hosted Instances using forge.projectIngressClassName, allowing you to run project traffic through a different ingress controller than the platform itself.

Additional self-hosted improvements

Team NPM Registry — Docker Compose deployments can now have all the Team Library, Custom Nodes pre-requisits configured.
File-server PVC configuration — Set the size, access modes, and storage class for file-server persistent volumes
Private CA certificate mounting — Docker Compose deployments can now mount a private CA certificate file into the forge service

What else is new?

Instances can now automatically receive scheduled maintenance, so they stay up to date without manual configuration.
Updated FlowFuse Expert documentation with dedicated guides for the Chat Interface and AI-assisted features in Node-RED

For detailed breakdowns of each feature with additional visuals, visit our changelog. For the complete list of everything included in FlowFuse 2.28, check out the release notes.

If something in this release improves your workflow, or if there is still friction we can remove, please share feedback or report issues regarding this release to us.

Try FlowFuse

FlowFuse Cloud

The fastest way to get started is with FlowFuse Cloud. Get started for free and have your Node-RED instances running in minutes.

Self-Hosted

Run FlowFuse locally using Docker or Kubernetes.

The Last Mile Problem in Industrial AI

2026-03-09T00:00:00Z

There is a slide that lives in almost every industrial AI project deck.

On the left: data collection, model training, validation. On the right: operational value, reduced downtime, optimized throughput. In the middle, a small box labeled "deployment" that nobody in the room questions, because everyone has already moved on to the numbers on the right.

That box is where most industrial AI projects end.

Not with a failure report. Not with a cancelled contract. They end slowly, in staging environments that quietly become permanent, in quarterly reviews where "ongoing" gets said for the fourth time with less conviction than the third. The model is fine. The model has always been fine. The floor looks exactly the same as it did before the project started.

What lives inside that box is harder than the model and less interesting to talk about. It is the work of connecting intelligent software to a plant that was not built to receive it. Machines that predate wireless. Protocols designed for reliability, not interoperability. Engineers who know every quirk of every line and have watched enough consultants walk through with laptops to reserve judgment until something actually works.

In logistics, the last mile is the final stretch of a delivery, the leg that accounts for more than half the cost of shipping and has defeated every attempt to engineer it away. Industrial AI has the same problem. Not measured in distance. Measured in the gap between a model that performs and a plant that benefits.

Most industrial AI projects are funded to build the model. The mile after it gets a box on a slide.

The Scoping Lie

Every industrial AI project proposal looks roughly the same.

There is a discovery phase. A data assessment. A model development stage with clear milestones and measurable accuracy targets. And then, near the bottom of the document, a deployment section that is usually one page, sometimes half a page, occasionally a single bullet point that says something like "integration with existing systems" without specifying which systems, how long that will take, or who is responsible for it.

That bullet point is where the project dies. It just takes six months to find out.

The people writing these proposals are not being dishonest. They are being optimistic in the way that every vendor is optimistic when the contract has not been signed yet. The integration work is real, they know it is real, but it is also the part of the project that is hardest to scope without knowing the plant, the protocols, the historian configuration, the network topology, the IT security policies, and a dozen other variables that only become visible once someone is standing on the floor with access credentials and a growing sense of unease.

So it gets compressed. One line. One assumption. One box on a slide.

And the buyer approves it, because the buyer is looking at the numbers on the right side of the timeline, the ones showing reduced downtime and optimized throughput, and the deployment box is between them and those numbers, and it looks small.

It is not small.

The integration work in a real industrial environment is not a technical footnote. It is the project. Connecting an AI model to a plant means touching systems that the OT team has kept stable for a decade and does not want anyone near. It means translating between protocols that were never designed to talk to each other. It means getting IT and OT into the same room, agreeing on data ownership, network access, security boundaries, and update procedures for infrastructure that both teams think belongs to the other.

None of that is in the proposal. All of it determines whether the proposal was worth signing.

The Cost of Standing Still

Pilot purgatory feels like a neutral state. The project is not cancelled. Progress is being made. The model is ready whenever the integration catches up.

It is not neutral.

Every month an AI model sits in staging is a month of decisions made on instinct instead of intelligence. A predictive maintenance model that never reached the floor did not just fail to deliver value. It failed to prevent every unplanned downtime event it would have caught. Every quality escape the anomaly detector would have flagged. Every maintenance window scheduled too late or too early because the optimization model was still "ongoing."

That cost does not appear in any project report. It is invisible precisely because the thing that would have measured it never got deployed. But it is real, and it compounds.

Every stalled initiative also makes the next one harder to fund. The VP who approved the last pilot is not writing another check with the same enthusiasm. The organizational appetite for transformation is not infinite. Stalled pilots consume it without producing anything in return.

The Ownership Vacuum

Here is a question worth asking before the next industrial AI project gets funded.

When the model is in production and something goes wrong at 2 a.m. on a Saturday, who gets the call?

In most manufacturing organizations, nobody has a clean answer to that. The data science team built the model but does not own the plant systems it connects to. The OT team owns the plant but did not build the model and does not have visibility into why it is behaving the way it is. IT owns the network the data travels across but considers the edge devices an OT problem. Nobody owns the pipeline between them.

This is not a technology problem. It is a leadership problem that has been dressed up as one.

The technology gap between a trained model and a production deployment is real, but it is solvable. Talented engineers solve harder problems every day. What stops them is not the complexity of the integration. It is the absence of anyone whose job it is to own the outcome. When the integration work falls between two teams and neither team has it in their objectives, it does not get done. It gets discussed. It gets escalated. It gets added to the agenda of a cross-functional meeting that gets rescheduled twice and then produces a decision to form a working group.

Meanwhile the model sits in staging.

The IT/OT divide gets talked about as a technical challenge, a matter of protocols and network segmentation and data formats. Those things are real. But the deeper divide is organizational. Two teams, built for different purposes, measured on different outcomes, reporting to different leaders, looking at the same plant and seeing completely different problems. IT sees a security perimeter to protect. OT sees uptime to defend. Neither is wrong. Neither is looking at the gap between them.

That gap does not close itself. It closes when someone in the organization is explicitly responsible for closing it, with the authority to make decisions across both teams and the mandate to finish what the project started.

Most industrial AI initiatives are not structured that way. The project has a data science lead and a project manager and a steering committee. It does not have an integration owner. And so the last mile, the mile that requires both teams to move toward each other, stays exactly as wide as it was on day one.

What Closing the Last Mile Actually Requires

The answer is not a better model. It is not a bigger data science team. It is not another vendor promising that this time the integration will be straightforward.

It is infrastructure. Built deliberately, before the model needs it, designed for the environment it will actually run in.

That means starting with connectivity that meets the plant where it is, not where the vendor deck imagines it to be. Real plants run Modbus, OPC-UA, Siemens S7, proprietary historian formats, and protocols that were old before most current software engineers started their careers. The integration layer has to speak all of it, fluently, without requiring the OT team to replace equipment that is working perfectly and will continue working perfectly for another decade.

It means edge execution that does not depend on the cloud. A prediction that requires a round trip to a cloud inference endpoint is a prediction that fails the moment the network hiccups, which in a manufacturing environment is not a rare event. Intelligence needs to run close to the equipment it is monitoring, locally, with enough resilience to keep functioning when connectivity is degraded and enough security to satisfy the IT team that approved it onto the network.

It means deployment infrastructure that OT teams can actually own. The data scientist who trained the model will not be available at 2 a.m. on a Saturday. The update that fixes the drift in the anomaly detector cannot wait for a change request to clear a two-week approval queue. The people running the plant need to be able to deploy, update, monitor, and roll back AI systems through tooling that respects their domain knowledge without demanding software development skills they were never hired to have.

And it means governance that scales across facilities from the beginning. One plant is a pilot. Twelve plants is a program. The infrastructure that works for one site needs to work for all of them, with consistent versioning, auditable change history, role-based access, and the ability to push a validated update across a fleet without touching each device individually. Organizations that build for one site and retrofit for scale spend years rebuilding what they should have built once.

This is what the proposal compressed into a single box on a slide. Not one problem. Four interconnected ones, each of which can stop a deployment on its own, all of which need to be solved together before the model delivers anything.

The Mile Is Closable

The last mile problem in industrial AI is not a technology problem waiting for a breakthrough. The technology exists. The manufacturers still stuck in pilot purgatory cannot blame the tools.

It is a prioritization problem. A scoping problem. A decision, made early in every project, about what the work actually is and what it will take to finish it.

The manufacturers generating real operational value from AI today made a different decision. They treated integration as the foundation, not the footnote. They gave the last mile the budget it deserved, the ownership it required, and the infrastructure it needed to hold. And then they built models on top of that foundation and watched them actually run.

That is the sequence. Infrastructure first. Intelligence on top of it. Not the other way around.

How to Stop Silent Pipeline Failures From Swallowing Your IIoT Data

2026-03-05T00:00:00Z

Somewhere in your IIoT pipeline, a message just failed. You don't know which one. You don't know when. And unless you have a Dead Letter Queue, you never will.

In industrial environments, failure is not the exception. It is the contract. Networks partition. APIs rate-limit. A sensor alert fires at the wrong moment and vanishes without a trace. And unlike consumer applications, missed messages in manufacturing have a real cost.

That cost is invisible by default. No error surface. No audit trail. Just data that was there and then wasn't. FlowFuse changes that. It gives your IIoT pipelines the production-grade tooling they need to handle failure the right way: catch it, retry it, and preserve everything that couldn't be recovered so you can act on it later.

This guide shows you how to build exactly that. You will walk away with a production-ready pattern for catching failed messages, retrying them with exponential backoff, and routing the unrecoverable ones into a Dead Letter Queue where they can be inspected, replayed, or discarded on your terms.

What Is a Dead Letter Queue?

A Dead Letter Queue is a holding area for messages that could not be delivered. When a message fails processing and has no path forward, it gets routed to the DLQ instead of being dropped or causing your flow to crash.

A message ends up in a DLQ for four reasons. It exceeded the maximum number of retry attempts. It is malformed and cannot be parsed. The target system is permanently unavailable. Or a business rule explicitly rejected it.

The value of a DLQ is not just storage. It is observability. Every failed message arrives with its full payload, error reason, retry history, and timestamps intact. You know exactly what failed, when it failed, and how many times it was attempted before giving up. That information is what makes recovery possible.

Without a DLQ, failed messages disappear silently. With one, failure becomes something you can inspect, act on, and fix.

The Retry Pattern: Exponential Backoff

Before a message earns its place in the DLQ, you should try, and try again. But naive retries are dangerous. Hammering a failing service every 100ms does not give it time to recover. It makes things worse for everyone.

The industry standard is exponential backoff with jitter:

delay = min(base * 2^attempt, max_delay) + random_jitter

Attempt	Base Delay	With Jitter (approx.)
1	1s	1.2s
2	2s	2.5s
3	4s	4.1s
4	8s	8.9s
5	—	→ DLQ

The jitter prevents the thundering herd problem, where every failed client retries at exactly the same moment and overloads the service all over again.

Building It

In this section, we'll build this pattern in FlowFuse step by step.

FlowFuse is the Industrial Application Platform that connects any machine or system, collects data across any protocol, and lets you act on it at production scale, with enterprise features like role-based access control, centralized device management, audit logging, and team collaboration built in. It also includes FlowFuse Tables, a built-in database service that gives all your instances a single shared DLQ, so every failed message across your entire fleet lands in one place, visible and queryable from anywhere. Contact us to get started.

The architecture has five components:

Retry state initializer
Catch node for centralized error handling
Retry manager with exponential backoff
Delay node for controlled retries
Dead Letter Queue backed by FlowFuse Tables

Here's how they connect:

flowchart TD
    A[Input] --> B[Process]
    B --> C[Success Handler]
    B -->|on error| D[Retry Manager]
    D -->|within max retries| E[Delay]
    E --> B
    D -->|max retries exceeded| F[Dead Letter Queue]
    linkStyle default stroke:#4F46E5,stroke-width:2px
    style A fill:#ffffff,color:#4B5563,stroke:#4F46E5
    style B fill:#ffffff,color:#4B5563,stroke:#4F46E5
    style C fill:#ffffff,color:#4B5563,stroke:#4F46E5
    style D fill:#ffffff,color:#4B5563,stroke:#4F46E5
    style E fill:#ffffff,color:#4B5563,stroke:#4F46E5
    style F fill:#ffffff,color:#4B5563,stroke:#4F46E5

Every step below maps directly to one part of that diagram. Follow it in order.

Step 1: Initialize Retry State

This function node runs once when a fresh message enters the pipeline. It attaches retry metadata to msg so every downstream node knows where the message stands.

Drag a function node onto the canvas.
Double-click it to open its settings.
In the Name field, enter Init Retry State.
In the Function tab, paste the following code:

msg._originalPayload = RED.util.cloneMessage(msg.payload);

if (!msg._retry) {
    msg._retry = {
        attempts: 0,
        maxAttempts: 5,
        lastError: null,
        originalTimestamp: new Date().toISOString(),
        topic: msg.topic
    };
}

return msg;

Click Done.

Two things are happening here worth noting. First, msg._originalPayload saves a deep clone of the original payload using RED.util.cloneMessage before anything touches it. A plain assignment (= msg.payload) would only copy a reference. If a downstream node mutates the object in place, the saved copy changes too. cloneMessage ensures the DLQ always holds the payload exactly as it arrived. Some nodes, like the HTTP Request node, also overwrite msg.payload with their response body, so this clone is what gets stored in the DLQ later. Second, the if (!msg._retry) check ensures initialization only runs on a fresh message. When the retry loop sends the message back through, this block is skipped entirely and the existing retry state is preserved. The underscore prefix on msg._retry also protects it from being overwritten by processing nodes.

Step 2: Add a Catch Node

The catch node monitors your processing nodes and intercepts any message that causes an error, routing it to the retry logic instead of letting it disappear.

Scoping it to All nodes is tempting but dangerous. If any node in the retry infrastructure itself throws, for example the Retry Manager calling node.error(), the catch node will intercept it and feed it back into the retry loop, creating an infinite loop. Scoping it explicitly to your processing nodes prevents this.

Drag a catch node onto the canvas.
Double-click it to open its settings.
In the Name field, enter Catch Errors.
Set Catch errors from to Selected nodes.
Select only the nodes where real failures can occur. In practice, these are the nodes that talk to the outside world: MQTT nodes, HTTP request nodes, database nodes, WebSocket nodes, or anything that reaches beyond the flow itself. Taking the example flow provided at the end of this guide, that means selecting the HTTP Request node and the Check Response function node.
Click Done.

Next, add a normalization step between the catch node and the retry manager. Built-in nodes sometimes attach msg.error as an object rather than a string, which causes problems downstream. This function node converts it to a consistent string format.

Drag a function node onto the canvas.
Double-click it to open its settings.
In the Name field, enter Normalize Error.
In the Function tab, paste:

msg.retry = msg._retry;

if (typeof msg.error === 'object') {
    msg.error = msg.error.message || JSON.stringify(msg.error);
}

msg.error = msg.error || 'Processing failed';
return msg;

Click Done.
Wire the catch node output to the Normalize Error input.

Step 3: Add the Retry Manager

This is the decision node. It increments the attempt count, calculates the backoff delay, and routes the message either back into the pipeline for another try or forward to the DLQ if retries are exhausted.

Drag a function node onto the canvas.
Double-click it to open its settings.
In the Name field, enter Retry Manager.
Go to the Setup tab and set Outputs to 2. This gives the node two output ports, one for retrying and one for the DLQ.
Go to the Function tab and paste:

const MAX_ATTEMPTS = msg.retry.maxAttempts || 5;
const BASE_DELAY_MS = 1000;
const MAX_DELAY_MS = 30000;

msg.retry.attempts += 1;
msg.retry.lastError = msg.error || 'Unknown error';
msg.retry.lastAttemptAt = new Date().toISOString();

// keep _retry in sync
msg._retry = msg.retry;

if (msg.retry.attempts >= MAX_ATTEMPTS) {
    msg.retry.exhausted = true;
    msg.dlq = {
        reason: 'Max retries exceeded',
        attempts: msg.retry.attempts,
        lastError: msg.retry.lastError,
        deadAt: new Date().toISOString()
    };
    return [null, msg];
}

const exponential = BASE_DELAY_MS * Math.pow(2, msg.retry.attempts - 1);
const jitter = Math.random() * 1000;
const delay = Math.min(exponential + jitter, MAX_DELAY_MS);

msg.delay = Math.round(delay);

node.status({
    fill: 'yellow',
    shape: 'ring',
    text: `Retry ${msg.retry.attempts}/${MAX_ATTEMPTS} in ${Math.round(delay / 1000)}s`
});

return [msg, null];

Click Done.
Wire the Normalize Error output to the Retry Manager input.

return [msg, null] sends the message out of Output 1 (retry path). return [null, msg] sends it out of Output 2 (DLQ path). No switch node is needed. The routing is built into the return statement.

Step 4: Add the Delay Node

The delay node holds the message for the calculated backoff period before it re-enters the pipeline. Without this, retries fire instantly and you are hammering an already-struggling service.

Drag a delay node onto the canvas.
Double-click it to open its settings.
In the Name field, enter Backoff Delay.
Set Action to Delay each message.
Set For to Override delay with msg.delay. This tells the node to use the backoff value the Retry Manager calculated rather than a fixed duration.
Click Done.
Wire Retry Manager Output 1 to Backoff Delay input.

Each pass through the loop, the delay gets longer. Roughly 1 second on the first retry, 2 seconds on the second, 4 on the third, and so on. When the Retry Manager decides retries are exhausted, it stops sending to Output 1 entirely and routes to Output 2 instead, ending the loop.

Wire Backoff Delay output to your processing node input. This completes the retry loop.

Step 5: Set Up the DLQ Handler

When a message reaches this stage, retries are finished. The goal now is to preserve everything: the original payload, the error reason, how many attempts were made, and the timestamp. That context is what makes later recovery possible. Without a persistent store, that context disappears the moment the flow restarts, the device reboots, or the pipeline moves on to the next message. And in a multi-instance deployment, you need a store that is accessible across every instance in your fleet, not just the device the failure happened on.

FlowFuse Tables gives you exactly that: a managed PostgreSQL database that connects directly to your flows with no credentials to configure and no external infrastructure to manage, making it the right storage layer for a production DLQ.

Note: FlowFuse Tables requires an Enterprise plan.

5a: Create the DLQ Table

In FlowFuse, go to Team Settings and enable the Tables feature for your team.
Once enabled, drag a Query node from the FlowFuse category onto the canvas.
The Query node is pre-configured to connect to your FlowFuse-managed database automatically. No credentials needed.
Paste the following into the Query field:

CREATE TABLE IF NOT EXISTS "dlq" (
  "id" TEXT PRIMARY KEY,
  "topic" TEXT,
  "payload" TEXT,
  "attempts" INTEGER,
  "last_error" TEXT,
  "captured_at" TEXT
)

Connect an Inject node set to run once on deploy to the Query node input.
Click Done and deploy.

Tip: If you prefer, you can also create the table directly from the Tables section in the FlowFuse navigation without writing any SQL.

5b: Build the Insert Flow

Drag a change node onto the canvas and name it Build DLQ Params.
Add the following rules:

Action	Target	Value type	Value
Set	`msg.queryParameters`	JSON	`{}`
Set	`msg.queryParameters.id`	msg	`_msgid`
Set	`msg.queryParameters.topic`	msg	`retry.topic`
Set	`msg.queryParameters.payload`	JSONata	`$string(_originalPayload)`
Set	`msg.queryParameters.attempts`	msg	`retry.attempts`
Set	`msg.queryParameters.last_error`	msg	`retry.lastError`
Set	`msg.queryParameters.captured_at`	JSONata	`$now()`

Drag a Query node from the FlowFuse category onto the canvas and name it Insert DLQ Record.
Paste the following SQL:

INSERT INTO "dlq" ("id", "topic", "payload", "attempts", "last_error", "captured_at")
VALUES ($id, $topic, $payload, $attempts, $last_error, $captured_at)
ON CONFLICT ("id") DO UPDATE SET
  "attempts" = EXCLUDED."attempts",
  "last_error" = EXCLUDED."last_error",
  "captured_at" = EXCLUDED."captured_at"

Wire Retry Manager Output 2 to Build DLQ Params, then Build DLQ Params to Insert DLQ Record.

ON CONFLICT DO UPDATE ensures a message that appears multiple times does not create duplicate rows. It updates cleanly on the same id.

Putting It All Together: Simulation

The best way to understand the pattern is to watch it work. This simulation models a temperature sensor publishing readings to an HTTP API every 5 seconds. The mock API is deliberately configured to fail 80% of the time so you can watch the full cycle in action: messages attempting delivery, retrying with increasing delays, and after 5 failed attempts landing permanently in FlowFuse Tables.

Import the flow below directly into FlowFuse. It contains everything: the sensor data simulator, the mock API, the retry logic, the DLQ handler, and a query button to inspect what landed in the database.

Note: In the simulation, the retry state initialization from Step 1 is folded directly into the Simulate Reading function node rather than existing as a separate node. In a real deployment you would keep them separate as described in the tutorial.

Closing Thoughts

Every message your system drops was someone's data. A sensor reading that never made it. A transaction that silently disappeared. An event that the downstream system never knew existed. In most IIoT deployments these failures are invisible. No record, no alert, no way to recover what was lost.

That is the problem this pattern solves.

A Dead Letter Queue does not make your system more reliable. Reliability comes from good infrastructure, careful design, and redundancy. What a DLQ gives you is honesty. An honest record of every message that could not be delivered, with enough context to understand why, and enough structure to do something about it.

You deploy it once and it works quietly in the background until the moment you need it.

And you will need it. Not because your flows are poorly built, but because distributed systems fail. APIs go down. Networks drop. Services timeout at the worst possible moment. The question has never been whether that happens. It is whether you are ready when it does.

Now you are.

The Bus Factor Problem in Integration Systems

2026-03-02T00:00:00Z

The bus factor is a simple idea. If one person leaves your team, how much breaks? If the answer is "a lot," your bus factor is one. Most integration systems have a bus factor of one.

It's not because teams are sloppy. Integration work just tends to accumulate in corners. Systems get built quickly to solve real problems, and the person who builds them naturally becomes the person who understands them. They know why the retry logic is set the way it is, why data gets reshaped at that particular step, why two systems connect the way they do. That knowledge rarely makes it into documentation because there's always something more urgent to work on.

Time passes. The system keeps running. Nobody questions it. Then that person moves to another team, takes a two-week vacation, or just gets sick at the wrong moment, and suddenly a routine maintenance task turns into a two-day investigation.

The problem isn't unique to integration systems, but it hits them harder. Integration logic lives between other systems, it's rarely the focus of code reviews, and it's usually the last thing anyone thinks to document. Knowledge concentrates fast and spreads slowly.

The good news is it's a solvable problem. The first step is knowing you have it. Before you read further, take two minutes to assess where your team stands today.

Now you know where you stand. The rest of this article explains how integration systems end up here, why documentation alone never fixes it, and what it actually takes to change it.

Why Integration Systems Are Especially Vulnerable

Most engineering work leaves a trail. Pull requests, code reviews, commit messages, test cases. Software teams have spent decades building habits and tooling that make their work legible to others. Integration work tends to skip all of that.

A flow gets built by one person to solve a specific problem: connect a PLC to a database, route sensor data to a dashboard, translate one protocol into another. It works, it gets deployed, and then it runs quietly in the background while everyone moves on. The person who built it moves on too, to the next urgent problem, the next system, the next deadline.

The people doing this work aren't cutting corners. They're IT engineers, automation specialists, OT technicians, and process engineers working under real time pressure. Their job is to get systems talking, not to produce documentation for a future colleague they've never met. In most organizations, nobody has ever defined what good engineering practice looks like for integration work, so the default is to ship and move on.

There's a structural problem compounding this. Integration flows don't belong cleanly to any one team. They're not part of the application codebase. They're not clearly IT's responsibility or OT's. They live in their own runtime, often on edge devices or gateways distributed across a facility, and they connect systems that different teams own. Nobody has obvious ownership, so nobody feels obvious accountability for making the knowledge transferable.

The result is a system that works fine as long as the right person is available. The moment they're not, you find out just how much was living only in their head.

What Happens When the Knowledge Walks Out the Door

The immediate impact is visible: something breaks and nobody knows how to fix it. But the slower damage is harder to measure.

Teams start treating their own integration flows as black boxes. They're afraid to touch them because they don't understand them well enough to know what will break. New team members spend weeks or months just trying to figure out what exists and what it does. Simple changes take longer than they should because every modification requires archaeology first.

Over time, organizations start building new flows around existing ones instead of modifying them, because modifying them feels risky. The system gets more complex. More people build more flows that only they understand. The bus factor gets worse, not better.

In manufacturing environments, this isn't just a productivity problem. Integration flows connect real machines, real production lines, and real safety systems. A flow that nobody understands is a flow that nobody can safely change, debug, or improve. That's a real operational risk, and it compounds with scale.

The Documentation Problem

The obvious answer is: write better documentation. And yes, that's true. But saying "just document it" has never actually solved the problem, and it's worth understanding why.

Documentation is a separate task. That's the core issue. When an engineer finishes building a flow, the work feels done. The flow works. Sitting down to document it means context-switching into a different mode of thinking, opening a different tool, and writing for an audience that doesn't exist yet. Most of the time, that just doesn't happen.

Even when documentation does exist, it goes stale. A flow gets modified. The documentation doesn't. Six months later, the documentation describes something that no longer exists, which is sometimes worse than no documentation at all.

The teams that actually maintain good documentation tend to do it because it's built into how they work, not because they decided to be more disciplined. The process makes it easy and the tooling keeps it close to the work.

How FlowFuse Approaches the Problem

FlowFuse is an industrial data platform built on Node-RED. It's designed for teams who need to connect machines, systems, and data across IT and OT environments at scale, with the governance and reliability that production environments require.

What makes it relevant to the bus factor problem is where FlowFuse has chosen to put the intelligence.

FlowFuse Expert is an AI assistant built directly into the Node-RED editor inside FlowFuse. It is not a generic AI. It is specifically trained on FlowFuse's own documentation, blog posts, and resources, which means it understands the platform, its nodes, and the industrial context it operates in. When you ask it a question, you are not talking to a general-purpose chatbot - you are talking to something that knows what a Function node is, what an MQTT broker does, and what your specific flow is actually doing.

That last part matters. FlowFuse Expert can take your flow as context. Select a flow, add it to the conversation, and ask plain-language questions about it - what does this flow do, why is this node outputting a number instead of a string, where could this logic fail. It can also take your palette as context, so it knows which nodes you actually have installed and can give advice based on what is available to you rather than what exists in theory.

For a team inheriting flows they didn't build, this changes the equation significantly. Instead of spending days reverse-engineering what a flow does, a new team member can get a working explanation in seconds and ask follow-up questions in plain language.

The video above shows just one example - asking questions about a selected flow. FlowFuse Expert goes much further than that. You can query your live operational data through MCP tools in Insights mode, get inline code completions as you type inside Function nodes, generate CSS and HTML for FlowFuse Dashboard templates, build Function nodes from plain-language descriptions, and get intelligent suggestions for which node to add next. The more you use it, the less the work depends on any single person remembering how something was built.

Beyond the chat interface, FlowFuse Expert also brings AI directly into Node-RED through Node-RED Embedded AI. This is AI that works where you already are - inside node editors and on the canvas - without needing to open a separate panel. It can write Function node code from a plain-language description, generate CSS and HTML for FlowFuse Dashboard templates, suggest which node to add next in a flow, and produce realistic test data to validate logic. It handles the JavaScript, the regex, the CSS, the JSON - so engineers can focus on the domain knowledge that actually requires a human.

Reducing the Bus Factor in Practice

FlowFuse Expert is one piece of a broader approach FlowFuse takes to making integration knowledge more durable.

The platform includes version control for flows, so changes are tracked and teams can roll back when something goes wrong without needing to call the person who made the change. It supports team collaboration on a single Node-RED instance, which means flows don't have to be the work of one person in isolation. DevOps pipelines let teams move flows through development, staging, and production environments with proper governance rather than deploying directly to production from someone's laptop.

Put together, these features don't just reduce the bus factor. They change the conditions that create it. When flows are version-controlled, when multiple people work on them together, when an AI can explain them on demand, the concentration of knowledge in one person's head becomes much harder to sustain accidentally.

The bus factor never fully goes away. Key people will always carry important knowledge. But there's a meaningful difference between a team where one person is the only one who understands something, and a team where one person understands it best but the system can explain itself well enough that others can follow, contribute, and take over.

The goal isn't to make everyone interchangeable. It's to make sure that when someone is out, the work can continue.

Closing Thought

Integration systems are the connective tissue of industrial operations. When they're well understood and well documented, they're an asset. When they're opaque and person-dependent, they're a liability that just hasn't failed yet.

The bus factor problem doesn't go away on its own. Knowledge concentrates by default, distributing it requires the right conditions, the right process, and tooling that makes the good behavior easier than the bad. That's exactly what FlowFuse is built to do.

Edge AI Is 80% Plumbing, 20% Intelligence

2026-02-27T00:00:00Z

The model is the easy part. I know that is not what you were told. But it is true, and somewhere between your third deployment and your first production fire, you will stop arguing with it.

Edge AI is infrastructure work. Unglamorous, load-bearing, invisible-until-it-breaks infrastructure work with a neural network sitting on top of it like a trophy on a foundation nobody inspected. The 20% is the trophy. The 80% is everything underneath it.

Most Edge AI projects do not fail because the model was wrong. They fail because nobody budgeted for the plumbing, nobody respected the plumbing, and everybody assumed the plumbing would figure itself out.

It does not figure itself out.

Here is what I have watched happen, repeatedly, across manufacturing facilities that were serious about Edge AI, staffed it well, and still could not get past the pilot: the model worked. The demo worked. The business case was real. And then the project stalled. Not because the technology failed, but because the infrastructure the technology needed to survive in an actual plant was never built.

McKinsey put a number on this: 84% of manufacturers pursuing IIoT were stuck in pilot mode. More than a quarter for over two years. In the years since, the models have gotten better, the hardware has gotten cheaper, and the percentage has not moved. That tells you the model was never the constraint.

What is the constraint? Data your system can actually trust. Updates that reach hardware you cannot physically touch. Security that was designed in, not bolted on. Monitoring that catches a drifting model before it causes a quality escape. And an operating model that answers, before something breaks at 3 a.m., who owns this: IT or OT.

None of that is in the vendor's proposal. All of it determines whether the vendor's proposal is worth anything.

The factory your AI vendor designed their solution for has clean data, modern equipment, stable connectivity, and IT and OT teams working from a shared operating model. That factory is a useful abstraction. It is not your plant.

Your plant has PLCs from three different vendors. A historian configured in 2009 that your OT team will not let anyone touch because the last time someone touched it, production stopped for four hours. Legacy equipment on the shop floor with no digital interface, because when it was commissioned, "digital interface" was not a specification category that existed. Sensor data in proprietary formats. Timestamps that do not align across systems. Protocols that your IT team has never heard of and your OT team has been working around for a decade.

Before a single inference runs at the edge, someone has to collect and normalize data from all of that. Protocol translation. Context tagging. Historian integration. That work is months of engineering. It is almost never scoped. And when it surfaces, it is always described as a surprise, even though everyone in the plant knew it was there.

This is why Node-RED matters in manufacturing in a way that nothing else quite does. It was built for exactly this problem: connecting things that were never designed to talk to each other. Modbus, OPC-UA, Siemens S7, MQTT. Thousands of community-built nodes covering the full reality of what is on the factory floor, not the idealized version. Your OT engineers, the people who actually understand the equipment, can build integration flows without waiting for scarce software developers. The domain knowledge that has been locked in people's heads for years can finally become logic that runs.

But Node-RED alone is a development tool. Running it in production, across a fleet of edge devices in multiple facilities, is a different problem entirely. And that gap, between a working flow on one machine and a reliable, managed, auditable deployment across your entire operation, is precisely where most IIoT projects quietly fall apart.

FlowFuse was built to close that gap. Both gaps, actually. Because the problem in manufacturing is not just that the infrastructure is hard. It is that building the intelligence on top of it is also harder than the demos suggest, and most teams are doing both with the wrong tools.

The OT engineer who has spent fifteen years learning one plant's quirks is not going to become a software developer. That was never a realistic ask. But they understand the equipment better than anyone who might be hired to build integrations for it, and if the tooling respects that knowledge, they can do the integration work themselves. Node-RED was the first tool in this space that actually respected that. Not because it simplified the problem, but because it let domain expertise drive the solution.

FlowFuse starts from that same premise and takes it further, into the territory Node-RED was never designed to handle alone.

Take what happens when you want to put a model in production. You have a data scientist who trained something useful — a predictive maintenance model, an anomaly detector, a vision system for defect classification. The model is accurate. It works on their laptop. And then there is the question of where it actually lives, how OT can interact with it, what happens when it needs to be retrained, and who owns it when something goes wrong at 2 a.m. on a Saturday.

In most deployments, nobody has a good answer to any of those questions. The model ends up in a container somewhere that only the data scientist understands, connected to the plant by a fragile handshake that no one wants to touch. The OT team treats it like a black box because it is a black box.

FlowFuse's ONNX nodes change that by putting the model where OT engineers already work. You train, you export, you deploy it as a node in a flow — alongside the Modbus reads, the historian writes, the MQTT publishes. The inference runs locally, on the edge device, no cloud round trip, no latency the line cannot afford. When we deployed a motor anomaly detector this way, the thing that changed was not the model's accuracy. It was that the people running the line could see what the model was looking at, wire its output to the control logic themselves, and update it through the same pipeline they use for everything else. That is not a convenience improvement. That is the difference between a model that gets maintained and a model that gets abandoned.

The same logic applies to the FlowFuse Expert. OT engineers are not waiting for JavaScript fluency. They know the equipment; they know what they need the flow to do; they just get slowed down in the translation between that knowledge and working code. The Expert handles the boilerplate — autocompletes flows, generates function node logic from a plain-language description, explains what a set of nodes does in terms that make sense. It is not a general-purpose chatbot bolted onto an IDE. It was trained on Node-RED and FlowFuse specifically, which means it gives answers that work in industrial contexts rather than answers that look plausible until you try to run them. For teams where the backlog of integration work is longer than the list of people who can do it, that matters.

And then there is the part that breaks most programs before they get to ask any of these questions: operating at fleet scale.

One Node-RED instance, on one machine, managed by the person who set it up, is survivable. Ten devices across two facilities, or a hundred devices across a global operation, is a different problem. You need to push an update to a device on a production line in a facility in another country, and you need to know it landed correctly, and you need to be able to roll it back in under five minutes if it did not. You need to prove, to an auditor or a regulator, exactly which software version was running on which device at which moment. You need to be sure that when a device is decommissioned, its credentials are gone and its configuration is immediately invalidated.

None of that is possible with stock Node-RED. All of it is table stakes in a real manufacturing environment.

FlowFuse's snapshot-based deployments give you a tested, versioned, rollback-capable pipeline for every device in your fleet. Staged rollouts let you push to a test group first, validate behavior in real conditions, and then promote to production — the same discipline software engineering spent twenty years learning, now available to the people managing industrial edge infrastructure. Role-based access control, SSO integration, and a complete audit trail are in the architecture, not added later when someone asks for them. In automotive, pharmaceutical, and food manufacturing, where you need to prove exactly which software version was running on which device at which moment, that audit trail is not a reporting feature. It is compliance infrastructure.

The manufacturers who escape pilot purgatory are not the ones with better models. They are the ones who decided, before the model was ever deployed, that the infrastructure was the product. The model is a feature. What makes the feature reliable, observable, and maintainable — across a fleet of heterogeneous devices, in real plants, over years — is everything underneath it.

FlowFuse is that infrastructure. Not because it is the most technically sophisticated platform available, but because it was built for the actual factory floor: the PLCs from three vendors, the historian nobody wants to touch, the protocols IT has never heard of, the OT engineers who know more about this equipment than anyone who might be hired to replace them. It meets the plant where it is. That is a harder design constraint than building for the idealized version.

The conference circuit will keep celebrating the 20%. The benchmark results, the accuracy curves, the inference speeds. That work matters. But it is not what separates the manufacturers generating real operational value from the ones still running the same pilot they started two years ago.

What separates them is the plumbing.

Build it on something that understands where you are starting from.

If you are running Node-RED in production today, or trying to, FlowFuse is the operational layer that makes it scale. Device management, snapshot deployments, DevOps pipelines, ONNX-based AI inference, and the FlowFuse Expert to build faster, all built specifically for industrial environments. Start a 14-day free trial today. No abstractions. No greenfield assumptions. Just the infrastructure your plant actually needs.

How to Build an MQTT-to-InfluxDB Data Pipeline (2026)

2026-02-26T00:00:00Z

An MQTT to InfluxDB is one of the most common and most critical pipelines in IIoT. Every timestamped telemetry event that drives decisions on the floor needs to land somewhere it can be queried, trended, and acted on.

The typical approach is a custom Python script that subscribes to the broker, parses the payload, and writes to InfluxDB. It works until a sensor changes its payload format, or the script quietly dies over a weekend and nobody notices until Monday. Now you're debugging a process nobody else fully understands, with no visibility into what failed or when. Others stitch together multiple tools, each with its own config, its own failure modes, and its own logs to dig through at 2am. The complexity ends up hidden in places that are hard to see, hard to debug, and hard to hand off.

This article takes a different approach. Using FlowFuse (the enterprise platform built on Node-RED), you'll build the entire pipeline as a visual flow covering MQTT subscription, payload transformation, and InfluxDB write. Every step is visible, editable, and easy to hand off.

TL;DR

What: Build an MQTT-to-InfluxDB pipeline that subscribes to a broker, transforms the payload, and writes time-series data to InfluxDB.
How: Three nodes in FlowFuse: MQTT in, change node for transformation, and InfluxDB out. No custom scripts or glue code.
Why FlowFuse: Every step is visual, editable, and easy to hand off. When something breaks, you know exactly where to look.

Prerequisites

Before you start, make sure you have the following in place.

A running FlowFuse instance. If you don't have one yet, sign up to get started.
An MQTT broker. FlowFuse Pro and Enterprise include a built-in broker, and the MQTT nodes configure themselves automatically. If you are using an external broker, keep your host, port, and credentials handy.
A running InfluxDB instance, either local or on InfluxDB Cloud. Keep your URL, token, organization, and bucket name handy.

Building the Pipeline

The flow has three stages. An MQTT in node subscribes to your broker and receives incoming sensor payloads. A change node transforms that payload into the structure InfluxDB expects. An InfluxDB out node takes that structured data and writes it to your bucket. That's the entire pipeline. Let's build it.

Step 1: Install the InfluxDB Node

Node-RED does not include an InfluxDB node out of the box, so you will need to install it first.

Open the Node-RED editor in your FlowFuse instance.
Click the main menu in the top right corner and select Manage Palette.
Go to the Install tab and search for node-red-contrib-influxdb.
Click Install. Once complete, the InfluxDB nodes will appear in your palette on the left side.

Step 2: Configure the MQTT In Node

Drag an MQTT in node onto the canvas and double-click it to open its settings. Click the pencil icon next to the Server field to add a new broker connection.

Enter your broker host in the Server field and set the Port.
Select MQTT 3.1.1 as the protocol version.
Leave the Client ID blank to let Node-RED generate one automatically.
The keepalive is 60 seconds by default, so there’s no need to change it.
Check Automatically unsubscribe when disconnecting.

Switch to the Security tab and enter your broker username and password.
Click Add to save the broker configuration.

If you are on FlowFuse Pro or Enterprise, the built-in broker details will already be picked up by the node and you can skip the above.

Once the broker is configured:

Set the Topic to acme-motors/detroit/welding/line-1/robot-3/temperature.
Set QoS to 2 to minimize message loss and reduce duplicates between the broker and Node-RED. For true end-to-end de-duplication, add an idempotency strategy (for example, a unique key or timestamp handling) before writing to InfluxDB.
Give the node the name robot 3 temperature and click Done.

Step 3: Transform the Payload with a Change Node

When the MQTT in node receives a message, msg.payload will look like this:

{
  "timestamp": 1738830735000,
  "value": 187.6,
  "unit": "celsius",
  "sensor_id": "temp-robot-3",
  "status": "normal"
}

The InfluxDB out node does not accept this structure directly. With node-red-contrib-influxdb, the easiest pattern is to pass msg.payload as an array, the first containing the fields to write and the second containing the tags. In InfluxDB, fields are the values you aggregate and query over, while tags are metadata used mainly for filtering and grouping. Getting this split right matters because you cannot aggregate or perform math on tags, only on fields.

Drag a change node onto the canvas and connect it to the MQTT in node.
Double-click it to open its settings and add the following rules:
- Set msg.measurement to the string value temperature. If your payload already contains the measurement name, you can set msg.measurement dynamically from msg.payload.measurement instead, making the flow reusable across multiple sensors without any changes. Otherwise, you can configure the measurement name directly in the InfluxDB out node.
- Set msg.payload to the JSONata expression:

     [{"value": payload.value, "status": payload.status, "time": payload.timestamp}, {"sensor_id": payload.sensor_id, "unit": payload.unit}]

Give the node the name transform for influxdb and click Done.

Step 4: Configure the InfluxDB Out Node

Drag an InfluxDB out node onto the canvas and connect it to the change node.
Double-click it to open its settings and click the pencil icon next to the Server field to add a new InfluxDB connection.
- Set Version to 2.0.
- Enter your InfluxDB instance URL.
- Enter your API token.
Click Add to save the connection.

Set the Organization to your organization name.
Set the Bucket to the bucket you want to write data into.
Leave the Measurement field blank since we are passing it via msg.measurement from the change node. If you prefer to hardcode it, enter temperature here.
Give the node the name write to influxdb and click Done.

Step 5: Deploy and Test

With all three nodes connected, click the Deploy button in the top right corner of the Node-RED editor. Once deployed, the flow will immediately start listening for messages on the topic you configured.

As your sensor publishes readings, open your InfluxDB instance and navigate to Data Explorer. Select your bucket, filter by measurement, and run the query. You should see the values and tags coming in from the pipeline.

If no data appears, open the Node-RED debug panel and check for any error messages on the InfluxDB out node. The most common issues are an incorrect API token, a mismatched organization name, or a bucket that does not exist yet in InfluxDB.

Conclusion

Most MQTT-to-InfluxDB pipelines don't fail because the technology is wrong. They fail because the implementation is invisible: a script running somewhere, maintained by someone, that nobody else fully understands until it stops working.

What you've built here flips that. Three nodes, one canvas, zero ambiguity about where data comes from, how it's shaped, and where it lands. When something breaks, and in IIoT, something always eventually breaks, you're not grepping through logs or reverse-engineering a process. You're looking at a flow that tells you exactly what happened and where.

From here, the pipeline is yours to grow. Handle multiple sensors by parameterizing the topic and measurement. Add a catch node so malformed payloads get logged instead of silently dropped. Connect your InfluxDB bucket to a FlowFuse dashboard and put live telemetry on the floor where operators can actually see it.

The three nodes you deployed today are the foundation. Everything else is just adding to what's already visible.

Building an AI Vibration Anomaly Detector for Industrial Motors

2026-02-20T00:00:00Z

Bearing wear, shaft misalignment, and imbalance don't appear overnight. They develop over days or weeks, leaving a clear trail in vibration data long before any audible or thermal symptoms emerge. By the time a technician hears grinding or feels heat, the window for low-cost intervention has already closed.

The challenge isn't visibility: it's continuity. Manual spot-checks capture a fraction of developing faults, and only if the timing is lucky. What's needed is something that watches constantly, understands what normal looks like, and flags the moment something shifts.

This guide walks through building exactly that: a custom AI model that learns the healthy vibration signature of your motor, detects deviations in real time, and integrates directly into Node-RED using FlowFuse with no separate ML infrastructure required.

How It Works

An accelerometer mounted on the motor captures vibration across three axes (X, Y, Z) and publishes batches of raw readings to an MQTT broker every half-second. A Node-RED flow subscribes to those readings, extracts 33 statistical features per batch (covering energy, peak forces, shape, and distribution across all three axes) and passes them to a trained autoencoder.

Why an Autoencoder?

An autoencoder is a neural network trained to compress its input and then reconstruct it. The architecture used here is:

Input (33) → Dense (16) → Dense (8) → Dense (16) → Output (33)

The bottleneck layer (8 nodes) forces the model to learn a compact representation of the input. When trained exclusively on healthy motor data, the model learns to reconstruct normal vibration patterns with very low error. When conditions change (a bearing begins to wear, alignment drifts, imbalance develops) the vibration signature shifts, reconstruction error rises, and the system flags an anomaly.

This approach is well-suited to industrial use because you almost certainly have abundant examples of normal operation, but few or no labeled examples of specific fault modes. You don't need to know what failure looks like; you only need to define what normal looks like.

Building the System

The implementation has three stages: setting up hardware to collect vibration data, training the autoencoder on normal operation, and deploying the trained model in Node-RED for real-time inference.

Part 1: Hardware and Data Requirements

This guide assumes you already have a vibration sensor publishing batches of acceleration readings across X, Y, and Z axes at regular intervals. The examples were built using an ESP32 wired to an ADXL345 accelerometer. If your hardware differs, the rest of the steps remain unchanged as long as your sensor publishes the same payload format.

Expected Payload Format

Each MQTT message contains a half-second snapshot of motor vibration. The sensor captures 256 measurements per axis and packages them into a single JSON payload:

{
  "motor_id": "motor-01",
  "ts": 1718000000000,
  "x": [0.12, 0.11, 0.13, 0.14, ...],
  "y": [0.04, 0.05, 0.04, 0.03, ...],
  "z": [0.98, 0.97, 0.99, 0.96, ...]
}

At 500 Hz sampling, 256 values represent roughly half a second of continuous vibration. This batching approach matters because it gives the AI model enough context to detect patterns: a single data point is meaningless, but 256 points reveal the behavioral signature of how the motor is actually running.

The motor_id and ts fields are ignored by the model and can be omitted or renamed without effect.

If your sensor uses different settings: The feature extraction math works regardless of sample count or sampling rate. If your sensor samples at 200 Hz and sends 128 values per batch, each window represents 640 ms instead of 500 ms; the model doesn't care about absolute timing, only the shape of the vibration signature. Aim for at least 100–200 ms of data per window; anything shorter may not carry enough signal for reliable detection.

MQTT Broker

You'll need an MQTT broker to route messages between the sensor, the training script, and Node-RED. Make sure your sensor is publishing to a consistent topic so all three can stay in sync.

Tip: If you're using FlowFuse for enterprise Node-RED, a built-in MQTT broker is available on Pro and Enterprise tiers with no external setup required. Contact us for more information.

Part 2: Training the Autoencoder

Before deploying anything in Node-RED, you need a trained model that understands what normal motor vibration looks like. This is done with a single Python script that connects to your MQTT broker, collects vibration data while the motor runs normally, then automatically trains and exports the model when you're done.

Prerequisites

System requirements: Python 3.11 or later. The steps below were tested on macOS (Apple Silicon); adapt as needed for Linux or Windows.

Create and activate a virtual environment:

python3 -m venv venv
source venv/bin/activate

Windows: Replace source venv/bin/activate with venv\Scripts\activate.

Install dependencies:

pip3 install numpy paho-mqtt torch onnx onnxruntime scikit-learn

Configuration

All setup lives in a single configuration block at the top of the script. Before running, update these variables to match your environment:

Variable	Description
`BROKER`	Hostname or IP of your MQTT broker
`PORT`	`1883` for plain MQTT, `8883` for TLS
`USERNAME`	Broker username. Leave empty `""` if not required
`PASSWORD`	Broker password. Leave empty `""` if not required
`CLIENT_ID`	Any unique string identifying this client
`TOPIC`	The MQTT topic your sensor publishes to
`MIN_WINDOWS`	Minimum samples to collect before training (default: 300)
`MIN_STD`	Minimum standard deviation floor that prevents near-constant features from skewing normalisation (default: 0.1)
`CLIP`	Hard clamp applied after normalisation to prevent extreme values (default: 5.0)
`EPOCHS`	Number of training epochs (default: 200)
`LEARNING_RATE`	Adam optimizer learning rate (default: 0.001)
`THRESHOLD_SIGMA`	Multiplier for threshold calculation: `mean + N × std` of training errors (default: 3)

Threshold tuning: The default mean + 3σ threshold is a solid starting point, but every motor environment is different. If you see too many false positives during normal operation, increase THRESHOLD_SIGMA. If faults are being missed, decrease it. You can also edit threshold.json directly after training without rerunning the script.

Collect and Train

Create a file called train_model.py and paste the following. Start the motor first, then run the script. The model needs to learn what running vibration looks like. Collecting data with the motor stopped or barely loaded will produce a model that treats idle conditions as normal and misses real anomalies.

"""
Motor Vibration Anomaly Detection: Data Collection and Training
"""

import json
import signal
import sys
import numpy as np
import torch
import torch.nn as nn
import onnx
import onnxruntime as ort
from onnx import numpy_helper, TensorProto, helper
import paho.mqtt.client as mqtt
from paho.mqtt.client import CallbackAPIVersion

# ── Configuration ────────────────────────────────────────────────────────────
BROKER         = "broker.example.com"            # Your MQTT broker address or IP
PORT           = 1883                            # 1883 for plain MQTT, 8883 for TLS
USERNAME       = ""                              # Leave as "" if broker has no auth
PASSWORD       = ""                              # Leave as "" if broker has no auth
CLIENT_ID      = "motor-trainer-01"             # Any unique string for this client
TOPIC          = "factory/motor-01/vibration/raw" # Must match your sensor's publish topic

# ── Training parameters ───────────────────────────────────────────────────────
MIN_WINDOWS    = 300    # Minimum samples before training is allowed
MIN_STD        = 0.1    # Prevents near-constant features from exploding normalisation
CLIP           = 5.0    # Hard clip applied after normalisation
EPOCHS         = 200    # Number of training epochs
LEARNING_RATE  = 1e-3   # Adam optimiser learning rate
THRESHOLD_SIGMA = 3     # Threshold = mean + N * std of training reconstruction errors
# ─────────────────────────────────────────────────────────────────────────────

training_data = []
stop_flag = [False]

def extract_features(sig):
    """Extract 11 time-domain features from a signal array."""
    sig  = np.asarray(sig, dtype=np.float64)
    mean = np.mean(sig)
    std  = np.std(sig) + 1e-9

    rms              = np.sqrt(np.mean(sig ** 2))
    peak             = np.max(np.abs(sig))
    peak_to_peak     = np.max(sig) - np.min(sig)
    crest_factor     = peak / (rms + 1e-9)
    variance         = np.var(sig)
    std_dev          = np.std(sig)
    skewness         = np.mean(((sig - mean) / std) ** 3)
    kurtosis         = np.mean(((sig - mean) / std) ** 4) - 3
    mean_abs         = np.mean(np.abs(sig)) + 1e-9
    shape_factor     = rms / mean_abs
    impulse_factor   = peak / mean_abs
    mean_sqrt_abs    = np.mean(np.sqrt(np.abs(sig)))
    clearance_factor = peak / (mean_sqrt_abs ** 2 + 1e-9)

    return [rms, peak, peak_to_peak, crest_factor, variance,
            std_dev, skewness, kurtosis, shape_factor,
            impulse_factor, clearance_factor]

def featurize(payload):
    """Concatenate features from X, Y, Z → 33-element vector."""
    return (extract_features(payload["x"]) +
            extract_features(payload["y"]) +
            extract_features(payload["z"]))

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code == 0:
        print(f"Connected to {BROKER}")
        client.subscribe(TOPIC)
        print(f"Subscribed to {TOPIC}")
        print("Run motor normally. Press Ctrl+C when done collecting.\n")
    else:
        print(f"Connection failed: {reason_code}")

def on_message(client, userdata, msg):
    if stop_flag[0]:
        return
    try:
        payload = json.loads(msg.payload.decode())
        training_data.append(featurize(payload))
        n = len(training_data)
        print(f"  Collected {n} windows", end="\r")
    except Exception as e:
        print(f"\nError parsing message: {e}")

def train_and_export():
    N = 33
    print(f"\n\nCollected {len(training_data)} windows. Starting training...")
    X = np.array(training_data, dtype=np.float32)

    # Normalisation with minimum std floor
    mean = X.mean(axis=0)
    std  = X.std(axis=0)

    clamped = std < MIN_STD
    if clamped.any():
        print(f"  Clamping {clamped.sum()} near-constant features to std={MIN_STD}")
        std[clamped] = MIN_STD

    X_norm = np.clip((X - mean) / std, -CLIP, CLIP)
    print(f"  Normalised range: [{X_norm.min():.3f}, {X_norm.max():.3f}]")

    scaler = {"mean": mean.tolist(), "std": std.tolist(), "clip": CLIP}
    with open("scaler_params.json", "w") as f:
        json.dump(scaler, f, indent=2)
    print("  Saved scaler_params.json")

    # Autoencoder definition
    class Autoencoder(nn.Module):
        def __init__(self, n):
            super().__init__()
            self.encoder = nn.Sequential(
                nn.Linear(n, 16), nn.ReLU(),
                nn.Linear(16, 8), nn.ReLU(),
            )
            self.decoder = nn.Sequential(
                nn.Linear(8, 16), nn.ReLU(),
                nn.Linear(16, n),
            )
        def forward(self, x):
            return self.decoder(self.encoder(x))

    model   = Autoencoder(N)
    opt     = torch.optim.Adam(model.parameters(), lr=LEARNING_RATE)
    loss_fn = nn.MSELoss()
    data_t  = torch.tensor(X_norm, dtype=torch.float32)

    model.train()
    for epoch in range(1, EPOCHS + 1):
        opt.zero_grad()
        loss = loss_fn(model(data_t), data_t)
        loss.backward()
        opt.step()
        if epoch % (EPOCHS // 5) == 0:
            print(f"  Epoch {epoch}/{EPOCHS}  loss={loss.item():.6f}")

    # Calculate threshold
    model.eval()
    with torch.no_grad():
        recon  = model(data_t).numpy()
        errors = np.mean((recon - X_norm) ** 2, axis=1)
        thresh = float(errors.mean() + THRESHOLD_SIGMA * errors.std())

    with open("threshold.json", "w") as f:
        json.dump({"threshold": thresh}, f, indent=2)
    print(f"  Threshold (mean+{THRESHOLD_SIGMA}σ): {thresh:.6f}")
    print("  Saved threshold.json")

    # Export to ONNX
    # Built manually to avoid version conflicts between PyTorch and ONNX exporters
    layers   = [("encoder.0","enc0"),("encoder.2","enc2"),
                ("decoder.0","dec0"),("decoder.2","dec2")]
    has_relu = [True, True, True, False]
    inits, nodes = [], []
    cur = "features"

    for (prefix, tag), relu in zip(layers, has_relu):
        w = model.state_dict()[f"{prefix}.weight"].numpy().T.astype(np.float32)
        b = model.state_dict()[f"{prefix}.bias"].numpy().astype(np.float32)
        inits += [numpy_helper.from_array(w, name=f"w_{tag}"),
                  numpy_helper.from_array(b, name=f"b_{tag}")]
        mm = f"mm_{tag}"; add = f"add_{tag}"
        nodes += [helper.make_node("MatMul", [cur, f"w_{tag}"], [mm]),
                  helper.make_node("Add",    [mm,  f"b_{tag}"], [add])]
        cur = add
        if relu:
            r = f"relu_{tag}"
            nodes.append(helper.make_node("Relu", [cur], [r]))
            cur = r

    graph = helper.make_graph(
        nodes, "autoencoder",
        [helper.make_tensor_value_info("features", TensorProto.FLOAT, [None, N])],
        [helper.make_tensor_value_info(cur, TensorProto.FLOAT, [None, N])],
        initializer=inits,
    )
    proto = helper.make_model(graph, opset_imports=[helper.make_opsetid("", 11)])
    proto.ir_version = 7
    onnx.checker.check_model(proto)
    onnx.save(proto, "motor_autoencoder.onnx")
    print("  Exported motor_autoencoder.onnx")

    # Sanity check
    sess = ort.InferenceSession("motor_autoencoder.onnx")
    out  = sess.run(None, {"features": X_norm[:5].astype(np.float32)})[0]
    mse  = float(np.mean((out - X_norm[:5]) ** 2))
    print(f"\n  Sanity MSE (5 normal samples): {mse:.6f}  threshold: {thresh:.6f}")
    if mse < thresh:
        print("  ✓ Model correct , normal data scores below threshold.")
    else:
        print("  ⚠ Sanity MSE above threshold , collect more data and retrain.")

    print("\nDone. Copy these 3 files to your Node-RED server:")
    print("  motor_autoencoder.onnx  scaler_params.json  threshold.json")

def handle_sigint(sig, frame):
    stop_flag[0] = True
    if len(training_data) < MIN_WINDOWS:
        print(f"\n\nNeed at least {MIN_WINDOWS} windows. Restart and collect longer.")
        sys.exit(1)
    train_and_export()
    sys.exit(0)

signal.signal(signal.SIGINT, handle_sigint)

client = mqtt.Client(callback_api_version=CallbackAPIVersion.VERSION2,
                     client_id=CLIENT_ID)
client.username_pw_set(USERNAME, PASSWORD)
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()

Let it collect for 5–10 minutes (aim for 300+ windows), then press Ctrl+C once and wait. The script will train the model and export three files:

motor_autoencoder.onnx , the trained model in a portable, runtime-agnostic format
scaler_params.json , the scaling parameters used to normalise input features
threshold.json , the reconstruction error value above which a reading is flagged as anomalous

Sanity check: Watch the output at the end. ✓ Model correct means the model correctly scores normal data below the threshold. A warning means you should collect more data with the motor under its typical load and retrain.

When to Retrain

The model captures what normal looks like at the time of training. Plan to retrain after any significant change to the motor's operating conditions: a maintenance overhaul, a change in load profile, a new mounting position, or seasonal temperature shifts that affect the vibration baseline. The process is identical, run the script again with the motor under its new normal conditions, replace the three output files, and restart the Node-RED flow.

Part 3: Deploying in Node-RED

The model now knows what healthy looks like. This section builds the Node-RED flow that runs continuously, scores every incoming vibration batch in real time, and raises an alert the moment something shifts.

Installing the AI Nodes

FlowFuse provides a dedicated AI nodes package for Node-RED that includes ONNX runtime support.

Note: These nodes are only available to FlowFuse users. If you don't have an account, get started here and follow the steps to run the device agent.

Open the Node-RED editor and go to Menu → Manage Palette
Search for @flowfuse-nodes/nr-ai-nodes
Click Install

Once installed, you will see new nodes in the palette under the FlowFuse AI category. This guide uses the onnx node.

Loading the Model Files

Place your three model files in the FlowFuse Device Agent directory before building the flow:

sudo mkdir -p /opt/flowfuse-device/models
sudo cp motor_autoencoder.onnx /opt/flowfuse-device/models/
sudo cp scaler_params.json /opt/flowfuse-device/models/
sudo cp threshold.json /opt/flowfuse-device/models/

Building the Inference Flow

The flow has five stages: receive the payload, extract features, scale and prepare, run inference, and score the result.

1. Subscribe to MQTT

Add an mqtt-in node and configure it to connect to the same broker and topic used during training. Set the output to auto-detect so the JSON payload is parsed automatically.

If you are using the built-in FlowFuse MQTT broker, use the FlowFuse MQTT nodes , these connect automatically when dragged into the flow.

2. Extract Features

Add a function node. In the Setup tab, add the module fs. Then paste the following into the On Message tab:

function extractFeatures(sig) {
    const arr = sig.map(Number);
    const n = arr.length;
    const mean = arr.reduce((a, b) => a + b, 0) / n;
    const std = Math.sqrt(arr.reduce((a, b) => a + (b - mean) ** 2, 0) / n) + 1e-9;
    const absArr = arr.map(Math.abs);
    const rms = Math.sqrt(arr.reduce((a, b) => a + b * b, 0) / n);
    const peak = Math.max(...absArr);
    const meanAbs = absArr.reduce((a, b) => a + b, 0) / n + 1e-9;
    const meanSqrtAbs = absArr.reduce((a, b) => a + Math.sqrt(b), 0) / n;
    return [
        rms, peak, Math.max(...arr) - Math.min(...arr),
        peak / (rms + 1e-9),
        arr.reduce((a, b) => a + (b - mean) ** 2, 0) / n,
        Math.sqrt(arr.reduce((a, b) => a + (b - mean) ** 2, 0) / n),
        arr.reduce((a, b) => a + ((b - mean) / std) ** 3, 0) / n,
        arr.reduce((a, b) => a + ((b - mean) / std) ** 4, 0) / n - 3,
        rms / meanAbs, peak / meanAbs, peak / (meanSqrtAbs ** 2 + 1e-9),
    ];
}

// Scaler and threshold are cached in flow context after the first message.
// If you update the model files, restart the Node-RED flow to reload them.
if (!flow.get('scaler')) {
    const sc = JSON.parse(fs.readFileSync('/opt/flowfuse-device/models/scaler_params.json'));
    const th = JSON.parse(fs.readFileSync('/opt/flowfuse-device/models/threshold.json'));
    flow.set('scaler', sc);
    flow.set('threshold', th.threshold);
}

const scaler = flow.get('scaler');
const CLIP = scaler.clip || 5.0;
const MIN_STD = 0.1;

const raw = [
    ...extractFeatures(msg.payload.x),
    ...extractFeatures(msg.payload.y),
    ...extractFeatures(msg.payload.z)
];

const normalised = raw.map((v, i) => {
    const s = Math.max(scaler.std[i], MIN_STD);
    const n = (v - scaler.mean[i]) / s;
    return Math.max(-CLIP, Math.min(CLIP, n));
});

msg.input = {
    data: new Float32Array(normalised),
    type: "float32",
    dims: [1, 33]
};
msg.payload = msg.input;
msg.threshold = flow.get('threshold');
return msg;

This function extracts 11 time-domain features per axis (33 total), loads the scaler on first run, and normalises the feature vector. The MIN_STD floor and ±CLIP clamp mirror the values used during training and prevent near-constant features from producing extreme values, which are a common source of false positives with vibration sensors.

If you changed the model file path, update the two readFileSync paths to match your chosen directory.

3. Run the Model

Add an onnx node and configure it:

Model path: /opt/flowfuse-device/models/motor_autoencoder.onnx
Input: msg.payload

The autoencoder compresses the 33-feature input through the bottleneck and reconstructs it on the output side. The reconstructed tensor is accessible in the next node via msg.payload. Since the output key name depends on how the ONNX graph was exported, the scoring node retrieves it dynamically rather than relying on a hardcoded name.

4. Score the Reconstruction Error

Add a second function node:

if (!context.get('initialized')) {
    flow.set('score_history', []);
    context.set('initialized', true);
}

// Generic output key lookup — works regardless of tensor name
const outputKey = Object.keys(msg.payload)[0];
const reconstructed = msg.payload[outputKey].cpuData;

const input = Array.from(msg.input.data);
const threshold = msg.threshold;

const mse = input.reduce((s, v, i) => s + (reconstructed[i] - v) ** 2, 0) / input.length;

let history = flow.get('score_history') || [];
history.push(mse);
if (history.length > 10) history.shift();
flow.set('score_history', history);

const smoothed = history.reduce((a, b) => a + b, 0) / history.length;

msg.anomaly_score = smoothed;
msg.is_anomaly    = smoothed > threshold;
msg.severity      = smoothed > threshold * 2 ? 'CRITICAL' : smoothed > threshold ? 'WARNING' : 'NORMAL';
msg.payload       = { anomaly_score: smoothed, threshold, is_anomaly: msg.is_anomaly, severity: msg.severity };
return msg;

This function computes mean squared error between the model's reconstruction and the normalised input, applies a 10-window rolling average to reduce sensitivity to transient spikes, then classifies the result as NORMAL, WARNING, or CRITICAL.

Recovery time: After an anomaly clears, the score returns to normal once the rolling window fills with healthy readings , typically 10 × your publish interval. At 500 ms publishing, that's roughly 5 seconds. Reduce the history window size for faster recovery; increase it to suppress false alarms.

Once deployed, the flow should look like this:

5. Act on the Result

Connect the scoring output to whatever suits your operation. For testing, a debug node shows results in real time. For production, an mqtt-out node can publish anomaly alerts downstream, the FlowFuse Dashboard package can visualise the anomaly score over time with a clear motor state indicator, and alerting nodes can notify your team directly, via Telegram, email, or SIGNL4 for structured mobile alerts with on-call scheduling and acknowledgement tracking.

What the Output Looks Like

Each message produces a structured result:

{
  "anomaly_score": 0.842,
  "threshold": 0.703,
  "is_anomaly": true,
  "severity": "WARNING"
}

When is_anomaly is false, the motor is behaving within the expected range. When it flips to true, the vibration pattern has shifted beyond the acceptable boundary, giving you time to act before the problem becomes a failure. A severity of CRITICAL means the score has crossed twice the threshold, signalling a more significant deviation that warrants immediate attention.

What This System Won't Tell You

This approach works well, but it's worth being clear about where it stops.

The autoencoder learns a statistical boundary around the vibration patterns it was trained on. It doesn't understand physics, it doesn't know the difference between a worn bearing and a loose mounting bolt, and it has no concept of severity beyond the reconstruction error score. When it flags an anomaly, it's telling you that something has changed, not what changed or why. Diagnosing the root cause still requires a technician with domain knowledge.

Training data quality matters more than model architecture. A model trained on data collected while the motor was lightly loaded, recently serviced, or running in cool ambient conditions will treat those as "normal." If real operating conditions differ, the threshold may be poorly calibrated from day one, generating either chronic false positives or, worse, missing genuine faults. There's no substitute for collecting training data under representative, sustained, real-world load.

False positives are inevitable in early deployment. External vibration from nearby equipment, transient load spikes, or sensor cable movement can all push the score above threshold momentarily. The rolling average window helps, but it doesn't eliminate them. Treat the first few weeks as a calibration period: log alerts, investigate them, and adjust THRESHOLD_SIGMA or the window size based on what you learn. The system improves with attention.

Finally, anomaly detection is an early warning layer, not a maintenance strategy on its own. It tells you to look sooner, not what to do when you get there. Pair it with regular physical inspection, lubrication schedules, and, where possible, a domain expert who can interpret the alerts in context. Used that way, it earns its place. Used as a replacement for those things, it will eventually let you down.

Modbus TCP vs Modbus RTU: Reliability, Latency, and Failure Modes

2026-02-20T00:00:00Z

Modbus shipped in 1979. It has outlasted every protocol that was meant to replace it, survived the transition from relay logic to microprocessors and modern SCADA systems, and is still running production lines today. That kind of longevity does not happen by accident. It exists because the protocol is simple, deterministic, and unambiguous, at least in its original form, a point I have discussed in more detail in a separate article.

Then TCP came along. The data model stayed the same, identical function codes and identical register maps. But the assumptions underneath changed completely, including expectations about the network, failure modes, and what happens when things go wrong. The industry gained real capability, but it also inherited an entirely new class of problems, ones that look nothing like the challenges Modbus engineers spent forty-seven years learning to solve.

That gap is what most people miss. And it is exactly what this post is about.

They Are Not the Same Protocol in Different Clothes

Modbus RTU runs over serial. That sounds simple until you consider what serial actually means in practice: one master, multiple slaves, one conversation at a time. The master initiates every transaction, the slave responds, and nothing else happens on the wire until that exchange completes.

The physical layer is almost always RS-485 in industrial installations, a differential pair that can run hundreds of meters, tolerate significant electrical noise, and connect up to 247 devices on a single bus.

That architecture imposes hard constraints. Only one device can transmit at a time. Timing between bytes within a frame matters: RTU uses silence on the line to mark frame boundaries, so a gap of 3.5 character times signals the end of one message and the start of the next. Get the baud rate wrong, introduce a noisy cable that stretches a byte, or misconfigure inter-character timing, and the frame parser loses its place. The message is silently discarded. No retransmission, no acknowledgment, just a timeout.

Modbus TCP moves the same application layer onto Ethernet and wraps it in a TCP socket. The serial constraints disappear. Multiple masters can coexist, transactions can be pipelined, and the physical layer handles collision detection and retransmission. What you gain in flexibility, you trade for a different set of assumptions. TCP guarantees delivery, but not timing. A retransmission storm on a busy network can stretch response times in ways that RTU, for all its limitations, never would.

Latency: What the Numbers Actually Mean on the Floor

RTU latency is predictable almost to the microsecond. That sounds like a strength until you realize how slow predictable can be.

At 9600 baud, a typical Modbus RTU transaction (request plus response) takes 50 to 100 milliseconds per device. Move to 115200 baud and that drops under 10 milliseconds. But you are still polling sequentially. Ten devices at 9600 baud means your slowest sensor gets updated once per second at best. Add more devices and the math gets worse in a straight line.

That ceiling matters. A real-world example: a water treatment plant running 32 RTU devices on a single RS-485 bus at 9600 baud had a worst-case poll cycle of nearly four seconds. When the control engineer needed tighter feedback on a pH dosing loop, the only options were to reduce the device count on that segment, split the bus, or increase baud rate, all of which required physical work on a running system.

Modbus TCP removes the baud rate ceiling and adds pipelining. A well-configured TCP master can have multiple transactions in flight simultaneously. On a lightly loaded Ethernet network, round trip times under 2 milliseconds are routine. For many applications, that is enough to stop thinking about latency altogether.

The catch is that Ethernet latency is not flat. It varies with network load, switch queue depth, and the TCP stack on the device side. Most of the time the numbers look excellent. Under the wrong conditions, they do not. A PLC with a modest embedded TCP stack, hit with traffic from a network scan or a broadcast storm, can stretch its response time by an order of magnitude. RTU would have delivered the same response time it always does.

RTU offers better worst-case latency. TCP offers better average latency. In industrial control, worst-case is usually what you design for.

Failure Modes: What Breaks, How It Breaks, and Whether You Will Know

This is where the two protocols diverge most sharply, and where choosing wrong costs the most.

RTU Failures Are Loud and Physical

RTU failures tend to be physical. A corroded terminal block. A cable run too close to a variable frequency drive. A termination resistor missing from one end of the bus. The symptoms are usually obvious: CRC errors climb, devices stop responding, the master logs timeouts.

What RTU rarely does is fail silently. Framing errors and timeouts are visible. The master knows a transaction failed. The application layer gets a clear signal that something is wrong, even if locating the fault takes time.

Locating it is the hard part. RS-485 is a shared medium, which means a single bad connection can drag down every device on the segment. Isolating which node is responsible requires methodical disconnection or a bus analyzer. Neither is fast at 2 AM with a line down.

But at least you know it is down.

TCP Failures Are Quiet and Strange

TCP failures are quieter and more varied. The physical layer is more robust: Ethernet cable is forgiving, switches regenerate signals, and a single bad port does not take down the network. But the failure surface is much broader.

A device can be electrically healthy and passing traffic, yet still behave badly. Connection state gets out of sync. A TCP socket on a cheap embedded device does not close cleanly after a timeout, leaving the master waiting on a half-open connection that looks alive but delivers nothing. A managed switch renegotiating link speed during a firmware update introduces 30 seconds of elevated latency that looks, from the application's perspective, like a slow device.

The worst TCP failures are the ones that are almost working. Partial connectivity. Occasional dropped transactions. Response times elevated but not elevated enough to trip a timeout threshold.

RFC 793 formally defines the half-open state: when one end of a TCP connection crashes or closes without notifying the other, the remaining side may wait indefinitely on a connection that appears alive and delivers nothing (RFC 793, Section 3.4). Rockwell Automation's troubleshooting documentation describes how conditions like duplex mismatches during switch replacement can produce exactly this pattern: performance that degrades quietly and stays within configured thresholds (Rockwell Automation, ENET-AT003).

RTU tends to fall over cleanly. TCP tends to degrade quietly. Degraded is harder to catch than broken.

TCP Introduces a Failure Mode That RTU Never Had: Security

Modbus has no authentication. On a serial bus, that is usually acceptable, because physical access to the wire implies physical access to the facility. On an Ethernet network, that assumption collapses entirely.

Modbus TCP devices reachable from a corporate network, or worse from the internet, will respond to commands from anyone who sends them. No credentials. No audit trail. No way to distinguish a legitimate master from an attacker with a laptop and a Modbus client.

This is not theoretical. Shodan regularly turns up Modbus TCP devices with publicly routable IP addresses. ICS security assessments routinely find Modbus exposed on flat networks shared with corporate IT. The clearest demonstration of what that exposure enables is FrostyGoop, malware discovered by Dragos in 2024 and the first ever to use Modbus TCP to cause direct physical impact. Attackers targeted a district energy company in Lviv, Ukraine supplying heat to over 600 apartment buildings — port 502 was open to the internet, no network compromise required, and remediation took nearly two days while residents endured sub-zero temperatures. No credentials were needed. Modbus provided none to ask for.

RTU is not inherently secure either, but attacking it requires being physically present on the wire. TCP removes that requirement entirely.

Choosing Between Them

Most engineers do not choose between RTU and TCP from a blank slate. They inherit a system, get handed a specification, or discover that the device they need only supports one of them. The real decision is narrower: whether what is already in place is appropriate for what the system now needs to do.

RTU is the right answer when device count is small, cable runs are already there, polling rates are modest, and nothing outside the cabinet needs to reach the network. Those conditions describe a large percentage of working industrial installations. Changing a system that meets all of them adds risk for no operational benefit.

TCP makes sense when you need to integrate field devices with higher-level systems like SCADA, historians, or MES, when device count or poll rate has grown beyond what serial can comfortably handle, or when the network already exists and adding serial infrastructure would cost more than it saves. It also makes sense when you need multiple masters, which serial cannot support without external arbitration hardware.

The hybrid case is a serial network running reliably for fifteen years, with a gateway at the head end converting RTU to TCP for the SCADA system. It is more common than either pure scenario, and more sensible than it looks on paper. The gateway adds a failure point, but it also insulates field devices from the corporate network. That insulation is worth keeping. Replacing it to simplify the architecture is usually not the right trade.

What to Actually Do Differently Based on This

If you are deploying RTU: use the highest baud rate the cable length and device count will reliably support, do not leave devices at 9600 baud out of habit; document your bus topology, because when something fails at night the person troubleshooting will not be you; and install proper termination resistors at both ends of every RS-485 segment, since this causes more problems than almost anything else.

If you are deploying TCP: isolate Modbus devices on a dedicated VLAN or network segment and never put them on the corporate LAN; configure short TCP timeouts and explicit connection retry logic in your master, because half-open connections will happen; and log poll latency over time, since degradation that stays inside timeout thresholds will not alarm and you have to trend it.

If you are maintaining a hybrid gateway architecture, resist the urge to rationalize it away. It is doing work.

The two protocols make different guarantees, fail differently, and require different diagnostic skills when something goes wrong. Understanding that distinction before the system is designed costs nothing. Understanding it for the first time during an incident costs considerably more.

CAN Bus Tutorial: Connect to Dashboards, Cloud, and Industrial Systems

2026-02-13T00:00:00Z

If you work with vehicles, industrial automation, or embedded systems, you've likely encountered CAN bus, the communication backbone that connects ECUs, sensors, controllers, and actuators in real-world environments. The challenge isn't just reading CAN data; it's getting that data into your dashboards, cloud platforms, databases, or industrial control systems.

Traditionally, this meant dealing with vendor-specific drivers, proprietary gateway hardware, and low-level C code just to bridge CAN bus to modern IT infrastructure. SocketCAN and FlowFuse offer a better approach.

SocketCAN brings CAN bus support directly into the Linux networking stack, treating CAN interfaces like Ethernet or Wi-Fi. Combined with FlowFuse's visual flow-based programming (built on Node-RED), you can connect CAN bus devices to virtually any system, building real-time dashboards, streaming data to cloud platforms, integrating with SCADA systems, or bridging to MQTT, databases, REST APIs, and industrial protocols, all without writing low-level code or relying on proprietary tools.

In this tutorial, you'll set up SocketCAN on Linux, integrate it with FlowFuse, and learn how to send and receive CAN frames, establishing the foundation for connecting your CAN infrastructure to the broader industrial ecosystem.

Understanding CAN Bus

CAN (Controller Area Network) is a robust communication protocol that allows multiple devices, such as sensors, controllers, and actuators, to share data over a two-wire bus. Commonly used in automotive, industrial, and embedded systems, CAN broadcasts all messages to every device on the network, with each message identified by an ID that devices use to filter relevant data.

What Is SocketCAN?

SocketCAN is a Linux kernel feature that integrates CAN bus support directly into the networking stack. It exposes CAN hardware as standard network interfaces (like can0 or vcan0), allowing you to configure and interact with CAN using familiar Linux networking commands. This abstraction means your application code remains the same whether you're using a USB-to-CAN adapter, an embedded controller, or a virtual interface, making development, testing, and hardware changes significantly simpler.

Getting Started

To follow this tutorial, you'll need a Linux environment where you can run FlowFuse and configure SocketCAN. In our setup, FlowFuse runs on an Ubuntu-based edge device, and we use a virtual CAN interface to simulate a real CAN bus. This allows you to complete the tutorial without any physical CAN hardware.

Prerequisites

Before you begin, ensure your environment meets the following requirements:

Linux Operating System SocketCAN is a Linux kernel feature and requires a Linux-based system. This guide is tested on Ubuntu 20.04+ and other Debian-based distributions, though the same concepts apply to any modern Linux distribution with kernel 2.6.25 or later.
Running FlowFuse Instance FlowFuse is built on top of Node-RED, providing the fastest and most production-ready way to deploy, manage, and govern your flow applications on edge devices. If you're using plain Node-RED, this tutorial will work there as well. For installation details of FlowFuse, see this guide.
System Permissions Root or sudo privileges are required to load kernel modules, create network interfaces, and configure SocketCAN devices.
CAN Hardware or Virtual Interface This tutorial uses a virtual CAN (vcan) interface to demonstrate SocketCAN and FlowFuse integration without requiring physical hardware. In production deployments, physical CAN interfaces are typically used, such as:
- USB-to-CAN adapters (for example, PEAK PCAN-USB or Kvaser devices)
- Embedded CAN controllers (such as MCP2515 via SPI)
- Built-in CAN interfaces on industrial computers or single-board computers

The FlowFuse flows and application logic remain the same when switching between virtual and physical CAN interfaces; only the underlying CAN interface configuration differs.

Enabling CAN Interfaces with SocketCAN

Before FlowFuse can interact with a CAN bus, a CAN network interface must be available and active at the operating system level. SocketCAN does not automatically create or enable interfaces; this step is always required, whether you are using a virtual or physical CAN bus.

The setup differs slightly depending on your environment.

Option A: Virtual CAN (vcan) for Development and Testing

A virtual CAN interface allows CAN frames to be exchanged entirely in software. It is useful for development, testing, and learning, but it does not model physical bus timing or electrical behavior.

Enable vcan Support

Load the virtual CAN kernel module:

sudo modprobe vcan

Verify that it is loaded:

lsmod | grep vcan

Create and Enable the Interface

Create a virtual CAN interface named vcan0:

sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

Verify the interface:

ip link show vcan0

At this point, vcan0 is ready to be used by SocketCAN applications such as FlowFuse.

Option B: Physical CAN Hardware for Production Systems

When using real CAN hardware, the interface is exposed by a hardware driver, but it still must be explicitly configured and enabled.

1. Hardware Driver

Most common CAN hardware is supported directly by the Linux kernel:

USB-to-CAN adapters are typically detected automatically when connected
SPI-based CAN controllers (for example, MCP2515) require kernel and device-tree configuration
Built-in CAN controllers may require BIOS or kernel configuration

Once the driver is loaded, a CAN interface such as can0 becomes visible to the system.

2. Configure and Enable the Interface

Physical CAN interfaces must be configured with a bitrate before use:

sudo ip link set can0 up type can bitrate 500000

This command enables the CAN interface, sets the bus bitrate, and makes the interface available to SocketCAN applications.

3. Verify the Interface

ip link show can0

If the interface is up, it can be used immediately by FlowFuse.

Comparison: Virtual vs Physical CAN

Aspect	Virtual CAN (vcan)	Physical CAN
Hardware required	No	Yes
Electrical bus	No	Yes
Bitrate configuration	Not required	Required
Kernel driver	`vcan`	Hardware-specific
FlowFuse (Node-RED) flows	Same	Same
Typical use	Development, testing	Production

Using SocketCAN in FlowFuse

Once a CAN interface (vcan0 or can0) is enabled at the operating system level, FlowFuse can interact with it like any other SocketCAN-compatible application. At this stage, no CAN frames are flowing yet. FlowFuse simply gains access to the interface.

In this section, we'll focus on how FlowFuse connects to SocketCAN and what that means conceptually, before building any actual flows.

The flow looks like this:

FlowFuse does not communicate directly with CAN hardware. Instead, it relies on SocketCAN, which exposes CAN interfaces through the Linux networking stack.

Once a CAN interface is enabled at the operating system level, whether a virtual interface like vcan0 or a physical interface like can0, it becomes available to any SocketCAN-compatible application. FlowFuse simply opens this interface and exchanges CAN frames using standard socket operations.

This design has two important advantages:

FlowFuse remains hardware-agnostic. The same flows work with virtual CAN interfaces, USB-to-CAN adapters, or embedded CAN controllers.
All hardware-specific configuration, such as driver loading and bitrate setup, is handled by the operating system, not by FlowFuse.

As a result, the application logic in FlowFuse stays the same across development, testing, and production environments. The only requirement is that the appropriate CAN interface is created and enabled before FlowFuse starts

Installing the SocketCAN Node

FlowFuse does not include native CAN support out of the box. To interact with SocketCAN interfaces (can0, vcan0, etc.), you need to install a module that provides CAN input and output nodes.

Follow these steps:

Open the Instance editor in your browser
Click the menu icon (☰) in the top-right corner
Select Manage palette
Open the Install tab
Search for node-red-contrib-socketcan
Click Install next to the package

Once installed, the SocketCAN nodes will appear in the FlowFuse palette.

Installation Troubleshooting

If the installation fails, it is usually due to one of the following reasons:

FlowFuse is not running on a Linux system (SocketCAN is Linux-only)
Required build tools are missing on the system

To resolve this, ensure you are running on Linux and install the required build dependencies:

sudo apt update
sudo apt install -y build-essential

After installing the build tools, retry installing node-red-contrib-socketcan from the FlowFuse palette.

Working with CAN Frames in FlowFuse

Once a CAN interface (vcan0 or can0) is enabled and the SocketCAN nodes are installed, FlowFuse can begin exchanging CAN frames. At a high level, there are only two operations involved when working with CAN in FlowFuse:

Receiving CAN frames from the bus
Transmitting CAN frames onto the bus

FlowFuse represents these operations using dedicated input and output nodes provided by the SocketCAN module.

Receiving CAN Frames

Receiving CAN frames means listening to all messages that appear on the CAN bus and processing them inside FlowFuse.

Drag a socketcan-out node from the FlowFuse palette onto the canvas.
Open the node configuration and add the interface by clicking the + button next to the interface. Enter your interface name, e.g., vcan0 (for virtual CAN) or can0 (for physical CAN).
Click Add, then Done to save the interface.
Connect the output of the socketcan-out node to a Debug node.
Deploy the flow to begin receiving CAN frames.

Once connected, the socketcan-out node will show a green status box with text. The same applies to the socketcan-in node:

connected <your-interface-name>

When frames are received, FlowFuse outputs them as JavaScript objects containing fields such as:

timestamp: the time the frame was received (in milliseconds since epoch)
ext: indicates whether the frame uses an extended CAN ID (true/false)
canid: the CAN identifier for the message
dlc: the Data Length Code, i.e., the number of data bytes in the frame
rtr: Remote Transmission Request flag (true if the frame requests data)
data: an array of bytes representing the payload of the frame
err: indicates whether the frame contains an error (true/false)
rawData: a copy of the data payload in its raw byte form

This makes it easy to filter, decode, or route messages using standard FlowFuse nodes.

Transmitting CAN Frames

Transmitting CAN frames means sending messages onto the CAN bus from FlowFuse. This allows you to control devices, trigger actions, or communicate with other ECUs on the network.

Drag a socketcan-in node from the FlowFuse palette onto the canvas.
Open the node configuration and set the interface to vcan0 (for virtual CAN) or can0 (for physical CAN).
Leave the node in transmit mode to send messages onto the bus.
Connect the input of the socketcan-in node to any source node, such as an Inject node for testing.
Configure the message in the Inject node by setting the payload as a JavaScript object containing the fields canid, data, and optionally ext for extended frames.
Deploy the flow to begin transmitting CAN frames.

For example, a message object could look like this:

{
  "canid": 512,
  "data": [22, 45, 170, 255],
  "ext": false
}

This would send a standard CAN frame with ID 0x200 and 4 bytes of data onto the bus.

String-Formatted Messages

Alternatively, CAN messages can be defined as strings using a compact format:

<canid>#{R|data}

Where:

canid: The CAN identifier in hexadecimal format. For standard IDs using this string format, specify 1-2 hex digits (e.g., 5A, FF). For extended IDs, use 3 or more hex digits (e.g., 7FF, 1F334455).
data: The data payload for the CAN frame, specified in hexadecimal format.
R: Indicates a Remote Transmission Request (RTR) frame instead of a data frame.

For example:

200#162DAAFF

This sends a CAN frame with ID 0x200 and data bytes [0x16, 0x2D, 0xAA, 0xFF].

To send an RTR frame:

200#R

This requests data from devices listening to CAN ID 0x200 without sending any payload.

Conclusion

By combining SocketCAN with FlowFuse, you've eliminated much of the complexity traditionally associated with CAN bus development. What once required low-level C code, vendor-specific drivers, and deep protocol knowledge can now be accomplished with visual flows and straightforward message handling.

The real power of this approach becomes clear when you consider scalability. The same FlowFuse flows work identically whether you're testing with a virtual CAN interface on your laptop or deploying to production hardware with physical CAN controllers. The abstraction layer provided by SocketCAN means your application logic remains stable even as your hardware requirements evolve.

Once you've connected to your CAN bus, the possibilities expand significantly. You can build real-time monitoring dashboards to visualize CAN data, send telemetry to cloud platforms for analytics and storage, or bridge CAN networks with virtually any other protocol or system. FlowFuse's extensive ecosystem of nodes and integrations supports connections to databases, MQTT brokers, REST APIs, industrial protocols, and more, making it straightforward to integrate your CAN infrastructure into larger IoT and automation workflows.

FlowFuse 2.27: Integrated Editor in Remote Instances & Context-Aware FlowFuse Expert

2026-02-12T00:00:00Z

FlowFuse 2.27 tightens the development loop for Remote instances and makes FlowFuse Expert more aware of what is actually running in your Node-RED environment. It also improves availability for High Availability hosted deployments.

A More Integrated Remote Development Workflow

Teams run production and edge workloads in Remote instances. When tooling behaves differently across environments, it slows debugging and increases risk during active changes.

Immersive Editor & Snapshot Restore

FlowFuse now brings the integrated editor experience to Remote instances. Clicking Open Editor provides the same FlowFuse capabilities regardless of where your instance runs.

Immersive Mode accessed from a remote instance

Device Agent v3.8.0 also allows you to restore snapshots while remaining in developer mode. You no longer need to exit developer mode to roll back changes. Pipeline protections remain in place, but manual recovery is faster.

Restoring a snapshot without leaving developer mode

In practice

You move between hosted and remote environments without changing your workflow
You restore snapshots without interrupting active debugging
You reduce friction while iterating on live systems

FlowFuse Expert Uses Live Flow and Palette Context

AI guidance is only useful when it reflects what is actually running in your environment. Manually describing flows or installed nodes slows troubleshooting and introduces gaps in context.

Palette Awareness & Flow Context

FlowFuse Expert now:

Understands your selected flows as troubleshooting context
Detects installed custom nodes automatically
Answers questions about your Node-RED palette, including versions, updates, and disabled nodes
Suggests node packages and links directly to manage them
Installs suggested nodes and imports flows with a single click

FlowFuse Expert surfaces context and performs actions only when initiated by the user.

FlowFuse Expert answering palette queries with live context

In practice

You do not manually describe your setup
You identify missing or outdated nodes faster
You troubleshoot flows based on real context
You move between chat, palette manager, and editor without unnecessary clicks or context switching

High Availability Improvements for Hosted Instances

Parallel restarts in HA environments can introduce avoidable service interruption during deploys or manual restarts.

Rolling Restarts

Hosted Node-RED instances with HA enabled now restart sequentially rather than in parallel. Any manual or pipeline-triggered restart follows this behavior.

This feature is available to Enterprise licensed self-hosted users and Enterprise tier users of FlowFuse Cloud.

In practice

You reduce service interruption during restarts
You improve availability during deploys
You maintain stronger continuity in HA environments

What else is new?

For detailed breakdowns of each feature with additional visuals, visit our changelog. For the complete list of everything included in FlowFuse 2.27, check out the release notes.

If something in this release improves your workflow, or if there is still friction we can remove, please share feedback or report issues regarding this release to us.

Try FlowFuse

FlowFuse Cloud

The fastest way to get started is with FlowFuse Cloud.
Get started for free and have your Node-RED instances running in minutes.

Self-Hosted

Run FlowFuse locally using Docker or Kubernetes.

Event-Driven Architecture: 99% of Your System Requests Are Worthless

2026-02-10T00:00:00Z

Nearly 99% of the requests your manufacturing systems make return the same answer: nothing changed. The 1% that matter? You find out too late. This isn't a monitoring problem. It's an architecture problem.

Event-Driven Architecture (EDA) flips this model entirely. Instead of systems asking questions on a schedule, they listen for events and react the moment something happens, eliminating the gap between occurrence and response.

In manufacturing, an "event" is any significant occurrence. A machine completes a cycle. A sensor detects an anomaly. A part fails inspection. Inventory hits a threshold. When these events occur, they are immediately broadcast to all interested systems, which respond automatically and in parallel.

When a machine finishes a production run, it triggers an event. Instantly, the inventory system updates stock levels. Maintenance logs machine hours. Quality control schedules an inspection. Production planning releases the next order. No manual intervention. No waiting.

This is what real-time responsiveness looks like in practice. Faster issue detection, dynamic optimization, and the ability to absorb disruptions before they cascade.

The Structural Limits of Traditional Manufacturing Systems

Traditional manufacturing systems operate on request-response models. The MES queries the ERP for inventory counts. SCADA polls sensors at fixed intervals. Quality systems run batch processes to aggregate data. Each system asks for what it needs, when it needs it. This worked when manufacturing moved slowly. It breaks down in modern production environments.

The waste is structural. Nearly 99 out of every 100 polling requests return no new information, and polling models consume orders of magnitude more server resources than event-driven alternatives to maintain the same data freshness. Bandwidth and processing power are spent confirming that nothing has changed.

Between polling intervals lies real risk. A fault appears on the floor at 9:14:01 AM. The monitoring system, configured to poll every five minutes, won't detect it until 9:15:00. During those 59 seconds, defective output flows downstream while costs accumulate at rates exceeding $38,000 per minute in automotive facilities. Schedules drift. Quality issues propagate. The gap between what's happening and what the business knows keeps widening.

Point-to-point integrations make this worse. Connection counts follow the n(n-1)/2 formula. Five systems require ten connections. Ten systems demand 45. Each connection carries its own protocol, authentication scheme, and maintenance overhead. A firmware update means manual remapping across dozens of endpoints. New functionality requires weeks of integration work. A single failure can cascade through every tightly coupled system downstream.

The architecture that once enabled the factory now constrains it.

How Event-Driven Architecture Works

Every polling system works the same way. Your MES wakes up on a timer and asks if anything changed. Usually nothing has. So it waits, then asks again. Multiply this across every system pair on your floor and you have an architecture that spends most of its energy confirming that nothing has happened.

EDA inverts this. Every significant occurrence gets broadcast the moment it happens. Any system that needs to know receives it immediately. Systems that don't are never involved.

Three components make this possible. Event producers generate the signal. PLCs, sensors, vision systems. Their only responsibility is to announce what happened. Event consumers act on it. The MES updates work orders. The ERP adjusts inventory. The maintenance platform logs runtime hours. Each subscribes only to relevant events and acts independently, so multiple consumers can respond to the same event simultaneously. The event broker connects them without coupling them. It receives events, routes them to subscribers, and keeps a durable log. Neither side needs to know the other exists. Adding a new consumer means subscribing it to the broker. Nothing else changes.

That last property is what solves the integration complexity problem. In point-to-point architectures, every new connection requires negotiated APIs and coordinated work across teams. The broker absorbs that complexity entirely.

The durable log solves a problem polling handles poorly. Events that occur while a system is offline are replayed in order when it comes back. Transient outages stop being data integrity problems. The record of what happened on the floor stays complete regardless of which systems were available when it happened.

The Business Impact of Running on Events

Most factories don't lose money because their equipment is bad. They lose it because their systems are slow to know what's happening and slower to act on it.

That slowness isn't a people problem. It's structural. When your systems communicate by asking rather than listening, there's always a gap between what's happening on the floor and what the business knows about it. Teams fill that gap with buffers, manual checkpoints, and end-of-shift reports. It works until it doesn't.

EDA closes that gap. When something happens, every system that needs to know finds out immediately. The right processes trigger automatically. No polling cycle. No batch job. No one manually connecting the dots.

The scale of what's at stake makes this worth stating plainly. Unscheduled downtime costs the world's largest manufacturers trillions annually, representing a double-digit percentage of revenue. Nearly three-quarters of manufacturing leaders report that delays in reporting problems trigger chain reactions across their operations. These aren't technology metrics. They're business outcomes produced by architectures that were never designed to respond in real time.

Quality compounds the same way. The 1-10-100 rule of manufacturing quality states that a defect costs $1 to catch pre-production, $10 to catch during production, and $100 once it reaches the customer. Every minute a failed inspection goes unbroadcast to downstream systems, that multiplier is running. EDA stops the propagation at the source by ensuring the result is instantly visible to every process that needs to act on it.

Integration debt follows the same logic. Enterprise-level manufacturing software implementations routinely take many months to multiple years. Every new capability your team wants requires a project. EDA changes the economics entirely. New systems subscribe to the broker. Existing systems stay untouched. What once consumed quarters now requires configuration.

And when something does go wrong, you have a complete timestamped record of everything that happened on the floor. Not reconstructed timelines. Root cause analysis that took days takes hours. Audits have a chain of custody by default.

The factories pulling ahead right now aren't the most automated. They're the ones where information moves as fast as production does. Every minute that gap exists, it has a cost. EDA removes it.

What It Takes to Move to Event-Driven Architecture

The hardware is already there. Sensors, PLCs, SCADA systems. All running. EDA doesn't replace them. It changes how they communicate.

You need an event broker and something that connects to legacy systems. MQTT for shop floor devices. Kafka for enterprise loads. Node-RED to bridge the gap. That's the stack.

The real work is defining what counts as an event. A sensor produces tens of thousands of readings per day. Broadcasting all of them is noise. The event is when temperature crosses a threshold, stays abnormal, or trends wrong. Exceptions, not data points.

Your team already knows which deviations matter. Which delays cascade. Which variations are normal. Get this wrong and you build a system that generates alerts faster than anyone can ignore them.

Start where waiting costs the most. Downtime reported late doesn’t need better sensors. The stop event needs to fire when it happens and route to maintenance, scheduling, and analytics simultaneously. One workflow. Measured impact. Studies show event-driven systems responding in milliseconds rather than minutes, reducing manual intervention dramatically and improving process completion rates at scale. Prove it on one line, then expand to the next bottleneck.

The broker is straightforward. The translation layer isn't. Your MES doesn't listen for events. Your ERP expects scheduled queries. Your quality system runs batch jobs. Bridging that gap is where real effort lives.

Brownfield doesn’t require cutover. Legacy runs. New workflows build on events. Each migration reduces polling overhead and creates durable audit trails. Value compounds.

The factories that fail treat this as infrastructure. The ones that succeed pick the highest-cost delay, fix it with events, measure the difference, and move on. Value drives adoption. Not architecture diagrams.

FlowFuse makes event-driven architecture practical for manufacturing by connecting IT and OT systems through a single platform that supports virtually any protocol, includes a built-in MQTT broker, and provides enterprise-grade deployment and security. Get started with FlowFuse today

Sources & References

APIPark — Moving Beyond API Polling to Asynchronous Architectures https://apipark.com/technews/TbhGSEzF.html
DZone — Webhooks vs. Polling: You’re Better Than This https://dzone.com/articles/webhooks-vs-polling-youre-better-than-this-1
Insane Cyber — The Real Cost of Industrial Downtime https://insanecyber.com/real-cost-industrial-downtime/
StackSync — Why Integration Complexity Grows Exponentially https://www.stacksync.com/blog/integration-complexity-growth
Siemens — The Cost of Downtime in Manufacturing https://www.siemens.com/global/en/products/services/industry-operations-services/digital-enterprise-services/manufacturing-operations-management/manufacturing-intelligence/downtime-cost.html
Rockwell Automation — The True Cost of Downtime https://www.rockwellautomation.com/en-us/company/news/blogs/the-cost-of-downtime.html
American Society for Quality (ASQ) — Cost of Quality and the 1-10-100 Rule https://asq.org/quality-resources/cost-of-quality
Gartner — Manufacturing ERP Implementation Timelines https://www.gartner.com/en/documents/manufacturing-erp-implementation
International Journal of Science and Advanced Technology (IJSAT) — Event-Driven Manufacturing Automation Systems https://www.ijsat.org/papers/2025/1/2907.pdf

Shop Floor AI: Dead on Arrival Without This

2026-02-06T00:00:00Z

Your industrial AI initiative is dying. Maybe it's already dead.

Not because the models are wrong. Not because the data scientists failed. Not because you didn't spend enough on sensors or compute power.

It's dying because you're building on a foundation that was never designed to support it.

You instrumented everything: motors, conveyors, bearings, valves, streaming thousands of data points per second. Historians filled to capacity. Dashboards displayed every metric. AI models trained on millions of records. Yet despite all this technology, you still can't see what's happening until something breaks.

The problem isn't your AI. It's the architecture underneath it.

This article reveals why most industrial AI projects fail before they start: why raw signals without context are just noise, why your three disconnected data layers doom AI from day one, and why a Unified Namespace is the only architecture that makes industrial AI actually work on the shop floor.

Twenty years ago, a skilled operator could diagnose a failing machine by sound, smell, or vibration. Today's machines still communicate just as clearly. They've simply switched languages. They produce numbers that nobody understands. A temperature spike, a current drift, a vibration anomaly: each is meaningless without knowing which product is running, under what conditions, with which maintenance history, and how this system typically behaves.

The problem isn't AI capability. It's poor architecture. Signals without context are difficult to interpret. Context without connection never reaches the people who need it. And decisions made without information are guesses at best.

For AI to actually work on the factory floor, we need three things working in concert: signals that feed context, context that creates understanding, and AI that empowers humans to ask the right questions at the right time.

The Three-Layer Problem

Most manufacturers diagnose themselves with an AI problem. Their models don't predict failures. Their anomaly detection drowns in false positives. Their optimization recommendations get politely ignored.

They're diagnosing the wrong disease. Most factory floors aren't ready for AI.

This isn't an AI problem. It's an architecture problem that AI just makes impossible to ignore. Your data exists in three disconnected layers, and until you bridge them, no amount of machine learning can help.

Layer One: The Signal Layer

Raw data accumulates here. PLCs, SCADA, historians, MES systems, all generating measurements at rates human cognition was never designed to process. Temperature, pressure, flow, current draw, RPM, torque, position. Millisecond timestamps. Perfect fidelity. Absolutely zero meaning.

The signal layer has no concept of importance. When a conveyor motor pulls 2.3 amps, that's just a number in a database. The system doesn't know if this represents peak efficiency or the warning sign of a dying gearbox.

But nobody knows which question to ask until something fails. Then you're analyzing historical data files, reconstructing what happened. It's post-incident analysis when what you needed was real-time diagnosis.

The signal layer does exactly one thing well: it remembers everything. What it can't do is understand anything.

Layer Two: The Context Layer

Context is everything the signal doesn't tell you. Which product is currently running. The ambient conditions. The maintenance history. The supplier change that wasn't documented. The operator who runs things hot because it's faster. The firmware update that altered control loop timing.

This layer exists in fragments, scattered across ERP systems, maintenance logs, Excel files, shift handover notes, and inside the heads of people who might retire next year.

Without this layer, signals are just sequential numbers. With it, they become useful information. They tell you not just what is happening, but why it matters, what it resembles, and what typically comes next.

The fundamental problem: we never built systems to unite these layers. Different databases, different teams, different vendors, different security models. Integration became a six-month IT project instead of a core design principle.

Your data has context, but it's locked away where neither your people nor your AI can see it.

Layer Three: The Human Decision Layer

This is where humans operate, increasingly overwhelmed by the gap between what they can see and what they need to know.

An alarm sounds. An operator has 30 seconds to decide: Is this real or noise? Critical or routine? Stop the line or log and monitor? The context they need is fragmented across three systems they can't access and two colleagues on different shifts.

So they decide based on experience and instinct. Sometimes they're right. Sometimes they're not. Either way, the decision logic gets lost - there's no system capturing why they chose what they did.

Engineers face the inverse problem: too much time and too much data. By the time they've extracted historian data, correlated it with production schedules, and cross-referenced maintenance records, the problem has either resolved itself or gotten worse.

This is where AI should enter, not as a decision-maker, but as an intelligent assistant. The human decision layer needs AI that can answer questions in real-time: "Is this vibration pattern normal for this product recipe?" "When did we last see this current signature?" "What were the conditions the last three times this alarm triggered?"

The decision remains human. The insight becomes instant.

Why This Architecture Breaks AI

You can't fix a three-layer problem with a one-layer solution.

Companies repeatedly make the same mistake: they drop AI models directly into the signal layer (pure time-series analysis on raw sensor data) then wonder why predictions are worthless. The model identifies a pattern, but it's blind to the fact that context just changed. It flags anomalies that are actually normal for this product recipe. It misses failures because the signal appeared fine while the context indicated problems.

But here's what's crucial to understand: AI is ready for the factory floor right now. Not ready to take autonomous action, but ready to be the most knowledgeable assistant your operators and engineers have ever had.

Think about what you actually need. When an operator sees unusual behavior, they need answers immediately: "Is this normal?" "What happened last time?" "Should I be concerned?" When an engineer investigates a problem, they need to explore data at depth: "Show me all the times we saw this pattern." "What were the ambient conditions?" "How does this compare across shifts?"

AI can answer these questions instantly if it has access to the right architecture.

Industrial AI fails when you ignore the architecture. You need the signal layer feeding a context layer that's actually integrated, queryable, and current. You need decision support that operates at the speed questions get asked, not at the speed IT can generate a report.

The Architecture Solution

The challenge isn't the layers themselves, but the gaps between them.

So what would an architecture look like that actually closes these gaps? What would it take to have signals arrive already carrying context? To have that context accessible the moment a question gets asked? To give AI and humans the same unified view of what's happening right now?

The requirements are clear: you need operational data organized the way factories actually run - by site, area, line, and asset. You need context added at the moment data enters the system, not reconstructed hours later. You need a single source of truth that every system can access in real time.

This isn't a future vision. This architecture exists, and it's been battle-tested in manufacturing operations worldwide.

It's called the Unified Namespace (UNS).

A Unified Namespace is a shared, real-time, event-driven structure where operational data flows with its context intact. Instead of systems integrating point-to-point, every system publishes to and consumes from the same namespace. Signals arrive already carrying context.

In a UNS, a motor current is no longer just a number stored in a historian. It's published as Line 3 / Conveyor 2B / Motor Current, alongside the active recipe, operating mode, ambient conditions, and relevant maintenance history. Every system sees the same structured truth, continuously updated.

This shift in architecture is what makes AI viable on the factory floor.

Building a Unified Namespace requires three things:

Connecting incompatible industrial systems
Enriching raw signals with operational context as data flows
Publishing that context once, over MQTT, so AI and humans can consume it in real time

This is where flow-based integration becomes essential.

Tools like Node-RED make UNS architectures practical. Instead of writing custom integration code, engineers visually wire systems together. PLCs publishing over Modbus, MES systems exposing REST APIs, and proprietary SCADA protocols can all be connected, normalized, and enriched as data moves through the flows.

FlowFuse builds on Node-RED to make this architecture production-ready. It adds centralized deployment, version control, access control, and remote management: the capabilities required to operate a Unified Namespace reliably across lines, plants, and teams.

Crucially, in a Unified Namespace, context is added at the moment data enters the system, not reconstructed later. A motor current isn't simply forwarded. It's enriched with equipment hierarchy, product recipe, operating mode, environmental conditions, and timestamps aligned with production events.

That enriched information is then published into a shared MQTT-based Namespace. One location. One structure. One source of truth. Dashboards, analytics, and AI systems all subscribe to the same contextualized view of reality.

Through FlowFuse MCP nodes, AI systems connect directly to the namespace, querying live operational context instead of pulling raw time-series data from isolated historians and attempting to reconstruct meaning after the fact.

FlowFuse AI Expert operates on the same MCP-backed context layer. Operators and engineers can ask questions in natural language ("Is Line 3 behaving normally?", "Have we seen this vibration pattern before?", "What changed before the last failure?") and receive answers grounded in the live Unified Namespace.

To learn how to build your own Unified Namespace with FlowFuse, see our comprehensive guide.

The result is immediate insight without additional tooling, custom integrations, or fragile data pipelines. The architecture already exists. The context is already there. The questions can finally be asked at the speed decisions are made.

Final Thoughts

Your industrial AI isn't failing because the models are bad. It's failing because the architecture was never designed to support it.

Most manufacturers make the same mistake: they bolt AI onto existing infrastructure - historians full of raw signals, context scattered across disconnected systems, decisions made with incomplete information. Then they wonder why predictions are worthless and anomaly detection drowns in false positives.

You can't solve a three-layer problem with a one-layer solution.

The Unified Namespace fixes this by doing what should have been done from the start: uniting signals with context in real time. A motor current stops being "2.3 amps" in a database and becomes operational intelligence - which line, which equipment, which recipe, what maintenance history, what patterns preceded past failures.

This is the foundation AI needs. Not more data. Not better models. Context that transforms signals into understanding.

With this architecture in place, AI shifts from a failed prediction engine to what it should be: a tool that multiplies operational expertise. It doesn't replace human judgment. It enables faster, better-informed decisions backed by complete operational context.

Manufacturers who build this architecture first get operations that learn from every incident, engineering teams that diagnose root causes in minutes instead of days, and confidence in decisions because they're based on understanding rather than guesswork.

The path forward isn't better AI models. It's better architecture. Build the Unified Namespace first. The AI will finally work.

Start with FlowFuse today. Build the architecture your industrial AI needs to succeed.

Mapping MTConnect Streams for Dashboard Visualization

2026-02-06T00:00:00Z

Most manufacturing facilities run MTConnect agents on their CNC machines, but the XML data these agents produce isn't directly usable. You receive streams of timestamped measurements, state changes, and condition flags wrapped in hierarchical XML structures. Converting this into a functional dashboard means solving three problems: retrieving the data reliably, parsing it correctly, and routing specific values to the right display components.

This article walks through the implementation. You'll connect FlowFuse to an MTConnect agent, extract data items from the XML response, and build dashboard widgets that update in real time.

What MTConnect Is and Why It Matters

MTConnect is an open manufacturing standard that defines how equipment communicates operational data. Before MTConnect, each machine tool manufacturer used proprietary protocols. Connecting a Mazak, Haas, and DMG MORI to the same monitoring system meant writing custom integrations for each brand. MTConnect solves this by providing a vendor-neutral protocol that any machine can implement.

The standard specifies what data machines should report and how to structure it. A spindle speed reading from a Haas looks identical to one from a Mazak when both machines run MTConnect agents. This standardization makes it possible to build dashboards and monitoring systems that work across mixed machine fleets without custom code for each manufacturer.

MTConnect agents typically run as software on the machine controller or on a separate computer connected to the machine. The agent reads data from the controller's internal systems and exposes it through HTTP endpoints that return XML. You don't interact with the machine directly—you interact with the agent.

Data Types in MTConnect

MTConnect organizes data into three categories:

Samples - Continuous numeric measurements like spindle speed, axis position, temperature, power consumption. These values change smoothly and have units.
Events - Discrete state changes like mode switches, program starts, door opens. Values are strings or enumerations.
Condition - Equipment health at the component level: normal, warning, fault, unavailable. Multiple conditions can be active simultaneously.

Agents expose this through HTTP endpoints. /current returns latest values for all data items. /sample?from=X&count=Y returns time-series data.

XML Response Structure

When you query an MTConnect agent, the response is an XML document rooted in the Streams element, which contains one or more DeviceStream elements—each representing a device or machine.

Within each DeviceStream, ComponentStream elements describe individual machine components such as spindles, axes, or controllers. Each component reports its data using three categories: Samples, Events, and Conditions.

Samples represent continuously measured values, while Events represent discrete or state-based changes. Conditions are reported inside a Conditions container and use state-specific elements—such as Normal, Warning, or Fault—rather than a generic condition element. Multiple condition states may be active at the same time, as long as they represent different condition data items.

Each reported data item includes a dataItemId for identification, a timestamp indicating when the value was recorded, and the value itself provided as text content, for example:

<SpindleSpeed dataItemId="S1spd" timestamp="2026-01-30T14:23:17.492Z">2847</SpindleSpeed>

While this hierarchical structure provides a complete and standardized view of the machine, dashboard implementations must traverse multiple levels of nesting and correlate dataItemId values with their definitions in the Devices model to extract and display the data they care about.

Getting Started

Now that we understand the structure of MTConnect and the challenges involved, let's look at how to collect and visualize MTConnect data using FlowFuse.

FlowFuse is an industrial application platform built on Node-RED that brings data collection, transformation, and visualization together in one place. Instead of writing custom integration code, you build flows visually by dragging, configuring, and connecting nodes, then deploying them—no separate tools required.

Prerequisites

Before you begin, you need:

FlowFuse instance – An active FlowFuse account with an instance created and access to the Node-RED Editor. Sign up at https://app.flowfuse.com and follow the FlowFuse getting started guide at https://flowfuse.com/docs/user/introduction/#getting-started-with-flowfuse. If you are new to Node-RED, you can also check out our course on Node-RED.
MTConnect agent – A CNC machine running an MTConnect agent or an MTConnect simulator such as the public agent at agent.mtconnect.org or a locally hosted agent
Network access – Connectivity from the FlowFuse instance to the MTConnect agent's HTTP endpoint, with the FlowFuse Remote Device Agent installed when connecting from cloud-hosted FlowFuse to on-premises machines

Collecting MTConnect Data

Bringing MTConnect data into FlowFuse is the first step toward a live dashboard. While you could use the standard HTTP Request node to query MTConnect agents, which is the most common approach, that method requires manually parsing XML responses and navigating through large nested objects to extract specific data points. In this article, I'll show you an easier way.

The Solution Engine node (node-red-contrib-solution-engine) makes this straightforward because it lets you access any data point directly by its dataItemId, without having to worry about parsing XML or navigating nested structures.

You can install the node by following the instructions in the FlowFuse documentation: Using the Palette Manager.

Once installed, follow these steps to start collecting data:

Add the mtconnect-dataitem node to your canvas and open its configuration.
Enter the host of your MTConnect agent or broker (for example, mtconnect.isoc.net).
Enter the port your agent is listening on.
Path (optional): leave this empty in most cases. The node automatically detects the type of agent or broker and chooses the correct endpoint:
- For SolutionEngine agents, it uses /api/v6/mtc/current.
- For generic MTConnect brokers like mtconnect.isoc.net, it uses /current.
Only fill in this field if your broker uses a custom endpoint that differs from the defaults. Entering /current manually for standard brokers may cause the node to fail.
Enter the dataItemId for the value you want to retrieve.
Once everything is configured, deploy the flow.

To trigger the node, add an Inject node, set the polling interval you want, and connect it to the mtconnect-dataitem node. This will fetch the latest data at regular intervals and send it to your dashboard or other nodes in the flow.

When the node successfully retrieves data, it outputs the following fields: msg.payload (the value), dataItemId, timestamp, sequence, and name. The node also shows the status with a green square when data is found successfully. If the value isn't available, it will display a yellow square.

Building the Dashboard

Now that you're successfully retrieving MTConnect data, the next step is to display it on a live dashboard. FlowFuse makes this straightforward with its dashboard package. You can bind any data item to a visual component, and it updates automatically whenever new data arrives.

Before you start, make sure to install the @flowfuse/node-red-dashboard package to add the dashboard nodes.

For this tutorial, we'll demonstrate two example data points: Controller Mode and Spindle Speed. You can apply the same steps to all other data points as an exercise. I'm using a public MTConnect demo agent (https://demo.mtconnect.org) to make it easy to follow along.

Note: This is a brief demonstration to help you understand the workflow. When building your production dashboard, make sure to use the appropriate host and port for your actual MTConnect agent, and select widgets that best suit your specific monitoring needs and use case.

I've provided additional data points with their dataItemIds below so you can practice. Try to match the dashboard shown in the image below, or create your own layout by selecting different dataItemIds and widget types. For more information on available dashboard widgets, see the FlowFuse documentation: https://dashboard.flowfuse.com/nodes/widgets.

Available Data Points for Practice

Data Item ID	Name	Description
`execution`	Execution State	Program execution status (ACTIVE, READY, STOPPED)
`doorstate`	Door State	Machine door status (OPEN/CLOSED)
`program`	Program Name	Currently loaded program name
`activeprog`	Active Program	Currently executing program
`Tool_number`	Tool Number	Active tool number
`pallet_num`	Pallet Number	Current pallet identifier
`Xabs`	X-Axis Absolute Position	Current X-axis absolute position in mm
`Zabs`	Z-Axis Absolute Position	Current Z-axis absolute position in mm
`Bpos`	B-Axis Position	Current B-axis rotational position
`Cpos`	C-Axis Position	Current C-axis rotational position

Steps to Create the Dashboard

Drag an Inject node onto the canvas, double-click it, and set Repeat to interval for every 1 second.
Drag two mtconnect-dataitem nodes onto the canvas and connect them to the inject node.
Double-click the first mtconnect-dataitem node and configure it: Host: demo.mtconnect.org, Port: 5000, Data Item ID: mode. For the second node, use the same configuration except Data Item ID: Srpm. Click Done for both nodes.
Drag a Text widget onto the canvas and double-click it. Click the + button next to Group to create a new group: Group Name: Machine State, select the page and check Display group name, then click Done.
In the Text widget configuration: Label: Controller Mode:, Layout: Select the 4th option, enable Style option, Font: Default, Text Size: 26, then click Done.

Connect the mode mtconnect-dataitem node output to the Text widget input.
Drag a Gauge widget onto the canvas and double-click it. Create a new group: Group Name: Spindle Speed. In the Gauge widget configuration: Type: Half gauge, Style: Rounded, Value: msg.payload, Range limits: 0 to 10000.
Add three segments by clicking the + button in the Segments section and configure them as shown in the image below.

Connect the Srpm mtconnect-dataitem node output to the Gauge widget input.
Click Deploy in the top-right corner.

To achieve the page layout as shown in the dashboard I have built, follow the Setting Page Layout guide and set it to Notebook.

Your dashboard should now display live updates for Controller Mode and Spindle Speed from the MTConnect agent. You can extend this by adding more data items from the table above, experimenting with different widget types, and organizing them into logical groups for your specific monitoring needs.

Below is the complete flow configuration. If you've successfully built the dashboard following the steps above, you can compare it with this reference implementation:

Conclusion

Your MTConnect dashboard is now live, pulling real-time machine data and displaying it through visual widgets. The setup you've built here works the same way across any MTConnect-compliant machine in your facility.

This is what FlowFuse does—it makes connecting to equipment, collecting data, transforming it into useful formats, and visualizing it on dashboards straightforward. Beyond basic monitoring, you can log production metrics to databases for trend analysis, set up automated alerts when machines enter fault states, integrate shop floor data with MES or ERP systems, and build event-driven workflows that respond to machine conditions. For production environments, FlowFuse Enterprise provides role-based access control, audit logging, high availability infrastructure, and dedicated support—giving you the operational controls needed to run manufacturing applications reliably across multiple facilities.

MQTT vs CoAP: Measure Your Constraints or Pick Wrong

2026-02-05T00:00:00Z

The MQTT vs CoAP debate is mostly noise. One protocol assumes you have infrastructure and want centralized coordination. The other assumes you don't and can't. If you're still debating which is "better," you haven't measured what matters.

MQTT dominates because it solved the hard problem: coordinating thousands of devices through centralized brokers with persistent connections, pub/sub semantics, and delivery guarantees. CoAP survived because some deployments can't afford that solution, not as a tradeoff, but as a physical impossibility. Battery-powered sensors often can't afford long-lived TCP connections (or frequent reconnects), depending on duty cycle, radio, and power budget. Microcontrollers with 16KB RAM can't run MQTT stacks. Mesh networks at the edge can't reach brokers reliably.

These aren't competing protocols. They're answers to incompatible constraints. MQTT requires infrastructure you can reach and connections you can sustain. CoAP requires neither. Pick MQTT for constrained devices, and watch batteries drain in months instead of years. Pick CoAP for cloud-coordinated fleets, and rebuild pub/sub patterns badly.

This article shows what each protocol actually demands, where each fails under real constraints, and why teams consistently choose wrong, not because they pick inferior technology, but because they never validated their deployment requirements.

What Actually Separates These Protocols

To choose between CoAP and MQTT, you need to understand what these protocols do and what architectural assumptions they force on your system.

MQTT uses a publish/subscribe model. Devices publish messages to topics. Other devices subscribe to those topics. A central broker handles routing, persistence, and delivery guarantees. This works well for many IoT scenarios: sensors broadcasting telemetry, commands flowing to actuators, aggregating data from thousands of devices into a single pipeline. The broker decouples publishers from subscribers, enabling flexible topologies and simplified client logic. But it also requires a mandatory intermediary, a single point that must be scaled, secured, and kept reliable.

CoAP uses a request/response model. It mirrors HTTP's client-server architecture but strips the overhead that makes HTTP unsuitable for constrained devices. CoAP runs over UDP by default, supports multicast discovery, and operates peer-to-peer without centralized infrastructure. Resources are addressed using URIs. Clients request data. Servers respond.

This isn't just a difference in wire format. It's a difference in architectural philosophy. MQTT assumes centralized coordination is beneficial. CoAP assumes it may not be necessary or even possible. That distinction shapes how these protocols behave under network failures, how they scale at the edge, and what happens when infrastructure becomes unreliable or unavailable.

Where CoAP Has Real Advantages

CoAP's architectural choices create measurable benefits in three specific scenarios.

Ultra-Constrained Devices

CoAP was built for devices with severe resource limits: sensors running on coin cell batteries for years, microcontrollers with kilobytes of RAM, networks where every transmission costs energy and money. In these environments, MQTT's TCP requirement and broker dependency create overhead that isn't just inefficient, it's prohibitive.

Consider the protocol overhead. An MQTT connection requires a TCP three-way handshake, then protocol negotiation. Even with minimal configuration, that's multiple round trips before any application data moves. For a sensor that wakes once per hour to send a temperature reading, this overhead destroys battery life.

MQTT-SN (MQTT for Sensor Networks) attempts to bridge this gap by adapting MQTT for UDP and removing the TCP requirement. While it reduces some overhead, it still requires gateway infrastructure to translate between MQTT-SN and standard MQTT brokers, preserving the centralized architecture that CoAP avoids entirely.

CoAP uses UDP, has tiny message headers (as small as 4 bytes), and operates without persistent connections. This makes it objectively more efficient. Field deployments of agricultural sensors, building automation, and environmental monitoring have demonstrated power consumption reductions of 40-60% when switching from MQTT to CoAP in ultra-constrained scenarios.

The math is straightforward: fewer transmissions, smaller packets, no connection state. When your device budget is measured in microwatts and your network budget in bytes per day, CoAP is often the only viable option.

Edge Architectures Without Internet Connectivity

CoAP's advantages become more pronounced at the system level. As more processing moves to the edge for latency, bandwidth, or regulatory reasons, the value of a centralized broker decreases. Edge gateways coordinating local sensors, device-to-device communication in factories, deployments where internet connectivity is intermittent or absent, in these scenarios, CoAP's ability to work peer-to-peer without infrastructure is a genuine advantage.

Consider a factory floor with hundreds of sensors and actuators coordinating through a local gateway. With MQTT, every sensor-to-actuator interaction must route through the broker, even when both devices are physically adjacent. The broker becomes a mandatory hop, adding latency and creating a single point of failure.

With CoAP, devices communicate directly. The gateway can still aggregate and forward data to the cloud when needed, but local control loops operate independently. When the internet connection drops, local operations continue. When latency matters, safety interlocks in industrial equipment, eliminating the broker hop can mean the difference between meeting requirements and failing them.

This distinction matters even more in mobile or disconnected scenarios: autonomous vehicles coordinating with roadside infrastructure, offshore platforms where satellite bandwidth is expensive, emergency networks operating with degraded connectivity.

Integration with Web Infrastructure

When distributed systems need to communicate with backend infrastructure, CoAP offers another benefit: it aligns with web semantics. CoAP deliberately mirrors HTTP: URIs, methods (GET, POST, PUT, DELETE), content negotiation, status codes. This means it integrates naturally with RESTful systems, web proxies, and developer tools built around HTTP.

For organizations already using REST APIs, CoAP presents a lower barrier than MQTT's topic-based model. HTTP-to-CoAP proxies are straightforward because the semantic models align. MQTT-to-HTTP bridges require significant translation. Topics must map to endpoints. QoS semantics must adapt. Pub/sub patterns must be forced into request/response or require additional infrastructure like webhooks.

None of this is impossible. Organizations bridge MQTT and HTTP successfully every day. But the mismatch is real and introduces complexity that CoAP avoids by design.

Where MQTT Still Dominates

These CoAP advantages are real. But if we stop here, we miss the bigger picture. MQTT isn't being displaced, and the reason goes deeper than momentum. In most production IoT deployments, MQTT's architectural choices aren't limitations, they're features that solve problems CoAP cannot.

Publisher/Subscriber Decoupling

The pub/sub model is a fundamental decoupling mechanism that enables capabilities difficult or impossible with request/response.

Consider industrial telemetry. Thousands of sensors publishing measurements. Multiple backend systems consuming that data: a time-series database for analysis, a rules engine for alerts, a machine learning pipeline for predictive maintenance, a dashboard for operators.

With MQTT, adding a new consumer is trivial. Subscribe to the topics. The sensors don't know you exist. They don't need reconfiguration or firmware updates. The decoupling is complete.

With CoAP, this becomes complex. If sensors are servers, how do new clients discover them? If sensors are clients pushing data, where do they push? How do you add a destination without reconfiguring every device? You end up rebuilding what a broker provides, service discovery, routing, fan-out, but distributed across your device fleet instead of centralized in infrastructure you control.

This is why MQTT dominates cloud ingestion. When your architecture is about collecting data from many devices and distributing it to many consumers, the broker model is the right abstraction.

Delivery Guarantees

The broker provides something CoAP struggles to match: robust delivery guarantees across unreliable networks.

MQTT's three QoS levels (at most once, at least once, exactly once) are fundamental guarantees many production systems require. CoAP, being UDP-based, offers optional confirmable messages with retransmission. This works for many scenarios, but it's not equivalent to MQTT's QoS 2 (exactly once delivery). If your application cannot tolerate duplicates, financial transactions, command-and-control, state machine updates, MQTT's exactly-once semantics are non-negotiable.

MQTT's QoS guarantees are end-to-end through the broker. Messages can persist to disk. Sessions resume after disconnection. Client state is maintained. This makes MQTT significantly more resilient to network instability and device mobility.

Ecosystem Maturity

These technical advantages are amplified by years of real-world deployment and community investment. MQTT has battle-tested brokers (Mosquitto, EMQX, HiveMQ, VerneMQ). Comprehensive client libraries in every language. Integration with major IoT platforms (AWS IoT Core, Azure IoT Hub) and widely used broker/vendor ecosystems. Monitoring tools, debugging utilities, best practices, and a large community that has solved common problems.

CoAP has matured significantly, but its ecosystem is smaller. This reflects where the use cases are. Cloud ingestion, telemetry aggregation, command and control, these patterns dominate IoT. CoAP's narrower focus on ultra-constrained devices and peer-to-peer edge scenarios means fewer developers encounter it, fewer tools get built, fewer problems get solved publicly.

Network effects matter. When MQTT is the default, more effort improves MQTT tooling, which makes MQTT more attractive, which reinforces its position.

Session State and Message Queuing

MQTT provides another capability CoAP implementers often underestimate: stateful session management.

MQTT's persistent sessions enable offline message queuing. If a device disconnects, battery dies, network drops, enters a tunnel, messages published to its subscribed topics get queued by the broker and delivered when it reconnects. This is invaluable for mobile devices, intermittently connected sensors, and scenarios where guaranteed delivery matters more than real-time delivery. Examples include fleet management tracking vehicles, medical devices uploading telemetry, and remote monitoring in areas with poor connectivity.

CoAP can implement message queuing, but it requires additional infrastructure, essentially building broker-like services for state management and persistence. At which point, you've rebuilt the pattern MQTT provides natively.

Security: Choose Based on What You Can Measure

MQTT and CoAP impose fundamentally different security architectures. MQTT's broker creates a centralized security choke point with TLS-protected connections, certificate-based authentication, and topic-level authorization. This simplifies policy enforcement and audit trails but introduces measurable overhead, a TLS handshake consumes 30-50% of total power for sensors transmitting hourly, prohibitive for ultra-constrained devices where battery life is measured in years.

CoAP distributes security across peer-to-peer networks. DTLS provides encrypted UDP communication with similar handshake costs to TLS. For constrained deployments, OSCORE enables application-layer security without connection establishment, reducing wake time by 60-80%. But this efficiency trades centralized control for distributed key management complexity that scales poorly without additional infrastructure.

The architectural trade-off is concrete: MQTT centralizes authentication and policy enforcement but requires broker infrastructure with power overhead. CoAP eliminates broker dependency but pushes authorization to individual devices, requiring distributed policy updates and log aggregation.

The most common security failure is choosing based on perceived simplicity rather than measured requirements. Teams select MQTT assuming TLS is well understood, then discover field batteries depleting in weeks. Teams choose CoAP to avoid broker dependency, then realize they cannot revoke compromised credentials without manual intervention across distributed devices.

Before choosing, measure connection establishment cost in actual power consumption for your device profile, operational cost of key management at your projected scale, and whether your compliance requirements favor centralized audit trails or distributed authorization. The right security model is the one that matches the operational reality you can actually sustain.

The Measurement Discipline That Matters

What separates successful deployments from failed ones isn't choosing the "better" protocol. It's starting with measured constraints rather than architectural preferences.

The teams that ship working systems know their sensor consumes 12 microamps in sleep and 45 milliamps during transmission. A CR2032 battery provides 235 milliamp-hours. For three-year operation, the math reveals a daily transmission budget of roughly 200 messages. Protocol overhead becomes concrete. Connection establishment costs aren't theoretical, they determine whether you meet requirements or miss by months.

Teams that struggle start with vague requirements. "Low power" sounds reasonable until batteries die early in field trials. "Real-time" invites endless debate until you specify "actuator response within 50 milliseconds for 99% of events." Precision transforms discussion into engineering.

If you need to decouple thousands of publishers from dozens of consumers with guaranteed delivery across unreliable networks, MQTT's broker model provides exactly that. The centralized architecture handles message routing, persistence, and quality of service.

If your constraint is battery operation where every transmission costs operational lifetime, and infrastructure cannot be deployed reliably, CoAP's lightweight UDP approach becomes necessary. TCP overhead and broker coordination would exceed your power budget.

If your system genuinely spans both contexts, use both protocols where each fits. The constraints will make this obvious.

Most failed projects share a common pattern. They selected protocols before measuring deployment reality. They assumed requirements without validation. They copied architectures without understanding the underlying trade-offs. Then field deployment revealed the gaps.

So before choosing between MQTT and CoAP, answer these with measured data:

What is your power budget per device?
What transmission frequency and payload size does your application require?
How does latency behave under network degradation?
During partitions, can operations continue locally or must activity queue?
What do infrastructure costs look like at production scale?

If you cannot answer with measurements, build a prototype. Instrument it. Run it under realistic conditions. Measure power, latency, and costs under stress. Then choose based on evidence, not assumptions.

The protocol debate becomes irrelevant once you measure. MQTT and CoAP each solve distinct problems well. Understand your constraints, and the choice becomes clear.

Agentic AI Reads OPC UA Servers So You Don't Have To

2026-01-30T00:00:00Z

OPC UA servers store everything. Finding anything takes hours.

Your historian has six months of production data across 847 variables. Wednesday's batch failed quality checks. The root cause is in there—a sensor drift, a temperature anomaly, something that happened before the failure became visible. But variables are named ns=2;s=Device1.PLC.DB1.Temp_Sensor_3. The namespace structure was designed for PLC efficiency, not human investigation.

So you click through hierarchies. Cross-reference documentation that's two firmware versions out of date. Export data to Excel. Build correlation matrices. Check timing against process logs. Four hours later, you find it.

OPC UA gave machines a common language. It solved connectivity. But it created an accessibility problem: the data infrastructure that captures everything makes finding specific answers remarkably slow.

The solution isn't better visualization or more dashboards. It's removing humans from the navigation process entirely. AI agents can browse OPC UA servers, pull historian data, run correlations, and surface answers while you're still typing the question.

Why Investigation Remains the Bottleneck

Implementation problems in industrial IoT are largely solved. Teams connect devices, configure historians, and establish data flows with impressive efficiency, especially on platforms like FlowFuse. The wheels fall off when someone actually needs to use that data.

Your monitoring dashboard flags a reject rate spike on Line 3. That's the easy part—alerts work. But dashboards show you symptoms, not causes. Finding the cause means reconstructing what happened in the hours leading up to the spike. Which of the seventy-three variables on Line 3 changed? What correlations exist between the temperature sensors and quality metrics? How does this week's pattern compare to normal operations?

Every operational question follows this pattern. Why did energy consumption spike Tuesday? Which sensor readings predict motor failures? What operating conditions maximize packaging throughput? The questions change. The investigative workflow doesn't—navigate namespaces, extract data, analyze patterns, interpret results. Manual. Every. Single. Time.

Here's what makes this a systemic crisis rather than an annoyance: the data exists. The infrastructure works. But converting data into operational intelligence requires hours of skilled labor per question. So people stop asking questions. They stick to pre-configured dashboards showing metrics someone decided to monitor six months ago. They don't explore. They don't investigate unexpected patterns. They definitely don't do the kind of exploratory analysis that actually drives improvement.

The standard solutions miss the fundamental problem. Hiring more analysts scales linearly at best—you get three people doing manual work instead of one. Building more dashboards only helps when you already know what to monitor. Neither solves for the unexpected question, the one-off investigation, the "something doesn't look right" hunch that requires pulling data you've never looked at before.

What AI Changes

The value proposition is straightforward: Replace manual investigation workflows with automated execution.

Thursday afternoon, Line 3's reject rate spikes. The traditional approach takes six hours minimum if the data's clean and you know exactly where to look: Pull historian data for fifty variables that might matter. Build correlation matrices in Excel. Analyze sensor drift patterns. Cross-reference timing against process logs. Compare current performance against last month's baseline. Pull in a colleague to verify you didn't miss something obvious.

Ask an AI agent: "What changed in Line 3 before Thursday's spike?"

The agent queries your historian across relevant subsystems. Runs timing correlations against the reject rate increase. Identifies statistical anomalies in sensor data. Tests relationships between variables. Flags causation with confidence intervals. Five minutes later you're reviewing root cause analysis, not building it from scratch.

This efficiency compounds across every investigative use case:

Predictive analysis that would take weeks becomes instant queries. Understanding how motor current relates to product quality typically requires extracting time-series data from your historian, cleaning datasets, running statistical tests, validating correlations, interpreting significance—three months of dedicated work. The agent returns correlation matrices with confidence intervals and outlier analysis while you're finishing your coffee.

Compliance documentation that takes weeks to compile generates on demand. Audits need complete OPC UA server documentation—node hierarchies, relationship mappings, system architecture, operational ranges calculated from historical performance. Manually, that's weeks of browsing address spaces and organizing specifications. The agent generates it directly from live server metadata and your historical data. Infrastructure changes next quarter? Regenerate the documentation instead of manually updating deprecated specs.

Pattern recognition at scale becomes feasible. Agents analyze patterns across days, weeks, months of continuous operation—patterns humans miss because they require simultaneous analysis of thousands of variables. "Show me every instance where Variable_A spiked within ten minutes of Variable_B changing" becomes a query you actually ask instead of a question you abandon because the manual investigation would take too long.

The mechanical work executes automatically: namespace navigation, data retrieval, correlation testing, anomaly detection. Your time goes to what requires actual judgment—interpreting analytical findings against operational knowledge, deciding whether to adjust processes or schedule maintenance. Questions you'd previously skip because investigation overhead exceeded potential value become queries worth asking.

The Technology Behind It

FlowFuse makes this work through a straightforward architectural approach that connects AI reasoning to industrial data systems.

As an industrial data platform, FlowFuse already handles connectivity to OPC UA servers, historians, and other industrial systems. The new capability comes from MCP nodes that expose this connectivity through the Model Context Protocol—a standardized interface that lets AI systems interact with any data source using common operations like browse, read, query, and analyze.

Here's how it flows: You ask your AI agent a question in natural language. The agent translates that into MCP operations—browse this namespace, retrieve these variables, analyze this time range. FlowFuse receives those operations and executes them against your actual infrastructure, handling all the OPC UA protocol complexity, session management, and security. The agent gets back structured data, interprets it, and gives you an answer.

High-level architecture diagram showing the interaction between Al agents and industrial systems via the FlowFuse Platform.

The architecture separates concerns cleanly. AI handles the reasoning—figuring out what data matters and how to interpret it. FlowFuse handles the execution—dealing with industrial protocols, data access, and system integration. Neither tries to do the other's job.

For teams building their own integrations, the implementation details are documented here: Building MCP Server Using FlowFuse

Watch It Work

The video below shows an AI agent generating complete OPC UA server documentation on request—finishing in minutes what typically requires weeks of manual effort.

What This Unlocks

Connecting agents to OPC UA infrastructure delivers capabilities manual investigation can't match at scale.

Autonomous navigation across address spaces. Agents read node hierarchies, examine metadata—DisplayNames, EngineeringUnits, data types, access levels—follow references between nodes, build structural understanding of systems. You describe what you need, agent locates relevant nodes. No memorizing namespace paths or node IDs. Looking for a pump's discharge pressure sensor buried five levels deep in your hierarchy? Agent finds it by understanding equipment relationships, not because someone documented the exact path.
Automated data analysis across historians. Agents pull historical data, run statistical tests, calculate correlations, detect anomalies, compare time periods, validate significance. Ask "How does ambient temperature affect motor current draw on Line 2?" and get months of historian data analyzed—variables correlated, confounding factors accounted for, confidence intervals calculated. Manual approach means days of Excel work: extraction, cleaning, statistical analysis, validation. Agent returns analyzed results in minutes while you're still drinking your coffee.
Pattern recognition at operational scale. Agents analyze patterns across days, weeks, months of continuous operation—patterns humans miss because they require simultaneous analysis of thousands of variables. "Show me every instance where Variable_A spiked within ten minutes of Variable_B changing" becomes a query you actually ask instead of a question you abandon. Finding subtle leading indicators of equipment degradation across hundreds of sensors? Agent correlates every variable combination, identifies statistically significant patterns, surfaces predictions. Doing this manually would take months of dedicated work. Nobody attempts it because nobody has months to spare.

Investigation capabilities that previously required dedicated data science teams become natural language queries. Complex analyses finish in minutes instead of weeks. Questions you'd skip because the investigation wasn't worth the effort become routine operational intelligence you actually use.

The Bigger Picture

The value in industrial data was never about collection—it was always about the questions that data could answer. Those questions just cost too much time to pursue. When investigation drops from hours to minutes, the economics change completely. Different questions become worth asking. Documentation stays current because updating it is on-demand instead of weeks of work. Pattern analysis across thousands of variables becomes routine instead of heroic.

This isn't about replacing people with automation. It's about making the data infrastructure you already built actually useful for the decisions it was meant to inform. Your team still interprets results, makes judgment calls, and takes action. The AI just handles the mechanical work of data access and analysis.

And it's not limited to OPC UA. FlowFuse's MCP approach works the same way across any industrial system—MQTT brokers, Modbus devices, SQL databases, REST APIs, whatever protocols you're running. Same natural language interface, same investigation capabilities, different underlying systems. The infrastructure you have becomes the infrastructure you can actually use.

Why Modbus Refuses to Die

2026-01-26T00:00:00Z

Modbus is 47 years old and has no built-in security. By every measure, it should have been obsolete a decade ago. OPC UA, EtherNet/IP, MQTT, Profinet: modern protocols with semantic modeling, encryption, and real-time capabilities arrived backed by billions in vendor investment and industry standardization efforts.

Yet in 2026, new equipment still ships with Modbus as the primary interface. Not tucked away for backward compatibility, but front and center as the deliberate first choice.

What's keeping a protocol from 1979 alive when everything about industrial automation has changed?

The Installed Base Reality

Manufacturing facilities don't replace working automation systems. They just don't. A plant manager looks at a control panel full of PLCs and motor drives from 2005, all communicating via Modbus, all running production smoothly, and the conversation ends there. Finance already depreciated that equipment over fifteen years. Maintenance has spare parts stocked. Operators know how to troubleshoot it. Why would anyone rip that out?

The equipment wasn't designed for short lifecycles. Industrial PLCs typically last around 10 to 20 years depending on environment and maintenance. Process industry equipment like pumps, transmitters, and valves often hits 20-30 years before replacement becomes necessary. The average age of manufacturing equipment in the US is close to 20 years, and since 1990, the age of assets has virtually doubled. Not because companies can't afford upgrades. Because the equipment still works.

That creates a problem for protocol modernization. You can't swap out a few devices at a time. Industrial networks are interconnected systems where everything talks to everything else. Upgrading means either taking down the entire line for a coordinated replacement, or maintaining parallel communication infrastructure during a phased migration. Both options are expensive, risky, and deliver zero production benefit.

The numbers show how big this problem is. The Modbus TCP market alone was $1.35 billion in 2024, projected to hit $2.55 billion by 2032. That's not legacy support. That's active growth. Companies are buying new Modbus devices in 2026 to integrate with Modbus networks from 2006.

It Costs Almost Nothing

The economics of Modbus implementation are absurdly compelling. A basic Modbus RTU interface costs manufacturers maybe $5-10 in components. Software licensing? Zero. The protocol is completely open, no royalties, no certification fees, no vendor lock-in. Compare that to implementing industrial Ethernet protocols where you might pay thousands for stack licenses, certification processes, and conformance testing.

For device manufacturers, this matters enormously. A sensor company can add Modbus support for trivial cost and immediately become compatible with millions of existing installations. The development effort is minimal: the protocol specification fits in a few dozen pages, implementations are straightforward, and countless reference designs exist. You don't need specialized silicon or complex firmware. A basic microcontroller with a UART can speak Modbus RTU. Add an Ethernet chip and you've got Modbus TCP.

This simplicity extends through the entire supply chain. Integrators don't need expensive training or specialized tools. A laptop, some free software, and basic understanding of serial communication gets you started. Troubleshooting requires nothing more sophisticated than a protocol analyzer, or in many cases, just watching register values change. The barrier to entry is so low that maintenance technicians can learn Modbus basics in an afternoon.

The contrast with modern protocols is stark. OPC UA requires understanding information modeling, certificate management, and complex security configurations. Profinet demands precise timing requirements and specialized hardware. EtherCAT needs real-time capable network controllers. Each adds cost, complexity, and dependencies. Each creates opportunities for things to go wrong.

The Vendor-Neutral Advantage

Perhaps Modbus's greatest strength is that nobody owns it. Modicon created it in 1979, but the rights now belong to the Modbus Organization, a trade association that maintains the specification as an open standard. This means no single vendor can kill it, paywall it, or steer it toward proprietary extensions.

Industrial automation is full of protocol wars where vendors push their preferred standards. Rockwell champions EtherNet/IP. Siemens invested heavily in Profinet. Every major automation vendor has protocols they'd rather you use: protocols that tie you into their ecosystem, their training programs, their support contracts.

Modbus doesn't care. It works with everyone's equipment. This vendor neutrality has enormous practical value in facilities running mixed automation systems. A typical factory floor might have Rockwell PLCs, ABB drives, Schneider Electric power meters, and Siemens HMIs all talking to each other. Getting all those vendors' preferred protocols to coexist would be a nightmare. Getting them all to speak Modbus is trivial.

This creates competitive pressure that keeps Modbus relevant. Device manufacturers can't afford to skip Modbus support because doing so immediately excludes them from projects with heterogeneous automation systems. Even vendors with their own sophisticated protocols implement Modbus as a fallback, ensuring interoperability when nothing else works.

The open nature also prevents the protocol from becoming a competitive weapon. Nobody can leverage Modbus to lock customers into their platform. Nobody can obsolete older Modbus devices by dropping support in newer products. The protocol's longevity is guaranteed by the fact that no single entity controls its fate.

The Technical Case for Modbus

Beyond the strategic and economic reasons, Modbus delivers real technical advantages that matter when you're building and maintaining industrial systems:

Brutally simple operation. Modbus does exactly one thing: it reads and writes registers. No object models, no service-oriented architecture, no semantic layers. Just addresses and values. When a motor drive fails at 3 AM, the maintenance technician doesn't want to debug XML schemas or navigate object hierarchies. They want to see if register 40001 is returning the right value. The diagnostic process is straightforward: Can you communicate? Are you reading the right address? Is the value correct? Done.

Predictable and lightweight. Modbus frames are small: RTU maxes out at 256 bytes, TCP at 260 bytes. The protocol data unit itself can't exceed 253 bytes. This minimal overhead works fine on 9600 baud serial links still common in older facilities. No state to manage, no synchronized clocks, no microsecond timing requirements like industrial Ethernet protocols demand.

Trivial to implement. A basic Modbus stack runs on 8-bit microcontrollers with as little as 10KB flash and 1.5KB RAM. On a PIC16F1827 with 7KB program memory and 384 bytes of data RAM, a complete Modbus RTU implementation uses roughly a quarter of total resources. The entire protocol specification runs maybe 150 pages total. A competent embedded developer can knock out a working implementation in days, not months.

Debugging is transparent. Register 40001 is register 40001, period. Hook up a protocol analyzer and you see the raw data: device address, function code, register address, value, CRC. No security? That's one less thing to troubleshoot. No discovery mechanism? That's fine, you configured the addresses once during commissioning and they never change. No data typing beyond basic registers? Perfectly adequate when you know a particular register holds temperature in tenths of degrees Celsius.

Universal compatibility. Same protocol on RS-485, RS-232, TCP/IP, even UDP. Modbus devices are addressed from 1 to 247 on serial networks. Converting between Modbus RTU and Modbus TCP is trivial: cheap gateway boxes handle it automatically. You can broadcast to all devices using address 0 for synchronized updates. Modbus devices from different manufacturers actually interoperate. Not in theory, in practice. A Modbus master from Company A will communicate with a Modbus slave from Company B without negotiation, configuration wizards, or integration consultants.

Fast enough for most applications. Typical Modbus response time is under 10 milliseconds for 90% of exchanges, though it can occasionally stretch to 150ms depending on device processing. That's plenty fast for process control, monitoring, and most industrial automation tasks. Not fast enough for coordinated motion control, but that's not what Modbus was designed for.

Reliable error detection. Modbus RTU uses CRC-16-MODBUS for error checking. Modbus ASCII uses longitudinal redundancy check (LRC). Modbus TCP relies on TCP's built-in data integrity. Each message is independent: no session state means no state corruption. Simple design means fewer things break when a sensor sits in a 60°C cabinet or -20°C freezer for twenty years.

These technical advantages translate directly to faster development cycles, simpler troubleshooting, lower hardware costs, and more reliable operation in harsh industrial conditions where complex protocols would create more failure points.

When Modern Protocols Actually Win

Modbus's strengths become liabilities when you need capabilities beyond simple register polling. There are entire classes of industrial applications where choosing Modbus means accepting fundamental limitations that modern protocols solve elegantly.

Try running a multi-axis CNC machine or coordinated robot cell over Modbus and you'll understand why EtherCAT exists. Modbus operates on a poll-response cycle: the master asks, the slave answers, repeat. At 115.2 kbaud, you're looking at 25-50 milliseconds per device minimum.

Stack up ten servo drives that need position updates synchronized within microseconds, and Modbus simply cannot deliver. EtherCAT, Profinet IRT, and SERCOS III provide deterministic cycle times under 1 millisecond with jitter measured in nanoseconds. This isn't a performance difference, it's a capability gap. Motion applications requiring sub-millisecond synchronization across multiple axes have no choice but to use these specialized protocols.

Modbus gives you registers. That's it. Register 40023 could be motor temperature, error flags, or the number of production cycles: you only know because someone documented it somewhere. Scale this to a facility with thousands of data points across hundreds of devices and the maintenance burden becomes crushing.

OPC UA solves this with information modeling that makes data self-describing. A temperature sensor doesn't just expose a value, it exposes metadata about units, range, accuracy, and context. When you're building systems that need to automatically discover capabilities, validate configurations, or provide rich HMI experiences, OPC UA's semantic layer isn't optional overhead: it's the foundation that makes complexity manageable.

For decades, industrial networks lived behind air gaps and Modbus's lack of authentication didn't matter. Those days are over. Modern facilities need remote monitoring, cloud analytics, vendor support access, and integration with enterprise IT systems.

The moment you connect to external networks, Modbus's plaintext communication and zero authentication become indefensible. An attacker with network access can send arbitrary commands to any Modbus device. No password, no certificate, no audit trail.

OPC UA provides TLS encryption, certificate-based authentication, role-based access control, and detailed audit logging. MQTT with Sparkplug B adds lightweight security for IIoT deployments. These aren't nice-to-have features when you're connecting critical infrastructure to the internet: they're requirements. Companies implementing Industry 4.0 initiatives, remote operations, or cloud-based analytics cannot build on Modbus. The protocol has no security model to extend.

Modbus RTU at 115.2 kbaud can theoretically handle around 80-100 transactions per second under ideal conditions, but real-world installations see more like 40-60 due to device processing time and network overhead. That's fine for a few dozen devices with slow-changing process variables.

It collapses when you need high-resolution data from hundreds of sensors. Environmental monitoring systems, vibration analysis, or energy metering across large facilities quickly saturate Modbus networks. Even Modbus TCP, while faster, lacks the bandwidth efficiency of modern protocols.

MQTT's publish-subscribe model eliminates polling overhead entirely. Profinet and EtherNet/IP use producer-consumer architectures that scale better. When data volume grows beyond simple polling scenarios, Modbus becomes the bottleneck.

If you're building a new plant from scratch with modern equipment and no legacy constraints, defaulting to Modbus is choosing 1979 technology for 2026 problems. You lose semantic modeling, security, diagnostic capabilities, and future-proofing.

The cost argument weakens too: modern industrial Ethernet switches and device interfaces aren't dramatically more expensive than RS-485 infrastructure when you factor in reduced wiring labor. The real question is whether you're building for today's requirements or tomorrow's.

Modbus works great until you need asset monitoring, predictive maintenance, cloud integration, or advanced analytics. Then you're ripping out infrastructure you just installed.

Modbus TCP added IP networking but fundamentally remained a register-based polling protocol. There's no roadmap for features industrial facilities increasingly need: time synchronization, alarm management, historical data access, file transfer, or complex data types.

Modern protocols continue evolving. OPC UA added pub-sub models, field-level communications, and TSN integration. The Modbus specification is essentially frozen because any significant changes would break the simplicity that makes it useful. This works fine in stable applications but becomes a ceiling when operational needs expand beyond what the protocol was designed for forty-six years ago.

The Hybrid Reality

The industry has settled on a hybrid reality that favors encapsulation over replacement. Edge gateways now act as the primary translators, speaking Modbus to legacy hardware while providing secure MQTT or OPC UA feeds to the cloud. This allows maintenance teams to keep their reliable hardware while IT departments receive the structured, authenticated data they require for modern analytics.

Network segmentation becomes the security strategy. Critical Modbus networks stay isolated from the internet. Remote access happens through VPNs and jump boxes. Protocol gateways enforce security boundaries. It's more complex than native security in modern protocols, but it works with equipment that was never designed for network security in the first place.

The result is a patchwork that reflects industrial reality rather than protocol purity. Modbus handles what it does well: simple, reliable communication with field devices. Modern protocols handle what Modbus can't: semantic data, security, cloud integration. The two worlds coexist because forcing a single protocol across all applications would be both technically limiting and economically wasteful.

This approach proves that Modbus survives not because it's technically superior, but because it solves real problems with minimal friction. The protocol succeeded by being simple enough that anyone can implement it, cheap enough that everyone does, and reliable enough that nobody has to think about it.

FlowFuse is the industrial data platform designed to bridge this gap between legacy Modbus registers and modern enterprise systems. Our platform provides the connectivity and security layers needed to transform aging infrastructure into a secure, data-driven operation.

MQTT vs OPC UA: Why This Question Never Has a Straight Answer

2026-01-21T00:00:00Z

The question itself is broken.

MQTT moves messages. OPC UA defines meaning. They operate at different layers of the stack. Comparing them is like comparing TCP to JSON.

Yet the debate persists. Vendors position them as competitors. Consultants bill by the complexity. Your procurement department demands a choice.

The industry knows better. OPC UA includes MQTT in its spec. Real factories use both: MQTT for telemetry, OPC UA for machine coordination. The technologies have been converging over time.

The persistent debate exists because the distinction between their purposes remains unclear to many decision-makers.

This article explains what each does, where they differ, and how to decide based on requirements instead of marketing.

What Each Actually Does

The confusion starts with a category error. Asking "MQTT or OPC UA?" is like asking "HTTP or PostgreSQL?" One moves bytes. The other organizes meaning.

MQTT: The Minimalist Messenger

MQTT is a publish-subscribe messaging protocol designed in 1999 for satellite oil pipeline monitoring. It does exactly one thing: move small messages between devices over unreliable networks with minimal overhead.

The entire protocol is remarkably compact:

Publishers send messages to named topics. Subscribers express interest in topic patterns. A broker routes messages from publishers to matching subscribers. That's it.

Device A publishes: "factory/line3/temperature" → 72.4
Device B subscribes: "factory/line3/#"
Broker delivers: Device B receives 72.4

MQTT's three quality-of-service levels handle network reality:

QoS 0: Fire and forget. Message might arrive. Might not. Zero guarantees.
QoS 1: At least once delivery. Message arrives one or more times. Duplicates possible.
QoS 2: Exactly once delivery between client and broker, using a four-way handshake.

The protocol header is 2 bytes. A temperature reading with topic and payload fits in under 50 bytes. This efficiency matters when you're transmitting over cellular networks, paying per kilobyte, or running on battery-powered sensors.

What MQTT doesn't provide:

MQTT has no concept of data types. That "72.4" could be Celsius, Fahrenheit, or an error code; the protocol doesn't know or care. It doesn't validate message structure, enforce schemas, or understand relationships between data points. Topic namespaces are conventions, not specifications. factory/line3/temp and factory/line3/temperature and line3/factory/temp are entirely different topics with no semantic relationship.

The broker is a single point of failure unless you architect clustering separately. Security implementation depends on broker configuration; MQTT itself focuses on message transport. Discovery mechanisms must be implemented externally; subscribers must know exact topic names in advance or use wildcards and filter received messages.

MQTT is deliberately minimal. This simplicity at the transport layer enables its flexibility and efficiency.

OPC UA: The Semantic Framework

OPC UA (Unified Architecture) isn't primarily about moving data; it's about describing what data means, how it relates to other data, and what operations are valid.

Released in 2008, OPC UA replaced a fragmented collection of Windows-only industrial protocols with a platform-independent standard. Where MQTT is minimal, OPC UA is comprehensive. The specification spans 37 parts in the core specification covering everything from information modeling to historical data access to alarm conditions

At its core is the address space, a hierarchical graph of nodes:

Every piece of industrial equipment is modeled as a connected set of typed nodes. A motor isn't just a collection of variables; it's an object with defined properties, methods, and relationships.

Motor (ObjectNode)
├── Speed (VariableNode: Double, Engineering Units: RPM)
├── Temperature (VariableNode: Float, Range: 0-150°C)
├── Status (VariableNode: Enum {Running, Stopped, Fault})
├── Start() (MethodNode: Returns StatusCode)
└── ConnectedTo → Pump_A (Reference: HasComponent)

The type system is rich. Variables carry metadata: engineering units, valid ranges, historical access, alarm limits. References define relationships: hierarchical containment, semantic associations, type inheritance.

Companion specifications extend this model for specific industries:

The Euromap 83 specification defines a complete injection molding machine in OPC UA terms: every sensor, every actuator, every state transition. A client connecting to any Euromap 83 compliant machine encounters the same address space structure. Software written for one machine works with any conforming machine, no custom integration required.

This semantic interoperability is OPC UA's primary value. Two systems can exchange meaningful information without prior coordination because the information model is standardized, not just the byte format.

OPC UA provides multiple interaction patterns:

Data access: Read/write variables synchronously
Subscriptions: Monitor variables, receive change notifications
Methods: Execute operations on server objects (start motor, set recipe)
Events: Structured alarm and event notifications
Historical access: Time-series query interface
PubSub (Part 14): Publish address space updates to message brokers, including MQTT

Security is integrated. Certificate-based authentication, message signing, and encryption are specification requirements, not implementation options. Every OPC UA server must support security policies.

The tradeoff is implementation complexity:

Implementing an OPC UA server requires managing an address space, handling multiple services, maintaining subscriptions, and processing security handshakes. Client libraries are measured in megabytes, not kilobytes. A simple "read a value" operation involves session establishment, service negotiation, and potentially certificate exchange.

This overhead is impractical for battery-powered sensors with infrequent reporting requirements. It's appropriate for a $2M manufacturing cell where understanding that a temperature reading represents "bearing temperature on the output shaft of motor 3, measured in Celsius, with a normal operating range of 40-65°C and critical alarm at 85°C" matters.

The Layer Mismatch

Think about the OSI model, that seven-layer networking abstraction everyone learns and immediately forgets:

MQTT operates at the application layer of the OSI model. It is a messaging protocol that happens to carry application data, but what that data represents is outside its scope.

OPC UA also operates at the application layer. It defines data models, type systems, and semantic relationships. Transport is abstracted; OPC UA can run over TCP, HTTPS, WebSockets, or MQTT.

Comparing them is comparing different architectural concerns:

MQTT answers: "How do I efficiently move this message from publisher to subscriber?"
OPC UA answers: "What does this data represent, and how does it relate to other data?"

They're not competing solutions to the same problem. They're solving different problems that happen to intersect in industrial automation architectures.

The Convergence

OPC UA Part 14 specifies OPC UA PubSub, a publish-subscribe model that can use MQTT as its transport mechanism. An OPC UA server publishes address space updates as MQTT messages encoded with OPC UA's type information.

MQTT Sparkplug B introduced structured payloads inspired by OPC UA’s semantic modeling concepts, adding type definitions and metric metadata to MQTT payloads. A Sparkplug message doesn't just carry "72.4"; it carries "Temperature (Float32, Engineering Units: °C, timestamp: 1704470400000) = 72.4".

The technologies are converging, not diverging. Industry 4.0 architectures increasingly use both: OPC UA for machine-to-machine communication where semantic interoperability matters, MQTT for high-frequency telemetry where bandwidth efficiency matters, and OPC UA PubSub over MQTT where both matter.

Yet vendor marketing, procurement processes, and consultant billable hours perpetuate the false choice. The question isn't "which one?"; it's "which one for what?"

Where They Actually Differ

Understanding real differences requires moving past marketing claims to examine what each technology optimizes for and what constraints it accepts as tradeoffs.

Network Assumptions

MQTT was designed for unreliable networks. The protocol was built for satellite links where latency is measured in seconds and packet loss is expected. QoS levels give explicit control over delivery guarantees versus bandwidth cost. The persistent session feature lets devices reconnect after network interruptions and resume exactly where they left off, receiving any messages published while offline.

OPC UA was designed for reliable networks and builds on that foundation. The request-response model expects millisecond response times. Session management assumes stable connections. Historical access and complex queries make sense when networks can support them. Running OPC UA over cellular or satellite links works, This operates outside the protocol’s primary design parameters.

This difference cascades into deployment patterns. MQTT excels when you're collecting data from thousands of remote assets: wind turbines, pipeline sensors, fleet vehicles. OPC UA excels when you're integrating systems within a plant where network quality is controlled and semantic understanding matters more than last-mile efficiency.

Discovery and Configuration

Walk up to an OPC UA server with a generic client. Hit the discovery endpoint. The server returns its complete address space: every node, every relationship, every available operation. You can browse the hierarchy, inspect type definitions, and understand capabilities without reading documentation. The server is self-describing.

MQTT itself does not define a discovery mechanism; discovery is typically handled through external conventions or platform-specific tooling. Topic structures and available data must be known in advance or determined through external documentation. The broker doesn't know what topics exist until something publishes to them. Subscribers must know exact topic patterns in advance or use wildcards and filter everything they receive. Topic naming is pure convention with no enforcement.

This reflects philosophical differences. OPC UA optimizes for systems integration where understanding what's available matters. MQTT optimizes for data distribution where publishers and subscribers coordinate through external mechanisms: configuration files, documentation, human agreement.

In practice, MQTT deployments build discovery and schema management in separate layers. Sparkplug defines topic namespaces and birth certificates that announce available metrics. Cloud platforms provide device registries and schema repositories. These additions extend MQTT's core capabilities to address requirements in complex industrial systems.

State and Synchronization

OPC UA maintains state. The server knows current variable values. Clients can read the current state at any time. Subscriptions detect changes and notify clients. If a client disconnects and reconnects, it can query what changed during the outage. The historical access service provides time-series queries.

MQTT focuses on message transport rather than state management. The broker routes messages but doesn't track values. If you want the current temperature, someone has to publish it after you subscribe. The "retained message" feature lets the broker store the last message per topic, but that's a single value with no history or change tracking. There's no way to query "what happened between 2PM and 3PM yesterday?"

This difference shapes architecture. OPC UA servers are often treated as authoritative sources of truth within an architecture. MQTT systems require separate databases if historical data or current state matters. Time-series databases like InfluxDB or Timescale became standard MQTT architecture components specifically because MQTT itself doesn't retain data.

Security Models

OPC UA integrates security into the specification. Every implementation must support certificate-based authentication and encrypted sessions. Security policies are negotiated during connection establishment. Message signing and encryption are first-class protocol features. The specification defines exactly how certificates should be managed, what cipher suites are allowed, and how security auditing works.

MQTT delegates security implementation to the broker and transport layer rather than defining it within the protocol specification. MQTT 3.1.1 supports username/password authentication and expects TLS encryption to happen at the transport layer, but these are optional features. Securing an MQTT deployment means configuring the broker correctly, managing TLS certificates, implementing access control lists, and possibly adding an authentication service. Two MQTT brokers can have completely different security characteristics.

MQTT 5.0 added enhanced authentication mechanisms, but security remains a broker implementation concern rather than a protocol guarantee. In practice, MQTT security depends on broker configuration and deployment choices, ranging from open development environments to enterprise-grade implementations with full authentication and encryption.

For regulated industries (pharmaceuticals, food processing, utilities) OPC UA's integrated security approach often simplifies compliance documentation, as the protocol specification itself defines security requirements rather than depending on correct broker configuration.

Bandwidth and Overhead

MQTT's 2-byte header and compact binary format minimize overhead. Publishing a temperature reading consumes roughly 50 bytes including topic and payload. Over a cellular connection transmitting 10,000 readings per day, that's under 500KB. At $1 per megabyte (typical M2M cellular rates), you're paying $0.50 per device per day just for bandwidth.

OPC UA's overhead varies by transport, but even optimized binary encoding uses hundreds of bytes per value due to security handshakes, message signatures, and type information. The same 10,000 readings might consume 5-10MB. At cellular data rates, that's $5-10 per device per day.

For battery-powered remote sensors, this difference determines project feasibility. For plant-floor equipment connected via ethernet, it's less significant. The question isn't which protocol has less overhead; it's whether that overhead matters in your deployment.

Scalability Patterns

MQTT scales horizontally through broker clustering. Mosquitto, EMQX, and HiveMQ all support distributed deployments where multiple broker instances share message routing. Add brokers as subscriber count grows. Millions of devices can publish to a broker cluster, and the brokers handle distribution to subscribers.

OPC UA scales through federation and aggregation. An aggregation server connects to multiple OPC UA devices, presents a unified address space, and handles client connections. Clients connect to the aggregator instead of individual devices. Adding devices means configuring the aggregator, not changing the client.

These patterns fit different problems. MQTT's approach works when you're collecting data from massive device fleets. OPC UA's approach works when you're building a plant information system that integrates hundreds of machines.

The Unified Namespace Question

"Just use Unified Namespace" appears in every MQTT versus OPC UA discussion, framed as the answer that makes protocol choice irrelevant.

It is not sufficient.

UNS is an integration pattern: all plant data flows through a central MQTT broker with hierarchical topics. Systems publish once. Systems subscribe to what they need. Instead of 200 point-to-point connections, you have one hub. Add systems without breaking existing integrations. This solves real problems in brownfield plants.

But UNS doesn't eliminate protocol choice. It relocates it.

Your OPC UA machines still speak OPC UA. Edge gateways consume that semantic data, translate it to MQTT Sparkplug, and publish to the UNS broker. Protocol choice happens at the edge. Your MES connects via OPC UA when it needs semantic precision, subscribes via MQTT when it just needs telemetry. Same downstream system, different protocols for different needs.

UNS centralizes data flow. It doesn't centralize protocol decisions; those still happen at every connection point based on the same factors: semantic requirements, bandwidth constraints, scale characteristics, native support.

The question changes from "MQTT or OPC UA for everything?" to "MQTT or OPC UA for this specific connection?"

UNS is valuable architecture. It's not a protocol substitute.

How to Actually Decide

Most protocol comparisons start with feature matrices. Yours should start with data flow diagrams.

Map your requirements first, not your preferences. Draw every connection in your architecture. Each arrow represents a data flow with distinct characteristics that should guide protocol selection. A temperature sensor transmitting hourly readings over satellite has fundamentally different needs than a CNC machine coordinating with your MES where both systems must agree on what "cycle complete" means.

Consider four factors for each data flow:

1. Semantic requirements

Do the connected systems need shared understanding of what data means? If your MES and machines must coordinate on production states, downtime codes, and quality parameters, OPC UA's information modeling provides that common language. If you're collecting sensor data for ML analysis where patterns matter more than metadata, MQTT with basic context suffices.

2. Network constraints

Let the infrastructure decide. Gigabit plant ethernet makes protocol overhead less critical; choose based on semantic needs. Cellular links where you pay per megabyte make the difference between MQTT's 50-byte messages and OPC UA's kilobyte handshakes a line-item cost. Satellite connections with multi-second latency benefit from MQTT's QoS handling regardless of other factors.

3. Native protocol support

Work with your equipment, not against it. Siemens PLCs, Rockwell controllers, and Schneider drives speak OPC UA natively. AWS IoT expects MQTT. HiveMQ clusters scale MQTT efficiently. Leveraging native support reduces integration complexity.

4. Scale characteristics

Five hundred vibration sensors streaming to cloud storage align with MQTT's horizontal scaling through broker clusters. Fifty machines requiring discovered operations and validated method calls align with OPC UA's self-describing address spaces. Different problems, different optimal solutions.

For example, you're connecting 50 CNC machines, 500 environmental sensors, MES, predictive maintenance, and cloud analytics.

- Machines → Edge: OPC UA (semantic interoperability for production coordination)
- Sensors → Edge: MQTT (efficient collection at scale)
- Edge → Cloud: MQTT Sparkplug (metadata preservation with bandwidth efficiency)  
- Edge → MES: OPC UA (shared understanding of manufacturing operations)

Four data flows, two protocols, zero false choices. The architecture reflects requirements, not vendor marketing.

The pattern emerges naturally: OPC UA where systems must share meaning. MQTT where efficiency and scale matter. OPC UA PubSub when you need both. Protocol choice becomes a local optimization within each data flow, not a global architecture decision that locks you into one approach.

Moving Forward

The persistence of this debate reveals something: we're still thinking protocol-first instead of problem-first.

Stop asking "which protocol?" Start mapping your actual data flows and constraints. That pipeline sensor? MQTT. That machine coordination? OPC UA. That edge-to-cloud telemetry? Sparkplug. The modern industrial stack uses multiple protocols because different problems have different optimal solutions.

The convergence technologies (OPC UA PubSub, MQTT Sparkplug, edge gateways) prove the industry already knows this. Protocol choice is becoming a local optimization, not a global architecture decision.

Your next project: map requirements first, select protocols second. Use semantic modeling where systems must share meaning. Use efficient messaging where scale and bandwidth matter. Use both when both matter.

The right question isn't "MQTT or OPC UA?"

It's "MQTT where? OPC UA where? Both where?"

Answer that based on your requirements, not vendor marketing.

Beyond Kepware: Why Modern Industrial Connectivity Demands a Second Look

2026-01-16T00:00:00Z

Kepware isn't chosen, it's assumed. It appears in budgets like line items for electricity or insurance. No one questions it. No one compares it. It just... goes in.

And that's exactly the problem. You've been paying luxury car prices, often well into six figures, for a data shuttle bus. Reliable? Sure. But while Kepware moves your data, it also moves your money straight into per-tag, per-connection licensing fees that explode as you scale. Worse, you don't control your own data. And now, with TPG's $600 million acquisition closing in early 2026, you're betting on a company mid-transition, mid-uncertainty, mid-everything.

The question isn't whether Kepware works. It's whether you can afford to keep not asking better questions.

Why You Picked Kepware (And Why That Made Sense)

Before we talk about why Kepware shouldn't be your next choice, let's acknowledge why it was your last one. Because the logic that got you here wasn't wrong, it was just incomplete.

You didn't choose Kepware. Kepware chose you.

Your integrator spec'd it. The equipment vendor had already validated it. Your boss signed off without discussion because "everyone uses Kepware." When you're staring down a plant expansion deadline with production breathing down your neck, safe beats optimal every time.

And Kepware was safe. Until the bills started compounding.

$15,000 for the initial license seemed reasonable. Then came additional tags for the new production line. New drivers for equipment you hadn't planned for. A redundant server because IT flagged single points of failure. Eighteen months later, you're at 20x annually, and nobody remembers approving half of it.

Here's what actually happened: Kepware didn't win on technical merit. It won on timing and driver ubiquity.

In the early 2000s, industrial connectivity was genuinely hard. Proprietary PLC protocols. Sparse documentation. Vendors actively hostile to third-party integration. Kepware invested aggressively in driver development, by 2010, if a PLC existed in North America, Kepware almost certainly supported it. That created a network effect system integrators couldn't ignore. Standardization followed. Equipment vendors tested against it. PTC's $100 million acquisition in 2016 cemented the strategy.

You didn't get tricked. Lock-in happened through entirely normal operations.

But here's what the sales process never highlights: escalating switching costs aren't a side effect. They're the business model.

Your goal was never "buy Kepware." Your goal was to move OT data where it matters, fast, reliably, without unnecessary drama.

Kepware Pricing Explained: How Costs Escalate as You Scale

The ROI spreadsheet your vendor showed you was accurate. It just ended when the story was just beginning.

You approved Kepware because the first-year quote made sense: base license, sufficient tags for operations, drivers for your PLCs. Number aligned with budget. Decision closed.

Then your plant didn't stop.

New production line? More tags needed. Different PLC brand? New driver license. Maintenance kicks in at 18-20%, calculated not on your starting point, but on everything you've added since. IT finally gets redundancy approved. Operations wants visualization. Kepware doesn't do that, so you're buying elsewhere. New vendor. New purchase order.

Year two: more equipment, more expansion. Your historian works with Kepware. Your analytics tool doesn't. Middleware required. Management wants remote access. Cloud gateway added. Every item individually justified. Every purchase properly approved. All operationally necessary.

Year three: you're maintaining the entire accumulated infrastructure. Tag costs scaled with production capacity. Integration expenses compounded with each system added.

What wasn't emphasized during procurement: Kepware moves data. Full stop. You still need separate systems for storage (historian), translation (middleware), visualization (dashboards), and processing (analytics). The purchase order said "connectivity." The actual infrastructure required five different vendors.

The pricing model punishes scale. More capacity needs more tags. More tags mean higher licensing. Higher licensing means steeper maintenance. Your costs climb while the underlying technology expenses, bandwidth, compute, storage, have been dropping for years.

Per-tag pricing doesn't match infrastructure reality. It matches what the market has tolerated. The actual cost of transmitting ten thousand data points versus one thousand? Essentially identical. Cloud providers know this. Modern software companies abandoned this model. The technology doesn't require metered billing, it just permits it.

Kepware charges per-tag because nobody's forced them to change.

You thought you bought connectivity. What you actually got was a billing structure that monetizes your success. Every expansion. Every new line. Every added system. Kepware extracts revenue from it. This isn't a partnership, it's value extraction wearing an enterprise license agreement.

Why Kepware Makes Less Sense in 2026

Five years ago, questioning Kepware meant gambling with production reliability. The alternatives weren't proven.

Today they are. And fundamental shifts made the old calculation obsolete.

Protocol secrecy collapsed. Kepware's advantage rested entirely on PLC manufacturers hiding their communication protocols. Documentation was unavailable. Reverse engineering was mandatory. Now every significant protocol specification is publicly published. Manufacturers provide detailed technical guides. Industry bodies standardized everything. What once demanded rare expertise is now freely available knowledge. The technical moat largely dried up. The pricing hasn't acknowledged it.

Infrastructure economics flipped. Handling 50,000 tags used to mean purchasing dedicated servers, implementing redundant hardware, staffing IT personnel. Real capital expenditure. Today that same capacity runs on $200 monthly cloud compute. The underlying cost dropped 90%. Kepware's licensing model operates as though nothing changed.

Complexity barriers vanished. Configuring Kepware required certified specialists. Three-day deployments minimum. Formal training requirements. Troubleshooting demanded protocol knowledge most engineers lacked. Modern platforms offer drag-and-drop setup, automatic device discovery, visual configuration. What took specialists three days, operations teams complete in two hours. The complexity that forced expensive integrator relationships disappeared.

Fragmented purchases became unified platforms. Kepware moved data. Full stop. You still needed separate historians, visualization tools, cloud gateways, middleware, analytics platforms. Five vendors. Five contracts. Five integration projects. Modern platforms ship unified, not assembled from parts, designed as integrated systems. The integration tax evaporated.

And private equity bought Kepware for $600 million. TPG's deal closes early 2026. Private equity doesn't maintain operations, it maximizes returns. That often means price increases, forced product bundles, or operational restructuring designed to extract more from existing customers. It's the same playbook every time.

You're not evaluating Kepware as it is. You're evaluating what it becomes under new ownership carrying $600 million in return expectations.

The window's narrow. Before new pricing hits. Before renewals reflect new ownership. While you control the timing instead of reacting to changes forced on you.

The safe choice five years ago became the risky bet today. Alternatives matured. Economics shifted fundamentally. Ownership transferred.

Evaluate now, or negotiate from weakness later.

The Bottom Line

You didn't select Kepware after rigorous evaluation. You selected it because it was the path of least resistance.

Least resistance meant proven reliability. Integrator familiarity. Budget pre-approval. Zero pushback.

But resistance-free had costs. Not just licensing, per-tag economics that scale against you. Integration overhead that multiplies vendor relationships. Lock-in that monetizes every operational expansion.

And now adds new risk: private equity ownership with $600 million in performance expectations.

The fundamentals shifted. Protocols became open. Infrastructure costs dropped 90%. Modern platforms integrated what previously required assembly. The technical and economic moats that justified Kepware as default evaporated.

You're not constrained by technology. You're constrained by inertia.

Kepware functions reliably. That's not disputed. But reliability alone doesn't justify paying 2015 prices for 2026 infrastructure when alternatives provide more capability at lower total cost.

Evaluate alternatives now from strength. Or negotiate renewals later from weakness under new ownership terms.

Kepware won through early dominance and ecosystem lock-in. That's separate from being the right architecture for current operations.

FlowFuse 2.26: Bringing access-controls to your MCP nodes

2026-01-15T00:00:00Z

With the holiday break sitting in the middle of this release cycle, it's a smaller release than usual this month. But that hasn't stopped us continuing to make the FlowFuse Expert even more useful.

Role-based access control for your MCP tools

Following on the the introduction of FlowFuse Expert MCP-Powered Insights we have added annotations to the FlowFuse MCP nodes and linked them up with the FlowFuse roles. This permits a level of control over who can access what. This is just a first step, we will be working in the area over the next few iterations.

The MCP nodes now allow you to set some standard annotations to give the platform a hint as to what type of action the node performs. This lets you separate tools that provide read-only information from those that make potentially-destructive changes.

Within the FlowFuse team, you can then use the granular RBAC feature to configure what users have access to the different types of node.

For example, Viewer role users can have access to read-only nodes, whilst Owners get to access the full range of tools. These roles can be customised for each Application within the team.

The annotations we apply are part of the MCP standard, so will be recognised by your own Agents and LLMs.

MCP Server Tool Node with new annotations

Integrating FlowFuse Expert with Node-RED

This release also brings some new abilities for the FlowFuse Expert to help you do things inside Node-RED itself.

Streamlined Node Installation: When the Expert suggests a node module, it can now automatically open the Palette Manager and filter for the correct package, leaving you just one click away from installation.
Direct Flow Imports: When the Expert provides demo flows, you no longer need to copy-paste JSON. The Expert can now inject those flows directly into your editor, ready for deployment.

Make sure you've updated the @flowfuse/nr-assistant module inside your instance to unlock these new capabilities.

FlowFuse Expert integration with the Palette Manager

What else is new?

For a complete list of everything included in our 2.26 release, check out the release notes.

Your feedback continues to be invaluable in shaping FlowFuse's development. We'd love to hear your thoughts on these new features and any suggestions for future improvements. Please share your experiences or report any issues on GitHub.

Which of these new features are you most excited to try? Reach out on GitHub or social media!

Try FlowFuse

FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

Get started for free and have your Node-RED instances running in the cloud within minutes.

Self-Hosted

Get FlowFuse running locally in under 30 minutes using Docker or Kubernetes.

What Is a System Integrator? Understanding Manufacturing's Most Misunderstood Role

2026-01-13T00:00:00Z

Most factories don't get built all at once. They evolve. Someone buys a robot in 2018. A conveyor system gets added when production ramps up. Last year, a vision system showed up because quality was slipping. Every piece from a different vendor, every piece with its own manual, its own software, its own way of doing things.

And somehow, it all has to work together.

That's what system integrators do. They look at what you've got and figure out how to make it run as one system. They write the code that connects it, wire the panels that power it, and test it until it works the way it needs to. When they're done right, everything just runs: the line moves, parts flow, production hits its numbers.

But here's what most people don't see: the complexity behind making that happen. Even if you work with system integrators regularly, the full scope of what they do often stays hidden beneath the surface. This article pulls back that curtain.

What System Integrators Actually Do, and Why They Matter

A system integrator is a partner that takes separate pieces of technology (from factory floor equipment to business software) and makes them work as one system.

But that definition doesn't capture the scope. The work spans two worlds that don't naturally speak to each other.

On one side, you have operational technology (OT): the physical equipment that runs your factory. Robots, PLCs, conveyors, sensors, vision systems, SCADA systems. On the other side, you have information technology (IT): the software that runs your business. ERP systems, MES platforms, databases, analytics tools.

System integrators connect both. And that's where things get complicated.

Discovery and Diagnosis

The work begins with understanding the actual problem. A line keeps jamming because two machines won't sync. Production data sits trapped in SCADA and can't reach your ERP for scheduling decisions. Quality defects have no connection to process parameters. These aren't isolated issues: they're integration failures.

A system integrator walks your plant with a specific lens. They document what equipment you're running, which protocols each device speaks, where IT and OT systems touch or fail to. They identify the gaps: a PLC speaking Modbus trying to feed a cloud platform, an MES that can't pull real-time SCADA status, a quality database disconnected from traceability. They map not just what's broken, but why, and what fixing it actually requires.

Architecture and Design

Then comes architecture. They design how everything communicates: OPC-UA for machine data, MQTT for sensor networks, APIs for enterprise integration. They map data flow with an understanding of latency, volume, and the cybersecurity boundaries between factory and business networks. They specify edge computing where real-time decisions matter and cloud connectivity where analytics adds value. The result accounts for your existing infrastructure, your future needs, and the reality that factories can't afford downtime.

Implementation

The build phase makes it real. Controls engineers program PLCs and configure SCADA. Electricians assemble panels and run cable. Network engineers deploy industrial Ethernet with the redundancy and determinism that production demands. Software developers write the middleware that translates between incompatible systems and build dashboards that turn raw data into decisions.

Testing and Commissioning

Commissioning proves it works. They test components in controlled environments, verify equipment in your actual plant conditions, and stress the complete system under load. They simulate equipment failures, run at maximum throughput, validate data accuracy from sensor to business report. They tune controller performance and set alarm thresholds. Nothing goes live until it runs reliably across all shifts and your team knows how to operate it.

Why This Matters

Modern manufacturing doesn't work without integration. You can't optimize production without data. You can't get data without connectivity. You can't connect systems that speak different languages and live in different networks. System integrators are the bridge builders who make your factory floor talk to your business systems. They turn equipment investments into operational capability. They make the difference between a factory that runs and one that competes.

But even for those familiar with the role, the true complexity often gets underestimated.

Why System Integration Is More Complex Than It Appears

Most people who work with system integrators understand what they do at a high level. But the depth and breadth of the work often gets compressed into simple categories that don't capture reality.

"They install robots." That's maybe 10% of the work (and often not the hardest part). "They're industrial electricians." Electricians are crucial team members, but they're one specialty among many. "They handle automation projects." True, but that doesn't explain the challenge of making a 2015 Siemens PLC talk to a 2023 cloud analytics platform while maintaining cybersecurity boundaries and microsecond-level timing precision.

The real complexity comes from operating across multiple domains simultaneously. A single project might require technical breadth across both factory floor protocols (Modbus, Profinet, EtherNet/IP) and enterprise systems (REST APIs, SQL databases, message queues). Understanding when to use edge computing versus cloud processing. Balancing real-time control requirements with data analytics needs.

Different industries have different requirements. Food processing needs washdown-rated equipment and FDA compliance. Automotive requires high-speed deterministic networks and traceability. Pharmaceuticals demand validation documentation and 21 CFR Part 11 compliance. An integrator can't just transplant solutions between industries: domain expertise matters.

Modern factories still run equipment from the 1990s alongside brand-new IoT sensors. Integration means making 30-year-old systems participate in Industry 4.0 initiatives without replacing everything (because replacing everything isn't an option). Legacy systems present unique challenges that require both historical knowledge and modern techniques.

Integration projects touch production, IT, quality, maintenance, and management. Each group has different priorities, different vocabularies, and different success metrics. The integrator must translate between them and build systems that serve all stakeholders. This organizational complexity often proves harder than the technical challenges.

Factories can't stop for testing. Integration work happens around production schedules, often during limited downtime windows. A mistake can halt a production line costing thousands per minute. Every decision carries operational risk that must be carefully managed. The pressure to get it right the first time is immense.

This complexity (the need to work across multiple domains, technologies, and organizational boundaries) is also why the tools integrators use have had to evolve. The traditional approach that worked for decades simply can't keep up anymore.

How Modern Tools Are Changing System Integration

System integration used to mean custom work every time. Integrators hard-coded point-to-point connections between machines and systems. Change a sensor, and you risk breaking the ERP connection. Scale that across a factory, and you end up with "spaghetti architecture," where everything depends on everything else.

That approach no longer works. Industry 4.0 has changed manufacturing priorities. Data isn't just a byproduct of production: it's the foundation for optimization, predictive maintenance, and competitive advantage. Modern factories generate massive amounts of data, evolve quickly, and can't afford brittle, one-off integrations.

The industry is moving toward architectures like the Unified Namespace (UNS). Instead of systems talking directly to each other, data flows to a central hub. A PLC publishes data once. MES, ERP, analytics platforms all subscribe to it. Add a new system, and it just subscribes. No rewiring. No breaking existing connections.

This shift demands different tools. Tools that support many protocols without custom drivers. Tools that are quick to understand and easy to maintain. Tools where you can see how data flows at a glance instead of digging through legacy code.

Several approaches address these challenges. One that many integrators are adopting combines flow-based programming with enterprise management capabilities. Node-RED provides the foundation for visual integration. Integrators build flows by connecting nodes instead of writing everything from scratch. Integrations that once took days can often be configured in hours. Node-RED already supports the protocols integrators rely on daily (MQTT, OPC-UA, Modbus, HTTP, and more) without custom development.

But Node-RED on its own presents challenges at scale. A single factory might run dozens of Node-RED instances across multiple production lines. Multiply that across multiple sites, and suddenly you're managing hundreds or thousands of separate installations. Version control becomes critical: you need to know which flows are running where. Updates need careful orchestration: you can't afford to push changes that break production systems. Teams need visibility into what's deployed and the ability to roll back when necessary.

This is where FlowFuse extends Node-RED's capabilities for production environments. It adds the enterprise management layer that large-scale deployments require: centralized control across all your Node-RED instances, version tracking for every flow change, and the ability to test updates in staging environments before they touch live equipment. What was once a prototyping tool becomes a platform you can trust in production.

The combination enables new patterns. Node-RED can run at the edge, close to machines, processing data locally and sending only what matters upstream. FlowFuse manages those edge deployments from a central location, giving you visibility and control without constant site visits. Teams can develop changes in one environment, test them against digital twins, then deploy systematically across production sites, reducing risk and eliminating the downtime that comes from untested changes.

The tools are also changing who can do integration work. Software developers and IT teams can now contribute meaningfully to industrial systems. The line between OT and IT continues to blur. Still, the core challenge remains the same. Someone must understand both the factory floor and the business systems. Someone must decide what runs at the edge, what belongs in the cloud, and how failures ripple across systems. The tools make integration faster and more scalable, but they don't replace the need for skilled system integrators.

That's why choosing the right integrator still matters.

How to Choose a System Integrator

Finding a system integrator isn't like hiring a contractor. You're looking for a partner who can solve problems you might not fully understand yet. Here's what to look for and what to watch out for.

Start with relevant experience. An integrator who specializes in automotive won't necessarily fit food processing. The protocols, regulations, and problems are different. Look for integrators who've worked in your industry or on similar projects. Ask for specific examples: What were the challenges? How did they solve them? What would they do differently now?

Check their technical depth. Can they handle both OT and IT? Do they know the specific equipment you're using? Certifications matter (look for manufacturer certifications for your key equipment vendors) but hands-on experience matters more. Ask technical questions during the selection process. If they can't explain complex topics clearly, that's a red flag.

Consider their documentation standards. When they leave, will your team understand what was built? Can someone else maintain it? Good integrators document thoroughly because they know you'll need to modify the system later. Ask to see examples of their documentation. It should include network diagrams, logic descriptions, troubleshooting guides, and clear explanations of design decisions.

Look at their tooling approach. Are they building everything custom or using modern platforms that make systems easier to maintain and scale? Integrators using flow-based programming and remote management can iterate faster and handle updates without constant site visits. Ask what tools they use and why. Good integrators can explain the tradeoffs.

Talk to their references (especially clients from projects two or three years old). How did the system hold up? When issues came up, how did the integrator respond? Were they available for support? Did the system adapt to changing needs? A system that works on day one but can't evolve is a liability.

Pay attention to communication style in initial conversations. Do they ask good questions? Challenge your assumptions when needed? Explain clearly or hide behind jargon? A good integrator makes complex things understandable. They should be able to translate between technical teams and management, between OT and IT, between what you asked for and what you actually need.

Be wary of integrators who promise everything will be easy, cheap, and fast. Good integrators set realistic expectations about timeline, budget, and risks. They identify potential problems upfront rather than discovering them halfway through the project. They explain what could go wrong and how they'll handle it.

Watch for red flags:

Reluctance to use standard protocols (proprietary solutions lock you in)
No disaster recovery plan (what happens when something fails at 2 AM?)
Unclear scope management (how do they handle change requests?)
Limited cybersecurity knowledge (OT security is non-negotiable now)
One-size-fits-all solutions (your factory isn't their last project).

Beyond all these factors, you'll eventually need to talk about price. And yes, price matters, but don't let it be your only decision factor. The cheapest bid often turns into the most expensive project once you add up the delays, rework, and ongoing maintenance issues. Look for value instead: an integrator with the right expertise, proven reliability, and an approach that matches your project's complexity. Yes, they might cost more upfront. But thorough documentation, proper testing, and real support usually cost far less over five years than hiring someone who cuts corners to win the contract.

Finally, remember that system integration projects rarely go exactly as planned. Equipment arrives late. Specifications change. Unexpected issues emerge during commissioning. You want a partner who'll work through problems with you, not one who disappears when things get complicated or immediately demands change orders for every small deviation. The best integrator relationships are collaborative. They bring technical expertise; you bring process knowledge. Together, you build systems that actually work for your operation.

Moving Forward

System integrators bridge the gap between equipment and outcomes. They take the complexity of modern manufacturing (the mix of old and new equipment, the demands for data and flexibility, the need for reliability and innovation) and turn it into working systems.

The role is evolving. New tools make integration faster and more scalable. New architectures make systems more flexible and maintainable. But the fundamental challenge remains: connecting technologies that weren't designed to work together and making them serve business goals.

Whether you're trying to understand what system integrators do, evaluating one for a project, or working as an integrator yourself, the core principle stays the same: good integration makes complexity disappear. The factory runs, data flows, and production hits its numbers (not by accident, but because someone built the systems that make it possible).

Work With Us

If you're a system integrator, FlowFuse helps you build integrations once and deploy them everywhere (across hundreds of sites, thousands of devices, without writing custom code for every project). Our platform gives you the tools to scale faster, reduce project complexity, and deliver more value to your clients.

Learn about our partner program

Integrating Git within Node-RED Workflow with FlowFuse

2026-01-06T00:00:00Z

If you've been using Node-RED in production, you already know the pain points. Flows get complex. Teams grow. Someone makes a change that breaks production at 2 AM. You need to roll back, but which version was working? Who approved this deployment? How do you keep your dev environment in sync with production?

Traditional Node-RED doesn't have answers to these questions. But modern software development has solved these problems decades ago with version control and DevOps pipelines.

That's the gap FlowFuse fills.

FlowFuse: DevOps for Node-RED

FlowFuse is a platform built specifically for running Node-RED at scale. It handles deployment, management, security, team collaboration, and more so you can focus on building flows instead of managing infrastructure.

Every FlowFuse can automatically create snapshots whenever flows are deployed. These snapshots let you track changes over time and roll back when needed. You can also create manual snapshots to mark important milestones.

The real power comes from DevOps pipeline stages. You set up stages like development, staging, and production, then push snapshots through them. Make changes in dev, test in staging, promote to production. Everything's tracked and auditable.

Why Git Integration Matters

We realized that many organizations already use Git as their central version control system. Their CI/CD pipelines run on Git commits. Their backup systems rely on Git repositories. Their compliance tools track changes through Git history too. To fit seamlessly into these existing workflows, Node-RED flows needed to be in Git too.

That's why we built Git integration for FlowFuse. FlowFuse pipeline stages now connect directly to Git repositories. Push your snapshots to Git and pull changes back when you need them.

Note: Git integration currently supports GitHub repositories.

Git integration brings several key advantages. Your flows are backed up in Git repositories alongside your other code, so if an instance is accidentally deleted, your flows remain safe and recoverable. For some companies, having all code assets version-controlled in Git repositories is a compliance requirement they must meet.

Git integration works alongside FlowFuse's DevOps features—snapshots, pipelines, rollbacks—giving you the full power of both systems.

Setting Up Git Integration

Let's walk through connecting your FlowFuse instances to a Git repository.

Prerequisites

Before you begin, make sure you have:

FlowFuse Team Account: Git integration is available exclusively to Enterprise users. If you don't have a Enterprise account, visit the FlowFuse pricing page or contact sales@flowfuse.com to upgrade.
GitHub Account: You'll need a GitHub account with permission to create repositories and generate personal access tokens.

Step 1: Create a GitHub Repository

First, set up a repository where your Node-RED flows will live:

Log in to your GitHub account
Click the + icon in the top right corner and select New repository
Name your repository (e.g., "nodered-flows" or "production-flows")
Choose Public or Private depending on your needs
You can initialize with a README if you'd like documentation
Click Create repository

Keep this repository URL handy—you'll need it later.

Step 2: Generate a GitHub Personal Access Token

FlowFuse needs permission to push and pull from your repository. GitHub uses Personal Access Tokens for this:

Go to GitHub Personal Access Tokens Settings
Click Generate new token and select Generate new token (fine-grained)
Give your token a descriptive name like "FlowFuse Node-RED Integration"
Set an expiration date (we recommend 90 days for security)
Under Repository access, choose Only select repositories and pick which repos FlowFuse can access
Under Permissions, expand Add permissions, then locate Contents and set it to Read and write
Click Generate token at the bottom

Critical: GitHub shows this token only once. Copy it immediately and store it somewhere secure. You'll paste it into FlowFuse in the next step.

Step 3: Add Your Token to FlowFuse

Now let's connect FlowFuse to your GitHub account:

Log in to your FlowFuse account
Navigate to Team Settings in the left sidebar
Click the Integrations tab
Find the Git integration section and click Add Token

Team Settings - Integrations tab showing Git integration options

Give your token a name (like "GitHub Production Flows")
Paste the Personal Access Token you copied from GitHub
Click Add

Adding a GitHub Personal Access Token to FlowFuse

Your token is now available to all Node-RED instances in your FlowFuse team.

Step 4: Configure a Pipeline Stage for Git

This is where it comes together. You'll configure a pipeline stage to push snapshots to your Git repository.

Important: A Git repository stage needs something to push. Make sure your pipeline has at least one stage before the Git stage—typically a Node-RED instance stage. The pipeline will take snapshots from that source stage and push them to Git.

In FlowFuse, navigate to your application
Go to the DevOps Pipelines section
Select the pipeline you want to add the Git stage to (or create a new one)
Click Add Stage
In the stage settings, select the Type Git Repository
Give the stage a name
Select the token you created earlier
Enter your repository URL (e.g., https://github.com/your-username/nodered-flows.git)
Enter the snapshot file name (e.g., flow.json). Leaving this blank will use the instance name. This is the name your flows will be saved as in the Git repository. When pulling changes back from Git, you must enter the exact same file name that exists in your repository to retrieve the correct flows.
Specify a branch name for pushing changes (like main). Make sure the branch already exists in your repository.
Optionally, specify a branch name for pulling changes (like main). Make sure the branch already exists in your repository.
Enter a secret credential key. This can be any strong passphrase. You'll need to re-enter it when pulling changes through the DevOps pipeline in FlowFuse.

Configuring a Git Repository stage in a DevOps pipeline

Click Add Stage

DevOps pipeline with Git repository stage added

Step 5: Push a Snapshot to Git

With the Git repository stage configured in your pipeline, you're ready to push your Node-RED flows to Git.

Open your Node-RED instance in FlowFuse that is part of the DevOps pipeline containing the Git repository stage
Make any required changes to your Node-RED flows, or keep them as-is if you want to push the current state
Navigate to the DevOps Pipelines section and select the pipeline that includes the Git repository stage
Create a snapshot to capture the current state of your flows
Click Run Pipeline and promote the snapshot through each stage until it reaches the Git repository stage
Once the pipeline completes successfully, FlowFuse automatically commits the snapshot to the configured Git repository

After the pipeline run finishes, you can open your Git repository and verify:

A new commit containing your Node-RED flows
A commit message linked to the snapshot
A complete, auditable history of changes

At this point, your Node-RED workflows are version-controlled in Git and fully integrated into your existing CI/CD and DevOps processes.

Step 6: Pull Changes from Git

FlowFuse's Git integration works both ways. You can push flows to Git and pull changes back from Git into your Node-RED instances.

The pipeline process is identical whether you're pushing or pulling—only the stage order changes. When pushing, your Git repository stage sits at the end of the pipeline. Snapshots flow from your Node-RED instance through intermediate stages and finally commit to Git. When pulling, the Git repository stage moves to the beginning. The pipeline fetches the latest commit from your configured branch, creates a snapshot, and promotes it through subsequent stages to your target instances.

This bidirectional workflow solves several common challenges. Teams can commit flow changes directly to the repository and pull them into FlowFuse. You can migrate flows from other systems by committing them to Git first. Your Git repository serves as both a backup destination and a source of truth.

Conclusion

FlowFuse simplifies everything about running Node-RED at scale—deployment, security, scaling, and team management. Git integration bridges the gap between FlowFuse's DevOps features and your existing development infrastructure. Your flows stay version-controlled, your team stays synchronized, and your operations stay simple.

The Node-RED Story: How Visual Programming Escaped the Lab and Conquered Industry

2026-01-05T00:00:00Z

In late 2011, Nick O'Leary was a "plumber" of the digital age. As part of IBM's Emerging Technology Group, he spent his days building experimental projects that pushed the boundaries of what connected systems could do. But there was a problem: for every new experiment, he found himself writing the same boilerplate code over and over — the tedious "wiring" work needed to make different systems talk to each other.

The Birth of Node-RED

The frustration was mounting. Each new project at IBM's Emerging Technology lab meant rewriting integration code from scratch. Nick knew there had to be a better way.

On a "wet January day in 2013," Nick decided to try something new. He wanted a way to visualize mapping messages across an MQTT infrastructure. He turned to Node.js — then a relatively new technology — as the foundation.

Over a single weekend, he built a rough prototype that allowed him to drag boxes and draw wires instead of writing endless integration code. When he showed it to his colleague Dave Conway-Jones on Monday morning, Dave’s response was immediate and world-changing: "Go on then."

Dave and Nick

The name was a light-hearted play on words. "Node" reflected the Node.js runtime and the flow-based model, while "RED" was a cheeky nod to "Code Red." While some later suggested it stood for "Rapid Event Developer," Nick and Dave never felt the need to formalize it. It was simply a vibrant alternative to the "Big Blue" corporate standard.

Early Node-RED Screenshot

Those two words meant everything. Dave didn't just approve — he joined in. Together, they started refining the tool, adding features, testing it on real IBM projects. What began as Nick's weekend hack became their shared mission. Within weeks, they had transformed a rough prototype into something that actually worked in production. The tool that was supposed to save Nick time on one project was now saving their entire team hours every week.

Node-RED offered something different: freedom. Drag boxes. Connect wires. Make anything talk to anything. No permission required.

The Public Spark

The transition from a lab tool to a public project wasn't a corporate rollout; it was a grassroots explosion. By late 2013, Nick and Dave had seen enough: Node-RED was too useful to keep locked inside the walls of IBM.

The First Commit: September 5, 2013

The public story of Node-RED began with a push, not a press release. On September 5, 2013, the first code was uploaded to GitHub. It was a "soft launch" — a way to see if the world actually needed a visual tool for "wiring" the Internet of Things. Within weeks, the community responded with an intensity that caught even the creators by surprise.

The "Workshop" Moment: Wuthering Bytes

The first external validation happened just a week after the GitHub release at the Wuthering Bytes technology festival. After Nick gave a brief, unprepared lightning talk, he walked into a workshop the following day and was stunned to see Node-RED on every single screen. A workshop facilitator had discovered the code on GitHub just days earlier and immediately scrapped his original plan. He realized that instead of teaching students how to troubleshoot line-by-line syntax, he could use Node-RED to let them actually build something. In thirty minutes, the class had achieved what usually took an entire day. It was the first time Nick saw people he had never met using his creation to solve real problems.

The London Node.js User Group (LNUG)

While the hardware community was the first to adopt it, the London Node.js User Group (LNUG) was where the project faced its first true technical trial. Standing before a room of seasoned JavaScript developers, Nick had a 30-minute slot to prove that Node-RED wasn't just a visual toy — it was a powerful tool built on the very event-driven architecture they loved. The talk was a massive success, generating immediate buzz across social media and solidifying Node-RED’s reputation within the developer community.

The Big Stage: ThingMonk 2013

While the September meetups provided the spark, ThingMonk on December 3, 2013, was the "Big Bang." This was the first major professional and industrial stage for Node-RED. It was here that the industry elite — the architects of the "Internet of Things" — realized that Node-RED was the answer to the "glorious mess" of incompatible protocols.

In his presentation, "Wiring the Internet of Things," Nick showed that visual programming wasn't just a shortcut for beginners; it was a professional-grade solution for the most complex integration problems on the planet.

2014: Proving the Concept

If 2013 was the spark, 2014 was the foundation. This was the year Node-RED moved from a lab experiment to a professional tool.

IBM's launch of Bluemix (now IBM Cloud) marked a pivotal moment — Node-RED became a flagship starter app, validating that visual programming could power enterprise-grade cloud applications. The year also saw multiple major version releases that enhanced the platform's capabilities.

Node-RED featured as a flagship starter app on IBM Bluemix in 2014

During this period, Nick took the project on the road — speaking at conferences and meetups to actively build the community around Node-RED. A major milestone came at QCon London 2014, a moment Nick has often described as especially meaningful. The talk marked a turning point, demonstrating to the professional software industry that visual programming could be a serious, scalable solution for complex data integration.

Nick O’Leary presenting Node-RED at QCon London 2014

The Explosion: The Raspberry Pi Milestone

By November 2015, Node-RED was officially integrated into the Raspbian Jessie image, marking its transition from a manual install to a core component of the Raspberry Pi ecosystem. The announcement was made by Simon Long, the Raspberry Pi Foundation's UX Engineer, who detailed the update in a blog post on December 2, 2015. This milestone meant that millions of $35 computers suddenly shipped with a visual programming tool built specifically for the "Internet of Things," sitting prominently in the application menu alongside educational staples like Scratch and Python.

Screenshot of the Raspbian Jessie desktop menu showing Node-RED included by default with Scratch and Python on Raspberry Pi

The impact was immediate and massive. Students learning to code on Raspberry Pi discovered Node-RED next to Python. Hobbyists building weekend projects found it pre-installed. Educators teaching IoT concepts had a visual tool ready to use. What had required hunting through forums and installation guides was now just a click away in the menu. The barrier to entry dropped to zero, and the community exploded.

Within months, Node-RED flows for Raspberry Pi projects flooded online forums. Home automation guides assumed you had it installed. The "install Node-RED" step disappeared from tutorials — it was just there. This wasn't just about convenience. It was about legitimacy. Being bundled with Scratch and Python signaled that Node-RED wasn't a niche hack — it was essential infrastructure for the IoT era.

A Home for the Future: The OpenJS Foundation

By 2016, Node-RED had outgrown its "side project" status at IBM. To ensure the tool remained open and vendor-neutral, IBM moved Node-RED into the newly formed JS Foundation (which merged in 2019 to become the OpenJS Foundation) as a founding project.

This was a pivotal moment for industrial adoption. By moving the project to a neutral foundation, Node-RED was no longer just an "IBM tool" — it became a public utility. Large-scale industrial players like Hitachi and Siemens could now contribute to the code and build their own products on top of it without fear of "vendor lock-in." It signaled that Node-RED was a stable, world-class piece of software infrastructure, governed by the same community standards as jQuery and Node.js.

The foundation move unlocked something crucial: trust at scale. When a Fortune 500 manufacturer evaluates tools, vendor neutrality isn't optional — it's mandatory. The OpenJS Foundation gave Node-RED the governance structure, intellectual property protections, and community oversight that enterprises require. Companies that would never bet their production lines on an IBM internal tool could now build on Node-RED with confidence. The path from hobbyist workshops to factory floors was open.

The Community Takes Over

The community didn't just use Node-RED — they built it. By 2023, the library contained over 4,300 nodes. Every new smart device gets a Node-RED node within weeks. Every protocol got wrapped. Forums filled with shared flows. Someone in Germany would solve a lighting problem at 2 AM, share the solution, and someone in California would adapt it for their garage door an hour later.

This wasn't just a user base — it was a movement. Makers, hobbyists, and tinkerers around the world were solving problems and sharing solutions freely. The barrier to contribution was low — anyone could create a node and publish it. The barrier to adoption was even lower — anyone could install a node with a single click.

The community's creativity extended across domains. Nodes were built for popular platforms, industrial protocols, cloud services, databases, messaging systems, AI services, and thousands of integrations beyond. If a technology existed, someone had already made it work in Node-RED.

But something unexpected was happening beneath the surface. While the community shared home automation flows in forums, engineers in factories were quietly watching. They saw the same drag-and-drop simplicity that connected smart lights could connect production equipment. They saw the protocol-agnostic approach that worked for hobbyists could work for industrial systems. They saw a tool that both IT and operations teams could actually understand.

The movement that began in living rooms was about to reach factory floors.

The Bridge Nobody Planned

The movement reached Hitachi's factory floors in a way nobody anticipated. Node-RED emerged as a crucial communication tool bridging the gap between IT and factory engineers. Its intuitive interface allowed the entire flow to be visible on screen, facilitating discussions and collaborative efforts seamlessly.

For decades, IT and OT spoke different languages. IT managed databases and networks. OT ran machines and production lines. They needed each other but couldn't understand each other. Node-RED gave them a shared vocabulary—visual flows that both sides could read.

A factory engineer could build a flow reading data from a Modbus PLC. An IT engineer could look at that same flow and immediately understand what it did. No translation needed. The same visual language that connected smart home devices was now connecting industrial equipment to enterprise systems.

The movement had arrived in the industry. And it brought its community-driven, protocol-agnostic approach with it.

The Numbers Prove It

The 2019 survey captured the movement mid-expansion: 31.5% used it in manufacturing, and 24% had created PLC applications. Home automation remained strong, but the industry was already significant.

By 2023, the industrial footprint had solidified. Manufacturing remained the second largest industry at 40%, up from 31.5%. Just over 40% now use Node-RED professionally. Home automation usage held steady at 70% — both sectors thriving, not competing.

The protocols revealed the depth of industrial adoption. MQTT and HTTP dominated both sectors. But Modbus and OPC-UA — industrial protocols — saw significant growth. These weren't hobbyists experimenting. These were engineers connecting real production equipment.

The movement had conquered two worlds simultaneously.

FlowFuse: Conquering Industrial IoT

By 2021, the challenge had shifted. Node-RED worked brilliantly for individual developers, but enterprises needed more: how do you scale it across tens of thousands of factory instances? How do you secure it? How do you make teams collaborate on flows without stepping on each other's work? To solve these problems, Nick founded FlowFuse (formerly FlowForge).

But a technical revolution needs both an inventor and an architect. In January 2022, Zeger-Jan van de Weg (ZJ) joined as CEO. Drawing on his experience as an early GitLab employee, ZJ knew how to turn a successful open-source project into an enterprise-grade platform. While Nick continues to guide the technical direction as CTO, ZJ leads the effort to scale industrial automation for Fortune 500 companies.

Nick and ZJ

Together, they have raised $14.5 million to build the infrastructure enterprises demand. With this funding, they assembled a talented team spanning engineering, product, customer success, marketing, sales, and community, each member contributing their unique expertise to drive FlowFuse's growth across every aspect of the business.

Between 2021 and 2025, FlowFuse evolved into a full industrial ecosystem through deliberate focus on operational maturity. The journey began with team collaboration and scaling — introducing version control, team permissions, and DevOps pipelines that let engineering teams work together on flows like software projects, then deploy updates across thousands of remote Node-RED instances with discipline. With collaboration and scale established, the focus shifted to enterprise security, adding SSO, RBAC, and SOC 2 compliance to meet strict governance requirements. Next came infrastructure independence, integrating a built-in MQTT broker and FlowFuse Tables to reduce reliance on external services. By 2025, as AI began reshaping industry, FlowFuse entered the intelligence era with MCP nodes, and FlowFuse Expert — an AI that converts plain-English industrial problems directly into working Node-RED flows.

FlowFuse's mission went beyond enterprise features. It invested continuously in Node-RED core development and community sustainability. When the original Node-RED Dashboard was deprecated, FlowFuse rebuilt Node-RED Dashboard 2.0 from the ground up.

That commitment extended to the ecosystem itself. Through the Certified Nodes program, FlowFuse identifies critical community nodes and subjects them to rigorous security and quality testing. To ensure long-term reliability, FlowFuse supports maintainers financially or assumes maintenance responsibility — an approach aligned with the expectations of large industrial organizations.

Education and community came next. FlowFuse launched Node-RED Academy, the first official Node-RED Academy offering Node-RED certification, providing a clear path from learning flows to building production-ready systems. This was followed by major investment in modernizing the Node-RED editor UI through an open, community-driven process. The journey culminated in the Node-RED Conference, bringing together over 1,000 live attendees worldwide and transforming a distributed user base into a connected industrial community.

Five years into its journey, FlowFuse stands as a rare example of open source scaling into industrial reality without losing its soul. What started as a way to operate Node-RED at scale is now a production platform deployed in some of the world's largest factories — increasingly taking on responsibilities once dominated by legacy industrial platforms. It demonstrates that when community stewardship, engineering rigor, and long-term vision align, open source can form the backbone of modern industrial systems.

This vision has translated into explosive market adoption, with the company multiplying its annual recurring revenue and customer base by nearly 5x in the last year alone.

Why It Succeeded

Node-RED won because it was simple when everyone else was complicated.

The smart home industry sold subscriptions and proprietary hubs. Industrial automation sold certifications and consulting contracts. Both pretended connecting systems required expertise only they could provide.

Node-RED proved them wrong. Drag a box. Draw a line. Done.

The same principles work everywhere. A homeowner connecting a thermostat to weather data uses the exact concepts an engineer uses connecting factory equipment to a data lake. Input. Logic. Output. The scale changes. The principles don't.

The visual interface removed the gatekeepers. You didn't need to understand APIs or write integration code. You could see the logic, understand it, and modify it — all on one screen. When both the factory floor worker and the IT manager can look at the same flow and grasp what it does, you've eliminated the translation layer that created vendor dependency.

Today and Tomorrow

Today, Node-RED spans from living rooms to factory floors. FlowFuse has made it enterprise-ready.

Home users still rely on Node-RED to make incompatible smart devices work together. But FlowFuse has transformed industrial adoption—turning a powerful tool into production infrastructure with fleet management, enterprise security, and DevOps pipelines that Fortune 500 companies trust.

The scale is substantial. Manufacturing plants run FlowFuse across thousands of remote sites. Energy companies depend on it for critical infrastructure monitoring. What started as visual programming for hobbyists now handles mission-critical operations where downtime costs millions per hour.

The momentum continues building. FlowFuse is pushing Node-RED into new territory — AI-powered flow generation, advanced analytics, and capabilities that didn't exist two years ago. As AI reshapes manufacturing and operations, Node-RED is positioned at the center of that transformation.

The revolution that began in living rooms and reached factory floors is entering its next phase.

Final Note

Writing this reminded me why I fell in love with Node-RED. But the real story isn't in these words — it's unfolding right now in someone's garage, on a factory floor, in a student's first "it works!" moment.

What amazes me most is the community's generosity. People don't just solve problems — they share them, celebrate each other's wins. Curiosity matters more than credentials. "I don't know, but let's figure it out together" is the standard response.

If this story touched you, please share it. Someone out there might need the reminder that the impossible is usually just the not-yet-possible.

Thank you for reading, and happy New Year!

Mean Time to Failure (MTTF): Formula, Calculation, MTTF vs MTBF vs MTTR, and More

2025-12-29T00:00:00Z

When a critical motor bearing assembly fails after just 6 months—half its rated lifespan—maintenance teams face a fundamental question: "How long should this component actually last?"

Mean Time to Failure (MTTF) provides the answer. It measures the average operational lifetime of non-repairable components before permanent failure, enabling data-driven decisions about replacement timing, spare parts inventory, and component selection.

MTTF emerged as a core reliability engineering metric in the 1950s during the development of military and aerospace reliability theory. Today, it remains essential across industries where component reliability determines operational success—from semiconductor manufacturing to data centers to industrial automation.

This guide explains what MTTF measures, how to calculate it correctly with real examples, how it differs from related metrics, and how to use MTTF data for strategic maintenance planning.

What is Mean Time to Failure (MTTF)?

Mean Time to Failure (MTTF) is a reliability metric that measures the average operating time of a non-repairable component before it fails permanently. Once the component fails, it is replaced, not repaired.

MTTF is commonly used for items such as light bulbs, batteries, sealed bearings, hard drives, electronic modules, and disposable filters. It helps teams understand how long a part typically lasts under normal operating conditions, enabling better planning for replacements, spare parts management, and reduction of unexpected downtime.

MTTF is a core concept in reliability engineering and is widely used in maintenance planning, lifecycle cost analysis, and dependability studies. It is formally supported by industry standards such as MIL-HDBK-217, IEEE Standard 1413, and IEC 60300-3-1, which provide guidance on reliability and dependability analysis across the equipment life cycle.

Important: MTTF represents a statistical average—some components will fail earlier while others last longer. Use it for planning and forecasting, not for predicting exact failure times of individual components.

Mean Time to Failure (MTTF) Formula

The MTTF calculation is straightforward:

MTTF = Total Operating Time / Number of Failures

Total Operating Time is the sum of all hours every unit ran before failing. Number of Failures is how many units failed permanently and were replaced (not repaired).

Example

You have 50 light bulbs. Ten bulbs burn out after 8,000 hours (that's 80,000 total hours). Fifteen more fail at 10,000 hours (150,000 hours). The remaining 25 bulbs last 12,000 hours each (300,000 hours). Add it all up and you get 530,000 hours across 50 bulbs.

MTTF = 530,000 / 50 = 10,600 hours

This means on average, each bulb lasts 10,600 hours before it fails.

Quick Shortcuts

If all your components run the same amount of time before the test ends, you can use this shortcut: multiply the number of units by hours run, then divide by failures observed.

The failure rate is simply the inverse of MTTF. If MTTF is 10,000 hours, your failure rate is 0.0001 failures per hour, which means you expect 1 failure every 10,000 hours.

What This Formula Assumes

The basic MTTF formula works when you're tracking non-repairable parts, failures occur randomly during their normal lifespan, and operating conditions remain roughly consistent. You also need enough failures to make the average meaningful—ideally 30 or more data points.

When basic MTTF doesn't apply: If you have components still running at the end of your observation period, or if failure patterns follow a bathtub curve (high early failures, stable middle period, increasing wear-out failures), you'll need advanced statistical methods like Weibull analysis or censored data techniques.

How to Calculate Mean Time to Failure (MTTF)

Example 1: Data Center Hard Drives

A data center operates 100 identical hard drives. Over 18 months of operation, they track which drives fail and need replacement:

Month 6: 3 drives fail after 4,380 hours each = 13,140 hours
Month 9: 5 drives fail after 6,570 hours each = 32,850 hours
Month 12: 4 drives fail after 8,760 hours each = 35,040 hours
Month 15: 6 drives fail after 10,950 hours each = 65,700 hours
Month 18: 7 drives fail after 13,140 hours each = 91,980 hours

Total operating time = 238,710 hours
Total failures = 25 drives

MTTF = 238,710 / 25 = 9,548 hours

This tells the data center they can expect each hard drive to last roughly 9,548 hours (just over 1 year). The remaining 75 drives are still running, so the actual MTTF might be higher, but this gives them a working estimate for planning replacements and maintaining spare inventory.

Example 2: Manufacturing Plant Conveyor Belts

A factory runs 20 conveyor lines, each with identical drive belts. The maintenance team tracks belt failures over 2 years:

All 20 belts start fresh. After 8,000 hours of operation, 4 belts have failed. After 12,000 hours, 6 more fail. After 16,000 hours, another 5 fail. The remaining 5 belts are still running at the 2-year mark (17,520 hours).

Simplified calculation using all belts (including those still running):

Total time = 20 belts × 17,520 hours = 350,400 hours
Total failures = 15 belts

MTTF = 350,400 / 15 = 23,360 hours

The plant now knows these belts typically last about 23,360 hours (roughly 2.7 years in continuous operation). They can schedule preventive replacements at around 20,000 hours to avoid unexpected breakdowns during production runs.

Common Calculation Mistakes to Avoid

One of the most common mistakes when calculating MTTF is confusing calendar time with actual operating hours. A component that runs only part of the day will accumulate operating hours much more slowly than calendar time passes, so it’s critical to measure true runtime rather than elapsed days or months. Another frequent error is including repaired equipment in MTTF calculations. If a component is fixed and returned to service, it belongs in MTBF calculations, not MTTF, which only applies to items that are permanently replaced after failure.

Small sample sizes also lead to misleading results. Calculating MTTF from just a few failures can produce numbers that fluctuate widely and don’t reflect real performance. In practice, at least 20 to 30 failures are needed to produce meaningful averages, with larger datasets providing more reliable insight. Operating conditions are another major source of error. The same component can have very different lifespans depending on factors like temperature, dust, vibration, and load, so MTTF values should always be compared under similar conditions.

Finally, MTTF is often misunderstood as a guaranteed lifespan. It is only an average. Some components will fail much earlier than the MTTF value, while others will last significantly longer. Maintenance planning should account for this natural variation instead of treating MTTF as a minimum life expectancy.

Difference Between MTTF, MTBF, and MTTR

These three acronyms measure fundamentally different aspects of reliability:

Metric	What It Measures	Use For	Example
MTTF	Average time until permanent failure	Non-repairable items replaced when they fail	Light bulbs, batteries, hard drives, sealed bearings
MTBF	Average time between repair events	Repairable systems fixed and returned to service	Motors, pumps, HVAC systems, vehicles
MTTR	Average time to complete repairs	Any equipment requiring repair	All repairable systems

The key distinction: MTTF applies when you discard and replace it. MTBF applies when you fix it and keep using it. MTTR tells you how long the fixing takes.

Calculation Formulas

MTTF = Total operating time ÷ Number of permanent failures
MTBF = Total operating time ÷ Number of repair events (excluding repair time)
MTTR = Total repair time ÷ Number of repairs

A facility might track MTTF for LED bulbs in their fixtures (replace when burned out) while tracking MTBF for the fixtures themselves (repair when they fail). Both metrics serve different planning purposes.

Where to Find Reliable MTTF Data

Manufacturer datasheets are a useful starting point, but they should not be treated as definitive. Published MTTF values are usually measured under controlled laboratory conditions with clean environments, ideal installation, stable temperatures, and moderate loads. Real operating environments are rarely this consistent, so actual component life in the field is often shorter or more variable than datasheet values suggest.

Industry reliability databases provide more realistic benchmarks. Standards such as ISO 14224 compile failure and maintenance data from hundreds of similar facilities, offering reference values that reflect real-world operating conditions rather than ideal test scenarios. These benchmarks are helpful for comparison, but they still represent averages across many sites and may not fully match your specific environment.

The most reliable MTTF data comes from your own facility. By tracking installation dates and failure times, you can build site-specific reliability data that reflects your actual loads, temperatures, maintenance practices, and environmental conditions. After collecting data from 20 to 30 failures, your internal MTTF values will often be more accurate and actionable than any external source.

Using MTTF for Better Maintenance Planning

MTTF delivers the most value when it supports proactive maintenance decisions rather than reactive repairs. When using MTTF for maintenance planning, the objective is to replace components before failures disrupt production. For example, if a component typically fails around 20,000 operating hours, scheduling replacement at 15,000 hours during planned maintenance windows can prevent unexpected breakdowns and emergency interventions. Replacing parts slightly early is often far less costly than absorbing unplanned downtime.

MTTF also plays a critical role in spare parts optimization, particularly in manufacturing and industrial automation environments where many identical components operate continuously across multiple machines. By estimating expected failures per year based on operating hours and installed quantities, maintenance teams can stock enough spares to meet short-term demand without tying up excessive working capital. Even modest improvements in MTTF-based inventory planning can significantly reduce both downtime risk and excess inventory.

Supplier selection becomes more objective when MTTF data is used instead of relying solely on datasheet claims. In real-world maintenance planning scenarios, teams can compare components based on total cost per operating hour rather than purchase price alone. A higher-priced component with a longer operating life may ultimately be more economical once labor costs, downtime impact, and replacement frequency are considered.

Finally, MTTF helps reveal the true cost drivers within maintenance budgets across manufacturing and industrial automation systems. By combining replacement costs, downtime impact, and failure frequency, teams can identify which components contribute most to annual maintenance spend. Incremental improvements in component reliability often translate into substantial cost savings while also improving overall equipment availability.

When MTTF Isn't the Right Metric

MTTF has limitations. Don't use it when:

Equipment gets repaired, not replaced - Use MTBF instead
Failure patterns show wear-out - Components with bathtub curves (high early failures, then stable, then increasing wear-out failures) need Weibull analysis
You need real-time reliability - MTTF describes past performance; it doesn't predict when the next specific unit will fail
Safety-critical applications - Statistical averages aren't appropriate for systems where a single failure could cause injury or environmental harm. Use fault tree analysis or failure mode effects analysis instead

Bottom Line

Stop guessing when parts will fail. Start tracking installation dates and failure times today. After 20-30 failures, you'll have better data than any manufacturer spec sheet—data that reflects your actual operating conditions, not laboratory ideals.

Use that data to schedule replacements during planned downtime rather than waiting for 2am emergency breakdowns. Stock the right number of spares—not too many tying up working capital, not too few forcing expedited shipping and production delays. Compare suppliers based on actual performance in your facility, not who's cheapest on paper.

The math is straightforward: unplanned breakdowns cost 3-5x more than scheduled replacements when you factor in overtime labor, rush parts shipping, and lost production. MTTF transforms reactive firefighting into predictable maintenance.

Your facility is unique. Your conditions, loads, and environment create a reliability profile unlike any other operation. The only MTTF numbers that truly matter are the ones you measure yourself.

As your equipment base grows, manual tracking becomes cumbersome. FlowFuse automates this by connecting to PLCs, SCADA systems, MES platforms, and your CMMS—pulling operating hours directly from equipment through industrial protocols like Modbus, OPC UA, and EtherNet/IP, then capturing failure events to recalculate MTTF in real-time across your entire facility.

What Is a PLC (Programmable Logic Controller)? What It Does, How It Works, and Where It’s Used

2025-12-26T00:00:00Z

A PLC (Programmable Logic Controller) is an industrial computer that continuously monitors sensors, executes control logic, and operates motors, valves, and equipment in real-time, serving as the reliable backbone of modern manufacturing and industrial automation.

On New Year's Day 1968, Dick Morley, also known as the “Father of the PLC,” woke up with a brutal hangover and did what any reasonable engineer might do: he invented the future of manufacturing. That morning, nursing what he later described as "a wicked headache," Morley wrote the complete specifications for the Programmable Logic Controller—a device that would replace entire relay-based control systems and become the invisible brain running modern industry.

Before that hungover epiphany, changing how a factory operated meant physically rewiring thousands of electromagnetic relays. General Motors was bleeding money—weeks of downtime and millions in labor costs every time they needed to retool a production line. Morley's Modicon 084 replaced 20,000 mechanical components with a single box that could be reprogrammed in hours.

Today, PLCs control everything from the jet engines on your flight to the insulin in your pharmacy. They manage power grids, traffic lights, water treatment plants, and semiconductor fabs. Eighty percent of industrial automation worldwide runs on PLCs. It's a $13 billion market. And yet, most of us have never heard of them.

This article breaks down what PLCs actually are, traces their evolution from Morley's specs to modern systems, explains how they work under the hood, explores their real-world applications, and tackles the biggest challenge facing industrial automation today: getting PLCs from different manufacturers to actually talk to each other.

What is a PLC (Programmable Logic Controller) ?

A Programmable Logic Controller is an industrial computer built for one job: controlling machines and processes in real-time with rock-solid reliability. Unlike your laptop or the servers running cloud applications, PLCs thrive in environments that would kill standard computers—extreme temperatures, constant vibration, electrical noise, dust, and humidity.

The concept is elegant in its simplicity. A PLC continuously monitors inputs from sensors and switches, executes control logic from its stored program, and updates outputs that control motors, valves, lights, and equipment. This happens in a repeating "scan cycle," typically thousands of times per second. Read inputs. Run logic. Update outputs. Repeat. Forever.

What sets PLCs apart isn't computing power—your phone vastly outperforms them. It's their deterministic behavior. When a PLC runs a program, it executes exactly the same way every single time. No operating system randomly running updates. No background processes stealing resources. No crashes. No reboots. In industries where failure means explosions, contaminated products, or fatalities, this predictability isn't a nice-to-have. It's survival.

The hardware reflects this zero-compromise approach. Industrial-grade components handle extreme temperatures and electrical interference. Power supplies absorb voltage swings that would fry consumer electronics. Input and output modules interface directly with industrial sensors and actuators at various voltages. The programming uses ladder logic and function blocks—visual languages mirroring the relay systems they replaced, designed for electricians and plant engineers rather than software developers.

This design has barely changed since Morley's 1968 specifications, and there's a reason: it works. When Siemens installs a PLC in a chemical plant, that system runs continuously for decades. When Rockwell Automation deploys controllers in automotive assembly, they execute millions of flawless cycles. Industrial automation doesn't embrace Silicon Valley's "move fast and break things." The motto here is simpler: never break.

History of PLCs: From Relay Rooms to Smart Controllers

Before PLCs, factories were wired nightmares. Control logic lived in walls of electromagnetic relays—thousands of mechanical switches wired together to define how a machine behaved. Changing a production process meant physically rewiring control panels. Every model change brought weeks of downtime, armies of electricians, and staggering costs. One wrong wire could halt an entire plant.

Pre-PLC industrial relay control cabinet used in factories before programmable logic controllers replaced hard-wired relay logic

By the late 1960s, this inflexibility was becoming fatal—especially for automotive manufacturers. General Motors was bleeding money on production line retooling. Meanwhile, a young engineer named Dick Morley was running a small consulting company called Bedford Associates, helping machine tool firms upgrade to solid-state controls. The work paid well, but it was monotonous—each project essentially the same as the last.

On New Year's Day 1968, nursing a hangover and running two weeks late on yet another proposal, Morley decided there had to be a better way. That morning, he wrote a complete specification for what he called a "Programmable Controller"—a device that could replace relay logic, survive factory conditions, and be reprogrammed without rewiring. His specs were specific: no processing interrupts, direct memory mapping, rugged sealed design with heat sinks instead of fans, and a proprietary programming language (which would become ladder logic). One specification he'd later regret: he wanted it to operate slowly.

Morley took his memo to his team at Bedford Associates—Mike Greenberg, Jonas Landau, and Tom Boissevain. They got to work immediately, with one iron rule: never call it a computer. If Morley saw that word on any document, he'd throw it away. They built a rugged unit with metal fin heat sinks, completely sealed against factory environments. They named it the Model 084—Bedford's 84th project.

To commercialize the design, they needed investors. The team formed a new company in October 1968, calling it Modicon—short for Modular Digital Controller. Morley was never technically an employee, but he ran engineering. The Model 084 shipped in 1969, followed quickly by the Model 184, which fixed issues found in the original.

General Motors heard about Modicon's work and placed a million-dollar order. In November 1969, GM's Hydramatic Division took delivery of the first batch. General Electric followed with their own million-dollar order, planning to rebrand and sell the controllers as OEM units. Within a year of Modicon's founding, the PLC had gone from hungover memo to production deployment at the world's largest automaker.

PLC Pioneers Richard Morley, Tom Bossevain, George Schwenk and Jonas Landau

Morley always called himself the "Father" of the PLC rather than its "Inventor"—he knew others were working on similar solutions and believed the technology "invented itself out of necessity." Bedford Associates eventually dissolved to avoid tax complications after Modicon's success. Modicon was later acquired and is now owned by Schneider Electric, which still occasionally uses the number 84 on products as a tribute.

How a PLC Works: Scan Cycle, Inputs, and Outputs

Open a PLC cabinet on a factory floor and you'll find a metal box covered in wire terminals, mounted on a DIN rail, silently controlling millions of dollars of equipment. No monitor. No keyboard. No fan. Just a microprocessor executing the same loop it's been running since installation—sometimes for decades.

The entire operating model fits in one sentence: read sensors, run program, control outputs, repeat. That loop executes thousands of times per second with mechanical precision. It's not elegant. It's not exciting. But it's exactly what keeps production lines moving and chemical reactors stable.

What's Actually Inside a PLC

The CPU runs your control program. Modern units use industrial microprocessors—nothing exotic, just chips designed for temperature extremes and long-term reliability. They're slower than your phone but infinitely more predictable. The CPU executes code the same way every single time. No background processes. No operating system deciding to update drivers mid-cycle. Just pure determinism.

Input modules interface with sensors. A temperature probe sends a 4-20mA signal. A limit switch closes a 24V circuit. A pressure transducer outputs 1-5V DC. The input module converts these industrial signals into numbers the CPU can process, while providing electrical isolation to prevent ground loops and noise from corrupting data.

Output modules control physical equipment. The CPU decides a motor should run, and the output module closes a relay or sends a signal to a motor starter. It translates digital logic into the industrial voltages needed to activate contactors, solenoids, and valves. Like inputs, isolation protects the CPU from the electrical violence of switching inductive loads.

The power supply handles whatever garbage voltage the plant feeds it—sags during motor starts, spikes from switching, harmonics from variable frequency drives—and outputs clean DC. It's rated for abuse because industrial power is chaos.

The Scan Cycle

Every PLC runs the same four-step loop:

Input scan: Copy all sensor states into memory. This creates a snapshot—every input frozen at one moment in time.
Program execution: Run the control logic from start to finish using that snapshot. If temperature > 250°F, open cooling valve. If part detected AND quality check passed, advance conveyor.
Output update: Write all calculated outputs to physical modules. Motors start or stop. Valves open or close. But only after the entire program runs—no partial updates.
Housekeeping: Handle communications, diagnostics, error checking. Then start over immediately.

The full cycle typically takes 1-50 milliseconds depending on program complexity. A 10ms scan cycle means the PLC makes 100 complete decisions per second. It's been doing this in some facilities since the 1980s.

This approach eliminates entire classes of software bugs. Inputs can't change mid-program. Outputs can't update while logic is executing. Race conditions don't exist. The program runs in strict sequential order, identically, every scan.

Programming Languages

PLCs don't use Python or C++. They use IEC 61131-3 languages designed for industrial electricians and control engineers.

Ladder Logic looks like relay wiring diagrams because it replaced relay logic. Horizontal lines represent power. Contacts (inputs) and coils (outputs) sit between them. An electrician who understood relay panels could program a PLC immediately. It's clunky for complex math but perfect for discrete control—if sensor A triggers and valve B is closed, start pump C.

Function Block Diagrams connect boxes representing timers, counters, math operations, and PID controllers. Data flows between blocks. It works well for process control where analog signals need continuous manipulation.

Structured Text handles complex calculations and algorithms. It looks like Pascal. Modern applications increasingly need it—ladder logic becomes unmanageable for sophisticated control strategies.

Each vendor implements these standards differently. Siemens uses TIA Portal. Rockwell has Studio 5000. Schneider offers Unity Pro. The languages are theoretically portable. The reality is vendor lock-in.

Why PLCs Haven't Changed

Your phone has more processing power than any PLC in existence. Yet every new factory, water treatment plant, and production line still installs PLCs. Why?

Because reliability beats performance in industrial automation. A PLC controlling a gas turbine or pharmaceutical batch doesn't need gigahertz processors or gigabytes of RAM. It needs to execute the same logic flawlessly for 20 years while operating at 140°F in an environment with electrical noise, vibration, and dust.

Consumer computing optimizes for speed and features. Industrial computing optimizes for never failing. Ever. The scan cycle, the isolated I/O, the deterministic execution—these aren't limitations. They're the exact solution the problem requires.

That's why Morley's 1968 architecture still dominates. Not because the industry is conservative or backwards. Because he solved the problem correctly the first time.

Types of PLCs

Not all PLCs are created equal. Walk through a factory and you’ll see shoebox-sized controllers running a single machine right next to rack-mounted systems managing entire production lines. While they all execute the same basic scan cycle, the hardware differs dramatically based on what they control.

Compact PLCs

Compact PLCs integrate the CPU, I/O, and power supply into a single fixed unit. They typically handle 10–100 I/O points, making them ideal for packaging machines, pump stations, and HVAC systems. They are simple, cost-effective, and quick to deploy. Some models allow limited expansion through add-on I/O modules, but scalability is constrained. Once that limit is reached, upgrading to a modular PLC is usually required.

Examples: Siemens S7-1200, Rockwell Micro800, Schneider Modicon M221

Modular PLCs

Modular PLCs separate the CPU from the I/O modules, which are installed on expandable racks. Need hundreds of I/O points? Add modules. Need motion control, high-speed counting, or specialized communications? There is a dedicated module. This flexibility makes modular PLCs the standard for complex automation such as automotive assembly, chemical processing, and large material-handling systems. Costs typically range from $10,000 to well into six figures depending on scale and redundancy.

Examples: Siemens S7-1500, Rockwell ControlLogix, Schneider Modicon M580

Safety PLCs

Safety PLCs are designed to protect people and equipment. They control emergency stops, light curtains, safety interlocks, and other safety-critical functions using redundant processors and continuous self-diagnostics. Certified safety architectures achieve reliability levels as high as 10⁻⁸ failures per hour (SIL 3 / PLe). In most systems, safety PLCs operate alongside standard PLCs: production logic runs on the normal controller, while the safety PLC can override everything instantly when a hazard is detected.

Examples: Pilz PNOZmulti, Siemens F-series, Rockwell GuardLogix

Micro PLCs

Micro PLCs handle very small automation tasks, typically 8–20 I/O points, such as a single conveyor, pump, or sorter. They usually cost between $100 and $500 and are common in car washes, vending machines, irrigation systems, and compact OEM equipment. Programming is often simplified and focused on basic control logic rather than advanced automation features.

Examples: Unitronics, AutomationDirect CLICK, IDEC SmartRelay

Choosing the Right PLC

Selecting a PLC comes down to I/O count, system complexity, safety requirements, and future expansion. Simple machines with fewer than 20 I/O points are well served by micro or compact PLCs. Production lines with hundreds of I/O points, motion control, or advanced networking typically require modular PLCs. Any application involving human safety must use a safety-rated controller, without exception. Most companies standardize on a single vendor—commonly Siemens or Rockwell—and stay with that ecosystem for decades, as switching platforms later is costly and disruptive.

PLC, HMI, and SCADA: How They Work Together

A PLC executes control logic in milliseconds, but it doesn't have a screen. It can't show operators what's happening. It can't log historical data or send alerts. That's where HMIs and SCADA systems come in.

These three technologies form distinct layers in industrial automation. PLCs control equipment in real-time—reading sensors, running logic, operating actuators. HMIs (Human-Machine Interfaces) are the touchscreens mounted next to machines that display what the PLC is doing and let operators start equipment, adjust setpoints, and acknowledge alarms. The HMI sends commands to the PLC, which evaluates safety conditions and executes them. One HMI typically monitors one machine or production line section.

SCADA (Supervisory Control and Data Acquisition) operates at the facility level. While an HMI monitors one machine, SCADA monitors entire plants or distributed systems. It collects data from dozens or hundreds of PLCs, stores trends in databases, generates reports, and coordinates system-wide operations. A water utility might have 50 pump stations, each with a PLC. SCADA at the central control room polls all 50 continuously, displays system-wide status, and lets operators manage the entire network from one location.

In practice: PLCs sit in control cabinets executing control programs. HMIs sit next to machines for local operation. SCADA runs on servers in control rooms for facility-wide oversight. All three communicate constantly—when a PLC detects high temperature, the local HMI displays an alarm, SCADA logs it with a timestamp and sends alerts to maintenance.

This hierarchy only works if these systems can actually talk to each other. That's where industrial automation hits its biggest challenge: vendor lock-in and protocol fragmentation. Getting PLCs from different manufacturers to communicate with HMIs and SCADA systems requires protocol converters, middleware, and significant integration effort—a problem we'll tackle next.

Where PLCs Actually Run: Real-World Applications

PLCs control processes where reliability isn't negotiable. They're not exciting. They're not visible. But they're running constantly in factories, utilities, and infrastructure—often for decades without replacement.

Automotive assembly lines use PLCs to coordinate welding robots, conveyors, and quality systems. A body shop might run 50+ PLCs managing hundreds of welds per vehicle. When manufacturers retool for new models, they reprogram the controllers instead of rewiring entire panels—exactly what GM needed in 1968.

Pharmaceutical production relies on PLCs for batch reactors where temperature and timing must stay within tight tolerances. Every parameter gets logged for regulatory compliance. If conditions drift outside specifications, the PLC flags the batch automatically. Food and beverage plants use them for mixing, cooking, and packaging lines. A bottling line coordinates filling, capping, labeling, and case packing—all controlled by PLCs running the same programs they've executed millions of times.

Water treatment plants use PLCs to manage pumps, chemical dosing, and filtration based on flow rates and quality sensors. These systems often run for 20-30 years, handling daily demand variations and responding to system changes automatically. Power substations rely on PLCs for load monitoring, breaker control, and grid coordination. When generation or demand shifts, controllers adjust in milliseconds to maintain stability.

Refineries and chemical plants use them in environments where control failures create safety hazards—managing temperatures, pressures, and emergency shutdown sequences. Distribution centers use PLCs to run conveyor networks, sorting systems, and automated storage. A package gets scanned, routed through the optimal path, and diverted to the correct lane—all coordinated by controllers managing thousands of decision points per hour.

Airport baggage systems are entirely PLC-controlled. Bags move from check-in through security screening to the correct carousel, sorted by destination and flight timing. Mining operations use PLCs for conveyors, crushers, and material separation running continuously with minimal supervision. The controllers monitor equipment health, adjust speeds based on material flow, and shut down automatically when sensors detect problems.

The common thread is long-term reliability in demanding environments. PLCs installed in the 1990s are still operating in many facilities. They execute the same control logic, respond to the same sensors, and drive the same equipment—scan after scan, year after year, exactly as designed.

The Interoperability Problem: When PLCs Won't Talk

Dick Morley solved factory automation in 1968. But as PLC manufacturers raced to capture the market he created, they built incompatible proprietary ecosystems—and vendor lock-in became the industry's unintended legacy.

Every major PLC manufacturer built their own proprietary ecosystem. Siemens controllers speak different protocols than Rockwell. Schneider systems don't natively understand Mitsubishi. Walk into any facility and you'll find a mix of PLCs—legacy systems, new equipment, different vendors. They all need to exchange data. Temperature from the Siemens PLC needs to trigger an action on the Rockwell controller. Production counts need to feed from one system into another.

The traditional solution? Custom integration work. Hire specialized engineers. Write gateway applications. Deploy protocol converters. Maintain separate codebases for each connection. When something breaks, troubleshoot across multiple proprietary systems while production sits idle.

The cost isn't just technical debt. It's strategic paralysis. Companies stick with a single vendor not because they offer the best solution, but because switching is too painful.

FlowFuse: Breaking the Integration Barrier

FlowFuse, built on Node-RED, solves the protocol chaos that vendor lock-in created. Node-RED emerged from IBM in 2013, created by Nick O'Leary (now CTO of FlowFuse) and Dave Conway-Jones as a visual programming tool for connecting devices and APIs—drag nodes onto a canvas, wire them together, deploy. The industrial community built protocol nodes for Modbus, Profinet, EtherNet/IP, S7comm, OPC UA, and more. It became the universal translator for industrial systems.

FlowFuse platform for industrial data integration connecting PLCs, Node-RED, and enterprise systems

A single Node-RED instance can simultaneously communicate with Siemens S7 PLCs, Rockwell ControlLogix systems, Modbus devices, MQTT brokers, and IT systems like databases, APIs, and cloud platforms. The data flows visually. Changes deploy instantly. No compilation. No downtime. It bridges the operational technology (OT) on the factory floor with information technology (IT) systems—connecting PLCs not just to each other, but to ERP systems, historians, dashboards, and analytics platforms.

FlowFuse adds the enterprise infrastructure: centralized management across hundreds of edge devices, version control and rollback, role-based access, audit logging, and security at every layer. Build one flow that reads from Siemens PLCs and deploy it to every facility. When something changes, update once and push the change everywhere. Edge instances run locally even if network connections drop.

FlowFuse doesn't replace your PLCs. It connects them. That Rockwell controller keeps running its proven logic. The Siemens system continues its scan cycle. What changes is the integration layer that lets isolated systems finally communicate.

A large US manufacturing company with over 10,000 employees uses FlowFuse to manage thousands of Node-RED instances deployed across global facilities. These instances collect data from sensors, PLCs, and cameras on production lines, enabling them to transition from paper-based operations to real-time data visibility. A team of five developers—former manufacturing engineers, not software specialists—built hundreds of applications using Node-RED's visual programming. FlowFuse now manages deployment to thousands of remote devices and maintains multiple versions across all instances, solving what had become an unmanageable tracking challenge as they scaled.

Start small. Node-RED is open source. Connect two different PLC brands as a proof of concept. FlowFuse scales from there—one production line, then more sites, running on-premises or in the cloud as needs dictate. Want to see how FlowFuse handles PLC integration in your environment? Book a demo with our team—we'll connect to your mixed-vendor systems and show you what's possible in under an hour.

Dick Morley's hungover epiphany gave us PLCs that could be reprogrammed without rewiring. FlowFuse extends that flexibility to integration—connecting different systems without vendor permission, finally breaking the proprietary barriers Morley never intended.

Node-RED Timer Tutorial: Create Stopwatch and Countdown Timers

2025-12-24T00:00:00Z

Timers are everywhere in industrial automation. You need them to track how long a machine has been running, measure downtime, schedule maintenance, or coordinate processes that happen in sequence.

Through my work as a technical writer covering IIoT, building industrial applications, and being part of a company where our customers deploy real-world automation systems, I've observed that timers are ubiquitous in production environments. Whether it's a production floor display showing machine runtime, a maintenance terminal counting down to the next service window, or an operator interface tracking downtime by reason code—timers are foundational to industrial visibility. Here's an example of a performance operator terminal with timer functionality:

Performance operator terminal displaying real-time production metrics with timer functionality

If you want to explore this interface yourself, you can deploy this blueprint to your FlowFuse instance and start experimenting immediately.

In this article, we'll build two types of timers in Node-RED: stopwatches that measure elapsed time and countdowns that trigger actions after a set duration. Both are straightforward to implement and essential for most automation projects.

Prerequisites

Before following this tutorial, you should have:

A running Node-RED instance. For professional development and production deployments, FlowFuse is the recommended platform. If you don’t have an account, start your free trial today.

FlowFuse provides enterprise-grade Node-RED hosting with managed infrastructure, built-in DevOps tools, MQTT broker, database, team collaboration with granular access control, and seamless scaling capabilities. Whether you need cloud-hosted instances managed by FlowFuse or remote instances running on your edge devices, the platform provides unified management for both. FlowFuse also includes AI-powered features that accelerate flow development and streamline automation projects. From prototyping to mission-critical production deployments, FlowFuse handles the infrastructure complexity so you can focus on building flows.

That's all you need to get started.

Getting Started

We'll use two Node-RED community nodes for this tutorial: node-red-contrib-hourglass for stopwatch timers and node-red-contrib-countdown for countdown timers. Both are simple to configure and work reliably in production environments.

Let's start with installing and building a stopwatch.

Installing the Hourglass Node

First, install the hourglass node in your Node-RED instance:

Open the Node-RED editor
Click the hamburger menu (top right) and select "Manage palette"
Go to the "Install" tab
Search for node-red-contrib-hourglass
Click "Install"

The hourglass node will appear in your palette under the function category.

Understanding Hourglass Commands

The hourglass node responds to control commands sent via msg.command. The available commands are:

start - Begins timing operation
stop - Stops the timer and outputs elapsed time
pause - Pauses timing without resetting
reset - Clears timer state and stops operation
status - Outputs current timer state without stopping

These commands control timer behavior.

Implementing a Stopwatch Timer

Build a basic stopwatch flow:

Drag four inject nodes onto the canvas
Add four change nodes, one after each inject node, and connect them
Configure the change nodes to set msg.command:
- First change node: set to "start"
- Second change node: set to "status"
- Third change node: set to "stop"
- Fourth change node: set to "reset"
Drag an hourglass node onto the canvas
Connect all four change nodes to the hourglass node input
Add a debug node and connect it to the hourglass node output
Deploy the flow

When you trigger the first inject node, the stopwatch starts. The second inject node checks current elapsed time without stopping the timer—you can configure this inject node to repeat at intervals for continuous time monitoring. The third inject node stops the stopwatch and outputs the total elapsed time. The fourth inject node resets the stopwatch back to zero.

The node outputs a message containing timing information:

Hourglass node output message showing elapsed time in multiple formats

The elapsed object provides multiple formats: a human-readable string, total milliseconds, and broken-down time components. This flexibility supports different display requirements and calculation needs.

This basic example demonstrates the pattern. In production applications, replace the inject nodes with actual process triggers—machine status signals from PLCs or MQTT messages from sensors. The hourglass node output then connects to databases for logging, dashboards for visualization, or notification systems for alerts when thresholds are exceeded.

Below is the complete flow.

Implementing a Countdown Timer

Countdown timers trigger actions after a specified duration. Common applications include scheduled maintenance windows, batch process timeouts, and timed equipment shutdowns.

To implement a countdown, we will use node-red-contrib-countdown.

Installing the Countdown Node

Install the countdown node in your Node-RED instance:

Open the Node-RED editor
Click the hamburger menu (top right) and select "Manage palette"
Go to the "Install" tab
Search for node-red-contrib-countdown
Click "Install"

The countdown node will appear in your palette.

Building a Countdown Timer

Create a countdown timer flow in Node-RED:

Drag an Inject node onto the canvas.
Add a Change node and configure it to:
- Set msg.payload to the countdown duration in seconds (for example, 50 for 50 seconds).
- Set msg.topic to "control".
- You can configure the countdown duration either in the Change node or directly in the Inject node, as long as msg.payload is in milliseconds and msg.topic is "control".
Drag a Countdown node onto the canvas and configure it with the following settings:
- Timer On payload: The message payload sent when the countdown starts (for example, true).
- Timer Off payload: The message payload sent when the countdown completes (for example, false).
- Restart countdown if message is received while running: Enable this to restart the countdown if a new control message is received.
- Send output message on Reset: Enable this to send a message when the countdown is reset.
- Set time to new duration if control message is received while running: Enable this to update the countdown duration while it is running.
- Start countdown if control message is received while not running: Enable this to start the countdown using a control message, enable it for this example to allow starting countdown when control message recived
Connect the Change node to the Countdown node.
Add a Debug node and connect it to the Countdown node output.
Click Deploy to activate the flow.

When you trigger the Inject node, the countdown starts. The Countdown node outputs messages at regular intervals, and the second output shows the remaining time.

Countdown node output showing remaining time updates

From the first output, it will send the message you configured at the start of the count and at the end of the countdown.

Below is the flow implementation that you can use as a starting point.

For this demonstration, we used an inject node to manually trigger the countdown. In production environments, you would replace this with actual process triggers—equipment status signals from PLCs, MQTT messages from sensors, or completion signals from upstream operations. For example, you might start a maintenance window countdown when equipment reaches a scheduled service interval, or initiate a cleanup cycle timer when a batch process completes.

While these examples cover the essential timer operations, both nodes offer additional configuration options. For comprehensive documentation, visit the node-red-contrib-hourglass and node-red-contrib-countdown pages on the Node-RED flows library.

Conclusion

That's it, you now have working stopwatch and countdown timers in Node-RED. The hourglass node tracks elapsed time, and the countdown node triggers actions after a set duration.

These implementations are ready for production use. Start with these basic patterns, test them in your environment, and expand as needed. Connect them to your PLCs, add dashboard displays, or integrate with your existing automation workflows.

Both nodes are actively maintained and used in real industrial systems, so you're building on proven foundations.

Five Whys Root Cause Analysis: Definition, Steps & Examples (2026)

2025-12-22T00:00:00Z

The Five Whys is a root cause analysis technique where you ask "why" repeatedly—typically five times—until you identify the underlying systemic cause instead of just symptoms.

Your equipment fails on Tuesday. The maintenance team fixes it. It fails again on Friday. They fix it again. Three weeks later, same failure. This cycle continues because everyone treats the symptom—the broken part—instead of asking why it broke.

The Five Whys breaks this pattern. Developed by Sakichi Toyoda at Toyota in the 1930s, it's become the standard root cause analysis method across manufacturing, healthcare, software development, and anywhere recurring problems drain productivity. The technique works through systematic questioning that strips away symptoms to expose fixable failures in your systems—the process gaps, training deficiencies, and procedural weaknesses that allow problems to persist. When applied correctly, it takes under an hour and prevents problems from returning.

What Is the Five Whys Root Cause Analysis Method?

The Five Whys root cause analysis is a questioning technique where you ask "why" a problem occurred, then ask "why" that condition existed, then keep asking until you hit something you can actually fix at a systemic level. It was developed by Sakichi Toyoda in the 1930s and became a core tool in the Toyota Production System. Today it's used across manufacturing, healthcare, software development, and anywhere else people need to solve recurring problems.

The technique is deceptively simple. You start with a specific problem. You ask why it happened. You take that answer and ask why again. You keep going until asking "why" one more time would just be splitting hairs or rehashing what you already know. Usually that takes about five iterations—the number comes from the observation that five whys is typically sufficient to reveal the root cause—but I've seen effective analyses that stopped at three and others that went to eight.

Watch this video if you prefer video format:

Why the Five Whys Works When Other Methods Don't

Organizations often spend weeks on elaborate root cause analyses using fault trees, fishbone diagrams, and statistical process control charts, only to implement solutions that don't stick. The Five Whys succeeds where these methods often fail for three reasons.

First, it's fast. You can complete a thorough analysis in under an hour. That speed matters because problems are freshest when they just happened. Witnesses remember details. Physical evidence hasn't been cleaned up or moved. The sense of urgency is still there. Wait two weeks to schedule your analysis meeting, and you're working from memory and assumptions.

Second, it's accessible. The machine operator who saw the problem doesn't need training in statistical methods or failure mode analysis. They just need to answer questions honestly about what they observed. This democratization of problem-solving means you're not waiting for specialists to free up their calendars. The people closest to the work can solve problems themselves.

Third, it forces you to follow a single causal chain all the way down. Other methods encourage you to map out every possible contributing factor simultaneously. That comprehensiveness sounds good in theory, but in practice it often leads to analysis paralysis. You've identified seventeen potential causes, and now you're trying to fix all of them at once. The Five Whys makes you pick the most likely path and follow it to the end. You can always come back and explore alternative explanations if your first solution doesn't work.

The Five Whys Checklist: What You Need Before You Start

Most failed Five Whys sessions fail before they even begin because people skip the setup. You need four things in place before you ask the first question.

Before you ask the first question, you need four things:

A specific problem statement. "Quality issues in Department B" won't work. "Thirty-seven units failed final inspection on December 18th due to incomplete welds" will. Specificity disciplines your thinking and keeps the analysis focused.
The right people. That means at least one person who directly observed or experienced the problem, someone who understands the process well enough to spot abnormal conditions, and a facilitator who can keep the questions moving forward. Three to five people is ideal. More than that and you'll spend more time managing the discussion than conducting the analysis.
Location at the gemba. Conduct the analysis close to where the problem occurred. This principle, which Toyota calls gemba, matters more than most people realize. Conference rooms encourage abstract thinking. The shop floor, the customer service desk, or the server room keeps everyone grounded in physical reality. You can point at things. You can test hypotheses on the spot.
Commitment to honest answers. If the real reason your new hires keep making mistakes is that your training program is inadequate, you need people willing to say that out loud. If your preventive maintenance schedule was designed fifteen years ago and never updated, someone needs to acknowledge it. The Five Whys only works if people tell the truth about what they see.

How to Complete a Five Whys Root Cause Analysis

The mechanics of the method are straightforward, but execution requires more care than most people expect.

Five Whys funnel diagram from problem to root cause

Start by stating the problem as precisely as you can. Write it down where everyone can see it. If you're working through this at the gemba, write it on a whiteboard or a large sheet of paper. If you're remote, put it in a shared document. The problem statement anchors everything that follows, so take the time to get it right. Include what happened, when it happened, where it happened, and how you know it happened. Measurements matter here. "Production was slow" is too vague. "Line 3 produced 847 units against a target of 1,000 units during the first shift on December 20th" gives you something concrete to investigate.

Ask your first why: Why did this specific problem occur? The answer should be factual, not speculative. "I think maybe the bearings were worn" isn't good enough. "The motor seized, and when we disassembled it, we found metal shavings in the bearing housing" is what you're after. If you don't know the answer with certainty, stop and gather evidence before continuing.

Take that answer and ask why again. Why did the motor bearings fail? Because the lubrication system wasn't delivering oil to that bearing. How do you know? Because we checked the oil flow and found the feed line was clogged. This is where many analyses go wrong. People start speculating instead of observing. They say things like "probably the operator forgot to check it" when what they actually know is that the line was clogged. Stick to what you can verify.

Continue this pattern. Each answer becomes the subject of the next question. Why was the feed line clogged? Because particulate from the oil reservoir got into the line. Why was there particulate in the reservoir? Because we're not filtering the oil when we top off the reservoir. Why aren't we filtering it? Because the maintenance procedure doesn't specify using a filter when adding oil.

Stop when you've identified a process failure or systemic gap. In this case, the inadequate maintenance procedure is your root cause. It's something you can fix with a clear corrective action: revise the maintenance procedure to require filtered oil and provide the appropriate filtering equipment. That's different from "operator error" or "equipment failure," which are symptoms, not causes.

Notice that this example took exactly five questions, but that's coincidental. Effective analyses sometimes reach the root cause in three questions and other times need eight. The number doesn't matter. What matters is reaching the point where you've identified something you can actually fix.

When and Where Should You Use the Five Whys?

The Five Whys is particularly effective for problems with a dominant causal chain. If your problem has one primary cause with some contributing factors, this method will find it quickly. It works well for equipment failures, quality defects, process bottlenecks, safety incidents, and customer complaints where you're trying to understand what broke down in your systems.

It's less effective for complex problems with multiple simultaneous causes that interact with each other. If you're investigating a major product recall with contributing factors spanning design, materials, manufacturing, and distribution, the Five Whys will feel inadequate. You're better off with something like fishbone analysis or fault tree analysis that lets you map multiple causal pathways simultaneously.

The method also struggles with problems that have deep organizational or cultural roots. If your real issue is that nobody wants to report problems because they fear retaliation, asking "why" five times might surface that fact, but fixing it requires organizational change management that's well beyond what a questioning technique can address. The Five Whys can identify the issue, but you'll need other tools to solve it.

The method works well for equipment failures and maintenance issues, quality problems that recur despite corrections, process bottlenecks that resist obvious solutions, safety incidents requiring rapid investigation, and customer complaints where you need to fix internal processes. It struggles with problems that have multiple independent causes, new product development scenarios where you're trying to prevent future failures, strategic planning issues, and situations where participants don't have sufficient knowledge to answer accurately.

The Toyota Five Whys: Where This Method Came From

Sakichi Toyoda developed the Five Whys in the 1930s as part of the manufacturing methodology that would eventually become the Toyota Production System. Toyoda, who founded what would become Toyota Industries, was obsessed with understanding why things failed. His approach was radical for its time: instead of accepting problems as inevitable, he insisted they were symptoms of deeper issues that could be identified and eliminated.

His son Kiichiro Toyoda and engineer Taiichi Ohno refined the method as they developed Toyota's production system in the decades after World War II. They formalized the practice of going to the gemba to observe problems firsthand and asking why until you hit something systemic rather than symptomatic.

Toyota's success with this approach attracted attention in the 1970s and 1980s when Western manufacturers were trying to understand why Japanese companies were outcompeting them. The Five Whys spread beyond automotive manufacturing into other industries, though often without the cultural foundation that made it effective at Toyota. Many companies adopted the technique as a standalone tool without understanding that it only works in an environment where people feel safe identifying systemic problems and where management is committed to fixing them.

That context matters when you're implementing the Five Whys in your organization. The technique itself is simple, but it won't survive in a culture that shoots the messenger or treats problem identification as complaining rather than continuous improvement.

Best Practices From Experienced Root Cause Analysis

Focus on processes and systems, not people. When your analysis points to an individual who made a mistake, don't stop there. Ask why that mistake was possible. Why didn't training cover this situation? Why didn't the procedure include a verification step? Why wasn't there a physical or administrative control that would have caught the error? Robust processes assume people will make mistakes and build in safeguards. If your process allows one person's mistake to cause a significant problem, your process is inadequate.

Verify every answer before moving to the next question. The Five Whys fails when it becomes an exercise in brainstorming rather than investigation. Each answer should be based on evidence you can point to: physical observations, data from sensors or logs, documents, measurements, or direct testimony from witnesses. If your team is guessing, stop and gather facts.

Stay on one causal chain at a time. Real problems often have multiple contributing causes, and your team will want to explore all of them simultaneously. Resist this. Follow the most likely path all the way to the end first. If the corrective actions you implement don't solve the problem, you can come back and explore alternative paths. Trying to investigate everything at once creates confusion and dilutes your focus.

Keep your questions neutral. "Why did the operator forget to check the pressure?" assumes forgetfulness and points toward blame. "Why wasn't the pressure checked?" opens up multiple possibilities including procedural gaps, time pressure, distraction, inadequate training, or unclear responsibility. How you phrase the question shapes what answers you'll get.

Know when to stop. You've found your root cause when the answer identifies something you can fix through a procedural change, a training modification, a design improvement, or another corrective action that addresses the systemic level. If you keep asking why beyond that point, you'll end up with philosophical answers about organizational culture or budget constraints that aren't actionable in the context of this specific problem.

Common Mistakes That Undermine Five Whys Analysis

The most frequent mistake is stopping at symptoms. A part fails, and the team replaces it, logs "component failure" as the root cause, and moves on. That's not root cause analysis. That's just describing what happened. The root cause is why the component failed: inadequate maintenance, incorrect installation, design limitation, contamination, or some other systemic issue that made the failure possible.

Another common failure is accepting "human error" as a root cause. People make mistakes. This is not new information. If your analysis concludes that someone made a mistake, ask why that mistake was possible and why existing safeguards didn't prevent or catch it. Human error is a symptom, not a cause.

Teams sometimes rush through the analysis because they're uncomfortable with the questions. Someone asks why a procedure wasn't followed, and instead of actually investigating, the team quickly blames the operator and moves on. This happens in organizations where problem-solving has become a blame-finding exercise. If your culture doesn't support honest answers, the Five Whys won't work regardless of how well you understand the technique.

Some teams branch off into multiple causal chains without finishing any of them. They ask the first why, get an answer, then immediately see three more potential causes and start investigating all of them. Before long, they've filled a whiteboard with possibilities but haven't followed any single path to a concrete root cause. Discipline yourself to investigate one chain completely before exploring alternatives.

Tools and Software for Five Whys Analysis

You don't need specialized software to conduct a Five Whys analysis. A whiteboard, a notepad, or a simple word processing document works fine. The tool matters far less than the discipline with which you apply the method.

That said, organizations that conduct frequent root cause analyses often find value in standardized digital tools. Quality management systems like ETQ, MasterControl, or Sparta Systems include Five Whys templates integrated with corrective action tracking. This integration helps ensure that the actions identified during analysis actually get completed and verified.

Project management platforms can be adapted for Five Whys documentation if you configure custom workflows. The advantage here is that corrective actions automatically flow into your existing task management processes rather than living in a separate system that nobody checks.

Some organizations prefer physical tools. I've worked in plants that keep Five Whys templates on clipboards at each production line. When a problem occurs, the shift supervisor conducts the analysis right there, documents it on the physical form, and posts it on a problem-solving board where everyone can see it. This visibility reinforces the importance of root cause analysis and shares lessons learned across shifts.

The best tool is the one your team will actually use consistently. If your organization already has a quality management system, use that. If you're just starting out, begin with the simplest thing that works: a shared document template and a commitment to complete one analysis per week.

What Is the 5 Problem-Solving Steps Process?

The 5 problem-solving steps is a broader framework that incorporates the Five Whys as one component. The steps are: define the problem, analyze the root cause, develop solutions, implement corrective actions, and verify effectiveness. The Five Whys specifically addresses the second step, root cause analysis.

This framework matters because root cause analysis by itself doesn't solve problems. You also need clear problem definition up front, solution development after you identify the cause, disciplined implementation, and verification that your corrective actions actually worked. Organizations sometimes do excellent Five Whys analyses but never implement the corrective actions they identify. The analysis becomes an end in itself rather than a means to improvement.

Effective problem-solving requires all five steps in sequence. Rushing to solutions before you understand root causes leads to wasted effort fixing the wrong things. Identifying root causes but failing to implement solutions means nothing changes. Implementing solutions without verification means you never know if they actually worked or if the problem just hasn't recurred yet by chance.

Example of a 5 Why Question in Practice

What does an effective Five Whys question actually sound like? Here's the classic example from Taiichi Ohno, one of the architects of the Toyota Production System, documented in his book "Toyota Production System: Beyond Large-Scale Production" (1988, p. 17).

The problem: A machine stopped functioning on the factory floor.

Why #1: "Why did the machine stop?"
Answer: There was an overload and the fuse blew.

Why #2: "Why was there an overload?"
Answer: The bearing was not sufficiently lubricated.

Why #3: "Why was it not lubricated sufficiently?"
Answer: The lubrication pump was not pumping sufficiently.

Why #4: "Why was it not pumping sufficiently?"
Answer: The shaft of the pump was worn and rattling.

Why #5: "Why was the shaft worn out?"
Answer: There was no strainer attached and metal scrap got in.

Root cause: No strainer in the lubrication system allowing debris contamination.

Corrective action: Install a strainer in the lubrication system to prevent metal scrap from entering the pump.

This example demonstrates the fundamental questioning pattern. Modern Five Whys analyses typically include more detailed evidence documentation at each step (inspection reports, sensor data, maintenance logs), but the core approach of following a single causal chain to reach a systemic issue remains unchanged. Notice how the analysis moved from a symptom (blown fuse) through intermediate causes (overload, insufficient lubrication, worn shaft) to arrive at a fixable process gap (missing strainer).

Implementing the Five Whys in Your Organization

If you want to implement the Five Whys effectively, start with a pilot program rather than a company-wide rollout. Select one department or one type of problem as your initial focus. Train a small group of people thoroughly rather than providing superficial training to everyone. Conduct your first few analyses with experienced facilitation, ideally from someone who has used the method successfully in another organization.

Expect the first several analyses to feel awkward. People will struggle with phrasing neutral questions. They'll want to skip ahead to solutions before finishing the analysis. They'll be uncomfortable when the questioning reveals gaps in procedures or training. This is normal. The skill develops with practice.

After each analysis, conduct a brief debrief focused on the process itself. What went well? Where did we struggle? Did we gather evidence before answering, or did we speculate? Did we follow one causal chain to the end, or did we branch off into multiple paths? This reflection builds capability faster than simply conducting more analyses.

Track your corrective action completion rate. If actions identified during Five Whys analyses aren't being implemented, you have an organizational problem that needs attention. Root cause analysis without follow-through is worse than no analysis at all because it creates the illusion of improvement while nothing actually changes.

Give it six months before evaluating whether the method is working for your organization. You should see a reduction in recurring problems, faster resolution of new problems, and increasing confidence among frontline staff in their ability to identify and solve issues. If you're not seeing these outcomes, the problem is usually implementation rather than the method itself.

Measuring Whether the Five Whys Is Working

How do you know if the Five Whys is actually improving your operations? Four metrics tell the story:

Problem recurrence rates. If you're conducting thorough root cause analyses and implementing effective corrective actions, the same problems should stop reappearing. Pull your incident data from six months before you started using the Five Whys and compare it to six months after. Look for problems that used to recur monthly or quarterly that have stopped appearing.

Cycle time from problem to solution. As your team gets more practiced with the method, this should decrease. Early on, you might take two weeks to complete an analysis and implement corrections. After several months of practice, you should be conducting same-day or next-day analyses with corrective actions implemented within a week.

Quality of corrective actions. Are you implementing procedural changes, training improvements, and system modifications? Or are you repeatedly concluding that operators need to "be more careful" and issuing reminders? High-quality corrective actions address systemic issues. Low-quality corrective actions ask people to try harder without changing anything about the system they work in.

Staff engagement. Are frontline staff bringing problems forward more readily? Are they participating actively in analyses? Are they suggesting root causes and corrective actions? Increasing engagement signals that the method is building problem-solving capability across your organization rather than remaining a management-only activity.

The Limitations Nobody Talks About

The Five Whys has limitations that don't get discussed much in the literature promoting it. Understanding these limitations helps you apply the method appropriately rather than treating it as a universal solution.

First, the method assumes a relatively linear cause-and-effect relationship. Many real-world problems involve complex interactions between multiple systems where causes and effects aren't clearly distinguishable. Equipment failures in modern automated systems often result from software interactions, sensor drift, mechanical wear, and operator actions all contributing simultaneously. The Five Whys struggles with this kind of complexity because it forces you to follow a single thread.

Second, the technique depends entirely on the knowledge and honesty of the people answering the questions. If they don't actually know why something happened, they'll speculate. If they're afraid of identifying systemic issues that might reflect poorly on management, they'll stop at superficial answers. The Five Whys doesn't magically generate insight. It structures questioning, but the quality of answers depends on the people providing them.

Third, the method can lead to what statisticians call "confirmation bias." If your team already suspects the cause of a problem, the questions will unconsciously steer toward confirming that hypothesis rather than genuinely exploring alternatives. A facilitator aware of this bias can counteract it, but it requires conscious effort.

Finally, the Five Whys doesn't help you prioritize which problems to investigate. If you have twenty recurring issues, it doesn't tell you which five deserve immediate root cause analysis and which can wait. You need a separate prioritization framework based on safety risk, financial impact, frequency, or strategic importance.

These limitations don't make the method useless. They just mean you need to recognize when you're facing a problem that requires a different or additional approach.

What Happens After the Analysis

The Five Whys analysis is the easy part. Implementation is where most organizations struggle. You've identified that your preventive maintenance schedule is inadequate, or your training program has gaps, or your procedures haven't been updated to match your current equipment. Now you have to actually fix these things, which requires resources, time, and organizational commitment.

Effective implementation requires clear ownership. Someone needs to be specifically responsible for each corrective action, with a realistic deadline and the authority to make the necessary changes. "The maintenance department will handle it" doesn't work. "James will revise the PM schedule by December 15th and review it with the maintenance manager before implementation" does.

Build verification into your corrective actions. How will you know if the changes you implemented actually solved the problem? In some cases, verification is straightforward: if the problem was equipment failures, track whether failures stop occurring. In other cases, you need to actively test: if you revised a procedure, observe someone following the new procedure to ensure it's clear and complete.

Communicate the results. When a Five Whys analysis leads to improvements, tell people about it. Post the analysis and the corrective actions where staff can see them. Mention it in team meetings. This visibility serves two purposes: it demonstrates that problem-solving leads to real changes, and it shares lessons learned across your organization so other areas can benefit from what you discovered.

Don't declare victory too soon. Some corrective actions take time to show results, and some problems are intermittent enough that you need several months of data to confirm they're truly resolved. Plan a follow-up review three to six months after implementation to verify effectiveness and make adjustments if needed.

The Five Whys is a tool for getting to root causes. But getting to root causes only matters if you do something about them. The analysis takes thirty minutes. The real work comes after.

Monitor Your Corrective Actions Across All Systems

You've identified the root cause and implemented fixes. Now you need to verify they're working, across IT systems, OT equipment, quality databases, and maintenance platforms.

FlowFuse connects them all. Whether it's legacy PLCs or modern IoT sensors, ERP systems or SCADA networks, FlowFuse brings your data together in one place. Build dashboards that track the metrics proving your solutions worked: reduced equipment failures, lower defect rates, improved maintenance compliance, or whatever KPIs matter for your specific corrective actions.

Catch warning signs before problems recur. See trends that reveal whether your fixes are holding or degrading over time. Turn root cause analysis into continuous improvement with real-time monitoring.

Start connecting your systems with FlowFuse and prove your Five Whys analyses deliver lasting results.

What is TEEP? Calculation, Benchmarks & TEEP vs OEE (2026)

2025-12-19T00:00:00Z

Total Effective Equipment Performance (TEEP) is a manufacturing KPI used to understand how much of an equipment investment is actually being utilized. While most manufacturers rely on Overall Equipment Effectiveness (OEE) to assess shop-floor performance, years of real-world use have revealed a critical blind spot: OEE only measures how well equipment runs when it is scheduled to run. It says nothing about the many hours assets sit idle due to planning decisions, demand patterns, labor availability, or maintenance strategy.

This gap matters. In many factories, equipment represents the largest capital investment on the balance sheet, yet significant capacity remains unused outside scheduled production hours. TEEP addresses this gap by extending measurement beyond scheduled production and into total calendar time—providing visibility into both operational performance and unused capacity.

To understand how TEEP does this, it’s important to be precise about what the metric actually measures.

What is TEEP?

TEEP measures the percentage of total calendar time that equipment spends producing good parts at the correct speed. Unlike OEE, which evaluates performance only during planned production, TEEP includes every hour of the day, whether production was scheduled or not. That means all 168 hours in a week and all 8,760 hours in a year are part of the calculation.

This distinction is fundamental. If a factory operates a single shift per day, OEE evaluates only those eight scheduled hours and ignores the remaining sixteen. TEEP counts them all. As a result, TEEP reveals how much of the equipment’s full potential is actually being used—not just how well it performs during active shifts.

TEEP Formula and Calculation

The math works the same way as OEE:

TEEP = Availability × Performance × Quality

But availability now means operating time divided by total calendar time, not just scheduled time. If a production line runs 120 hours per week at full speed with no defects, it has 71.4% TEEP (120 divided by 168). The other 48 hours might be maintenance time, unplanned downtime, or time when no production was scheduled.

Why TEEP Matters

TEEP matters because it connects operational performance to business value, not just shop-floor efficiency. While OEE shows how well equipment runs during scheduled shifts, it says nothing about how much of the asset you're actually using relative to what you paid for it. TEEP fills that gap.

For capital-intensive manufacturing, this difference is critical. Equipment often represents millions in investment, yet much of that capacity may sit idle due to scheduling choices, demand patterns, labor availability, or maintenance strategy. TEEP makes this visible. It answers the executive-level question: "Are we getting a return on our equipment, or is capacity hiding in plain sight?"

TEEP is especially valuable when:

Customer demand is increasing and capacity feels tight
Management is considering adding shifts or buying new equipment
Capital expenditure decisions need justification
Different plants or lines need to be compared at a high level

In many cases, TEEP reveals that the fastest and cheapest way to increase output is not buying new machines—but better utilizing the ones already installed. A modest TEEP improvement can unlock significant production capacity without additional capital investment.

Importantly, TEEP is not about pushing equipment to run 24/7 at all costs. Instead, it provides the data needed to make intentional, informed decisions about scheduling, staffing, maintenance, and growth.

TEEP vs OEE: Key Differences

OEE and TEEP both measure equipment performance, but they look at different things. The big difference is what time period they measure against.

Feature	OEE	TEEP
What it measures	How well equipment runs during scheduled time	How much of total time equipment actually produces
Time counted	Only planned production hours	Every hour (24/7, all year)
Who uses it	Production supervisors and operators	Executives and plant managers
Typical numbers	60-85% is good	30-80% depending on shifts
Main question answered	"How efficiently did we use our scheduled time?"	"How much are we actually using this equipment?"

Here's another simple example:

Your packaging line runs one 8-hour shift per day, Monday through Friday. In one week:

You scheduled 40 hours of production
Equipment actually ran well for 34 hours
Your OEE: 85% - Great! The production team did an excellent job during their shift.
Your TEEP: 20% - The equipment was productive for 34 out of 168 total hours in the week.

Both numbers are correct and useful. OEE shows your production team is doing their job well. TEEP shows the equipment sits unused most of the time. Whether that's okay depends on customer demand, labor costs, and your business strategy.

What Is a Good TEEP Score?

One of the most common questions manufacturers ask is: "What TEEP score should we target?" The answer depends entirely on your industry, shift strategy, and business model.

Industry-Specific TEEP Benchmarks:

Continuous process industries (paper mills, chemical plants, refineries): 80-90% TEEP for critical equipment. These operations are designed for 24/7 production, and high TEEP reflects the economics of continuous processing.
Two-shift batch manufacturers (automotive parts, packaging, electronics): 40-60% TEEP is typical. Even with excellent operational performance, running two 8-hour shifts five days per week caps theoretical maximum TEEP at 48%.
Single-shift operations (job shops, specialized manufacturing): 25-35% TEEP is common and often optimal. Running one 8-hour shift per day limits maximum TEEP to about 24% even with perfect execution.

The key insight: good TEEP is relative, not absolute. A 35% TEEP might represent world-class performance for a single-shift custom manufacturer, while 65% TEEP could indicate serious underutilization for a continuous process line.

What matters most is:

Trend analysis: Is your TEEP improving or declining over time?
Internal benchmarking: How does similar equipment compare within your facility?
Business alignment: Does your TEEP support your capacity strategy and customer demand patterns?

Don't chase arbitrary TEEP targets. Instead, use TEEP to understand whether your equipment utilization matches your business strategy, identify capacity constraints before they become critical, and make informed decisions about shift additions or capital investments.

How to Use Both Metrics

Most companies track both OEE and TEEP. OEE stays the main tool for production supervisors and operators who focus on running equipment well during scheduled time. TEEP gives executives information they need for planning capacity, deciding on equipment purchases, and analyzing whether to expand into new markets.

To calculate TEEP correctly, you need to track time carefully. Many manufacturing systems already sort downtime into planned and unplanned categories for OEE. TEEP needs more detail:

Scheduled production time: When equipment runs or could start running right away
Planned maintenance: Regular maintenance windows
Changeovers: Time spent switching between different products
No orders: Equipment sits idle because not enough customers want products
Operational limits: Problems with other equipment, not enough workers, or other constraints

Without clear categories, TEEP can unfairly punish good operational decisions. Equipment that creates bottlenecks should show high TEEP. Other equipment may correctly show lower numbers.

Real-World Examples

TEEP works best in industries where equipment can run around the clock. Paper mills, chemical plants, and steel factories typically target higher TEEP values for their main production equipment since continuous operation makes business sense for these processes.

Industries that make distinct products in batches usually see lower numbers. This makes sense when you think about it: a factory running two eight-hour shifts, five days per week, can only reach about 48% TEEP even if everything runs perfectly during those scheduled hours.

The automotive industry shows why context matters. Assembly lines often run two shifts per day. Even with excellent operational performance during scheduled production time, TEEP numbers naturally stay lower. This reflects intentional business decisions about shift schedules, labor costs, and maintenance planning rather than poor performance.

Common Mistakes to Avoid

Several problems come up when companies use TEEP incorrectly. One major mistake is using TEEP to judge daily operations. Production workers cannot control customer demand or high-level scheduling decisions. Holding supervisors responsible for TEEP creates bad incentives to build unnecessary inventory or skip planned maintenance.

Another common error is ignoring the bigger picture. Equipment designed to handle product changes, quality testing, or work with other equipment should not be compared to equipment that runs continuously. A 35% TEEP might be the best possible number for a packaging line that serves multiple production lines.

Finally, many companies make the mistake of treating TEEP as a fixed target. TEEP helps you compare performance over time or across similar equipment. A dropping TEEP trend means you should investigate. But any single TEEP number needs context to understand what it means.

Using TEEP for Capacity Planning

TEEP helps most when planning capacity. When customer demand gets close to what you can produce, companies face a big decision: spend money to expand capacity or accept slower growth. TEEP analysis clarifies this choice by showing how much extra capacity exists in current equipment.

A factory with 65% TEEP across major equipment could theoretically increase production by 54% without buying new equipment, assuming customer demand exists and operational problems can be solved. Whether this capacity can actually be used depends on shift schedules, worker availability, maintenance needs, and product mix—but TEEP shows the theoretical maximum.

Setting Up TEEP Measurement

Companies that want accurate TEEP need good data collection systems. Writing down times by hand produces unreliable results. Automated data capture from equipment computers, control systems, or manufacturing software provides the foundation for accurate calculations.

The money spent on measurement systems should match decision-making needs. Companies making frequent capacity investment decisions benefit from real-time TEEP monitoring. Organizations with stable capacity and clear bottlenecks might find quarterly manual calculations work fine.

Building TEEP dashboards has become much simpler with modern tools. FlowFuse offers a practical solution for companies that want real-time equipment monitoring without complex programming. The platform bridges the gap between OT (Operational Technology) on the factory floor and IT systems in the office. It connects directly to your equipment—whether through PLCs, SCADA systems, or machine controllers and MES platforms—and creates visual dashboards that track performance metrics. You can see how straightforward the process is by looking at their OEE dashboard blueprint. The same approach works for TEEP—connect your data sources, set up the calculations, and view your equipment utilization in real-time. This makes professional-grade monitoring accessible even for smaller manufacturers or companies without dedicated programming staff.

Want to see how TEEP monitoring would work for your specific equipment and production environment? Book a demo with FlowFuse to explore how you can track equipment utilization, identify capacity opportunities, and make data-driven decisions about your manufacturing assets.

The Bottom Line

TEEP extends equipment measurement from operational efficiency to overall asset use. It does not replace OEE but adds to it by answering questions OEE cannot answer. When used carefully with proper context, TEEP gives manufacturing leaders clear visibility into total equipment productivity. It helps inform capacity investment decisions with solid numbers. The value is not in achieving high percentages but in understanding what those percentages reveal about equipment use, customer demand, and operational constraints.

FlowFuse 2.25: Interacting with MCP Resources in FlowFuse Expert, Improved Update Scheduling, and lots of UI improvements!

2025-12-18T00:00:00Z

This release comes with some big updates for the FlowFuse Expert.

Interact with MCP Resources in FlowFuse Expert

[FlowFuse Expert Interface]

Our MCP nodes make is super easy to extend AI Agents with tools and resources in your environment. With this release, we're introducing the ability to interact your MCP servers directly within the FlowFuse Expert.

Previously, when setting up an MCP server in FlowFuse, you would first designate your tools, resources, and servers in side of Node-RED using the MCP nodes. Then, to interact with them, you needed a separate tool like VSCode to query and perform operations.

We want you to be able to access your resources as quickly and easily as possible, and reduce the manual overhead involved in managing and querying your MCP resources.

We've greatly simplified this process. You can now set everything up in Node-RED and then use the FlowFuse expert to designate your tools and interact with them, without ever leaving FlowFuse. This will speed you up and simplify your operations.

FlowFuse Expert Assistant in Node-RED

[FlowFuse Expert UI]

We're very excited to announce that all Node-RED users can now use our FlowFuse Expert Assistant. The ASsistant will help you create Function nodes, Template nodes, and explain highlighted flows using the Flow Explainer.

Previously, this was only available in Node-RED managed directly by the FlowFuse platform. Now everyone using Node-RED, whether they are a FlowFuse user or not, can make use of this technology and speed the development of their Node-RED workflows.

You will need an account on FlowFuse Cloud to connect it to, but for this release, it does not require a paid subscription to use.

Check the FlowFuse Expert Assistant docs for how to get started.

Improved Update Scheduling

[Scheduled Updates Interface]

We added the ability to schedule updates for your instances in the last release. Based on user feedback, we've now also added the ability to schedule restarting of your instance regardless of whether an update is available.

Lots of small updates for a better user experience

When we plan our releases, we look for what will make good headlines in our release annoucements - the big, shiny features that can get lots of attention. Sometimes we also take an opportunity to clear lots of little issues that ultimately are less headline-worthy, but all make for a better user experience.

For example, this release sees lots of small improvements to the FlowFuse Tables user experience; adding the ability to refresh the displayed data, more accessible column table names, an improved layout. Nothing to set the socials buzzing, but genuine quality of life improvements to our users.

What else is new?

For a complete list of everything included in our 2.25 release, check out the release notes.

Which of these new features are you most excited to try? Reach out on GitHub or social media!

Try FlowFuse

FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

Get started for free and have your Node-RED instances running in the cloud within minutes.

Self-Hosted

Get FlowFuse running locally in under 30 minutes using Docker or Kubernetes.

MQTT vs Kafka: Complete Comparison Guide 2026

2025-12-17T00:00:00Z

Building IoT systems means making hard choices about how messages flow through your infrastructure. Apache Kafka and MQTT couldn't be more different in their approaches. MQTT came from the world of sensors and resource-constrained devices. Kafka was designed to push massive data streams between backend systems. Getting this choice right early determines whether your architecture scales smoothly or hits a wall.

What Makes MQTT Different

MQTT (Message Queuing Telemetry Transport) showed up in 1999 when engineers needed to monitor oil pipelines with SCADA systems over unreliable satellite links. The whole point was squeezing messages through terrible networks without killing battery life.

The protocol uses binary encoding with headers as small as 2 bytes. That's it. This matters when you're running on an ESP32 with 520KB of RAM or sending data over a 2G connection that costs per kilobyte. MQTT runs over TCP/IP and supports TLS when you need encryption.

Here's how it works: A central broker sits in the middle. Devices publish messages to topics like factory/line-1/temperature. Other devices subscribe to those topics. The broker figures out who gets what. Topics use forward slashes to create hierarchies, so you can subscribe to factory/# and catch everything happening in the factory. You can also use wildcards: # matches multiple levels (like factory/# for everything under factory), while + matches exactly one level (like sensors/+/temperature for temperature readings from any single sensor).

MQTT has three Quality of Service levels:

QoS 0 - Fire and forget. Send the message once, hope it arrives. No acknowledgment, no retry. Fast but unreliable.

QoS 1 - At least once delivery. The broker acknowledges receipt and retries if needed. You might get duplicates.

QoS 2 - Exactly once through a four-way handshake. Slowest but guaranteed.

Pick based on what you're sending. Temperature readings every 10 seconds? QoS 0 is fine. Critical alarm messages? QoS 2.

How Kafka Works

LinkedIn built Kafka in 2011 because they were drowning in activity streams and operational metrics. Traditional message queues couldn't keep up. So they designed something that acts more like a distributed database than a message broker.

Kafka organizes everything into topics, and topics split into partitions. Each partition is just an ordered log of messages that never changes once written. Producers append messages to the end. Consumers track where they are in each partition using offsets. Multiple producers and consumers can hammer different partitions simultaneously, which is how Kafka gets ridiculous throughput.

The architecture spreads partitions across multiple broker servers. Each partition gets replicated to other brokers based on your replication factor. If a broker crashes, another one takes over for its partitions immediately. No data loss, no downtime.

Unlike MQTT, messages don't disappear after delivery. Everything writes to disk. You configure retention policies—keep messages for 7 days, 30 days, or forever. This means you can replay messages, let new consumers read historical data, or reprocess everything if your analytics code had a bug.

Early Kafka needed Apache Zookeeper for cluster coordination, which added complexity. Recent versions support KRaft mode that removes this dependency, though many production systems still run Zookeeper.

The Real Differences

Architecture Philosophy

MQTT keeps things simple with a central broker. Devices connect, the broker routes messages, everyone's happy. You can get started with a single Raspberry Pi running Mosquitto. The 2-byte headers and compact binary format mean your sensor data flows efficiently even on constrained networks.

Kafka is distributed by design. Topics partition across brokers. Consumers track offsets themselves. Everything replicates for fault tolerance. You need coordination infrastructure (Zookeeper or KRaft), multiple brokers for production, and someone who knows distributed systems. But this complexity buys you throughput that single-broker systems simply can't match.

Performance Reality

MQTT delivers messages in milliseconds. It runs on microcontrollers with kilobytes of RAM. A sensor reading might be 10-20 bytes including protocol overhead. A decent broker handles thousands to tens of thousands of messages per second, which works fine when you have hundreds of thousands of devices sending data every few seconds.

Kafka sacrifices latency for volume. Messages take tens to hundreds of milliseconds because of disk writes, replication, and consumer polling. But a single broker can handle hundreds of thousands of messages per second. Clusters process billions daily. You need real hardware—multiple cores, 32GB+ memory, fast SSDs—but you get data movement at enterprise scale.

How Messages Get Delivered

MQTT's three QoS levels give you options. QoS 0 is fast but lossy. QoS 1 guarantees delivery but might duplicate. QoS 2 does exactly-once with a four-way handshake. Brokers can queue messages for offline subscribers, but they're not designed for long-term storage.

Kafka writes everything to disk based on your retention policy. Producers pick acknowledgment levels: wait for the leader broker (fast, less safe) or wait for all replicas (slower, fully durable). Consumers commit offsets after processing messages. Modern Kafka supports exactly-once semantics through transactions and idempotent producers. The persistence model enables message replay and handles consumer failures completely differently than MQTT.

Running This Stuff in Production

Setting up an MQTT broker is straightforward. You can start with something like Mosquitto for development, or choose from production-ready brokers that support clustering and high availability. Configure authentication, add redundancy as needed, and monitor connection counts, message rates, and queue depths—most brokers expose metrics via REST APIs or monitoring endpoints.

FlowFuse includes a managed MQTT broker built right into the platform—no separate infrastructure to set up or maintain. It connects directly with your Node-RED flows, so you can publish and subscribe to topics without leaving the environment. Check out the details to see how it works.

Kafka demands more. You need at least three brokers plus coordination services. Monitor partition distribution, replication lag, consumer group status, disk usage. Plan capacity for both storage and network bandwidth. Rolling upgrades require care. Partition reassignment needs coordination. The learning curve is real, but the system handles failures gracefully once you understand it.

Where to Use Each One

MQTT dominates in manufacturing plants with sensor networks, building automation, remote sites on cellular connections, and fleet tracking. It's the right call when devices have limited CPU and memory, networks constrain bandwidth, you're dealing with thousands of messages per second, and you don't need long-term storage.

Kafka powers financial transaction processing, e-commerce backends, infrastructure monitoring at scale, and data engineering pipelines. Use it when message volumes hit hundreds of thousands per second, multiple systems need independent access to the same data stream, you need replay capabilities, or you're feeding data into analytics platforms.

Most real systems use both. MQTT handles the edge, Kafka moves data between central systems. You see this pattern everywhere—MQTT at factory sites, Kafka in the data center.

Making the Choice

Here's how to think about it:

Pick MQTT when:

Your devices are resource-constrained (microcontrollers, embedded systems)
Network bandwidth is limited or expensive
You're handling thousands of messages per second
Simple deployment matters
You need efficient edge device communication
Long-term message storage isn't a requirement

Pick Kafka when:

Message volumes hit hundreds of thousands per second or more
Multiple applications need independent access to message streams
You need message replay or event sourcing capabilities
Stream processing is part of the architecture
Integration with big data tools matters
Your ops team knows distributed systems

Neither is "better." They solve different problems. Your requirements drive the decision.

Integrating MQTT and Kafka

As mentioned, real production systems don’t choose between these—they use both. Devices and sensors typically publish data over MQTT, while analytics platforms, data lakes, and stream processors consume events from Kafka. The real challenge lies in bridging the two reliably and cleanly.

Most teams write custom bridge services or deploy Kafka Connect with MQTT source connectors. Custom bridges give you complete control but require development and maintenance. Kafka Connect reduces code but adds configuration complexity, especially when you need transformation logic beyond simple field mapping.

FlowFuse takes a different approach using Node-RED's visual programming model. MQTT and Kafka nodes connect through flows that define routing and transformation logic. The platform manages protocol connections and flow execution without separate bridge infrastructure.

As mentioned before, FlowFuse includes a managed MQTT broker built directly into the platform. Beyond MQTT and Kafka, it supports industrial protocols like Modbus, OPC UA, and HTTP. Device connections, message processing, and Kafka integration all happen in one environment. You get built-in version control, deployment management, team collaboration, and much more.

FlowFuse offers a free trial for testing MQTT-Kafka workflows. Start building or schedule a consultation to discuss your specific needs.

Conclusion

MQTT and Kafka solve different problems. MQTT gives you efficient device connectivity with minimal overhead. Kafka delivers high-throughput event streaming with persistence and replay.

Understanding these differences helps you pick the right tool for the job. Most production systems use both, leveraging each where it provides the most value. Base your decision on message volumes, device capabilities, operational requirements, and team expertise—not on whatever's trending on Hacker News.

Node-RED Buffer Parser Guide: Decode Modbus and Industrial Device Data

2025-12-10T00:00:00Z

Legacy industrial devices communicate in bytes. Your temperature sensor doesn't send you {"temp": 23.5} - it sends you [1, 3, 4, 1, 44, 0, 200, 190, 125]. Those numbers are meaningless unless you know how to decode them.

This is what makes working with legacy PLCs and Modbus sensors challenging. You're not dealing with modern APIs that return JSON. You're dealing with raw binary data where byte 3 might be temperature and byte 4 might be humidity, and if you read them in the wrong order, everything breaks.

Node-RED's Buffer Parser node solves this problem. Instead of writing JavaScript to manually decode every buffer, you configure it once visually and it handles the conversion automatically. In this article, we'll learn how to use this node effectively.

Understanding Buffer Data

When your Modbus sensor responds to a query, Node-RED shows you something like this in the debug panel:

[1, 3, 4, 1, 44, 0, 200, 190, 125]

Nine bytes. Each one is a number between 0 and 255. This data is completely meaningless without context.

Byte 0 might be a device address. Bytes 3 and 4 together might encode temperature. But the buffer itself doesn't tell you any of this - you need the device manual to figure out what goes where.

Take bytes 3 and 4: 1 and 44. If you're supposed to read them as a 16-bit integer, that's either 300 or 11265 depending on byte order. If the device uses a scale factor of 10, the actual temperature could be 30.0°C or 1126.5°C. Get any part of this wrong and your dashboard shows nonsense.

So why do devices work this way? Why not just send {"temperature": 30.0}?

That JSON message takes 21 bytes. The same information in binary takes 2 bytes. When you're on a serial connection running at 9600 baud, sending thousands of sensor readings per day, those extra bytes add up fast.

More importantly, this is how industrial hardware has worked since 1979. Modbus was designed when PLCs had kilobytes of memory. Modern factories still run equipment from the 90s. The protocol isn't going to change because it would be more convenient for us.

You work with what's on the factory floor, this means you need to parse buffers.

Example: Temperature and Humidity Sensor

Suppose you have a temperature and humidity sensor connected via Modbus RTU. When you query it for data, you get this buffer:

[1, 3, 4, 1, 44, 0, 200, 190, 125]

The device manual says this buffer breaks down as:

Byte 0: Device address (1)
Byte 1: Modbus function code (3 = read holding registers)
Byte 2: Data length in bytes (4)
Bytes 3-4: Temperature reading
Bytes 5-6: Humidity reading
Bytes 7-8: CRC checksum

You need to extract temperature and humidity. Everything else is Modbus protocol overhead.

The manual also specifies:

Temperature: 16-bit unsigned integer, big-endian, divide by 10 for actual value in °C
Humidity: 16-bit unsigned integer, big-endian, divide by 10 for actual value in %RH

Without Buffer Parser, you'd write a function node like this:

const buffer = Buffer.from(msg.payload);
const temperature = buffer.readUInt16BE(3) / 10;
const humidity = buffer.readUInt16BE(5) / 10;

msg.payload = { temperature, humidity };
return msg;

This works, but it's also fragile. When you need to add a pressure reading next month, you're editing code and hoping you don't break the offset calculations. When someone else looks at this flow, they have no idea what's happening without reading the function and if they don't understand JavaScript, they're stuck.

Buffer Parser turns this into configuration you can see and modify without touching code. Let's walk through a practical example.

But before you start, make sure you have a Node-RED instance running on your edge device. The fastest, easiest, and most production-ready way is using FlowFuse. If you don't have an account yet, create one with our free trial. FlowFuse simplifies managing remote instances and provides the ability to create hosted instances—no matter how many you need to manage, it makes it easy. There are no deployment headaches either; everything is managed by FlowFuse with built-in security. You'll also get access to tools such as DevOps pipelines, snapshots for recovery, audit logs, real-time collaboration with granular role-based access control (RBAC), and much more.

Setting Up the Buffer Parser

The Buffer Parser node is part of the node-red-contrib-buffer-parser package. To install it:

Open your Node-RED editor
Click the menu icon (three horizontal lines) in the top-right corner
Select Manage palette
Go to the Install tab
Search for node-red-contrib-buffer-parser
Click Install

Building the Flow

Now let's create a flow to parse the buffer data. For this example, we'll use an Inject node to simulate Modbus data, so while reading you can follow along and learn.

Drag an Inject node from the palette onto the canvas
Double-click the Inject node to open its configuration
Set msg.payload to "Buffer" from the dropdown
In the field, enter: [1, 3, 4, 1, 44, 0, 200, 190, 125]

Node-RED Inject node configuration showing payload set to a Buffer array for simulating data.

Click Done
Drag a Buffer Parser node from the palette onto the canvas
Drag a Debug node onto the canvas
Connect the Inject node output to the Buffer Parser node input
Connect the Buffer Parser node output to the Debug node input

Configuring the Buffer Parser

Now let's configure the Buffer Parser node to extract temperature and humidity.

Double-click the Buffer Parser node to open its configuration panel

You'll see several fields. Most of them you can ignore for basic parsing. Here's what matters:

Property: Leave this set to msg.payload. This tells the node where to find your buffer data.

Specification: Keep this set to UI Specification. This is the visual method, allowing you to configure everything directly within the node.

Result Type: Set this to "Key/value". This gives you clean JSON output like {"temperature": 30.0, "humidity": 20.0}.

Byte Swap: Leave this set to "No swap" for now. Byte swapping reorders bytes within multi-byte values and is only needed when your device stores data in an unusual format that doesn't match standard big-endian or little-endian conventions. If you've selected the correct endianness (like uint16be or uint16le) and values still look wrong, you might need swap16 (for 16-bit values), swap32 (for 32-bit values), or swap64 (for 64-bit values). Most devices won't require this.

Now let's configure the actual data extraction.

Extracting Temperature

Let's add the first field to extract temperature from bytes 3-4.

Click the add button at the bottom of the configuration panel to create a new row in buffer parser node

You'll see several fields appear in the row. Let's fill them in:

In the Name field, enter temperature. This is what you'll see in your output JSON.
In the Type dropdown, select uint16be
- This breaks down as:
  - uint16 = 16-bit unsigned integer (positive values only)
  - be = big-endian (reads bytes in order: first byte is high, second is low)
- The manual specified "16-bit unsigned integer, big-endian" so this is a direct match
In the Offset field, enter 3. Temperature data starts at byte 3. Offset counts from zero, so byte 0 is first, byte 3 is fourth.
In the Length field, enter 1. We're reading one value, not an array of values. Length stays at 1 for single values.
In the Scale field, enter 0.1. Here's the important part: the Buffer Parser multiplies by the scale value, so to divide by 10, you need to multiply by 0.1. Raw value 300 × 0.1 = 30.0.

Note: Beyond simple multiplication, the Buffer Parser also supports scale equations for more complex transformations. You can use operators like >> for bit shifting (e.g., >>4 to shift right 4 bits), + or - for offsets (e.g., +42 to add 42), / or * for division/multiplication, ** for exponents, and comparison operators like ==, !=, >, < for boolean results. These equations are applied after any mask, giving you powerful options for handling bit-packed data or applying formulas without writing JavaScript.

Let's verify this works with a simple calculation. Bytes 3 and 4 in our buffer are 1 and 44. Big-endian means we read them in order: (1 × 256) + 44 = 300 in decimal. Multiplied by 0.1 gives 30.0°C. Perfect.

Extracting Humidity

Now let's add the second field to extract humidity from bytes 5-6.

Click the add button again to create a second row
In the Name field, enter humidity. This will appear as the key in your output JSON.
In the Type dropdown, select uint16be
- Same as temperature:
  - uint16 = 16-bit unsigned integer (no negative values)
  - be = big-endian (reads bytes in order)
In the Offset field, enter 5. Humidity data starts at byte 5.
In the Length field, enter 1. We're reading a single humidity value.
In the Scale field, enter 0.1. Again, multiply by 0.1 to effectively divide by 10.

Buffer Parser configuration rows defining temperature and humidity extraction using uint16be with offsets and scale values.

Click Done to save the configuration

Let's verify this. Bytes 5 and 6 are 0 and 200. Big-endian reads them in order: (0 × 256) + 200 = 200. Multiplied by 0.1 = 20.0% RH. Perfect.

Testing the Configuration

Now let's test if everything works correctly.

Click Deploy in the top-right corner of the Node-RED editor
Click the button on the left side of the Inject node to trigger it
Open the Debug panel on the right side of the editor

Your Buffer Parser output should look like:

{
  "temperature": 30.0,
  "humidity": 20.0
}

This example should work as shown, but with your actual device data, the output may differ. If the values in your JSON don't match what you expect, you're likely running into one of a few common issues. Here's how to recognize and fix them.

If your values are way off—for example, you expect 300 but see 11265, or expect 100 but see 25600—you've got the endianness backwards. Change int16le to int16be (or vice versa) in the Type field. Alternatively, try setting Byte Swap to swap16 (or swap32/swap64 for larger data types).

If you're seeing negative numbers when you know the value should be positive, you're using signed integers when you need unsigned. Change int16 to uint16 (or int32 to uint32) in the Type field.

If your values are exactly 256 times too large or too small, you're using the wrong data type size. If you're using int8 but the device sends 16-bit values, change it to int16be or int16le. If you're using int16 but the device sends 32-bit values, change it to int32be or int32le. Check your device manual for the correct bit size.

If you're getting raw values instead of scaled values (for example, 300 instead of 30.0), it means you either forgot to set the Scale field or set it incorrectly. If the device manual says ‘divide by 10,’ enter 0.1 in the Scale field (not 10). Remember: the Buffer Parser multiplies by the scale, so to divide by 10, you must multiply by 0.1

If every number looks completely wrong, recount your offsets carefully. Check each Offset value and verify against your device manual. Remember that byte 0 is first, byte 1 is second, byte 3 is fourth, and so on. The most common mistake is being off by one byte.

If you're getting only one value when the device sends multiple, check the Length field. If your device sends an array of 5 temperature readings starting at byte 10, set Offset to 10 and Length to 5. The node will return an array of values instead of a single value.

What About Those Other Fields?

The configuration screen has more fields we didn't touch:

Bit Offset only matters when you're using the bool type to extract a single bit from a byte. This field is only visible when the bool type is selected. If you need to check whether bit 3 of byte 7 is set (like a "pump running" status flag), you'd set Offset to 7, Type to bool, and Bit Offset to 3. For reading whole numbers, ignore this field.

Mask is for when multiple values are packed into the same byte. Industrial protocols do this to save space - why waste 8 bits on a simple on/off flag when you can pack eight flags into one byte? If bits 0-3 hold one sensor reading and bits 4-7 hold another, you use masks like 0x0F (binary: 00001111, lower 4 bits) and 0xF0 (binary: 11110000, upper 4 bits) to extract each value separately. You'll know when you need this because the manual will say something like "status bits 0-3 contain pump speed, bits 4-7 contain valve position."

For more details on the Buffer Parser node, you can also explore the official Buffer Parser node documentation — it's comprehensive, well-maintained, and a great reference when working with more advanced parsing options.

When You Need More Complex Parsing

Buffer Parser handles most industrial protocols, but not everything.

If you need conditional parsing where the structure changes based on values in the buffer itself, you'll need JavaScript. For example, if byte 2 tells you how many temperature readings follow and that number varies, Buffer Parser can't handle variable-length structures dynamically.

If you're dealing with bit-packed data where individual bits within bytes have meaning (common in PLC memory maps), you can use the bool type with Bit Offset, but extracting many bits gets tedious. Sometimes a function node doing bitwise operations is cleaner.

If you're using FlowFuse, you don’t even need to write JavaScript yourself. You can simply ask the FlowFuse Expert in plain English, paste what your device manual says, and it will generate the Function node directly on your Node-RED canvas.

For standard Modbus registers, serial sensor protocols, and fixed-structure PLC memory layouts - which covers most industrial data, Buffer Parser does exactly what you need.

Final Thoughts

Binary data from industrial devices isn’t going anywhere. Modbus isn’t disappearing. Neither are PLCs from the 90s or sensors that still speak in raw bytes. This is the reality of factory floors, and it will be for a long time.

The Buffer Parser makes that reality manageable. You don't need to be a buffer expert or master bitwise operations. You just need your device manual, a few minutes to configure the node, and—occasionally—the patience to flip the endianness when a value looks strange. The buffers are still just arrays of bytes, but now you have a tool that turns them into meaningful data without rewriting JavaScript every time you add a new sensor. That's worth something.

And if you’re managing industrial devices at scale—handling remote Node-RED instances, deploying updates across fleets of edge hardware, or keeping everything secure and consistent—FlowFuse can remove much of the daily friction. With features like remote deployment, snapshots, secure device connectivity, and the FlowFuse AI Expert built right into the editor, you can book a free demo. Our team will understand your requirements, show you exactly how FlowFuse fits into your workflow, and guide you on getting the most out of your industrial data pipelines.

Building a Weather Dashboard in Node-RED (2026)

2025-12-05T00:00:00Z

A weather dashboard is honestly the best first project if you're getting into Node-RED. Takes about 10-15 minutes from start to finish, and by the end you'll understand how the whole thing works - connecting to APIs, processing data, and displaying it visually.

This isn't one of our typical deep-dive industrial posts—it's a straightforward starter tutorial. You'll be building something real: calling an actual weather API, handling JSON responses, and watching live data appear on your dashboard. It's the kind of project that makes Node-RED's flow-based approach suddenly make sense. Once you've built it, you'll have a solid foundation for more complex projects.

We'll use FlowFuse Dashboard for the UI since it's modern and easier to work with. If you know how to drag nodes around and hit the deploy button, you're ready to start.

What You'll Need

Before you start, make sure you have:

Node-RED Instance: You need Node-RED running somewhere. Easiest option is FlowFuse, grab a free trial and you get a cloud-hosted instance ready to go. No server setup, no port forwarding hassles.
OpenWeatherMap Account: Sign up at openweathermap.org. The free tier gives you enough API calls for this project.

Installing FlowFuse Dashboard

First, get the dashboard package installed:

Click the hamburger menu in the top right corner
Select Manage palette
Go to the Install tab
Type @flowfuse/node-red-dashboard in the search box
Click the install button next to it

Wait for it to finish. You'll see a bunch of new dashboard nodes pop up in your left sidebar, things like ui-gauge, ui-text, ui-chart. That's how you know it worked.

Getting Your API Key

Go to your account section
Find API keys
Copy the default key (or generate a new one)
Save it in a text file or a note app.

Setting Up the API Connection

First, we need to connect to the weather API and make sure it's working.

Drag an inject node onto the canvas
Double-click to configure it
Change Repeat from "none" to "interval"
Set it to repeat every 5 seconds (or whatever interval you prefer)
Check the box for Inject once after and set it to 0.1 seconds, this will trigger the flow immediately when you deploy
Click Done

Inject node configured to trigger the weather API every 5 seconds

Drag an http request node to the right of it
Drag a debug node to the right of the http request node
Double-click the http request node to open its settings:
Make sure Method is set to GET
In the URL field, paste: https://api.openweathermap.org/data/2.5/weather?q=London&appid=YOUR_API_KEY&units=metric
Replace YOUR_API_KEY with the actual API key you copied from OpenWeatherMap
Replace London with your city if you want
Select the Return as parsed JSON.

HTTP request node configured to fetch weather data from OpenWeatherMap API

Click Done

The units=metric gives you Celsius. Change it to units=imperial for Fahrenheit. For more details on what parameters you can use, check out the OpenWeatherMap API documentation.

Now wire the nodes together by clicking and dragging from the inject node's right side to the http request node's left side, then from the http request node to the debug node.

Click the Deploy button in the top right and open the debug panel on the right sidebar if it's not already open.

You should see a JSON object with weather data, temperature, humidity, wind speed, description, and more. This is the raw data coming back from the API.

If you see a 401 error, your API key may still be activating. Wait 10–15 minutes and try again, or verify the key again in case it’s invalid or mistyped.

Processing the Weather Data

Now that you're getting data from the API, you need to extract the specific values you want to display. We'll use a function node to pull out temperature, humidity, weather description, and wind speed.

Drag a function node and add following code into it and connect it to the http request node:

// Extract the data we need
const temp = msg.payload.main.temp;
const humidity = msg.payload.main.humidity;
const description = msg.payload.weather[0].description;
const windSpeed = msg.payload.wind.speed;
const city = msg.payload.name;

// Create separate messages for each value
return [
    { payload: city, topic: "city" },
    { payload: description, topic: "description" },
    { payload: temp, topic: "temperature" },
    { payload: humidity, topic: "humidity" },
    { payload: windSpeed, topic: "wind" },
];

Tip: If you're using FlowFuse, you don't need to write this JavaScript manually. You can use the FlowFuse Expert to generate the function code for you—just describe what you want the function node to do. Check out the article for more details.

Set the function node's Outputs (in the Setup tab) to 5, since the function will return five separate messages.

Function node configured with 5 outputs to split weather data

Click Done

This function node splits the API response into separate outputs - one for temperature, one for humidity, and so on. Each output gets its own topic label so you can track what's what.

Building the Dashboard

Now you'll see your weather data displayed on screen. This demonstrates how Node-RED connects data sources to visual components. We'll organize the dashboard into separate groups for better visual organization.

Configuring the City Name Display

Start by displaying which city you're tracking:

Drag a ui-text node onto the canvas
Connect it to output 1 of your function node (the city output)
Double-click the ui-text node to open its settings
Set Label to "City"
For Group, click the pencil icon to create a new group called "Weather Info"
Click Add, then Done

UI text node configured to display city name in Weather Info group

You've just created your first dashboard element and dashboard group. Groups organize widgets on the page and function as containers.

Configuring the Weather Description

Add a text field to show current conditions:

Drag another ui-text node onto the canvas
Connect it to output 2 of your function node (description output)
Double-click to configure
Set Label to "Conditions"
Use the same "Weather Info" group
Click Done

UI text node configured to display weather conditions

The API returns descriptions like "scattered clouds" or "light rain" - human-readable conditions.

Configuring the Temperature Gauge

Next, add a circular gauge for temperature:

Drag a ui-gauge node onto the canvas
Connect it to output 3 of your function node (the temperature output)
Double-click to open settings
Set Label to "Temperature (°C)"
Set Min to 0 and Max to 50 (adjust these based on your climate)
Add the color segments you want, as shown in the reference image.
For Group, click the pencil icon to create a new group called "Temperature & Humidity"
Click Add to create the group
Under the Appearance tab, you can select a color scheme if desired
Click Done

Temperature gauge configured with color-coded segments in Temperature & Humidity group

The gauge will automatically color-code based on the value - cooler temperatures display in blue tones, warmer in orange/red.

Configuring the Humidity Gauge

Add the humidity gauge to the same group:

Drag another ui-gauge node onto the canvas
Connect it to output 4 of your function node (humidity output)
Double-click to configure
Set Label to "Humidity (%)"
Set Min to 0 and Max to 100 (humidity is always a percentage)
Add the color segments you want, as shown in the reference image.
Use the same "Temperature & Humidity" group from the dropdown
Click Done

Humidity gauge configured to display percentage values with color coding

The two gauges will display side by side in the same group, making it easy to compare both metrics at once.

Configuring the Wind Speed Display

Next, create a dedicated chart to display wind speed trends over time:

Drag a ui-chart node onto your flow.
Connect it to output 5 of your function node (the wind speed output).
Double-click the ui-chart node to configure it.
Set Label to "Wind Speed (m/s)".
Set Type to Line chart.
For the X-axis, select Timestamp.
Set Y-axis to use msg.payload.
Set Series to msg.topic.
Under Group, click the pencil icon and create a new group named "Wind Speed".
Click Add, then Done to save the configuration.

Wind speed chart configured as a line chart to show trends over time

Viewing Your Dashboard

Hit the Deploy button in the top right corner.

Then, open the Dashboard 2.0 sidebar and click the Open Dashboard button. You should now see a dashboard similar to the one shown below.

Complete weather dashboard displaying real-time weather data

Below is the complete flow. Import it, enter your API URL with your API key in the http request node, and deploy the flow:

What's Next?

That's it! You've built a real-time weather dashboard and learned the basics of Node-RED—connecting to APIs, processing data, and building visual interfaces.

Throughout this tutorial, you used FlowFuse to host Node-RED and FlowFuse Dashboard for the UI. If you're just starting out, FlowFuse makes things easier—no server setup, no port forwarding, and your dashboard works anywhere. Plus, when you're ready to build bigger projects, features like team collaboration, DevOps pipelines, RBAC, snapshots, and audit logs are already built in.

Try expanding your dashboard by adding more cities, creating historical charts, or setting up weather alerts. The pattern stays the same—you're just swapping data sources and visualizations.

Start your free FlowFuse trial and keep building.

How to Access Optimized Data Blocks in TIA Portal (S7-1200/1500)

2025-12-04T00:00:00Z

When working with Siemens S7-1200 and S7-1500 PLCs, you’ll notice that TIA Portal creates optimized data blocks by default. Unlike the classic S7-300/400 controllers, optimized blocks do not use fixed memory offsets. Instead, the PLC compiler reorganizes the data internally for better performance and memory efficiency. This architectural change often creates confusion when trying to read PLC data from external systems.

FlowFuse simplifies this challenge by providing a modern way to connect OT and IT systems and build industrial applications using a low-code, drag-and-drop approach. However, reading optimized data blocks still requires a different access method than traditional S7 communication.

You can disable optimization in TIA Portal by unchecking the "Optimized block access" option in your data block properties. This gives you the old-style addressing where you can read data using fixed offsets like DB1.DBW0. However, this approach has several drawbacks. Optimized blocks run faster, use less memory, and follow Siemens' current best practices. If you're working on existing projects with thousands of tags, converting everything to standard blocks isn't practical. Many companies also require optimized blocks as part of their coding standards.

This guide shows you how to read optimized data blocks directly without disabling optimization. You'll learn to use symbolic addressing, which is the proper way to access data from modern Siemens PLCs.

Why Reading Optimized Data Blocks Is Challenging

The S7 Protocol Problem

Traditional S7 communication, which most Node-RED S7 nodes use, relies on absolute memory addresses. You read data by specifying exact locations like DB1,INT0 (read integer at byte 0) or DB5,REAL10 (read real at byte 10).

This worked fine with classic S7-300/400 controllers where memory layout was predictable. If you declared an integer first in your data block, it always started at byte 0. Simple and reliable.

What Optimization Breaks

Optimized data blocks rearrange variables for better performance and memory efficiency. The compiler groups variables by type, adds alignment padding, and reorders declarations. Your variable positions become unpredictable and can change with each recompile.

Example: You create variables Temperature (Real), Status (Bool), Pressure (Real), Alarm (Bool). Instead of sequential storage, the optimizer might group the two Real values together and pack Bools elsewhere. The Status boolean isn't at byte 4 anymore—it could be anywhere.

Why S7 Nodes Fail

Node-RED packages like node-red-contrib-s7 need exact memory addresses. With optimized blocks:

TIA Portal doesn't show you the actual memory layout
Offsets can't be reliably determined
Recompiling your PLC program silently breaks all your addresses
The S7 protocol has no way to read variables by name

You're stuck guessing at memory locations that keep changing.

The Solution: OPC UA

OPC UA reads variables by name, not memory address. Instead of asking "what's at byte 10?" it asks "what's the value of Temperature_Sensor_01?"

Siemens S7-1200 and S7-1500 PLCs have built-in OPC UA server. Activate it in TIA Portal, mark which variables to expose, and the PLC handles all memory mapping internally. FlowFuse connects and reads data by variable name, regardless of how the PLC organizes memory.

When you modify your data block or recompile, your flows keep working because they reference variable names, not memory locations that might shift.

Prerequisites

Before you begin, make sure you have:

TIA Portal V13 or later, and you know how to download a program to your PLC
A Siemens S7-1200 or S7-1500 PLC with OPC UA server support
A FlowFuse Agent running on your edge device
The PLC and edge device connected to the same network

Step 1: Activate OPC UA Server on Your PLC

First, you need to activate the OPC UA server that's built into your S7-1200/1500 PLC.

Launch TIA Portal and open your project
In the project tree on the left, select your PLC and double-click it
Find OPC UA in the device properties (usually under General or Properties section)
Check Activate OPC UA Server

Activate OPC UA server option in TIA Portal

Set Port to 4840 (the standard OPC UA port)
Set Security Policy to None (for testing only)
Enable Guest authentication.

Note that we've disabled security entirely in steps 6-7 to get you up and running quickly. This is fine for learning and testing, but don't leave it this way. Before moving to production, configure proper authentication with certificates and user credentials. Get the communication working first, then secure it.

Step 2: Add OPC UA Server Interface

Before exposing variables, you need to create an OPC UA server interface in your PLC configuration.

For S7-1500 PLCs (firmware V2.5 or higher):

If you're using an S7-1500 PLC with firmware version 2.5 or higher, you have the option to enable the standard SIMATIC server interface. Simply check Enable standard SIMATIC server interface in the OPC UA settings. This automatically makes all PLC tags that are marked as accessible available through OPC UA.

For S7-1200 PLCs (or manual configuration for S7-1500):

For S7-1200 PLCs, you must manually create a server interface and add the tags you want to expose:

In TIA Portal, navigate to OPC UA communication in the project tree
Right-click on Server interfaces
Select Add new server interface

Adding OPC UA server interface in TIA Portal

Leave the default settings and click OK
The server interface will be created (you can rename it if needed)

Now this interface needs to know which data blocks to expose.

Step 3: Expose Your Data Block Variables

For OPC UA to access your data blocks, you need to mark them as accessible.

First, enable OPC UA access on your data blocks (required for all methods):

Open your data block in TIA Portal
Right-click on the data block name in the project tree
Select Properties
Go to the Attributes tab
Check Accessible from HMI/OPC UA and Optimized Block Access
Click OK

Attribute settings for optimized and OPC UA accessible data blocks

If using S7-1500 with standard SIMATIC server interface:

You're done. All variables in data blocks marked as accessible are now automatically available through OPC UA.

If using manual server interface (S7-1200 or S7-1500):

You need one more step to add specific variables to your server interface:

In the project tree, expand OPC UA communication
Expand your server interface
Drag and drop variables from the OPC UA elements panel (on the right) into your server interface table
Alternatively, right-click Variables and select Add new variable, then browse to select them

Tags added inside OPC UA server interface

Compile and download:

Click Compile in TIA Portal
Download the program to your PLC

Your OPC UA server is now running with the exposed variables ready for access.

Step 4: Install OPC UA Client in FlowFuse

Now switch to your FlowFuse instance to set up the connection to your PLC.

Open your FlowFuse editor
Click the menu icon (three horizontal lines, top right)
Select Manage palette
Go to the Install tab
In the search box, type node-red-contrib-opcua
Find the package in the results and click Install
Confirm the installation when prompted
Close the palette manager

The OPC UA nodes will now appear in your node palette on the left side under the "opcua" category.

Step 5: Configure OPC UA Connection

Create a new flow to connect to your PLC and read data.

Drag an OpcUa-Client node onto your canvas
Double-click it to open the configuration
Click the pencil icon next to Endpoint to add a new connection
Enter the endpoint URL: opc.tcp://[YOUR_PLC_IP]:4840
- Replace [YOUR_PLC_IP] with your actual PLC IP address (e.g., opc.tcp://192.168.1.10:4840)
Set Security Policy to None
Set Security Mode to None
Under Authentication, select Anonymous
Click Add to save the endpoint
Click Done to close the node configuration

Your OPC UA client is now configured to connect to your PLC.

Step 6: Browse Available Variables

Now it's time to discover what's actually available on your PLC. Think of this like opening a file explorer to see what's inside.

Drag an Inject node onto your canvas
Drag an OpcUa-Browser node onto the canvas
Drag a Debug node onto the canvas
Connect the Inject node to the OpcUa-Browser node, then connect the OpcUa-Browser node to the Debug node
Double-click the OpcUa-Browser node to open its configuration
In the Endpoint dropdown, select the connection you created in Step 5
Leave the Action field set to browse
Click Done
Click Deploy in the top-right corner
Click the inject node button
Open the Debug panel on the right side
You'll see a structured tree showing everything your PLC is sharing

Step 7: Read Your First Variable

Let's prove this actually works by reading real data from your PLC.

Drag an Inject node onto your canvas
Double-click the Inject node to configure it
Change Repeat from "none" to interval
Set it to repeat every 5 seconds
In the Topic field, enter the NodeId you copied (e.g., ns=3;s="Demo_Datablock"."Temperature")
Click Done
Drag an OpcUa-Client node onto the canvas
Double-click the OpcUa-Client node to open its configuration
Select your endpoint from the Endpoint dropdown
Change Action to read
Click Done
Drag a Debug node onto the canvas
Double-click the Debug node
Change the output to complete msg object
Click Done
Connect the Inject node to the OpcUa-Client node, then connect the OpcUa-Client node to the Debug node
Click Deploy
Open the Debug panel on the right side
You'll see messages appearing every 5 seconds with your variable's value in msg.payload

Try changing the value in your PLC through TIA Portal and watch the updates appear in FlowFuse. No memory addresses, no offset calculations, just the variable name.

To explore more OPC UA capabilities like subscribing to value changes, writing data back to your PLC, and working with complex data types, check out our article.

Scale Your Industrial Applications with FlowFuse

You've successfully read data from your Siemens PLC, but FlowFuse does much more than connect to a single device. The platform helps you build complete industrial applications that connect to any equipment, collect and transform data from across your factory floor, visualize it in real-time dashboards, and take automated actions based on what's happening in your operation.

FlowFuse makes deployment and management simple, even at scale. Develop your application once, then deploy it to thousands of edge devices across multiple facilities. Manage all your instances from one central platform—push updates, monitor performance, and troubleshoot remotely without visiting each site. Built-in security features protect your industrial data, while horizontal and vertical scaling ensures your applications grow with your business needs.

Whether you're building a predictive maintenance system, a production monitoring dashboard, or a complete MES solution, FlowFuse provides the unified platform to connect, collect, transform, visualize, and act on your industrial data.

Ready to scale beyond a single PLC? Book a demo to see how FlowFuse can transform your industrial operations.

How to Optimize Industrial Data Communication with Protocol Buffers

2025-11-28T00:00:00Z

You're generating terabytes of sensor data every day. Most of it is waste, I mean..

Not the measurements—those are fine. It's the packaging. Text formats wrap every reading in field names, quotes, and brackets. You're moving more formatting characters than actual data across your network.

Protocol Buffers eliminates this. It's binary serialization that transmits only what matters—no overhead, no bloat. This article shows you how to implement it and what happens when you stop paying to transmit garbage.

Don't worry about complexity—in FlowFuse this is three nodes and one text file. No thousand lines of code. You'll define your data structure in 5-10 lines, drag some nodes into your flow, point them at that file, and you're done. FlowFuse handles the rest.

What You're Actually Transmitting

Your network doesn't have a data problem. It has a packaging problem.

Right now, somewhere in your facility, a sensor just reported 74°C. Simple reading. Four pieces of information. But here's what actually transmitted:

{
  "sensor_id": "T-220",
  "temperature": 74,
  "unit": "C",
  "timestamp": 1700580000,
  "status": "OK"
}

See those field names? sensor_id, temperature, unit, timestamp, status. You wrote them once when you defined your data model. Now you're transmitting them thousands of times per second. Every single message carries a complete description of itself.

It's like receiving a package where the shipping label is bigger than what's inside.

Here's what this costs you:

One sensor sending 109 bytes every 5 seconds is nothing. One thousand sensors doing the same thing creates 21.8 KB/second of continuous traffic. That's 1.88 GB per day. Except only about 650 MB are actual measurement—the rest is field names, quotes, and brackets you're paying to transmit, store, and process.

Your edge device receives this message and fires up a JSON parser. It reads character by character, validates every quote matches, converts "74" from a string into a number, and builds a data structure. This happens millions of times per day in a mid-sized facility. The CPU isn't processing sensor data—it's processing text formatting.

Your control loop needs that temperature reading in 50 milliseconds. But the network is congested because it's moving 3-4x more data than necessary. The parser is slow because it's converting strings. And suddenly your 50ms requirement becomes 200ms, and nobody can figure out why because "we have plenty of bandwidth."

Meanwhile, your cloud provider charges by the gigabyte. Every month, you pay to ingest 1.88 GB from this sensor array. About 1.2 GB of that is field names and formatting. You're literally paying to store the word "temperature" millions of times.

The compression trap:

The obvious fix is GZIP. Compress everything, cut it in half, problem solved. Except now you're compressing garbage, then paying CPU cycles to decompress it, then parsing the same bloated JSON on the other end. You've added latency and processing overhead to save bandwidth on data you shouldn't be sending in the first place.

What if you just didn't send it?

Protocol Buffers doesn't compress your JSON. It replaces it. No field names in every message—they're defined once in a schema. No quotes or brackets—it's binary. No string-to-number conversions—numbers are already numbers.

That 109-byte JSON message becomes 47 bytes with Protocol Buffers. Not compressed. Just stripped of everything that isn't data—a 60% reduction in size.

The same sensor array that generated 1.88 GB per day now generates 750 MB. Your edge devices process messages in microseconds instead of milliseconds. Your control loops hit their timing requirements. And your cloud bill drops by 60%.

This isn't theoretical. It's measurable, repeatable, and you can implement it in an afternoon.

Understanding Protocol Buffers

Before we dive into implementation, let's understand what makes Protocol Buffers different.

Protocol Buffers (protobuf) is a serialization format developed by Google. Unlike JSON, which describes data with every message, protobuf separates the schema from the data. You define your message structure once in a .proto file:

syntax = "proto3";

// Temperature sensor reading
message TemperatureSensorReading {
  string sensor_id = 1;
  float temperature = 2;
  string unit = 3;
  int64 timestamp = 4;
  string status = 5;
}

Those numbers (1, 2, 3, 4, 5) are field identifiers. When you encode a message, protobuf transmits only the field number and the value. No field names, no formatting characters, no whitespace.

The binary difference:

JSON: {"sensor_id":"T-220","temperature":74,...} (109 bytes)
Protobuf: [21,0,0,74,66,26,7,99,101,108,11... (47 bytes)

The receiver uses the same .proto file to decode field 1 as sensor_id, field 2 as temperature, and so on. The schema exists once on each side—never in the message itself.

Now let's implement this in FlowFuse.

Implementing Protocol Buffers in FlowFuse

We'll build a complete protobuf pipeline: define your data schema, encode sensor readings, transmit them, and decode on the receiving end.

Before you start, Make sure you have a FlowFuse instance running on your edge device. If you don't have an account yet, create one with our free trial. FlowFuse simplifies connecting devices and systems—transform, validate, contextualize, and visualize data while building industrial applications, all in a low-code environment. It includes enterprise features that accelerate management, development, deployment, and scaling with built-in security.

Preparing Your Protocol Buffers Schema

Let's start by defining your data structure. This will be the foundation of your binary serialization. If you're using FlowFuse Device Agent to run your Node-RED instance, it's recommended to create this file inside the /opt/flowfuse-device/ directory for proper access and management.

Create a file named temperature-sensor.proto ( or you can give it any name you want ). Make sure it ends with the .proto extension:

syntax = "proto3";

message TemperatureSensorReading {
  string sensor_id = 1;
  float temperature = 2;
  string unit = 3;
  int64 timestamp = 4;
  string status = 5;
}

You can define as many message types as you need for different data in the file. Each message type gets its own structure optimized for the specific data it carries.

Installing the Protocol Buffers Node

To work with Protocol Buffers in FlowFuse, you'll need the protobuf node:

In your FlowFuse instance, open the palette manager (Menu → Manage palette)
Search for node-red-contrib-protobuf
Install the node

Once installed you will see the nodes in the left palette under the protobuf category.

Encoding Data with Protocol Buffers

Drag your data source node (Modbus Read, OPC UA Client, S7, etc.) into the flow. Ensure it's configured correctly and that data is coming through — you can verify this using a Debug node.
Transform the data as needed and add any required metadata.
Add the Encode node to the flow. Open its configuration and click the + icon next to Protofile to add the full path to your .proto file.
- Enable Watch file if you want the node to automatically reload when the .proto changes
- Enable Keep snake_case (underscores) if your field names require it

Protocol Buffers node configuration

Specify the Message Type as defined in your .proto file. For example, using the schema shown earlier, the type would be:

TemperatureSensorReading

This tells the Encode node which message structure to apply during serialization.

If you need to set the type dynamically, you can also do:

msg.protobufType = "TemperatureSensorReading";

Finally, connect the Encode node to the communication node (or to the node that is transforming data and adding metadata) that will send your data onward, for example, MQTT Out, HTTP Request, or any other transport you're using.
Deploy the flow.

Once data passes through the Encode node, it will automatically encode it into Protocol Buffers. When everything is working correctly, you'll see the node status update to "processed" with a green indicator.

Decoding Protocol Buffers Data

Now that you're encoding and transmitting binary data, you need to decode it on the receiving end. This is where the matching .proto schema comes into play.

On your receiving FlowFuse instance (or wherever you're processing the data):

Copy the same .proto file to your receiving system. The schema must match exactly—same field numbers, same types, same message structure. This is critical for successful decoding.
Add the Decode node to your flow where you receive the protobuf data (after MQTT In, HTTP In, etc.)
Configure the Decode node by Clicking the + icon next to Protofile and enter the full path to your .proto file. Set the Message Type to match what was encoded (e.g., TemperatureSensorReading). Enable Watch file if you want automatic reloading on schema changes.
Connect Protocol buffer data source to Decode node.
Deploy the flow.

The Decode node will parse the binary message and output a standard JavaScript object that you can work with in function nodes, store in databases, or display in dashboards.

What You Actually Get

Let's talk about what changes when you actually implement this.

Your network traffic drops by half or more. That struggling edge gateway suddenly has headroom. You can add more data sources or increase message frequency without upgrading anything.

Your edge devices aren't parsing text anymore. Messages that took milliseconds now decode in microseconds. Those freed CPU cycles go back to your actual application logic. Your processing loops hit their timing requirements again.

Your time-series database just got considerably smaller. The storage you already paid for goes further. That retention policy you've been managing? You just extended it without buying anything.

Your cloud provider charges per gigabyte. You were paying to transmit and store field names with every reading. Whatever your current cloud bill is, expect it to drop by 40-60%. Your provider doesn't care why—they just bill you for what moved through their infrastructure.

Before Protocol Buffers, scaling meant budgeting for more capacity. After implementation, the same infrastructure handles more without additional spend. That next tier pricing? You just pushed it out by years.

You're not rebuilding anything. Define a .proto schema, drop in encode/decode nodes, deploy. No consultants, no multi-phase rollout, no capital purchases.

This isn't optimization theater. It's removing waste that never should have been there. And once implemented, every new data source, every increased message rate, every additional field benefits from the same reduction. You're not just cutting your bill once—you're changing the cost structure of every future expansion.

Cut the Waste Now

Your messages are 60% packaging. Protocol Buffers strips it out.

One schema file. Three nodes in FlowFuse. Deploy. Done.

The same platform you use to connect devices, systems and build dashboards now optimizes every byte you transmit. No new tools. No complexity. Just smaller messages and lower bills.

Pick one data flow. Implement it this afternoon. Scale it tomorrow.

Start your free FlowFuse trial and stop paying to transmit field names.

How to Protect Your Factory From Bad Data: A Must-Have Read for IIoT

2025-11-27T00:00:00Z

Bad data quietly corrupts production analytics, triggers false equipment alarms, and causes automation systems to make faulty control decisions. Unlike system crashes, these issues go unnoticed until they've already propagated through your operations—affecting multiple processes and causing unexpected shutdowns or production anomalies.

This article shows you how to build a data validation gateway using FlowFuse that stops bad data before it reaches your critical systems. You'll implement validation checkpoints, establish quality rules, and configure alerts, creating a protective barrier that ensures only reliable data flows into your production environment.

Below is a short video demonstration of the data validation gateway we'll be building together.

The Problem with Trusting Your Data

Most industrial applications assume incoming data is valid—temperature sensors send numbers between 0-100°C, MQTT messages contain properly formatted JSON, PLC status codes follow documented formats. There's usually no validation checking if these assumptions hold true.

This works until it doesn't. Sensors drift out of calibration. Network issues corrupt packets. Firmware updates change data formats without warning. When these things happen, bad data flows straight through unchecked.

Consider a temperature sensor sending {"temperature": 72.5, "unit": "Celsius"}. Then electromagnetic interference corrupts transmission, and your system receives {"temperature": "ERR", "unit": "Celsius"}. Your code tries to do math with "ERR"—it fails silently, throws an exception, or worse, coerces "ERR" to NaN or 0. Now you're making decisions based on garbage data without realizing it.

Scale makes this worse. With hundreds of sensors, multiple PLCs, edge gateways, and third-party integrations sending data continuously, quality issues aren't occasional—they're constant. You spend more time troubleshooting data problems than actual equipment problems. Reports contain incorrect numbers. Predictive models make bad predictions from corrupted training data.

The solution isn't hoping for perfect data—it's validating it explicitly. That's what we're building in this guide.

Understanding Data Quality

Before we start building, we need to answer a simple but critical question:

What makes data "good"?

This isn't about what data you collect or which machine it comes from. It's about whether the data is reliable enough to drive decisions without causing chaos.

Good data enables confident automation and informed decision-making.

Bad data misleads—and when your automation acts on misleading information, your team and operations pay the price.

To build effective validation, you need to check multiple dimensions of data quality. Some key aspects include:

Type Correctness: Is the temperature a number or the string "ERR"?
Completeness: Are all required fields present?
Range Validation: Is the temperature between 0-100°C or an impossible 500°C?
Format Consistency: Is the timestamp in ISO 8601 format or some custom format?

These aren't rigid categories—they're lenses through which you examine your data. Real validation often combines several of these checks together.

Building Your Data Quality Checker

Now that we understand what "good data" looks like, let's build guardrails to enforce it.

Before we start, make sure you have a running FlowFuse instance that is collecting data. If you don't have a real data source, don't worry—we'll provide a simulated setup as well. Just make sure you have a FlowFuse account and instance running. If you don't have an account, create one now with our free trial.

Installing the JSON Schema Validator Node

For our validation system, we'll use JSON Schema, a powerful, industry-standard way to define what valid data should look like. Think of it as a contract that your data must fulfill before entering your system.

JSON Schema lets you specify exactly what fields should exist, what types they should be, what ranges are acceptable, and what formats are required. Instead of writing dozens of if-statements to check each condition, you define the rules once in a schema, and the validator does the heavy lifting.

To get started, install the node-red-contrib-full-msg-json-schema-validation node in your FlowFuse instance:

Open your FlowFuse instance
Click the hamburger menu (three horizontal lines) in the top right
Select Manage palette
Go to the Install tab
Search for node-red-contrib-full-msg-json-schema-validation
Click Install next to the node

Once installed, you'll find the "json full schema validator" node in your palette under the function category.

Creating Your First Validation Schema

Let's start with a practical example—validating temperature sensor data. Here's what we expect our sensor to send:

{
    "temperature": 72.5,
    "unit": "Celsius",
    "sensor_id": "TEMP_LINE_01",
    "timestamp": "2025-11-21T10:30:00Z"
}

Now let's create a JSON Schema that validates this structure:

{
    "type": "object",
        "required": ["temperature", "unit", "sensor_id", "timestamp"],
            "properties": {
        "temperature": {
            "type": "number",
                "minimum": 0,
                    "maximum": 100,
                        "description": "Temperature reading in Celsius"
        },
        "unit": {
            "type": "string",
                "enum": ["Celsius"],
                    "description": "Temperature unit (Celsius only)"
        },
        "sensor_id": {
            "type": "string",
                "pattern": "^TEMP_LINE_[0-9]+$",
                    "description": "Sensor identifier following the required naming convention"
        },
        "timestamp": {
            "type": "string",
                "format": "date-time",
                    "description": "ISO 8601 formatted timestamp"
        }
    },
    "additionalProperties": false
}

Let's break down what this schema validates:

Type Safety: temperature must be a number (catches "ERR", null, undefined)
Required Fields: all 4 must exist (catches incomplete messages)
Range Limits: temperature must be between 0–100°C.
Value Constraints: unit must match the enum "Celsius" (enforces consistent units)
Format Rules: ISO 8601 timestamps and TEMP_LINE_* naming (catches config/naming errors)

The additionalProperties: false line is particularly important—it rejects any data with unexpected fields, preventing schema drift over time.

Building the Validation Flow

Now let's build the flow:

Drag in your data input node such as MQTT In node, HTTP In node, or Inject node (for testing)
Drag the JSON Full Schema Validator node into your flow
Double-click the validator node and paste your JSON schema into the schema field.

JSON Schema Validator node configured with schema rules

The validator node has two outputs:
- Output 1: Valid data that passes all schema checks
- Output 2: Invalid data that fails validation

When validation fails, the node adds a msg.error property as an array, where each item provides detailed information about what went wrong (missing fields, incorrect types, out-of-range values, etc.)

Connect Output 1 to your normal processing pipeline (database writes, dashboards, automation logic)
Connect Output 2 to an error handler that logs the error details.

Testing Your Validator

Time to test your validator. We'll use the temperature sensor schema from the example above, but you can follow these same steps with any schema you create. Just make sure your test payload matches what your schema expects—same field names, correct data types, and proper structure. Then you can tweak the values to trigger validation failures and see how your error handling responds.

Add an Inject node with this valid payload, and connect it to your JSON Schema Validator node:

{
    "temperature": 72.5,
    "unit": "Celsius",
    "sensor_id": "TEMP_LINE_01",
    "timestamp": "2025-11-21T10:30:00Z"
}

This passes all checks against the temperature sensor schema example and routes to your valid data handler.

Now test with bad data:

{
    "temperature": "ERR",
    "unit": "Celsius",
    "sensor_id": "TEMP_LINE_01",
    "timestamp": "2025-11-21T10:30:00Z"
}

This fails because temperature is a string instead of a number (as defined in our example schema), routing to your error handler. The msg.error output shows exactly what's wrong:

[{
  "keyword": "type",
  "dataPath": ".temperature",
  "schemaPath": "#/properties/temperature/type",
  "params": {
    "type": "number"
  },
  "message": "should be number"
}]

These detailed error messages eliminate guesswork. You see the field, the problem, and where validation failed.

Test additional scenarios to see how the validator catches different issues:

Missing required field:

{
  "temperature": 72.5,
  "unit": "Celsius",
  "timestamp": "2025-11-21T10:30:00Z"
}

Out of range value:

{
  "temperature": 150,
  "unit": "Celsius",
  "sensor_id": "TEMP_LINE_01",
  "timestamp": "2025-11-21T10:30:00Z"
}

Invalid enum value:

{
  "temperature": 72.5,
  "unit": "F",
  "sensor_id": "TEMP_LINE_01",
  "timestamp": "2025-11-21T10:30:00Z"
}

Each failure produces specific error messages that pinpoint the exact issue.

Setting Up Error Alerts

Now that your validator is catching bad data on Output 2, let's set up Telegram notifications so you get instant mobile alerts whenever validation fails.

Installing the Telegram Node

First, install the Telegram node from the palette:

Click the hamburger menu (three horizontal lines) in the top right.
Select Manage palette.
Go to the Install tab.
Search for node-red-contrib-telegrambot.
Click Install next to the node.
Wait for installation to complete.

Once installed, you'll find the "telegram sender" and "telegram receiver" nodes in your palette.

Creating Your Telegram Bot and Getting Your Chat ID

Before you can send alerts, you need to create a Telegram bot and get your Chat ID. We have a detailed guide that walks you through the entire process: How to Create a Telegram Bot and Find Your Chat ID

Once you have your bot token and Chat ID, come back here to continue with the alert setup.

Create the Alert Message

Now we'll format the error information into a clear Telegram message.

Find your validator node (the JSON Schema Validator).
Look at its second output (the bottom one). This is where bad data with errors comes out.
Drag a function node onto the canvas.
Connect it to the validator's second output.
Double-click the function node to open it.
Change the Name at the top to: Format Alert and add the following JavaScript:

// Get error information
const errors = msg.error || [];
const badData = msg.payload || {};

// Build error list
let errorText = "";
errors.forEach((err, index) => {
    errorText += `${index + 1}. Field: ${err.dataPath || 'unknown'}\n`;
    errorText += `   Problem: ${err.message}\n\n`;
});

// Get current time
const time = new Date().toLocaleString();

// Build the alert message
msg.payload = {
  chatId: "PUT_YOUR_CHAT_ID_HERE",
  type: "message",
  content: `🚨 DATA VALIDATION FAILED

Time: ${time}
Sensor: ${badData.sensor_id || 'Unknown'}

ERRORS FOUND:
${errorText}

BAD DATA:
${JSON.stringify(badData, null, 2)}`
};

return msg;

Find the line chatId: "PUT_YOUR_CHAT_ID_HERE".
Replace PUT_YOUR_CHAT_ID_HERE with your actual Chat ID.
Click Done.
Drag telegram sender node onto the canvas.
Connect your Format Alert function node to the telegram sender node.
Double-click the telegram sender node.
Click the + icon next to Bot to add your bot configuration.
Paste your Bot Token that you got from BotFather.
Give it a name like "Quality Check Bot".
Click Add, then Done.
Click Deploy.

Now test your setup by triggering a validation failure. You should receive an instant Telegram message showing exactly what went wrong.

Below is the complete flow that demonstrates the entire validation pipeline—from receiving sensor data to catching errors and sending Telegram alerts.

Wrapping Up

You now have a working validator that stops corrupted data before it reaches your dashboards and automation logic. Bad sensor readings, malformed payloads, missing fields—your system catches them all and sends you detailed Telegram alerts the moment validation fails.

Pick one critical data source and deploy your validator there first. Watch how it performs, adjust your schema based on real patterns, then roll it out to additional sources. Apply this approach everywhere data enters your system—MQTT streams, API endpoints, PLC connections. You'll shift from constantly troubleshooting mysterious failures to preventing them entirely.

Pay attention to your validation metrics. High failure rates from specific sensors signal equipment problems. Recurring error patterns reveal network issues or configuration drift. Your validator becomes an early warning system for operational problems.

The validation patterns you build today make your automation trustworthy tomorrow.

Want to discover how FlowFuse helps you collect, validate, enrich, and use machine data to reduce costs and improve operational efficiency, along with powerful enterprise features? Contact us or Book a demo to get started.

Store-and-Forward at the Edge: Buffering Production Data During Network Outages

2025-11-21T00:00:00Z

Network outages happen. A fiber cut, a switch failure, or infrastructure maintenance can take your connectivity offline without warning. When it does, your PLCs continue operating normally—they don't wait for the network to recover.

The problem is that all the data they generate during that outage has nowhere to go. Production metrics, quality measurements, and alarm events accumulate with no path to your historian or cloud platform. When connectivity returns, you're left with gaps in your operational records. Those gaps create real problems: incomplete batch records for quality audits, missing data for troubleshooting production issues, and compliance documentation that doesn't hold up under review.

Store-and-forward solves this. This article walks through building a store-and-forward system with FlowFuse that maintains complete data continuity during network failures.

Below is the demo video where I show how production data can be lost without buffering, and how buffering prevents that from happening.

What is Store-and-Forward?

Store-and-forward is a pattern where data is saved locally before transmission, then forwarded when network connectivity is available. Your edge device writes every data point to local SQLite storage first. If the network is up, the data transmits to your destination—MQTT broker, historian, cloud platform, or database. If the network is down, the data stays in storage until connectivity returns.

The edge device operates in three states. During normal operation, data writes to the buffer and forwards successfully—the buffer stays near-empty. During a network outage, data continues writing to the buffer but cannot forward—the buffer grows. When connectivity returns, the device forwards the buffered backlog in chronological order while continuing to collect new data—the buffer drains back to empty.

flowchart TD
    Source[PLC / Sensor]
    Destination[Cloud / Broker / Server]

    Source --> Start[Data Arrives at Edge]
    Start --> Save[Store in Local Buffer]
    Save --> Check{Network Available?}

    Check -->|Connected| Send[Send Data]
    Send --> Destination
    Destination --> Clear[Remove Data from Buffer]

    Check -->|Disconnected| Wait[Keep Data in Buffer]
    Wait --> Retry[Retry Until Network Restored]
    Retry --> Check

    %% Styling (consistent theme)
    style Source fill:#3B82F6,color:#fff
    style Start fill:#3B82F6,color:#fff
    style Save fill:#818CF8,color:#fff
    style Check fill:#6366F1,color:#fff
    style Send fill:#60A5FA,color:#fff
    style Destination fill:#60A5FA,color:#fff
    style Clear fill:#93C5FD,color:#000
    style Wait fill:#A5B4FC,color:#fff
    style Retry fill:#BFDBFE,color:#000

This solves the core problem in industrial data collection: network failures creating gaps in your time-series data. A four-hour outage would normally mean four hours of missing production data. With store-and-forward, that same outage causes zero data loss. Your destination system receives complete chronological data with only a delivery delay.

Getting Started

Let's build a store-and-forward system to protect your data during network outages.

We'll approach this in six steps: establish a connection to collect data, set up a local buffer to temporarily store that data, write incoming data to the buffer, monitor network connectivity status, create forwarding logic to transmit buffered data when connectivity returns, and finally add error handling and buffer management to ensure reliable operation.

Prerequisites

You'll need the following before implementing store-and-forward:

Edge Device Running FlowFuse Agent: A running FlowFuse instance deployed on your edge hardware or gateway device.
node-red-node-sqlite: SQLite node for local data storage.
node-red-contrib-ping: Ping node for connectivity monitoring.

Step 1: Set Up Data Collection

Data collection is the foundation of store-and-forward. Your edge device needs reliable connectivity to your data sources before you can buffer and forward their data.

FlowFuse handles this through Node-RED's 5,000+ community nodes, which support virtually every industrial protocol and interface—Modbus, OPC UA, MQTT, Ethernet/IP, GPIO pins, serial connections, and more. You collect data from your sources, transform it into the format you need, and prepare it for buffering.

For this guide, we'll assume you already have data flowing into FlowFuse. The store-and-forward pattern works the same regardless of which data sources or protocols you're using.

For more information on how FlowFuse can help you connect, collect, transform, and contextualize your data, and how it simplifies deployment, management, scaling, and security with enterprise features for production environments, book a demo.

Step 2: Implement SQLite Buffering

SQLite provides the persistent storage layer for your store-and-forward buffer. It's lightweight, requires no separate database server, and handles the write volumes typical of industrial data collection without issue.

Follow these steps to set up your SQLite buffer:

Drag the sqlite node from the palette onto your workspace.
Double-click the node to open its configuration panel. Click the pencil icon next to the Database field to create a new database configuration. Give it a name like sqlite, select Read-write-create as the mode, and click Add to save the configuration.

SQLite database configuration with read-write-create mode enabled

Set the SQL Query mode to Fixed Statement. In the SQL Query field, enter:

CREATE TABLE IF NOT EXISTS data_buffer (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp INTEGER NOT NULL,
    sent INTEGER DEFAULT 0,
    payload TEXT,
    created_at INTEGER DEFAULT (strftime('%s','now') * 1000)
);

The payload stores the serialized data as JSON. The sent flag indicates whether the record is still pending (0) or has been successfully delivered (1) — this acts as a safety marker to prevent cleanup of unsent data.

Connect an Inject node to Sqlite node
Deploy your flow and click the inject node button to create the table.

Your SQLite buffer is now ready to store data during network outages. The next step implements the logic to write incoming data to this buffer.

Step 3: Store Incoming Data in Buffer

With your SQLite buffer ready, implement the logic to write incoming PLC data to storage.

Drag a JSON node onto the canvas and connect it to your data input source.
Double-click the node to open its configuration. Set the Action to Always convert to JSON String and set the Property to msg.payload, then click Done to save.

Note: JSON converts your data object into a text string for storage. If your data source already provides a JSON string (not an object), you must delete this node.

JSON node configured to stringify payload data for storage

Drag a Change node onto the canvas and connect it to the JSON node.
Double-click the Change node to configure it. Add the following rules:
- Rule 1: Set msg.params to {} (JSONata expression)
- Rule 2: Set msg.params.$ts to msg.timestamp
- Rule 3: Set msg.params.$payload to msg.payload

Change node rules for preparing SQLite insert parameters

Drag another Sqlite node onto the canvas and connect it to the Change node.
Double-click the node to configure it. Select your existing Sqlite database, set the SQL Query mode to Prepared Statement, and in the SQL Query field, enter:

INSERT INTO data_buffer (timestamp, payload, sent)
VALUES ($ts, $payload, 0);

Click Done to save the configuration and deploy your flow.

Your buffer now accumulates all incoming data. Each data point is serialized to JSON, structured into parameters, and written to SQLite with sent=0 (not yet forwarded). The prepared statement approach prevents SQL injection issues and handles special characters correctly.

Step 4: Monitor Network Connectivity

Network connectivity monitoring determines when your system can forward buffered data. The ping node checks connectivity to your destination system, and when the network is available, it triggers the forwarding process.

Follow these steps to implement connectivity monitoring:

Drag a Ping node onto the canvas.
Double-click the node to configure it. Enter the IP address or hostname of your destination system in the Target field (e.g., broker.flowfuse.cloud), select mode to "Automatic", set "Ping every" to 30 seconds (adjust based on your requirements), name it "Network Health Check", and click Done to save.

Ping node configured to monitor network connectivity every 30 seconds

Drag a Switch node onto the canvas and connect it to the Ping node.
Double-click the Switch node to configure it. Set the Property to msg.payload,
- add Rule 1 as false (network is down),
- add Rule 2 as otherwise (network is reachable).

Switch node routing messages based on network connectivity status

Click Done to save.

The switch node routes messages based on ping results. When ping fails, msg.payload is false. Otherwise, the ping succeeded with a response time.

Drag two change nodes onto the canvas. Connect the first one to output 1 of the switch node (network down), and the second one to output 2 (network reachable).
Double-click the first change node to configure it:
- Rule 1: Set flow.networkOnline to false (boolean) ( make sure it is stored in the persistent storage )
- Name it "Set Network Offline"
- Click Done to save.

Change node setting network offline flag in persistent storage

Double-click the second change node to configure it:
- Rule 1: Set flow.networkOnline to true (boolean)
- Name it "Set Network Online"
- Click Done to save.

Change node setting network online flag when connectivity is restored

Drag another change node onto the canvas and configure it:
- Rule 1: Set flow.flowError to false (this resets the error state triggered in the Handle Errors and Disconnections section).

Change node resetting error state when network becomes available

Drag a Link Out node onto the canvas and connect it to the "Set Network Online" node. Name it "Trigger Forward".

Your connectivity monitoring is now complete. When the network is available, the system will trigger the forwarding logic to send buffered data.

Step 5: Build the Forwarding Logic

The forwarding logic retrieves unsent data from the buffer, prepares it for transmission, and sends it to the destination. This section shows how to build a forwarding system that processes buffered data in batches.

Retrieve and Prepare Unsent Records

Drag a Link In node onto the canvas and name it "Trigger Forward". Link this to the Link Out node from Step 4.
Drag an SQLite node onto the canvas and connect it to the Link In node. Name it "Get Unsent Data" and configure it by selecting your database, setting SQL Query mode to Fixed statement, and entering the following SQL:

   SELECT * FROM data_buffer 
   WHERE sent = 0 
   ORDER BY timestamp ASC 
   LIMIT 50;

Click Done to save.
Drag a Split node onto the canvas and connect it to the SQLite node. Configure it to split msg.payload and click Done.
Drag a Change node onto the canvas and connect it to the Split node. Name it "Prepare Forward Message" and add the following rules:
- Rule 1: Set msg.record_id to msg.payload.id
- Rule 2: Set msg.payload to msg.payload.payload

Change node extracting record ID and payload for forwarding

Click Done to save.
Drag a JSON node onto the canvas and connect it to the Change node. Configure it by setting Action to Always Convert to JSON Object and Property to msg.payload, then click Done.

JSON node configured to parse stored JSON string back to object

Click Done to save.
Drag a Link Out node onto the canvas and connect it to the JSON node. Name it "Send to Destination".

Your forwarding logic now retrieves unsent records, prepares them for transmission, and passes them to the next stage for sending.

Step 6: Send Data and Handle Errors

This step implements data transmission to your destination with comprehensive error handling and buffer management.

Send Data to Destination

Drag a Link In node onto the canvas and link it to the Link Out node from Step 5. Name it "Send to Destination".
Drag a Switch node onto the canvas and connect it to the Link In node. Name it "Check Network Online", set the Property to flow.networkOnline, add a condition is true, and click Done to save.

Switch node verifying network connectivity before sending data

Drag another Switch node onto the canvas and connect it to the first switch node's output. Name it "Check Flow Error", set the Property to flow.flowError, add a condition is false, and click Done to save.

Switch node checking for error-free state before transmission

Drag a Change node onto the canvas and connect it to the second switch node's output. Configure it to append the record ID into the payload for transmission confirmation:
- Rule 1: Set msg.record_id to msg.payload.record_id

Change node preserving record ID for transmission confirmation

Drag a Project Out node onto the canvas and connect it to the Change node. Double-click the node to open its configuration. Select "Send to specified node" as the mode, then enter select target "broadcast message" and enter topic (for example: acme_manufacturing/plant_01/floor_2/cell_a/machine_A12/measurements). Click Done to save the configuration.

Note: you can use any output node that suits your architecture instead of Project Out, such as MQTT Out for publishing to MQTT brokers, HTTP Request for sending data to REST APIs, Database nodes for writing directly to databases or other protocol-specific nodes depending on your destination requirements.

Deploy the flow.

Mark Records as Sent and Clear Buffer

Drag a Project In node onto the canvas, double-click the node to configure it with source set to "Listen for broadcast messages", and configure it to listen on all instances and devices with the topic that should match the same topic you configured in the Project Out node earlier to subscribe to your data that was sent before.

Note: The Project In node is used here to confirm successful transmission when using Project Out nodes. If you are using other output nodes such as MQTT Out, HTTP Request, or database nodes, replace the Project In node with the corresponding confirmation mechanism for your chosen protocol. For example, if your output node such as HTTP Request responds with a status code or success message, you can use that response directly for confirmation instead of the Project In node.

Drag a Change node onto the canvas and connect it to the Project In node. Name it "Prepare Record ID" and configure the following rules:
- Rule 1: Set msg.params to {} (JSONata expression: {})
- Rule 2: Set msg.params.$record_id to msg.record_id

Change node preparing parameters for marking record as sent

Click Done to save.
Drag an SQLite node onto the canvas and connect it to the Change node. Name it "Mark as Sent", then double-click it to configure. Select your database, set SQL Query mode to Prepared Statement, and enter the following SQL:

   UPDATE data_buffer 
   SET sent = 1 
   WHERE id = $record_id;

Click Done to save.
Drag another SQLite node onto the canvas and connect it to the previous SQLite node. Name it "Delete Record", then double-click it to configure. Select database, set SQL Query mode to Prepared Statement, and enter the following SQL:

   DELETE FROM data_buffer
   WHERE id = $record_id
   AND sent = 1;

Click Done to save and deploy the flow.

Handle Errors and Disconnections

Drag a Catch node onto the canvas. Configure it to catch errors from all nodes.
Drag a Change node onto the canvas and connect it to the Catch node.
Name it "Set Flow Error" and configure it:
- Rule 1: Set flow.flowError to true (boolean)

Change node setting error flag when transmission fails

Click Done to save.
Drag a Status node onto the canvas and configure it to monitor the Project node's status.
Drag a Switch node onto the canvas and connect it to the status node.
Name it "Check Disconnected", set the Property to msg.status.text, add a condition == with value disconnected, and click Done to save.
Drag a Change node onto the canvas and connect it to the Switch node.
Name it "Set Network Failure Flag" and configure it:
- Rule 1: Set flow.networkOnline to false (boolean)
Click Done to save and deploy your flow.

Conclusion

You now have a working store-and-forward system that protects your data during network failures.

When the network is up, data flows through the buffer and transmits immediately. When the network goes down, data accumulates in SQLite. When connectivity returns, the buffered data forwards automatically while new data continues collecting. No data is lost, regardless of how long the outage lasts.

This pattern solves a common problem in industrial environments: maintaining complete time-series data when network infrastructure fails. Your production systems can now operate independently of network reliability.

The system you've built is production-ready as-is, but you can extend it based on your requirements—add monitoring for buffer capacity, implement data validation rules, or configure forwarding to multiple destinations. The core mechanism remains the same.

If you want to get the flow template that you can use directly and modify according to your needs, check out our latest blueprint.

FlowFuse 2.24: FlowFuse Expert in the Node-RED Editor, Scheduled Updates, Simpler Edge Device Addition, Store and Forward Blueprint, and what's next!

2025-11-20T00:00:00Z

This release unlocks several new abilities for our users, speeding your development time, easing management of Node-RED instances, providing a smoother path to adding large numbers of devices, and more. Let's dig in.

FlowFuse Expert

[FlowFuse Expert UI]

The FlowFuse Expert used to live only on flowfuse.com, where you could use an LLM trained on FlowFuse and Node-RED documentation, and trained by the Node-RED experts at FlowFuse. Now, we've taken it a step further. The FlowFuse Expert is now available inside of the FlowFuse UI, and even in the Immersive Editor in Node-RED!

You are no longer limited in your interactions with the FlowFuse Expert by the location where you started your conversation. Keep the conversation going and rely on the Expert's advice right where you're building in Node-RED.

Even better, when you're working in the Immersive Editor, the Expert will recommend flows based on your inputs, and you can copy and paste them directly into the Node-RED Editor, once again saving you time and reducing the effort needed to develop in Node-RED.

Automatic Updates of Instances

[Scheduled Updates Interface]

When there are new updates to Node-RED, or the FlowFuse components, it has been a manual task for users to spot the update and trigger the upgrade to get the latest fixes and features applied to their instances.

We're here to make your tasks easier, not to give you more maintenance burdens. So with this release, we've introduced the ability to automatically apply any updates that are available to Node-RED or the FlowFuse stack around it. You get to pick a maintenance window during the week for when the updates should get applied.

For Starter tier teams, we will apply a default schedule for overnight at the weekend to minimise disruption. For Pro and Enterprise tiers, users can configure their own schedule via the Instance's Maintenance settings tab.

Keeping your software up to date is important, and this features gives you one less thing to worry about.

Simpler Edge Device Addition

[Provisioning Token Interface]

Many of our customers make use of large fleets of edge devices. Through the use of provisioning tokens it's easy to get lots of devices setup quickly - but there were still some additional steps needed to get the devices properly named and organised. Now, when setting up a new device with a provisioning token, it is possible to name it at the same time, reducing the complexity of the workflow. We want you to be able to scale up your edge device count quickly and easily, and this represents a significant step in that direction.

Blueprint: Store and Forward

When data acquisition and processing at the edge is mission critical, it is vital that data received at the edge can be stored and protected until it can be forwarded to its destination. Having heard from customers that an easy way to execute a store and forward structure is needed, we have created this Blueprint to speed your development of this data-preserving flow.

Find out more on the blueprint page.

Sneak Peek

FlowFuse MCP nodes allow you to surface information to an LLM to create custom AI agents. We're working on enabling FlowFuse to identify anything you have surfaced to an MCP, paving the way for creating massively powerful agents, enabled by everything you've connected to FlowFuse.

FlowFuse Expert for Open-Source Node-RED

FlowFuse Expert is our collection of AI-enhancements within the Node-RED editor - assisted creation of Function nodes, autocompleting flows and documentation generation amongst other features. Currently it's an exclusive feature of the FlowFuse platform, but we're hard at work to bring it to standalone Node-RED instances.

Coming soon you'll be able to experience the power of AI-enhanced development within Node-RED wherever it's running.

What else is new?

For a complete list of everything included in our 2.24 release, check out the release notes.

Which of these new features are you most excited to try? Email me directly at greg@flowfuse.com - I'd love to hear from you!

Try FlowFuse

FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

Get started for free and have your Node-RED instances running in the cloud within minutes.

Self-Hosted

Get FlowFuse running locally in under 30 minutes using Docker or Kubernetes.

Building a Web HMI for Factory Equipment Control

2025-11-19T00:00:00Z

Most factory HMIs are still stuck in one place. Dedicated panels mounted next to equipment, or SCADA workstations in the control room. Need to check something? You're walking over there.

Web-based HMIs change that. Build your interface once in FlowFuse, and it runs anywhere—desktop, tablet, phone. Your operators can monitor and control equipment from wherever they need to be.

This tutorial walks you through building a simple motor control interface: two buttons and a status display. You will learn how to connect to PLCs, build HMI dashboards, and enable remote access. From there, you can scale up to production lines with multiple sensors and actuators, live charts, gauges, sliders, and interactive controls.

Here's what you'll build:

Prerequisites

Before beginning, ensure you have:

Edge device - A computer, Raspberry Pi, or industrial PC that connects to your PLC and runs FlowFuse
PLC on the same network - Your PLC must be networked with your edge device
Equipment to control (optional but recommended) - Having a motor or other equipment connected to your PLC helps you follow along and see real results as you build the HMI

Understanding the Setup

Your PLC already controls your equipment. It reads sensors, executes logic, and switches outputs. That doesn't change.

FlowFuse sits between operators and the PLC. It runs on an edge device connected to the same network as your PLC. FlowFuse communicates with the PLC using Modbus, OPC UA, EtherNet/IP, S7, or whatever protocol your PLC speaks.

Inside FlowFuse, nodes handle the PLC communication and data transformation while dashboard nodes let you build the HMI. These nodes create buttons, gauges, charts, and status displays. FlowFuse serves this interface as a webpage that any browser can access.

When an operator clicks a button, FlowFuse writes the command to the PLC. When the PLC updates its output, FlowFuse reads it and pushes the new value to the dashboard. The browser updates automatically.

HMI Design Principles Worth Knowing

Before diving into the build, it's helpful to understand what makes industrial HMIs effective. Our tutorial keeps things simple, but these principles are worth knowing as you get more comfortable with FlowFuse and expand your system.

Good HMIs let operators quickly assess what's happening at a glance. Status should be immediately obvious: what is running, what is stopped, what needs attention. Color coding helps with this: green for running, red for stopped, yellow for warnings. Following standards like ISA-101 ensures your color choices are consistent with what operators expect across different systems. We'll use this approach in our motor control example.

Your PLC handles real-time control—your HMI just reflects what's happening. Polling intervals between 500-1000ms work well for most applications. Faster polling doesn't improve control, it just increases network traffic. Status indicators should be large and clear, with critical information immediately visible and text readable from a reasonable distance.

If operators will use tablets, design for touch targets (minimum 44x44 pixels) and avoid interactions that depend on hovering. Test on actual devices your team will use. Most importantly, always show operators when the HMI is disconnected from the PLC. This is critical for safety—operators need to know immediately if their commands aren't reaching the equipment. Display connection status prominently, and consider disabling controls when disconnected.

Step 1: Set Up FlowFuse

You need the FlowFuse agent running on an edge device that can reach your PLC over the network.

Start by creating a FlowFuse account. Once logged in, install and register the FlowFuse agent on your edge device by following this guide: Installing Node-RED on Your Edge Device

Step 2: Connect to Your PLC

Your HMI needs to talk to your PLC to read equipment status and send control commands. FlowFuse handles this through Node-RED's protocol nodes, which support every major industrial controller. No proprietary gateways, no per-tag licensing, no vendor lock-in—just direct communication with your PLC.

Choose the node that matches your PLC:

node-red-contrib-modbus – Modbus RTU/TCP PLCs and devices
node-red-contrib-s7 – Siemens S7-300/400/1200/1500
node-red-contrib-opcua – OPC UA servers (universal industrial standard)
node-red-contrib-cip-ethernet-ip – Allen-Bradley/Rockwell PLCs
node-red-contrib-mcprotocol – Mitsubishi PLCs
node-red-contrib-omron-fins – Omron PLCs
node-red-contrib-bacnet – BACnet building automation devices

Installing Protocol Nodes:

Click the hamburger menu (top right) → Manage palette.
Go to the Install tab.
Search for your protocol node (e.g., node-red-contrib-s7 for Siemens).
Click Install.

Configuring Your Connection

After installation, drag the protocol node onto your canvas. You’ll need two types of nodes: one for reading equipment status and one for sending commands.

Start with an input node for reading status (motor running, faults, sensor values). Use S7 In for Siemens, Modbus Read for Modbus devices, or OPC UA Client for OPC UA servers, etc. Open the node configuration and click the pencil icon next to the Server/Connection dropdown to create a new connection configuration. Here, enter the connection details for your PLC or server — such as IP address, port, credentials, and polling interval. The exact parameters vary by protocol; if you need help understanding what to configure, refer to the documentation links in the protocol node list above. Each link includes detailed setup guidance.

After saving the connection configuration, specify the variable addresses that provide the status information you want to read (tags/registers such as motor state, faults, and sensor values). If available, enable efficiency features like “emit only on change” or “subscribe mode” to minimize unnecessary updates.

For sending commands (start motor, stop motor, setpoints), drag the corresponding output node onto your canvas. When configuring it, select the same Server/Connection from the dropdown instead of creating a new one. This shared connection approach means the IP address, port, and credentials only need to be configured once and can be reused across all your PLC/server nodes. You then only need to specify the variable addresses that control your equipment, and connect those nodes to your dashboard buttons or automation logic.

Important Note: Some PLCs require configuration in their engineering software before allowing external access. For example, Siemens S7 requires PUT/GET communication enabled in TIA Portal, and Allen-Bradley controllers may need explicit messaging enabled in Studio 5000. Refer to your PLC’s documentation for any communication prerequisites.

Test Your Connection:

Add a Debug node and connect it to your input node.
Click Deploy.
Check for a green "connected" or "online" status indicator on your protocol node.
Open the debug panel to verify data is flowing from your PLC.

Once you see live values in the debug panel, your PLC connection is working and you're ready to build the operator interface.

Step 3: Build Your HMI Dashboard

With your PLC connected, let's create the operator interface using FlowFuse Dashboard, a set of UI nodes that build web-based interfaces without writing HTML or JavaScript.

Install Dashboard 2.0

Click the hamburger menu and select Manage palette.
Go to the Install tab.
Search for @flowfuse/node-red-dashboard.
Click Install.

Create Your Motor Control Interface

Add Control Buttons:

Drag a ui-button widget onto your canvas.
Double-click to open its configuration.
Click the pencil icon next to "Group" to create a new group name, example, "Motor Controls" or another name that fits your equipment.
Click the pencil icon next to "Page" to create a new page like "Line 1", for example, "Line 1" or the area of your process this interface belongs to.
Configure the button:
- Label: "Start"
- Payload: true (boolean)
- Background: #28A745

Start button node configuration

Click Done.
Connect this node to your PLC write node.
Repeat to add a "Stop" button with payload false and #DC3545 background.

Stop button node configuration

Add Status Display

The PLC continuously reports whether the motor is running or stopped as a boolean value. We'll convert these values into readable text with color-coded styling.

Convert Boolean Values to Readable Status:

Drag a switch node onto the canvas and connect it to your PLC read node.
Add two conditions: is true and is false to check msg.payload.

Switch node configuration for motor status

Drag two change nodes onto the canvas:
- Connect the first to the "true" output: set msg.payload to "RUNNING" and msg.class to "running"
- Connect the second to the "false" output: set msg.payload to "STOPPED" and msg.class to "stopped"

Change node configuration for running status

Change node configuration for stopped status

Create the Status Display:

Drag a ui-text widget onto your canvas.
Double-click to configure:
- Group: Select "Motor Controls" (or create a "Status" group).
- Label: Leave empty or enter "Motor Status:"
- Value Format: msg.payload.
Click Done.
Connect both change nodes to the ui-text widget.

Motor status text widget configuration

Add Status Styling:

Drag a ui-template widget onto the canvas.
Configure:
- Type: Select "CSS (All Pages)" or "CSS (Single Page)".
- Add this CSS:

.running {
    color: lightgreen !important;
    font-size: 60px !important;
    font-weight: bold;
}
.stopped {
    color: red !important;
    font-size: 60px !important;
    font-weight: bold;
}

CSS template for status display styling

Click Done and deploy the flow

You've just built a basic motor control interface. FlowFuse Dashboard includes gauges, charts, sliders, and other widgets that work the same way—drag, configure, connect. See the widget reference for the full list.

Accessing Your Dashboard

Local Network Access:

The dashboard in a remote instance isn't accessible by default. To enable it:

Go to Instance Settings → Security.
Check "Allow Offline Access" and set a username and password.

Enabling offline access in instance security settings

Click save settings, then restart the instance using the top-right action button dropdown
Navigate to http://[device-IP]:1880/dashboard in your browser.

Completed HMI dashboard running in browser

Note: While offline access is convenient for testing purposes, it should be avoided in production environments. Running the dashboard locally may bypass secure authentication, potentially exposing sensitive controls and data. For production deployments, we recommend using a FlowFuse-hosted instance, which provides proper security. Setup instructions are available below.

Remote Access:

While a local dashboard works for on-site monitoring, it’s not ideal for production. A FlowFuse hosted instance lets you securely monitor and control your equipment from anywhere. Your edge device remains behind your factory network, while the hosted instance subscribes to PLC data via MQTT and displays it on the dashboard.

The architecture is straightforward: your edge device publishes PLC data to MQTT topics, and a hosted FlowFuse instance subscribes to those topics to display the data. When an operator clicks a control button in the hosted dashboard, it publishes a command to MQTT, which your edge device receives and writes to the PLC.

Enable MQTT in Your Team:

Before you can use MQTT, you need to enable the FlowFuse MQTT broker for your team, a one-time setup in your FlowFuse team settings that also covers PLC to MQTT integration in depth.

Configure Your Edge Device:

On your remote instance (the one connected to your PLC), you'll publish status data and subscribe to commands:

Drag an ff-mqtt-out node onto the canvas.
Double-click to open configuration and click "Configure access control".
FlowFuse automatically creates an MQTT client for your instance—enable both Publish and Subscribe permissions.
Set the topic to something descriptive like: factory/line1/motor/status
Connect this node to your PLC read node (the one that gets motor status).
Add an ff-mqtt-in node and set its topic to: factory/line1/motor/command
Connect this node to your PLC write node (the one that controls the motor).
Deploy your flow.

Your edge device now shares motor status via MQTT and listens for control commands.

Build Your Remote Dashboard:

Create a new hosted instance in FlowFuse. This instance runs in the cloud and will host your operator dashboard:

Install @flowfuse/node-red-dashboard using Manage Palette.
Build your control interface following the same steps as before—add ui-button widgets for start/stop and ui-text widgets for status display.
Add an ff-mqtt-in node with topic factory/line1/motor/status and connect it to your status display widgets.
Add an ff-mqtt-out node with topic factory/line1/motor/command and connect it to your control buttons.
Configure access control for this hosted instance's MQTT client (enable Publish and Subscribe).
Deploy.

Your dashboard is now accessible at https://[your-instance].flowfuse.cloud/dashboard from any device with internet access. Commands flow from the hosted dashboard through MQTT to your edge device, then to your PLC. Status updates travel the reverse path.

Next Steps

You now have a working HMI that controls real equipment from any browser. The same approach scales to more equipment—motors, conveyors, pumps, valves—just repeat the connection and dashboard steps.

As your system grows, organize controls across multiple dashboard pages for different production lines or work cells. Add chart widgets to visualize production rates, cycle times, and sensor trends. Configure notification nodes to alert your team via email or Telegram when faults occur.

And if you need to deploy the solution across many production lines, FlowFuse's DevOps features help you manage the scale. Build your HMI once, then deploy it across multiple edge devices and push updates centrally without visiting each location.

Book a demo to see how FlowFuse can help your organization connect, collect, transform, and visualize industrial data with our low-code and AI-powered editor—without the hassle of infrastructure management, deployment complexities, or security concerns at scale.

FlowFuse + LLM + MCP = Text Driven Operations

2025-11-12T00:00:00Z

In industrial operations it's all about getting more out of the CAPEX already spent. Achieving higher efficiency means everyone needs to get data from a lot of different machines, have an understanding how these machines form lines and fit together, and holistically understand these as a group of assets that collectively can achieve more.

With the rapid adoption of Artificial Intelligence (AI), Model Context Protocol, low-code platforms it's clear that the future of operations is conversational. The interface to machines is becoming plain text, allowing teams to obtain effects and scale operational excellence across entire business units simply by asking the right questions.

The Context Challenge

Data capture involves integrating various machine protocols (like OPC-UA or Modbus), transporting, combining, and visualizing the information. While low-code tools like Node-RED have decreased the implementation time to mere hours, the full problem isn't solved: what happens after the data is collected?

Often, raw sensor data—like pressure, voltage, and temperature readings—lacks context to immediately understand there's a problem worth solving. Even when a dashboard has been built, spotting an issue (such as a high energy consumption on machine 1) doesn't inherently guide the operator on how to resolve it. Furthermore, data flow often involves a psychological hurdle, moving from areas where an engineer feels comfortable (perhaps the data storage side) to areas of less expertise (like machine protocols or physical voltage readings).

The goal is to asking high-level questions, such as: "What changed in the energy consumption for machine 4?".

Text: The New Language of Control

Removing code, often a complex layer, can be now achieved because of Large Language Models (LLMs) and the Model Context Protocol (MCP).

LLMs, like ChatGPT, predict the next word in a sentence, allowing humans to query systems using natural language rather than complex code. LLMs face fundamental limitations though: they are typically cloud-based, can be slow, and are trained at specific points in time, meaning they cannot inherently react to real-time, event-based data or proprietary local context.

This is where the Model Context Protocol (MCP) steps in. The promise of MCP is to give models more context through an agreed-upon protocol. MCP allows operators to define exactly what read-only information (resources) or functionality (tools) they want to expose to the LLM.

Resources are read-only, like sensor readings, employee staff lists, vacation calendars, or specification sheets (e.g., upper and lower temperature limits).
Tools are functions that allow the LLM to perform an action or change a state in the physical world.

By feeding this context into an MCP server (such as the official FlowFuse MCP node), the LLM transforms into a powerful operational partner.

For example, an operator can ask: "Can you show me the last five temp sensor readings recorded?". Once the model identifies an anomaly, the operator can incorporate specifications and ask: "Are any of these values outside of spec for upper temp or lower temp?". If a problem is confirmed, the system can use staff and location data to answer a pointed question like: "Who are all the staff located nearest to the problem, and what is the quickest way to get there?". This capability quickly transforms complex data into actionable steps—finding the problem, comparing it to specs, finding the right person, and routing them to the site—all within a matter of minutes.

Orchestrating Effects Across the Machine Fleet

The ability to propagate these text-driven decisions across many machines by the same team is enabled by Node-RED serving as the essential integration layer.

FlowFuse, a major corporate sponsor of Node-RED, aims to fuse the digital realm with machines and the shop floor for IoT use cases. Node-RED acts as the shell that connects proprietary and legacy machine protocols (OT side) to the modern MCP structure.

If a manufacturing facility wants to allow an LLM to control a physical device, Node-RED can integrate the machine (e.g., a Siemens S7 stack light) and wrap the control logic in an MCP tool. The LLM requests an action (e.g., "turn the stack light green"), the MCP tool sends the action through Node-RED's established adapters, and the action is executed.

This means that existing organizational logic and machine adapters, which have already been integrated into Node-RED, can be instantly made LLM and AI ready. This rapid adaptation allows a very broad spectrum of engineers to be applied to problems, moving past relying on "tribal knowledge" held by a single expert.

Text-Driven Playbooks and the Human in the Loop

Looking ahead, this technology enables the creation of text-driven playbooks. An operator might input a natural language prompt: "How do we optimize a certain procedure in the factory?". The resulting operational procedure, driven by the LLM and executed via MCP tools, becomes a documented playbook. This system helps organizations achieve operational excellence by turning human text input into processes that the rest of the company can read, understand, and replicate.

However, the industry must move cautiously. A critical element of the future of operations is the necessity of a human in the loop.

AI is predictive and, in certain ways, random, meaning that if context slightly changes, the output is not deterministic. When the consequences of an action are physical or high-stakes (e.g., stopping a production line, or an irreversible action like boiling an egg), full control should not be handed over to a non-deterministic system. The risk of an AI being "as confident when they're wrong as when they're right" necessitates human oversight.

For the near future (the next five years), the AI acts as a partner or a fault partner, making the uncomfortable aspects of complex flows more manageable. It is currently best applied in reversible or digital tasks, such as generating reports or triggering low-consequence actions like turning a stack light orange to signal an engineer. As trust grows and impacts iterate, AI will gain more influence and context, but the final, consequential decisions will remain with the human.

The combination of LLMs, MCP, and Node-RED provides operators with super powers. The operational floor is transforming from a place where experts write complex code for singular machines, to a conversational environment where high-level, natural language queries drive intelligent, scalable actions across the entire enterprise.

Ready to experience text-driven operations in your own facility? Try FlowFuse for free or request a personalized demo to see how LLM-powered automation can transform your industrial processes. Contact us today or sign up for our upcoming webinar to stay ahead in the Industry 4.0 revolution.

Building a Label Scanner with FlowFuse for Product Labels & Serial Numbers

2025-11-11T00:00:00Z

In production environments, labels are everywhere! Products have Serial Numbers and Lot Codes, Packages have Batch IDs and Dates. These are often critical to the processes for packaging, tracking, logging, inventory and so on.

Many companies still do this manually. Someone types in each code as products move through the line. It's repetitive, time-consuming work - mistakes are inevitable.

That's where OCR comes in. Optical Character Recognition (OCR) uses cameras to automatically read and extract text from labels and product markings. Instead of manual data entry, a camera simply captures the image and the system pulls out the information you need. It's a straightforward solution that's already being deployed in modern manufacturing facilities worldwide.

Part with Serial No

For example, take a look at the image above. When processed with OCR, it returns the following text:

Serial No: XYZ123456789

This tutorial shows you how you can build an OCR system using FlowFuse that can capture images from cameras, extract text from product labels, lot codes, and serial numbers, validate and parse the extracted data, store results in a database or trigger downstream workflows.

Getting Started

Before we dive in, make sure you have a running FlowFuse instance. If you do not have one yet, you can sign up for the 14-day free trial and get a hosted instance running in under two minutes.

Installing Required Nodes

To perform text extraction from images, you’ll need to install the @sumit_shinde_84/node-red-contrib-simple-ocr node in your FlowFuse instance. This node uses the Tesseract OCR engine under the hood to recognize text from image files or image buffers. To capture images and build a dashboard, you’ll also need the FlowFuse Dashboard and Webcam packages.

Open your FlowFuse editor.
From the main menu, select Manage palette → Install.
Search for and install the following packages one by one:
- @sumit_shinde_84/node-red-contrib-simple-ocr
- @flowfuse/node-red-dashboard
- @sumit_shinde_84/node-red-dashboard-2-ui-webcam

Once installed, you’ll see the simple-ocr node under the Function category and the Webcam widget under the dashboard 2.0 category in the left sidebar.

Building the Scanner

Now, let’s build a scanner dashboard that you can open on a mobile device, allowing the phone to act as a scanner for capturing product labels and serial numbers.

[Label Scanner Built with FlowFuse]

To capture images directly from your browser, you can use the FlowFuse Dashboard along with the Webcam widget, let's install them first.

Configuring the Webcam Node

Drag the Webcam widget onto your canvas.
Double-click the node to open its configuration.
Create a new ui group for it to render the feed (for example, OCR Scanner).
Drag the Button widget onto the canvas and set its label to Scan. Select the appropriate group, check Enable pointerdown event, and set the payload to "capture".
Click Done. When the button is clicked, it will send the "capture" payload, which will trigger the Webcam widget to capture an image.

Scan Label Button Widget Configuration

Deploy the flow

When deployed, this flow creates a dashboard interface with a live camera preview and a large Scan Label button. Each time you click Scan Label, the captured image is sent as a msg.payload.image containing a image buffer.

Tip: To correct a flipped or mirrored camera preview, open the three-dot menu (⋮) on the webcam widget and enable "Mirror Image".

Handling High-Resolution Images

When capturing an image, if you encounter an error stating that the image size exceeds Dashboard 2.0’s maxHttpBufferSize, you’ll need to reduce the image resolution or quality — otherwise, the dashboard connection may reset.

To fix this:

Double-click the Webcam widget.
Adjust the image width, height, and quality parameters.
By default, these are set to 640×480 resolution and 0.8 quality.

You can also check the image size from the webcam output using msg.payload.sizeBytes.

Adding the OCR Node

Now, let’s add an OCR node to extract text from the captured images.

Drag a Change node onto the canvas and set msg.payload to msg.payload.image.
Drag a Simple OCR node onto the canvas.
Connect the output of the Webcam widget to the Change node, and then connect the Change node’s output to the Simple OCR node.
Add a Debug node and connect it to the Simple OCR node to view the results.
Click Done, then Deploy.

Next, open the dashboard by clicking the Dashboard 2.0 button in the right sidebar. Then, click the Scan Label button — the first click will activate your camera (make sure to grant your browser permission to access it).

Position the label in front of the camera, focus on it, and click Scan again. The recognized text will appear in the Debug panel. Now, you need to validate and trim the recognized text, and add a visual indicator to show a successful scan. Let’s set that up next.

Validating and Parsing the Extracted Text

The OCR node returns raw text that may contain extra whitespace, line breaks, or unwanted characters. Let's add validation and parsing logic:

Drag another Function node onto the canvas.
Connect it after the simple-ocr node.
Add the following code:

// Extract and clean OCR text
let text = (msg.payload.text || msg.payload || "")
  .replace(/[\r\n]+/g, ' ')
  .replace(/[^\w\s:]/g, '')
  .replace(/\s+/g, ' ')
  .trim();

// Match part number
let match = text.match(/(?:Part\s*No|No)[:\s]+([0-9A-Z]{6,12})/i);
let part = match?.[1]?.trim() || null;

// Validate format: 6 digits + 2 letters + 2 digits
let valid = part ? /^\d{6}[A-Z]{2}\d{2}$/.test(part) : false;

// Build payload
msg.payload = {
  success: valid,
  partNumber: valid ? part : null,
  timestamp: new Date().toISOString(),
  notificationMsg: valid
    ? `Label successfully scanned: ${part}`
    : "Scan failed — Invalid or unreadable label."
};

return msg;

Tip: You don’t need to know JavaScript to create a function for validating and extracting the label text you’re scanning — just tell the FlowFuse Expert what you want, and it will generate it for you.

Click Done.

This function cleans the text, validates that something was detected, and attempts to extract structured data like serial numbers or part numbers using regular expressions.

Adding Visual Feedback

Users need immediate feedback when a scan succeeds or fails. Let's add both visual indicators:

Drag a Change node onto the canvas and connect it to the validation Function node.
Configure the Change node to set msg.payload to msg.payload.notificationMsg.
Drag a ui-notification widget onto the canvas.
Double-click the ui-notification node to configure it:
- Select or create a UI Base configuration
- Set the position to center
- Optionally, configure the timeout duration (e.g., 3000ms for 3 seconds)
Connect the Change node output to the ui-notification node input.
Click Done and Deploy the flow.

Now when you scan a label:

If the scan is successful, you'll see a green notification with "Label successfully scanned: [part number]"
If the scan fails, you'll see a warning notification with "Scan failed — Invalid or unreadable label"

Your OCR scanning system is now complete! You can test it by opening the dashboard on your mobile device, positioning a product label in front of the camera, and clicking the Scan button. The system will capture the image, extract the text, validate it, and provide immediate visual feedback on the scan result.

If you want to fully automate this process, you can set up a fixed camera positioned where products pass through on the production line. This approach eliminates manual scanning, but it will require proper camera mounting, lighting setup, and trigger mechanisms to capture images at the right moment as products move past the camera.

Furthermore, you can push scanned label data to a database. The easiest way to do this is using FlowFuse Tables, which is a built-in database service managed by FlowFuse. You'll find the query node in the palette that not only simplifies setup by connecting to the FlowFuse Tables database without any setup, it also has access to the integrated FlowFuse Expert, allowing you to generate queries using natural language — no SQL skills required!

What's Next?

You've just built a working OCR system that turns any mobile device into a label scanner. It captures images, reads text, validates the data, and gives instant feedback—all without writing hundreds of lines of code.

This is just the starting point. Your system can grow with your needs: connect it to your inventory database, add support for different label formats, set up multiple scanning stations, or integrate it with your existing ERP system. The foundation is there.

Also, this OCR scanner is just one piece of what's possible with FlowFuse. Imagine connecting all your manufacturing systems—machine data, quality checks, inventory tracking, production metrics—into a unified industrial data platform where everything flows together seamlessly.

FlowFuse helps manufacturers like you break down data silos and build connected, intelligent operations. From shop floor to top floor, your data works together.

See it in action. Book a demo and discover how FlowFuse can transform your entire facility—not just your label scanning.

Or start building today with our 14-day free trial.

How to Ingest CSV Logs into MQTT, Databases, and Dashboards

2025-11-10T00:00:00Z

If you work in manufacturing, you likely have gigabytes of data in CSV files—temperature logs, production counts, machine status records. The data exists and is organized, but it's not accessible to the systems that need it.

PLCs log directly to CSV through proprietary software. Legacy SCADA systems write flat files. Custom applications generate daily reports. These systems are reliable, but they weren't built to integrate with MQTT brokers or databases.

If you're using FlowFuse to log data, you can send to MQTT and databases as data flows through FlowFuse. But if your CSV files come from PLCs, SCADA systems, or other external tools, you need to read and ingest them after they're written.

This guide shows you how to read CSV files—whether real-time or historical—and route them to MQTT brokers, databases, and dashboards.

Prerequisites

Before starting, ensure you have:

A running FlowFuse instance. If you don't have one, sign up for free
CSV log files with industrial data
Access to an MQTT broker
Access to a database

Note: If you have an Enterprise account, you won't need to set up external MQTT brokers or databases, FlowFuse provides these services built into the platform.

Sample Data

If you don't have a CSV file and want to follow along, you can import the following flow and deploy it. This flow will simulate a temperature sensor and log readings to a daily CSV file.

Real-Time Data Pipeline

This pipeline monitors CSV files for changes and immediately publishes new data to MQTT topics. Use this approach when you need live data streams for dashboards, alerting systems, or real-time coordination between multiple systems.

Step 1: Monitoring CSV Files

The Watch node continuously monitors a directory and triggers whenever a file is created or modified.

Drag the Watch node onto the canvas and double-click to configure it. Enter the directory path you want to monitor in the Files field, such as /home/user/data/.
Drag a Change node onto the canvas to set the correct filename. Configure it to set msg.filename using a JSONata expression: "plc_data_" & $moment().format("YYYY-MM-DD") & ".csv" which dynamically constructs the filename based on today's date. If your files use a different naming convention, adjust the expression accordingly.
Drag a Read File node onto the canvas to read the file contents. Set the Filename field to msg.filename as a message property. Configure the Output as "a single utf8 string" and leave Encoding at Default.

Configuration of the File In node to read CSV file contents

Connect the output of the Watch node to the input of the Change node, and the output of the Change node to the input of the Read File node.
Deploy the flow.

At this point, whenever a CSV file in your monitored directory is created or modified, the flow reads its contents. The raw CSV data is now in msg.payload as a text string, ready to be parsed.

Step 2: Parsing CSV Data

Now we'll convert the raw CSV text into structured data.

Drag a CSV node onto the canvas and connect it to the File In node output. Double-click to configure it to set:
- Separator: Comma
- Parser: RFC4180
- Check "First row contains column names" and "Parse numerical values"
- Output: "a single message [array]"

CSV parser configuration for batch processing with RFC4180 standard

The CSV node now converts the raw text into an array of objects, where each object represents a row with named properties from the column headers.

Step 3: Extracting the Latest Record

Since we’re reading the entire file each time it changes, we only need to publish the most recent data point to MQTT.

Drag a Function node onto the canvas and connect it to the CSV node output.
Add this code to extract only the latest row:

// msg.payload is an array of all CSV rows
const rows = msg.payload;

// Extract only the latest row
if (rows && rows.length > 0) {
    msg.payload = rows[rows.length - 1];
    return msg;
} else {
    // No data in file yet
    return null;
}

Deploy the flow.

Your parsed data now flows through as individual records, ready to be published to MQTT.

Step 4: Publishing to MQTT

Now we'll publish the parsed CSV data to an MQTT broker for real-time distribution. If you have FlowFuse Team or Enterprise tier, enable the MQTT broker within your FlowFuse team.

Adding Context to Your Data

Drag a Change node onto the canvas and connect it to the output of the Function node. This step adds useful context for better data traceability.
Configure the node to set msg.payload to a structured object—customize it based on your data and application needs:

{
    "timestamp": payload.timestamp,
    "site": "tokyo_plant",
    "line": "assembly_line_a",
    "device": "press_01",
    "measurement": "temperature",
    "value": payload.temperature,
    "unit": "celsius"
}

Configuring the MQTT Publisher

Drag the ff-mqtt-out node onto the canvas and connect it to the Change node. When you drag the node, it will be automatically configured with the FlowFuse MQTT broker—you do not need to manually add configuration.
By default, the client automatically created for your instance only has subscribe permissions. Click Configure Access Control next to the server in the node configuration window. This will redirect you to the platform’s broker client management page, filtered to show the client associated with this instance. Click the Edit button, enable both Publish and Subscribe actions, and then restart your instance.
Set the topic following ISA-95 hierarchy:

company/site/area/line/cell/device/measurement

For example:

acme/tokyo/assembly/line-a/press-01/temperature

Configure the QoS level in the MQTT node. Set it to QoS 1 for reliable delivery—this ensures your data reaches subscribers even if there are brief network issues, or choose according to your reliability requirements (QoS 0 for high-frequency non-critical data, QoS 2 for critical data).

Configuring the MQTT Out node

Deploy the flow.

Batch Processing Pipeline

This pipeline reads CSV files on a schedule and writes data to databases in efficient batches. Use this approach for historical data storage, trend analysis, and reporting where immediate writes aren't necessary.

Step 1: Reading CSV Files on Schedule

Unlike the real-time pipeline that watches for file changes, batch processing runs on a timer.

Drag an Inject node onto the canvas. Configure it to trigger on your desired schedule:
- For hourly batches: Set repeat interval to "interval" and enter 1 hour
- For shift-based batches: Add multiple inject nodes, For example, one at 08:00 for night shift end, another at 16:00 for day shift end, and a third at 00:00 for evening shift end.
- For daily batches: Set to trigger "at a specific time" once per day
Drag a Change node and configure it to set msg.filename to your CSV file path. Use a JSONata expression if you need dynamic filenames: "plc_data_" & $moment().format("YYYY-MM-DD") & ".csv". If your files use a different naming convention, adjust the expression accordingly.
Drag a Read File node onto the canvas to read the file contents. Set the Filename field to msg.filename as a message property. Configure the Output as "a single utf8 string" and leave Encoding at Default.
Connect the output of the Inject node to the input of the Change node, and the output of the Change node to the input of the Read File node.

Step 2: Parsing All Records

Drag a CSV node and connect it to the File In node output.
Configure it the same way as in the real-time pipeline:
- Separator: Comma
- Parser: RFC4180
- Check "First row contains column names" and "Parse numerical values"
- Output: "a single message [array]"

Step 3: Filtering New Records

Since we’re reading the entire CSV file each time, we need to track which rows have already been written to the database to avoid duplicates.

Drag a Function node and connect it to the CSV node output. Add this code:

const allRows = msg.payload;

// Get the last processed row count from flow context
let lastRowCount = flow.get('lastRowCount') || 0;

// Get only new rows since last processing
const newRows = allRows.slice(lastRowCount);

if (newRows.length > 0) {
    // Update the row count for next run
    flow.set('lastRowCount', allRows.length);
    
    msg.payload = newRows;
    return msg;
} else {
    // No new data to process
    node.warn("No new records to process");
    return null;
}

Step 4: Inserting to Database

Now we'll configure the database insertion to write batched data efficiently.

Enabling FlowFuse Database

If you have a Enterprise account, you can use the built-in PostgreSQL database service instead of setting up an external database. Follow the instructions in Getting Started with FlowFuse Tables to enable the database in your project.

Once enabled, you'll have access to a fully managed PostgreSQL database that's automatically configured and ready to use with your FlowFuse flows.

Creating the Database Table

Before inserting data, you need to create a table to store your sensor readings.

In your Node-RED editor, drag a Query node onto the canvas. Just like the FlowFuse MQTT nodes, it will automatically configure itself when added to the canvas.
Double-click to open it and click "Ask the FlowFuse Expert" at the top of the configuration dialog.
In the assistant prompt, enter: “Create a new table named sensor_data to store sensor readings with the following columns: timestamp, site, line, device, measurement, value, and unit.”, Modify the table name and columns as needed to match your specific data and application requirements.
Click the "Ask the FlowFuse Expert" button. The assistant will generate the SQL query for you and automatically populate it in the Query field.
Drag an Inject node onto the canvas, set it to trigger once, and connect it to the Query node.
Add a Debug node connected to the Query node output to see the result.
Deploy the flow and click the Inject button to create the table.

Preparing Data for Batch Insert

Instead of writing each CSV row individually to the database, we'll use batch inserts for much better performance. A single transaction with many rows is far more efficient than many separate transactions.

Drag a Function node onto the canvas and connect it to the previous Function node (the one that filters new records).
Name this node "Prepare Batch Insert" and add the following code:

// msg.payload contains the new rows from CSV
const newRows = msg.payload;

// Transform each row to match your database schema
const formattedData = newRows.map(row => ({
    timestamp: row.timestamp,
    site: 'tokyo_plant',
    line: 'assembly_line_a', 
    device: 'press_01',
    measurement: 'temperature',
    value: row.temperature,
    unit: 'celsius'
}));

// Generate parameter placeholders for batch insert
// Each row has 7 fields, so we need 7 parameters per row
// Example: ($1,$2,$3,$4,$5,$6,$7), ($8,$9,$10,$11,$12,$13,$14), ...
const values = formattedData.map((_, i) => 
    `($${i * 7 + 1}, $${i * 7 + 2}, $${i * 7 + 3}, $${i * 7 + 4}, $${i * 7 + 5}, $${i * 7 + 6}, $${i * 7 + 7})`
).join(',');

// Build the SQL insert query with placeholders, modify the query according to your table name and schema.
msg.query = `
    INSERT INTO sensor_data 
    (timestamp, site, line, device, measurement, value, unit)
    VALUES ${values};
`;

// Flatten the data into a single array of parameters
// Order must match the columns in the INSERT statement
msg.params = formattedData.flatMap(r => [
    r.timestamp,
    r.site,
    r.line,
    r.device,
    r.measurement,
    r.value,
    r.unit
]);

return msg;

Click Done.

This function generates a parameterized SQL query that inserts all rows in a single database transaction, which is significantly faster than individual inserts.

Visualizing CSV Data on Dashboard

Now that we've ingested CSV data into MQTT and databases, let's visualize it on a dashboard. We'll focus on real-time visualization using the MQTT pipeline we built earlier. For historical data visualization from FlowFuse Tables, refer to our comprehensive guide: Building Time-Series Dashboards with FlowFuse Tables

Step 1: Installing Dashboard

In your Node-RED editor, click the hamburger menu (≡) in the top right corner.
Select Manage palette.
Go to the Install tab.
Search for @flowfuse/node-red-dashboard.
Click Install and confirm.

Step 2: Subscribing to MQTT Data

Drag an ff-mqtt-in node onto the canvas.
Configure the Topic to match your publisher: acme/tokyo/assembly/line-a/press-01/temperature
Set Output to "auto-detect (string or buffer)".

Configuring the MQTT Out node

Step 3: Creating the Dashboard Widgets

Now we'll add a chart to visualize the temperature data in real-time.

Drag a ui-chart widget onto the canvas and double-click it. Create a new UI group for it to render.
Set the size according to your needs for the chart, label to "Temperature", type to "line", action to "append", and x-axis to "timescale".
Next, set series to msg.payload.device, x to msg.payload.timestamp, and y to msg.payload.value.

Chart widget configuration for real-time temperature visualization

Click Deploy.

Once deployed, open the dashboard — you should see a real-time line chart displaying temperature values over time, with each device shown as a separate series. Data points will automatically update as new MQTT messages arrive.

Live dashboard displaying real-time temperature readings from CSV data stream

What's Next

You've transformed static CSV files into live data streams that flow through MQTT, databases, and dashboards. Your legacy equipment now communicates with modern systems without any hardware changes.

This tutorial walked you through building a data pipeline. FlowFuse takes it further by handling both development and production deployment. When you need to scale across multiple production lines, manage team collaboration, deploy to hundreds of devices remotely, or maintain infrastructure like MQTT brokers and databases, FlowFuse provides the platform to do it all. As you saw, it also includes an FlowFuse Expert to speed up your workflow.

If you want to see more on how FlowFuse helps with scaling and production deployments, book a demo today.

The Industrial IoT Market Shift: What the PTC Divestment Means for Your Data Strategy

2025-11-06T00:00:00Z

The news of PTC selling Kepware and ThingWorx to TPG for $600 million has caused a significant impact across the industrial automation sector. For anyone working in manufacturing, OT data integration, or industrial IoT, this divestment raises important questions about the future direction of these widely-used platforms, and what it means for organizations relying on them.

But here's the thing: this isn't an isolated event. Back in July 2024, there were rumors that Autodesk might acquire PTC for $20+ billion. Those talks ultimately fell through when Autodesk walked away from the deal. Now, just months later, PTC has decided to divest two of its major industrial IoT assets. The pattern is clear: PTC is refocusing its strategy.

A Strategic Realignment, Not a Surprise

PTC has been under strategic pressure for some time. The company operates across multiple domains: CAD and PLM (with Creo and Windchill), Application Lifecycle Management (ALM) with Codebeamer, and Industrial IoT with Kepware and ThingWorx. While this portfolio diversity has value, it also creates complexity, and when Autodesk considered acquiring PTC earlier this year, that complexity likely played a role in their decision to walk away.

Now, PTC is taking action on its own. By divesting Kepware and ThingWorx to TPG, the company is narrowing its focus to what it calls its "Intelligent Product Lifecycle" vision, concentrating on CAD, PLM, ALM, SLM (Service Lifecycle Management), and the integration of AI and SaaS across these core areas.

For PTC, this makes sense. Kepware and ThingWorx solve different problems than the rest of their portfolio. They're about OT data connectivity and IIoT application development (areas that don't naturally integrate with product design and lifecycle management). By selling these assets to TPG, PTC can focus resources on its core business while TPG invests in growing the connectivity and IoT platforms.

But for customers, this introduces uncertainty: What does life under TPG ownership look like?

The Customer Reality: Uncertainty and Opportunity

For organizations using Kepware or ThingWorx, this transition will bring uncertainty. Product roadmaps may shift. Pricing structures could change. Integration strategies may no longer make sense in the same way. Even if TPG commits to investing in these platforms, the reality is that customers are now operating in a period of transition (and transitions often, if not always, bring risk).

This is precisely why, back in July when the Autodesk acquisition rumors started, we launched our migration landing page at flowfuse.com/vs/kepware. To leave things clear. To make a clear statement. We saw what was coming. Organizations that had built their OT data strategies on these platforms would soon be re-evaluating their options. And for many, this is the perfect moment to ask a more fundamental question: what should a modern industrial data integration platform actually look like?

The Open-Source Alternative: Built by Node-RED's Founder

At FlowFuse, we take a fundamentally different approach to industrial data integration. We're not a closed, proprietary platform tied to a single vendor's roadmap or business priorities. Instead, we're built on Node-RED, the truly open-source, low-code programming tool created by Nick O'Leary, who is also the founder of FlowFuse.

This isn't just a technical detail but it's a strategic advantage. Here's why:

FlowFuse vs. Kepware: A Clear Comparison

For organizations evaluating their options, the differences between FlowFuse and traditional platforms like Kepware become clear when you compare them side by side:

Open-source foundation: FlowFuse is built on Node-RED and the open-source ecosystem, giving you full transparency and control. Kepware, by contrast, is a proprietary stack with limited visibility into how it works.
Zero vendor lock-in: With FlowFuse, your flows are portable. You can run them anywhere (cloud, on-premises, or at the edge). Kepware ties you to their licensing model and roadmap.
Integration flexibility: Node-RED's 5,000+ community-contributed nodes mean you can connect to virtually anything (MQTT, OPC-UA, REST APIs, SQL databases, cloud services, and more). Kepware's integrations are often limited to proprietary or custom connectors.
Transparent pricing: FlowFuse offers use-based, transparent pricing that scales with your needs. Kepware's licensing model is tiered, often creating cost barriers as you grow.
Active community: Node-RED has one of the largest and most active open-source communities in industrial automation. You're not dependent on a single vendor for support, innovation, or problem-solving. Kepware operates in a closed ecosystem.
Future-proof architecture: FlowFuse is cloud-ready, portable, and designed to evolve with your infrastructure. After multiple ownership transitions, Kepware's future direction under TPG remains uncertain.

You can explore these differences in detail at https://flowfuse.com/vs/kepware.

Connect to Anything, Collect Everything

Node-RED has over 5,000 community-contributed nodes, covering virtually every industrial protocol, database, cloud service, and API you can imagine. Whether you need to pull data from a Siemens S7 PLC, a Modbus device, an OPC UA server, push it to AWS IoT Core, Azure, or your own database, transform it in real-time, and visualize it on a custom dashboard. Node-RED can do it all.

And because it's open source, if a connector doesn't exist, you or the community can build it. This level of connectivity is unmatched. Kepware is powerful for protocol translation, sure, but it's primarily focused on moving data from OT systems to IT systems. Node-RED, by contrast, is a full data orchestration platform. You're not just collecting data, you're transforming, routing, analyzing, and acting on it, all in one place.

No Vendor Lock-In, Ever

With proprietary platforms, your data integration strategy is tied to the vendor's business decisions. Pricing changes? You adapt. Features deprecated? You work around it. Company gets acquired? You hope for the best.

With Node-RED and FlowFuse, you're in control. The core technology is open source, maintained by a thriving global community. FlowFuse adds the enterprise-grade management, security, and scalability that industrial organizations need, but you're never locked in. If you ever decide FlowFuse isn't the right fit, your Node-RED flows are yours to take and run elsewhere. That's the power of true open source.

Enterprise-Ready from Day One

One of the challenges with open-source tools is that they often require significant effort to operationalize at scale. That's where FlowFuse comes in. We provide:

Centralized management of Node-RED instances across multiple sites and edge devices
DevOps-ready workflows with version control, CI/CD integration, and team collaboration features
Enterprise security with role-based access control, audit logs, and compliance-ready deployment options
Scalability to manage thousands of edge devices or cloud-based instances from a single platform

In short, FlowFuse gives you the flexibility and openness of Node-RED with the operational rigor that enterprise IT and OT teams require.

To learn more take a quick look at this video and learn about these 5 reasons you should migrate to FlowFuse. https://youtu.be/fUqfA521Iqg

Simple, Visual, and Incredibly Powerful

Node-RED's low-code, visual programming interface makes it accessible to engineers who aren't developers, while still being powerful enough for complex industrial applications. You wire together nodes to create data flows, connecting sources, transforming data, triggering actions, and building dashboards. It's intuitive, fast to prototype, and easy to maintain.

This means faster time-to-value. Instead of waiting months for vendor implementations or custom development, your team can build and deploy solutions in days or weeks. And because everything is visual, it's easier to document, troubleshoot, and hand off to other team members.

What This Means for You

If you're currently using Kepware or ThingWorx, this transaction isn't necessarily bad news. TPG may very well invest in these platforms and accelerate their development. But it's also a reminder of a fundamental truth in enterprise software: when you build on proprietary platforms, you are always subject to the strategic priorities of the company that owns them.

This is a good time to ask some strategic questions:

Is your data integration platform aligned with your long-term strategy?Or are you constantly adapting to vendor-driven changes?
Can you extend and customize your platform to meet your unique needs? Or are you constrained by what the vendor offers?
Do you have flexibility in how and where you deploy? Cloud, on-premises, edge, hybrid, can your platform handle all of these?
What happens if your vendor’s priorities shift again? Are you prepared for another transition?

For organizations re-evaluating their options, open-source platforms like Node-RED and FlowFuse offer a compelling alternative. You get the connectivity, flexibility, and control to build exactly the data strategy you need, without being tied to a single vendor’s roadmap or business model.

The Path Forward

The industrial automation market is evolving rapidly. As companies like PTC realign their portfolios, the organizations that thrive will be the ones that build on flexible, future-proof foundations.

At FlowFuse, we believe that foundation is open source. It's why we've built our platform on Node-RED, created by our founder Nick O'Leary. And it's why we're committed to giving industrial organizations the tools they need to take control of their data strategies, with the flexibility to adapt, the power to innovate, and the freedom to choose their own path.

Ready to Explore Your Options?

If you're evaluating your options, whether you're currently on Kepware, ThingWorx, or another platform, we'd love to talk.

See how we stack up against Kepware to learn more about how FlowFuse compares to traditional industrial connectivity platforms, or contact our team to speak with one of our Migration Experts. We can help you understand your options, plan a migration strategy, and show you how open-source industrial data integration can transform your operations.

The industrial IoT market is shifting. Make sure your data strategy is built to adapt.

How to Connect Any PLC to MQTT in Under an Hour

2025-10-27T00:00:00Z

Getting PLC data into systems where it can be monitored, analyzed, and acted upon is essential for modern manufacturing. MQTT has become the standard for moving this data. It's lightweight, handles unreliable networks well, and excels at real-time streaming. Once your PLC data is published to MQTT, it creates a common pipeline that IT systems understand—flowing easily to cloud platforms, analytics tools, dashboards, and eliminating protocol translation headaches.

The protocol itself is simple. But implementation in a real factory, with actual PLCs and production networks, is where things fall apart. Costs pile up, timelines drag on, and you end up needing expertise that's hard to find.

This guide cuts through that complexity. You'll learn how to connect PLCs using MQTT without the typical headaches. We'll walk through extracting data from any PLC protocol, transforming it properly, and publishing it reliably—with working examples you can adapt to your own setup.

Why PLC-to-Cloud Gets So Complicated

Before diving into the solution, it's worth understanding why this is so difficult.

First, there's the proprietary protocols. Factory floors have PLCs from different manufacturers, each speaking their own language: Modbus, OPC-UA, Ethernet/IP, Profinet, FINS, etc. Getting data out means dealing with all of them at once, maintaining multiple drivers and troubleshooting different failure modes.

Then there's the networking challenge. Factory networks weren't built for internet connectivity. Isolated subnets, strict firewalls, and security-conscious IT departments mean getting approval for gateways (whether edge devices or software platforms) involves security reviews and architecture decisions that can drag on for months.

The costs add up quickly. Cloud platforms charge per message, and streaming data from dozens of machines easily reaches thousands per month, before gateway hardware and licenses.

And there's the expertise gap. Plant engineers know PLCs but not cloud APIs. IT teams know infrastructure but not industrial protocols. You end up needing expensive consultants, turning what should be straightforward into a six-figure project.

The solution lies in low-code integration platforms that consolidate protocol handling, edge computing, and cloud connectivity into a single system. This guide demonstrates one approach using FlowFuse, a platform built on Node-RED that addresses each challenge outlined above.

Prerequisites

Before you start, make sure you have the following:

A properly configured and fully operational PLCs, located on the same network as the edge device that will be reading its data.
A running FlowFuse instance on your edge device. If you do not have an account, sign up for a free trial and set up your instance following the instructions in this article.

Getting Started

Now, let's get started. First, watch this demo, where I have built a FlowFuse flow that collects data from four sources: Siemens S7 and Allen-Bradley PLCs, an OPC UA server, and a Modbus simulator.

This flow standardizes data from each protocol into a consistent JSON format, enriches it with contextual metadata, and publishes everything to the FlowFuse MQTT Broker — all within a single instance. The following guide explains how to replicate this setup for any PLC on your factory floor.

Step 1: Extract Data from Your PLC

As mentioned earlier, extracting data is the first and most complex step. Get this wrong, and the complexity and costs can spiral out of control. FlowFuse simplifies this process. Its pre-built connectors handle Modbus, OPC UA, EtherNet/IP, and other protocols right out of the box—no custom coding, expensive proprietary gateways, or per-tag licensing fees required. You can configure your connections visually and have data flowing within minutes.

This is not just theory—Fortune 500 manufacturers are already running production systems on FlowFuse. Their consistent feedback? Massive cost savings compared to legacy systems, especially when deployed across multiple facilities. The enterprise features of FlowFuse handle the scale and security requirements large operations demand.

The Node-RED ecosystem that powers FlowFuse offers comprehensive protocol support. You'll find nodes available for every major PLC manufacturer, including:

node-red-contrib-modbus – Modbus RTU/TCP PLCs and devices
node-red-contrib-s7 – Siemens S7-300/400/1200/1500
node-red-contrib-opcua – OPC UA servers
node-red-contrib-cip-ethernet-ip – Allen-Bradley PLCs
node-red-contrib-mcprotocol – Mitsubishi PLCs
node-red-contrib-omron-fins – Omron PLCs
and many more

Adding a protocol node to your FlowFuse instance takes just a few clicks. Open the palette manager from the hamburger menu, select Manage palette, go to the Install tab, and search for the node you need.

Convincing the IT Team

When talking to people in the IIoT community, one recurring challenge always comes up—convincing the IT team.

Traditional industrial gateways require inbound connections from the cloud. This means opening specific ports in your firewall, creating security exceptions, and giving external systems a pathway into your production network. IT security teams push back on this, and rightly so. Inbound connections expand your attack surface and violate the principle of defense in depth.

FlowFuse solves this with an edge-first architecture. The Device Agent installs directly on hardware inside your factory network—a Raspberry Pi, an industrial PC, or even directly on supported PLCs. Once running, the agent initiates outbound connections to the FlowFuse platform using standard web protocols (HTTPS and WebSocket over port 443). All communication flows through this outbound connection. The platform never initiates connections back to your network.

From a security standpoint, this changes everything. Your firewall configuration does not change.
No new inbound rules. No DMZ setup. No VPN tunnels to maintain.

The device agent behaves like any other business application making secure outbound HTTPS requests—something your network already allows.

For networks with proxy servers, the agent supports standard proxy configurations through environment variables. For air-gapped networks, you can pre-cache Node-RED modules and deploy without internet connectivity after the initial setup.

Step 2: Transform and Structure Your Data

Now let's move to the next step. Raw PLC data needs reshaping before cloud transmission. Register values, bit arrays, floating points, and timestamps arrive in different formats. FlowFuse offers several transformation methods suitable for different skill levels.

Visual Transformation with Change Nodes and JSONata

Change nodes handle simple transformations without coding. They allow you to map fields, modify values, convert units, and add metadata using dropdowns and form fields. JSONata allows more advanced data manipulation directly within the Change node.

Plant engineers can work directly with these visual tools—no programming required.

For example, suppose you are receiving a pressure sensor value as msg.payload but it lacks context.

You can use a Change node to:

Add contextual information such as the machine ID, facility, or sensor location, unit

Change node used to convert temperature and add machine context

Function Nodes for Custom Logic

Function nodes provide full JavaScript access for complex requirements. Write custom logic, install npm packages, and access the complete JavaScript standard library when Change nodes and JSONata reach their limits.

Tip: Use the FlowFuse Expert to generate function nodes. Describe the transformation you need in plain English, and it will create the code for you. For best results, provide sample input data to ensure the output matches your requirements.

Pre-built Community Nodes

Before building custom solutions, check the palette manager. The Node-RED ecosystem includes thousands of nodes for data aggregation, statistical analysis, time-series buffering, and unit conversions. Many common transformation tasks already have ready-made solutions.

For example, a popular node I'm using in my demo for parsing and transforming data is node-red-contrib-buffer-parser. This node is especially useful when working with Modbus or PLC outputs, as it converts raw data into structured formats that can be easily processed further.

Step 3: Set Up MQTT with FlowFuse

Most MQTT implementations require setting up a separate broker either paying for a managed service or hosting your own. FlowFuse includes a managed MQTT broker built directly into the platform, eliminating this extra step.

Traditional PLC-to-cloud setups typically involve several moving parts: edge gateways running protocol drivers, a separate MQTT broker (cloud-hosted or self-managed), and your destination cloud services. Each layer adds configuration work, licensing costs, and potential failure points. When data stops flowing, you end up troubleshooting across multiple systems to locate the issue.

FlowFuse consolidates those layers into a single integrated platform. It provides enterprise-grade features for management, scaling, deployment, and security—all handled by the FlowFuse infrastructure. You retain full control over configuration settings through a clean, intuitive interface, without needing to maintain multiple external systems.

To use the FlowFuse MQTT broker, you'll need a FlowFuse Pro or higher-tier account. Once on the Pro plan, you can enable the managed MQTT service by navigating to the Broker section from the left sidebar and selecting FlowFuse Broker.

Enabling FlowFuse MQTT Broker

Configure Publishing

Drag a FlowFuse MQTT Out node onto your canvas.
Open the node configuration. It will automatically pick up its configuration.
Set the topic following ISA-95 hierarchy:

company/site/area/line/cell/device/measurement

For Example:

acme/plant-a/assembly/line1/press-1/pressure01/bar

Why ISA-95 for MQTT Topics

The ISA-95 Equipment Hierarchy Model is an international standard that defines how to organize manufacturing operations into logical layers. When you structure MQTT topics using this model, you're building toward a Unified Namespace (UNS)—a single, consistent way to organize all operational data across your entire organization.

The goal of UNS is to eliminate data silos. Instead of each system maintaining its own proprietary structure, everything publishes to one shared namespace using a common hierarchy. Applications subscribe to exactly the data they need without knowing where it physically comes from or how it was collected.

ISA-95 makes this possible because it maps to how factories actually operate. company/site/area/line/cell matches your organizational structure. When you expand to new facilities or add equipment, the hierarchy extends naturally. Analytics tools can compare performance across sites. MES systems subscribe to production line data. Dashboards pull from specific cells. Everything uses the same addressing scheme.

This enables powerful wildcard subscriptions:

acme/# - all company data
acme/chicago/# - single site
+/+/assembly/# - assembly operations everywhere
acme/chicago/assembly/line2/# - one production line

Note: Use lowercase with hyphens for multi-word names.

Set QoS to 1.
Click Deploy.

After deploying the flow, the MQTT client for your device will be automatically created. To configure access:

Double-click the MQTT Out node.
Click Configure Access Control. You will be redirected to the platform's broker client management section, filtered to show the client created for this instance.

Configure MQTT Client Access Control

Click the client edit, select Publish, and then click Confirm.

Configure MQTT Client Access Control

That's it. You now have PLC data flowing to MQTT with proper access controls configured and a topic structure that scales with your organization. To view the topic hierarchy and the schema for your topics, go to the FlowFuse Broker section. Here, you'll see all the topics within your MQTT broker. By clicking Open Schema, you can view the auto-generated schema document created by FlowFuse.

FlowFuse Topic Hierarchy View

Topic schema auto-generated by FlowFuse

Bridging the Expertise Gap and Cutting Costs

Now let's talk about the remaining problems: the expertise gap and cost. FlowFuse solves both by changing how the work gets done.

Plant engineers configure PLC connections, transform data, contextualize it, and send it to MQTT through drag-and-drop interfaces without writing code—that's what you saw in the steps above. IT teams manage security and access controls through standard web tools. Neither needs expertise in the other's domain.

The FlowFuse Expert fills remaining gaps—describe what you need in plain English, and it generates function nodes, database queries, or dashboard components. Click "Explain" on any flow to get instant documentation.

This eliminates the consultant dependency that inflates project costs. Your team handles implementation and maintenance without external help at $150-$250 per hour, saving $12,000 to $30,000 on setup alone. The managed MQTT broker includes unlimited messaging with no per-message fees. Protocol drivers are free and open-source with no per-tag licensing. Deploy on existing industrial hardware instead of buying $10,000 proprietary gateways.

Manufacturers typically see substantial cost reduction in the first year, with improving economics as you scale since hardware and licensing costs stay eliminated. Most engineers ship production flows in their first session.

Get Started

Connect your first PLC today. Sign up for FlowFuse, install the Device Agent on your edge hardware, and have data flowing to MQTT in under an hour. The platform handles the complexity—you focus on turning factory data into insights.

FlowFuse 2.23: MCP and ONNX nodes, FlowFuse AI Expert on the homepage, Application-level Permission Control, FlowFuse Expert for Self-Hosted, and more!

2025-10-23T00:00:00Z

In this exciting release, we've shipped several features that accelerate development in Node-RED using AI, enable creation of AI agents using new Model Context Protocol nodes, provide application-level access controls for much more sophisticated user permissions management, and put an expert flow creator right on our homepage. It's a big one! Let's have a look.

MCP Nodes

[MCP nodes in the Node-RED palette, ready for use]

With this release, you can now create a Model Context Protocol server using Node-RED. The new MCP nodes enable the creation of a MCP server so that you can create AI agents that will rely on the exact data that you want to surface to an LLM. As AI services rely upon data presented to them, whether it's anything available on the world wide web (as with LLMs generically) or more focused information, our MCP nodes provide the ability to expose specific resources so that an AI service will rely upon the right data without making all of your information public. It's a really exciting development. Check out the Changelog entry for more.

FlowFuse AI Nodes

While MCP makes it possible to create AI agents to rely on the data you have chosen, the new FlowFuse AI nodes allow you to connect AI models of your choosing--including ones that you have trained yourself--to Node-RED to create any workflow you like. The ONNX (Open Neural Network Exchange) format lets you connect a model for whatever purpose you have in mind. This package ships with nodes for running your own custom-trained model, for classifying images, for object detection, and for image depth estimation. This is a huge step in the direction of fully-controlled AI automation inside of Node-RED on FlowFuse.

For self-hosted customers, once you've upgraded, contact FlowFuse Support to get access to these exciting new nodes.

Application-Level Role-Based Access Control

[Control permissions at the application level]

One of the key features of FlowFuse is the ability to manage Node-RED applications by choosing who gets access to what. Up to now, team owners had to configure permissions at the team level. But what if there are members of your team that should have write permissions to one Node-RED instance, but only viewer access to another? You would have to put those instances on different teams and configure permissions there. With many instances and applications, this could be a headache.

We've solved it. You can now manage permissions at the Application level. Now one and the same team can have users who can access some applications with one level of permissions, and and another application with a different level. We've heard your feedback on this need and are happy for you to give it a try!

FlowFuse Expert

[The FlowFuse Expert gives step-by-step instructions for building flows]

You can now get complete instructions for building a Node-RED flow on flowfuse.com using the FlowFuse Expert! This newest feature in the FlowFuse AI toolkit provides detailed guidance on creating Node-RED flows for any purpose you have in mind.

Head over to flowfuse.com to check it out! We have big plans in mind for this feature, but can't say much yet. For now, it's enough to say that low code development is headed toward a whole new level with FlowFuse.

FlowFuse Expert for Self Hosted Deployments

Speaking of AI assistance, self-hosted FlowFuse deployments have until now not had access to the FlowFuse Expert inside of Node-RED, helping to complete flows using natural language for explanation of flows, creation of Dashboard, Function, and Tables nodes, and Snapshot descriptions. These had been available only to FlowFuse Cloud customers. I'm happy to say that our many self-hosted customers now (finally) can get access to this tool, which helps speed flow creation exponentially. Contact FlowFuse Support to help get you setup.

Import JSON at Instance Creation

Developers want the fastest way to spin up a functional Node-RED instance, and we've taken another step in that direction by offering the option of uploading a JSON file during the instance creation workflow.

Sneak Peek

What if you could surface your FlowFuse Tables data outside of the FlowFuse environment, for broader consumption as you see fit? Or use data coming into Node-RED to predict maintainance needs? We have exciting things on the way for you!

Don't Miss Node-RED Con 2025!

While not exactly a release item, I'd be remiss if I failed to mention Node-RED Conference 2025! We've got a great lineup of speakers who will cover a broad and deep variety of topics on the use of Node-RED. Check out the website and register here: https://nrcon.nodered.org/.

What else is new?

For a complete list of everything included in our 2.23 release, check out the release notes.

Which of these new features are you most excited to try? Email me directly at greg@flowfuse.com - I'd love to hear from you!

Try FlowFuse

FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

Get started for free and have your Node-RED instances running in the cloud within minutes.

Self-Hosted

Get FlowFuse running locally in under 30 minutes using Docker or Kubernetes.

How to Log PLC Data to CSV Files

2025-10-22T00:00:00Z

CSV files have been recording manufacturing data since the mid-1980s, over 40 years of continuous use across every industry. Logging to databases like InfluxDB, TimescaleDB, or PostgreSQL is excellent for real-time analytics, complex queries, and large-scale operations. But many organizations still rely on CSV files for good reasons: regulatory compliance, legacy system integration, offline analysis, or simply because it's the format their teams know and trust. If you're reading this, you're likely one of them and need a reliable solution.

CSV files offer something databases can't always guarantee: universal compatibility and permanence. Excel opens them instantly, databases import them natively, and analysis tools expect them. No licensing, no vendor tie-ins, no format obsolescence. Data captured decades ago is still perfectly readable today and will be readable decades from now, regardless of what systems you're using.

The truth is, most manufacturers use both for distinct purposes. CSVs remain the standard on the shop floor for data loggers that write locally during network outages, regulatory submissions requiring immutable audit trails, batch documentation archived for decades, and data exchange with suppliers and auditors.

Meanwhile, databases handle real-time monitoring and automated alerts, cross-functional analytics, high-frequency sensor queries, and dynamic relationships across materials and equipment.

This isn't an either/or choice. It's a dual-track system where databases provide operational speed and CSVs provide the permanence layer, ensuring your compliance records and critical data outlive any technology stack. This guide shows how to implement PLC data logging with FlowFuse in a way that keeps running, stable, resilient, and production-ready.

Image showing FlowFuse collecting data from a PLC using OPC UA and logging it to a CSV file.

Prerequisites

Before getting started, make sure you have:

A running FlowFuse instance – If you don’t have one yet, sign up for FlowFuse and set up an instance on your edge device. This device will manage data collection and logging from your PLC using Node-RED.

Step 1: Setting Up PLC Communication in FlowFuse

Before logging data, you need a stable connection to your PLC. FlowFuse uses Node-RED under the hood, which supports every major industrial protocol through community-maintained packages. This means you can connect to any equipment—regardless of age or manufacturer.

Choosing Your Protocol

The right protocol depends on what your PLC supports.

Modern PLCs typically offer open standards like OPC UA, Modbus TCP, or EtherNet/IP. These protocols work across different manufacturers and give you the most flexibility.

If your PLC supports OPC UA, that is likely your best option. It is becoming the common language across industrial equipment—Siemens, Rockwell, Schneider, and most other manufacturers support it. This is also the option I used in the demo I prepared for this article. For more information on how to use OPC UA with your PLC, you can refer to this article.

Legacy systems use vendor-specific protocols: S7 for Siemens, MC Protocol for Mitsubishi, FINS for Omron, and EtherNet/IP for Allen-Bradley. If your PLC only speaks its native language, Node-RED has dedicated nodes for each one.

Installing the Right Node

Node-RED's package ecosystem includes nodes for virtually every industrial protocol. The most common ones are:

node-red-contrib-modbus – Modbus RTU/TCP devices
node-red-contrib-s7 – Siemens S7-300/400/1200/1500
node-red-contrib-opcua – OPC UA servers
node-red-contrib-cip-ethernet-ip – Allen-Bradley PLCs
node-red-contrib-mcprotocol – Mitsubishi Q/L series
node-red-contrib-omron-fins – Omron PLCs

To install a package in FlowFuse, go to the palette manager (hamburger menu → Manage palette → Install) and search for the node you need. Installation takes seconds.

Configuring Your Connection

Drag the appropriate input node onto your canvas and configure it according to the node's documentation.

Verifying Data Quality

Before building your logging flow, verify you're getting clean, consistent data. Connect a debug node to your PLC input, deploy, and watch the incoming messages.

You should see values updating at your configured interval with consistent structure and sensible numbers. No connection errors, timeouts, or garbage data.

If something's wrong—intermittent connections, bad values, protocol errors—fix it now. Connection problems multiply when you add logging logic on top.

A stable PLC connection is the foundation. Get this right, and the rest is straightforward.

Step 2: Building the Basic CSV Logging Flow

With a stable PLC connection verified, you can now build the flow that writes data to CSV files.

Understanding the Data Flow

The logging system needs four components working together:

PLC input node that collects data at regular intervals
Function node that adds timestamps and handles daily file rotation
CSV node that formats data into proper CSV structure
File node that writes to disk

Adding Timestamps and Daily File Rotation

Your PLC data needs timestamps and a way to organize files by date.

Drag a function node onto your canvas
Connect it to your PLC input node
Double-click the function node and add this code:

const now = new Date();
const timestamp = now.toISOString();

// Create filename with today's date (YYYY-MM-DD format)
const dateStr = now.toISOString().split('T')[0];
const filename = `./plc_data_${dateStr}.csv`;

// Structure the data
msg.payload = {
    timestamp: timestamp,
    temperature: msg.payload.temperature,
    pressure: msg.payload.pressure,
    flowRate: msg.payload.flowRate
};

// Store filename for the file node
msg.filename = filename;

return msg;

Click Done

This creates a new file each day automatically. When the date changes, the filename changes, and Node-RED starts writing to a fresh file. Your logs stay organized by date: plc_data_2025-10-16.csv, plc_data_2025-10-17.csv, and so on.

Formatting Data with the CSV Node

The CSV node handles all the formatting work—proper escaping, column ordering, and headers.

Drag a CSV node onto your canvas
Connect it to your function node
Double-click to configure:
- Set the columns: timestamp,temperature
- Enable "first row contains column names"
- Choose comma as the separator
- Choose RFC 4180 as parser (this handles commas in your data—like alarm messages or status text—by wrapping them in quotes so they don't break the CSV structure)
Click Done

Image showing CSV node configuration

The CSV node converts your data object into a properly formatted CSV line with headers included automatically when a new file is created.

Writing to File

The file node writes your formatted CSV data to disk.

Drag a file node onto your canvas
Connect it to your CSV node
Double-click to configure:
- Set filename to msg.filename (uses the dynamic filename from your function)
- Choose "append to file" mode
- Enable "Create directory if it doesn't exist"
Click Done
Deploy your flow

Image showing Write node configuration

Let it run. Each day at midnight, the system automatically starts a new file. Old files stay untouched, new data goes to today's file.

This daily rotation keeps file sizes manageable and makes it easy to find data from specific dates. But there are still edge cases to handle—what happens when disk space runs low or file writes fail? The next step addresses these reliability issues.

Step 3: Monitoring Disk Usage

Running a logging system continuously means files accumulate. Monitor disk space to prevent unexpected failures when storage runs low.

Add disk space monitoring to prevent unexpected failures.

Drag an inject node onto your canvas and configure it to trigger every hour
Add a Function node with the following code. Since the code uses the fs module, make sure to import it within the setup of function node:

try {
    // Get disk usage information
    const stats = fs.statfsSync('./');

    const totalSpace = stats.blocks * stats.bsize;
    const freeSpace = stats.bfree * stats.bsize;
    const usedSpace = totalSpace - freeSpace;
    const percentUsed = (usedSpace / totalSpace) * 100;

    msg.payload = {
        totalGB: (totalSpace / (1024 ** 3)).toFixed(2),
        freeGB: (freeSpace / (1024 ** 3)).toFixed(2),
        usedGB: (usedSpace / (1024 ** 3)).toFixed(2),
        percentUsed: percentUsed.toFixed(2)
    };

    // Warning threshold
    if (percentUsed > 90) {
        msg.warning = `Disk space critical: ${percentUsed.toFixed(1)}% used`;
    }

    return msg;

} catch (err) {
    msg.payload = { error: err.message };
    return msg;
}

Connect it to your notification system to alert when space is critical, for notification you can use email, telegram, discord with FlowFuse.
Deploy the flow

Now you'll get warnings before disk space becomes critical, giving you time to archive old data or expand storage.

Step 4: Handling Connection Interruptions

Network issues, PLC restarts, or equipment maintenance can cause connection drops. Your logging system should handle these gracefully and automatically resume when the connection is restored.

Most PLC nodes emit error events when a connection fails. Add error handling to detect and log these events.

Add a Catch node configured to monitor your PLC input node and Write File node.
Drag a Function or Change node to format the error messages according to your chosen notification method, and connect it to the Catch node.
Connect the node that formats the error message to your selected Notification node.
Deploy the flow.

Below is the complete flow we have built throughout this article.

Note: When testing with the Inject node, bypass the OPC UA Client and inject data directly into the logger flow.

Conclusion

You now have a production-ready PLC data logging system built on FlowFuse. It addresses the key reliability issues that typically cause downtime — connection drops, write failures, disk space limits, and daily file rotation — turning a simple flow into one that can run unattended for months.

The use of CSV ensures long-term data accessibility. Every analytics platform, database, and spreadsheet can read it, and it will remain usable decades from now — regardless of what tools or systems you adopt in the future.

Start small: connect one PLC, verify data quality, and deploy your first logging flow. Then gradually add error handling, storage monitoring, and redundancy as needed. Over time, this setup becomes a foundation for scalable, dependable industrial data collection.

FlowFuse makes this process straightforward by combining Node-RED’s flexibility with enterprise-grade management and monitoring. You can deploy updates remotely, manage devices across multiple sites, and standardize data collection — all from a single platform.

And while CSV is a reliable starting point, FlowFuse also integrates seamlessly with modern databases and historians like InfluxDB, TimescaleDB, and MySQL. Even better, FlowFuse Cloud includes a built-in PostgreSQL service and an AI Query Node that lets you explore your data conversationally — turning raw logs into actionable insights.

You can talk to our team, they’ll walk you through a live demo showing how FlowFuse helps you connect, collect, transform, and visualize your industrial data reliably and intelligently.

Introducing FlowFuse Expert

2025-10-16T00:00:00Z

We've had an exciting week launching MCP and ONNX nodes, and now we’ve added something else we're really excited about: FlowFuse Expert. It helps you build flows by providing a step-by-step recipe to build an application in FlowFuse and Node-RED, in plain language.

Oh, and it was created by and is running on FlowFuse technology! Take a look:

Instead of hunting through documentation or piecing together forum posts, you simply describe what you want to build and get a clear recipe for creating it.

Head over to flowfuse.com and you'll see it right on the home page. Type what you're trying to build. FlowFuse Expert might ask a few questions to clarify your setup, and once you answer, it will provide a simple, easy-to-follow recipe: which nodes you need with exact copyable names, how to configure them, and how to wire them together.

FlowFuse Expert: Providing a Recipe for Connecting Serial Devices

Down the road, we plan to integrate it directly into the FlowFuse environment. So if you're already using FlowFuse Expert to speed up your development, FlowFuse Expert will be right there alongside it, answering questions and providing recipes for whatever you're trying to build.

Why We Built This

We kept seeing people get stuck at the same point. They were excited about FlowFuse and Node-RED, with a clear idea of what they wanted to build, but weren't sure how to get started.

That gap between vision and implementation shouldn't be a bottleneck, nor should time be wasted reading long documents or articles. FlowFuse Expert provides the starting point, the specific guidance you need to start building, without dumbing anything down.

How It Works

FlowFuse Expert is built on and runs entirely using FlowFuse technology itself. It is powered by RAG + GPT-4.1. We've ingested all of our blogs, changelogs, and documentation into a vector database. When you describe what you want to build, FlowFuse Expert searches this knowledge base and uses that context to generate accurate, and super simple step-by-step instructions.

Try FlowFuse

FlowFuse Expert is just one of the many powerful tools we’ve made available to everyone. With FlowFuse, you can deploy, scale, and manage Node-RED effortlessly, accelerate development with FlowFuse AI-assistance, and build your own MCP server. Let AI agents monitor and control industrial applications using MCP nodes—or run your custom AI models in Node-RED with ONNX nodes.

Start your free FlowFuse trial today and see how you can deploy, manage, and scale secure Node-RED to build powerful industrial applications while exploring the new AI tools we’ve made available for FlowFuse users within Platform.

Building MCP Servers for AI Agent Integration in Node-RED with FlowFuse

2025-10-14T00:00:00Z

FlowFuse released MCP nodes for Node-RED, allowing AI to directly interact with the flows you have built. These nodes let AI read sensor data, query databases, and control equipment. You use FlowFuse to collect and manage data in your flows, while AI agents determines what actions to take and why, enabling intelligent monitoring and automated control of factory and IIoT/IoT systems.

This article explains how to build an MCP server with FlowFuse and connect AI to your systems for real-time insights, operational decisions, and automated control.

What Is MCP?

The Model Context Protocol (MCP) is an open standard that enables AI assistants to access data and execute actions across external systems.

MCP works through three key components. Resources give AI visibility into your operations through read-only access to sensor data, database records, SCADA tags, and equipment logs. This real-time information helps AI understand what's actually happening on your factory floor or in your IIoT environment.

Tools let AI perform specific actions in your systems. These might include adjusting equipment parameters, triggering maintenance alerts, or generating operational reports. Each tool clearly defines what it needs as input and what it will produce as output, which keeps operations predictable and safe.

Prompts are workflow templates that guide AI through more complex tasks. They show AI how to use multiple resources and tools together to complete multi-step operations. This is particularly valuable when you need AI to follow established procedures rather than improvising solutions.

When you connect an AI agent to your MCP server, it discovers all available resources and tools automatically. The protocol handles the technical details of data requests and action execution, so AI can start working with your industrial systems right away. You build your flows in Node-RED, and AI learns how to interact with them intelligently through the MCP interface.

Getting Started

This section guides you through setting up an MCP server, defining resources, and creating tools so AI can interact with your system.

Prerequisites

Before you begin, ensure you have the following:

A running FlowFuse Enterprise instance. If you do not have one, contact us to discuss Enterprise options and get started.
Ensure the @flowfuse-nodes/nr-mcp-server-nodes package is installed. This will add the MCP nodes to your Node palette in your instance editor.

Note: The MCP nodes (@flowfuse-nodes/nr-mcp-server-nodes) are only available on the Enterprise tier.

Configuring the MCP Server

Before defining resources or tools, the MCP Server must be configured. This server acts as the central endpoint for AI agents, ensuring all resources and tools are accessible under a single, consistent configuration.

Drag an MCP Resource or Tool node onto your workspace and click the + next to Server to create a new configuration.
Define the server properties:
- Name: Enter a descriptive name, e.g., Node-RED MCP Server.
- Protocol: Leave the default http/sse (currently the only option).
- Path: Specify the endpoint path for the server, e.g., /mcp.

Caption: Configuring the MCP Server in Node-RED

Click Done to save the server configuration.

Once the server is configured, clients can connect using a URL. The URL to connect with is your instance URL plus the MCP path you configured, for example:

https://your-instance.flowfuse.cloud/mcp

or if you are running FlowFuse Node-RED instance locally, use the host, port, and MCP path of your instance, for example:

http://localhost:1880/mcp

http://192.168.1.100:1880/mcp

This URL allows AI agents to discover resources, execute tools, and interact with your flows.

Securing Your MCP Server

To ensure your MCP server is protected from unauthorized access, enable FlowFuse User Authentication.

Navigate to your instance Settings → Security tab
Select FlowFuse User Authentication, click Save Changes, and in the popup, click Restart to apply the changes.

FlowFuse User Authentication settings screenshot

Click Add Token and provide a descriptive name for identification
Set an expiry date (recommended for enhanced security)
Click Create and copy the generated token

When connecting to your MCP server from a client, include the token in the request headers:

{
  "node-red-mcp-server": {
    "url": "http://localhost:1880/mcp",
    "type": "http",
    "headers": {
      "Authorization": "Bearer ffhttp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    }
  }
}

Replace ffhttp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx with your actual token. This ensures that only authorized clients can access your MCP server resources and tools.

UPDATE: FlowFuse Expert now allows you to connect directly with your MCP Resources and Tools, so you don't need to connect external AI agents anymore.

You'll need to select the MCP server you want to connect to in the FlowFuse Expert Insights tab. Once connected, FlowFuse Expert will automatically query your Resources and execute your Tools based on your team role and your instructions. The annotations you configure in the MCP Tool node (read-only, destructive, idempotent, open-world) integrate with FlowFuse's role-based access control to ensure secure, appropriate access for every team member.

Defining an MCP Resource

Now let's start by defining a Resource. In MCP, a Resource represents a data source that you want to expose to an AI agent. In an industrial context, this could be a sensor value, a machine's status, or a list of production lines.

Drag the MCP Resource node from the palette onto your workspace.
Double-click the node to open its configuration panel and select the added mcp server configuration.
Enter the unique id for the resource, for example : "all-production-lines"
Provide a unique URI for this specific resource, for example, mcp://monitor-all-production-lines Make sure your every resource must have a unique URI.
Enter a clear, human-readable title, like "Monitoring All production lines". This is the name the AI agent or client that will connect will see, so make it descriptive.
Give the node a descriptive name for your flow, such as Production Lines Resource, and enter a brief description.

Setting up an MCP Resource in FlowFuse

Click Done and then Deploy your flow.

At this point, your MCP server is live and resource is discoverable. However, it doesn't contain any data yet.

To expose data you will need to connect the MCP Resource node to any data-producing node in your flow. This could be an HTTP Request node retrieving data from an API, a FlowFuse Query node for fetching records from a FlowFuse data table, industrial connectors such as OPC UA Read, Modbus Read, PLC Read nodes.

Next, drag the MCP Response node and connect its input to the output of the upstream data source node.

The MCP Response node is crucial because it delivers the results of your flow back to the AI agent. Without it, the AI will not receive the data it requests. Any errors are also fed back to the MCP Response node, enabling the AI to handle them appropriately.

Deploy the flow

Now, when an AI agent or any other client requests this URI, the flow will automatically execute and query your data source for the latest information. This data is then returned to the agent, providing it with the real-time context needed to answer your questions.

Example: Monitoring Production Lines

For this article, we've built a demonstration data flow. We have a table named production-lines where new data is inserted every five seconds from 10 different lines.

We then created a data resource and exposed all the line data to it. Now, let's connect a AI Agent to this resource and explore the kinds of questions we can ask to monitor the factory floor effectively.

Production line monitoring using MCP Resources

Defining an MCP Tool

While resources are useful for providing access to data, tools enable an AI agent to perform specific, parameterized actions within your system.

Drag the MCP Tool node from the Node-RED palette onto your workspace.
Double-click the node to open the configuration panel and select the MCP Server configuration you previously created.
Enter a tool name that will be visible to clients connecting to the MCP server, such as Maintenance or Maintenance Scheduler.
Next, set annotations. Annotations help AI clients understand your tool's behavior and control which FlowFuse team members can access it based on their role (Viewer, Member, or Owner).
- Read-Only Hint: Tool only reads data, doesn't modify anything. Safe for exploratory queries.
  - Access: Viewer role and above
- Destructive Hint: Tool may delete or irreversibly modify data. Use with caution.
  - Access: Owner role only
- Idempotent Hint: Calling the tool multiple times with same parameters has the same effect as calling it once. Safe to retry.
  - Access: No effect on roles (only relevant for writing tools, which require Member minimum)
- Open-World Hint: Tool interacts with external systems or data sources that may change unpredictably.
  - Access: Member role and above
Note: These are hints only and do not enforce behavior. The actual behavior of a tool is determined by your Node-RED flow implementation. Annotations are used by FlowFuse for role-based access control (RBAC) and FlowFuse Expert. They are also part of the standard MCP specification and can be consumed by external agents, but their effect ultimately depends on the client's implementation.
Provide a clear description of the tool's purpose, and assign a descriptive name to the node within your flow.

Define the input schema in JSON format. This schema helps the AI understand what data is required to perform the action and also validates incoming requests. For detailed guidance, refer to the Getting Started Guide.

Tip: You can also use the FlowFuse Expert to generate the JSON schema automatically. Just click Ask FlowFuse Expert in the input schema field and describe the expected input in plain English.

Below is an example schema for a Tool node. It shows how data is defined, its type, and which fields are required along with minimum lengths:

{
  "type": "object",
  "properties": {
    "line": {
      "type": "string",
      "description": "The production line where maintenance is required",
      "minLength": 1
    },
    "description": {
      "type": "string",
      "description": "Description of the maintenance task",
      "minLength": 1
    },
    "priority": {
      "type": "string",
      "description": "Priority of the task",
      "enum": [
        "Low",
        "Medium",
        "High"
      ]
    }
  },
  "required": [
    "line",
    "description",
    "priority"
  ]
}

Setting up an MCP Tool in FlowFuse

Click Done, then deploy your flow.

At this stage, the tool becomes discoverable by connected AI clients. However, it will not perform any action until it is linked to a flow that executes a task, such as an HTTP Request node performing a POST operation, a Query node inserting data into a database, or an OPC UA Write node controlling a device.

Drag the MCP Response node and connect its input to the output of the final node in your action flow.

The MCP Response node is necessary because the AI needs to receive the outcome of the action—whether it was successful or not. Errors are also fed back to the MCP Response node, enabling the AI to handle them appropriately.
Deploy the flow once again.

Your MCP Tool is now active. When an AI agent invokes it, the connected flow executes the defined action and returns the result to the agent.

Example: Scheduling Maintenance for Production Lines

In this example, the flow includes a tool that triggers a POST request to the maintenance system API, which was developed using FlowFuse and the FlowFuse Dashboard. The AI Assistant was then asked to identify which production line was performing the worst and schedule a maintenance task for it.

AI agent scheduling maintenance using an MCP Tool

Below is the flow that includes the Resource we created to monitor production lines and the Tool that sends a POST request.

Note: The flow uses the FlowFuse Query node and FlowFuse tables, which are only available on the Enterprise tier. If you do not have Enterprise, you can use other data sources instead, such as HTTP Request, OPC UA, or other database nodes.

If you need more example flows, you can import the examples that come with the MCP nodes. Click the main menu from the top right, click Import, switch to Examples, and look for @flowfuse-nodes/nr-mcp-server-node, then select mcp_server and click Import. If you prefer a video tutorial, watch this video tutorial on YouTube.

With your MCP server, Resources, and Tools in place, the AI agent can now interact with your industrial systems in a structured way. Up to this point, we've covered the basics and demonstrated a simple workflow. The MCP Prompt node, which allows AI agents to be guided through complex, multi-step tasks, will be explored in a future article.

Conclusion

This guide demonstrated how to build a fully functional MCP server with FlowFuse and Node-RED, providing AI agents with structured access to industrial systems through Resources and Tools, which enable workflows such as monitoring production lines, scheduling maintenance, and automating operational decisions — all without complex coding.

FlowFuse recently added ONNX AI nodes. With these nodes, you can train custom models, deploy them in Node-RED, and execute tasks tailored to your processes. Combined with FlowFuse’s capabilities to collect, transform, and visualize industrial data, the platform makes development, monitoring, and optimization faster, smarter, and more scalable.

Adopting MCP with FlowFuse is a strategic step toward AI-enabled, future-ready industrial automation. Book a demo today to see how FlowFuse connects, transforms, and visualizes your industrial data while making AI-driven operations easy and actionable.

MCP and Custom AI Models on FlowFuse!

2025-10-13T00:00:00Z

We have a VERY exciting announcement today: you can now build an MCP server and upload custom-trained AI models to FlowFuse!

AI on FlowFuse

Node-RED is already the most capable and flexible low-code development environment out there. FlowFuse makes it secure, robust, and scalable.

As of today, you can now use FlowFuse to create your own MCP server and use custom-trained AI models that you've built for any application.

Build an MCP server to create an AI agent that will do whatever you've design it to do. And add a training model that you've built using your own training data, so data processing works exactly the way you want it to.

Model Context Protocol

LLMs were trained by scraping data from the internet to build data models that can complete a task (like answering a question or writing a blog article -- but not this one!) given some input prompt. When you rely on an LLM to answer questions that are very general or perform operations that are rather straightforward, LLMs can generally do so with ease.

However, if you want to do something more sophisticated, or create an AI agent that will rely on specific data, that data needs to be presented to the AI somehow. MCP is what enables that.

Instead of relying just on LLMs trained from scraping the entire internet, the new MCP nodes enable you to create your own MCP servers, so you can present information to an AI tool, putting much more power and control in your hands as a developer.

You are now able to create your own, custom AI agent using FlowFuse.

Custom Data Models

When creating an AI agent or getting AI assistance with some task, one component is the data that is surfaced to the model. That part is handled by MCP. Another part is how the model interacts with that data. That part is handled with our new AI nodes.

Instead of relying on a standard LLM, even one that has been set up to connect with an MCP server, it is possible to train the model itself. The new AI nodes allow you to train a custom model, put it in ONNX format, and connect it to Node-RED, where it can be deployed to run any operation you wish with your new, personally-trained AI.

The Sky Is the Limit

The flexibility of Node-RED, the reliability of FlowFuse, and the customizability enabled by these MCP and AI nodes means you can build just about any AI application you wish!

And this week, we're going to tell you all about it. Stay tuned for a demo or three, some tutorials, and overall plenty of instructional content goodness that will demonstrate the power that is now available with these AI releases!

While we're at it, we are also going to unveil a new feature right on our home page: a trained FlowFuse Expert (AI) that will teach you how to build applications in FlowFuse and Node-RED!

Try it Now

Ready to try out these new nodes? If you're new to FlowFuse, create a trial team. Then, head to Manage Palette (in the hamburger menu on the right side of the Node-RED editor), click Install, and in the dropdown menu, choose FlowFuse Nodes to see the catalog of nodes that are exclusive to FlowFuse customers. From here, you can install both the MCP nodes and AI ONNX nodes.

If you're an existing FlowFuse user, begin by restarting the Node-RED instance where you want to use the nodes, then follow the same instructions as above.

EtherNet/IP Integration with FlowFuse: Communicating with Allen-Bradley PLCs

2025-10-10T00:00:00Z

EtherNet/IP is one of the most widely used industrial communication protocols for connecting PLCs, sensors, and controllers across manufacturing environments. If you're working with Allen-Bradley PLCs—whether it's ControlLogix, CompactLogix, or MicroLogix—you're using some of the most trusted automation hardware in the industry.

This guide will show you how to integrate Allen-Bradley PLCs with FlowFuse using EtherNet/IP. While the focus is on Allen-Bradley, the same Node-RED nodes and techniques also work with other EtherNet/IP-compatible PLCs, such as Omron and Automation Direct. You will learn both connected and unconnected messaging modes, so you can choose the approach that fits your setup. By the end of this guide, your PLCs will be communicating with FlowFuse (Node-RED with enterprise capabilities), enabling you to build powerful industrial automation workflows.

Prerequisites

Before integrating your Allen-Bradley PLC with FlowFuse, ensure you have the following:

PLC Configuration:

Your Allen-Bradley PLC (ControlLogix, CompactLogix, or MicroLogix) should be properly configured and operational.
Ensure that the appropriate ladder logic program is written according to your requirements and successfully downloaded to the PLC.
Verify that the controller tags or data structures you want to access are properly defined.
Note the PLC's IP address and slot number (typically slot 0 for the processor).

Node-RED:

Install Node-RED on the device that will communicate with the Allen-Bradley PLC. You cannot install Node-RED directly on the PLC, as PLCs are controllers, not computers. You can use devices like the Raspberry Pi, Revolution Pi, or industrial PCs to connect and transfer data across systems.
Use the FlowFuse Device Agent to install Node-RED on your edge device.

Why FlowFuse Device Agent? FlowFuse provides Node-RED with enterprise capabilities like remote management, team collaboration, device management, and DevOps pipelines—essential features for scaling industrial automation across your organization. These capabilities help streamline operations and ensure reliability in complex manufacturing environments. Sign up for free to get started.

Network Setup:

Verify that the device running Node-RED is on the same network as the PLC and can successfully ping the PLC's IP address.
Ensure the PLC is properly connected to the network via Ethernet with a static IP address configured.
Ensure that firewalls do not block EtherNet/IP communication (typically port 44818 for both TCP and UDP).

Understanding EtherNet/IP Communication Modes

EtherNet/IP is an industrial network protocol widely used to communicate with Allen-Bradley and other PLCs over Ethernet. It allows devices to exchange data efficiently and reliably, making it a common choice for industrial automation systems.

EtherNet/IP supports two primary communication modes: connected and unconnected messaging. Your choice depends on how frequently you need to communicate with the PLC, the number of available connection resources, and—most importantly—what your PLC actually supports. Not all PLCs support both modes. For example, Allen-Bradley Micro800 series PLCs only support connected messaging, while ControlLogix and CompactLogix typically support both.

Connected Messaging

Connected messaging establishes a persistent session between Node-RED and the PLC using the Forward Open protocol. Once connected, data flows continuously with minimal overhead, making it ideal for real-time monitoring and high-frequency updates. The advantage is speed—after the initial handshake, communication is fast and efficient. The tradeoff is that each session consumes one of the PLC's limited connection slots, typically ranging from 8 to 32 depending on the model.

Connected messaging itself can operate in two ways:

Without Routing (Direct Connection): Used for PLCs that connect directly via Ethernet without backplane routing, such as the Allen-Bradley Micro800/850/870 series. Only the IP address is needed—no slot number or routing path is required.

With Routing: Used for chassis-based PLCs like ControlLogix and CompactLogix, where the processor sits in a backplane slot. In this case, the slot number must be specified, as it automatically creates a routing path through the backplane to reach the processor.

Unconnected Messaging

Unconnected messaging sends individual requests without maintaining a persistent connection. Each transaction is standalone—request, response, done.

This approach doesn't consume connection slots, making it ideal when resources are limited or when multiple systems need occasional PLC access. The downside is higher overhead per message, resulting in slower performance compared to connected mode.

In practice, use connected mode for frequent polling and unconnected mode for occasional reads or writes—but always check your PLC's documentation to confirm which modes are supported.

Installing the EtherNet/IP Node

To communicate with Allen-Bradley PLCs from FlowFuse, use the popular node-red-contrib-cip-ethernet-ip node, which supports both connected and unconnected messaging modes.

Open your FlowFuse Instance Node-RED editor in a web browser.
Click the main menu (three horizontal lines) in the top-right corner.
Select "Manage Palette" from the menu.
Switch to the "Install" tab and search for node-red-contrib-cip-ethernet-ip.
Click "Install" next to the node name.
Wait for the installation to complete.

Once installed, you'll find the EtherNet/IP nodes in your palette under the "plc" category. The main nodes are ethernet-ip in for reading data and ethernet-ip out for writing data to the PLC.

Configuring the EtherNet/IP Node

Now that you have installed the EtherNet/IP node, it is time to configure the connection to your Allen-Bradley PLC.

Drag any EtherNet/IP node onto the canvas.
Double-click the node to open its configuration panel.
Click the "+" icon next to the "PLC" dropdown to add a new PLC configuration.
Enter the basic connection details:
- Give your connection a descriptive name, such as "Line 1 PLC", for easy identification.
- Enter your PLC’s IP address.
- Specify the slot number where your processor is located.
Configure the communication parameters:
- Cycle time controls how often the node communicates with the PLC (for example, 500 ms means it updates twice per second).
Select the communication mode:
- Standard (Unconnected) — This is the default option supported by most PLCs.
- Connected (With Routing) — Use this option if you want to enable connected messaging with routing.

EtherNet/IP Node Configuration

This node does not currently support connected messaging (without routing). I have developed node — @sumit_shinde_84/node-red-contrib-cip-ethernet-ip-enhanced — which supports connected messaging (without routing) but is still under development.

If you need connected messaging without routing, you can use that node. To enable connected messaging without routing, select Connected (no routing) from the communication mode dropdown in the configuration dialog.

Adding Tags to Read or Write

After configuring the endpoint, you need to specify which tags you want to read from or write to the PLC.

In the same configuration window, switch to the "Tags" tab.
Click the "+Add" button in the top-right corner to add a new tag.
Enter the tag details:
- Name: Enter the exact tag name as it appears in your PLC program (e.g., "Motor1Speed" or "Program:MainProgram.Motor1Speed")
- Type: Select the data type from the dropdown (e.g., BOOL, INT, DINT, REAL, etc.)
Repeat this process for each tag you want to monitor or control. You can add multiple tags that will all use the same PLC connection you configured earlier.

Adding tags to read and write

If your tag belongs to a different scope, click the “+ Add” button at the top to create a new scope. Then, within that scope, add the tags in the same manner.

Once you've added all your tags, click "Add" to save the configuration, then "Done".
Finally, deploy the flow by clicking the "Deploy" button in the top-right corner.

Important: Tag names must match exactly as they appear in your PLC program—they are case-sensitive. Make sure to select the correct data type for each tag to ensure proper communication.

Getting Started

Before we start, I'd like to show you what I've prepared—a flow where I'm sending commands to the PLC to control the stack light. To interact with it, I've built a nice dashboard using FlowFuse Dashboard. Here's a quick demonstration:

That’s the program I have downloaded to the PLC

Program downloaded to the PLC

Now let’s learn how to build a flow that can both read and write data to your PLC.

Writing Data to Your PLC

Writing to a PLC is where things get exciting—this is where you move from monitoring to actually controlling your equipment. Maybe you want to start a motor, adjust a setpoint, or trigger a sequence. Whatever your goal, the process is straightforward.

Drag an ethernet-ip out node onto the canvas.
Double-click the node to open its configuration.
Select the PLC configuration you created earlier from the dropdown.
Select the scope under which you added the tag, choose the tag that you want to write to.

Configuring the EtherNet/IP out node to write data to a PLC tag

Click "Done".
Connect an inject node or any other input node to send data.
Deploy the flow and click inject button to test it.

The node expects the incoming message payload to contain the value you want to write to the tag. Ensure that the value type matches the data type you configured when adding the tag and what the PLC expects.

Reading Single Tag from Your PLC

Reading data from your PLC is the foundation of any monitoring or control system. Whether you're tracking production counts, monitoring temperatures, or checking machine status, you'll start here.

Here's how to set it up:

Drag an ethernet-ip in node onto the canvas.
Double-click the node to open its configuration.
Select the PLC configuration you created earlier from the dropdown.
Select the scope under which you added the tag, select the mode to "Single Tag" and choose the tag that you want to read.

Configuring the EtherNet/IP in node to read a single tag from the PLC

Click "Done".
Connect a debug node to view the data.
Deploy the flow.

The node will automatically read data based on your configured cycle time and output it.

Note: Reading single tags individually isn't recommended for production use as it creates unnecessary network overhead. Consider using "All tags" mode or structuring your PLC with array data types to read multiple values efficiently in one request.

Reading Multiple Tags from Your PLC

Sometimes you need the full picture—not just one data point, but everything that matters for your process. Reading multiple tags at once gives you a complete snapshot of your system in a single message.

Let me show you how:

Drag an ethernet-ip in node onto the canvas.
Double-click the node to open its configuration.
Select the PLC configuration you created earlier from the dropdown.
In the Mode field, select "All tags" to read all configured tags together in a single message, or select "All tags (one per msg)" if you want each tag value sent as a separate message.

Reading all tags with each tag sent as a separate message

Reading all tags together in a single message object

Click "Done".
Connect a debug node to view the data.
Deploy the flow.

The node will automatically read all configured tags based on your cycle time, giving you full visibility into your PLC data.

Next Steps

Now that you've learned how to read and write data with your Allen-Bradley PLC, you can build interactive dashboards to monitor and control your industrial processes. FlowFuse Dashboard makes it easy to create professional interfaces with buttons, gauges, charts, and controls—all without writing complex code.

Check out our Getting Started with Dashboard guide to learn how to build your first dashboard.

Beyond Allen-Bradley

FlowFuse isn't limited to EtherNet/IP. Connect Siemens PLCs via S7, use OPC UA for vendor-neutral communication, integrate Modbus devices, or connect IoT sensors with MQTT. Mix protocols as needed—your factory floor probably isn't single-vendor anyway.

Book a demo to see how FlowFuse connects your entire operation.

Deploy Custom-Trained AI Models: Using ONNX with Node-RED and FlowFuse

2025-10-10T00:00:00Z

FlowFuse is introducing a new set of AI nodes to make it easier than ever to integrate AI and machine learning into your Node-RED workflows. In this guide, you will learn how to train an image classifier model, and use it with the new FlowFuse AI Nodes to recognise your own products, components - or anything else you can imagine.

Introduction

In this article, we will be building a PyTorch-based image classification model to identify fruit types (apple, kiwi, mango) using a dataset of labelled images. Of course, you would typically be classifying your own things like your company widgets and products, but for the sake of learning the process, we will be using images of fruit. Once the model is trained, it is exported to the ONNX format, it is then ready for use with the new FlowFuse AI nodes.

Note: The code and sample dataset used in this tutorial can be downloaded from this link.

Some background first

The process we will use is commonly referred to as "transfer learning". This is where you take a pre-trained model and fine-tune it on your own dataset. This is a common approach in deep learning as it allows us to leverage the knowledge learned by the pre-trained model and adapt it to our specific task with a smaller dataset. For reference, this tutorial will use ResNet-18 which is an 18-layer Residual Network (ResNet), a convolutional neural network (CNN) architecture that uses "skip connections" to help train very deep networks by addressing the vanishing gradient problem. Pre-trained ResNet-18 models are often trained on the ImageNet dataset and are widely used for image classification of 1000 categories.

Overview of operations

The 3 main steps to achieve this involves:

Setting up a Python environment with PyTorch, TorchVision, ONNX, and ONNX Runtime.
Organizing your dataset into train, validation, and test folders for each class.
Perform "transfer learning" to fine-tune the model against your images & generate the ONNX model.

Let's get started...

Setup the environment

Pre-requisites

This tutorial was tested on Ubuntu using Python 3 and pyenv for environment management.

For the sake of brevity, from this point forward, the tutorial will assume you are using a debian based operating system and pyenv. Instructions will need to be adapted if you are using something else.

Python tools

Ensure you have pyenv and pyenv-virtualenv installed.

pyenv --version
pyenv virtualenv --version

If you don't have them installed, this Medium article worked well in our case.

Sub dependencies

During setup and testing, my installation failed at the last step due to missing bz2 support (a TorchVision dependency). If you encounter this, you would need to install libbz2 then you would need to rebuild your python environment. To save time, I recommend that you perform the steps below now to ensure the dependencies are installed and avoid the mis-step.

sudo apt update
sudo apt install -y libbz2-dev liblzma-dev libsqlite3-dev libssl-dev zlib1g-dev libffi-dev build-essential

Virtual Environment Setup

Install python 3.10.14 (or any version compatible with pytorch and onnx):

pyenv install 3.10.14

Create a new virtual environment:

pyenv virtualenv 3.10.14 venv_py3_10_14_pytorch

Activate the virtual environment:

pyenv activate venv_py3_10_14_pytorch

NOTE: Depending on your shell, your commandline may become decorated with the name of the virtual environment.

Install the required packages:

pip install --upgrade pip
pip install torch torchvision onnx onnxruntime matplotlib numpy

Create a working directory

mkdir ~/my-py-projects
cd ~/my-py-projects
mkdir pytorch-onnx
cd pytorch-onnx
# Associate this directory with the virtual env we created earlier
pyenv local venv_py3_10_14_pytorch

(Optional) Create a requirements.txt file to document the packages used in this project:

pip freeze > requirements.txt

Organizing your dataset

For this example, I have created a simple dataset of images of apples, kiwis, and mangos. You can use your own dataset or download a dataset from the internet (e.g. this one or this one). Just make sure to organize the images in the following structure:

data/
    train/
        apples/
            apple1.jpg
            apple2.jpg
            ...
        kiwis/
            kiwi1.jpg
            kiwi2.jpg
            ...
        mangos/
            mango1.jpg
            mango2.jpg
            ...
    val/
        apples/
            apple3.jpg
            apple4.jpg
            ...
        kiwis/
            kiwi3.jpg
            kiwi4.jpg
            ...
        mangos/
            mango3.jpg
            mango4.jpg
            ...
    test/
        apples/
            apple5.jpg
            apple6.jpg
            ...
        kiwis/
            kiwi5.jpg
            kiwi6.jpg
            ...
        mangos/
            mango5.jpg
            mango6.jpg
            ...

Now, inside ~/my-py-projects/pytorch-onnx/ you should have:

pytorch-onnx/
│
├── data/
│   ├── train/
│   │   ├── apples/
│   │   ├── kiwis/
│   │   └── mangos/
│   ├── val/
│   └── test/
│
├── fruit_classifier.py   # we will create this shortly
└── requirements.txt      # optional

Fine-tune the model

Now we can create a simple pytorch model to classify the images.

Create a new file called fruit_classifier.py

# Use nano to create the file (you can use your favorite editor e.g. vim, code, etc)
nano fruit_classifier.py

Add the following code:

# fruit_classifier.py

import torch
import torch.nn as nn
import torch.optim as optim
from torch.utils.data import DataLoader
import torchvision.transforms as transforms
import torchvision.datasets as datasets
import torchvision.models as models
import onnxruntime as ort
import numpy as np

# --- Dataset ---
data_dir = "data"
transform = transforms.Compose([
    transforms.Resize((224, 224)),
    transforms.ToTensor(),
    transforms.Normalize(mean=[0.485, 0.456, 0.406],
                         std=[0.229, 0.224, 0.225])
])

train_dataset = datasets.ImageFolder(f"{data_dir}/train", transform=transform)
val_dataset   = datasets.ImageFolder(f"{data_dir}/val", transform=transform)
test_dataset  = datasets.ImageFolder(f"{data_dir}/test", transform=transform)

train_loader = DataLoader(train_dataset, batch_size=32, shuffle=True)
val_loader   = DataLoader(val_dataset, batch_size=32, shuffle=False)
test_loader  = DataLoader(test_dataset, batch_size=32, shuffle=False)

print("Class mapping:", train_dataset.class_to_idx)

device = torch.device("cuda" if torch.cuda.is_available() else "cpu")

# --- Model ---
model = models.resnet18(weights=models.ResNet18_Weights.IMAGENET1K_V1)
model.fc = nn.Linear(model.fc.in_features, len(train_dataset.classes))
model = model.to(device)

criterion = nn.CrossEntropyLoss()
optimizer = optim.Adam(model.parameters(), lr=1e-4)


# --- Training ---
def train(num_epochs=5):
    for epoch in range(num_epochs):
        model.train()
        running_loss = 0.0
        for inputs, labels in train_loader:
            inputs, labels = inputs.to(device), labels.to(device)

            optimizer.zero_grad()
            outputs = model(inputs)
            loss = criterion(outputs, labels)
            loss.backward()
            optimizer.step()

            running_loss += loss.item()

        avg_loss = running_loss / len(train_loader)
        print(f"Epoch {epoch+1}, Loss: {avg_loss:.4f}")


# --- Evaluation ---
def evaluate(loader):
    model.eval()
    correct, total = 0, 0
    with torch.no_grad():
        for inputs, labels in loader:
            inputs, labels = inputs.to(device), labels.to(device)
            outputs = model(inputs)
            _, preds = torch.max(outputs, 1)
            correct += (preds == labels).sum().item()
            total += labels.size(0)
    return correct / total


# --- Export to ONNX ---
def export_model():
    dummy_input = torch.randn(1, 3, 224, 224, device=device)

    torch.onnx.export(
        model,               # model being run
        dummy_input,         # model input (or a tuple for multiple inputs)
        "fruit_classifier.onnx",    # where to save the model (can be a file or file-like object)
        export_params=True,  # store the trained parameter weights inside the model file
        opset_version=16,    # the ONNX version to export the model to
        do_constant_folding=True,  # whether to execute constant folding for optimization
        input_names=['input'],   # the model's input names
        output_names=['output'],  # the model's output names
        dynamic_axes={"input": {0: "batch_size"}, "output": {0: "batch_size"}}
    )

    print("Model exported to fruit_classifier.onnx")


# --- Test with ONNX Runtime ---
def test_onnx():
    ort_session = ort.InferenceSession("fruit_classifier.onnx")

    def to_numpy(tensor):
        return tensor.detach().cpu().numpy() if tensor.requires_grad else tensor.cpu().numpy()

    inputs, _ = next(iter(test_loader))
    ort_inputs = {"input": to_numpy(inputs[:1])}
    ort_outs = ort_session.run(None, ort_inputs)

    pred_class = np.argmax(ort_outs[0])
    print("ONNX Prediction:", train_dataset.classes[pred_class])


# --- Main ---
if __name__ == "__main__":
    train(num_epochs=5)
    val_acc = evaluate(val_loader)
    print(f"Validation Accuracy: {val_acc:.2%}")

    export_model()
    test_onnx()

Run the fruit_classifier.py Python script

Now you can run the script that will train the model, export it to ONNX format, and run a quick classification test using the ONNX Runtime:

python fruit_classifier.py

What you should see:

Class mapping: {'apple': 0, 'kiwi': 1, 'mango': 2}
Epoch 1, Loss: 0.7811
Epoch 2, Loss: 0.1383
Epoch 3, Loss: 0.0671
Epoch 4, Loss: 0.0399
Epoch 5, Loss: 0.0184
Validation Accuracy: 80.95%
Model exported to fruit_classifier.onnx
ONNX Prediction: apple

If you changed the data set from fruit to your use own images and classifications, it will output a different Class mapping that you will need to use in the Node-RED flow on the next step - make a note of this.

Using your newly generated ONNX Model with the FlowFuse ONNX Node

Import the finished ONNX model into a location in the file system where your Node-RED instance can access it
- In FlowFuse cloud you can do this via the Assets tab
Import the demo flow
- Open your Node-RED editor
- Press CTRL-I or select Import from the menu to open the Import Dialog
- Select the Examples tab
- Click the @FlowFuse/nr-ai-nodes entry
- Click the demo named advanced-custom-model
- Click the Import Button
Double click the ONNX node to open the configuration dialog
Enter the path to your ONNX model in the Path field
If necessary, update the classifications (labels) in the Function node named load labels as noted in the previous section
Deploy the flow
Click the inject button on the left of the flow to trigger an inference

Image showing how to import demo flow

Image showing inference in action

Supplementary Notes

Clean up

To deactivate the virtual environment when you're done, simply run:

pyenv deactivate

You can remove the __pycache__ and other temporary files if they were created:

rm -rf __pycache__
rm -rf runs/ logs/ checkpoints/

If you want to completely remove the virtual environment, you can do so with:

pyenv uninstall venv_py3_10_14_pytorch

Beyond Cloud AI Orchestration: Why the Future is Hybrid Edge-Cloud Intelligence

2025-10-09T00:00:00Z

Congratulations to n8n on their Series C funding round! This is a fantastic milestone and a clear signal that the market has moved beyond AI experimentation and into the serious business of production deployment. Platforms like n8n are mastering what we call centralized orchestration: creating cloud-native "brains" that connect digital services, APIs, and data sources to execute complex workflows. This approach excels for digital-first applications and represents a crucial evolution in workflow automation.

But for industrial applications, we need to think beyond traditional cloud orchestration.

The tech world is buzzing with talk of AI agents and orchestration platforms, and the energy around n8n's recent funding is proof of this momentum. This energy is a fantastic sign of a maturing market, proving that we've moved beyond AI experimentation and into the serious business of production deployment.

Cloud orchestration platforms excel at what they're designed for: connecting digital services, managing API workflows, and orchestrating cloud-native applications. However, for the industries that power our physical world—manufacturing, logistics, energy, and infrastructure—we need complementary approaches that address the unique requirements of operational technology. This is where hybrid edge-cloud architectures become essential.

Industrial Requirements: Where Cloud-Only Solutions Face Challenges

When operations involve real-world assets like factory machinery, remote sensors, or logistics fleets, purely centralized approaches encounter specific industrial constraints. For applications where milliseconds matter—such as emergency shutdowns or quality control decisions—the latency of cloud round-trips can be too slow for critical responses. Connectivity challenges in industrial environments, from remote oil platforms to underground mining operations, require systems that can operate intelligently even when cloud connections are intermittent.

Additionally, the economics of data movement become significant at industrial scale. Streaming continuous data from thousands of sensors to the cloud for processing can be costly and inefficient, especially when much of that processing could happen locally. Many industries also have regulatory requirements that mandate certain operational data remain on-premise for compliance and security reasons.

These constraints don't invalidate cloud orchestration—they highlight the need for hybrid approaches that leverage both cloud capabilities and edge intelligence where each excels.

The Next Paradigm: Hybrid Edge-Cloud Intelligence

The future of industrial AI isn't choosing between cloud or edge—it's intelligently combining both. Rather than replacing cloud orchestration, the industrial world needs a hybrid architecture: a distributed nervous system where cloud orchestration handles high-level coordination and data aggregation, while edge intelligence manages real-time operations and local decision-making.

In this paradigm, AI operates at multiple levels. Edge devices handle immediate responses—predictive maintenance alerts, quality control decisions, and safety shutdowns—without waiting for cloud communication. Meanwhile, cloud orchestration excels at what it does best: aggregating data from multiple sites, running complex analytics, coordinating across systems, and managing enterprise-wide workflows. This creates a complementary relationship where each layer operates within its strengths.

FlowFuse: Bridging Edge and Cloud Intelligence

While the market builds excellent tools for cloud-based AI orchestration, FlowFuse specializes in the hybrid approach that industrial applications demand. Built on the proven foundation of Node-RED, our platform provides engineers with a unified control tower to manage both cloud orchestration and edge intelligence at scale.

FlowFuse Cloud enables centralized management and coordination, while our edge capabilities allow thousands of Node-RED instances to operate intelligently at remote locations. This hybrid architecture lets you seamlessly integrate the physical and digital worlds—leveraging cloud orchestration for enterprise workflows while maintaining real-time edge intelligence where it matters most.

Our FlowFuse Expert simplifies the creation and management of complex logic across both cloud and edge environments, democratizing advanced automation without requiring specialized data science skills. Soon, with our upcoming AI Agent nodes, FlowFuse will enable powerful AI agents to operate seamlessly across the entire hybrid architecture, from cloud coordination to edge execution.

Conclusion: The Power of Hybrid Intelligence

The rise of AI orchestration platforms represents an important evolution in automation technology. These tools excel in their domain and will continue to play a crucial role in digital transformation initiatives.

For industrial applications, the future lies in hybrid architectures that combine the strengths of both approaches. Cloud orchestration provides the coordination, analytics, and enterprise integration capabilities that modern businesses require, while edge intelligence delivers the real-time responsiveness and resilience that industrial operations demand.

Choosing the right approach comes down to understanding your requirements. For digital-first applications, cloud orchestration platforms offer powerful solutions. For industrial and IoT applications that bridge physical and digital worlds, hybrid edge-cloud architectures provide the comprehensive intelligence needed to succeed.

Ready to Build the Future of Industrial AI?

FlowFuse is built for the challenges of industrial and IoT data. Whether you're implementing Industry 4.0 initiatives or building predictive maintenance systems, we provide the platform to deploy and manage intelligence across both cloud and edge environments.

Start building today: Try FlowFuse free or Book a demo

The Node-RED Revolution: How Low-Code is Democratizing Industrial Automation

2025-10-09T00:00:00Z

To understand the impact Node-RED has had on industrial automation, it's useful to understand where it has come from and what has enabled its success.

Almost 20 years ago, I was helping to develop an MQTT broker. One of the features of the broker was to create message transformations; taking messages from one topic, modifying their structure and republishing on another topic. It was a really useful feature, but it was only ever exposed via a programming API. Customers had to write lots of code to make use of it. It was also difficult to examine what transformations had already been created. I would often find myself getting a piece of paper and writing out the transformations to help spot any unexpected interactions between them. At the time, I dreamed of a way to better visualise what was happening - but that was far out of scope of our requirements at the time.

Fast forward a few years, and I found myself faced with a similar challenge; working on customer projects that often required pulling data from different sources and having to write the same bits of code again and again to get the job done. This time, I was more in a position to do something about it, and after a couple days of coding, I had a simple demo of a tool that could visualise MQTT topics and how messages would get routed between them. Then we added a way to pull data from a Serial port, a way to run custom code against the messages, a way to do HTTP requests - each week, a new customer project would raise a new requirement and this little side project would prove its worth again and again.

This is, of course, the Node-RED origin story. But how has this little side project become the widely adopted success it has - and why is it so valuable to Industrial users? I think there are three parts to this; its low-code visual nature, its Open Source availability and its extensibility.

Low-Code Visualisation

One of my original motivations for Node-RED was to save time by not having to write the same pieces of boiler-plate code each time I needed to do a particular task. Dragging a node into the workspace takes seconds and replaces minutes - or even hours - of traditional code development time.

This abstraction empowers anyone to start building applications in Node-RED. System engineers understand the problem they are trying to solve. Node-RED gives them the ability to build their solutions without having to think about the lines of code each node represents - they can focus on the task at hand.

Open Source

The move away from proprietary solutions gives users more control and influence over the tools they use. Open Source Software brings principles of collaboration, transparency, and interoperability. It was a very deliberate choice to make Node-RED Open Source in its early days; we knew the project’s future lay in building an open community around it - with contributors from many backgrounds.

Extensibility

A natural consequence of the Open Source path the project took was to make it easy to extend what Node-RED could do. Enabling the community to build their own nodes greatly accelerated the adoption of the project - with the Open Source ethos underpinning that work.

Whilst we see Node-RED used in many industries, it finds a natural home in the Industrial automation space. Being able to run anywhere from edge-of-network devices to the cloud gives a lot of flexibility in the types of solutions it can be applied to. At its heart, Node-RED is all about accessing data, wherever it may be and doing something meaningful with that data.

We see it being used alongside traditional PLCs, providing an easier point of integration - pulling data from many different systems in one place, providing a dashboard visualization in situ, and making the data available to the wider organization. Having a consistent developer experience for all those tasks makes Node-RED a natural choice.

Scaling Node-RED within your organization

Through the early life of the project, we focussed on the core of Node-RED being a high-quality, reliable, low-code development tool. Through the community, we knew there were companies beginning to adopt Node-RED at scale, but some of the challenges they were facing were out of scope of what the core project could address.

The flexibility of Node-RED comes at a cost of how you scale and manage your Node-RED infrastructure. All organizations have a responsibility to keep their IT infrastructure secured and well-maintained - and that has to be considered when adopting any technology.

For all of its strengths, the choice of Open Source at the core does pose some questions that should not be overlooked. For example, who can be relied on to fix issues if you don’t have the engineering capacity within your own organization? How do you manage all of those Node-RED instances throughout your organization?

These were the questions that motivated me to start FlowFuse - and is where we elevate Node-RED to be a robust enterprise-ready platform. Just as the early development of Node-RED was driven by our own requirements, FlowFuse has been built based on first-hand experience of what’s needed to scale Node-RED.

A great example is one of our early customers who is a large manufacturer in the US. They began adopting Node-RED in 2018 across their facilities. At the time, they had to build a lot of custom automation to manage it, but the overheads were becoming unmanageable. With their small IT team, they found it hard to properly track the different versions of flows deployed across their sites. They moved over to FlowFuse which has enabled them to continue scaling their operations and now have thousands of Node-RED instances being managed by the platform.

This is a common pattern we see; FlowFuse solves the operational challenges that slow down digital transformation; engineers are able to focus on solving real business problems with confidence.

Join us at Node-RED Con

Next month we’re sponsoring the Node-RED Con virtual event - a free day of talks from the Node-RED community all about how it’s being used in industry. There are lots of fascinating talks scheduled and I’d urge you to register to attend.

What's the Difference Between Node-RED and FlowFuse

2025-10-08T00:00:00Z

FlowFuse is an industrial data platform built on Node-RED. Many Fortune 500 manufacturers and Industrial IoT companies use it to run mission-critical operations where downtime is not an option.

If you're hearing about FlowFuse for the first time, you might wonder: "If it's built on Node-RED, what makes it different?"

This article answers that question. You'll learn what FlowFuse adds to Node-RED, whether it competes with Node-RED, and how to decide which platform is right for you.

Where Node-RED Came From

To understand what FlowFuse adds, it helps to first look at Node-RED itself.

In 2013, Nick O'Leary (CTO and Founder of FlowFuse) and Dave Conway-Jones at IBM identified a problem: connecting devices, APIs, and services required hundreds of lines of code for tasks that should be straightforward. Their solution was to make programming visual. Drag nodes, draw connections, deploy your logic.

Engineers who understood systems but couldn't code could suddenly build applications. Tasks that took weeks were completed in hours. Node-RED runs on laptops, Raspberry Pis, factory floor gateways, and enterprise servers. The community has built thousands of nodes for most scenarios you'll encounter.

For small projects, prototypes, and learning, Node-RED provides what you need without overhead.

When Limitations Surface

Your Node-RED flow works. It monitors equipment, processes data, and displays dashboards. Then the question arises: 'Can we deploy this across all 50 of our factories efficiently, without wasting time or money?

That question exposes the limitations of standalone Node-RED:

You need to deploy to 50 sites across three continents without manual setup at each location. Five engineers need to work on improvements without conflicts. You need alerts when any instance goes down because downtime stops production and costs money. Your security team requires SSO integration, role-based access control, and audit trails. You need to push updates to all sites at once, not travel to each location over weeks. When someone deploys a breaking change on Friday afternoon, you need to roll it back in seconds.

This is where Node-RED ends and FlowFuse begins.

Node-RED gives you the tools to build. FlowFuse provides the infrastructure to deploy, manage, and scale what you've built.

What FlowFuse Adds

FlowFuse doesn't replace Node-RED. You use the same visual editor, nodes, and flows. FlowFuse adds the operational layer that transforms Node-RED from a development tool into a production platform.

Security and Compliance

Standard Node-RED leaves authentication to you—typically basic auth or custom middleware. For personal projects, this suffices. Production environments controlling industrial systems need more.

FlowFuse provides role-based access control (RBAC) to define who edits flows versus who views them. Single Sign-On via SAML, LDAP, and OIDC integrates with your existing identity systems. Audit logs capture every deployment with details on who made changes and when. Database credentials and API tokens are managed through encrypted secrets storage, keeping them out of flow exports and version control.

For supply chain security, FlowFuse generates a Software Bill of Materials (SBOM) listing every node and dependency across your instances. Security teams can scan for vulnerabilities and track what needs updating.

Team Collaboration and Version Control

Node-RED was built for individual developers. When two people edit the same instance, the last save wins. No version history exists. No way to review changes before deployment. No rollback option.

FlowFuse enables multi-user teams working on shared projects with proper permissions. Every deployment creates a snapshot—a complete record of your flows at that point in time. Compare snapshots to track changes or restore previous versions when deployments break production.

Remote Device Management

Node-RED instances running on edge devices in remote factories, warehouses, or hard-to-reach locations create operational challenges. Troubleshooting means traveling on-site or configuring complex VPN access.

FlowFuse provides centralized management through its Device Agent—a lightweight service installed on remote devices that establishes secure connections back to your FlowFuse instance. From one dashboard, you see and control your entire fleet. Open any device's editor or view its logs through secure tunnels without exposing ports or setting up VPNs. Push updates over-the-air to individual devices or groups.

Deployment Pipelines and Scalability

Standalone Node-RED moves code from development to production through manual export and import. This doesn't scale and introduces errors with each manual step. Managing one instance is simple. Managing hundreds requires standardization.

FlowFuse builds structured deployment into the platform. Create Development, Staging, and Production environments for each project. Promote snapshots between stages with single clicks. Organize devices into groups by location or function, then target updates to specific groups. Deploy to all North American packaging lines while leaving European facilities on their current version. The platform organizes work through teams and projects, giving each group isolated resources while maintaining central oversight.

Observability and Monitoring

Standalone Node-RED displays logs from a single instance. When you're running multiple instances across different locations, you need centralized visibility. Building this yourself means integrating Prometheus, configuring exporters, creating Grafana dashboards, and setting up alerting—weeks of specialized work.

FlowFuse provides centralized observability. View logs from any instance, check audit logs for specific deployments, monitor real-time status showing when each instance was last seen, and track CPU and memory usage across your entire fleet—all from one interface.

Managed Infrastructure

Running Node-RED means managing servers or edge devices, handling installations, planning updates, configuring backups, and preparing disaster recovery. At scale, this becomes a full-time responsibility.

FlowFuse Cloud is fully managed—they handle infrastructure, you build applications. FlowFuse Self-Hosted runs on your infrastructure but manages orchestration, updates, and monitoring. Both options deliver over-the-air updates for Node-RED versions, security patches, and configuration changes without downtime.

Certified Nodes

The Node-RED community has built thousands of nodes covering most use cases. Production environments need assurance about maintenance, security vulnerabilities, and long-term support.

FlowFuse's Certified Nodes program vets community contributions for quality, security, and maintenance. FlowFuse takes ongoing responsibility for certified nodes and accepts certification requests for nodes you need.

Development Acceleration

Node-RED's visual programming is fast, but real-world development has friction points. Complex function nodes and UI templates require time and coding skill. Understanding teammates' flows isn't always straightforward. Building the same patterns across projects becomes repetitive.

FlowFuse Expert tackles these challenges directly in the editor. Describe your need in plain language—it generates function nodes or UI templates, explains existing flows, writes SQL queries, suggests relevant nodes, and creates documentation. This speeds up experienced developers while making Node-RED accessible to those still learning.

The Blueprint Library provides tested and proven templates for common industrial scenarios—OEE dashboards, Andon systems, operator terminals. Instead of building from scratch, start with working solutions and customize them for your needs.

Team Library enables reusability within your organization. Export a flow to your Team Library once, and it's available across all team instances. Your team maintains consistent patterns without recreating the same work.

Commercial Support

Node-RED's community provides excellent support for learning and troubleshooting through forums and discussions. Production outages costing money per minute require faster resolution and guaranteed response times.

FlowFuse offers commercial support with Service Level Agreements. Work directly with engineers who understand Node-RED internals, have encountered your problems before, and can architect solutions that scale.

Are Node-RED and FlowFuse Competitors?

No. Node-RED and FlowFuse are not competitors—they’re complementary. FlowFuse is built directly on top of Node-RED, and the two projects share deep roots. In fact, FlowFuse employees, including Node-RED’s co-creator Nick O’Leary, are among the most active contributors to Node-RED itself. They review pull requests, write code, run Node-RED Con, and maintain long-term support for the community.

When Node-RED improves, FlowFuse improves too. This is the same dynamic seen in other open-source ecosystems: Linux thrives alongside Red Hat, Kubernetes powers enterprise platforms, and PostgreSQL continues to evolve while vendors provide enterprise features. The open-source project remains free and independent, while the commercial platform adds operational value on top.

FlowFuse also invests back into the ecosystem. A good example is the FlowFuse Dashboard (often called Node-RED Dashboard 2.0), which replaced the deprecated original Node-RED Dashboard. By sponsoring and maintaining this project, FlowFuse ensures the community continues to have a modern, supported visualization tool.

And importantly, your flows remain portable. Anything you build in FlowFuse works in plain Node-RED. There is no vendor lock-in. FlowFuse exists to extend Node-RED, not replace it.

Conclusion

Node-RED is a development tool. FlowFuse is a production platform.

Node-RED lets you build flows. FlowFuse lets you deploy them securely, collaborate, manage them centrally, and scale them across your organization.

FlowFuse takes what you’ve built in Node-RED and makes it production-ready.

Want to See FlowFuse in Action?

This article highlighted the key differences between Node-RED and FlowFuse, but many advanced features and real-world use cases remain to be explored.

Book a demo with our team to see a complete live demo and discover how FlowFuse extends Node-RED for enterprise operations, or start a free trial to experience it yourself.

OpenAI's AgentKit or FlowFuse: Choosing the Right Low-Code App for Your Needs

2025-10-07T00:00:00Z

AI is moving fast, and with it, the tools we use to build intelligent applications. Two interesting platforms that have emerged are OpenAI's AgentKit and FlowFuse. While both offer AI capabilities, they are designed for very different purposes. Let's break down the key differences to help you decide which platform is the right fit for your needs.

OpenAI's AgentKit: For building AI agents

OpenAI's AgentKit is a toolkit for developers who want to build and deploy AI agents. Key features of AgentKit include the Agent Builder, a low-code visual environment for designing multi-agent workflows, and a Connector Registry for managing data and tool connections. It also provides ChatKit for embedding chat-based agent experiences, Expanded Evals for measuring agent performance, and reinforcement fine-tuning (RFT) to customize reasoning models. Essentially, AgentKit is for developers who are building AI-native applications and need a robust set of tools to create and manage their agents within the OpenAI ecosystem.

FlowFuse: The Bridge Between the Physical and Digital Worlds

FlowFuse, on the other hand, is built on the foundation of Node-RED, also a low-code platform. FlowFuse is specifically designed for industrial and IoT applications, with a strong focus on what's known as "the edge" – the physical world where data is generated by assets like sensors, machines, and other devices.

This is where the user's point about edge data extraction comes in. FlowFuse excels at managing and scaling fleets of Node-RED instances running on edge devices. This allows engineers to easily and securely collect data from all their industrial devices and sensors, effectively "fusing the physical with the digital."

Key Differentiators

So, how do these two platforms really differ? The first key differentiator is their core focus. AgentKit is for building AI agents that live in the digital world of applications and services, whereas FlowFuse is for building and managing end-to-end data applications that interact with the physical world through edge devices.

AgentKit, in its current form, does not have a focus on edge data extraction. Its purpose is to help you build the "brains" of an AI. FlowFuse's entire reason for being is to provide the "nervous system" that connects those brains to the real world. It's all about managing edge deployments and ensuring a reliable flow of data from the edge.

The FlowFuse Expert is a powerful tool that helps engineers, even those who aren't expert coders, to build and manage their Node-RED flows. For instance, you can describe what you need in plain English and the assistant will generate the necessary code. It can also analyze a complex flow and explain what it does, making it easier to maintain. Furthermore, the assistant is a huge time-saver as it can create realistic test data and even help you build custom dashboards to visualize your data.

So, while AgentKit is a toolkit for building AI agents, the FlowFuse Expert is a tool that helps you build the applications that connect to the physical world. It empowers any engineer to fuse the physical with the digital by making it easier than ever to create the logic needed to collect, transform, and act on data from the edge.

What's more, FlowFuse already supports creating AI and RAG integrations and will soon be releasing dedicated MCP nodes that greatly simplifies low-code building of AI Agents. enabling AI to work directly at the edge. This means you can create AI agents that not only process data from physical devices but also make decisions right where the data is generated — with a lot less latency due to less Cloud round-trips. This is especially important for industrial applications where milliseconds matter.

Conclusion

Choosing between OpenAI's AgentKit and FlowFuse comes down to what you're trying to achieve. If your goal is to build sophisticated, AI-powered agents for your applications and your focus is on the digital realm, then OpenAI's AgentKit is the clear choice. However, if you need to connect to, manage, and extract data from physical devices in the real world, and you want to empower your engineers with an FlowFuse Expert that makes this process easier, then FlowFuse is the platform for you.

In the end, these are two powerful but very different tools. AgentKit is for the AI developer, while FlowFuse is for the industrial engineer who wants to bring the power of AI to the edge. We're looking forward to how these technologies can be combined in future!

Ready to Connect Your Physical World?

While AgentKit is perfect for building AI agents in the digital realm, FlowFuse is built for the challenges of industrial and IoT data: managing edge deployments at scale, connecting to diverse industrial protocols, and ensuring reliable data flow from thousands of physical devices.

Whether you're monitoring production lines, building predictive maintenance systems, or implementing Industry 4.0 initiatives, FlowFuse provides the infrastructure to collect, transform, and act on data from the edge.

Start building today: Try FlowFuse free or book a demo to see how we help teams manage industrial data at scale.

Modbus RTU (RS485/RS422/RS232) Communications with FlowFuse

2025-09-26T00:00:00Z

Modbus RTU is one of the most widely used communication protocols in industrial automation. It allows you to read sensor data, monitor equipment status, and control devices through a simple master-slave architecture. This guide will walk you through everything you need to know to start reading and writing industrial data with FlowFuse (a platform built around Node-RED with enterprise-level capabilities).

Whether you're connecting a single sensor or building a comprehensive industrial monitoring system, this step-by-step guide will show you how to leverage FlowFuse's powerful capabilities to bridge the gap between legacy industrial devices and modern data systems.

Understanding Modbus RTU Basics

Modbus RTU operates on a master–slave system. Unlike its TCP counterpart, it runs over serial connections (RS485/RS422/RS232), making it extremely reliable in environments where network connectivity may be unstable. The protocol has been battle-tested in harsh conditions for decades, which is why it is still used in everything from simple temperature sensors to complex PLCs.

In a FlowFuse setup, the instance acts as the master, initiating all communication. Devices such as sensors, meters, and controllers act as slaves, responding only when addressed. Each slave has a unique address from 1 to 247, with 0 reserved for broadcast messages. Communication follows a simple pattern: the master sends a request, the addressed slave responds, and the master processes the response before moving to the next device.

Device Data Types

Devices organize data into four main types, each with a specific purpose:

Coils (Digital Outputs) – Remote switches you can turn on/off from FlowFuse, used for motors, pumps, relays, or alarms.
Discrete Inputs (Digital Inputs) – Read-only status points that indicate the state of buttons, doors, or alarms.
Input Registers (Analog Inputs) – Read-only values representing measurements such as temperature, pressure, or flow.
Holding Registers (Analog Outputs/Settings) – Read/write values for setpoints, timers, and configuration parameters.

Note: Coils and discrete inputs are single-bit (ON/OFF), while registers store 16-bit values that may require scaling depending on the device.

Register Addressing

Addressing can be confusing because manufacturers document it differently:

Zero-based – Modbus standard (first register = 0).
One-based – Some manuals start counting at 1 (subtract 1 in FlowFuse).
Offset-based – Registers like 40001 or 30001 require subtracting the base number to get the actual address.

Example: If a manual shows “Temperature = 40001,” FlowFuse should use address 0. Always refer to the device’s “Register Map” for clarity.

By understanding the master-slave control, data types, and addressing, you can reliably communicate with your devices and make the most of Modbus RTU in FlowFuse.

Getting Started

Let’s start by setting up the basics before connecting Modbus RTU devices to FlowFuse.

Prerequisites

Before diving in, make sure you have the following ready:

Node-RED instance – A running Node-RED instance. The quickest way to get one ready for production is with FlowFuse. Simply sign up and create and set up a remote instance, and you’ll have a managed Node-RED environment running in minutes.
Node-RED Modbus nodes – Installable via the Palette Manager (node-red-contrib-modbus).
Modbus-enabled device – Such as a sensor, PLC, or meter, along with its register map documentation.
Serial interface – For example, a USB-to-RS485 converter to physically connect your Modbus devices. Connect the A (+) and B (–) terminals of the RS485 adapter to the device, add termination resistors if the line is long or has multiple devices, and note the serial port path (e.g., /dev/ttyUSB0 on Linux or COM1 on Windows).

Reading Data

Reading data from Modbus slaves in FlowFuse is straightforward. The process is the same regardless of which data type you want to read.

Drag the Modbus Read node onto the FlowFuse canvas. Double-click it to open the configuration. Enter the Unit ID (slave address), select the data type you want to read, specify the starting address, set the quantity of values to read, and define the poll rate (how often data should be read).

Modbus Read node configured to read data from a slave device.

Click the + icon next to the Server field to add Modbus connection details.
In the server configuration window:
- Set Type to Serial.
- In the Serial Port field, use the dropdown or search option to see all available ports (e.g., /dev/ttyUSB0 on Linux or COM1 on Windows). Select the port to which your Modbus device is connected.
- Configure the communication settings to match your device:
  - Baud Rate
  - Data Bits
  - Stop Bits
  - Parity
These values must match exactly with the Modbus device’s configuration; otherwise, the communication will fail.

Serial port and communication settings for the Modbus device.

Connect the Modbus Read node to a Debug node and deploy your flow. If everything is set up correctly, you will start seeing live data from your Modbus device in the debug sidebar.

Writing Data

Modbus RTU allows you to write data back to devices, enabling control of motors, relays, setpoints, and other outputs directly from FlowFuse.

Follow these steps to configure and test writing:

Drag the Modbus Write node onto the canvas. This node will send data to your Modbus device.
Double-click the node and set:
- Unit ID – the slave address of your device.
- Data type – choose one of:
  - Force Single Coil – write one digital output.
  - Force Multiple Coils – write several digital outputs at once.
  - Preset Single Register – write one analog/config value.
  - Force Multiple Registers – write several analog values at once.
- Address – the target coil or register.
- Quantity – only for multiple writes, set the number of values you will send.
Writing a single coil using the Modbus Write node.

Writing multiple coils using the Modbus Write node.
Connect an Inject node to the Modbus Write node to send values:
- Single Coil/Register: send a boolean (true/false) for coils or a number for registers.
- Multiple Coils/Registers: send an array corresponding to each value.
Examples:
- [true, false, true] → Coils 0, 1, 2
- [25, 50, 75] → Holding Registers 0, 1, 2
Deploy the flow and press Inject. The Modbus device should update immediately.

Tip: Use a UI input (slider, switch, or numeric box) from the FlowFuse Dashboard instead of an Inject node for real-time control via a web interface.

Scaling and Interpreting Values

Raw Modbus values often don’t make sense until you apply scaling factors or unit conversions.

A temperature register might return 235, which actually means 23.5 °C.
An energy meter might output 12345, representing 12.345 kWh.
A pressure sensor could use two consecutive registers (32-bit values) that need decoding.

You can handle these conversions with simple Function nodes or Change nodes in FlowFuse.

Example Function Node:

// Convert raw register value to temperature in °C
let raw = msg.payload[0];
msg.payload = raw / 10;
return msg;

This takes the raw register, divides it by 10, and gives you a clean, human-readable temperature.

Tip: You do not need to know JavaScript — simply use the FlowFuse Expert, which can generate a Function node for you from plain English instructions. For the most accurate results, provide sample data along with the scaling you want to achieve. You can learn more in this article: FlowFuse Expert for Manufacturing.

Best Practice: Always keep a copy of the device’s Register Map documentation handy. It tells you which addresses map to which variables, and how to interpret them.

Troubleshooting Tips

If things do not work on the first attempt, avoid frustration. Modbus is straightforward, but even small configuration mismatches can disrupt communication.

Verify the serial port is correct and not already in use.
Double-check baud rate, data bits, stop bits, and parity. Even a single mismatch will block communication.
Ensure the Unit ID matches your device’s slave address.
Keep your wiring neat. For longer cables, use termination resistors and twisted-pair shielded cables.
Use a Modbus simulator or diagnostic tool to test the setup if the hardware isn’t responding.

Conclusion

Modbus RTU has stood the test of time in industrial automation because it’s simple, reliable, and built for harsh environments. With FlowFuse, you can take this legacy protocol and give it modern superpowers:

Collect real-time data from sensors and machines.
Control devices directly from a web dashboard.
Combine Modbus with MQTT, REST APIs, or databases to share data across your entire organization.
Scale from a single sensor to a factory-wide monitoring and control system.

The real value comes when you stop treating Modbus as just a communication protocol and start using FlowFuse as the bridge between industrial devices and enterprise systems. From dashboards to alerts, from analytics to cloud integration — the possibilities are endless once the data is in your hands.

Takt Time: Definition, Formula, How to Calculate with Examples & More [2026 Edition]

2025-09-25T00:00:00Z

Takt time is one of the most fundamental—and most misunderstood—concepts in lean manufacturing. Despite being widely referenced in textbooks, audits, and production meetings, many factories still calculate takt time incorrectly or treat it as a theoretical number rather than an operational control. The result is familiar: overproduction during low demand, missed deliveries during peak demand, unstable lines, and constant firefighting on the shop floor.

In reality, takt time is not a KPI—it is a design constraint. It defines the exact pace at which a production system must operate to meet real customer demand using the available working time. When applied correctly, takt time becomes the backbone of flow, line balancing, capacity planning, and continuous improvement. When applied incorrectly, it creates false confidence, hidden bottlenecks, and chronic inefficiencies.

This guide is written from a practical, factory-floor perspective, not just a theoretical lean framework. It reflects how takt time is actually used in modern manufacturing environments—automotive plants, electronics assembly lines, FMCG production, and digitally connected factories running real-time systems. Every definition, formula, and example in this article is grounded in how takt time is applied by production engineers, operations managers, and lean practitioners to solve real problems.

In this 2026 edition, you’ll learn:

The correct definition of takt time and what it truly represents operationally
How to calculate takt time accurately, including what time must be excluded (and why)
The difference between takt time, cycle time, and lead time, and how confusing them leads to bad decisions
Real-world examples showing how takt time exposes bottlenecks and capacity gaps
How modern digital tools calculate and monitor takt time in real time, not spreadsheets

Whether you are designing a new production line, stabilizing an existing process, or transitioning toward lean and Industry 4.0 practices, this guide gives you a complete, trustworthy, and experience-backed explanation of takt time, from first principles to real-world execution.

What is Takt Time?

Takt time is the maximum allowable time to produce one unit of product to meet customer demand. It acts as the "heartbeat" of your production line, establishing the rhythm at which work must flow to satisfy customer orders without overproducing or falling behind.

The word "takt" derives from the German word "taktzeit," which translates to "cycle time" or "beat." This linguistic origin reflects the concept's European manufacturing heritage, though it's important to recognize that takt time and cycle time represent fundamentally different metrics. We'll examine this critical distinction in detail later in this guide.

Formal Definition of Takt Time

The definition of takt time is: the available production time divided by customer demand. This establishes the pace at which your production line must operate to meet customer requirements. It's a customer-driven metric calculated from actual demand rather than production capability.

Takt time serves as both a planning tool and a mechanism for waste elimination, providing a common reference point for distributing work evenly across production stations.

Meaning of Takt Time

The meaning of takt time goes deeper than just a calculation—it represents your production heartbeat. It's the pulse that synchronizes all production activities with real customer demand.

The operational meaning of takt time functions as:

A planning target that prevents overproduction and underproduction
A balancing tool that distributes work evenly across workstations
A performance metric that reveals bottlenecks and capacity constraints
A continuous improvement baseline that quantifies the gap between current and required performance

When you properly understand what takt time means, you transform it from a simple formula into a powerful operational philosophy that drives lean manufacturing excellence.

Takt Time Formula

The fundamental takt time formula

The takt time formula is deceptively simple, yet its application transforms manufacturing operations:

Takt Time = Available Production Time ÷ Customer Demand

This formula of takt time contains two critical components that require careful definition. Let's break down each element to understand how to calculate takt time accurately.

Available Production Time

This is the net time available for production during your planning period (typically one shift or one day). When applying the takt formula, available production time includes only planned production time. It excludes planned breaks, meetings, shift changes, and scheduled maintenance, but does not include unplanned downtime such as breakdowns or minor stoppages. It excludes scheduled breaks and lunch periods, shift changeovers, planned maintenance windows, and scheduled meetings or training.

Consider an example calculation of takt time. An eight-hour shift equals 480 minutes. Subtract a 10-minute break to yield 470 minutes. Subtract a 20-minute lunch to yield 450 minutes. Subtract a 30-minute planned changeover to yield 420 minutes. The available production time equals 420 minutes.

The distinction between included and excluded time proves critical for accurate takt time calculation. Organizations frequently overestimate available time by failing to account for all legitimate non-production activities, then face persistent schedule shortfalls when reality proves less generous than planning assumptions.

Customer Demand

When you calculate takt time, customer demand represents the number of units customers require during your planning period. This figure can derive from actual customer orders, forecasted demand, production targets based on inventory levels, or averaged demand over longer periods such as weeks or months.

The choice of demand figure affects the meaning of takt time stability and operational practicality. Using daily order quantities creates takt times that vary day-to-day, potentially requiring frequent line rebalancing. Averaging demand over weekly or monthly periods creates more stable takt times but may result in temporary overproduction or underproduction as actual daily demand fluctuates around the average.

Most manufacturers employ hybrid approaches, using averaged demand for line design and capacity planning while adjusting targets periodically to reflect actual order patterns. The appropriate averaging period depends on demand volatility, product mix complexity, and production flexibility.

Calculating Takt Time: A Step-by-Step Example

Using our example numbers where available production time equals 420 minutes and customer demand equals 210 units, let's apply the takt time formula:

Takt Time = 420 minutes ÷ 210 units = 2.0 minutes per unit

This result means your production line must complete one unit every 2 minutes to meet customer demand. When you define takt time this way, the calculation establishes a maximum allowable cycle time—any operation taking longer than 2 minutes per unit will prevent the line from meeting demand unless compensated by faster cycle times elsewhere or by adding capacity.

Real-World Examples of Takt Time

Examining several real-world examples demonstrates how to calculate takt time across different manufacturing contexts. These examples show the practical application of the takt time formula in diverse scenarios.

Example 1: Automotive Parts Manufacturing

An automotive parts manufacturer produces brake assemblies during an eight-hour shift. The shift includes a 30-minute lunch period and two 10-minute breaks totaling 20 minutes. A planned changeover consumes 10 minutes. Customer orders require 120 brake assemblies per shift.

To calculate takt time, first determine available production time. Start with 480 minutes for the eight-hour shift. Subtract 30 minutes for lunch, 20 minutes for breaks, and 10 minutes for changeover. The available production time equals 420 minutes.

Now apply the takt time formula. Divide 420 minutes by 120 units to yield 3.5 minutes per unit.

Understanding the meaning of takt time in this result shows the production line must complete one brake assembly every 3.5 minutes to meet customer demand. If actual cycle time equals 5 minutes per unit, production will fall short by approximately 30 percent, completing only 84 units instead of the required 120 units. If actual cycle time equals 3 minutes per unit, the line produces 140 units, creating 20 units of excess inventory and risking overproduction waste.

This example illustrates why defining takt time correctly matters for matching cycle time to customer demand. Cycle times significantly exceeding takt time reveal capacity shortfalls requiring immediate attention. Cycle times falling well below takt time suggest excess capacity that might be redeployed elsewhere or indicate risk of overproduction if production control systems fail to prevent excess output.

Example 2: Electronics Assembly (Multiple Shifts)

An electronics manufacturer operates two shifts producing circuit boards, with weekly demand of 2,400 units across five operating days. Each eight-hour shift allocates 40 minutes for breaks and 20 minutes for changeovers.

When you calculate takt time for multiple shifts, first determine available time per shift: 480 minutes minus 40 minutes for breaks minus 20 minutes for changeovers equals 420 minutes per shift.

Calculate total available time per week: 420 minutes multiplied by 2 shifts multiplied by 5 days equals 4,200 minutes per week.

Apply the takt formula: 4,200 minutes divided by 2,400 units equals 1.75 minutes per unit.

An alternative approach to calculate takt time uses per-shift demand. Daily demand equals 2,400 units divided by 5 days, or 480 units per day. Demand per shift equals 480 units divided by 2 shifts, or 240 units per shift. Using the takt time formula: 420 minutes divided by 240 units equals 1.75 minutes per unit—the same result.

This example demonstrates that the takt time calculation can proceed from different time horizons and still yield consistent results. Whether calculating weekly, daily, or per-shift takt time using the takt formula, the fundamental relationship between available time and required output remains constant. Organizations typically choose calculation periods matching their planning cycles and demand visibility horizons.

Example 3: Variable Product Mix

A manufacturer produces three different models on the same production line with 450 minutes of available time. Model A requires 100 units at 2 minutes per unit, Model B requires 50 units at 3 minutes per unit, and Model C requires 30 units at 4 minutes per unit.

To define takt time for mixed-model production, calculate weighted average takt time by summing total demand: 100 plus 50 plus 30 equals 180 units. Using the takt time formula, average takt time equals 450 minutes divided by 180 units, or 2.5 minutes per unit.

Individual product takt times can also be calculated using the formula of takt time. Model A would receive 4.5 minutes per unit (450 divided by 100), though its actual process time is only 2 minutes. Model B would receive 9.0 minutes per unit, and Model C would receive 15.0 minutes per unit. In mixed-model production, manufacturers typically employ level loading techniques to smooth production across the shift rather than producing in large batches.

Level loading for this scenario might sequence production as A-A-B-A-A-C-A-A-B-A-A-C, distributing the three models proportionally throughout available time. This sequence maintains steadier overall pace than producing all Model A units first, then all Model B units, then all Model C units. Understanding the meaning of takt time in this context shows how steady pace reduces work-in-process buildup, makes quality problems visible sooner, and creates more predictable material consumption patterns.

Takt Time vs. Cycle Time vs. Lead Time: Comparison Matrix

You might have heard the terms takt time, cycle time, and lead time, but they're not the same. Let's define takt time and these related metrics to understand their distinct meanings.

Feature	Takt Time	Cycle Time	Lead Time
Fundamental Meaning	The "Heartbeat." The pace required to satisfy the customer.	The "Actual Speed." The time it takes to perform the work.	The "Wait Time." The total duration a part spends in the system.
Formula	Available Production Time ÷ Customer Demand	Time to complete one unit of work	Order completion time – Order placement time
What it Includes	Only net available production time (no breaks).	Loading, processing, unloading, and reset time.	Processing time + Queue time + Shipping + Delays.
Operational Focus	Planning: How many people or machines do we need?	Efficiency: How can we make this specific task faster?	Responsiveness: How quickly can we turn an order into cash?
Management Signal	If this changes, you must rebalance your production line.	If this is too high, you have a bottleneck at that station.	If this is too high, your inventory levels are likely bloated.

The "Ideal State" Relationship

In a perfect Lean environment, the relationship between these three metrics follows a hierarchy that maximizes ROI and eliminates waste. When you properly calculate takt time and understand its meaning, the ideal relationships emerge:

Cycle Time ≤ Takt Time: Your actual work speed should be roughly 90–95% of Takt Time, providing a small buffer for minor interruptions without failing to meet customer demand.
Minimized Lead Time: Lead Time should be as close as possible to the sum of your Cycle Times. For example, if total Cycle Time is 1 hour but Lead Time is 10 days, 99% of the product's time is idle, representing pure waste.

Why Takt Time Matters in Manufacturing

Understanding the definition of takt time and applying the takt formula functions as more than a calculation exercise. It represents a fundamental operating principle that transforms manufacturing execution from reactive scheduling to demand-synchronized production.

Synchronization with Customer Demand

Production systems operating without understanding what takt time means typically run at maximum achievable speed, independent of actual demand signals. This approach generates inventory during periods of low demand and creates capacity shortages when demand increases. The disconnect between production pace and order rate leads to resource misallocation and suboptimal working capital deployment.

When you define takt time and apply it correctly, you establish direct alignment between order rate and production pace. When demand changes, the calculated takt time changes proportionally using the takt time formula, triggering controlled adjustments to production resources. This synchronization maintains lean inventory levels while meeting delivery commitments.

Elimination of Overproduction

Overproduction amplifies other forms of manufacturing waste. Excess production requires additional handling, consumes storage capacity, ties up working capital, and increases the inventory at risk from quality issues or obsolescence. Organizations often underestimate the compounding effect of overproduction on total manufacturing cost.

The meaning of takt time in waste elimination establishes a maximum production rate derived from actual demand. Production exceeding the rate calculated using the takt formula generates inventory that customer orders have not yet justified. Pull-based production systems use takt time as the foundation for inventory replenishment signals, preventing unauthorized production while maintaining buffer stock at calculated levels.

Line Balancing and Flow

Manufacturing lines develop bottlenecks when workstation cycle times vary significantly. Slow stations create waiting at downstream operations, fast stations create waiting at upstream operations, and both conditions generate work-in-process inventory that obscures quality issues and extends lead time.

When you calculate takt time and apply it to each workstation, you provide a common target for balancing workload across all stations. When each station operates near the calculated takt time, flow improves and waiting decreases. Line balancing efforts use the takt time formula as the reference point for redistributing work elements across stations.

Consider a three-station line before balancing. Station 1 completes work in 1.5 minutes, Station 2 requires 3.5 minutes, and Station 3 completes in 2.0 minutes. The bottleneck at Station 2 limits throughput while Stations 1 and 3 accumulate idle time. After balancing to a 2.5-minute takt time (calculated using the takt formula), Station 1 performs work totaling 2.3 minutes, Station 2 completes 2.4 minutes of work, and Station 3 handles 2.3 minutes. Flow improves and bottleneck waiting largely disappears.

Resource Planning and Capacity Analysis

The takt time formula quantifies the relationship between demand and required capacity. When cycle time exceeds the calculated takt time, analysis immediately reveals whether additional operators, additional shifts, faster equipment, or process improvement can close the gap. When cycle time falls well below takt time, excess capacity becomes visible and can be redeployed.

Staffing requirements derive from the comparison between takt time and cycle time. Equipment investment decisions gain quantitative support when takt time analysis demonstrates that current equipment cannot achieve required cycle times. Capacity planning validates whether demand projections require facility expansion or whether existing assets suffice.

Continuous Improvement Framework

When you define takt time clearly, it establishes a baseline for improvement initiatives. The gap between current cycle time and required takt time (calculated using the takt time formula) quantifies the improvement target. Kaizen events and process optimization efforts use this gap to prioritize activities and measure progress.

The improvement cycle follows a standard pattern. Measure current cycle time and compare to calculated takt time. Identify root causes for the gap. Implement improvements addressing these causes. Validate the new cycle time against the takt formula results. Document the process and repeat. This structured approach replaces ad hoc improvement with systematic capability building.

Quality and Safety Considerations

Operating at sustainable pace rather than maximum speed affects both quality outcomes and safety performance. Production systems pushed to maximum throughput often sacrifice quality checks, proper technique, and ergonomic considerations. The pressure to maintain speed creates conditions where errors multiply and injuries occur.

Understanding the true meaning of takt time shows it's about sustainable pace. Takt time–based production (properly calculated using the takt formula) operates at a pace that supports proper work methods, allows time for quality verification at each station, and reduces the physical stress associated with rushing. Manufacturing operations report substantial reductions in defects when transitioning from maximum-speed production to takt time–based production. Similarly, safety incident rates decline when operators work at a sustainable pace rather than pushing to maximum achievable speed.

Implementing Takt Time Monitoring with FlowFuse

While understanding the theory behind the definition of takt time is important, putting it into practice requires the right tools and approach. FlowFuse provides an industrial automation platform that connects to your existing systems—whether that's PLCs, databases, or ERP software—to automatically calculate takt time in real-time using the takt time formula.

Instead of manually calculating takt time on spreadsheets or relying on static reports, you can build a dynamic monitoring system that updates continuously as customer orders and production conditions change. Let's see how to calculate takt time automatically, but before we begin, make sure you have a FlowFuse instance running. You can create an account here and get it set up quickly.

Step 1: Connect to Your Data Sources

The foundation of accurate takt time calculation is reliable data. FlowFuse supports connections to virtually any industrial system through its extensive library of protocol and database nodes.

In a real implementation where you define takt time based on actual operations, you would pull customer order data from your ERP system, gather production schedules from manufacturing execution systems, connect to PLCs for real-time production counts, and integrate with quality systems for good parts tracking. You can pull customer order data from your ERP system using FlowFuse's integration capabilities.

For this demonstration of how to calculate takt time, we'll simulate customer orders using an Inject node:

Add an Inject node
Configure the payload with this JSONata expression:

   $round($random() * 50 + 50)

Set it to trigger every 5 seconds

This simulates variability in customer demand between 50 and 100 units, demonstrating how the takt time formula responds to changing demand.

Step 2: Calculate Available Production Time

Next, establish the available production time for your shift—a critical component when you calculate takt time. This typically equals your total shift hours minus planned downtime for breaks, maintenance, and changeovers.

Add a Change node
Use the following JSONata expression:

   (8 * 60) - 60

This represents an 8-hour shift (480 minutes) minus 1 hour (60 minutes) for breaks and changeovers, giving 420 minutes of available production time—the numerator in the takt time formula.

Step 3: Automate Takt Time Calculation

Now, apply the takt formula to calculate takt time based on customer demand and available time.

Add another Change node
Configure it with this JSONata expression:

   $round(($number(msg.payload.availableTime) / $number(msg.payload.customer_order)) * 100)/100

This implements the takt time formula automatically: Available Production Time ÷ Customer Demand. The calculation ensures takt time updates dynamically with each new order and produces clean, readable numbers for operators and managers.

Step 4: Create Real-Time Dashboards

Data is most valuable when operators can interpret the meaning of takt time instantly on the shop floor. FlowFuse's dashboard lets you create real-time displays showing calculated takt time using the same intuitive drag-and-drop interface.

Install the FlowFuse Dashboard package via the Palette Manager (@flowfuse/node-red-dashboard)
For basic displays, use text widgets to show current takt time values calculated using the takt formula. For more sophisticated interfaces, the Template widget allows you to create custom components. With FlowFuse AI, you can describe your desired interface in plain English and let the AI generate the appropriate code
Connect the output of the Inject node to the input of the Change node that calculates available production time. Next, connect the output of this Change node to the input of the Change node that calculates takt time using the formula. Finally, connect the output of the takt time Change node to the input of the UI Template node
Next, deploy the flow and open the dashboard to see real-time takt time updates

Real-time takt time monitoring dashboard in FlowFuse showing the takt formula in action

Here's the complete flow we built for automated takt time calculation and visualization with FlowFuse, demonstrating how to calculate takt time in real-time.

Best Practices for Takt Time Implementation

When you understand how to define takt time and apply the takt time formula correctly, implementation success depends on following proven best practices. The meaning of takt time only translates to operational excellence when these principles guide your approach:

Accurate Data: Base your takt time calculation on actual production time, including breaks, changeovers, maintenance, and realistic downtime. Use real customer demand when applying the takt formula and update regularly to maintain accuracy.
Leadership Commitment: Leaders must support implementation visibly, allocate resources, participate in training, and communicate the benefits clearly. Understanding the takt time starts at the top.
Gradual Deployment: Start with a pilot line where you can define takt time clearly, train operators thoroughly, stabilize each phase, and expand gradually. Avoid implementing the takt time across all lines at once.
Lean Integration: Combine takt time (calculated using the proper formula) with value stream mapping, standardized work, and 5S to reduce waste and improve process capability. The meaning of takt time is amplified when integrated with other lean tools.
Visual Management: Use intuitive, visible displays that show calculated takt time and production status at a glance, enabling quick operator action when cycle times exceed the takt time.
Problem Response: Establish escalation procedures, maintain critical spares, station maintenance nearby, and train operators in basic troubleshooting. Quick response preserves the production pace defined by takt time.
Continuous Refinement: Review takt time calculations regularly, analyze performance trends against calculated takt time, and share lessons learned to improve future deployments.

Conclusion

The true meaning of takt time goes far beyond a simple calculation—it's the essential "heartbeat" of lean manufacturing that transforms volatile customer demand into a precise, manageable production rhythm. When you properly define takt time and apply the takt time formula consistently, you expose bottlenecks, balance workloads, and create predictable flow that maximizes resource utilization.

While the takt formula (Takt Time = Available Production Time ÷ Customer Demand) is mathematically simple, its implementation is what separates world-class operations from those plagued by overproduction and constant firefighting. Understanding how to calculate takt time accurately and what the definition of takt time truly means operationally allows you to synchronize your production pace with the market.

By learning to define takt time properly and applying the takt time formula in the right contexts, you expose bottlenecks, balance workloads, and create a predictable flow that maximizes resource utilization. However, manual tracking often leads to lagging data and missed opportunities. Modern industrial platforms like FlowFuse bridge this gap, providing the real-time visibility needed to monitor Takt Time, Cycle Time, and Lead Time automatically across your entire value stream.

Mastering takt time isn't about working faster—it's about working at the right pace. When production is synchronized with demand, every minute on the shop floor creates customer value instead of waste. When you truly understand what it means to define takt time and calculate takt time correctly using the proper formula, you unlock the foundation of lean manufacturing excellence.

Book your demo today to see how FlowFuse can automate your production metrics and help you eliminate waste through real-time data visibility.

FlowFuse 2.22: FlowFuse Expert for node editing, FlowFuse Broker schema autodetection, Improved Snapshots Interface, eCharts enablement, and FlowFuse Dashboard Updates

2025-09-25T00:00:00Z

FlowFuse 2.22 provides more powerful development by bringing the FlowFuse Assistant to more nodes, supports operational maturity with automatic FlowFuse Broker schema detection, and enhances the developer experience with an improved Snapshots interface, support for more powerful visualizations, a better Device Agent Installer experience, Dashboard updates, and more! Take a look:

AI Expert for Node Editing

FlowFuse Expert at work

We've enhanced the capabilities of the FlowFuse Expert, which now provides automatic suggestions to draft and edit your code that extends to Tables nodes, Dashboard Template nodes (ui-template), and Function nodes. You can now simply start typing, and the FlowFuse Assistant will provide code for you based on your context, making the FlowFuse Assistant your AI copilot in Node-RED.

With this change, the FlowFuse assistant can now write HTML, CSS, SQL, Javascript, and JSON, all based on your words, and with awareness of your FlowFuse environment (like your Tables structure), cursor position, and where in your code you are editing.

FlowFuse Team Broker Automatic Schema Detection

Enable schema autodetection for FlowFuse Broker

Documenting a broker schema can be a challenging and time-consuming task, which is why we've provided schema autodetection for the FlowFuse Broker. With the click of a button, our broker will now listen for topics and provide suggestions for the topic schema that you can accept or revise, and these will be added to documentation for your broker.

This will keep your team aligned on message format and serve as a single source of truth for maintaining your Unified Namespace.

Enablement for Apache eCharts

With this release, we are now positioned to enable much more powerful and visually-compelling charts to FlowFuse Dashboard, and have significantly increased chart performance.

We've enabled the use of Apache eCharts. It used to take 8.3 seconds to render 1,000 data points, and now it takes 75 milliseconds -- that is about 111 times faster performance!

While the primary work for Apache eCharts has been to enable the addition of new chart types, we did add one new type of chart: categorical line charts.

Which charts would you like to see added first? Check out these examples of what is now possible, and reach out on GitHub!

Updated Snapshots UI

Manage Snapshots in the new panel

Snapshots are now much easier to manage and interact with.

The Snapshots user interface now provides a centralized place to manage your snapshots, providing a preview of the snapshot, download options, restore, edit name and description, and compare to other snapshots, all in one easy-to-manage location in the right side of the interface.

While the features available for managing Snapshots remain, this update brings those features to the surface in a much cleaner and more intuitive way.

Remote Instance Snapshot Summaries

Speaking of Snapshots: until this release, our automatic snapshot summary feature only worked with hosted instances. As of today, you can now get AI-generated summaries of snapshots of your remote instances as well.

This is especially important for users with large remote instance deployments, and provides an important step forward in enabling FlowFuse users to manage and scale their deployments.

SAML Group Assertions for Dashboard Development

Managing Dashboard permissions when building flows just got easier for Enterprise teams using SSO.

We've added an new option so that a users SSO Group memberships can be included in the user object Dashboard flows receive when a user is logged in. This makes it much easier to build custom permissions into your FlowFuse Dashboard applications, giving you far more flexibility.

Device Agent Installer handles Multiple Remote Instances

We're continuing to work on making the process for installing the Device Agent as simple, easy, fast, and reliable as possible. With this release, the Device Agent Installer can install multiple Device Agents on a single remote device, by allowing you to install the Device Agent in a non-default directory and specify a non-default port. In addition, clearer installation summaries, documentation links, and improved installer output have improved the overall usability of the installer.

Dashboard Fixes

Finally, we've made a number of small fixes that overall improve the Dashboard experience. These include:

Changeable colors on the X-axis
Significantly decreased loading time for ui-chart
Categorical line chart option
Number inputs can be set to decimals
Fixed some display bugs with the display when the sidebar is collapsed or uncollapsed

Sneak Peek

We're excited about a few more features that are just on the verge of being ready to ship! Here's a preview:

Detailed Access Control

Until now, all user permissions in FlowFuse are set at the team level, where each user is either an Owner, Admin, Viewer, or Dashboard-only user, for everything in the team. If you wanted to set different permissions for different applications, you needed to put your application under a team where you had set the permissions you wanted: this made visibility difficult and increased the hassle of managing permissions.

Now, permissions can be set at the application level. If you're a team running many different applications and need to organize who can access what, you are able to do that for each individual appication, significantly increasing the security and management abilities of FlowFuse.

This feature will be available in the next few days - keep an eye on our ChangeLog for updates on when its available.

AI and Machine Vision

Be on the lookout for some very cool applications of AI to machine vision!

What's Next?

In the next release, we'll provide support for building AI agents, real-time streaming protocol, a far more flexible Dashboard, bringing the FlowFuse Assistant to all self-hosted customers, and more! Stay tuned!

What else is new?

For a complete list of everything included in our 2.22 release, check out the release notes.

Which of these new features are you most excited to try? Email me directly at greg@flowfuse.com - I'd love to hear from you!

Try FlowFuse

FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

Get started for free and have your Node-RED instances running in the cloud within minutes.

Self-Hosted

Get FlowFuse running locally in under 30 minutes using Docker or Kubernetes.

Download Node-RED for Production: Windows, Mac, Linux, Raspberry Pi (2026)

2025-09-19T00:00:00Z

Installing Node-RED is straightforward. Install Node.js, run a command, and you're ready for visual programming in industrial automation. The real challenge begins when it must run across production lines, connect to PLCs, and stay operational 24/7.

Download Node-RED for Production Use

Standalone Node-RED works great for testing, but production is different. When your flows control PLCs and critical equipment, downtime costs thousands per minute.

Hardware fails. Networks drop. Power cuts out. Your Node-RED instance must restart automatically, handle connectivity issues, and keep production running without manual intervention. Deploying, managing and scaling must be easy and quick in such environments.

Managing dozens of industrial PCs running Node-RED? You need centralized updates, secure remote access, proper backups, and role-based permissions. Your engineering team's months of flow development can't be lost to a hardware failure.

Production Node-RED needs enterprise reliability, security, and management capabilities that the basic installation simply can't provide.

FlowFuse for Production: Built by Node-RED’s Creator

FlowFuse was co-founded by Nick O'Leary, the creator and project lead of Node-RED. Since creating Node-RED at IBM in 2013, Nick has led its evolution from an internal IoT tool into one of the most widely used low-code platforms for industrial automation, with millions of downloads each year. You can read the history of Node-RED written by Nick here.

After more than a decade of working directly with enterprise users deploying Node-RED in production environments, Nick and the FlowFuse team built FlowFuse to address the operational challenges that standalone Node-RED cannot solve at scale.

FlowFuse makes Node-RED production-ready through centralized management across industrial infrastructure, incorporating years of real-world deployment experience from the creator of Node-RED himself.

Enterprise Reliability from Node-RED Experts

When hardware fails, FlowFuse keeps operations running through High Availability mode that distributes processing across multiple instances. Device Agents monitor system health and provide secure remote access for engineering teams—features designed by the same team that built and maintains Node-RED's core architecture.

Engineering teams get proper DevOps workflows that move flows through development, testing, and production with automated deployments. Device grouping makes updates reach thousands of devices possible while version control and rapid rollbacks keep projects on track.

Enterprise security comes built-in with single sign-on, role-based access control, comprehensive audit logging, and encrypted communications. Automated snapshots protect engineering work with rapid recovery when needed.

These core capabilities are just the foundation—FlowFuse includes dozens of additional features designed specifically for industrial environments, refined through direct experience deploying Node-RED across Fortune 500 manufacturers and critical infrastructure.

Trusted by Industry Leaders

FlowFuse is deployed in production environments across manufacturing, energy, and infrastructure sectors where Node-RED reliability is mission-critical. The platform's architecture reflects over 12 years of Node-RED development expertise and direct feedback from thousands of industrial deployments.

As the official enterprise solution developed by Node-RED's creator, FlowFuse represents the authoritative approach to production Node-RED deployments, backed by the team with the deepest expertise in the technology.

Setting Up FlowFuse

Step 1: Add Remote Instance

Once the platform opens:

Click on Remote Instances from the left sidebar

FlowFuse platform dashboard showing Remote Instances option

Click Add Remote Instance

Button to add a new remote Node-RED instance

Give it a name and select the device type

Configuring the remote device instance with name and type

Select your application and click Add

Step 2: Install Device Agent

FlowFuse shows you a device configuration window with two options. The One-Line Install handles everything automatically. It installs Node.js if missing, installs the device agent, and registers your device with the platform.

The NPM Installation method provides manual instructions for Windows, Mac, or Linux.

Device configuration window showing installation options for the FlowFuse Device Agent

Follow the steps given within the window, which takes less than a minute to connect your device.

Step 3: Manage Your Device

Once registered, you get complete control over your remote Node-RED instance through FlowFuse's management interface:

Tools for managing Node-RED instance remotely via FlowFuse

There are even more features available at the application level and team level that you can explore. To remove infrastructure management complexity of required services such as MQTT and PostgreSQL, they are built-in and available for use.

Step 4: Start Building

To start building flows:

Enable Developer Mode from the top right

Developer Mode Option

Click Open Editor

Open Editor Option

Your automation flows now run with production reliability. Remote access works securely, and your team can collaborate while production continues running.

Node-RED Editor

Up Next

FlowFuse bridges the gap between Node-RED's simplicity and production reliability requirements—built by the people who created Node-RED and understand its production needs better than anyone.

Ready to see FlowFuse in action? Book a demo and we'll show you how it works with your setup.

Query Your Database with Natural Language Using FlowFuse Expert

2025-09-18T00:00:00Z

Getting data from your database used to mean writing SQL queries. Not anymore. The FlowFuse Expert now lets you ask for what you want in plain English and automatically generates the SQL for you in query node.

Removing Technical Barriers

Industrial operations generate massive amounts of valuable data from sensors, equipment, and PLCs. This data can drive optimization and cost savings, but extracting insights often requires SQL skills that not every team member possesses.

FlowFuse already makes it simple to connect to databases and build data flows using its Query nodes. However, the need to manually write SQL queries has remained a significant barrier for many users.

To address this, FlowFuse continues its mission of making industrial automation accessible to everyone, regardless of coding expertise. Features like the FlowFuse Expert have already reduced complexity by enabling users to create custom functions and UI components using natural language.

With FlowFuse 2.21, this ease of use extends to database queries as well. Users can now ask questions in plain English and have SQL automatically generated, removing the last major hurdle and empowering a broader audience to gain actionable insights quickly and easily.

Getting Started

Let's see how this works with a practical example. This feature combines two FlowFuse components:

FlowFuse Tables provides the database connectivity and Query nodes
FlowFuse Expert adds the natural language processing capability that converts plain English into SQL

Before you begin, make sure FlowFuse Tables is activated in your FlowFuse team. For more information, refer to Getting Started with FlowFuse Tables. Then, import the following flow and deploy it to create a sensor_readings table for practice:

After deployment, press the "Insert simulated Data" inject button to populate your table with a week's worth of hourly sensor readings. This sample data will help you explore Query node capabilities.

Note: FlowFuse Tables is currently available for Enterprise users only.

Now, let us test the natural language querying powered by the FlowFuse Expert:

Add an Inject node to your flow
Connect it to your Query node
Open the Query node and locate the new "Assistant" codelens
Enter: "Show me all readings from today"
Click Ask the FlowFuse Expert. The FlowFuse Expert will process your natural language request and automatically generate the corresponding SQL query in the Query node's SQL field. Click Done.
Connect a Debug node to see the results
Deploy the flow and click the Inject button to test it.

FlowFuse Expert in Query Node

Practical Query Examples

With your sample data in place, here are some immediately useful queries to try:

Performance Analysis

Track temperature averages:
Prompt: "What's the average temperature for this week?"

Identify peak readings:
Prompt: "Find the highest temperature reading this month"

Time-Based Analysis

Hourly patterns:
Prompt: "Average temperature per hour today"

Advanced Query Capabilities

Beyond basic queries, the FlowFuse Expert can handle sophisticated analysis:

Complex filtering:
Prompt: "Show readings where temperature > 20, temperature < 25, and temperature ≠ 22"

Statistical operations:
Prompt: "Calculate standard deviation of temperature readings this month"

These examples demonstrate how the FlowFuse Expert simplifies advanced analysis, turning complex database operations into easy, natural-language requests.

What's Next

The FlowFuse Expert now brings natural language capabilities to database queries in FlowFuse Tables. This removes the complexity of SQL, allowing industrial teams to extract insights using simple conversational commands.

FlowFuse's mission has always been to democratize industrial automation and reduce complexity for engineers and operational teams. As part of this commitment, more AI-powered features are on the roadmap to simplify industrial workflows even further.

Ready to transform how your team works with data? Book a demo and see how FlowFuse makes building industrial applications simple and accessible.

Integrating LoRaWAN with FlowFuse

2025-09-17T00:00:00Z

LoRaWAN (Long Range Wide Area Network) is a low-power wireless protocol designed for IoT devices that need to transmit small amounts of data over long distances. FlowFuse is a platform that provides a visual programming interface for connecting IoT devices and services.

By combining LoRaWAN with FlowFuse, you can easily collect data from remote sensors, process it, and integrate it with other systems or dashboards—all without writing complex code. In this article, we will guide you through setting up the integration and creating your first data processing flows.

What is LoRaWAN and How Does It Work?

LoRaWAN is designed for devices that need to send small amounts of data over long distances while using very little battery power. Your sensors can communicate up to 15 kilometers away and run for years on a single battery.

The system has three main parts:

End devices - Your sensors that collect and send data
Gateways - These receive data from your sensors and pass it along
Network server - Manages everything and sends your data to applications

The Things Network (TTN) is a free, global LoRaWAN network with thousands of gateways around the world. It's perfect for getting started with LoRaWAN projects and provides easy-to-use tools for managing your devices.

We'll show you how to connect TTN to FlowFuse for monitoring sensor data and building scalable industrial applications.

Getting Started

Now that we understand the basics of LoRaWAN, let's set up the integration with FlowFuse.

Prerequisites

Before we begin, make sure you have the following components ready:

Node-RED instance – Ensure you have a running Node-RED instance. The quickest way to set one up is through FlowFuse. Sign up, create your instance, and you will be able to manage, deploy, scale, and secure your flows with ease. FlowFuse also provides enterprise-ready features out of the box.
LoRaWAN device and gateway registered on TTN – You need a sensor or device connected to TTN and a gateway that can receive its uplinks.

If you do not have a LoRaWAN device, you can simulate one using available tools. For this article, I am using the LWN-Simulator.

Setting Up TTN MQTT Connection

TTN provides MQTT integration that allows external applications to receive uplink messages from your devices. We'll use this to connect TTN with FlowFuse.

Getting TTN Connection Details

Log into your TTN Console (https://console.thethingsnetwork.org)
Navigate to your application
Go to the Other Integrations tab and select MQTT
Note down the following connection details:
- Server Address: Depends on your cluster, for example: nam1.cloud.thethings.network
- Port: 1883 (for non-TLS) or 8883 (for TLS)
- Username: Your application ID
- Password: Your API key

Screenshot of TTN console showing MQTT integration details including server address, port, username, and API key

Configure MQTT Node and Receiving Uplink Messages

Uplink messages are data transmissions sent from your LoRaWAN sensors and devices to Network and then forwarded to your applications. These messages contain sensor readings, status updates, or any other data your devices collect. Let's configure FlowFuse to receive these uplink messages.

Open your FlowFuse instance Editor.
Drag an MQTT In node from the palette onto your workspace
Double-click the node to configure it:
- Server: Add a new MQTT broker configuration
- Host: Enter your TTN server address (e.g., nam1.cloud.thethings.network)
- Port: 1883 or 8883 (if using TLS)
- Username: Your TTN application ID
- Password: Your TTN API key
- Topic: v3/{application-id}/devices/{device-id}/up (replace with your actual application and device IDs)
Click Done to save the configuration
Connect a Debug node to the output of your MQTT In node
Deploy the flow by clicking the Deploy button
Open the Debug panel to see incoming messages from your LoRaWAN device

The messages you receive will be in JSON format and contain various fields as following:

Field	Description
end_device_ids.device_id	Unique identifier of the device in TTN
end_device_ids.dev_eui	Globally unique hardware identifier (EUI) of the device
end_device_ids.join_eui	Identifier used during device activation (JoinEUI/AppEUI)
end_device_ids.dev_addr	Device address assigned by the network
received_at	Timestamp when TTN received the message
uplink_message.f_port	LoRaWAN port number (used to separate types of payloads)
uplink_message.f_cnt	Frame counter for tracking uplinks
uplink_message.frm_payload	Raw payload
uplink_message.decoded_payload	Decoded values (requires a payload formatter in TTN)
uplink_message.rx_metadata	Metadata per gateway (includes RSSI, SNR, gateway ID, etc.)
uplink_message.settings	Radio parameters (frequency, data rate, spreading factor, etc.)
uplink_message.received_at	Timestamp when TTN processed the uplink
correlation_ids	IDs used internally to correlate events across the TTN stack

Processing Data

Let's add some processing to extract and format the received data. This approach uses community-contributed nodes and requires minimal coding. Install the node-red-node-base64 and node-red-contrib-buffer-parser nodes.

Drag a Change node and set msg.payload to msg.payload.uplink_message.frm_payload
Drag a base64 node and set the action to "Decode" (converts Base64 string to Buffer)
Drag the buffer parser node and configure elements based on your data format
Click the "+" button to add each element and fill in the following fields for each data point you want to extract:

Example Configuration for Temperature/Humidity Sensor:

Element	Type	Name	Length	Offset	Scale
1	int16be	temperature	2	0	0.01
2	int16be	humidity	2	2	0.01

Quick Parameter Guide:

Type: How to read the bytes (int16be = 2-byte big-endian signed integer, uint8 = 1-byte unsigned integer)
Name: What to call it in your output (becomes msg.payload.temperature)
Length: Number of bytes to read (2 for int16be, 1 for uint8)
Offset: Where to start reading (0 = first byte, 2 = third byte, etc.)
Scale: Math to apply (0.01 = divide by 100, 1 = no scaling)

Connect the MQTT in node to the input of change node, change node output to base64 node and base64 node output to the input of buffer parser and add the debug node at the end to see the output.
Deploy the flow.

Now you will see the object with the parsed sensor data in the debug panel. The output will show something like:

{
  "temperature": 21.5,
  "humidity": 57.2
}

As you can see in the image below, TTN console shows live data with uplink message on the left side, and FlowFuse successfully reads and processes it on the right side.

Image showing TTN console with live uplink messages on the left and FlowFuse debug panel with processed sensor data on the right

Sending Commands to Devices (Downlink)

Downlink messages are commands sent from your application back to LoRaWAN devices through the network. These messages allow you to remotely control your devices, update their configuration, trigger specific actions, or send firmware updates. LoRaWAN devices can only receive downlink messages during their receive windows after sending an uplink, making this communication asynchronous but highly power-efficient.

Drag the Inject node onto the canvas.
Drag a Function node and add JavaScript to format the downlink message with the data you want to send. Alternatively, you can use a Change node with a Base64 node for a low-code approach.

// Example: Send a command to turn on LED or change sensor interval
const downlinkMessage = {
    downlinks: [{
        f_port: 1, // Port number (1-223)
        frm_payload: Buffer.from([0x01, 0x0A]).toString('base64'), // Command bytes
        priority: "NORMAL"
    }]
};

msg.payload = JSON.stringify(downlinkMessage);
return msg;

Downlink Properties Explanation:

f_port: The LoRaWAN port number (1-223) used to differentiate message types
frm_payload: Your command data encoded as Base64 string
priority: Message priority ("LOWEST", "LOW", "BELOW_NORMAL", "NORMAL", "ABOVE_NORMAL", "HIGH", "HIGHEST")

Add an MQTT Out node to your workspace
Configure it with the same TTN broker settings as your MQTT In node
Set the topic to: v3/{application-id}/devices/{device-id}/down/push (replace with your actual application and device IDs)
Connect the Inject node to Function node and Function node to MQTT out node.
Deploy the flow.

In the image below, you can see FlowFuse sending and processing the downlink message, while TTN console displays the live data on the left.

Image showing TTN console with live Downlink messages on the left and FlowFuse debug panel with processed sensor data on the right

Next Steps

Next, you can store this data in a database. With FlowFuse, a managed PostgreSQL database is already provided—so you do not need to install or configure one manually. FlowFuse also offers a Query node that is automatically configured for your instance. Inside the Query node, you can use FlowFuse Expert, which allows you to write natural language prompts instead of SQL queries. The assistant will generate SQL automatically based on your table schema.

For a complete guide on storing and visualizing data, see the article on Building Historical Data Dashboards with FlowFuse Tables. It also includes step-by-step instructions for creating dashboards using FlowFuse Dashboard—a low-code way to build powerful industrial dashboards that also allows you to send downlink data to devices interactively.

With FlowFuse, you get a complete enterprise-grade platform built around visual programming—perfect for production-ready IoT deployments. It adds powerful capabilities like centralized management of Node-RED instances, DevOps tools, snapshots, real-time team collaboration, audit logs, RBAC, SSO, Built mqtt broker and database service and more—all designed to help you scale and manage your applications with ease.

If you're interested in exploring FlowFuse further for your industrial IoT applications, come visit us at our booth at upcoming TTN conferences to see live manufacturing demos. You can also book a demo to see how FlowFuse can streamline your development and deployment workflows, or start your free trial and build your first LoRaWAN-enabled dashboard today.

Poka Yoke (Poke Yoke, Bokayoke) Explained: Definition, Examples, Types (2026)

2025-09-11T00:00:00Z

Every day, skilled operators make mistakes that cost thousands. A component installed backwards. A critical step skipped during rush orders. A measurement misread at shift's end.

The shocking truth? Human errors account for nearly 23% of manufacturing defects worldwide, costing businesses billions annually. But here's what's different: companies implementing poka yoke have reduced defects by up to 50% and increased production efficiency by 30%.

What if the problem isn't your people—but your processes?

What Does Poka Yoke (Often Misspelled as Bokayoke or Poke Yoke) Mean and Where Did It Come From?

Poka yoke (pronounced "POH-kah YOH-kay") is a Japanese term that means "mistake-proofing" or "error prevention." The phrase comes from "poka o yokeru" (ポカを避ける)—literally, avoiding an unthinkably bad move in the game of shogi. While it's sometimes misspelled as bokayoke or poke yoke, and formally written as poka-yoke with a hyphen, the correct term is poka yoke.

In 1961, a Japanese electronics plant faced a staggering 25% defect rate. Workers kept missing tiny springs in switch assemblies—not due to carelessness, but because the repetitive handling of microscopic components made mistakes inevitable.

Toyota engineer Shigeo Shingo introduced a simple but revolutionary solution: a fixture holding exactly two springs for each assembly. Workers had to remove both springs before starting their task, instantly highlighting any incomplete assembly. As a result, defects dropped to zero overnight—without additional training.

Originally called "baka-yoke" (idiot-proofing), the technique was renamed poka yoke after a worker objected, emphasizing that human errors are natural, not a reflection of intelligence.

Shingo made a key distinction between human mistakes and production defects. Mistakes happen—they're part of being human. Defects occur when those mistakes reach the customer. Poka yoke focuses on designing processes so mistakes are immediately detected and corrected, eliminating defects at the source. This philosophy shifts manufacturing focus: rather than trying to perfect human behavior, perfect the systems in which humans work.

Poka Yoke Definition?

Poka yoke is a systematic approach that uses automatic devices or methods to either make errors impossible or make them immediately obvious once they occur. It's any mechanism that helps equipment operators avoid mistakes by preventing, correcting, or drawing attention to human errors as they happen.

The poka yoke meaning extends beyond simple error prevention. Rather than treating errors as moral failures or training deficiencies, it treats them as design problems. This lean manufacturing approach recognizes that even the most skilled workers experience moments of distraction, fatigue, or cognitive overload.

Traditional quality control detects defects after they occur, requiring inspection, rework, and often scrapping of materials. The poka yoke approach prevents defects during production by making errors physically impossible or immediately visible. This prevention-first approach creates a cascading effect: quality control teams focus on complex issues rather than basic errors, workers gain confidence in their processes, customer satisfaction improves through consistent product quality, and excellence becomes the natural outcome rather than a heroic achievement.

If you prefer a video format, watch this short and clear video explaining what poka yoke is:

Why Is Poka Yoke Important for Manufacturers?

The impact of mistake-proofing extends far beyond just catching errors. By designing assembly processes that are mistake-proof, poka yoke prevents defects from occurring in the first place rather than inspecting quality issues later. Companies achieve defect rates measured in parts per million rather than percentages.

Errors in manual assembly lead to increased scrap rates, rework, and delays—all contributing to higher production costs. By eliminating errors at the source, the cost of mistakes within a company is reduced significantly. Companies implementing poka yoke techniques saw a 25% increase in productivity, with time previously spent correcting errors now available for value-added activities.

Mistake-proofing creates safer processes by eliminating conditions that lead to accidents. When errors can literally mean life or death (as in pharmaceutical manufacturing), poka yoke becomes mission-critical. Workers experience less frustration from rework and greater confidence in their processes, leading to improved morale. Successful implementation leads to a 20% improvement in customer satisfaction through consistent product quality and reliability.

The benefits of poka yoke in manufacturing deliver measurable business outcomes: defect elimination achieving near-zero defects, waste reduction across the eight forms identified in lean manufacturing, process simplification turning complex procedures into straightforward steps, real-time correction catching mistakes immediately rather than weeks later, scalable quality built into the system rather than dependent on individual heroics, and continuous improvement creating a foundation for ongoing kaizen activities.

Poka Yoke Types?

Understanding the types of poka yoke helps you choose the right approach for your specific error prevention needs.

The contact method identifies product defects by testing the product's shape, size, color, or other physical attributes. This uses physical design features to make mistakes impossible. Diesel fuel nozzles are sized larger than gasoline tank openings—you literally can't put diesel in a gas car. USB-C connectors only fit one way, preventing incorrect insertion. Parts with unique shapes only fit correctly in assembly fixtures, and machine guards prevent equipment operation until properly closed. This is the most effective mistake-proofing method because it makes errors physically impossible.

Fixed-value methods often involve measurement devices such as scales or counters to prevent or identify nonconformances. These build the right limits directly into your tools. Torque wrenches automatically stop at correct force. Parts trays hold exactly the number of components needed—leftovers indicate a missing part. Automated pill dispensers count exact doses, weight verification systems ensure complete assemblies, and digital counters track the number of operations performed. If there are leftover parts or incorrect counts, something's wrong—and you know immediately.

Motion-step methods focus on ensuring operators perform the right steps in the correct sequence. These force the correct sequence of operations. Lockout/tagout systems prevent equipment access until safety steps are complete. CNC machines require tool verification before program execution. Assembly stations physically prevent advancement until the current step is finished, sequential interlocks ensure proper startup and shutdown procedures, and guided work instructions must be completed in order. These turn complex procedures into foolproof, step-by-step processes.

Beyond these three detection methods, poka yoke systems function in two fundamental ways: control-based and warning-based. Control poka yoke actually prevents the mistake from being made, making it mechanically or electronically impossible for errors to occur. Think of a car transmission requiring "Park" or "Neutral" to start, or computer forms that won't submit until all required fields are filled. Use this when errors must be prevented entirely, especially for safety-critical operations. Warning-based poka yoke alerts operators to occurring or soon-to-occur defects, relying on human intervention to stop and correct errors. Examples include backup sensors beeping when you're too close to an obstacle, warning lights indicating missing components, or Outlook reminding you about missing attachments. The key difference: control systems stop the process automatically; warning systems rely on human response.

What Are the 6 Steps of Poka Yoke Mistake-Proofing?

Implementing poka yoke follows a systematic six-step process that ensures effective error prevention.

Step 1: Identify the Problem. Create a detailed process flowchart mapping every operation, no matter how small. Review each step to determine where human errors are likely to occur, which can involve using the 5 Whys technique. Where do defects occur most frequently? Which errors have the highest impact? What causes operators the most difficulty? Use tools like Pareto analysis to prioritize—typically 80% of defects come from 20% of causes. Before implementing any mistake-proofing tools or poka yoke devices, you need to identify your most frequent quality problems. A Pareto chart analysis helps you prioritize which defects cause 80% of your quality issues, ensuring you focus your poka yoke efforts where they'll have maximum impact. Learn how to create effective Pareto charts for quality analysis

Step 2: Analyze Root Causes. Once every potential error is found, work through the process to find the root cause. Don't just identify when errors occur—understand why they happen. Use techniques like 5 Whys analysis, fishbone diagrams, process mapping, Failure Mode and Effects Analysis (FMEA), and gemba walks (go see where work happens). Understanding root causes prevents implementing complex solutions for simple problems.

Step 3: Design the Solution. Design solutions in the process to eliminate the risk of the error ever happening, which can include eliminating the step or replacing it with a mistake-proof step. The solution hierarchy from most to least effective includes elimination (remove the error-prone step entirely), replacement (substitute with an error-proof alternative), facilitation (make correct actions significantly easier than errors), detection (identify errors immediately when they occur), and mitigation (minimize effects if errors reach this point). The four key principles are elimination, prevention, detection, and mitigation.

Step 4: Choose the Implementation Method. Select the appropriate mistake-proofing technique based on your specific situation. Consider inspection methods like source inspection (checks before the process step occurs), self-inspection (workers check their own work immediately), or successive inspection (next worker verifies previous step). Choose setting functions such as contact/physical checks, fixed-value counting or weighing, motion-step sequence verification, or information enhancement for visibility. Decide on regulatory functions including warning signals (lights, buzzers, colors) or control mechanisms (preventing advancement).

Step 5: Test the Poka Yoke. A poka yoke pilot project will help you iron out any issues with the process before introducing it to your shop floor. Does it prevent or detect the target error? Does it slow down production unacceptably? Can it create new safety hazards? Does it introduce new failure modes? Do operators understand and accept it? Is it cost-effective? Start small, validate effectiveness, then scale up.

Step 6: Implement and Monitor. Roll out the solution with proper training and documentation. But implementation isn't the end—it's the beginning of continuous improvement. Monitor error rates before and after implementation, track effectiveness metrics, gather operator feedback, make adjustments as needed, apply successful solutions to similar processes, and update FMEA documentation. Remember: poka yoke is about continuous improvement, not one-time fixes.

Poka Yoke Examples

The automobile industry showcases poka yoke transformative applications across assembly lines and production processes. Toyota's implementation includes fixtures that physically prevent incorrect part installation and sensors that detect missing components before products advance to subsequent stations. These systems have helped achieve defect rates measured in parts per million rather than percentages, setting industry standards for quality excellence.

Electronics manufacturing demonstrates sophisticated applications in high-precision environments. Component placement machines verify correct parts before PCB assembly, preventing costly defects that would be difficult or impossible to correct later. Color-coded component storage and automated inventory systems ensure operators select correct parts while maintaining production speed and efficiency.

Pharmaceutical production represents perhaps the most critical mistake-proofing applications, where errors can literally mean life or death. Automated dosing systems prevent medication errors, while segregated production lines eliminate cross-contamination risks. Barcode scanning and weight verification create multiple checkpoints that ensure accurate formulations without slowing production processes.

You encounter mistake-proofing daily in everyday life, often without noticing. In your car, manual transmissions require clutch depression to start, automatic transmissions require "Park" or "Neutral" to start, seat belt warnings sound until buckled, and keys must be in the ignition to remove from "Park." Technology examples include USB connectors that only fit one orientation, spell-check catching errors as you type, email reminders about missing attachments, forms preventing submission until all fields are complete, and phone warnings before deleting photos. Around your home and office, overflow drains prevent bathtub floods, three-prong plugs ensure proper grounding, microwave doors stop operation when opened, hotel room keycards control energy consumption, and pen clips retract tips to prevent pocket damage.

Is Poka Yoke Right for You?

Poka yoke is particularly valuable when you're experiencing repetitive defects that training alone can't fix, high-volume production where small error rates create massive waste, safety-critical operations where mistakes could cause injury, complex assemblies with multiple potential error points, or processes where inspection after production is too late or too expensive.

However, poka yoke isn't always the answer. For truly unique, one-off custom work, the investment in mistake-proofing devices may not be justified. When processes change frequently, rigid mistake-proofing systems can become obstacles. In highly creative work where "mistakes" sometimes lead to innovation, too much control can stifle breakthroughs.

The key question: Are errors systematic or random? If the same mistakes happen repeatedly, poka yoke is your solution. If every error is unique and unpredictable, focus on training and skill development instead.

How to Implement Poka Yoke in Your Manufacturing Processes

Successful poka yoke implementation begins with systematic error pattern analysis through root cause investigation and detailed process mapping. Understanding why errors occur—rather than just when they occur—enables targeted mistake-proofing techniques that address underlying causes rather than symptoms. This analytical foundation prevents the common mistake of implementing complex solutions for simple problems.

Employee involvement throughout the design process proves crucial for successful adoption. Operators who participate in solution development understand the reasoning behind changes and can provide valuable insights about practical implementation challenges. Their buy-in transforms potential resistance into enthusiastic support for quality improvement initiatives aligned with poka yoke principles.

Testing and refinement cycles validate system effectiveness before full-scale deployment. Pilot implementations reveal unexpected challenges and opportunities for improvement while building confidence in proposed solutions. This iterative approach prevents costly mistakes and ensures solutions work effectively in real production environments.

Start simple by focusing on obvious, high-impact problems using basic mistake-proofing examples before tackling complex issues. Prioritize cost-effective solutions and devices that deliver measurable results. Include operators in design for better adoption rates, following kanban poka yoke and kaizen principles. Build mistake-proofing into standard operating procedures and integrate it with Six Sigma methodologies. Conduct regular reviews and enhancements of existing systems for continuous improvement.

Modern Digital Poka Yoke: Engineering Mistake-Proof Systems

The future of poka yoke increasingly incorporates Industry 4.0 technologies that expand traditional concepts. IoT sensors provide real-time capabilities that detect deviations instantly, while machine learning algorithms identify subtle patterns that predict potential failures before they occur. These advanced digital tools complement rather than replace fundamental poka yoke principles.

Modern smart manufacturing systems integrate digital work instructions that guide operators through complex procedures step-by-step, ensuring consistency while accommodating process variations. Adaptive tooling automatically adjusts parameters based on real-time measurements, preventing specification deviations while maintaining production efficiency.

FlowFuse enables sophisticated poka yoke implementations by connecting IoT sensors, machine data, and quality control systems in real-time workflows. Manufacturing teams can build automated solutions that trigger immediate alerts, stop processes when deviations occur, and guide operators through corrective actions—all without complex programming or expensive custom solutions. To learn more or see it in action, you can book a demo or get in touch with the team.

Conclusion

The poka yoke technique represents more than a quality improvement method—it embodies a fundamental shift toward designing human error out of manufacturing processes. By accepting human fallibility and engineering around it, manufacturers achieve consistent quality while reducing costs and improving employee satisfaction.

The method's enduring relevance in an era of smart manufacturing demonstrates that the most powerful solutions often combine simple principles with sophisticated execution. Whether you're implementing basic mistake-proofing devices or advanced IoT-enabled systems, the core philosophy remains unchanged: make errors impossible, or make them immediately obvious.

The question isn't whether poka yoke works—decades of success across industries prove it does. The question is: which errors in your process are you ready to eliminate forever?

References

Shingo, Shigeo. "Zero Quality Control: Source Inspection and the Poka-Yoke System." Productivity Press, 1986.
Liker, Jeffrey K. "The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer." McGraw-Hill Education, 2004.
Robinson, Harry. "Using Poka Yoke Techniques for Early Defect Detection." International Conference on Software Testing, 1999.
Womack, James P., Jones, Daniel T. "Lean Thinking: Banish Waste and Create Wealth in Your Corporation." Free Press, 2003.
ASQ Quality Press. "The Certified Quality Engineer Handbook, Fourth Edition." American Society for Quality, 2013.
Toyota Motor Corporation. "Toyota Production System: Beyond Large-Scale Production." Productivity Press, 1988.
Pyzdek, Thomas, Keller, Paul. "The Six Sigma Handbook: A Complete Guide for Green Belts, Black Belts, and Managers." McGraw-Hill Education, 2014.

What is 5S Checklist: Definition, Benefits, Implementation, and Template

2025-09-10T00:00:00Z

Manufacturing environments face increasing pressure to eliminate waste, improve safety, and maintain quality standards. Disorganized workspaces contribute to production delays, safety incidents, and quality defects that directly impact operational performance. The 5S methodology addresses these challenges through systematic work area organization, but implementation requires consistent evaluation and measurement. A 5S checklist provides the structured framework necessary to assess, maintain, and improve work area organization standards across manufacturing operations.

Understanding 5S Methodology

The 5S methodology originated in Japanese manufacturing and has become the gold standard for work area organization worldwide. The name comes from five Japanese words that each begin with 'S', representing a systematic approach to creating efficient, safe workspaces:

Sort (Seiri) means removing everything that doesn't belong in your workspace. This involves ruthlessly eliminating "just in case" items that create clutter and reduce efficiency.
Set in Order (Seiton) gives everything that remains a logical, designated home based on frequency of use and workflow patterns.
Shine (Seiso) focuses on cleanliness that reveals problems early. Oil leaks, wear patterns, and safety hazards become immediately visible in clean environments.
Standardize (Seiketsu) creates consistent procedures so everyone follows identical organizational principles across shifts and departments.
Sustain (Shitsuke) builds the culture and accountability systems needed to maintain improvements permanently.

The challenge isn’t just understanding these concepts; it’s implementing them consistently across different operations.

What Makes a 5S Checklist Essential

A 5S checklist transforms abstract organizational principles into concrete, measurable actions with specific evaluation criteria. Instead of subjective opinions about workspace organization, teams get objective standards: Is every tool in its designated shadow board outline? Are walkways completely obstacle-free? Can someone new find required materials within two minutes?

Beyond simple evaluation, these checklists serve as training tools for new employees, communication devices between shifts, historical records showing improvement trends, and accountability systems that prevent 5S from becoming another forgotten initiative.

Essential 5S Checklist Items Every work area Needs

While each work environment requires specific evaluation criteria, certain fundamental items should be included in every 5S checklist. Here is a practical framework of 25 questions that you can adapt for your operations.

Sort

Are workstations free of unnecessary materials, tools, and equipment?
Have outdated documents and reference materials been removed?
Are broken or obsolete items properly tagged for disposal?
Do storage areas contain only frequently used items?

Set in Order

Is every tool in its designated location with clear identification?
Are frequently used items positioned within easy reach?
Are visual management systems (labels, shadow boards, floor markings) clearly visible?
Can workers retrieve needed items without searching or moving obstacles?

Shine

Are all surfaces, equipment, and floors properly cleaned?
Are maintenance schedules current and inspection logs up-to-date?
Are cleaning supplies readily available and properly stored?
Are leaks, spills, and abnormal conditions immediately visible?

Standardize

Are work instructions current, accessible, and consistently followed?
Do similar workstations follow identical organizational principles?
Are all team members trained on current 5S standards?
Are procedures regularly reviewed and updated?

Sustain

Do workers maintain organizational standards without constant supervision?
Are team members actively identifying improvement opportunities?
Do supervisors regularly participate in evaluations and improvements?
Are 5S achievements recognized and celebrated?

The Real Impact on Your Operations

Companies that implement 5S checklists consistently report dramatic improvements that go far beyond having a tidy workspace. Workers typically spend less time searching for tools and materials once proper organization takes hold. This isn't just about efficiency, it's about frustration levels and job satisfaction too.

Safety improvements often exceed expectations. When everything has a proper place and workspaces stay clean, accident rates can drop. Spills get noticed and cleaned immediately instead of becoming slip hazards. Tools don't get left in walkways where someone might trip.

Quality improvements follow naturally from better organization. Clean, well-organized environments make it easier to spot problems before they become defects. When workers aren't rushed or frustrated from searching for materials, they make fewer mistakes. The predictability of well-organized processes reduces variability in outcomes.

Perhaps surprisingly, employee engagement often increases significantly. Teams take pride in maintaining organized workspaces, especially when they participate in regular evaluations and see their scores improve over time. The checklist process gives everyone a voice in work area improvement.

Making Implementation Work

Starting a successful 5S checklist program requires more than distributing forms. Begin with leadership commitment and comprehensive training so everyone understands both the evaluation process and its connection to their daily work experience.

Create area-specific checklists rather than generic ones. A machine shop needs different evaluation criteria than an assembly line or office environment. While core 5S principles remain constant, specific items should reflect each workspace's unique requirements.

Establish regular evaluation cycles: daily quick checks for immediate problems, weekly detailed reviews for improvement planning, and monthly comprehensive evaluations for trend analysis. The crucial element many programs miss is systematic follow-through. Identifying problems only creates value when those problems get solved with assigned responsibility and completion tracking.

The Digital Advantage with FlowFuse

Traditional paper checklists have inherent limitations. Results get lost, data analysis becomes time-consuming, and accessing information from multiple locations proves challenging. Digital solutions eliminate these problems while adding capabilities that paper cannot match.

FlowFuse's low-code Node-RED interface makes building sophisticated 5S checklist applications accessible without extensive programming backgrounds. You can create custom evaluation forms capturing exactly the information your operation needs. Simple yes/no questions, numerical scores, or detailed condition comments.

As an industrial data platform, FlowFuse enables seamless integration of 5S checklists into broader operational workflows, connecting work area organization efforts with real-time factory data for comprehensive improvement insights.

Mobile access transforms team interaction with the evaluation process. Workers complete checklists on tablets or smartphones directly in work areas, take photos documenting conditions, and immediately see how current scores compare to previous evaluations. This real-time feedback creates engagement impossible with paper forms.

Up next

If you want to start immediately without creating a checklist from scratch, FlowFuse’s pre-built 5S Checklist Blueprint is ready to use. It includes 25 evaluation questions to assess work area organization, scoring to measure compliance, and follow-up tracking to ensure issues are resolved. The dashboard provides a clear view of improvements over time, and the entire system is fully customizable to match the unique needs of your operations.

Ready to Transform Your Work Area?

Get started with FlowFuse's customizable 5S Checklist Blueprint and build your digital evaluation system in minutes.

Explore 5S Checklist Blueprint →

IT vs OT: Key Differences, Security Risks, and IT/OT Convergence

2025-09-08T00:00:00Z

IT vs OT is one of the most critical distinctions in modern manufacturing, representing two fundamentally different technology ecosystems: Information Technology (IT) and Operational Technology (OT). Understanding how these systems differ—and how to secure and integrate them—isn’t just a technical necessity. It’s a competitive advantage that prevents downtime, reduces cyber risk, and unlocks operational efficiency.

What is Information Technology (IT)?

Information Technology encompasses the systems, software, and infrastructure that manage your business data and enable enterprise operations. IT systems handle everything from email and databases to enterprise resource planning (ERP), customer relationship management (CRM), and business intelligence platforms.

Your IT infrastructure manages data storage and processing, enterprise communications like email and video conferencing, business applications for finance and accounting, and customer and supplier management systems. These systems increasingly rely on cloud services and software-as-a-service applications that enable flexible, scalable operations.

The defining characteristics of IT systems reflect their business-oriented nature. They prioritize data confidentiality and integrity above all else, stay connected to external networks and the internet for collaboration and communication, and receive regular updates and patches on monthly or quarterly cycles. IT systems use standardized protocols like TCP/IP, HTTP, and HTTPS that enable straightforward connectivity. Most IT equipment has a typical lifecycle of three to five years before replacement, designed with flexibility and scalability as core requirements. When IT systems need maintenance, businesses can usually tolerate downtime measured in minutes to hours.

What is Operational Technology (OT)?

Operational Technology refers to the hardware and software systems that monitor and control physical devices, processes, and infrastructure in industrial environments. OT directly manages your production operations, making it the backbone of manufacturing execution.

OT systems include Industrial Control Systems (ICS), which serve as the umbrella term for all control systems used in industrial operations. Within this category, you'll find Supervisory Control and Data Acquisition (SCADA) systems that provide centralized monitoring and control, Programmable Logic Controllers (PLCs) that execute real-time control logic, and Distributed Control Systems (DCS) that manage complex continuous processes. Human-Machine Interfaces (HMI) provide operators with visualization and control capabilities, while Safety Instrumented Systems (SIS) protect people and equipment from hazardous conditions. Building Management Systems (BMS) and Manufacturing Execution Systems (MES) round out the OT ecosystem.

The characteristics of OT systems stand in stark contrast to IT. OT prioritizes safety, availability, and reliability above everything else. These systems were historically air-gapped or completely isolated from external networks, receiving infrequent updates—often annually or only when absolutely necessary during planned shutdowns. OT environments rely on proprietary and industrial protocols like Modbus, Profibus, OPC-UA, EtherNet/IP, and DeviceNet rather than standard internet protocols. Equipment lifecycles stretch fifteen to twenty-five years in operation, designed for stability and deterministic performance rather than flexibility. In OT, downtime tolerance is essentially zero because every minute of stopped production directly costs money. Real-time processing happens in milliseconds, where timing precision can mean the difference between safe operation and catastrophic failure.

IT vs OT: Understanding the Real Differences

Information Technology (IT) and Operational Technology (OT) are often discussed together, but they were created to solve very different problems. Before connecting these systems, it’s critical to understand where they differ and why those differences matter in real-world manufacturing environments.

Simply put, IT manages information, while OT controls physical processes. IT systems support business operations such as finance, planning, communication, and analytics. OT systems directly run machines, production lines, and safety-critical infrastructure. Because OT interacts with the physical world, its requirements for reliability, timing, and safety are far stricter than those of IT systems.

The table below summarizes the most important distinctions between IT and OT.

IT vs OT: Side-by-Side Comparison

Dimension	Information Technology (IT)	Operational Technology (OT)
Primary Role	Manage business data and digital workflows	Control and monitor physical equipment
Main Priority	Efficiency, data integrity, and confidentiality	Safety, availability, and reliability
Operating Environment	Offices, data centers, cloud platforms	Factory floors, plants, field locations
Typical Systems	ERP, CRM, email, databases, cloud apps	PLCs, SCADA, DCS, HMIs, SIS, MES
What Is Controlled	Information and processes	Machines and industrial operations
Impact of Downtime	Reduced productivity and service disruption	Production stoppage and safety risk
Downtime Tolerance	Minutes to hours	Near zero
Response Time Requirements	Seconds to minutes	Milliseconds to seconds
System Lifecycle	3–5 years	15–25+ years
Patch & Update Frequency	Regular and frequent	Rare and carefully scheduled
Connectivity Model	Internet and cloud by default	Historically isolated, now selectively connected
Protocols Used	TCP/IP, HTTP/HTTPS, REST, SQL	Modbus, OPC-UA, Profibus, EtherNet/IP
Security Priority Model	CIA: Confidentiality → Integrity → Availability	AIC: Availability → Integrity → Confidentiality
Security Approach	Patching, endpoint security, zero trust	Segmentation, monitoring, minimal disruption
Change Management Style	Fast and iterative	Slow, controlled, and risk-averse
Failure Consequences	Data loss or system outage	Equipment damage, safety incidents
Regulatory Emphasis	Data protection and compliance	Safety and critical infrastructure protection
Typical Skill Sets	IT, networking, cybersecurity	Automation, electrical, mechanical engineering

The Growing Convergence of IT and OT

Historically, IT and OT operated in complete isolation. Your factory floor systems never touched corporate networks, and your business systems had no visibility into production processes. This separation provided natural security but created information silos that limited operational intelligence and prevented data-driven decision making.

Today, Industry 4.0, the Industrial Internet of Things (IIoT), and smart manufacturing initiatives are driving unprecedented IT/OT convergence. Manufacturers are connecting production equipment to business systems to enable real-time production monitoring and analytics, predictive maintenance based on equipment data, automated supply chain integration, quality management with immediate feedback loops, and energy optimization across operations. Remote monitoring and control capabilities that were once impossible are now becoming standard expectations.

This convergence is driven by shared goals that benefit from integration. Both IT and OT teams want operational efficiency and cost reduction, data-driven decision making, improved asset utilization, and enhanced quality control. Regulatory compliance and reporting requirements increasingly demand integrated data from both environments. Perhaps most compellingly, competitive advantage now flows from digital transformation that breaks down the walls between business and operational systems.

Despite their differences, IT and OT systems share more similarities than many realize. Both require robust access controls and authentication mechanisms. Both generate valuable data for business insights when properly captured and analyzed. Both face increasing cybersecurity threats that demand attention. Both benefit from modern technologies like artificial intelligence, machine learning, and cloud computing. Both require skilled personnel for effective management and maintenance. And both are absolutely critical to business continuity—failure in either domain can cripple operations.

The Critical Challenge: Cybersecurity in IT/OT Convergence

While IT/OT convergence delivers substantial benefits, it also creates significant cybersecurity risks. When you connect production systems to business networks—and potentially to the internet—you expose critical operational infrastructure to cyber threats that were previously impossible. Understanding these risks and implementing appropriate security measures isn't optional. It's essential for protecting your operations, your people, and your business.

Why OT Security Differs Fundamentally from IT Security

Traditional IT security assumptions simply don't apply in OT environments, creating dangerous gaps when IT security approaches are applied without modification. IT security relies heavily on regular patching and updates to address vulnerabilities. OT systems often can't be updated without production downtime, and some legacy equipment literally cannot be patched because vendors no longer support decades-old systems or the equipment lacks the computing resources for security updates.

The availability versus confidentiality trade-off creates fundamental conflicts between IT and OT security priorities. IT security teams will gladly take systems offline to patch critical vulnerabilities or investigate potential breaches. OT security must prioritize system availability and safety above all else—a security measure that stops production or creates safety risks is worse than the threat it prevents. This isn't about OT teams being lax about security. It's about the reality that stopping a production line costs thousands of dollars per minute, and certain security measures could literally endanger human lives.

System lifespan differences compound security challenges. IT equipment is replaced every few years, ensuring relatively current security capabilities. OT systems run for decades, meaning manufacturing facilities commonly operate equipment from the 1990s or early 2000s that was never designed with cybersecurity in mind. This equipment predates modern security threats and often lacks basic capabilities like encryption, authentication logging, or network security features.

Real-time requirements in OT systems prevent the use of many standard IT security tools and techniques. OT systems control physical processes with millisecond timing requirements where deterministic behavior is critical. Security measures that introduce latency, even small amounts, can cause safety issues or production failures. Network scans, intrusion detection systems, and other IT security tools that work perfectly in business networks can inadvertently crash industrial controllers or disrupt critical timing.

Legacy equipment presents perhaps the most intractable security challenge. Manufacturing facilities contain equipment from dozens of vendors spanning multiple decades. Much of this equipment was designed when industrial networks were completely isolated, so it has no security features whatsoever. Usernames and passwords might be hardcoded and unchangeable. Communications happen in cleartext with no encryption. These systems were built to last and they do their jobs perfectly—they just can't be secured using modern security practices.

Understanding Real Cybersecurity Threats to OT Systems

The threat landscape for OT environments is serious and growing. Ransomware attacks increasingly target manufacturing facilities because cybercriminals understand that production downtime pressure makes companies more likely to pay ransoms. A single ransomware attack can cost millions in downtime and recovery, even if no ransom is paid. Manufacturing targets are attractive because unlike IT systems where data can be restored from backups, stopping production creates immediate financial pain.

Nation-state attacks represent sophisticated threats to critical infrastructure and manufacturing capabilities. State-sponsored actors seek to disrupt operations, steal intellectual property, or establish persistent access for future attacks. These attacks are often discovered only after months or years of presence in target networks, during which time attackers map systems, exfiltrate data, and position themselves for maximum impact.

Insider threats from disgruntled employees or contractors with access to OT systems can cause significant damage through malicious action or negligent behavior. Someone with legitimate access and knowledge of industrial systems can bypass security controls that would stop external attackers. The damage can range from sabotage of production systems to theft of proprietary processes and formulations.

Supply chain compromises introduce vulnerabilities through third-party equipment, software, or vendor access. When a vendor's remote access credentials are compromised, attackers gain legitimate pathways into OT environments. Equipment may ship with malware pre-installed or contain undisclosed backdoors. Software updates from trusted vendors can be compromised to distribute malware to multiple customers simultaneously.

Perhaps ironically, unintentional disruptions from well-meaning IT actions cause frequent problems. IT security scans or updates applied to OT networks can inadvertently crash industrial systems that can't handle the traffic patterns or protocol variations. A network scan that's routine for IT systems might overwhelm a PLC that was never designed to handle that volume or type of network traffic.

Implementing Effective OT/IT Security

Network segmentation provides the foundational defense for converged IT/OT environments. Implementing defense-in-depth architecture with clear separation between IT and OT networks prevents threats from freely moving between environments. Industrial DMZs (demilitarized zones) control data flow between environments through strictly managed interfaces. The cardinal rule: never allow direct connectivity from the internet to OT networks, regardless of business pressure or convenience arguments.

Asset inventory and visibility seem basic but prove surprisingly challenging in practice. Maintaining comprehensive inventories of all OT assets including hardware specifications, software versions, communication protocols, and system dependencies requires ongoing effort. Shadow IT in OT—unauthorized equipment connected to industrial networks—creates unknown vulnerabilities. You cannot secure what you don't know exists, making discovery and inventory continuous processes rather than one-time projects.

Access control and authentication require careful implementation that balances security with operational requirements. Role-based access controls with the principle of least privilege ensure people can do their jobs but nothing more. Multi-factor authentication for remote access adds protection without adding excessive friction for legitimate users. Regular reviews of access permissions catch orphaned accounts and excessive privileges that accumulate over time.

Industrial security monitoring deploys OT-specific security tools that understand industrial protocols and can detect anomalous behavior without disrupting operations. Traditional IT security tools often aren't appropriate for OT environments because they don't understand industrial protocols, introduce unacceptable latency, or generate false positives that create alert fatigue. Purpose-built industrial security platforms can monitor traffic, detect threats, and alert security teams while respecting OT's unique requirements.

Vendor and third-party management controls one of the largest attack surfaces in OT environments. Carefully controlling vendor access to OT systems through jump servers, time-limited credentials, and continuous monitoring protects against both malicious actors and accidental damage. Every remote access session should be logged and auditable. Vendors should access only the specific systems they need, not entire network segments.

Backup and recovery planning takes on special importance in OT environments. Maintaining offline backups of critical OT configurations, PLC programs, HMI setups, and system documentation enables recovery when systems are compromised or fail. Testing recovery procedures regularly ensures they work when needed, because restoring OT systems is fundamentally different from IT recovery. You can't simply restore from last night's backup if that backup is months old or doesn't include the custom programming that makes your production line run.

Security awareness training must address the unique requirements of converged environments. IT staff need to understand OT constraints including real-time requirements, change management processes, and why their normal security tools can't be used without modification. OT staff need to understand cybersecurity fundamentals including threat landscapes, attack vectors, and security best practices. Building mutual understanding between IT and OT teams prevents dangerous assumptions and enables effective collaboration.

Regulatory compliance provides frameworks and requirements for industrial security. Industry-specific standards like IEC 62443 for industrial automation security, NERC-CIP for critical infrastructure protection, and NIST Cybersecurity Framework guidance for industrial systems establish baseline security practices. Compliance isn't just about checking boxes—these standards codify lessons learned from incidents across industries and provide structured approaches to industrial security.

Technical Deep Dive: Core OT Technologies

Industrial Control Systems (ICS) serves as the umbrella term for all control systems used in industrial operations. ICS includes SCADA systems, distributed control systems, programmable logic controllers, and related technologies that monitor and control industrial processes across manufacturing, energy production, water treatment, chemical processing, and critical infrastructure sectors. Understanding ICS architecture and components is essential for securing and integrating OT environments.

SCADA systems provide supervisory control and data acquisition for geographically distributed processes. A SCADA system might monitor and control water treatment across an entire city, manage electrical generation and distribution across a region, or coordinate production across multiple manufacturing facilities. SCADA systems collect data from remote locations, provide centralized visualization and control, generate alarms when conditions exceed thresholds, and log historical data for analysis and compliance. Modern SCADA platforms increasingly integrate with IT systems for advanced analytics and business intelligence.

Programmable Logic Controllers (PLCs) execute real-time control logic at the machine and process level. These ruggedized industrial computers run specialized programs that read sensors, make decisions based on programmed logic, and control actuators and equipment. PLCs operate in harsh industrial environments with extreme temperatures, vibration, electrical noise, and contamination that would destroy standard computers. They provide deterministic execution where timing is guaranteed, ensuring safety and process control requirements are met. PLCs use ladder logic, function block diagrams, or structured text programming languages designed for industrial applications rather than general-purpose computing.

Distributed Control Systems (DCS) manage complex continuous processes like chemical production, oil refining, or power generation. Unlike SCADA systems that supervise distributed operations, DCS provides integrated control of processes within a single facility. DCS architecture distributes control functions across multiple controllers for redundancy and performance, integrates control, operator interfaces, and engineering tools in unified platforms, and manages complex regulatory control strategies for maintaining product quality and process efficiency. DCS platforms represent significant investments with lifecycles often exceeding twenty years.

Human-Machine Interfaces (HMI) provide the visualization and control capabilities that operators use to monitor and manage industrial processes. Modern HMIs display real-time process data through graphics, trends, and alarms, enable operators to adjust setpoints and control equipment, provide historical trending and reporting capabilities, and increasingly support mobile access for remote monitoring. HMI design significantly affects operator effectiveness and safety, making usability and information clarity critical considerations.

Industrial Protocols: The Languages of OT

Industrial protocols enable communication between OT devices but differ fundamentally from standard IT protocols. Modbus, developed in 1979, remains widely used for connecting industrial electronic devices. This simple, robust protocol enables PLCs, sensors, and other devices to communicate over serial connections or Ethernet networks. Modbus's age means it has no built-in security features—all communications are unencrypted and unauthenticated—but its ubiquity and simplicity ensure it will remain deployed for decades.

Profibus and Profinet serve as standard protocols in European manufacturing and are particularly common in automotive and process industries. Profibus operates over serial connections while Profinet runs on standard Ethernet, providing faster communications and more features. These Siemens-developed protocols dominate in certain industries and regions, creating integration challenges when connecting equipment from different vendors.

OPC-UA (OLE for Process Control - Unified Architecture) represents a modern, secure, and platform-independent protocol designed for industrial interoperability. Unlike older protocols, OPC-UA includes built-in security features including encryption, authentication, and authorization. It enables semantic modeling of industrial data so systems understand not just values but their meaning and relationships. OPC-UA is increasingly adopted as the standard for Industry 4.0 and IIoT applications because it addresses both connectivity and security requirements.

EtherNet/IP adapts standard Ethernet and TCP/IP protocols for industrial automation, particularly in North American manufacturing. This protocol is common in discrete manufacturing, packaging, and material handling applications. DeviceNet provides a low-cost network for connecting simple industrial devices like sensors, motor starters, and actuators to PLCs and controllers.

The diversity of industrial protocols creates significant integration challenges. A single manufacturing facility might use half a dozen different protocols across equipment from various vendors and vintages. Protocol converters, gateways, and translation tools are often necessary to achieve connectivity, adding complexity and potential points of failure. This protocol fragmentation makes unified IT/OT integration technically challenging and expensive.

The Organizational Challenge: Bridging IT and OT Teams

Technical integration challenges are matched by organizational and cultural differences between IT and OT teams. These groups often have fundamentally different priorities, training, and approaches to problems, creating friction that can derail integration projects if not addressed thoughtfully.

IT teams focus on keeping business systems running, securing data, enabling collaboration, and adopting new technologies to improve business processes. They're accustomed to regular change, view updates and patches as routine and necessary, prioritize cybersecurity and data protection, and measure success through system availability, user satisfaction, and cost efficiency. IT professionals typically have formal education in computer science or information systems and hold certifications like CISSP, CISM, or various vendor credentials.

OT teams focus on keeping production running safely and efficiently, maintaining equipment reliability, preventing unplanned downtime, and preserving process knowledge that might span decades. They're accustomed to stability and view changes with skepticism until proven necessary, prioritize safety and availability over all other concerns, and measure success through production uptime, quality metrics, and safety records. OT professionals often come from engineering backgrounds in electrical, mechanical, or chemical engineering, holding certifications like PE licenses or vendor-specific industrial automation credentials.

These different backgrounds create predictable conflicts. When IT suggests network upgrades or security improvements, OT worries about production disruption and unproven technology in critical systems. When OT wants to keep running proven systems unchanged, IT worries about security vulnerabilities and inability to integrate with modern business systems. Both perspectives are valid and rooted in real concerns shaped by each team's responsibilities and past experiences.

Successful IT/OT convergence requires building bridges between these cultures. Creating cross-functional teams that include both IT and OT expertise ensures projects consider all relevant concerns from the beginning. Establishing shared goals and metrics that both teams contribute to helps align priorities. Developing mutual respect through education about each domain's challenges and constraints builds understanding. And perhaps most importantly, ensuring executive leadership understands and supports convergence efforts provides the authority and resources necessary to overcome organizational inertia.

Making IT/OT Convergence Work: Strategic Implementation

Successful IT/OT convergence requires a strategic, methodical approach rather than ad-hoc connectivity projects. Start by establishing clear business objectives that justify the effort and investment. What specific problems are you trying to solve? What measurable outcomes define success? IT/OT convergence is a means to an end, not an end in itself, so clarity about the desired outcomes guides all subsequent decisions.

Prioritize use cases with measurable return on investment to build momentum and prove value. Rather than attempting comprehensive integration all at once, identify specific high-value opportunities where connectivity delivers clear benefits. Predictive maintenance that prevents unplanned downtime, real-time quality monitoring that reduces scrap, or energy optimization that lowers utility costs provide concrete value propositions. Success with focused use cases builds organizational confidence and provides lessons for broader implementation.

Design robust security architectures from the beginning rather than adding security as an afterthought. The security model must respect OT constraints while providing effective protection. This typically involves network segmentation with industrial DMZs, defense-in-depth strategies with multiple security layers, OT-specific security monitoring and threat detection, and carefully managed interfaces between IT and OT environments. Security architecture decisions made early are difficult and expensive to change later.

Foster collaboration between IT and OT teams through shared projects, cross-training, and integrated planning. The technical integration cannot succeed without organizational integration. Create forums for regular communication between teams, establish joint governance for converged systems, and develop shared understanding of each domain's requirements and constraints. Successful convergence projects consistently cite strong IT/OT collaboration as a critical success factor.

Plan for long-term evolution rather than one-time projects. IT/OT convergence is an ongoing journey as technology, business requirements, and threat landscapes evolve. Build flexible architectures that can adapt to changing needs, establish processes for continuous improvement, and plan for lifecycle management of integrated systems. The goal isn't reaching a finished state but rather creating capabilities for continuous adaptation and improvement.

Real-World Benefits of IT/OT Integration

When implemented thoughtfully, IT/OT convergence delivers substantial operational and business benefits. Production visibility transforms from lagging indicators based on end-of-shift reports to real-time dashboards that show current performance, immediate quality metrics, and live equipment status. This visibility enables faster problem identification and response, data-driven decision making at all organizational levels, and immediate understanding of production impacts from changes.

Predictive maintenance shifts maintenance strategies from reactive repairs or time-based schedules to condition-based maintenance driven by actual equipment health. Sensors and analytics identify early warning signs of impending failures, allowing maintenance during planned downtime rather than crisis response to breakdowns. This reduces unplanned downtime, extends equipment life through optimal maintenance timing, and lowers maintenance costs through better resource allocation.

Quality management improves through immediate feedback loops that connect production processes with quality results. Rather than discovering defects in finished goods or during sampling, integrated systems can detect quality excursions in real-time and automatically adjust processes or alert operators. This reduces scrap and rework, improves first-pass yield, and enables faster root cause analysis when issues occur.

Energy optimization becomes possible when business systems can analyze energy consumption patterns across production operations. Identifying energy-intensive processes, optimizing production schedules to leverage time-of-use rates, and detecting energy waste from inefficient equipment operation deliver measurable cost reductions. Many manufacturers discover that previously invisible energy waste represents significant savings opportunities.

Supply chain integration becomes more dynamic and responsive when production systems can communicate directly with inventory, purchasing, and logistics systems. Automated reordering triggered by actual consumption rather than forecasts, real-time visibility of production status for customer order management, and immediate coordination of material delivery with production schedules reduce inventory carrying costs while improving delivery performance.

Common Pitfalls to Avoid

Understanding common implementation failures helps organizations avoid costly mistakes. The single biggest pitfall is treating IT/OT convergence purely as a technology project rather than a strategic business initiative. Without clear business objectives and executive sponsorship, projects devolve into technical exercises that may achieve connectivity but deliver limited business value. Secure executive commitment to desired business outcomes before beginning significant integration work.

Underestimating security requirements leads to vulnerable implementations that expose critical operations to cyber threats. Organizations sometimes focus on achieving connectivity while treating security as something to address later. In IT/OT convergence, security must be architectural rather than bolted on afterward. The cost and complexity of retrofitting security after deployment far exceeds incorporating it from the beginning.

Ignoring legacy equipment challenges causes projects to stall when teams encounter the reality of decades-old systems that can't be integrated using modern approaches. Assess the actual state of existing equipment early in planning, identify systems that will require special handling or replacement, and budget accordingly. Many legacy systems can be integrated through edge devices or protocol converters, but this requires planning and investment.

Failing to involve OT teams in planning and implementation creates resistance and risks disrupting production. IT-led initiatives that treat OT as simply another network to be managed often fail because they don't account for OT's unique requirements and constraints. Successful projects include OT expertise from the beginning and respect the primacy of production operations.

Attempting too much too quickly overwhelms organizations and dilutes resources across multiple initiatives. Better to achieve significant success with focused use cases than superficial progress across broad initiatives. Build momentum through early wins rather than comprehensive transformation attempts.

Your Path Forward with FlowFuse

Navigating IT/OT convergence requires tools that understand both worlds. FlowFuse is built on Node-RED, an open-source platform that has become the de facto standard for industrial integration, with over 5,000 pre-built nodes connecting to industrial protocols, databases, cloud platforms, and business systems. This extensive library means you can integrate Modbus devices with your ERP system, connect OPC-UA machines to cloud analytics, or bridge SCADA systems with business intelligence tools—all without extensive custom programming.

The visual, drag-and-drop interface enables your engineers and technicians to build integration workflows directly. People who understand your processes and equipment can implement solutions themselves, reducing dependency on external developers and speeding project delivery. This democratization of integration development means OT teams aren't dependent on IT resources for every connection or modification.

FlowFuse adds enterprise capabilities including team collaboration, version control, and secure deployment to the Node-RED foundation. These features make Node-RED suitable for production manufacturing environments where change management, security, and reliability are non-negotiable. Projects can be developed in test environments, reviewed by stakeholders, and deployed to production with confidence.

Security features built into FlowFuse protect your integration projects and the systems they connect. Role-based access controls ensure people can access only appropriate projects and deployments. Audit logging provides visibility into changes and activities. Network isolation options enable proper segmentation between IT and OT environments even within your integration platform.

The open-source foundation means you're never locked into proprietary technology or single-vendor solutions. Node-RED's active community continuously develops new protocol support, integration capabilities, and functionality. When you need to connect to new equipment or systems, chances are someone has already created the necessary integration components.

Manufacturing operations worldwide rely on FlowFuse for IT/OT convergence projects ranging from simple data collection to sophisticated predictive maintenance, quality management, and energy optimization initiatives. The platform scales from proof-of-concept projects to enterprise deployments managing thousands of devices and processes.

Book a demo today to see how FlowFuse can help you navigate IT/OT convergence securely and effectively, using proven open-source technology that respects both IT and OT requirements.

Preventive Maintenance in Manufacturing: Avoid Multi-Million Dollar Equipment Failures

2025-09-04T00:00:00Z

At 2:47 AM on a Tuesday, a $15 bearing brought down a $2 million production line.

While this specific incident is illustrative, the failure pattern it represents is all too real and systemic. According to recent industry research, unplanned downtime outages last an average of four hours and cost an average of $2 million per incident. These bearing failures happen across manufacturing facilities worldwide with predictable consistency: emergency repairs, overtime labor, expedited parts, delayed customer orders, and relationship damage. All from a component that could have been replaced during scheduled downtime for $800.

The real tragedy? Every signal was there. Vibration readings had climbed 40% over six weeks. Temperature spikes occurred during peak loads. Acoustic signatures screamed impending failure. But without systematic monitoring, these warnings vanished into the noise of daily operations.

This isn't a maintenance story, it's a data story. And it's playing out in manufacturing facilities worldwide every day. According to Forbes, unplanned downtime can cost manufacturing companies a whopping $50 billion per year. Siemens' 2024 report reveals that unplanned downtime now costs Fortune Global 500 companies 11% of their yearly turnover, almost $1.5 trillion, up from $864 billion two years ago.

The Predictable Science of Equipment Death

Equipment failures aren't random disasters, they're predictable processes that unfold over weeks or months, leaving digital breadcrumbs that reveal exactly when intervention will be most cost-effective.

Reliability engineers call this the P-F curve: the measurable interval between when a potential failure (P) becomes detectable and functional failure (F) occurs. For rotating equipment like motors and pumps, this window typically spans 6-12 weeks. For hydraulic systems, 2-8 weeks. For electronic components, days to months.

P-F Curve.

During this P-F interval, equipment broadcasts its distress through dozens of measurable parameters:

Vibration patterns shift as bearings wear and alignments drift
Power consumption increases as friction rises and efficiency drops
Temperature profiles change as lubricants degrade and clearances widen
Acoustic signatures evolve as mechanical tolerances exceed design limits
Process variables drift as equipment performance degrades

The math is brutal. According to research by Eptura, on-demand work orders generally take twice as long as preventive maintenance, cutting associated labor costs in half through proactive approaches. A comprehensive study by JLL (Jones Lang LaSalle) analyzing 14 million square feet of mixed building types found that preventive maintenance produces an astounding 545% return on investment.

Why Over Half of Manufacturers Still Play Failure Roulette

Despite overwhelming evidence favoring preventive approaches, many facilities still operate critical equipment on run-to-failure strategies. The reason isn't ignorance, it's infrastructure complexity and historical implementation challenges.

Traditional preventive maintenance software promised comprehensive monitoring but delivered integration nightmares. Each device required custom programming, proprietary gateways, and specialized expertise. Implementation projects stretched 12-18 months, cost hundreds of thousands of dollars, and often failed to deliver promised capabilities.

Meanwhile, production environments grew increasingly complex. A single line now might include:

1990s CNC machines speaking serial protocols
2000s PLCs using Modbus communication
2010s robots on Ethernet/IP networks
2024 sensors transmitting via MQTT and other IoT protocols

Each system operates in isolation, generating valuable data that remains trapped behind incompatible interfaces.

The Platform Revolution: Universal Data, Unified Insights

Modern industrial data platforms are eliminating these barriers by treating connectivity as a solved problem rather than a custom project.

Instead of requiring expensive integration for each device type, these platforms provide universal connectivity out of the box. Legacy equipment, modern sensors, and everything in between can communicate through a single interface without gateways, converters, or custom programming.

This fundamental shift changes the economics of comprehensive monitoring. Instead of monitoring a few critical machines with dedicated systems, manufacturers can monitor everything, from primary production equipment to auxiliary systems like compressed air, HVAC, and power distribution.

Research indicates that 95% of predictive maintenance adopters reported a positive ROI, with 27% of these reporting amortization in less than a year.

Evidence-Based Results from Leading Manufacturers

The transformation from reactive to predictive maintenance is delivering measurable results across industries:

Automotive Manufacturing: Major automotive suppliers have achieved 50% reduction in unplanned downtime after implementing comprehensive equipment monitoring across their facilities. The key wasn't just monitoring critical assets, it was monitoring everything, creating a complete picture of facility health.

Electronics Production: Leading electronics manufacturers report 25% reduction in maintenance costs by connecting previously isolated systems on unified data platforms. Maintenance teams can finally see relationships between equipment performance and environmental factors.

Industrial Equipment: According to the U.S. Department of Energy, predictive maintenance helps enterprises gain remarkable results such as a tenfold increase in ROI, 70-75% decrease in breakdowns, 25-30% reduction in costs, and 35-45% reduction in downtime.

FlowFuse: The Open, Scalable, and Flexible Industrial Data Platform

FlowFuse represents the next evolution in industrial data platforms, designed by engineers who understand both the promise and frustrations of traditional systems.

Built on Node-RED, the open-source standard for industrial connectivity, FlowFuse eliminates integration barriers that have historically made comprehensive monitoring expensive and complex. Native support for almost all industrial protocols and systems means any device that communicates digitally can connect without custom development.

But connectivity is just the foundation. FlowFuse's visual programming environment enables engineers to build sophisticated monitoring applications using drag-and-drop interfaces. Need to correlate motor vibration with production load? Create custom dashboards for different user roles? Set up automated alerts based on complex conditions? All possible without writing code.

The platform's AI-powered editor goes further by reducing the development effort for engineers.

For enterprise users, FlowFuse provides several essential features to support large-scale, collaborative, and secure industrial data operations. This includes DevOps tools and Remote Device Management, which streamline the deployment of applications and allow teams to remotely monitor and update their connected devices. To facilitate teamwork and project management, the platform incorporates Snapshot & Version Control and Real-Time Team Collaboration, enabling multiple people to work together on projects and easily track changes. For system reliability, FlowFuse offers High Availability, and to simplify user access while boosting security, it provides Single Sign-On (SSO). Additionally, Role-Based Access Control is a key security feature that lets administrators manage and restrict data access for different users.

Most importantly, FlowFuse uses transparent pricing that encourages comprehensive data collection. No per-tag penalties, no volume restrictions, just straightforward costs that scale with business value rather than data points monitored.

The New Maintenance Economics

Companies implementing comprehensive equipment monitoring through modern data platforms are rewriting the economics of manufacturing operations. The financial picture changes almost immediately: emergency repairs drop by as much as 60–80% as failures shift from unexpected crises to planned interventions. Overall maintenance spending falls by 12–18% as teams allocate resources more efficiently, while spare parts inventories shrink by 30–50% because demand becomes predictable rather than chaotic.

The impact extends well beyond cost savings. Equipment life stretches by 20–40% when replacement is driven by condition rather than arbitrary schedules. Overall Equipment Effectiveness (OEE) climbs by 10–20% as downtime disappears from production schedules, and energy consumption drops by 5–15% as machines run closer to their designed efficiency.

Operational excellence amplifies across the board. Companies see on-time delivery rates climb past 95%, far outpacing the industry average of 75% in reactive environments. Customer satisfaction rises in parallel, supported by the reliability of consistent delivery. Workforce safety also improves as proactive monitoring identifies hazards before they escalate.

According to research by McKinsey & Company, the cumulative effect of these improvements is profound: organizations that adopt data-driven decision making are on average 5% more productive and 6% more profitable than competitors who remain locked in reactive cycles.

The Implementation Reality

The path from reactive to proactive maintenance is clearer than ever, but success requires more than software selection, it requires cultural transformation.

Start with pain point identification. Which equipment failures cause the most disruption? Where are emergency repair costs highest? What assets have the longest replacement lead times? These become your monitoring priorities.

Focus on quick wins that build organizational confidence. Monitor 3-5 critical assets that represent different failure modes and equipment types. Establish baselines, implement basic condition monitoring, and measure results rigorously.

The US Department of Energy reports a projected ROI of ten times the investment for organizations implementing predictive maintenance strategies.

Most importantly, treat this as a capability-building exercise, not a technology project. The goal isn't just preventing failures, it's developing organizational competencies in data-driven decision making that enable continuous operational improvement.

Taking Action

The business case is overwhelming. The technology barriers are eliminated. The competitive advantages are clear and measurable.

The question isn't whether to implement comprehensive equipment monitoring, it's how quickly you can build capabilities that deliver sustainable competitive advantages.

Calculate your current failure costs honestly. Include not just repair expenses but lost production, customer impact, and opportunity costs. Identify your most critical assets and pain points. Evaluate platforms that provide universal connectivity without integration complexity.

The manufacturers moving decisively are gaining first-mover advantages in operational excellence that their competitors will struggle to match. Those delaying risk permanent disadvantage in an increasingly data-driven industry.

Ready to transform equipment failures from crisis events into predictable costs? Discover how FlowFuse enables comprehensive equipment monitoring that delivers measurable competitive advantages from day one.

References

TeamSense (2024). High Cost of Downtime in Manufacturing & How to Reduce It.
IIoT World (2023). The Actual Cost of Downtime in Manufacturing.
Evocon (2024). Cost of Downtime in Manufacturing: Insights & Implications.
IDS Data (2025). The Real Cost of Downtime in Manufacturing.
Eptura (2025). Workplace Index: Preventive Maintenance ROI.
IoT Analytics (2024). Predictive Maintenance Market: 5 Highlights.
Polaris Market Research (2024). Predictive Maintenance Market Report, 2024–2032.
MoldStud (2024). ROI Benefits of Predictive Maintenance.
Sensorfy (2023). How to Calculate Predictive Maintenance ROI.
MicroMain (2024). Preventive Maintenance ROI of 545%.
ScienceDirect (2025). Systematic Review of Predictive Maintenance Practices.
IIoT World (2024). Predictive Maintenance: Hidden ROI Driver.

Additional references: U.S. Department of Energy (predictive maintenance effectiveness), McKinsey & Company (productivity studies), Siemens (True Cost of Downtime reports).

How to Create a Pareto Chart for Manufacturing Data

2025-09-02T00:00:00Z

In the first part of this series, we explored the foundational principles of the Pareto Chart, understanding how this powerful tool can help manufacturing teams quickly identify and focus on the "vital few" problems that have the biggest impact. We learned that by combining a bar graph and a cumulative percentage line, a Pareto Chart provides a clear visual roadmap to prioritize quality issues, equipment downtime, or other key performance indicators.

Now, it's time to move from theory to practice. This guide will show you how to create a Pareto Chart using modern industrial data tools. You will learn how to connect to your production data, calculate frequencies and format data, and visualize the results in a chart that helps your team make data-driven decisions.

Pareto Chart showing defect categories in manufacturing with bars for scratches, cracks, color issues, and other defects, alongside a cumulative percentage line.

Getting Started

To create a Pareto Chart for manufacturing data, you'll need access to industrial data platforms that can connect to your production systems. This guide uses FlowFuse, a low-code platform that simplifies industrial data workflows. If you don't have an account yet, you can sign up for a 14-day free trial.

Step 1: Connect to Your Data Source

The first step to create a Pareto Chart is accessing the data you want to analyze. In industrial environments, machine or process data is commonly collected via industrial protocols such as OPC-UA, MQTT, or direct database queries. Modern industrial platforms support nearly all industrial protocols and databases, making it easy to connect to your existing systems.

To connect your data:

Drag the appropriate input node into your flow (e.g., an OPC-UA Read node).
Enter the connection details for your industrial system.
Test the connection to confirm that live data is flowing correctly.

If a live PLC or factory dataset is not available, you can use a simple Inject node to simulate production data and learn how to make a Pareto Chart with sample data.

Step 2: Format and Aggregate the Data

Once data is flowing, the next step to create a Pareto Chart is to organize it into types or categories and count how often each occurs. A Pareto Chart is most useful when you can clearly see, for example, defect data like:

"Scratch on Surface – 20 occurrences, Misaligned Parts – 10 occurrences, Loose Screws – 5 occurrences."

When you make a Pareto Chart, this can be done in three steps:

Format the data – Use a JSON, CSV, or Change node to clean or convert incoming data if needed.
Aggregate in a Function node – Map each data point to a type (e.g., machine type, process step, defect category) and keep a running count of occurrences.

Tip: You do not need to know JavaScript. Simply describe the desired outcome and provide a sample dataset—the FlowFuse Expert will generate the Function node for you. Learn more.
Sort the results – Use a Sort node to arrange categories so the most frequent appear first.

At the end of this step, your data should be transformed into a structure like this, which is the required format to create a Pareto Chart in Step 3:

[
  { "type": "Paint Defect", "count": 8 },
  { "type": "Faulty Electronics", "count": 6 },
  { "type": "Scratch on Surface", "count": 5 },
  { "type": "Misaligned Parts", "count": 3 },
  { "type": "Loose Screws", "count": 2 },
  { "type": "Cracked Housing", "count": 1 }
]

Step 3: Visualizing the Chart

Before you can create a Pareto Chart visualization, ensure that you have installed the @flowfuse/node-red-dashboard node. This library provides the essential user interface components needed to create a real-time dashboard.

Open the Editor and click on the hamburger menu (☰) in the top-right corner.
Select Manage palette.
Navigate to the Install tab.
Search for @flowfuse/node-red-dashboard and click Install.

After installation, new UI nodes—such as UI Chart, UI Gauge, UI Template, and others—will appear in your palette. These nodes provide the building blocks to make a Pareto Chart and other interactive dashboard components for industrial applications.

While the standard UI Chart node supports most common chart types, it does not include a native Pareto chart. To create a Pareto Chart with advanced features, the UI Template node can be used, allowing you to embed custom components for fully tailored visualizations.

Below is an example showing how to create a Pareto Chart using the UI Template node. You can copy and import this flow directly into your editor to start using it immediately.

Connecting Your Real Production Data

Ensure your upstream data flow (from OPC-UA, MQTT, or database nodes) is cleaned and aggregated into the JSON format described in Step 2.
Connect the output of that flow to the Pareto Chart (UI Template) node you imported, then deploy the flow.
Whenever new data arrives, the chart will automatically update, displaying both the bars (frequency) and the cumulative percentage line.

To view the dashboard, click the Open Dashboard button in the top-right corner of the Dashboard 2.0 sidebar. Your newly created Pareto Chart will appear, complete with bars, the cumulative line, and the 80% threshold.

Pareto Chart showing defect categories in manufacturing with bars for scratches, cracks, color issues, and other defects, alongside a cumulative percentage line.

The chart visualizes defect types using bars. The cumulative line and the 80% threshold indicate the cutoff point: bars to the left of this intersection represent the vital few defects that contribute most to the total—and these are the areas where you should focus your improvement efforts.

Pareto Chart showing defect categories in manufacturing. The bars on the left, highlighted with a red box, represent the vital few defects

Takeaways

By following the steps outlined above, you have successfully learned how to create a Pareto Chart that transforms raw production data into clear, actionable insights. This visualization helps manufacturing teams focus their limited time and resources on the problems that matter most.

Why This Matters for Your Business

The real power when you create a Pareto Chart isn't just in identifying problems—it's in changing how your team makes decisions. Instead of trying to fix everything at once or relying on gut feelings, you now have data-driven clarity on where to focus. This translates into:

Less firefighting, more strategic improvement: Teams can stop chasing every small issue and concentrate on the critical few that truly impact production.
Faster problem resolution: When everyone can see which issues dominate, alignment happens quickly and solutions get implemented faster.
Better conversations with management: Visual data makes it easier to justify resource allocation and demonstrate the impact of improvement initiatives.
Continuous learning: As the top issues are resolved, new patterns emerge, creating a cycle of ongoing improvement.

Building on Your Success

With your ability to create a Pareto Chart established, you've built a foundation for data-driven decision-making. The same approach to make a Pareto Chart can be applied to other areas of operations:

Track equipment downtime reasons to optimize maintenance schedules.
Analyze customer feedback to prioritize product improvements.
Monitor supplier performance to strengthen the supply chain.
Identify training gaps by analyzing operator errors.

FowFuse makes it simple to replicate this success across your organization. The same flow can be deployed to multiple lines, shared with other teams, and adapted for different use cases—while maintaining security and control through enterprise-grade features.

Ready to see how FlowFuse can help your team make better decisions with production data? Book a demo to discover how manufacturers are using visual analytics to drive continuous improvement and operational excellence.

FlowFuse API for Industry: Automating Node-RED Instances, Devices, and CI/CD Tasks

2025-08-29T00:00:00Z

FlowFuse includes an API that lets you manage Node-RED instances, edge devices, and deployments directly from your scripts or applications. While most people use the web interface, the API is a great option if you want to automate tasks or connect FlowFuse with other tools.

In this guide, you’ll learn the basics of the FlowFuse API, along with practical examples you can start using right away.

What is the FlowFuse API and Why Use It?

The FlowFuse API is a REST-based interface fully described using the OpenAPI 3.0 Specification, allowing you to explore its capabilities, test endpoints, and even auto-generate client libraries in multiple programming languages. It provides programmatic control over everything available in the FlowFuse platform, so instead of navigating the dashboard, you can manage Node-RED instances, devices, and deployments directly from scripts or applications.

This is particularly useful when you want to:

Manage multiple Node-RED instances or devices simultaneously.
Automate repetitive tasks such as starting, stopping, or updating instances.
Build custom notifications or alerts.
Implement CI/CD pipelines for testing and deploying flows automatically.
Integrate FlowFuse with external systems like monitoring, alerting, or scheduling tools.

In short, the API provides greater flexibility, simplifies automation, and allows FlowFuse to fit seamlessly into your existing workflows.

Getting Started with the FlowFuse API

Before you can use the API, you need:

Your FlowFuse account
You will need to authenticate using an API token, which you can generate from the FlowFuse platform.

Generating an API Token

Log in to the FlowFuse platform.
Open User Settings → Security.
Switch to the Tokens tab and click Add Token.
In the form that opens:
- Give the token a descriptive name (e.g., automation-script).
- (Optional) Check Add Expiry Date and choose a date if you want the token to automatically expire.
- Click Create Token to generate it.

FlowFuse platform token creation form showing fields for token name, expiry date, and create button.

After creation, a dialog will open showing your secret token.
Click Copy to Clipboard and store this token securely. It will only be shown once and provides full access to your account.

Dialog showing the generated FlowFuse API token with copy-to-clipboard option.

Exploring the FlowFuse API with Swagger

FlowFuse provides Swagger/OpenAPI documentation that gives you a complete overview of all available endpoints, along with request and response formats.

Note: The Swagger UI is read-only. You cannot execute API calls directly from it. Its purpose is to display all endpoints after visiting the page, so you can plan and structure your API calls in Node-RED flows, scripts, or other applications.

FlowFuse Swagger/OpenAPI documentation interface displaying endpoints for users, Node-RED instances, devices, deployments, and much more.

How to Use the Swagger Docs

Open the FlowFuse API documentation in your browser.
Once loaded, you will see all available endpoints, organized by category:
- /api/v1/user/ – Retrieve user details
- /api/v1/instances/ – List and manage Node-RED instances
- /api/v1/devices/ – Manage edge devices
- /api/v1/deployments/ – Trigger or monitor deployments
Click on each endpoint to expand it and review the details, including:
- Required parameters
- Headers
- Response schemas
Use this information to construct actual API requests in Node-RED HTTP Request nodes, curl, or other scripts.

Making Your First API Call

Once you have your API token, you can start interacting with the FlowFuse API. Every request must include your token in the Authorization header.

Example: Get User Information

A good first step is to fetch your user details to verify that your token works. You can use curl, any HTTP client in your preferred programming language, or even do it directly within Node-RED using an HTTP Request node, as shown below.

Steps in Node-RED:

Drag an Inject node onto the canvas.
Drag an HTTP Request node and connect it to the Inject node.
Double-click the HTTP Request node and configure it:
- Method: GET
- URL: https://app.flowfuse.com/api/v1/user/
- Check Use authentication, select Bearer Authentication, and enter your API token.
Connect a Debug node to the HTTP Request node to see the response.
Deploy the flow and click the Inject button.

Note: When using API tokens in Node-RED flows, always store them in environment variables instead of directly in the node to prevent accidental exposure when sharing flows. See FlowFuse Environment Variables for more details.

Once triggered, the debug panel will show your user information as shown below with status code 200, confirming that your token works and your API connection is successful.

{
  "email": "john.doe@example.com",
  "email_verified": true,
  "sso_enabled": true,
  "mfa_enabled": false,
  "tcs_accepted": "2024-01-01T00:00:00.000Z",
  "id": "john12345",
  "username": "johndoe",
  "name": "John Doe",
  "avatar": "https://app.flowfuse.com/avatar/john-avatar",
  "admin": false,
  "createdAt": "2024-01-01T00:00:00.000Z",
  "suspended": false
}

Automating DevOps Pipelines with the FlowFuse API

One of the most powerful features of the FlowFuse API is its ability to integrate directly with CI/CD pipelines. This makes it possible to trigger builds, deployments, or pipeline stages automatically—either from scripts or directly within Node-RED flows—reducing manual effort and accelerating development cycles.

To trigger a pipeline stage, you will use the following endpoint:

PUT /api/v1/pipelines/{pipelineId}/stages/{stageId}/deploy

This requires two pieces of information: the pipeline ID and the stage ID. Before triggering a deployment, you first need to retrieve the list of pipelines for your application:

GET /api/v1/applications/{applicationId}/pipelines

This request returns all pipelines for the given application, including their pipelineId and the stages associated with them. Once you identify the correct pipelineId and stageId, you can use them in the deploy request to trigger the stage automatically.

API Steps

Before triggering a stage, we first need to retrieve the pipeline details for the application. This will give us both the pipeline ID and the stage ID required for deployment.

Step 1: Get Your Application ID

Navigate to your application in FlowFuse.
Open the Settings page.
Copy the Application ID (you will need this in later steps).

Step 2: Retrieve Pipelines for an Application

Drag an Inject node to manually trigger the request.
Add an HTTP Request node and configure it as follows:
- Method: GET
- URL:
```
/api/v1/applications/{applicationId}/pipelines
```
  Replace {applicationId} with the actual Application ID you copied in Step 1.
- Authentication: Enable Bearer Authentication and set it to use your API token from the environment.
Connect the Inject node to the HTTP Request node, and then connect the HTTP Request node to a Debug node.
Deploy the flow and click the Inject button to retrieve the pipelines.

The response will return a list of pipelines, each containing a unique pipelineId.

Step 3: Identify the Stage

Review the pipeline details returned from Step 2.
Note the pipelineId and the stageId of the stage you want to trigger.

Step 4: Trigger the Stage Deployment

Once you have the pipelineId and stageId, you can trigger the deployment stage with a PUT request.

Add another Inject node to trigger the deployment.
Connect it to a new HTTP Request node and configure it as follows:
- Method: PUT
- URL:
```
/api/v1/pipelines/{pipelineId}/stages/{stageId}/deploy
```
  Replace {pipelineId} and {stageId} with the values from Step 3.
- Authentication: Use Bearer Authentication with your API token.
Connect the HTTP Request node to a Debug node to view the response.
Deploy the flow and click Inject.

If successful, you will receive a JSON response confirming that the deployment stage has been triggered.

{"status":"importing"}

The FlowFuse API allows you to deploy a specific stage of a pipeline. It does not automatically move to the next stage, but you can create a workflow that monitors the status of each stage and triggers the next one once the current stage is complete. In the following flow, the development stage is deployed every day at 10 PM. After that, the workflow checks the status of the next stage, the staging instance, before proceeding.

Conclusion

The FlowFuse API puts you in control of your Node-RED infrastructure through code. Instead of managing instances manually, you can automate repetitive tasks, integrate with existing tools, and build custom workflows that fit your exact needs.

Whether you're managing a handful of instances or thousands of edge devices, the API scales with you. It's straightforward to get started—generate a token, make your first API call, and gradually automate more of your workflow as you go.

The real value comes from the time you save and the consistency you gain. Let the API handle the routine work while you focus on building great Node-RED applications.

Start today by generating your first API token and making a call — you’ll see how quickly FlowFuse can automate your Node-RED operations. Sign up for free and put your industrial workflows on autopilot.

Pareto Chart & Diagram: What It Is, Formula, Examples & Manufacturing Applications

2025-08-28T00:00:00Z

A Pareto Chart helps manufacturing teams cut through the chaos when problems arrive in clusters—defects, delays, downtime, and customer complaints all competing for attention. With limited resources and time, how do you decide which fire to put out first?

A Pareto Chart is a decision-making tool that reveals which problems deserve immediate attention and which can wait. Based on the principle that roughly 80% of problems stem from 20% of causes, this visual tool transforms chaos into clarity. It shows manufacturing teams exactly where to focus their efforts for maximum impact.

Whether you call it a Pareto Chart, Pareto diagram, or Pareto analysis graph, this quality control tool serves the same purpose: helping you identify and prioritize the most impactful problems in your manufacturing process.

What is the Pareto Principle ?

The Pareto Principle, discovered by Italian economist Vilfredo Pareto in 1896, reveals a universal truth: imbalance is the norm, not the exception. Pareto originally observed that 80% of Italy's land belonged to 20% of the population. This same pattern appears everywhere in manufacturing.

Think about your own facility. Chances are, most of your headaches come from a handful of root causes. A few machines cause most breakdowns. A small number of suppliers create most delays. A limited set of defect types generate most customer complaints. The Pareto Chart makes these hidden patterns visible, turning intuition into actionable data.

If you prefer video, watch this quick explainer to understand the Pareto Principle:

Pareto Chart vs Pareto Diagram: What's the Difference?

You'll hear both terms used interchangeably in manufacturing—and they refer to the same tool. "Pareto Chart" is more common in North America, while "Pareto diagram" is frequently used in ISO standards and international quality documentation. Whether your team calls it a chart, diagram, or graph, the visualization combines bar charts with a cumulative line to reveal the vital few causes driving the majority of your problems.

Pareto Chart Formula

Creating a Pareto diagram involves a straightforward calculation process. Here's the step-by-step formula approach:

Step 1: Calculate Frequency or Impact

First, count how many times each problem occurs (or calculate the cost/impact of each problem type).

Frequency = Number of occurrences for each category

Step 2: Calculate Total

Add up all frequencies to get the total:

Total = Sum of all frequencies

Step 3: Calculate Individual Percentage

For each category, calculate what percentage it represents of the total:

Individual Percentage = (Category Frequency / Total) × 100

Step 4: Calculate Cumulative Percentage

Starting from the largest category, add percentages progressively:

Cumulative Percentage = Sum of all previous percentages + Current percentage

What Does a Pareto Chart Show?

A Pareto diagram combines the best of both worlds—the immediate clarity of a bar graph with the cumulative insight of a line graph. Here's what makes it powerful:

The Bars Tell the Story: Each vertical bar represents a problem category, arranged from tallest to shortest. The height shows frequency or impact. This simple arrangement immediately draws your eye to the biggest problems—no statistical knowledge required.
The Line Shows the Opportunity: The cumulative percentage line climbs from left to right, showing the combined impact of addressing each problem. When this line starts to flatten, you've found your "vital few"—the problems that, once solved, will transform your operation.
The Axes Frame the Decision: The left axis measures actual occurrences, the right shows cumulative percentage, and the horizontal axis lists your problem categories. Together, they create a complete picture that anyone can understand and act upon.

This visualization does something remarkable: it makes the invisible visible. Problems that seemed equally important suddenly reveal their true impact. The path forward becomes clear.

Pareto Real World Example

Pareto diagram showing defect categories in manufacturing with bars for scratches, cracks, color issues, and other defects, alongside a cumulative percentage line.

Look at this real Pareto diagram from a manufacturing facility. The bars show different types of defects found in one month, arranged from most common (scratches) to least common (other defects).

Here's the key insight: See where the orange line crosses the 80% mark? It happens after just three defect types—scratches, cracks, and color issues. This means:

Fix these three problems → Eliminate 80% of all defects
Ignore the other six for now → Save time and resources

Instead of trying to fix nine different problems, the team focuses on just three:

Why do scratches happen? (Maybe rough handling)
What causes cracks? (Could be temperature changes)
How to fix color issues? (Check supplier materials)

This simple focus typically cuts total defects by 60-70% in just a few months. That's the power of Pareto—work smarter, not harder.

What is a Pareto chart (diagram) used for ?

Quality Control Smart manufacturers prioritize defects, not just track them. When teams break down defects into specific categories—particle contamination, dimensional variations, assembly errors, material flaws—each reveals different root causes requiring targeted solutions.

The key is specificity. Generic "defect" tracking will not reveal actionable insights. Break them down into meaningful categories that point to specific improvement opportunities.

Equipment Maintenance Traditional maintenance schedules treat all equipment equally, but Pareto analysis reveals this approach wastes resources. Manufacturing studies show that bearing wear and sensor failures often account for nearly 50% of all equipment failure occurrences. By identifying which specific components cause the most downtime, teams can shift from time-based maintenance to condition monitoring on critical equipment.

The lesson: focus your predictive maintenance budget where failures hurt most.

Supply Chain Intelligence When supplier issues multiply, Pareto diagrams cut through the noise. Manufacturing teams tracking supplier-caused delays often discover that a small fraction of suppliers cause the majority of production stoppages. This data-driven insight enables targeted negotiations for backup agreements and buffer stock arrangements with critical suppliers.
Safety Management Safety teams using Pareto analysis on incident data typically find that specific operations or areas account for the majority of lost-time incidents. This focused view enables targeted ergonomic improvements and specialized training where they will prevent the most harm.

Safety resources are precious. Pareto diagrams ensure they go where they will have maximum impact.

Cost Reduction Not all problems cost the same. Frequency alone can mislead—a defect occurring frequently but costing little to fix might be less important than rare defects causing expensive customer line stops. Cost-weighted Pareto Charts often completely reverse improvement priorities, focusing teams on high-impact issues rather than high-frequency ones.

Why Pareto Charts Matter Now More Than Ever

Manufacturing is more complex than ever. Global supply chains, tight margins, and higher quality expectations mean every decision and every resource matters. Pareto charts help teams focus on what truly drives problems and results.

One major benefit is speed of decision-making. In manufacturing, slow decisions cost money. A Pareto chart reduces analysis time from days to minutes. With a quick look, teams can see which issues matter most and where action is needed.

Another advantage is that Pareto charts are easy to understand. Operators, engineers, and executives can all read the same chart and reach the same conclusion. This shared understanding improves alignment and speeds up action without requiring deep statistical knowledge.

Pareto charts also make progress visible. When charts are updated regularly, it becomes clear whether improvements are working. When the largest bars shrink or rankings change, teams can see real results instead of relying on assumptions.

Beyond solving daily problems, Pareto charts support long-term strategy. Repeated patterns across multiple charts can reveal deeper issues. If supplier-related problems appear at the top again and again, it may signal the need to rethink sourcing. If equipment failures dominate, investment in maintenance, upgrades, or automation may be justified.

Organizations that track Pareto trends over time can also prevent future problems. When a small issue starts moving up the chart month after month, teams can investigate early and address it before it becomes a major disruption.

Conclusion

In manufacturing, success isn't about solving every problem—it's about solving the right problems first. Pareto Charts cut through the noise to show you exactly where your efforts will deliver the greatest returns. By focusing on the vital few causes that drive the majority of your issues, you transform scattered firefighting into strategic improvement.

The beauty of Pareto analysis lies in its simplicity. No complex formulas, no statistical expertise required—just clear visual evidence that guides your team toward impact. Whether you're reducing defects, minimizing downtime, or cutting costs, the Pareto principle remains your compass: tackle the 20% that matters, and watch 80% of your problems disappear.

But knowing the principle and applying it in real-time are two different challenges. Modern manufacturing moves fast, and static charts built from monthly data reports can't keep pace. FlowFuse bridges this gap by connecting directly to your production systems, automatically collecting data, and generating dynamic Pareto diagrams that evolve as your operation does. See problems emerge before they escalate. Track improvements as they happen. Make decisions backed by live data, not outdated reports.

The first step is always the hardest—and the most important. Choose one persistent problem area this week. Gather the data. Build your first Pareto Chart. You'll be surprised how quickly priorities become obvious and how fast your team aligns around them.

Next up: read our article on building interactive Pareto diagrams in FlowFuse that connect directly to your production systems.

Ready to transform your manufacturing data into actionable insights?

Stop guessing which problems to tackle first. Try FlowFuse free for 14 days and build automated Pareto Charts that connect directly to your production data, or see a live demo of how leading manufacturers identify their vital few problems in real-time.

FlowFuse 2.21: AI-Assisted SQL, Low-Code Custom Nodes, and Remote Instance Performance Insights

2025-08-28T00:00:00Z

It's been a very busy release and we have many great new features available on FlowFuse that will provide a better Node-RED development experience, makes it easier to develop and interface with your Unified Namespace, provide more insight into Remote Instance performance and new low-code tooling for building your own custom Node-RED nodes.

Assistant Functionality in Tables Nodes

FlowFuse Expert in Tables recognizes table schema and turns natural language prompts into SQL queries

Building on our successful Tables launch in 2.20, we've now integrated AI assistance directly into our Tables nodes. This lowers the barrier for working with databases, reducing the dependency on SQL knowledge. With this, you can type a natural language prompt that will be interpreted in light of the structure of tables in your FlowFuse Tables, which enables an AI-supported autocomplete and assists with writing SQL specifically for connected FlowFuse tables.

This integration makes working with FlowFuse Tables even more accessible, allowing developers to leverage AI guidance for database operations without requiring deep SQL expertise.

Summarize Snapshots

New snapshot summarization provides clear, AI-generated descriptions of changes between versions

Managing instance versions becomes more intuitive with our new Snapshot Summary feature. When creating snapshots, FlowFuse can now automatically generate intelligent summaries that describes the changes introduced. This saves you time, and makes it much easier for teams to understand project evolution and quickly identify the right version for deployment or rollback scenarios.

Available for Pro and Enterprise.

Team Broker Nodes

Easily publish and subscribe to topics in the FlowFuse Broker using new Team Broker nodes. Send a message from a Node-RED flow directly into the FlowFuse Broker. These new nodes extend the Unified Namespace capabilities of FlowFuse and provide:

Publish Node: Send messages to any topic on your team broker with configurable retention settings
Subscribe Node: Receive messages from specified topics with flexible output formatting
Auto-Configuration: Nodes automatically use your team's broker settings
TypedInput Support: Dynamic topic configuration using message properties or static values

These nodes make working between Node-RED and the FlowFuse Broker much simpler and easier.

Low-Code Custom Node Development

Subflows are a great way in Node-RED to build custom nodes, all within the Node-RED Editor, and without having to write any code. The limitation of Subflows though is that they're constrained to just one Instance of Node-RED, they cannot be shared across your whole team. That is no longer the case.

We've now introduced the Subflow exporter which provides a low-code and intuitive way to create and manage custom nodes.

From the sidebar in your Node-RED Editor, you can now very easily create and manage custom nodes, without writing code or having to create and manage your own version control infrastructure. Simply create a flow in Node-RED, convert it to a subflow, fill out the package details for your new custom node and hit "Publish". Now your new node is available for all to install across your FlowFuse team.

Available for Enterprise customers only.

Remote Instance Observability

Remote Instance monitoring in the Performance view provides usage insights

Following the success of our Hosted Instance performance monitoring, we've extended observability capabilities to include Remote Instances too. This extension gives insight into CPU usage and memory usage for your remote instances.

This enhancement is particularly valuable for industrial deployments where remote instances run critical processes across multiple locations.

Blueprint: Energy Monitoring Dashboard

Energy Monitoring Dashboard provides realtime usage and cost insights

This Blueprint provides a real-time energy monitoring dashboard template for industrial facilities. It features live consumption tracking, cost analytics, spike detection, and historical trending with an integrated energy rate display. Perfect for demonstrating IoT energy management capabilities, and with Node-RED, it is fully customizable.

Annual Billing Option

New annual billing options provide cost savings and simplified budget planning

FlowFuse Cloud customers on Starter and Pro plans can now choose to subscribe on a yearly basis and receive a free month for doing so. This allows teams to save money compared to a monthly subscription and lock in current pricing.

What's Next?

For the next release, we're working on features that will enable you to connect your own AI models with Node-RED and FlowFuse, paving the way to create AI-supported automations in your applications. We're also planning on pushing a lot of performance updates to Dashboard, and to make it even easier to build your own applications on FlowFuse. We're excited about it -- stay tuned!

What else is new?

For a complete list of everything included in our 2.21 release, check out the release notes.

Which of these new features are you most excited to try? Email me directly at greg@flowfuse.com - I'd love to hear from you!

Try FlowFuse

FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

Get started for free and have your Node-RED instances running in the cloud within minutes.

Self-Hosted

Get FlowFuse running locally in under 30 minutes using Docker or Kubernetes.

Orchestrating Virtual Power Plants: How Low-Code Platforms Bridge the Gap

2025-08-22T00:00:00Z

Our electric grid is changing. For a century, it operated as a one-way street: large, centralized power plants generated electricity and pushed it downstream to homes and businesses. But today, that model is shifting. Rooftop solar panels, home batteries, and electric vehicles (EVs) are turning that one-way street into a dynamic, two-way intersection.

These technologies are known as Distributed Energy Resources (DERs). They promise a cleaner, more resilient, and more flexible energy future. However, with that promise comes a challenge: how do we manage this growing web of distributed systems? How do we coordinate them to work seamlessly with the traditional grid? The answer lies in the concept of the Virtual Power Plant (VPP).

What is a Virtual Power Plant?

A Virtual Power Plant isn’t a physical facility. It’s a software-based system that connects and orchestrates hundreds — sometimes thousands — of DERs into a unified energy asset. Think of it like a conductor of an orchestra: the conductor doesn’t play an instrument, but ensures that every musician plays at the right time and in harmony with the others.

Similarly, a VPP ensures that solar panels, batteries, EVs, and other devices respond to real-time energy conditions. It might tell a group of batteries to store excess solar power during the afternoon or instruct EVs to send power back to the grid during a peak evening demand spike. The goal is coordinated action that supports both local needs and broader grid stability.

Why VPPs Have Been So Hard to Build

While the concept of a VPP is not new, the execution has long been a technical and operational struggle. At the heart of the problem is integration — getting disparate devices and systems to work together.

First, there's the vendor lock-in problem. You might buy a top-tier battery system, only to find it doesn't communicate with your solar inverter from another manufacturer. This limits functionality and undermines the value of your investment.

Second, there's the manual integration nightmare. Engineers often spend weeks writing custom code to onboard new devices — and they must do this over and over for each new asset. It’s time-consuming, expensive, and frustrating.

Third, the data you eventually collect typically comes in inconsistent formats, making it difficult to use without first cleaning and transforming it. Valuable time is lost in standardizing data before any control logic can be applied.

Finally, there's the challenge of scale. As the number and types of assets grow, so do the operational complexities. How do you securely update logic across thousands of devices? How do you ensure uptime and reliability? How do you onboard new assets without starting from scratch every time? Without a centralized management platform, these challenges quickly become overwhelming.

Low-Code: The Universal Translator for the Grid

This is where low-code platforms, like FlowFuse built on Node-RED, come into play. They offer a powerful and accessible way to bridge the technical gap — without reinventing the wheel every time.

Using a low-code platform, an engineer can visually build flows and logic without needing to write large amounts of custom code. This approach dramatically accelerates development and reduces complexity.

For example, connecting to devices becomes as simple as dragging and dropping pre-built nodes. You can pull data from a solar panel using Modbus, a battery using a REST API, and even fetch weather forecasts — all within the same interface.

Once the data is collected, standardizing it is straightforward. JSON, CSV, Change, and function nodes allow you to reformat disparate data streams into a single, consistent structure that the VPP can understand.

Building logic is also visual. You can create rules like: “If the electricity price is high and the batteries are full, then send power to the grid.” Such logic is easy to build, read, and modify — even for teams that aren't deeply technical.

FlowFuse: Scaling and Securing the VPP

Beyond integration, FlowFuse provides the centralized control and management layer that VPPs need to scale. It gives operators a single dashboard to deploy logic, monitor device health, and push updates — regardless of how large or geographically dispersed the device fleet is.

Need to onboard new assets? You can do it from the same platform, without custom scripts or separate tools. This is what makes it possible to scale from managing 100 devices to 10,000 — in a structured, reliable way.

FlowFuse is also designed with industrial-grade security and management capabilities, essential for critical infrastructure environments. Role-based access control, audit logs, and deployment workflows are all built in.

And importantly, FlowFuse supports collaborative development. No more siloed knowledge stuck with one engineer. Teams can work together in a controlled environment, making development faster and more sustainable.

Ready to Build Smarter Energy Systems?

Virtual Power Plants are the future of the energy grid — but building them without the right tools is slow, brittle, and expensive. Low-code platforms like FlowFuse change that. They offer a practical, scalable, and secure way to integrate DERs, manage fleet operations, and coordinate distributed energy like never before.

Ready to revolutionize your energy infrastructure? Start building your VPP with FlowFuse's free trial or Book a Demo to see how leading energy companies are orchestrating thousands of DERs with low-code automation.

Save with FlowFuse Annual Billing – Now Available!

2025-08-22T00:00:00Z

We're excited to announce that FlowFuse customers can now choose annual billing for their Starter and Pro plans! Starting today, when you choose to pay for a full year upfront, you'll get one month completely free.

How Annual Billing Works

Switching to annual billing is straightforward:

New customers: Select annual billing when signing up for Starter or Pro plans

Existing customers: To switch to annual billing, go to Billing → Upgrade Team. Enable the yearly billing toggle, then click Switch to Yearly Billing.

When you switch to annual billing, any unused time from your current bill will be applied as a credit on your new invoice. For example, if you paid for a month and you upgrade to annual billing halfway through the month, that remaining half of a month charge will be deducted from your next invoice.

As your applications grow with additional Node-RED instances, you may wonder what happens if you add or delete instances. Not a problem: additional instances beyond the basic allowance for your plan - one hosted instance for Starter, five instances for Pro - will be billed yearly as well, but if you remove instances the amount you have already paid will be prorated either toward the next yearly billing cycle or toward any new product subscriptions you add, whichever comes first.

Your annual subscription will automatically renew each year unless you choose to cancel, giving you continuous access to FlowFuse's comprehensive Node-RED hosting and development platform.

Why Choose Annual Billing?

Beyond the immediate cost savings, annual billing offers several advantages for teams and individual developers:

Financial Benefits: Lock in current pricing for a full year and save money that can be invested back into your projects and development initiatives.

Administrative Simplicity: Reduce the overhead of monthly billing cycles and invoice processing, especially valuable for teams managing multiple subscriptions.

Long-term Planning: Annual commitments align well with project planning cycles and budget allocation, making it easier to plan your Node-RED development roadmap.

Perfect for Growing Teams

Whether you're a solo developer working on IoT projects or part of a larger team building enterprise automation solutions, annual billing provides the stability and savings that support sustained growth and development.

Our Starter plan remains perfect for individual developers and small projects, while the Pro plan continues to offer the advanced features and scalability that growing teams need.

Get Started Today

Ready to start saving with annual billing? Log into your FlowFuse account to make the switch, or sign up for a new annual plan today.

Questions about annual billing or need help choosing the right plan? Our support team is ready to help.

Try FlowFuse free →

Building Historical Data Dashboard with FlowFuse Tables

2025-08-21T00:00:00Z

In Industrial IoT, tracking data over time is crucial. Whether you’re monitoring temperature changes throughout the day, spotting machine downtime, or analyzing production trends across shifts, a historical data dashboard helps you see important patterns clearly.

This tutorial guides you through building such a dashboard using FlowFuse Tables. FlowFuse Tables currently provides a managed PostgreSQL database—a reliable and widely used system—which we will use throughout this tutorial to store time-series data.

Why PostgreSQL for Time-Series Data?

You might wonder if PostgreSQL can efficiently handle large volumes of time-series data. The answer is yes—when configured properly. Without optimization, query performance can slow as data grows. However, by using techniques like batch inserts and smart indexing, PostgreSQL delivers fast and reliable access even at an industrial scale.

PostgreSQL is selected as the first database offering in FlowFuse Tables because it is flexible, reliable, and open source. It serves as a solid foundation for FlowFuse Tables. Whether your data comes from IIoT sensors or other sources, PostgreSQL is well equipped to handle it.

Prerequisites

Before we begin, please ensure you have the following set up:

A FlowFuse Enterprise account, as FlowFuse Tables is an exclusive Enterprise feature.
The @flowfuse/node-red-dashboard package installed in your FlowFuse instance to create the user interface.
The node-red-contrib-moment node installed for handling date and time operations within your flows.
FlowFuse Tables configured for your FlowFuse Team with a managed PostgreSQL database.

If you are new to FlowFuse Tables, we highly recommend reading our getting started guide to familiarize yourself with the basics.

Creating an Optimized Database Schema

Our first step is to design a database table structured for both high-speed writes and efficient queries.

Step 1: Design and Create the Table

We will create a single table to hold all our sensor data. The key is to use appropriate data types and indexes to ensure performance.

In your FlowFuse Node-RED instance, drag a Query node onto the canvas.
Configure the node with the following SQL statement to create the table and its indexes:

CREATE TABLE "sensor_readings" (
    "id" SERIAL PRIMARY KEY,
    "timestamp" TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    "sensor_id" VARCHAR(50) NOT NULL,
    "location" VARCHAR(100),
    "temperature" DECIMAL(5,2)
);

CREATE INDEX "idx_sensor_timestamp" ON "sensor_readings"("sensor_id", "timestamp" DESC);

Schema Breakdown:

TIMESTAMPTZ: We use this data type to store timestamps with timezone information. This is critical for applications with sensors spread across different geographical locations, ensuring data is always consistent.
Index: The composite index on sensor_id and timestamp (in descending order) is vital for query speed. It allows PostgreSQL to quickly locate and return results for a specific sensor while already ordering them from newest to oldest. This avoids expensive sorting when fetching the most recent readings for a given sensor.

Important: The DESC in the composite index provides a significant performance boost for queries like:
SELECT * 
FROM sensor_readings
WHERE sensor_id = 'sensor_01'
ORDER BY timestamp DESC
LIMIT 10;
If you instead need results in chronological order, you could create an ascending index or let PostgreSQL reverse the order at query time.

To execute this one-time setup, connect an Inject node to the input of the Query node and a Debug node to its output.
Click Deploy, then click the button on the Inject node to create your table.

Step 2: Storing Sensor Data Efficiently with Batch Inserts

Writing every single sensor reading to the database individually can create significant overhead and slow down performance. A much more efficient method is to "batch" readings together and write them in a single transaction.

Let's build a flow to simulate sensor data and batch-insert it.

Add an Inject node configured to repeat every 1 second to simulate a continuous stream of data.
Connect it to a Change node that generates a simulated sensor reading. Configure it to set msg.payload using the following JSONata expression:

    {
        "sensor_id": "sensor_01",
        "location": "Production Line A",
        "temperature": 20 + $random() * 5
    }

Add another Change node to add a precise timestamp to each reading.
- Set msg.payload.timestamp
- To the value type timestamp.
Add a Function node and name it "Batch Accumulator". Paste the following JavaScript code into the node — it already includes inline comments explaining each step. This function will accumulate incoming readings in batches until the specified batch size is reached, and then creates the SQL query to perform batch inserts into the database.

// Set the number of records to collect before triggering a batch insert
const batchSize = 100;

// Retrieve previously stored readings from context (or start with an empty array)
const readings = context.get('readings') || [];

// Add the new reading (from msg.payload) to the readings array
readings.push(msg.payload);

// Check if we have enough readings to perform a batch insert
if (readings.length >= batchSize) {

    // Generate parameter placeholders for each reading (4 fields per record)
    // Example: ($1, $2, $3, $4), ($5, $6, $7, $8), ...
    const values = readings.map((_, i) => 
        `($${i * 4 + 1}, $${i * 4 + 2}, $${i * 4 + 3}, $${i * 4 + 4})`
    ).join(',');

    // Build the SQL insert query with placeholders
    msg.query = `
        INSERT INTO sensor_readings
        (timestamp, sensor_id, location, temperature)
        VALUES ${values};
    `;

    // Flatten the readings into a single array of values matching the placeholders
    // For each reading, we pass: current timestamp, sensor_id, location, temperature
    msg.params = readings.flatMap(r => [
        new Date(),          // Or use r.timestamp if actual reading time is available
        r.sensor_id,
        r.location,
        r.temperature
    ]);

    // Clear stored readings in context now that they are being inserted
    context.set('readings', []);

    // Return the msg with the SQL query and parameters for execution
    return msg;
}

// If not enough readings collected yet, store them back into context
context.set('readings', readings);

// Do not send anything forward yet
return null;

Connect the output of the "Batch Accumulator" to a Query node. This node will receive the fully formed msg.query and execute the batch insert.
Deploy the flow. It will now collect 100 readings (over 100 seconds) and perform a single, highly efficient database write instead of 100 separate ones.

Building the Interactive Dashboard

With data flowing into our database, let's create a user interface to query and visualize it.

Step 3: Create an Interactive Time Range Selector

We'll start with a form that allows users to select a date, time, and duration to view.

Drag a ui_form node onto the canvas. Create a new dashboard group for it and add the following form elements:

Time Range Selector form configuration in Node-RED Dashboard
Connect the output of the form to a Change node to format the input. Add the following rules in the Change node:
- Set msg.startDateTime to the JSONata expression:
```
payload.start & "T" & payload.time & ":00"
```
- Set msg.windowMinutes to the expression:
```
payload.window
```
Add a Date/Time Formatter node. This is crucial for handling timezones correctly. Configure it as follows:
- Input property: msg.startDateTime
- Input timezone: your local timezone, for example, Asia/Kolkata
- Output timezone: Etc/UTC (to match the database TIMESTAMPTZ standard)
- Output property: msg.startDateTime
Configuring the Date/Time Formatter node to convert from local timezone to UTC
Add another Change node to set the query parameters for the SQL query. Set msg.params to the following JSONata expression:
```
[
    msg.startDateTime,
    msg.windowMinutes & " minutes"
]
```

Connect this to a Query node with the following parameterized SQL, which fetches data for the selected time window:

SELECT 
    "timestamp",
    "temperature"
FROM "sensor_readings"
WHERE "sensor_id" = 'sensor_01'
  AND "timestamp" >= $1::timestamptz
  AND "timestamp" < ($1::timestamptz + $2::interval) ORDER BY "timestamp" DESC;

Connect a Debug node after the Query node to test the flow.
Drag a Switch node onto the canvas and add a condition to check whether msg.payload is empty. Connect the output of the Query node to the Switch node.
Connect the output for the "empty" condition from the Switch node to a Change node that sets msg.payload to:
```
No data found for the selected time range.
```
Drag a ui_notification node, select the appropriate UI group, and connect it to the output of the Change node.
Deploy the flow. On the dashboard, select a date, time, and window using the form. Verify in the debug panel that the correct data is returned, or that a notification appears if no data is found.

Complete time range selector form

Step 4: Display the Data in a Chart

The final step is to visualize the query result.

Connect the output of the final Query node to a ui_chart widget.
Configure the chart node:
- Group: Create new group for chart.
- Type: Line
- X: Set to timestamp as a key.
- Y: Set to temperature as a key.
- Series: Set to "Temperature" as string.
Deploy the flow. Your complete historical data dashboard is now live — you can explore it and experiment with different time ranges to see the results.

Historical data dashboard retrieving and displaying historical data

Below is the complete flow we built in this tutorial.

Conclusion

You have successfully built a historical data dashboard using FlowFuse Tables and Node-RED. By implementing efficient batch inserts and optimized query patterns, you have created a solution that is both powerful and scalable for demanding Industrial IoT environments.

With FlowFuse Tables now part of the platform, you can build complete industrial applications without juggling external databases or leaving the FlowFuse environment. FlowFuse is now a comprehensive data platform with the ability to collect, connect, transform, store, and visualize data. Combined with FlowFuse's enterprise features—team collaboration, version control, device management, and secure deployments—you have everything needed to take your IIoT projects from prototype to production within one integrated platform.

This means less complexity and faster time to value for your industrial data initiatives. Your historical dashboards, real-time monitoring, and OEE dashboards can all live in the same ecosystem, managed by the same team, with consistent security and governance controls.

Ready to build your own time-series dashboard? Get started with FlowFuse Tables or explore our industrial blueprints

Winning Through Open-Source Software in Manufacturing Digitalization

2025-08-20T00:00:00Z

The manufacturing sector is in an interesting situation. It's caught between a future with immense promise and a present with high complexity. The promised ROI of digital transformation (DX) is into the trillions of dollars globally over the next decade. For manufacturers, this is more than just an opportunity for incremental improvement; it is a fundamental shift to competitiveness.

Yet, on the other hand, a starkly different narrative is heard from the factory floor. Despite the commitment of many IT and OT teams, paired with colossal investment, the path to digitalization is proving to be unexpectedly slow. About 70% of digital transformation projects are (self-reported!) considered failures. Falling short of their objectives and failing to deliver the promised return on investment (ROI).

To break this impasse a strategic shift and pivot will be needed, industrial IT and OT need a decisive pivot to open-source software (OSS). With its core principles of collaboration, transparency, and interoperability—manufacturers can systematically remove barriers that have slowed their DX. Open source provides the tools and the philosophy necessary to acquire and transport data more effectively, build powerful analytics and interaction applications that deliver real ROI, and, most of all, escape vendor lock-in.

The Digitalization Paradox in Manufacturing

The economic case for digital transformation in manufacturing is unequivocal and immense. The global digital transformation market, valued at nearly $1 trillion in 2020, is forecasted to be over $2.7 trillion by 2026. This growth is driven by the operational benefits; the primary motivators for these investments are to achieve greater operational efficiency (cited by 40% of executives), a faster time-to-market for new products (36%), and an improved customer experience (35%).

To understand the paradox, one must dissect why manufacturing initiatives fail. These challenges are connected with one-another, and are symptom from more systemic issues. Financial constraints and ROI, particularly high initial costs for hardware, software, and integration, coupled with pressure for rapid ROI, create a catch-22. DX is now viewed as a cost center rather than a source of operational improvement and thus ROI. A lack of qualified workers and in-house skills, especially in IT, is another roadblock. With manufacturing competing for talent with tech and finance. Then there’s legacy systems, where factory floors have old, incompatible machinery and systems, making upgrading or retrofitting this "rigid infrastructure" costly and complex, often stalling or killing projects. Finally, cybersecurity fears arise from increased connectivity in factories, expanding the attack surface and making the implementation of robust and costly cybersecurity solutions complex, especially for SMEs.

The Iron Grip of Proprietary Systems and Vendor Lock-In

The challenges detailed in the earlier, stem from the same key issue – the manufacturing industry's historical and continued reliance on a technological paradigm built around closed, proprietary systems. This licensing model, which was key in enabling the first wave of digital automation, has now become a barrier. Its defining characteristic is vendor lock-in, a condition that systematically stifles innovation, inflates licensing costs, and holds the industrial sector as a whole back from progress.

Innovation has always driven industrial automation forward. The transition from mechanical systems to electrical relay logic in the early 20th century, and then to the maturing of Programmable Logic Controller (PLC) in the 1960s, transformed the factory floor. PLCs, followed by Supervisory Control and Data Acquisition (SCADA) and Distributed Control Systems (DCS), brought control, reliability, and programmability to industrial processes. These technologies were the engines of the Third Industrial Revolution. Industrial automation was leading the way in what was possible with digital systems, and combining these systems with one another in new ways. The manufacturers were driving innovation in the software industry and gaining real momentous ROI.

Since the late seventies, software became a copywrightable good, and with a shift happened mostly in traditional applications of the software – Vendor Lock-In.

Vendor lock-in is an economic and technical condition where a customer becomes so dependent on a specific vendor's products and services that switching to an alternative provider becomes prohibitively difficult or costly.

With that, manufacturers used to lead the way three quarters into the 20th century, now are stuck with their 21st-century digital ambitions.

The traditional, vertically integrated model of industrial digitalization, ‘featuring’ vendor lock-in, is a critical hindrance currently. This paradigm now showcases inflated costs, lack of innovation, interoperability issues, and a skills gap. These issues have effectively made manufacturers followers rather than leaders in the realm of software-aided business. To regain an edge a fundamental shift is a requirement. This shift requires abandoning vertical point-solutions and instead embracing a new technological foundation that is inherently open, fostering interoperability, and freeing manufacturers from the constraints of single-vendor control.

DX with Open-Source Software

In contrast to the closed, proprietary software, the open-source variant offers a fresh approach to creating and distributing software. Born from the need of collaboration and transparency, open-source software (OSS) provides fundamentals to break vendor lock-in once and for all.

In 1983, MIT programmer Richard Stallman, annoyed by the practice of withholding source code, founded the Free Software Foundation. His goal was to create a completely free (“Free” as in speech, and also “Free” as in beer) operating system, establishing a philosophy built on the user's right to run, study, modify, and redistribute software. In the late 1990s, this movement gained a more pragmatic and business-friendly identity with the coining of the term "open source".

The value proposition of OSS is great and shows up in four key points:

Cost-Effectiveness
High flexibility and extensibility
Cross-Industry collaboration
Stability and Strategic Control

To go over each, one by one.

The most immediate appeal of OSS is the absence of high upfront licensing fees. OSS is not "free" when considering the total cost of ownership (TCO), which includes implementation, integration, training, and support. The crucial difference lies in where the money goes. With proprietary software, a large portion of the budget is spent on license and maintenance fees that primarily benefit the vendor. With OSS, that same capital can be reinvested into activities that build direct value for the manufacturer.

Secondly, flexibility of software and freedom to extend it – the single most powerful advantage of OSS. Because the source code is accessible, manufacturers are no longer constrained by a vendor's limited feature set or development roadmap. Anyone can propose changes that modify, adapt, and extend the software to meet their operational needs. If a particular open-source tool doesn't support a niche industrial protocol, the company has the option to build that integration itself or hire a third party to do so. As these investments do not provide an edge over competition, it’s almost always shared within the OSS community – building libraries of open toolchains.

Extending on that; Cross-industry collaboration enables wildly different use-cases with the same fundamental problems to resolve to apply their knowledge and craft serving all other businesses. For example, database technology has been perfected for decades by banking and trading companies to allow for atomic transactions and durability of data of those transactions. These scalability improvements have profound impact for manufacturing use-cases around the world, helping out with compliance, track-and-trace, and more.

Finally, Long-Term Stability and Strategic Control is implicitly featured with OSS. With proprietary software, a manufacturer is exposed to the business risks of the vendor. If the vendor is acquired, goes out of business, or simply decides to discontinue a product line, the manufacturer can be left with an unsupported and obsolete system. With OSS, the code is publicly distributed and cannot be withdrawn. Even if the original maintainers abandon a project, the community—or the company itself—can "fork" the code and continue its development. This provides a level of long-term stability and strategic control over critical technology assets that is impossible to achieve in a vendor-dependent relationship.

Finale

The manufacturing industry faces a challenge with its digital transformation efforts. A reliance on proprietary systems has contributed to an impasse where investment does not always produce the expected results. This model, characterized by vendor lock-in, can lead to higher costs and constraints on innovation, causing manufacturers to lag in technology adoption.

To move forward, a different approach can be considered. Open-source software (OSS) offers a model that addresses many of the barriers causing digital transformation projects to fail. With OSS, companies can gain more strategic control over their technology, redirect funds from licensing fees toward in-house capabilities, and connect previously isolated systems. This allows a manufacturer to shift from being a consumer of a vendor's technology to a director of its own.

The conversation is therefore shifting from if manufacturing should adopt open source, to how it can be implemented to improve operations and deliver a return on investment. This transition presents new questions, but it is one that companies do not have to approach on their own. At FlowFuse, we work with manufacturers to navigate this change, and we would love to explain how an open-source strategy can transform your factory of the future. Download our comprehensive whitepaper "Open Source Software for Manufacturing," to learn how to transform your factory operations and secure a competitive edge.

OPC UA Tutorial: Advanced Monitoring with Subscriptions, Alarms, and Historical Data

2025-08-14T00:00:00Z

In our previous tutorial, we covered OPC UA basics—connecting to servers, reading tags, and writing values. Now it's time for the features that make OPC UA truly powerful in production.

Polling for data every few seconds works fine for demos, but real systems need better. They need instant updates when values change. They need alarms that fire immediately when something goes wrong. They need access to historical data for troubleshooting. And they need to trigger complex operations without juggling dozens of write commands.

This guide shows you how to build all of that using advanced OPC UA features in FlowFuse Node-RED.

What You'll Learn

This guide covers four powerful OPC UA features:

Subscriptions: Get real-time updates without constant polling
Events & Alarms: Capture and handle equipment alerts as they happen
Historical Data: Query past values for trending and analysis
Method Calls: Execute functions directly on your equipment

Prerequisites

To follow this guide, you'll need:

FlowFuse running instance with the node-red-contrib-opcua nodes installed
A working OPC UA server connection
The basics from our previous tutorial

Managing and scaling Node-RED instances is easy with FlowFuse, offering DevOps pipelines, audit logs, snapshots, high availability, and much more. Start your free trial today!

Before proceeding, check which features your OPC UA server supports—most handle subscriptions and events, but historical data and methods vary by vendor.

Let's get started.

Real-Time Monitoring with Subscriptions

OPC UA subscriptions monitor values on the server side and notify you only when they change. This is fundamentally different from polling, where you repeatedly ask for values whether they've changed or not.

Consider a pressure sensor that spikes from 5 to 20 bar and back to 5 bar in one second. With 2-second polling, you miss this critical event entirely. With subscriptions, the server captures it and notifies you immediately.

The efficiency gains are significant too. Monitoring 100 tags with polling means 100 requests every 2 seconds, consuming bandwidth even when nothing changes. Subscriptions send updates only when values actually change, reducing network traffic and server load.

Setting Up Subscriptions

To create your first subscription:

Drag an Inject node onto your canvas. This will trigger the subscription to start.

Note: This article uses Inject nodes for manual triggering to illustrate key concepts. In production, it is advisable to create interactive dashboards with FlowFuse Dashboard to enable effective monitoring and control. For more information on designing operator interfaces, please refer to this article.

Add an OpcUa-Item node. Double-click it and enter the NodeId of the tag you want to monitor, like ns=2;i=2007. Select the correct data type for your tag.
Place an OpcUa-Client node on the canvas. Open its Configuration, select your OPC UA server endpoint configuration, and change the Action dropdown to "SUBSCRIBE". Set the interval to how often you want updates.
Connect the Inject output to the OpcUa-Item input. Connect the OpcUa-Item output to the OpcUa-Client input. Add a Debug node and connect the OpcUa-Client output to the Debug input.
Deploy your flow and click the Inject button.

When clicked, the OpcUa-Item node sends the tag to the OpcUa-Client and creates the subscription. The node’s status will update to “subscribed” once the subscription is active. When values change, they appear in the debug panel. If no value changes occur within the interval time, the status will show “keep alive” to confirm that the connection is still active.

Subscribing to Multiple Tags

To monitor multiple tags, simply create multiple OpcUa-Item nodes and connect them all to the OpcUa-Client node. Each item node should have its own NodeId configured. When you trigger the flow, all tags start updating simultaneously.

For many tags, you can also use a Function node to subscribe to multiple tags at once. Connect the Function node directly to the OpcUa-Client node (no OpcUa-Item node needed). Use the "multiple" topic with the following code:

msg.topic = "multiple";
msg.payload = [
    { nodeId: "ns=3;i=1007" },
    { nodeId: "ns=3;i=1002" },
    { nodeId: "ns=3;i=1001" }
];
return msg;

Below is the complete flow monitoring multiple tags:

This subscribes to all tags in the array with a single request.

When using the "multiple" topic, each value update arrives in OPC UA's DataValue format. Here's what you'll see in the debug panel:

{
    value: {
        dataType: "Double",
        value: 23.5
    },
    statusCode: {
        value: 0,  // 0 = Good
        description: "Good"
    },
    serverTimestamp: "2025-07-24T11:12:45.640Z",
    sourceTimestamp: "2025-07-24T10:33:17.697Z"
}

Subscribing to multiple tags with OpcUa-Item nodes returns just the value.

Stopping Subscriptions

To stop receiving updates and free up server resources, you have two options:

UNSUBSCRIBE: Removes specific monitored items from the subscription but keeps the subscription alive. Use this when you want to stop monitoring certain tags while keeping others active.

DELETESUBSCRIPTION: Completely removes the subscription and all its monitored items. Use this when you're done monitoring and want to clean up all resources.

To use either action, change the OpcUa-Client node's Action dropdown to "unsubscribe" or "deletesubscription".

Events and Alarms

OPC UA events and alarms go beyond simple value monitoring. While subscriptions tell you "the temperature is 95°C", events tell you "high temperature alarm triggered at 14:32:15 on Tank 3".

Events capture the full context of what happened, when it happened, and what needs attention. Alarms are a special type of event that requires acknowledgment - perfect for critical situations that need human intervention.

Setting Up Event Monitoring

Add an Inject node to trigger the event subscription.
Add an OpcUa-Event node and configure the Source node to the event source. For server-wide events, use ns=0;i=2253 (the Server object).
Add an OpcUa-Client node with Action set to "EVENTS".
Connect the Inject output to the OpcUa-Item node input. Connect the OpcUa-Item output to the OpcUa-Client input. Add a Debug node and connect the OpcUa-Client output to the Debug input.

Deploy and trigger the flow. The debug panel will show events as they occur on your server.

Acknowledging Events

When alarms trigger, operators often need to acknowledge them to indicate they've seen the issue. Here's how to send acknowledgments back to the OPC UA server:

Add an Inject node to manually trigger the acknowledgment.
Add a Function node to prepare the acknowledgment message.
In the Function node, add the following code. Comments within the code explain what needs to be replaced.

msg.topic = "ns=6;s=MyLevel.Alarm";        // The alarm's NodeId
msg.conditionId = "ns=6;s=MyLevel.Alarm/0:EventId";  // NodeId + "/0:EventId"
msg.comment = "Acknowledged via Node-RED";  // Your acknowledgment message
return msg;

Add an OpcUa-Client node and configure it with your OPC UA server endpoint. Open the node’s configuration and set the Action dropdown to "ACKNOWLEDGE".
Connect the Inject output to the Function input. Connect the Function output to the OpcUa-Client input.

Deploy the flow. When you click the Inject button, it sends the acknowledgment to the server. The alarm state changes to "Event: <alarm's NodeId> Acknowledged" and operators know someone has seen the issue.

Method Calls

OPC UA methods let you execute functions directly on your equipment. Instead of writing multiple values to trigger an action, you call a method with parameters—like calling a function in code.

Methods are ideal for complex operations like starting batch processes, resetting counters, or triggering calibration routines. They encapsulate the logic on the server side, making your Node-RED flows simpler and more reliable.

Calling Methods

To call a method on your OPC UA server:

Add an Inject node to trigger the method call.
Add an OpcUa-Method node and double-click it. Select your OPC UA endpoint, then enter the Object ID (like ns=6;s=MyDevice) and Method ID (like ns=6;s=MyMethod).
In the Arguments section, enter each argument's name, type, and value. For example:
- Name: Operator, Type: String, Value: "sin"
- Name: Value, Type: Double, Value: 3.3
Connect the Inject output to the OpcUa-Method input. Add a Debug node to see the result.

Deploy and click the Inject button. The method executes on the server and the node status changes to "Method Executed". The result appears in the debug panel.

Historical Data Access

OPC UA Historical Access lets you query past values from your equipment. Instead of just seeing current temperature, you can ask "what was the temperature yesterday at 3 PM?" or "show me all pressure values from the last shift."

This is essential for troubleshooting, compliance reporting, and trend analysis. However, not all OPC UA servers support historical data—check your server documentation first. Also, not all tags are configured for history—verify that the "Historizing" attribute is set to true for your tag.

Reading Historical Values

To query historical data from your server:

Add an Inject node to trigger the historical read.
Add a Function node to prepare the query parameters.
In the Function node, add this code:

msg.topic = "NodeId ns=6;s=MyLevel"; // Replace with your NodeId
msg.aggregate = "raw"; // Or use: "min", "max", "ave", "interpolative"
msg.start = new Date(Date.now() - 60 * 60 * 1000); // 1 hour ago
msg.end = new Date(); // Now
return msg;

Add an OpcUa-Client node. Open its configuration and set the Action dropdown to "HISTORY".
Connect the Inject output to the Function input. Connect the Function output to the OpcUa-Client input. Add a Debug node to see the historical values.

Deploy and click the Inject button. The debug panel shows all stored values for that tag within your time range.

Advanced Historical Queries

While all historized tags support raw data, aggregate support varies by tag type. Analog values typically support aggregates like min, max, and ave, while discrete tags may only support raw.

Working with Aggregates:

msg.topic = "ns=6;s=MyLevel";
msg.aggregate = "ave";  // Options: "min", "max", "ave", "interpolative"
msg.start = new Date(Date.now() - 60 * 60 * 1000); // 1 hour ago
msg.end = new Date(); // Now
msg.interval = 300000;  // Required for aggregates: 5-minute intervals
return msg;

Hourly Averages for the Last Day:

msg.topic = "ns=3;s=Temperature";
msg.aggregate = "ave";
msg.start = new Date(Date.now() - 24*60*60*1000);  // 24 hours ago
msg.end = new Date();
msg.interval = 3600000;  // 1-hour intervals
return msg;

Peak Detection:

// Find maximum values in 15-minute windows
msg.topic = "ns=3;s=Pressure";
msg.aggregate = "max";
msg.start = new Date().setHours(0,0,0,0);  // Midnight today
msg.end = new Date();
msg.interval = 900000;  // 15-minute intervals
return msg;

The historical data returns with timestamps and quality codes. Use this for shift reports, compliance documentation, or troubleshooting equipment issues that happened hours or days ago.

You've now mastered the advanced features that make OPC UA essential for industrial systems. With subscriptions, you're monitoring values in real-time without wasting bandwidth. With events and alarms, you're capturing critical alerts the moment they happen. With method calls, you're executing complex operations with a single command. And with historical access, you have the data trail needed for analysis and compliance.

Scale Your OPC UA Implementation

Managing OPC UA flows across multiple sites? FlowFuse helps teams deploy Node-RED to hundreds of edge devices with one click, monitor everything from a central dashboard, and roll back instantly if something goes wrong. Built-in team collaboration, audit logs, and enterprise security keep your industrial data safe.

Following our managed MQTT broker, we've now added database services built right into the platform, plus new AI features that make building flows faster than ever.

Get started free and scale and manage your Node-RED deployments today.

FlowFuse's New Database: The Easiest Way to Store Industrial IoT Data

2025-08-08T00:00:00Z

FlowFuse recently introduced a beta release built-in database service to their platform, making it easier than ever to store Industrial IoT data. In a typical setup, you would need to provision a database, manage connection strings and credentials, configure nodes, and handle security settings. The goal of this new feature is to simplify or even eliminate those steps entirely. In this article, you will learn how it works and how to get started.

Getting Started

FlowFuse Tables is available for Enterprise users. If you do not have an Enterprise FlowFuse account and are interested in trying it out, contact us to get started.

Step 1: Enable the Database in Your Project

Once the database feature is active on your account, the first step is to create a database instance for your team to use.

Log in to your FlowFuse platform.
In the navigation menu on the left, select the Tables option.
On the next screen, you will be prompted to "Choose which Database you'd like to get started with."
Currently, only Managed PostgreSQL is available. Click on Managed PostgreSQL to proceed.

FlowFuse Tables

After you make your selection, FlowFuse will begin provisioning your dedicated database in the background. This process typically takes only a few moments.

Once the provisioning is complete, you will see two tabs in the Tables section:

Explorer – Allows you to manage your tables through the user interface. You can create tables, add columns, and view stored data.

FlowFuse Tables: Explorer Tab

Credentials – Provides the database connection details such as host, port, username, and password. These credentials allow you to access the FlowFuse-managed database from outside FlowFuse as well.

FlowFuse Tables: Credentials Tab

Step 2: Create Your First Table

With your database instance provisioned, you can now create a table to start storing data.

FlowFuse offers two ways to create a table:

Option 1: Using the Table Explorer (UI)

Navigate to the Explorer tab under the Tables section.

Click the + button.
A form will slide in from the right side of the screen.
In the first input field, enter the name of your table.
Click Add New Column to start defining the structure of your table:
- Column Name: Enter the name of the column.
- Type: Select the appropriate data type (e.g., text, bigint, boolean).
- Default: Check this if you want to set a default value for the column and Once checked, enter the default value in the input field that appears next.
- Nullable: Check this if the column can contain empty (null) values.

Interface for creating FlowFuse tables

Click Save once your columns are defined.

Option 2: Using SQL via the Query Node

If you prefer writing raw SQL or need more control over your table structure, you can use the Query node in Node-RED.

Go to your FlowFuse instance where you plan to build the flow and use this table.
Once you're in the Node-RED editor, look at the left-side node palette. You will find the Query node under the FlowFuse category.

FlowFuse Query Node

Drag the Query node into your flow.

The Query node uses standard SQL syntax and is pre-configured to connect to your FlowFuse-managed database automatically — you do not need to manually enter any database credentials when working inside a FlowFuse Node-RED instance.

Double-click the Query node and write your SQL command in the Query field.

Note: Table names and column names are case-sensitive in SQL when using certain databases like PostgreSQL. To avoid unexpected errors, it is recommended to wrap them in double quotes in your queries.:

For example:

CREATE TABLE "maintenance_tasks" (
  "id" SERIAL PRIMARY KEY,
  "title" TEXT NOT NULL,
  "description" TEXT,
  "assigned_to" TEXT NOT NULL,
  "due_date" DATE NOT NULL,
  "status" TEXT NOT NULL CHECK ("status" IN ('pending', 'in_progress', 'completed')),
  "priority" TEXT NOT NULL CHECK ("priority" IN ('low', 'medium', 'high'))
);

If you want to send the SQL query dynamically at runtime, you can pass it through msg.query instead of hardcoding it in the node configuration.

Add an Inject node to trigger the query and optionally connect a Debug node to see the output.
Deploy and click the inject button to create the table.

Step 3: Performing Operations with Your Table

Once your table is ready, you can start interacting with it using the Query node. This node allows you to run SQL queries directly—whether it is inserting new data, retrieving records, updating rows, or deleting entries. You can perform all standard operations just as you would with the other database nodes. For this demonstration, you will see how to insert data into your table.

For a complete walkthrough of CRUD operations, you can try out the flow provided at the end of this guide.

Inserting a New Record

In your Node-RED editor, drag a Query node from the FlowFuse category.
Add an Inject node.
Drag a Change node and place it between the Inject and Query nodes. Connect the Inject node to the Change node, and then connect the Change node to the Query node. Double-click the Change node and configure the following properties based on your SQL query requirements. For example:
- msg.title = "Check motor status"
- msg.description = "Routine check of motor and related sensors"
- msg.assigned_to = "technician_1"
- msg.due_date = "2025-08-10"
- msg.status = "pending"
- msg.priority = "medium"
Double-click the Query node and write the SQL command in the Query field, For example:

INSERT INTO "maintenance_tasks" (
  "title",
  "description",
  "assigned_to",
  "due_date",
  "status",
  "priority"
) VALUES (
  {{{msg.title}}},
  {{{msg.description}}},
  {{{msg.assigned_to}}},
  {{{msg.due_date}}},
  {{{msg.status}}},
  {{{msg.priority}}}
);

This node uses the Mustache template system to dynamically generate queries based on message properties, using the {{{ msg.property }}} syntax.

While convenient for quick testing and prototyping, this method is not recommended for production use. For better reliability and maintainability, consider using parameterized queries, for that follow Using Parameters in Your Queries.

Optionally, connect a Debug node to the output of the Query node to inspect the result.
Deploy the flow and click the Inject button to execute the query.

Upon a successful insert operation, the Query node will output a msg.payload containing an empty array, and a msg.pgsql object that includes the executed command and a rowCount indicating the number of rows affected.

For update or delete operations, the behavior is the same. For select operations, the msg.payload will contain an array of the returned rows.

Using Parameters in Your Queries

As mentioned earlier, placing Mustache-style strings directly into SQL queries is not considered a best practice. Instead, you should use parameterized queries to keep your queries cleaner, more reliable, and easier to maintain while following best practices.

The FlowFuse Query node supports both numbered parameters and named parameters, making your SQL queries more flexible, secure, and reusable.

Option 1: Numbered Parameters

Numbered parameters let you define placeholders in the SQL string and then pass actual values through msg.params as an array.

Drag an Inject node.
Drag a Change node and set properties based on your SQL command requirements. For example:
- Set msg.payload.priority to 'high'
- Set msg.payload.status to 'pending'
Add a Change node and set msg.params to [msg.payload.priority, msg.payload.status].
Add a Query node and write an SQL query with numbered parameters. For example:

SELECT * FROM "maintenance_tasks"
WHERE "priority" = $1 AND "status" = $2;

Optionally, add a Debug node to view the output.
Connect the Inject node to the Change node that sets the payload values, then connect it to another Change node that sets the query parameters. Next, connect it to the Query node, and finally connect the Query node to the Debug node.
Deploy the flow and trigger the Inject node.

This query will retrieve rows where priority and status match the specified values. When you click the Inject node, the actual values from msg.params will be passed into the placeholders $1 and $2.

Option 2: Named Parameters

Named parameters allow you to reference values by name using a dollar prefix (e.g., $status) in your SQL query. The actual values are passed using msg.queryParameters as an object.

Drag an Inject node.
Drag a Change node and set properties based on your SQL command requirements. For example:
- Set msg.payload.id to 1
- Set msg.payload.status to "in_progress"
Add another Change node and set msg.queryParameters to {}. Then add the following rules:
- Set msg.queryParameters.id to msg.payload.id
- Set msg.queryParameters.status to msg.payload.status
Add a Query node and write the SQL query using named parameters. For example:
```
UPDATE "maintenance_tasks"
SET "status" = $status
WHERE "id" = $id;
```
Optionally, add a Debug node to view the output.
Connect the Inject node to the Change node that sets the payload values, then connect it to another Change node that sets the query parameters. Next, connect it to the Query node, and finally connect the Query node to the Debug node.
Deploy the flow and click the Inject button to trigger the update.

When the flow runs, the values in msg.queryParameters will replace $status and $id in the SQL statement, ensuring that your queries are dynamic, readable, and secure.

The Node-RED flow provided below demonstrates a complete set of database interactions. It covers table creation, all standard CRUD (Create, Read, Update, Delete) operations, and includes examples of how to use both numbered and named parameters.

Wrapping Up

You've now learned how to leverage FlowFuse Tables to simplify database management in your Industrial IoT projects. Here's what you've accomplished:

Provisioned a managed PostgreSQL database with zero configuration overhead
Created tables using both the intuitive UI and flexible SQL approach
Executed queries safely using parameterized queries for production-ready flows
Performed CRUD operations with the versatile Query node

The combination of FlowFuse Tables and the built-in MQTT broker eliminates the complexity of managing external database and messaging infrastructure, letting you focus on building automation solutions rather than wrestling with DevOps.

Ready to see how FlowFuse Tables can accelerate your next industrial project? Book a demo with our team to explore the full platform capabilities.

Next up: We'll dive into Query node advanced features including backpressure handling and streaming large datasets—essential techniques for high-volume industrial applications.

The Evolution of Business Automation: Why Pricing Models Matter

2025-08-08T00:00:00Z

The automation landscape is evolving rapidly, and recent industry developments have sparked important conversations about how businesses should evaluate their automation platforms. N8N’s recent shift from workflow-based to execution-based pricing — positioned as removing limits — has received mixed reactions from the community, with many growing businesses finding the reality more complex. As pricing models change across the industry, now is the perfect time to reflect on what truly matters when choosing the right automation solution for your needs.

The Current State of Automation Pricing

Many automation platforms are rethinking their pricing structures, moving from workflow-based models to execution-based billing. While this approach aims to provide more flexibility, it can create new challenges for businesses trying to predict costs and plan their automation strategies.

Execution-based pricing means each step or run of your workflow consumes credits or counts toward your usage limits. What initially appears straightforward can become complex when scaling automation across teams and departments.

What Business Users Really Need

Based on conversations we're seeing in automation communities, business users are looking for:

Cost predictability: The ability to forecast automation expenses as operations grow
Scalability confidence: Knowing their platform can handle increased complexity without surprises
Team collaboration: Tools that support multiple users working together effectively
Enterprise readiness: Solutions built to handle business-critical operations from the start

FlowFuse: Built for Business Automation

FlowFuse takes a different approach to business automation, focusing on what enterprises actually need rather than trying to retrofit consumer tools for business use.

Industrial-Grade Foundation

FlowFuse is designed as an Industrial Application Platform that empowers teams to build, deploy and manage applications that optimize industrial operations. This isn't an add-on feature—it's fundamental to how we approach automation.

The Power of Node-RED

At the heart of FlowFuse is Node-RED, the free and truly Open Source low-code programming tool of choice for industrial applications. With over 5,000 community-contributed nodes, Node-RED enables engineers to collect, transform, and integrate data through visualized dashboards. It's been proven in everything from home automation to massive industrial deployments.

Transparent Business Model

Rather than complex execution counting, FlowFuse focuses on delivering reliable automation that scales with your business needs. Our approach eliminates the guesswork and lets you focus on building solutions rather than calculating usage; costs scale with how many Node-RED runtimes you need to manage.

Key Advantages of the FlowFuse Approach

Enterprise-First Design: FlowFuse is built specifically for mission-critical business applications where reliability isn't optional.
True Team Collaboration: FlowFuse enables organizations to reliably deliver Node-RED applications in a continuous, collaborative and secure manner, supporting team-based development from the ground up.
Flexible Deployment Options: Whether you need cloud, on-premises, or hybrid deployment, FlowFuse adapts to your infrastructure requirements without artificial constraints.
Mature, Battle-Tested Ecosystem: Built on Node-RED's proven foundation, FlowFuse leverages years of community development and real-world industrial deployment experience.

Evaluating Your Automation Strategy

As the automation landscape evolves, consider these key factors when choosing or re-evaluating your platform:

Cost Transparency: Can you clearly understand and predict your automation costs as you scale?

Business Focus: Is your platform designed for enterprise requirements, or adapted from simpler use cases?

Team Support: Does your solution enable effective collaboration across your organization?

Long-term Stability: Is your chosen platform built to handle the complexity and scale of business operations?

The FlowFuse Advantage

FlowFuse stands out because we've built our platform specifically for business automation challenges:

Predictable, business-friendly pricing that grows with your needs
Industrial-grade reliability for mission-critical applications
Enterprise security and compliance built in from day one
Professional support that understands business requirements

Ready to Experience the Difference?

While other platforms adapt consumer tools for business use, FlowFuse was designed from the ground up for enterprise automation needs.

A free trial is available for FlowFuse Cloud, and you can also run FlowFuse locally, docker-based, or in Kubernetes.

Experience automation without the complexity of execution counting or artificial limitations. Discover how FlowFuse can support your business's growth with transparent, scalable solutions.

Ready to get started? Explore FlowFuse today and see why businesses choose purpose-built automation platforms.

FlowFuse 2.20: AI-Assisted Node-RED & New Database Service

2025-07-31T00:00:00Z

This release represents a major leap forward in FlowFuse's data management and AI capabilities, introducing our new FlowFuse Tables database feature, along with enhanced AI assistance features and a streamlined user interface. These improvements make FlowFuse a complete solution for building industrial applications, even while reducing development time.

Introducing: FlowFuse Tables

A screenshot of the new "Tables" view, now available in FlowFuse

FlowFuse Tables is our brand new database offering that provides a simple way to store your data, all within the FlowFuse ecosystem. This comprehensive database offering comes with FlowFuse's enterprise-grade security and unlocks the ability to seamlessly build critical systems like MES and ERP.

FlowFuse Tables eliminates the complexity of setting up and managing separate database infrastructure, allowing you to focus on building applications that drive operational efficiency.

FlowFuse Tables is available now for all Enterprise users running on FlowFuse Cloud.

New Node: Query

A flow in Node-RED that uses the new FlowFuse "Query" node

Alongside the new Tables offering, we have shipped a new node that you can find in your Node-RED Editor - "Query". This will automatically connect to any associated database you have with your team, saving you time in manually configuring nodes and credentials, giving you more time to just focus on the fun of building your flows, and making it really easy to start storing and querying your data.

AI-Assisted Node-RED with Smart Suggestions

GIF of Smart Suggestions in Action

Development in Node-RED is now even faster with Smart Suggestions, an agent that runs in-browser and offers intelligent flow completion for next-node recommendations. With Smart Suggestions, as you place a node, the agent will automatically calculate the most likely next node to place, and will offer suggestions for the node's configuration. It present up to 5 options, so even if the first suggestion isn't correct, it's very likely that the correct choice is only a quick keyboard shortcut away.

This work extends the functionality of the in-built FlowFuse Expert and it's MCP server that runs behind the Node-RED Editor to provide power additional development enhancements.

New Blueprint: Agentic AI with Retrieval Augmented Generation

The new RAG (Retrieval Augmented Generation) Blueprint enables you to train your own LLM agents, combining your own data with natural language capabilities.

This Blueprint provides two flows: one that adds text into Node-RED's flow context store and uses it to train an OpenAI agent, so you can query the content of the flow directly; and one flow that scrapes websites to train an OpenAI agent so that content can be queried and used as well.

The RAG Blueprint makes it easy to create intelligent agents that leverage your organizational knowledge without requiring deep AI expertise. Try it out for yourself here.

Refined Applications Page

Screenshot of Redesigned Applications Page

With the new FlowFuse Home page in place, we have greatly streamlined the Applications page. The new structure includes:

Streamlined Navigation: Applications now appear under Instances in the navigation hierarchy
Reduced Cognitive Load: Eliminated the overwhelming number of buttons and links in the previous design
Focus on Important Information: The newly refined design focusses on giving you a clear overview of the status of your Hosted and Remote Instances, split by Application.
Performance Optimizations: The above has also lead to faster page loading and improved responsiveness

This redesign creates a more intuitive workflow that aligns with how teams actually use FlowFuse, reducing clicks and improving productivity.

More Powerful "Small" Instances

Based on user feedback and our own review of instance performance, we have increased the CPU and memory of all "small" Node-RED instances running on FlowFuse. This will have the immediate benefit of preventing slowdowns and loading issues for all Starter and Team customers.

What's Next?

Our development roadmap continues to focus on AI integration and enterprise data management. Upcoming releases will expand FlowFuse Tables with additional database types and analytics capabilities, while our FlowFuse Expert will gain more sophisticated workflow automation features.

We're also working on enhanced Blueprint offerings and deeper integration between our AI capabilities and industrial data sources, with several exciting announcements planned for the coming months!

What else is new?

For a complete list of everything included in our 2.20 release, check out the release notes.

Which of these new features are you most excited to try? Email me directly at greg@flowfuse.com - I'd love to hear from you!

Try FlowFuse

FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

Get started for free and have your Node-RED instances running in the cloud within minutes.

Self-Hosted

Get FlowFuse running locally in under 30 minutes using Docker or Kubernetes.

FlowFuse Expert: Let Your Engineers Build Automation, Not Write Code

2025-07-29T00:00:00Z

Every manufacturing engineer knows this scenario: Node-RED's visual programming handles most of your automation needs brilliantly. Connect to PLCs, route data, trigger actions—all with drag-and-drop simplicity, but then you hit the wall. Your machine outputs data in a proprietary format. You need a custom dashboard widget that doesn't exist. You're manually creating test data for hours, or you're trying to understand a complex flow built by someone who left last year.

These bespoke tasks can often demand coding skills—JavaScript for parsing data, Vue.js for custom widgets, CSS for styling. Skills your automation engineers might not have. Skills that pull them away from what the engineers do best: optimizing production.

FlowFuse Expert changes this dynamic completely. Describe what you need in plain English, then, get working code instantly. No more hours lost to syntax errors or Stack Overflow searches. Your engineers can focus on their own expertise, and FlowFuse Expert fills in the gaps. Let's look at how manufacturing teams can use it to solve real problems.

Parsing Machine Data Without the JavaScript Struggle

While Node-RED's low-code nodes cover most scenarios, every production line has unique quirks. Complex data parsing, multi-step calculations, proprietary protocols—these can all be accomplished in Node-RED by writing your own JavaScript. Engineers, who should be focussed on optimizing processes, end up out of their comfort zone, searching regex patterns and debugging syntax errors.

Consider this output from a CNC machine that's been reliable for 15 years:

-- CYCLE END REPORT --
ID: M-45B / PART: XF-201
TIMESTAMP: 2025-07-09T14:22:01Z
SERIAL: 2025-0001547
OPERATOR: JONES, M
STATS ---
PART_COUNT: 481
CYCLE_TIME: 114.72
MAX_TEMP: 85.3
TOOL_WEAR_IDX: 0.73
COOLANT_LEVEL: OK
ALERTS: NONE
-- END --

The traditional approach means spending 30-50 minutes writing regex patterns, handling edge cases, and testing thoroughly. Your engineer needs to remember JavaScript string methods, debug regex syntax, and account for variations in the output format.

With FlowFuse Expert, the process changes completely. Your engineer opens a function node, clicks the FlowFuse Expert button, and types:

"Parse this CNC report format. Extract PART_COUNT as integer, CYCLE_TIME as float, TOOL_WEAR_IDX as float, OPERATOR name, and ALERTS. Return as JSON."

The engineer reviews the code, tests it with their data, and moves on to solving actual manufacturing problems instead of wrestling with JavaScript syntax.

FlowFuse Expert generating a Node-RED function node to extract data from a CNC text report.

Creating Test Data in Seconds, Not Hours

Before connecting to live equipment, you need test data that looks real. Making it by hand is tedious and wastes lots of time.

With FlowFuse Expert, just ask:

"Generate 20 machine records with machine_id, production_count, efficiency_percentage, downtime_minutes, and last_maintenance_date. Show realistic variations."

It's as simple as that.

FlowFuse Expert creating realistic test data for manufacturing dashboards—complete with machine IDs, production metrics, and maintenance dates.

Building Custom Dashboards Without Web Development

FlowFuse Dashboard widgets cover most UI needs, but manufacturing can often demand more. Custom visualizations for specific KPIs can be build in Dashboard with the "Template" node, where developers can write their own Vue.js templates.

Developing custom components to match your HMI design standards takes CSS expertise. Whether you're building new widgets or styling existing ones, you're suddenly in web development territory—far from where most automation engineers want to be.

Take a Pareto Chart for defect analysis as an example—essential for quality teams but not available as a standard Dashboard widget. Building it requires Vue.js knowledge, Chart.js integration, and responsive design skills.

With FlowFuse Expert, just describe what you need:

"Create a Pareto chart widget showing defect counts as bars with a cumulative percentage line. Include the 80% threshold."

FlowFuse Expert building both custom widgets and styling existing components for manufacturing dashboards.

Or consider input boxes for operator data entry that look too modern. Your team prefers the familiar green LCD screens they've used for decades, you can ask FlowFuse Expert:

"Add CSS that makes the input with classes 'calculator' and 'text-input' look like an old green LCD calculator screen."

FlowFuse Expert creating CSS that transforms standard input boxes into retro LCD displays with glowing green text.

Whether creating new widgets or styling existing ones, FlowFuse Expert handles the Vue.js and CSS complexity. You describe the outcome—it generates the code.

Documenting Complex Flows Before Knowledge Walks Out

Production flows evolve over years into complex systems. Hundreds of nodes, critical logic buried in functions, intricate routing between tabs. When knowledge walks out the door, new team members can face weeks of detective work trying to understand flows and their colleague's work.

FlowFuse Expert's Flow Explainer solves this. Select any flow or group of nodes, click "Explain," and get instant documentation. It analyzes connections, reads function code, and generates clear explanations of what everything does and why.

FlowFuse Expert turning complex flows into clear documentation for easy knowledge transfer.

Start Building Today

FlowFuse Expert is just one way FlowFuse helps manufacturing teams work faster.

Teams collaborate on flows in real-time. Version control with snapshots means you can always go back if something breaks. Remote device management handles edge devices across your factory floor. Deploy to one machine or a thousand with a single click. Built-in DevOps pipelines streamline your workflow from development to production.

For production reliability, high availability keeps systems running 24/7. The integrated MQTT broker handles all your device messaging. Enterprise security includes SSO, multi-factor authentication, role-based access control, and complete audit logs.

FlowFuse gives you everything you need to build, deploy, and manage Node-RED at scale.

Try FlowFuse free →

Statistical Process Control (SPC): Benefits and Implementation Guide

2025-07-24T00:00:00Z

Leading manufacturers are quietly saving thousands, sometimes millions, of dollars annually with a quality control method that's been proven since the 1920s. The difference today? Modern tools make it simple to implement.

Consider this real example: A manufacturer shared on Practical Machinist forum that they process 400,000 parts per year with a 4% scrap rate. That's 16,000 parts discarded annually. At even a conservative $10 per part, this represents $160,000 in direct losses from a single production line. They accepted this as normal because industry reports confirm 4-5% scrap rates are standard.

What separates industry leaders from the rest? They refuse to accept "normal" waste. Using Statistical Process Control (SPC), they detect problems as they occur, not after producing defective parts. When a process begins drifting, they receive immediate alerts and correct it before generating scrap.

This guide shows you exactly how to build a real-time SPC system using FlowFuse. You'll create a live dashboard that tracks measurements and alerts operators the moment something goes wrong. No statistics degree needed, just practical steps you can implement today.

Why Traditional Quality Control Falls Short

Most manufacturers still rely on end-of-line inspection. Make parts, check parts, scrap the bad ones. This reactive approach creates three expensive problems:

Problem 1: You're always too late When inspection finds a defect, you've already invested in material, machine time, labor, and energy. That investment is now scrap. Worse, how many parts did you make between when the problem started and when you caught it?

Problem 2: The borderline parts you miss Not all defects are obvious. Parts that barely pass inspection today might fail in the field tomorrow. These marginal parts slip through because traditional inspection only catches clear failures, not process degradation.

Problem 3: No insight into root causes Finding bad parts tells you nothing about why they're bad. Was it temperature drift? Tool wear? Material variation? Without process data, you're guessing at solutions.

The Proactive Alternative: Statistical Process Control

SPC flips the entire approach. Instead of checking parts after production, it monitors your process during production. The NIST Engineering Statistics Handbook explains it simply:

"The underlying concept of statistical process control is based on a comparison of what is happening today with what happened previously."

When your process starts to drift from its normal behavior, SPC alerts you immediately. You fix the issue before making defective parts, not after.

Walter Shewhart developed this method at Bell Labs in the 1920s, proving its effectiveness across industries. Today, FlowFuse makes it accessible to any manufacturer, regardless of size or technical expertise.

Building Your First SPC System with FlowFuse

Let's build a real example. This guide shows you how to create a SPC control chart for individual measurements - perfect for monitoring critical dimensions in real-time.

First, open your FlowFuse Node-RED instance. If you don't have one yet, you can sign up for a free account and have an instance running in minutes.

What We're Building

A real-time SPC control chart that monitors individual measurements and automatically calculates control limits. Perfect for scenarios where you measure one part at a time - like bearing dimensions on a CNC line. When measurements drift outside the calculated limits, you'll know instantly.

Step 1: Get Your Tools Ready

First, we need two nodes for SPC monitoring.

Open FlowFuse's palette manager (hamburger menu → Manage palette)
Go to the Install tab
Search for and install these nodes:
- node-red-contrib-simple-spc - This is your statistics engine
- @flowfuse/node-red-dashboard - For that slick real-time chart
Click Install for each node and wait for completion

Step 2: Simulate Your Machine Data

In production, you'd connect to your PLC. For now, let's simulate a bearing measurement around 10mm nominal.

Drag an inject node onto your canvas. This is your "sensor."
Double-click it and set:
- Repeat: interval → 2 seconds (mimics real sensor timing)
- Payload: switch to JSONata mode and enter: $random() * 0.2 + 10

This generates readings like 10.05, 9.98, 10.11 - realistic variation around 10mm.

Step 3: Add the Statistical Brain

Find the spc node in your palette (it'll be under "function" category after install).

Drag it over and wire your inject node to it.
Double-click to configure:
- Control Limit Multiplier: 3 (for 3-sigma limits)
- Timer: 10 (seconds before alerting out-of-control)

Once configured, the node outputs an object like this:

{
    value: 10.020214950604476,      // Current measurement
    avg: 10.089877376434453,         // Running average
    ucl: 10.344067494423967,         // Upper control limit
    lcl: 9.835687258444938,          // Lower control limit
    outOfControl: false              // Alert status
}

Step 4: Make the Data Chart-Ready

Charts need data in a specific format. Add a change node between SPC and your chart.

Drag a change node onto the canvas
Wire it between the SPC node and where your chart will go
Double-click to configure and set one rule: Set msg.payload to this JSONata expression:

[
    {"series": "Measurement", "x": $millis(), "y": payload.value},
    {"series": "UCL", "x": $millis(), "y": payload.ucl},
    {"series": "LCL", "x": $millis(), "y": payload.lcl},
    {"series": "Average", "x": $millis(), "y": payload.avg}
]

This creates four lines on your chart, your actual measurements plus the three control lines.

Step 5: Build Your Control Room Dashboard

Now we'll create the dashboard that displays your SPC control chart. This is what operators will watch to spot problems in real-time.

Drag a chart widget from the dashboard section and set:
- Type: Line Chart
- X-axis: HH:mm:ss (shows time)
- Series: Set to series (as key)
- X: Set to x (as key)
- Y: Set to y (as key)
- Legend: Show
- Label: "SPC Chart: Bearing Diameter (mm)"
Connect the change node to it.
Deploy the flow.

Complete SPC monitoring flow with real-time chart display

Step 6: Add the Alert System

A chart is nice, but you need immediate alerts. Here's the clever bit:

Add a switch node connected to your SPC output
Set it to check msg.payload.outOfControl
Create two outputs: true and false
Now add a text nodes from dashboard. Wire it to your switch outputs.

For the "true" path, set the text to something attention-grabbing using change node: ⚠️ PROCESS OUT OF CONTROL - CHECK MACHINE!

For the "false" path: ✓ Process Stable

Deploy the flow.

Node-RED alert system with switch node: Process stable

Step 7: Test Your SPC System

Open your dashboard (switch to the Dashboard 2.0 tab → click Open Dashboard button on the top-right of the right sidebar).

What you'll see initially:

First 20 measurements: Chart builds up baseline data
After 20 points: Control limits appear automatically
Blue line bouncing between red lines: Process is stable

Let the system run for a minute to establish your baseline. The control limits aren't arbitrary - they're calculated from your actual process data.

Now test it with a simulated process shift:

Double-click the Inject node
Change the formula to $random() * 0.2 + 10.5 (this shifts the mean up by 0.5mm)
Click Done to close the node
Deploy only the modified nodes:
- Click the down arrow next to the Deploy button
- Select Modified Nodes
- Click the Deploy button

Deploy menu with Modified Nodes option for updating only changed nodes

Once done You will see the chart detect the change within seconds.

SPC chart detecting process shift - measurements above UCL trigger immediate alert

SPC Chart Rules That Actually Matter

Control limits catch obvious problems. But subtle issues need pattern recognition. Here are the four rules that catch 95% of real problems:

Rule 1: Any point outside limits This one is fairly obvious: If a measurement point falls outside of the established upper or lower limits, something is wrong.
Rule 2: Seven points on one side Seven consecutive points above or below the center line means your process has shifted. Maybe a new material lot, maybe tool wear.
Rule 3: Seven points trending Seven points in a row going up or down. Classic sign of tool wear or temperature drift.
Rule 4: Repeating and Cyclical Patterns This rule is for recurring behaviors that the other rules miss. Cycles that repeat over time, like a regular pattern that appears at the start of every shift change or every Monday. Speak with your operators, they will likely know what these mean.

Here's how to implement these rules in FlowFuse:

Drag a Function node onto the workspace and add the following JavaScript code to it.
Replace switch node with this Function node.
Deploy the flow.

const buffer = context.get('measurements') || [];
const current = msg.payload;

// Rule 1: Out-of-control point (handled by SPC node)
if (msg.payload.outOfControl) {
    msg.payload = "⚠️ PROCESS OUT OF CONTROL – CHECK MACHINE!";
    return msg;
}

// Store the current measurement
buffer.push({
    value: current.value,
    avg: current.avg,
    timestamp: new Date()
});

// Keep only the last 20 measurements
if (buffer.length > 20) {
    buffer.shift();
}
context.set('measurements', buffer);

// Initialize alert message
let alertMessage = "✓ Process Stable";

// Check rules if we have enough data
if (buffer.length >= 7) {
    const recent = buffer.slice(-7);
    const values = recent.map(r => r.value);

    // Rule 2: Seven points on one side of the center line
    const allAbove = values.every(v => v > current.avg);
    const allBelow = values.every(v => v < current.avg);
    if (allAbove || allBelow) {
        alertMessage = "⚠️ Process shift detected – 7 points on one side of center";
    }

    // Rule 3: Seven points trending up or down
    let trending = true;
    const increasing = values[1] > values[0];
    for (let i = 2; i < values.length; i++) {
        if ((increasing && values[i] <= values[i - 1]) ||
            (!increasing && values[i] >= values[i - 1])) {
            trending = false;
            break;
        }
    }
    if (trending) {
        alertMessage = increasing
            ? "⚠️ Increasing trend – check for tool wear"
            : "⚠️ Decreasing trend – check material quality";
    }
}

msg.payload = alertMessage;
return msg;

The following image demonstrates the advanced alerting system in action, detecting specific patterns beyond simple control limit violations:

Real-time SPC monitoring detecting process drift and triggering appropriate alerts based on trend analysis

Connecting to Real Equipment

Time to connect your actual machines. The approach depends on what equipment you have.

For modern PLCs - anything from the last decade like Siemens S7-1200/1500, Allen-Bradley ControlLogix, or Omron NX - you'll use OPC UA. It's already built into these PLCs. Enable it in the configuration, install node-red-contrib-opcua from the FlowFuse palette, and point it at your PLC. The endpoint looks like opc.tcp://192.168.1.100:4840. Browse for your measurement tags and connect them to your SPC flow. Full OPC UA guide here.

Older equipment speaks Modbus TCP. Check your manual's appendix for the register map. Install node-red-contrib-modbus, configure it with your device's IP address and the register holding your measurement (like 40001 for holding registers). Almost every industrial device from the last 30 years supports this. Modbus tutorial here.

For everything else, get creative. Old gauges with RS-232 ports work fine with a USB adapter and the serial node - see our serial port guide. Machines that dump CSV files can be monitored with the watch node. Manual measurements need just a simple dashboard form, one input field, one submit button. Don't overcomplicate it.

Before connecting to SPC, always test with inject → protocol node → debug to make sure data flows. Once you see measurements in the debug panel, wire it to your SPC node and you're monitoring real processes.

The Money You're Leaving on the Table

Remember that manufacturer from the forum processing 400,000 parts annually with a 4% scrap rate? That's 16,000 parts straight to the trash. At just $10 per part, that's $160,000 in annual waste. Cut that rate to 2% with SPC and you save $80,000 yearly.

But here's what most people miss - the $10 part cost is just the beginning. Consider what every defective part also burned through:

Machine time: Say 3 minutes at $200/hour = another $10 gone
Labor: About 15 minutes handling the defect at $30/hour = $7.50 more
Materials: The raw stock you'll never get back

That "$10 part" actually cost you around $27.50 to scrap. Those 16,000 defects? Try $440,000 in real losses.

SPC attacks all of this simultaneously. When your process stays in control, you're not just saving parts - you're saving machine capacity, labor hours, and materials. Plus stable processes need less inspection, letting you redeploy quality staff to improvement projects instead of firefighting.

Quick ROI calculation: Take your annual defect count, multiply by your true cost per defect (part + machine + labor), then multiply by 0.5 for a conservative estimate. That's your yearly savings potential with SPC. Most manufacturers see payback in under 3 months.

SPC works. It's not magic, it's not complicated, and it doesn't have to be expensive. It's just math applied to manufacturing data in real-time.

The tools exist. Node-RED gets you started, but FlowFuse keeps you running in production. With built-in high availability, your SPC charts stay live even if a server fails. Multiple engineers can work on the same flows without conflicts. Deploy updates to 50 production lines with one click. When downtime costs thousands per hour, you need a platform built for manufacturing.

Start Preventing Defects Today

Every day without SPC is money left on the table. Those 16,000 scrapped parts per year? The warranty claims from undetected drift? All preventable.

Here's your path to production-ready SPC:

Start Free with FlowFuse - Get your instance running in minutes
Follow this tutorial - Build your first SPC chart today
Connect one machine - Start with your most critical measurement
Expand gradually - Add more parameters as you prove value

Don't wait for the perfect plan. Don't form another committee. Pick one measurement that matters and start monitoring it today. Need help getting started? Book a demo to discuss your specific requirements or contact our team for enterprise deployment guidance.

Because somewhere right now, one of your machines is drifting out of spec. The only question is whether you'll catch it in time.

Build Your First SPC Dashboard Now →

References

Six Sigma Online - Statistical Process Control - Background on manufacturers saving thousands with quality control methods
Practical Machinist Forum - Scrap Rates Discussion - Real manufacturer example: 400,000 parts/year with 4% scrap rate
ServiceChannel - Industry Scrap Rate Report - Industry data confirming 4-5% scrap rates are standard
NIST Engineering Statistics Handbook - Statistical Process Control - Official definition and explanation of SPC principles
Walter Shewhart - Wikipedia - SPC creator at Bell Labs in the 1920s

OPC UA Tutorial: Connect and Exchange Data with Industrial Equipment

2025-07-16T00:00:00Z

If you’ve ever tried to connect industrial equipment from different vendors, you know how frustrating it can be, a mess of incompatible protocols, proprietary software, and confusing drivers. Your Siemens PLC speaks one language, your Allen-Bradley controller another, and that Modbus sensor? Yet another protocol entirely.

OPC UA changes that.

OPC UA (Open Platform Communications Unified Architecture) is the industry-standard protocol that eliminates this chaos. Also known as OPC Unified Architecture or IEC 62541, it provides a universal language for secure communication between PLCs, SCADA systems, HMIs, and enterprise applications ,regardless of the manufacturer.

This hands-on guide walks you through building your first OPC UA integration using Node-RED and FlowFuse:

Connect to any OPC UA server—Kepware, MatrikonOPC, or built-in PLC servers
Browse available tags and discover Node IDs from your equipment
Read real-time values from PLCs, sensors, and industrial devices
Write control signals and setpoints back to your systems

Why OPC UA?

If you have worked with industrial equipment, you know the pain. Every PLC vendor uses a different protocol. Your Siemens S7-1500 requires TIA Portal and PROFINET drivers. The Allen-Bradley ControlLogix needs RSLinx and EtherNet/IP. A Modbus temperature sensor needs yet another tool. Before long, you are juggling a dozen different software packages—each with its own licensing, training, and maintenance overhead.

Breaking the Cycle

OPC UA eliminates this fragmentation. Instead of relying on vendor-specific protocols, it provides a universal language for all your equipment. Here is why it is becoming the industry standard:

Universal Connectivity

Connect to any modern PLC using a single protocol. Leading manufacturers like Siemens, Rockwell, Schneider, and ABB now embed OPC UA servers directly into their controllers. One client, all your equipment.

Information, Not Just Data

Reading a temperature value from OPC UA does not just give you "42.5"—it gives the full context: 42.5 °C, measured at 14:32:15.625 with "Good" quality, from "Tank_01/Temperature", and includes alarm limits (10 °C / 80 °C). This context reduces guesswork and helps prevent costly mistakes.

Security Built for Industry

While protocols like Modbus transmit everything in plain text, OPC UA uses enterprise-grade security. It supports X.509 certificates, 256-bit encryption, and robust user authentication to safeguard critical infrastructure from cyber threats.

Future-Proof Investment

OPC UA is the foundation of Industry 4.0 initiatives around the world. It is not just another protocol—it is the one major vendors are standardizing on. Choosing OPC UA today ensures long-term compatibility and ROI.

Getting Started

Now that you understand why OPC UA is widely adopted, let’s explore how to implement it using FlowFuse Node-RED.

This next section walks you through exactly what you need to get started with a working setup, whether for prototyping or production.

What You’ll Need

Before diving into the flow-building process, make sure you have the following:

An OPC UA server (like Kepware, MatrikonOPC, or built into your PLC)
A FlowFuse Node-RED instance running on your edge device.

For production OPC UA deployments, we recommend using FlowFuse. When connecting to industrial systems, you need more than just Node-RED—you need team collaboration so multiple engineers can work on flows safely, audit logs for compliance tracking, high availability to prevent downtime, and remote device management for edge deployments.

FlowFuse provides these enterprise features plus automatic backups, one-click rollbacks, environment variables for different sites, and DevOps pipelines for testing changes before they reach production.

Get started →

Installing OPC UA Support in FlowFuse

To work with OPC UA in FlowFuse Node-RED, you will first need to install the required nodes.

Install the OPC UA Node Package

Open the FlowFuse Node-RED editor.
Click the menu in the top-right and choose Manage palette.
Navigate to the Install tab and search for node-red-contrib-opcua.
Click Install.

Once installed, you will find new nodes for OPC UA communication in your palette, including Client, Item, and Browser and other OPC UA nodes.

Connecting to Your OPC UA Server

To begin accessing industrial data, create a client connection using the OPC UA Client node.

Drag an OPC UA Client node onto the canvas.
Double-click to configure it.
Click the + icon to create a new endpoint configuration.
Enter your OPC UA server address, for example: opc.tcp://192.168.0.10:4840
Set the security mode to None (you can add security later).

Security Note: This tutorial uses "None" for the security setting to keep things simple. In production environments, always use appropriate security—typically "Sign & Encrypt" with certificates.

Click Add, then Done.

OPC UA endpoint configuration

With the connection now defined, you’re ready to explore what tags are available.

Browsing Tags (Optional)

If you do not already know the Node IDs of the tags you want to access, use the OPC UA Browser node to explore the tag structure.

Drag an Inject, OPC UA Browser, and Debug node onto the canvas.
Connect the output of the Inject node to the input of the Browser node, then connect the Browser's output to the Debug node.
In the Browser node, set the topic to ns=0;i=85 (the root Objects folder).
Configure the Inject node to send a timestamp.
Deploy the flow and click the Inject node.

Tag information will be printed to the debug sidebar. You can now identify the exact Node IDs to use in your reads or writes.

OPC UA Browser node

Reading Tag Values

Once you know the Node IDs, you can start reading data from your industrial equipment through the OPC UA server.

Reading a Single Tag

Here’s how to read a single value in real time:

Drag an Inject node onto the canvas (this will trigger the read operation).
Add an OPC UA Item node and configure:
- Node ID: Enter the tag’s identifier (e.g., ns=3;i=1003)
- Data Type: Select the appropriate type (e.g., Boolean)
Connect the output of the Inject node to the input of the Item node.
Add an OPC UA Client node and set its Action to read.
Select the endpoint configuration you created earlier.
Connect the output of the Item node to the input of the Client node, then connect the Client node's top output to a Debug node.

The OPC UA Client node has three outputs: the top carries the data payload, the middle indicates connection status, and the bottom provides raw responses for debugging.

Deploy the flow and click the Inject button to trigger the read.

You should see the tag value appear in the debug panel. This confirms that communication is working correctly.

You can also pass the Node ID dynamically using msg.topic from the Inject node if you prefer not to use an Item node.

Reading Multiple Tags

Batch reading improves performance when you need multiple data points from your equipment

Drag an OPC UA Client node and set its Action to "READ MULTIPLE".

Screenshot showing OPC UA Client node with "READ MULTIPLE" action selected

Select the endpoint configuration.
Add an OPC UA Item node for each tag you want to read.
Add an Inject node for each Item node to trigger it.
Connect each Inject node to its corresponding Item node.
Wire all Item nodes into the OPC UA Client node.
Add a Debug node to the top output of the Client node.
Deploy the flow.
Click each Inject node once, the client node will store the tag definitions.
Send a message with msg.topic = "readmultiple" to trigger the actual read.
To clear stored items, send msg.topic = "clearitems".

You now have a flexible setup for reading multiple values from your PLC on demand.

Writing Values

In addition to reading data, OPC UA also allows you to write control signals or parameters to your equipment.

Writing a Single Tag

To write a single value:

Drag an Inject node onto the canvas (used to trigger the write operation).
Add an OPC UA Item node and configure:
- Node ID: Enter the target identifier.
- Data Type: Choose the appropriate type (e.g., Boolean, Double).
- Value: Enter the value to write.
OPC UA Item node configured for a write operation
Connect the Inject node to the Item node.
Add an OPC UA Client node and set its Action to WRITE.

OPC UA Client node with "WRITE" action selected
Select the endpoint configuration you created earlier.
Connect the Item node to the Client node, then connect the Client node's top output to a Debug node.
Deploy the flow and click the Inject button to trigger the write.

The OPC UA Client node will confirm the operation with a status like "values written".

Writing Multiple Tags

To write multiple values at once, follow this pattern:

Add an OPC UA Client node and set its Action to WRITE MULTIPLE.

OPC UA Client node configured for writing multiple values
Select the appropriate endpoint configuration.
Add multiple OPC UA Item nodes, each configured with a Node ID, Data Type, and Value to be written.
Add an Inject node for each Item node.
Connect each Inject node to its corresponding Item node, then connect all Item nodes to the Client node.
Add a Debug node to the top output of the Client node.
Deploy the flow and trigger all Inject nodes to load the values.
To execute the write operation, send a message with msg.topic = "writemultiple".
To clear the stored items, send a message with msg.topic = "clearitems".

This setup allows you to prepare multiple tag values and write them all at once, giving you precise control through a single command.

What’s Next

You’ve now mastered the fundamentals of OPC UA integration—connecting to servers, browsing tags, and reading or writing data. These core building blocks lay the foundation for powerful industrial automation.

In real deployments, you will want more than Inject nodes and debug panels. With FlowFuse Dashboard 2.0, you can build full operator interfaces—live gauges, control buttons, trend charts—fully connected to your OPC UA data.

This guide covered the basics, but OPC UA offers far more. In the next article, we will explore:

Subscriptions for real-time monitoring without polling
Events and alarms directly from equipment
Historical data queries for trend analysis
Method calls to execute functions on your devices

When it is time to move beyond prototypes, FlowFuse delivers what industrial systems truly need—remote device management, instant rollbacks with full version control, built-in team collaboration, and high availability you can trust.

If you’re ready to simplify your OPC UA integration and scale industrial workflows with Node-RED, start your free trial of FlowFuse today.

Node-RED Serial Port Tutorial: Connect RS232/RS485 Manufacturing Equipment

2025-07-09T00:00:00Z

Many factories rely on machines, both new and old, that communicate via traditional serial interfaces such as RS-232, RS-422, or RS-485. These machines remain reliable but can be challenging to integrate with modern systems due to their connectivity style.

This guide shows you how to use FlowFuse (Node-RED with enterprise capabilities) to connect manufacturing equipment, collect data, and enable real-time monitoring—without modifying your original hardware.

Making Sense of Serial Communication

Before diving into the wiring and flow configuration, it helps to understand how serial communication works—and why it is still relevant in industrial settings.

Serial ports move data one bit at a time, like passing beads on a string. This may sound old-fashioned, but it remains one of the most reliable and predictable ways to connect machines.

Data Direction: Which Way Does It Flow?

Not all serial connections behave the same. The direction of data flow is defined by its duplex mode:

Simplex: One-way only. Like a speaker giving a lecture—the machine talks, you just listen. This is common for devices like weight scales or scanners that only output data.
Half-Duplex: Data can flow in both directions, but only one side can transmit at a time. This is like using a walkie-talkie. It is the most common operational mode for RS-485 (using two wires), where multiple devices share the same communication line.
Full-Duplex: Two-way, simultaneous communication. This is like a phone call—both sides can talk and listen at once. This is the typical mode for RS-232 (using separate transmit and receive lines) and RS-422, which is designed for full-duplex, multi-drop scenarios (one sender, multiple listeners).

Across industrial environments, serial interfaces like RS-232, RS-422, and RS-485 remain prevalent for device communication, depending on the wiring and number of connected devices.

Data Format: How Is It Structured?

Machines are picky—they expect data to arrive in a specific format. Here are the key pieces that make up a serial data frame:

Setting	What It Means
Baud Rate	Speed of transmission (e.g., 9600 or 115200)
Data Bits	The actual data, usually 7 or 8 bits
Parity	Optional error check—even, odd, or none
Stop Bits	Marks the end of each message

Interface Types: How Devices Physically Connect

Different machines use different physical standards. The most common are:

RS-232: Typically full-duplex and one-to-one. Good for short-distance device communication.
RS-422: Full-duplex, multi-drop (one sender, multiple receivers). Used for longer distances than RS-232.
RS-485: Typically half-duplex and multi-device. Ideal for networks and even longer cable runs.
USB (via adapter): Most modern PCs and gateways use USB-to-Serial adapters to talk to RS-232/422/485 devices.

Setting Up Serial Communication with FlowFuse

Now that you understand how serial communication works and what kind of interfaces your machine might use, the next step is to put that knowledge into practice.

Using FlowFuse, you can easily establish serial communication, process the data, and integrate it into dashboards or automated workflows, all without modifying the original hardware.

Let's walk through how to set this up.

Prerequisites

Before we start, ensure the following prerequisites are met:

Hardware Connection: The machine must be physically connected to your system using a serial interface.
Node-RED Instance: Make sure you have an instance of Node-RED up and running. The quickest way to do this is via FlowFuse. If you don't have an account, check out our free trial.
Serialport Node: Install the node-red-node-serialport package if it is not already available in your palette.

Configuring the Serial Port Node

After installing the node-red-node-serialport package, follow these steps to configure serial communication in your Node-RED flow:

Drag a Serial In node from the Node-RED palette onto the canvas.
Double-click the node to open the configuration dialog.
Click the pencil icon next to the Serial Port field to add a new port configuration.
Enter the serial port path (e.g., /dev/ttyUSB0 on Linux or COM3 on Windows). You can also click the search option to list available ports.

Screenshot of Node-RED serial port node configuration showing available serial ports after clicking the search option.

Set the baud rate, data bits, stop bits, and parity according to your machine’s specifications. These values must match the device exactly, or communication will fail or result in corrupted data.
Optionally, define an input delimiter, such as \n or \r, to segment incoming messages if your device sends data in lines or chunks. If the output is fixed-length, you can configure it to wait for a specific number of characters. You can also set a timeout to receive data at regular intervals. Later in the output section, you can choose to add characters back to the message, such as restoring the line break.

Screenshot of input and output settings in the Node-RED serial port node, showing options like delimiter, character count, and timeout.
Click Done to save the configuration.

Once the serial port is correctly configured and the device is connected, the serial in node will show a "connected" status below the node with a small green square.

Screenshot of the Serial In node in Node-RED showing a green square that indicates a successful connection to the serial port.

Writing to Serial Port

To send data to a machine, use the serial out node in Node-RED. This is often necessary to trigger actions such as starting a process, requesting a reading, or changing an internal state.

Follow these steps to send a command:

Drag an inject node onto the canvas.
Set the payload type appropriate to your machine’s requirements. This could be a string, number, raw buffer, or JSON object.
Add a serial out node and select the configured serial port.
Connect the inject node to the serial out node.

Once deployed, clicking the inject button will send the specified data to the machine via the serial interface.

In this guide, we are using a real machine connected via a serial interface. The machine is programmed to simulate a production process when it receives the "START" command (sent as a string). Once triggered, it begins incrementing the count of good and defect products and sends this data back over the same serial connection.

The next section demonstrates how to read and process this simulated production data using the serial in node.

Reading and Processing Serial Data

Follow these steps to read and handle the serial data:

Drag a serial in node onto the canvas and configure it to use the same serial port.
Add a debug node and connect it to the output of the serial in node. This helps you inspect the raw payload and confirm that data is being received correctly.
Once you confirm the format of the incoming data, use any of the change, JSON, or function node to parse and convert it into a structured format, here we have used function.

In our case, the machine sends production data every 2 seconds in the following format:

Screenshot of Node-RED debug panel showing production data sent from the machine every 2 seconds.

To convert this string into a structured JSON object, you can use a function node with the following code:

let parts = msg.payload.trim().split(' ');
let result = {};

parts.forEach(part => {
    let [key, value] = part.split(':');
    result[key.trim()] = parseInt(value);
});

msg.payload = result;
return msg;

This transforms the string into a JSON object like:

{
  "GOOD": 214,
  "DEFECT": 22
}

Tip: You do not need to know JavaScript to use the function node. If you are using FlowFuse, the built-in FlowFuse Assistant can help you write function code using natural language. Simply provide a sample of the data received from your machine and describe the output you expect — the Assistant will generate the function for you.

Handling Request-Response Serial Communication

Not all machines stream data continuously. Some expect a request command, and only then respond with data. In these cases, using a combination of inject, serial out, and serial in nodes can become tricky—especially if you need to match each request with exactly one response. That’s where the serial request node becomes useful.

The serial request node handles this entire pattern for you. Internally, it combines the logic of sending a message and waiting for a single reply, working in a first-in, first-out manner. This means it will only send the next request after receiving a response (or timeout) for the previous one, making it ideal for synchronous devices.

To use it:

Drag a serial request node from the palette.
Double-click to configure the port—use the same path and settings as your other serial nodes.
Connect it to an inject node configured with the command your machine expects, such as "READ" or "STATUS".
On the output side, connect a debug or function node to handle the response.

Each time you trigger the inject, the command will be sent over the serial port, and the response will be delivered to the output—ready to be parsed just like before. This approach is clean, predictable, and removes the guesswork from matching writes with reads.

The output message includes msg.payload containing the response (if any), msg.status with the result status, and msg.port for reference.

This node is especially useful for polling machines that respond with production counts, part IDs, temperature readings, or system status—but only when asked.

Dynamically Managing Serial Ports

In a perfect setup, the serial device is connected, the port is stable, and everything just works. But in practice, hardware is not always so predictable.

For example, You might disconnect and reconnect a USB-to-serial adapter—and now the device shows up as /dev/ttyUSB1 instead of /dev/ttyUSB0. Or maybe you need to temporarily release the serial port to flash new firmware onto an Arduino. In some environments, the port assignment could change on every reboot, making it difficult to hardcode anything.

Rather than redeploying or editing your flow every time, Node-RED gives you a more flexible option: the serial control node.

This node lets your flow adjust serial communication settings on the fly. You can:

Stop the serial connection when needed.
Start it again later.
Even switch to a different port entirely—without touching the Node-RED editor.

All of this happens by sending a simple message to the control node.

To stop communication:

{ "enabled": false }

To start it again:

{ "enabled": true }

And if the port changes or needs reconfiguration, you can send everything in one message:

{
  "serialport": "/dev/ttyUSB1",
  "serialbaud": 9600,
  "databits": 8,
  "parity": "none",
  "stopbits": 1,
  "enabled": true
}

This is especially useful when your flow needs to recover automatically—for example, after a USB reconnection—or if you want to let a user select the correct port from a dashboard interface.

Each time a message is received, the node also outputs the current port configuration. This allows you to log or verify changes as part of your flow—making it easy to track what the system is doing behind the scenes.

In short, the serial control node adds a layer of resilience and flexibility that is often essential in real-world deployments—where devices come and go, ports are never quite consistent, and downtime is not an option.

Key Takeaways

Manufacturing floors often bring together a mix of old and new machines. Among them, many still operate on traditional communication methods that are reliable but difficult to integrate with modern systems. These machines continue to perform their core functions well, but without connectivity, they remain isolated from digital workflows.

With FlowFuse and Node-RED, you can bridge that gap—bringing equipment online without changing or replacing existing hardware. From data collection to triggering actions and monitoring performance, your machines can become part of a connected and intelligent system.

Whether you’re in textiles, precision engineering, or automotive manufacturing, FlowFuse helps you unlock the full potential of your existing equipment. No rip-and-replace needed—just smarter connections. Get in touch with us and start building your serial integration flow today.

How we Built a Smart Manufacturing Order Execution Panel with FlowFuse

2025-07-03T00:00:00Z

A few days ago, I had a conversation with a solution architect about how the lack of integration between the shop floor and business systems often leads to missed opportunities and financial losses. He also mentioned that while many manufacturers want to bridge this gap, they often hesitate — mostly due to concerns about complexity of integration or fear of disrupting existing operations.

But there is no need to be afraid. In this blog, I will walk you through a simple demo that shows how easy it can be to connect production systems with your ERP. With just a small integration, you can improve visibility, avoid manual errors, and prevent unnecessary losses.

To demonstrate this, I built a smart Manufacturing Order (MO) execution panel using FlowFuse, connected to ERP.

Let’s take a closer look.

Demo: Smart Manufacturing Order Execution Panel in Action

In this demonstration, an operator starts by selecting a Manufacturing Order (MO) from a list pulled directly from Odoo ERP. The system immediately checks if enough raw materials are available for that specific order.

If the materials are ready, production begins, and the MO status in Odoo is automatically updated to In Progress. The system then tracks the production count in real time. However, if materials are missing, production won’t start, and the operator is notified instantly. Once the produced quantity matches the target, the system automatically stops the line and marks the MO as Done in Odoo, completing the cycle without manual intervention.

How It Works: Behind the Scenes

To build this system, I used FlowFuse to create a Node-RED flow that connects to Odoo ERP and controls a simulated production line.

System Components

Odoo ERP
Holds Manufacturing Orders, product details, and inventory data. This integration allows for a two-way conversation between the shop floor and the business's core planning system. For a detailed guide on how to read from and write to Odoo, you can read our article, Connect Your Shop Floor to Your ERP – Odoo Edition
FlowFuse
Executes logic such as fetching manufacturing orders, checking material availability, updating statuses, controlling production, and building the operator interface.
Simulated Production Line (Factory I/O)
Acts as the shop floor. Starts and stops production based on FlowFuse commands.
PLC
Receives commands from FlowFuse and controls the actual machinery or simulated production environment.
S7 Protocol (S7Comm)
This is the protocol used to communicate with Siemens S7 series PLCs. We use Node-RED nodes within FlowFuse to send control commands (e.g., start/stop production) and read critical data (e.g., produced quantity, machine status) directly from the PLC’s memory blocks. To learn exactly how to set this up, check out our step-by-step tutorial, Getting Started: Integrating Siemens S7 PLCs with Node-RED

Below is the full Node-RED flow that powers this smart manufacturing execution panel.

Workflow Breakdown

sequenceDiagram
    participant Operator
    participant FlowFuse
    participant Odoo
    participant PLC
    Operator->>FlowFuse: Select MO
    FlowFuse->>Odoo: Fetch MO details
    Odoo-->>FlowFuse: Return MO + Material info
    alt Materials Available
        FlowFuse->>Odoo: Update MO to "In Progress"
        FlowFuse->>PLC: Start production
        loop While producing
            PLC-->>FlowFuse: Report produced quantity
        end
        FlowFuse->>PLC: Stop production
        FlowFuse->>Odoo: Update MO to "Done"
    else Materials Not Available
        FlowFuse-->>Operator: Notify: Cannot start
    end

Fetch Manufacturing Orders
The system pulls a list of confirmed or in progress MOs from Odoo using HTTP requests with help of Odoo node.
Check Raw Material Availability
When an operator selects an MO, FlowFuse checks if enough raw materials are available in Odoo.
Start Production
If materials are available:
- The MO status is updated to In Progress
- The simulated line starts producing
Track Quantity in Real Time
As the line runs, FlowFuse keeps track of the produced quantity.
Stop and Complete the MO
When the produced quantity matches the MO target:
- FlowFuse sends a stop command to the PLC
- The MO status in Odoo is updated to Done

Why This Matters for Business

This demo might seem simple, but it solves some of the most common and expensive problems on the shop floor. Think about the daily headaches: an operator starts a big job, only to find out halfway through that a key material is missing, forcing the entire line to stop. Or, they produce 10% more than the order required, creating waste that just sits in inventory.

This smart panel is designed to prevent those exact scenarios. By connecting your production line directly to your business systems, it:

Prevents material shortages by automatically checking for raw materials before a job can even start.
Eliminates overproduction by stopping the line the moment the target quantity is hit.
Gets rid of manual data entry by instantly updating the order status in the ERP.

This means managers get a live, accurate view of what’s happening on the floor, not data from hours ago. The best part is that you don't need to overhaul your entire operation or buy a huge, complex system to get these benefits. A smart, focused integration like this can deliver real results, quickly.

Ready to Connect Your Shop Floor?

This demo shows how even a small, targeted integration between your production line and ERP can eliminate manual errors, reduce waste, and improve visibility — without overhauling your entire system.

If you are exploring how to bring these kinds of improvements to your manufacturing operations, let’s talk.

We’d be happy to discuss how FlowFuse can help you build custom, scalable solutions tailored to your factory’s needs.

👉 Get in touch with us

FlowFuse 2.19: More Powerful AI in Node-RED, Drop-In Blueprints, Memory Monitoring, and Faster Onboarding

2025-07-03T00:00:00Z

This release focuses on speeding time to value with more powerful AI functionality within Node-RED, along with reducing friction for new users while enhancing the experience for existing users through improved Blueprint functionality, comprehensive performance monitoring, and a modernized interface that reflects FlowFuse's evolution.

AI Enhancements to Node-RED

GIF of AI Flow Explainer

The FlowFuse Expert can now do more than create a Function node based on your text instructions. With this release, you can highlight a flow in the Node-RED editor and ask the FlowFuse Expert to explain the purpose of the flow. This new functionality is perfect for learning and collaboration.

You can also use the FlowFuse Expert to create Dashboard templates with HTML, VUE, Vuetify, and CSS, allowing you to build even faster.

Stay tuned for more developments as we continue to add enhancements to the Node-RED editor in FlowFuse to enable even faster development.

Comprehensive Performance Monitoring

Screenshot of Memory Monitoring Building on our existing CPU monitoring capabilities, we've added memory usage tracking to the Performance feature. This enhancement provides:

Complete visibility into both CPU and memory utilization
Better understanding of instance resource consumption
More informed decision-making for scaling and optimization

With these features, you can now get a holistic view of your instance performance and make informed decisions about resource allocation.

Add Blueprints to Existing Instances

Screenshot of Blueprint Import

Previously, Blueprints could only be used when creating new instances. Now you can import Blueprints into existing instances, making them much more versatile. Blueprints now appear as an option in the Import menu.

And if you're running Node-RED version 4.1, when you select a Blueprint to import that uses nodes not in your current palette, it will offer to install them automatically.

This change transforms Blueprints from a one-time instance creation tool into a constantly useful resource to speed your development with Node-RED.

Screenshot of Google Signin

To make it easier than ever to create a FlowFuse account, we've introduced social sign-in options that allow users to create FlowFuse Cloud accounts using their Google credentials.

This enhancement removes multiple steps from the onboarding process, making it significantly easier for new users to get started with FlowFuse.

Enhanced Device Agent Flow Selection

Connecting your existing Node-RED instances running on remote devices is now even easier with the new Device Agent terminal file browser. When installing the Device Agent, you can now easily navigate your file system and select existing Node-RED instances through an interactive interface directly in the terminal.

This improvement replaces the previous manual file path entry process with:

An intuitive file browser that works directly in your terminal
Easy navigation through your file system to locate flows
Contextual information about flows including file size and modification dates
A streamlined selection process that reduces setup friction

Modernized User Interface

Screenshot of Homepage

The FlowFuse user interface was due for a restructuring in light of what users are looking for, along with a visual touchup. This release introduces a dedicated landing page that focuses on what we've learned users want to do when they first access FlowFuse. The new homepage provides:

Direct access to relevant hosted and remote instances
Smart prioritization based on recent activity and deployments
Prominent display of issues requiring attention (performance alerts, errors)
Recent team activity overview through audit log integration
Improved layout and visual hierarchy
Updated color scheme and styling

These changes make it easier to find what you are looking for within FlowFuse, address issues that may arise, and creates a more pleasant workspace.

What's Next?

Our development team continues to focus on AI integration and workflow optimization. The upcoming releases will build on these foundational improvements while introducing more intelligent automation and development assistance features.

We're also working on expanding our Blueprint library and improving the overall development experience within the Node-RED editor, with several exciting features planned for the coming months.

What else is new?

For a complete list of everything included in our 2.19 release, check out the release notes.

Which of these new features are you most excited to try? Email me directly at greg@flowfuse.com - I'd love to hear from you!

Try FlowFuse

FlowFuse Cloud

The quickest way to get started is with FlowFuse Cloud.

Get started for free and have your Node-RED instances running in the cloud within minutes.

Self-Hosted

Get FlowFuse running locally in under 30 minutes using Docker or Kubernetes.

Curated Node-RED Integrations: FlowFuse Certified Nodes 2.0

2025-07-01T00:00:00Z

At FlowFuse, we believe that enterprises deserve access to the best of Node-REDs custom nodes and solutions crafted by recognized experts who bring deep domain knowledge and professional standards to their work. That's why we are thrilled to announce a significant evolution of our ecosystem: FlowFuse Certified Nodes v2.0.

From Community Contribution to Professional Partnership

The Node-RED community has always had a pasionate and thrived on the domain-expertise of its developers. The community has created an environment of innovation, and now we're taking the next step to support enterprise-grade solutions that companies are building on Node-RED today.

Our new Certified Nodes program we hope to elevate the community. We are establishing a professional partnership with the most skilled node developers and domain experts in the community.

Here’s how it works:

Expertise Recognition: FlowFuse partners with developers who have demonstrated deep expertise in their domains, and may have already published nodes in their area of expertise. Ensuring our enterprise customers access the most knowledgeable contributors in each field.
Quality-Driven Selection: Our certification process identifies nodes that excel in real-world environments, focusing on reliability, security, up-to-date documentation and professional implementation standards.
Comprehensive Solutions: We welcome both open-source innovations and proprietary solutions. This approach allows experts to share their knowledge broadly while also providing targeted solutions for specific industry needs.

What Does It Take to Become a Certified Publisher?

We are seeking partners who represent the pinnacle of expertise in their respective domains. To join our certified ecosystem, we look for developers who demonstrate:

Domain Expertise: Deep knowledge and proven experience in the specific technology or industry vertical their nodes address
Professional Standards: Commitment to enterprise-grade code quality, comprehensive testing, and security best practices
Continuous Innovation: Ongoing development and enhancement of features that solve real-world enterprise challenges
Expert Support: Ability to provide advanced technical support and guidance that goes beyond basic troubleshooting

Our certification process ensures that every node in the certified nodes ecosystem meets these exacting standards. When enterprises choose certified nodes, they gain access not just to code, but to the expertise and ongoing support of recognized industry professionals. This creates a sustainable model where expert knowledge is properly valued and enterprises receive the reliability they require.

Why Partner with FlowFuse?

Joining the FlowFuse Certified Nodes v2.0 program means becoming part of an elite community of experts. Moreover, there's now a financial reward for doing so. FlowFuse commits a fixed percentage of our FlowFuse Enterprise Platform Fee to be distributed quarterly to the node authors.

If you are an expert developer or organization that has built exceptional Node-RED nodes and are committed to maintaining the highest professional standards, we want to collaborate with you. Let's work together to create a more sustainable, professional ecosystem that connects enterprise users with the industry's leading experts.

Contact us to discuss your node certification

Part 2: Building an Andon Task Manager with FlowFuse

2025-06-26T00:00:00Z

In Part 1, we introduced the concept of an Andon Task Manager—designed to streamline issue reporting and resolution on the factory floor—and outlined the system’s key features, user roles, and dashboard layout.

In this part 2, we move from planning to implementation. The focus now shifts to building the actual system using FlowFuse Dashboard (Node-RED Dashboard 2.0), hosted on the FlowFuse platform. We will begin by developing the Lines view for regular users, along with a line selection menu. The Department View and Admin interface will follow in a later part of the series.

Getting Started

To simplify the development process, the implementation is divided into the following key sections:

Initialize SQLite Database
Seed Demo Data: Departments & Lines
Build Line Selection Menu
Enable URL-Based Dashboard Access
Create Live Request Fetch Flow (Per Line)
Render Request Data in a Table
Setting Up Visual Alerts and Timestamp Formatting
Highlight Requests with CSS & Add Buttons to Update Request Status
Create New Request Submission Flow

Before proceeding, a basic understanding of Node-RED is recommended. If you are new to Node-RED, consider going through this free Node-RED Fundamentals Course to get started.

Tip: Organize your flows into clearly defined groups. For reference, images of each flow are provided. Please use the exact names given to each flow—this will help ensure consistency and make it easier to navigate back to specific flows when referenced later.

Prerequisites

Before you begin building the Andon Task Manager with FlowFuse, make sure you have the following:

Running FlowFuse Instance: Make sure you have a FlowFuse instance set up and running. If you don't have an account, check out the free trial and learn how to create an instance.
@flowfuse/node-red-dashboard: Ensure you have FlowFuse Dashboard (also known as Node-RED Dashboard 2.0 in the community) installed.
SQLite Contrib Node: Install node-red-contrib-sqlite to handle local data storage.
FlowFuse Multi-user Andon: Install @flowfuse/node-red-dashboard-2-user-addon to enable multi-user support.
Enable FlowFuse User Authentication: Enable FlowFuse User Authentication on your FlowFuse instance.
Moment Contrib Node: Install node-red-contrib-moment for date and time formatting.

Initialize SQLite Database

The first step is to set up a database to store requests and their updates.

Drag an Inject node onto the canvas and configure it to trigger on Deploy, after a delay of 0.1 seconds.
Drag an SQLite node onto the canvas. Double-click and click the + icon to add a new database configuration.
Give the database a name and set the mode to Read-Write-Create. Click Add to save.

Set SQL Query to Fixed statement and enter:

CREATE TABLE IF NOT EXISTS requests (
  rowid INTEGER PRIMARY KEY,
  line TEXT NOT NULL,
  support TEXT NOT NULL,
  requested TEXT NOT NULL,
  acknowledged TEXT,
  resolved TEXT,
  notes TEXT
);

Connect the Inject node to the SQLite node.
Click Deploy.

Flow to initialize the SQLite database and create the requests table.

Once deployed, this will create the SQLite database and requests table if it does not already exist.

Seed Demo Data: Departments & Lines

As discussed in the planning section, only the admin role will have the ability to add new departments and lines. Since the admin feature is not yet available, we will populate demo data using a predefined flow to allow ourself to test the application while the standard user interface is being developed.

Import the provided demo flow.
Deploy the flow.

This will store demo lines and departments in the global context as global.lines if not already present.

Now, let us create a new page and menu item for Production Lines. This page will list all currently available production lines, making it easier to navigate through them.

Drag a ui-event node onto the canvas to detect page navigation.
Drag a change node and configure it to:
- Set msg.payload.lines to global.get("lines")
Drag a ui-template node onto the canvas. Create a new page with name “Line Menu” and a group.
Paste the following into the template:

<template>
  <v-container>
    <v-row>
      <v-col>
        <h3>Production Lines</h3>
      </v-col>
    </v-row>

    <v-row class="scrollable-row" no-gutters>
      <v-col v-for="(btn, index) in lines" :key="index" cols="auto">
        <v-btn :href="`/dashboard/lines?line=${btn.value}`" class="custom-btn" rounded>
          
        </v-btn>
      </v-col>
    </v-row>

    <v-alert v-if="selectedLine" type="success" class="mt-3">
      Selected Line: 
    </v-alert>
  </v-container>
</template>

<script>
export default {
  data() {
    return {
      selectedLine: '',
      lines: []
    };
  },
  methods: {
    updateButtonContent(data) {
      this.lines = (data.lines || []).sort((a, b) => a.label.localeCompare(b.label));
    }
  },
  mounted() {
    this.lines = [];
    this.$socket.on('msg-input:' + this.id, (msg) => {
      this.updateButtonContent(msg.payload);
    });
  }
};
</script>

<style scoped>
.scrollable-row {
  display: flex;
  overflow-x: auto;
  padding: 10px 0;
  flex-wrap: wrap;
}
.scrollable-row .v-col {
  flex-shrink: 0;
  margin-bottom: 10px;
}
.scrollable-row {
  min-height: 60px;
}
.custom-btn {
  background-color: rgb(32, 44, 52) !important;
  color: white !important;
  margin-right: 12px;
  padding: 8px 16px;
}
.custom-btn:hover {
  background-color: rgb(54, 70, 86) !important;
}
</style>

Deploy the flow.

Once deployed, the dashboard will show buttons for each production line. Clicking a line redirects the user to a page with following url:

https://<your-instance-name>/dashboard/lines?line=T1

Node-RED flow to create a dynamic menu for production lines on the dashboard.

Dashboard view showing production line buttons generated from the flow.

The "line" URL parameter will be used in the next section to store the user's selected production line.

Enable URL-Based Dashboard Access

In this section, we’ll build a flow that allows users to directly access the dashboard using a URL with a line parameter (e.g., ?line=T1). The flow will validate this parameter and store the selected line for each user session. If the parameter is missing or invalid, the user will be redirected to a Not Found page.

To achieve this, we need to:

Configure the dashboard to expose client-specific metadata.
Create a flow that validates the line parameter from the URL.
Store the user’s selected line using session-aware context data.

Configuring Dashboard Widgets to Include Client Information

To ensure client data is available in your flows, follow these steps:

Open the Dashboard 2.0 sidebar.
Switch to the Client Data tab.
Enable the option “Include client data”.
Tick the checkbox in front of:
- ui-control
- ui-template
- ui-button
- ui-text-input
- ui-dropdown
- ui-notification
Deploy the updated configuration.

Dashboard 2.0 settings to include client metadata from selected widgets like buttons and templates.

With this setting enabled, the selected widgets will include client-related metadata in their output messages under the msg._client property. This metadata is essential for building session-aware features in the Dashboard.

Building a Dashboard Flow for URL Access, Line Validation, and User Selection

In this section, we'll build a Node-RED flow that handles dashboard access via direct URLs, validates the line parameter, and stores the selected line per user session using client metadata. This ensures that each user's line selection is tracked independently and that invalid or missing parameters are handled gracefully.

The flow performs the following key tasks:

Detects when a user accesses the dashboard using a URL containing a line parameter.
Validates the parameter against a list of predefined production lines.
Stores the selected line using session-aware (client-specific) data.
Redirects the user appropriately based on the validity of the parameter.

Steps to Build the Flow:

Drag a ui-event node onto the canvas and configure it with the correct UI base path.
Drag a switch node and name it "Is it a pageview event?" and configure it with the property msg.topic and add the following condition:
- == $pageview
Drag another switch node and name it "Has line key?" and configure it with the property msg.payload.page.params.line, with two conditions:
- has key line
- is empty
Connect the ui-event node to the first switch node (labeled Is it a pageview event?). Then, connect the first output of this switch node to the second switch node (labeled Has line key?). This checks whether the page was accessed via URL and if a line parameter is present.

Drag a function node and name it "Extract Labels from Lines" and paste the following code:

let lines = global.get('lines', 'persistent') || [];
let labels = [
   ...lines.map(obj => obj.label),
];
msg.payload.labels = labels;
return msg;

This retrieves the list of available lines from the persistent global context, extracts their labels, and creates an array for easier verification of whether the user selected line is present.

Drag a change node and name it "Store line selection":
- Set global.store[msg._client.socketId].line to msg.payload.
Drag another switch node and name it "Is the currently accessed page 'Lines'?":

is equal to "Lines"

Connect the function node (Extract Labels from Lines) and the change node (Store line selection) to the first output of the switch node (Has line key?).
Drag another switch node and name it "Is line valid?" and set the property to msg.payload.labels and add following conditions:
- contains global.store[msg._client.socketId].line
For the first output of the switch node (Is the currently accessed page 'Lines'?), drag a change node and name it "Redirect the user to the All Lines menu" and Configure it to:
- Set msg.payload to "All Lines"
Drag a ui-control node onto the canvas and connect it to the change node (Redirect the user to the All Lines menu). This node will handle the redirection or display feedback on the dashboard.

This checks whether the selected line is valid by comparing it with the list of known line labels.

For the second output of the switch node (Is line valid?), drag a switch node and give it name "Is the currently accessed page 'Lines'?" and Set property to msg.payload.page.name and add following condition to check against:

== "Lines"
Otherwise

For the first output of the switch node ((Is the currently accessed page 'Lines'?), drag a change node and configure it to: - Set msg.payload to "Incorrect Link"
Drag a ui-control node onto the canvas and configure it with the correct UI base path and connect it the change node (Redirect to Not found page).
Deploy the changes.

Flow for managing URL-based access, validating line parameters, and storing client-specific selections on the OEE dashboard.

Create Live Request Flow (Per Line)

Let’s build the flow to retrieve the data now based on the user selection.

Drag a Template widget onto the canvas.
Double-click the Template widget to open its configuration.
Set the scope to ui and select the appropriate UI Base.

Paste the following script into the content field. This script triggers every second and sends a message that includes the current user's client data:

<script>
  export default {
    mounted() {
      // Set an interval to update the message every second
      this.intervalId = setInterval(() => {
        this.send('Component has loaded');
      }, 1000);
    },
    beforeUnmount() {
      // Clear the interval when the component is about to be destroyed
      clearInterval(this.intervalId);
    },
  };
</script>

Drag a Change node and name it "Set params".
Configure the Change node with the following rules:
- Set msg.params.$line to global.store[msg._client.socketId].line
- Set msg.query to "line"
Drag a Template node onto the canvas.
Double-click the Template node and set the property to msg.topic.

Paste the following SQL query into the content field:

SELECT * FROM requests WHERE "" = "" AND resolved IS NULL

Drag a Markdown widget and name it "Show currently selected line".
Create a new group in the UI for the Markdown widget to render into.
Enter the following content into the Markdown widget:
```
<h1 style="text-align: center;">Line: </h1>
```

The dashboard displays the selected production line name, retrieved from the client context, rendered using a Markdown widget.

Drag a SQLite node onto the canvas.
Select the appropriate database configuration.
Set the node to use the SQL query via "Prepared Statement".
Connect the Template widget to Change node and Template node to SQLite node.
Drag a link-out node onto the canvas and connect it to the SQLite node.
Deploy the changes.

Flow that triggers periodic queries for open requests specific to the user’s selected line using the client session and a SQLite database.

Preparing Data Rendering it in a Table

Once the data is retrieved, it needs to be validated, formatted, and routed appropriately for display. In this section, a flow will be built to check whether any unresolved requests exist for the selected production line. If there are no requests, a message will be shown to the user. Otherwise, the data will be processed and rendered in a table format using Dashboard widgets.

Drag a link-in node onto the canvas and connect it to the last link-out node.
Add a switch node to check whether the msg.payload is empty, name it "Is Payload empty?".
- Configure the switch with the following conditions:
  - msg.payload is empty
  - Otherwise
Drag a change node, name it "Show 'no outstanding request' message" and configure it to set a message when the payload is empty:
- Set msg.payload to "There are no outstanding requests"
Connect this change node to the first output of the switch node ("Is Payload empty?").
Drag another change node, name it "Remove 'no outstanding request' message" and configure it as follows:
- Set msg.payload to an empty string ""
Connect this second change node to the second output of the switch node ("Is Payload empty?").
Drag a text widget, name it "Text Widget for Message", onto the canvas, double-click it, and add a new group in the "Lines" page to render the message.
Connect the text widget ("Text Widget for Message") to both change nodes that are setting the text message ("Show 'no outstanding request' message" and "Remove 'no outstanding request' message").
Drag another link-out node onto the canvas and connect it to the second output of the switch node ("Is Payload empty?") that checks whether msg.payload is empty.
Drag another link-in onto the canvas.
Drag a split node, name it "Split Node", onto the canvas and connect it to the link-in node.
Drag a link-out node and connect it to the split node.
Deploy the changes.

Flow that checks if unresolved requests exist, sends an appropriate message when none are found, or prepares the data for tabular rendering.

Setting Up Visual Alerts and Timestamp Formatting

To enhance the visibility of production line requests, this section focuses on setting up visual alerts based on the age of each request and formatting timestamps in a user-friendly way. The created timestamp is always shown using relative time (e.g., "5 minutes ago"). For acknowledged and resolved, relative formatting is applied only when those timestamps are available. This improves readability and makes it easier to identify requests that are pending action.

Drag a link-in node and a function node onto the canvas. Name the function node as "Highlight Old Requests" and open it.
Paste the following JavaScript code into the function node:

const requested = msg.payload.requested;
const now = Date.now();

const requestedTime = new Date(requested).getTime();
const difference = now - requestedTime;

const oldRequestThreshold = global.get('oldRequestThreshold');
const veryOldRequestThreshold = global.get('veryOldRequestThreshold');
const alertActivationThreshold = global.get('alertActivationThreshold');

if (difference > (veryOldRequestThreshold * 60 * 1000)) {
   msg.payload.class = 'older';
   if (difference > (alertActivationThreshold * 60 * 1000)) {
       msg.payload.alert = true;
   }
   return msg;
}
else if (difference > (oldRequestThreshold * 60 * 1000)) {
   msg.payload.class = 'old';
   if (difference > (alertActivationThreshold * 60 * 1000)) {
       msg.payload.alert = true;
   }
   return msg;
}
else {
   if (difference > (alertActivationThreshold * 60 * 1000)) {
       msg.payload.alert = true;
   }
   msg.payload.class = 'normal';
   return msg;
}

Connect the link-in node to the function node.
Drag a date time formatter node onto the canvas. Name it "Format Requested Time" and double-click it to configure.
- Set outputFrom to fromNow.
- Set both input and output to msg.payload.requested.
Connect the function node to the date time formatter node.
Drag a link-out node and connect it to the function node.
Drag a switch node onto the canvas. Name it "Check if Acknowledged is null". Set the property to msg.payload.acknowledged, and add the following conditions:
- is null
- Otherwise
Connect the function node to the switch node.
Drag a second date time formatter node onto the canvas. Name it "Format Acknowledged Time".
- Set outputFrom to fromNow.
- Set both input and output to msg.payload.acknowledged.
Connect the second date time formatter node to the second output of the switch node ("Check if Acknowledged is null").
Drag another switch node onto the canvas. Name it "Check if Resolved is null". set the property to msg.payload.resolved. Add the following conditions:

is null
Otherwise

Connect this switch node ("Check if Resolved is null") to the output of the second date time formatter ("Format Acknowledged Time") node and to the first output of the first switch node ("Check if Acknowledged is null").
Drag a third date time formatter node onto the canvas. Name it "Format Resolved Time" and set outputFrom to fromNow. Set both input and output to msg.payload.resolved.
Connect this third date time formatter node to the second output of the second switch node ("Check if Resolved is null") .
Drag a link-out node and connect it to the third date time formatter node.
Drag another link-out node and connect it to the first output of the second switch node. Name it "Link to First Switch Output".
Deploy the changes.

Dashboard showing a request visually highlighted based on how long ago it was made, with applied styling and alert classification.

Flow for setting visual alert classes and formatting timestamps like "5 minutes ago" to enhance clarity and urgency of displayed requests.

Highlight Requests with CSS & Add Buttons to Update Request Status

We have the data prepared, the class property added to each request message, and the timestamp formatted for better readability. In this section, we will add 'Resolve' and 'Acknowledge' buttons for each request to update its status and apply CSS classes based on the status property for visual highlighting.

Drag a link-in node onto the canvas and connect it to the last link-out node.
Drag a switch node, name it "Is acknowledged null?", and set the property to msg.payload.acknowledged. Add the following conditions:
- is null
- otherwise
Drag a template node, name it "Build ack link", set the property to msg.payload.acknowledged, and add the following Mustache:
```
<a href="/dashboard/lines?line=&action=ack&request=" style="color: #000000" class="">ACKNOWLEDGE</a>
```
Connect the link-in node to the switch node. Connect the first output of the switch node ("Is acknowledged null?") to the input of the template node.
Drag another switch node, name it "Is resolved null?", set the property to msg.payload.resolved, and add the following conditions:
- is null
- otherwise
Drag a template node, give it name "Build res link", set the property to msg.payload.resolved, and add the following Mustache:
```
<a href="/dashboard/lines?line=&action=res&request=" style="color: #000000">RESOLVE</a>
```
Connect the input of this second switch node ("Is resolved null?") to the second output of the previous switch node (acknowledged switch), then connect the first output of the resolved switch node to the input of the second template node.
Drag a link-out node and connect both outputs of the resolved switch node to this link-out.
Deploy the changes.

Adding action buttons to update the status of each request directly from the dashboard table.

Adding a Mechanism to Update the Status of a Request in the Database

Drag ui event widget onto the canvas and configure it with the correct ui base.
Drag change node onto the canvas and add the following element:
- Set msg.params to {}
- Set msg.params.$request to msg.payload.query.request
Drag Date/Time Formatter node onto the canvas and set input format to "timestamp: milliseconds since epoch" and output to msg.now.
Drag switch node onto the canvas, set property to msg.query.action, and add the following conditions to check against:
- == ack
- == res
- otherwise
Drag two SQLite nodes onto the canvas, select the correct database configuration for both, and set the query type to 'Prepared Statement'.

For the first, set the following sql query:

UPDATE requests 
SET acknowledged = $now
WHERE rowid = $request 
AND acknowledged IS NULL

For the second, set the following sql query:

UPDATE requests 
SET resolved = $now
WHERE rowid = $request 
AND resolved IS NULL

Connect the ui event widget to change node, change node to date/time formatter node, date/time formatter to switch node, and:

switch node first output to first first sqlite node
switch node second output to second second sqlite node

Flow that handles the update of request status based on user actions (Acknowledged or Resolved).

Render Request Data in a Table

Now, let's display the prepared data in a table. To do this, we'll use a ui_table widget. However, before displaying, we need to convert the data back into an array, as we are currently spilling array data retrieved from the database into a single message.

Drag a link-in node onto the canvas and connect it to the last link-out node.
Drag a join node onto the canvas and connect it to the link-in node. Double-click on the join node and set the mode to automatic.
Drag another link-out node and connect it to the join node.
Drag a link-in node and connect it to the last link-out node.
Drag a ui_table widget onto the canvas and double-click to configure.
Create a new group on the lines page.
Set Action to replace and Interaction to none.
Untick the Auto Calculate Columns option.
Add the following column elements:
- Key: rowid, Label: Request, Align: Left, Type: Text
- Key: line, Label: Line, Align: Left, Type: Text
- Key: support, Label: Support, Align: Left, Type: Text
- Key: requested, Label: Requested, Align: Left, Type: HTML
- Key: acknowledged, Label: Acknowledged, Align: Left, Type: HTML
- Key: resolved, Label: Resolved, Align: Left, Type: HTML
- Key: notes, Label: Notes, Align: Left, Type: Text
Deploy the changes.

Render Data on table.

Create New Request Submission Flow

To create a flow that allows users to submit a request, follow these steps to set up the necessary UI elements, store the request details, validate input, and store the data in a database.

Drag the ui-event widget onto the canvas and configure it with the correct UI settings.
Drag a change node to retrieve the department list and name it "Show Dropdown Options". Add the following:
- Set msg.ui_update.options to global.departments.
Create a new group for the dropdown widget on the lines page. Connect the change node to the input of the dropdown widget, then link it to the ui-event node.
Drag another change node and set msg.payload to msg.store[msg._client.socketId].support. Name it "Store support (department) to context store".
Drag a text input widget for the notes field. Create a group for it in the lines page.
Add another change node to store the notes in the global context and name it "Store notes to context store":
- Set msg.payload to msg.store[msg._client.socketId].notes.
Connect the change node ("Store support (department) to context store") to the input of the dropdown widget and connect the change node ("Store notes to context store") to the text input widget.
Drag the button widget, label it "Request Support," and connect it to the change node that updates the UI with the department list.
Add a change node to store the request details in the global context and name it "Retrieve entered support request data":
- Set msg.request to {}.
- Set msg.request.support to the value msg.store[msg._client.socketId].support.
- Set msg.request.notes to the value msg.store[msg._client.socketId].notes.
- Set msg.request.line to the value msg.store[msg._client.socketId].line.
- Set msg.request.reference to the value msg.store[msg._client.socketId].reference.
Drag the switch node onto the canvas and set property to msg.request and add condtion to check "is not null".
Drag a function node and add the following code. Name it "Does department and notes are not empty?":

let request = msg.request;
if (typeof request !== "object" || request === null) {
   msg.payload = "Request must be an object.";
   return [null, null, msg];
} else if (!request.hasOwnProperty("support")) {
   msg.payload = "Please select the appropriate department for the request.";
   return [null, msg, null];
} else if (!request.hasOwnProperty("notes") || typeof request.notes !== "string" || request.notes.trim() === "") {
   msg.payload = "Please add notes to provide more context on the request.";
   return [null, null, msg];
} else {
   return [msg, null, null];
}

Connect the change node to switch node and switch node to function node. Connect the function node's first output to a Date/Time Formatter node. Set the input to 'Timestamp (milliseconds since epoch)' and the output to msg.request.time.
Drag a change node and set msg.payload to "Are you sure you want to submit a request?". Name it "Set Confirmation message".
Connect the change node ("Set Confirmation message") to the Date/Time Formatter node.
Drag a ui-notification widget, configure it with the correct UI, and set the position to center, checked the checkbox for both allow mnaual dismisal and all amnual confirmation, change close to "Cancel".
Connect the change node ("Set Confirmation message") to the ui-notification widget.
Drag another ui-notification widget, configure it with the correct UI, and set the position to center.
connect it to the second output of the function node.
Add a switch node and set the property to msg.payload with the condition:

== confirm_clicked Name it "Is confirm clicked?"

Drag a change node and add the following elements and give it name "Set Params":

Set msg.params to {}.
Set msg.params.$line to the value msg.request.linet.
Set msg.params.$support to the value msg.request.support.
Set msg.params.$time to the value msg.request.time.
Set msg.params.$notes to the value msg.request.notes.

Connect the change node ("Set Params") to the switch node ("Is confirm clicked?").
Drag a sqlite node, select the correct database configuration, and choose SQL Query via "Prepared Statement" and connect that sqlite node to the input change node ("Set Params")
Drag a change node and set the following, give it name "Clear entered request data":

Delete msg.store[msg._client.socketId].support.
Delete msg.store[msg._client.socketId].notes.

Connect the change node* ("Clear entered request data") to the sqlite node.
Drag a link-out node and connect it to the last change node.
Drag a link-in node and connect it to the last link-out node.
Drag two change nodes and configure them as follows:

First change node: Set msg.payload to an empty array [].
Second change node: Set msg.payload to an empty string "".

Connect the change nodes to the link-in node to complete the flow.
Connect the first change node to the ui dropdown widget and the second to the text input widget.
Deploy the changes.

Node-RED flow to handle request submission, including form validation, timestamp formatting, and SQL database insertion.

We have now successfully built one part of the Andon task dashboard. You can open the line view in the dashboard and check whether you can submit a request, mark it as acknowledged, and resolve it.

Dashboard UI where users select a department, enter notes, and submit a support request for the production line.

Up Next

Up until now, the focus has been on building the core functionality of the Andon Task Manager dashboard, including the Lines page. Design and layout have not been the priority. In the next part, you will learn how to enhance the visual design, improve usability, and create a dedicated page and menu for departments.

Later, we will guide you through building the Admin page for the Andon Task Manager dashboard—enabling request management, department configuration, and overall system control.