[{"data":1,"prerenderedAt":4222},["ShallowReactive",2],{"blog-\u002Fblog\u002Fmodbus":3,"blog-all-for-related":4,"blog-all-modbus":5},null,[],[6,501,798,1049,1270,1542,2070,2797,3982],{"id":7,"title":8,"authors":9,"body":11,"cta":474,"date":478,"description":479,"extension":480,"image":481,"lastUpdated":3,"meta":482,"navigation":490,"path":491,"seo":492,"sitemap":493,"stem":494,"subtitle":495,"tags":496,"tldr":499,"video":3,"__hash__":500},"blog\u002Fblog\u002F2026\u002F04\u002Fdiagnosing-modbus-degradation.md","Diagnosing Modbus Degradation: From CRC Errors to TCP Timeouts",[10],"sumit-shinde",{"type":12,"value":13,"toc":454},"minimark",[14,18,21,30,35,38,48,51,56,66,75,78,81,88,91,94,103,107,110,119,122,131,134,146,149,153,156,165,168,174,180,186,189,193,201,204,212,224,230,236,242,248,251,255,258,261,270,273,277,280,289,292,296,299,302,308,314,320,326,330,348,351,354,360,372,378,381,384,387,391,394,400,403,409,415,427,430,434,437,446],[15,16,17],"p",{},"Modbus doesn't fail loudly. It drifts, and by the time operators notice, you've already lost the easy fix.",[15,19,20],{},"It shows up as slightly stale values, a poll cycle that's somehow three times slower than configured, operators filing tickets about data that \"seems off.\" Never a hard fault. Never a clear cause.",[15,22,23,24,29],{},"The ",[25,26,28],"a",{"href":27},"\u002Fblog\u002F2026\u002F04\u002Fmodbus-polling-best-practices\u002F","previous article"," covered setup mistakes. This one covers what breaks after that: how to read CRC errors and TCP failures correctly, how dead devices silently consume your poll cycle, and what metrics catch degradation before your operators do.",[31,32,34],"h2",{"id":33},"serial-and-tcp-fail-through-different-mechanisms","Serial and TCP Fail Through Different Mechanisms",[15,36,37],{},"Modbus RTU and Modbus TCP share the same application protocol. The similarity ends there.",[15,39,40,45],{},[41,42],"img",{"alt":43,"src":44},"Comparison of Modbus RTU on RS-485 and Modbus TCP over Ethernet, showing shared serial bus versus network-based communication paths","\u002Fblog\u002F2026\u002F04\u002Fimages\u002Fmodbus-rtu-and-tcp-physical-layer-image.png",[46,47,43],"em",{},[15,49,50],{},"They fail through fundamentally different mechanisms, and the most common diagnostic mistake is applying serial troubleshooting logic to a TCP problem, or vice versa. It doesn't just waste time; it produces fixes aimed at the wrong layer entirely.",[52,53,55],"h3",{"id":54},"rs-485-physical-and-timing-failures","RS-485: physical and timing failures",[15,57,58,59,65],{},"On ",[25,60,64],{"href":61,"rel":62},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FRS-485",[63],"nofollow","RS-485"," serial segments, failure is almost always physical or timing-related.",[15,67,68,69,74],{},"RS-485 is a shared medium with no collision detection built into the protocol. Modbus RTU relies on a strict master-slave architecture where only the master initiates requests and only one device responds at a time. When the physical layer degrades (damaged cable, missing termination resistor, ground loop between panels, high-current wiring running parallel to the RS-485 pair) the master sees ",[25,70,73],{"href":71,"rel":72},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FCyclic_redundancy_check",[63],"CRC errors",". The request frame goes out clean. The device receives noise. It either drops the frame silently or sends back something corrupted.",[15,76,77],{},"The pattern of where and when errors appear is what makes serial failure diagnosable.",[15,79,80],{},"CRC errors distributed across all devices on a segment point to the shared medium: cable damage, missing or doubled termination resistors, ground potential differences between panels. Note that unterminated segments can still produce uneven error distributions. A device at the end of an unterminated run will often show higher CRC error rates than devices at midpoints due to signal reflection, even though the root cause is a shared physical problem. Errors that cluster on one or two specific devices point to those devices: a UART that can't sustain the configured baud rate, a transceiver pulling down bus voltage, or a passive RS-485 converter that doesn't fully meet the electrical spec. Errors that appear at predictable times of day point to induced noise. A 30-meter RS-485 run sharing a cable tray with a 460V motor feed will see induced voltage during motor start transients. Routing away from high-current runs, using shielded twisted pair, and grounding the shield at one end resolves it. Widening the timeout does not.",[15,82,83,87],{},[84,85,86],"strong",{},"Duplicate Slave IDs"," are an underappreciated source of corruption. If two devices on the same segment share the same address (a common result after device replacement when the replacement unit ships with a default address already in use) both will respond simultaneously to the same request, corrupting the frame with no physical cause. Before assuming the wiring is at fault, verify that every device address on the segment is unique.",[15,89,90],{},"One failure mode that gets far less attention than it deserves: bus contention from a transmit driver that doesn't release the line cleanly.",[15,92,93],{},"RS-485 is half-duplex. After sending a request, the master must de-assert its transmit driver before the device can respond. If the driver stays asserted even a few hundred microseconds too long (firmware timing bug, misconfigured enable pin, USB adapter with incorrect turnaround handling) the device's response overlaps with the master's still-active driver. The result is frame corruption on every transaction, every time, and it's indistinguishable from a severely damaged cable.",[15,95,96,97,102],{},"A ",[25,98,101],{"href":99,"rel":100},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FProtocol_analyzer",[63],"protocol analyzer"," confirms it immediately by showing both signals active simultaneously. Before you pull cable on a segment where every transaction is corrupted, swap the serial adapter or test with a different master. It takes ten minutes and it's right more often than people expect.",[52,104,106],{"id":105},"modbus-tcp-connection-management-and-latency","Modbus TCP: connection management and latency",[15,108,109],{},"On Modbus TCP, failure is almost always about connection management and latency. There's no shared medium and no electrical noise path. Instead, you get connection-level problems that the polling stack surfaces as device-offline errors, which are easy to misread as device failures when the device is fine.",[15,111,112,113,118],{},"The most common TCP failure pattern is connection table exhaustion. Modbus TCP devices enforce a hard limit on simultaneous connections at the firmware level, but this limit varies considerably across hardware, from as few as 1 connection on some embedded devices to 16 or more on capable gateway hardware. A common midrange figure for simple PLCs and meters is 4 to 8, but you should check your device's datasheet rather than assume. If your polling stack opens a fresh ",[25,114,117],{"href":115,"rel":116},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FTransmission_Control_Protocol",[63],"TCP connection"," for every request rather than maintaining a persistent one, it can fill the connection table within seconds. Once full, the device responds to new connection attempts with a TCP RST. Your stack logs this as the device being offline. The device is operating normally.",[15,120,121],{},"Those connection slots release when the idle-connection timeout or the TCP FIN\u002FRST sequence clears them. On most embedded Modbus TCP firmware, this idle timeout is typically 60 to 120 seconds, producing a failure cycle with a consistent interval: errors for roughly 90 seconds, reconnect, fill the table again, repeat.",[15,123,124,128],{},[41,125],{"alt":126,"src":127},"Cyclical Modbus TCP connection exhaustion loop showing connection creation, table saturation, TCP resets, and idle timeout recovery","\u002Fblog\u002F2026\u002F04\u002Fimages\u002Fmodbus-tcp-connection-cycle.png",[46,129,130],{},"Cyclical failure pattern caused by connection table exhaustion. Diagnostic signal: failures repeat at a consistent interval.",[15,132,133],{},"That regularity is the diagnostic signal. A device with intermittent hardware faults fails unpredictably. A device whose connection table is being exhausted fails on a clock. If you're seeing periodic offline events with suspiciously consistent timing, check your connection handling before you assume the device is faulty.",[15,135,136,139,140,145],{},[84,137,138],{},"Transaction ID handling"," is worth checking in high-concurrency polling configurations. The ",[25,141,144],{"href":142,"rel":143},"https:\u002F\u002Fwww.modbus.org\u002Ffile\u002Fsecure\u002Fmodbusprotocolspecification.pdf",[63],"Modbus application protocol specification"," defines Transaction IDs to match requests with responses. A polling stack that reuses Transaction IDs before receiving a response to the previous one can match incoming responses to the wrong pending request. When this occurs, the symptom is correct values appearing in the wrong registers. It doesn't show up as an error at all, which makes it unusually difficult to diagnose. If you're seeing values that are off by a plausible amount but never produce error codes, check whether your stack's Transaction ID handling is correct under concurrent load.",[15,147,148],{},"The second TCP failure mode that's become more common as industrial networks gain remote access infrastructure is latency on routed network paths pushing transaction times past configured timeouts. This applies to any routed path: site-to-site VPNs, SD-WAN appliances, MPLS links with QoS misconfiguration, or firewalls with deep-packet inspection enabled for industrial protocols. Modbus TCP on a dedicated plant-floor LAN has round-trip latency in single-digit milliseconds. The same configuration over a site-to-site VPN or through a stateful firewall can see 80 to 200ms per transaction. If your timeouts were calculated against a local network and you've since added any routing hops, your effective timeout margin may now be zero under any congestion. The failures are load-dependent: worse during business hours, cleaner overnight, invisible when you run a manual test. The fix is the same as in the last article: measure actual round-trip time under realistic load, then set your timeout to 1.5 to 2x that value.",[52,150,152],{"id":151},"the-hybrid-case-serial-to-ethernet-converters","The hybrid case: serial-to-Ethernet converters",[15,154,155],{},"Most production Modbus installations aren't purely serial or purely TCP. They're RS-485 segments accessed through a serial-to-Ethernet converter with TCP on the network side and RS-485 on the fieldbus side. Both failure modes can exist simultaneously, and the converter adds its own at the boundary.",[15,157,158,159,164],{},"The most common converter-specific failure is inter-frame gap violation. The ",[25,160,163],{"href":161,"rel":162},"https:\u002F\u002Fwww.modbus.org\u002Ffile\u002Fsecure\u002Fmodbusoverserial.pdf",[63],"Modbus over Serial Line specification"," requires a minimum 3.5-character silent interval between frames. When concurrent TCP requests arrive simultaneously, a converter that doesn't enforce this gap between queued RS-485 dispatches corrupts the second transaction, even when the cable is perfect and both devices are healthy. The error looks serial. The cause is software. Disabling concurrency and forcing strictly sequential requests to that segment is the fastest confirmation: if errors stop, the converter's queuing was the cause.",[15,166,167],{},"Three other failure modes are worth knowing before you chase wiring:",[15,169,170,173],{},[84,171,172],{},"Buffering latency."," Some converters buffer TCP data before forwarding to RS-485, adding variable latency under load. Failures become load-dependent, mimicking electrical problems. Reducing polling concurrency or adding a small inter-request delay often resolves it without hardware changes.",[15,175,176,179],{},[84,177,178],{},"Silent connection limits."," Like the devices they front-end, converters enforce connection limits, but some accept the connection and then stop responding rather than refusing it. If timeouts resolve when the polling engine restarts but not otherwise, check for a converter connection limit and configure persistent connection reuse.",[15,181,182,185],{},[84,183,184],{},"Baud rate or parity mismatch."," After any converter replacement, verify baud rate, parity, and stop bits match the segment. A mismatch corrupts every transaction and is easy to miss if the previous unit's settings weren't documented.",[15,187,188],{},"Most converters expose diagnostic statistics through a web UI or Telnet interface. Pull those first. Near-zero serial error counters with nonzero queue depth during failures points to a software queuing problem. Climbing serial error counters points to a real physical fault on the RS-485 side.",[31,190,192],{"id":191},"exception-codes-tell-you-what-type-of-error-youre-dealing-with","Exception Codes Tell You What Type of Error You're Dealing With",[15,194,195,196,200],{},"Before treating every failed transaction as a generic timeout or communication fault, check the ",[25,197,199],{"href":142,"rel":198},[63],"Modbus exception code",". When a device receives a valid request but can't fulfill it, it returns an exception response, and that code is specific enough to redirect your troubleshooting immediately.",[15,202,203],{},"The codes you'll encounter most often:",[15,205,206,210],{},[41,207],{"alt":208,"src":209},"Modbus exception codes quick reference table showing error codes, meanings, common causes, and first troubleshooting steps","\u002Fblog\u002F2026\u002F04\u002Fimages\u002Fexception-table-modbus.png",[46,211,208],{},[15,213,214,217,218,223],{},[84,215,216],{},"Exception 0x01, Illegal Function",": The device doesn't support the function code you sent. Usually a configuration issue: the polling stack is sending a ",[25,219,222],{"href":220,"rel":221},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FModbus#Supported_function_codes",[63],"function code"," the device firmware doesn't implement.",[15,225,226,229],{},[84,227,228],{},"Exception 0x02, Illegal Data Address",": The requested register address doesn't exist on this device. This is the most diagnostic exception for register batch problems. If a batch that spans a gap in the device's register map produces this exception, split the batch into two separate reads covering the contiguous ranges.",[15,231,232,235],{},[84,233,234],{},"Exception 0x03, Illegal Data Value",": The value in a write request is outside the range the device accepts. Relevant for write operations; not typically seen on reads.",[15,237,238,241],{},[84,239,240],{},"Exception 0x04, Device Failure",": The device received and understood the request but encountered an internal error. This is a device-side problem, not a communication problem. Persistent 0x04 responses on a specific register range warrant checking the device's own diagnostics.",[15,243,244,247],{},[84,245,246],{},"Exception 0x06, Device Busy",": The device received the request but is temporarily unable to process it. Consistent 0x06 responses mean you're polling faster than the device can handle. Reduce the poll rate for that device or increase the inter-request delay.",[15,249,250],{},"Log exception codes as a separate field alongside transaction success\u002Ffailure. A poll list generating steady 0x02 responses on one device and steady 0x06 on another has two different problems requiring two different fixes.",[31,252,254],{"id":253},"dead-devices-are-draining-your-bus-on-every-poll-cycle","Dead Devices Are Draining Your Bus on Every Poll Cycle",[15,256,257],{},"There is a problem in almost every Modbus installation that's been running for more than a year: the poll list contains devices that no longer respond, and the master is spending measurable time waiting for them on every single cycle.",[15,259,260],{},"Take a serial network with 18 active devices and 3 that are offline. With a 300ms timeout and 2 retries configured, each unresponsive device costs 900ms per cycle. Three offline devices: 2.7 seconds of dead time on every poll cycle. On a bus where each active device transaction takes 70ms, that's the equivalent of roughly 40 active transactions blocked per cycle.",[15,262,263,267],{},[41,264],{"alt":265,"src":266},"Modbus poll cycle timeline showing active transactions and dead device waits consuming majority of cycle time","\u002Fblog\u002F2026\u002F04\u002Fimages\u002Fmodbus-poll-cycle-dead-time.png",[46,268,269],{},"Dead devices dominate the poll cycle: ~5.1s actual vs 500ms target, with 2.7s wasted on non-responsive devices.",[15,271,272],{},"If your fast-tier registers are supposed to poll at 500ms, your actual cycle time is now well over three seconds. Data still flows. Values still update. Nothing throws a hard error. The system looks operational while running at a fraction of its designed capacity.",[52,274,276],{"id":275},"the-runtime-fix-backoff","The runtime fix: backoff",[15,278,279],{},"After a device fails a configurable number of consecutive polls, move it out of the normal rotation and into a low-frequency check, once every 60 seconds is a reasonable starting point. When it responds again, restore it to the normal rotation immediately.",[15,281,282,283,288],{},"Most commercial ",[25,284,287],{"href":285,"rel":286},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FSCADA",[63],"SCADA"," systems and industrial gateways support this natively, usually labeled as device backoff, retry holdoff, or failure-state polling interval. In FlowFuse, you implement this explicitly: track a failure counter per device address, suppress it from the main poll rotation when the counter exceeds your threshold, and run it on a separate low-frequency timer.",[15,290,291],{},"Backoff is a runtime mitigation, not a solution. Backoff entries should be reviewed quarterly, and anything that hasn't responded in 30 days warrants a direct question: is this device expected to return, or is it permanently gone? If it's gone, remove it. The poll list should reflect the actual field.",[31,293,295],{"id":294},"the-metrics-that-tell-you-whats-actually-happening","The Metrics That Tell You What's Actually Happening",[15,297,298],{},"A device running at 91% transaction success rate isn't failing visibly. Data still flows, values still update. But 9 out of every 100 polls are producing errors. If that 91% has been drifting down from 99% over six weeks, something is changing: a connector degrading, electrical conditions worsening. The window to investigate at low cost is open right now. It closes when the rate hits 70% and starts producing visible data gaps.",[15,300,301],{},"The four metrics worth tracking continuously are transaction success rate, response time, segment-level CRC error count, and poll cycle completion time. Your Modbus master has all of this information on every transaction. The only question is whether you're capturing and storing it.",[15,303,304,307],{},[84,305,306],{},"Transaction success rate"," per device, measured as a rolling average over the last 100 polls, is the primary health indicator. Healthy devices run above 99%. A device that's been at 95% for two weeks is telling you something has changed. The distinction between gradual drift and a sudden drop tells you whether you're looking at environmental degradation or a discrete fault.",[15,309,310,313],{},[84,311,312],{},"Response time"," per device, trended over time, is often a leading indicator of developing problems, though not always. Gradual degradation due to worsening electrical conditions, increasing bus load, or a device struggling under heavier firmware load typically shows up as rising response times before timeouts begin. That said, some failure modes are abrupt: a cable that finally breaks, a device that locks up, a switch port that goes down. These jump straight to timeout failures without any response time warning. Treat response time trending as a useful early-warning signal for gradual faults, not as a guarantee that failures will always be preceded by visible latency drift.",[15,315,316,319],{},[84,317,318],{},"CRC error count"," should be tracked at the segment level, not just per device. A simultaneous uptick across all devices on a segment points to a shared-medium change. One device's error rate rising while the others stay flat points to that device specifically.",[15,321,322,325],{},[84,323,324],{},"Poll cycle completion time"," should be stable. A slow upward drift means something is adding latency: response times lengthening, backoff not engaging on newly failed devices, devices added to the rotation without reviewing the impact on total cycle time. A sudden jump usually means a device started timing out that wasn't before. By the time individual device success rates start dropping visibly, cycle time has usually already been warning you for days.",[52,327,329],{"id":328},"putting-it-into-practice","Putting it into practice",[15,331,332,333,337,338,342,343,347],{},"Instrument your polling layer to write a timestamped record on every transaction: device address, function code, success or failure, response time in milliseconds, exception code on failures, and error type (timeout vs. CRC vs. exception response). Write those records to a ",[25,334,336],{"href":335},"\u002Fnode-red\u002Fdatabase\u002F","time-series store",". ",[25,339,341],{"href":340},"\u002Fnode-red\u002Fdatabase\u002Finfluxdb\u002F","InfluxDB"," is a common choice for industrial deployments; a ",[25,344,346],{"href":345},"\u002Fblog\u002F2025\u002F08\u002Fgetting-started-with-flowfuse-tables\u002F","PostgreSQL"," table with a timestamp index works fine too.",[15,349,350],{},"A reasonable retention strategy is to keep raw transaction records for 7 days and roll up to hourly aggregates (per-device success rate, median response time, CRC error count) for 90 days of trend data.",[15,352,353],{},"From that raw stream, you want three derived views:",[15,355,356,359],{},[84,357,358],{},"Per-device rolling success rate"," calculated over a sliding window of the last 100 transactions, not a fixed time window. Time windows conflate a healthy device polled infrequently with a struggling device polled every 500ms.",[15,361,362,365,366,371],{},[84,363,364],{},"Per-device response time baseline and deviation",": compute the ",[25,367,370],{"href":368,"rel":369},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FMedian",[63],"median"," response time per device over the prior 30 days, then flag any device whose current 1-hour median exceeds twice that baseline. Median rather than mean, because a single timeout event skews the mean and obscures the underlying trend.",[15,373,374,377],{},[84,375,376],{},"Segment-level CRC error rate",": sum CRC failures across all devices sharing a physical segment or converter, and plot that alongside the individual device rates. The divergence between the segment total and any individual device is the diagnostic signal.",[15,379,380],{},"In FlowFuse, write a structured record after each Modbus response (device ID, timestamp, success boolean, response time, error type) to a flow targeting your time-series backend.",[15,382,383],{},"Build a dashboard that flags any device whose rolling success rate drops below 97%, or whose current response time median exceeds twice its 30-day baseline. Treat these thresholds as starting points. High-noise environments or older legacy devices may warrant looser thresholds; safety-critical systems warrant tighter ones. The goal is to make unplanned degradation visible early, not to produce alerts for every expected variance during a planned network change or device restart.",[15,385,386],{},"This is a few hours of implementation work. Done once, it runs indefinitely and gives you the diagnostic foundation that makes every future troubleshooting conversation shorter.",[31,388,390],{"id":389},"what-you-can-fix-without-a-maintenance-window","What You Can Fix Without a Maintenance Window",[15,392,393],{},"Changes that affect only the master's behavior (what it polls, how it times out, how it handles failures) can be made at runtime. Changes that affect the physical bus or network topology require the bus to be quiet.",[15,395,396,399],{},[84,397,398],{},"One change per maintenance window."," If you adjust scan rates, timeout values, register batches, and the device list in the same two-hour window and something breaks, you've lost the ability to know which change caused it. One change per window keeps causality traceable and mistakes recoverable.",[15,401,402],{},"With that principle in place:",[15,404,405,408],{},[84,406,407],{},"Scan rate changes are hot-changeable."," Adding a device to the poll rotation, adjusting a scan interval, moving a register to a different poll tier, disabling a device in persistent backoff: none of these require the serial bus to go quiet. Make the change, watch bus metrics through one full cycle, confirm the outcome.",[15,410,411,414],{},[84,412,413],{},"Timeout values can be adjusted per device without touching anything else."," If a specific device's response time has increased and is now generating intermittent timeouts, raise that device's timeout to match its current behavior plus a real margin. Keep the change narrow: one device, one parameter, one observable outcome.",[15,416,417,420,421,426],{},[84,418,419],{},"Register batch restructuring can be done incrementally."," If a batch spans a gap in the register map and produces exception 0x02 responses, split it into two clean batches covering the contiguous ranges. The ",[25,422,425],{"href":423,"rel":424},"https:\u002F\u002Fwww.ni.com\u002Fen\u002Fshop\u002Fseamlessly-connect-to-third-party-devices-and-supervisory-system\u002Fthe-modbus-protocol-in-depth.html",[63],"Modbus data model"," defines four distinct address spaces (coils, discrete inputs, input registers, holding registers) and batches must not cross between them.",[15,428,429],{},"Physical changes to the RS-485 segment (wiring, termination, baud rate or parity settings, converter replacement) require the bus to be quiet. So does any change to network topology on the TCP side. Everything else: don't wait.",[31,431,433],{"id":432},"where-this-leaves-you","Where This Leaves You",[15,435,436],{},"What keeps a Modbus installation stable for years is mostly mundane: a poll list reviewed quarterly against the actual field, scan rates tiered with the reasoning written down, timeouts calculated from measured device response times rather than defaults, and per-device success rates visible on a dashboard that someone checks regularly enough to catch drift before it becomes failure. None of it is sophisticated. All of it requires treating the Modbus layer as something that needs ongoing maintenance, not a configuration artifact from the last integration project.",[15,438,439,440,445],{},"If you've worked through both parts and the installation is still misbehaving, you're likely past what configuration review can resolve. Power quality on the RS-485 segment, a device firmware bug producing malformed responses on specific register ranges, or a network infrastructure change that introduced unexpected latency: these are real causes that look like everything else until you rule everything else out. A ",[25,441,444],{"href":442,"rel":443},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FPacket_analyzer",[63],"protocol capture"," on the wire during an active failure event will tell you more in twenty minutes than another hour of configuration review. At that point, that's where to start.",[15,447,448,449,453],{},"For a guide to connecting Modbus PLCs, alongside OPC UA, EtherNet\u002FIP, and Siemens S7, to MQTT, cloud, and enterprise systems, see the ",[25,450,452],{"href":451},"\u002Flanding\u002Fplc\u002F","FlowFuse PLC integration overview",".",{"title":455,"searchDepth":456,"depth":456,"links":457},"",4,[458,465,466,469,472,473],{"id":33,"depth":459,"text":34,"children":460},2,[461,463,464],{"id":54,"depth":462,"text":55},3,{"id":105,"depth":462,"text":106},{"id":151,"depth":462,"text":152},{"id":191,"depth":459,"text":192},{"id":253,"depth":459,"text":254,"children":467},[468],{"id":275,"depth":462,"text":276},{"id":294,"depth":459,"text":295,"children":470},[471],{"id":328,"depth":462,"text":329},{"id":389,"depth":459,"text":390},{"id":432,"depth":459,"text":433},{"type":475,"title":476,"description":477},"sign-up","Unlock your Modbus data with FlowFuse","Get Modbus data flowing reliably, then connect every other protocol on your plant floor. OPC-UA, MQTT, legacy and modern, all in one place","2026-04-29","Modbus doesn't fail loudly. It drifts. This guide covers how to diagnose serial vs. TCP failures, eliminate dead device overhead, and build the metrics layer that tells you something is wrong before your operators do.","md","\u002Fblog\u002F2026\u002F04\u002Fimages\u002Fmodbus-degradation-img.png",{"keywords":483,"excerpt":484},"Modbus, Modbus RTU, Modbus TCP, RS-485, CRC errors, TCP timeouts, polling, connection exhaustion, industrial networking, SCADA, exception codes, latency, device backoff, response time, time-series monitoring",{"type":12,"value":485},[486,488],[15,487,17],{},[15,489,20],{},true,"\u002Fblog\u002F2026\u002F04\u002Fdiagnosing-modbus-degradation",{"title":8,"description":479},{"loc":491},"blog\u002F2026\u002F04\u002Fdiagnosing-modbus-degradation","CRC errors, connection exhaustion, dead poll lists, and the metrics that catch Modbus degradation early",[497,498],"flowfuse","modbus","Modbus degradation rarely announces itself it shows up as stale values, slower-than-expected poll cycles, and vague operator complaints. RS-485 serial and Modbus TCP fail through different mechanisms (CRC errors vs. connection table exhaustion), and the four metrics to monitor are transaction success rate, response time, CRC error count, and poll cycle completion time.","EEbwl5YsHjkMCubXdTrxlKbik5IsaDwtkmYi7pGVBV4",{"id":502,"title":503,"authors":504,"body":505,"cta":773,"date":777,"description":778,"extension":480,"image":779,"lastUpdated":3,"meta":780,"navigation":490,"path":790,"seo":791,"sitemap":792,"stem":793,"subtitle":794,"tags":795,"tldr":796,"video":3,"__hash__":797},"blog\u002Fblog\u002F2026\u002F04\u002Fmodbus-polling-best-practices.md","Most Modbus Polling Setups Are Wrong: Here's How to Fix Yours",[10],{"type":12,"value":506,"toc":767},[507,512,515,518,521,529,533,536,539,542,545,551,557,563,566,594,597,600,603,607,610,613,616,621,624,627,630,635,638,644,650,656,659,662,667,670,673,678,681,684,688,691,698,701,704,709,712,715,718,721,726,729,732,735,740,743,748,751,753,756,759,762],[15,508,509],{},[84,510,511],{},"Modbus polling looks simple. It is simple. That's the problem.",[15,513,514],{},"You set a scan rate, point it at a device, start reading registers, and data flows. It works. So nobody looks at it again.",[15,516,517],{},"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.",[15,519,520],{},"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.",[15,522,523,524,528],{},"This article isn't about the basics of how Modbus works. If you need that, start ",[25,525,527],{"href":526},"\u002Fblog\u002F2026\u002F01\u002Fwhy-modbus-still-exist\u002F","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. It covers the three mistakes made at commissioning. The next article covers what happens after the system is running.",[31,530,532],{"id":531},"the-myth-of-the-universal-scan-rate","The Myth of the Universal Scan Rate",[15,534,535],{},"Every Modbus polling setup has a scan rate. Most setups have one scan rate. That's where the trouble starts.",[15,537,538],{},"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.",[15,540,541],{},"The problem isn't the interval you picked. The problem is that one interval is the wrong answer for almost every real installation.",[15,543,544],{},"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.",[15,546,547,550],{},[84,548,549],{},"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.",[15,552,553,556],{},[84,554,555],{},"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.",[15,558,559,560],{},"The fix isn't complicated, but it requires making a deliberate decision you've probably been deferring: ",[84,561,562],{},"categorize your data by how fast it actually changes, then assign poll rates to match.",[15,564,565],{},"A practical starting framework for most industrial installations:",[567,568,569,576,582,588],"ul",{},[570,571,572,575],"li",{},[84,573,574],{},"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.",[570,577,578,581],{},[84,579,580],{},"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.",[570,583,584,587],{},[84,585,586],{},"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.",[570,589,590,593],{},[84,591,592],{},"On-demand only:"," Nameplate data, firmware versions, serial numbers, calibration constants. Poll once at startup and cache. Never poll again during normal operation.",[15,595,596],{},"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.",[15,598,599],{},"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.",[15,601,602],{},"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.",[31,604,606],{"id":605},"how-timeout-misconfiguration-kills-stability","How Timeout Misconfiguration Kills Stability",[15,608,609],{},"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.",[15,611,612],{},"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.",[15,614,615],{},"That silence is where most setups go wrong.",[15,617,618],{},[84,619,620],{},"The too-tight timeout problem",[15,622,623],{},"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.",[15,625,626],{},"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.",[15,628,629],{},"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.",[15,631,632],{},[84,633,634],{},"Calculating a timeout that actually makes sense",[15,636,637],{},"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:",[15,639,640,643],{},[46,641,642],{},"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.",[15,645,646,649],{},[46,647,648],{},"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.",[15,651,652,655],{},[46,653,654],{},"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.",[15,657,658],{},"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.",[15,660,661],{},"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.",[15,663,664],{},[84,665,666],{},"The too-loose timeout problem",[15,668,669],{},"The other failure mode gets less attention because it doesn't cause errors. It causes slowness, which is easier to ignore.",[15,671,672],{},"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.",[15,674,675],{},[84,676,677],{},"Retries: the configuration that multiplies your problems",[15,679,680],{},"Most Modbus stacks let you configure a retry count. The default in many tools is 3. That sounds conservative. It isn't.",[15,682,683],{},"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.",[31,685,687],{"id":686},"register-batching-do-it-right-or-dont-do-it","Register Batching: Do It Right or Don't Do It",[15,689,690],{},"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.",[15,692,693,694,697],{},"What gets left out of that explanation is the word ",[46,695,696],{},"contiguous",", and that omission is where batching goes from optimization to problem.",[15,699,700],{},"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.",[15,702,703],{},"The advice to batch your reads is correct. The problem is what happens when engineers apply it without reading the register map first.",[15,705,706],{},[84,707,708],{},"The contiguous register requirement",[15,710,711],{},"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.",[15,713,714],{},"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.",[15,716,717],{},"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.",[15,719,720],{},"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.",[15,722,723],{},[84,724,725],{},"How to batch correctly",[15,727,728],{},"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?",[15,730,731],{},"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.",[15,733,734],{},"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.",[15,736,737],{},[84,738,739],{},"Batching and your poll rate tiers",[15,741,742],{},"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.",[15,744,745],{},[84,746,747],{},"A note on writes",[15,749,750],{},"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.",[31,752,433],{"id":432},[15,754,755],{},"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.",[15,757,758],{},"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.",[15,760,761],{},"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. The next article covers that: serial versus TCP failure modes, unresponsive device handling, live diagnostics, and how to fix what you find without taking production down.",[15,763,764,765,453],{},"For a complete guide to connecting Modbus PLCs, alongside OPC UA, EtherNet\u002FIP, and Siemens S7, to MQTT, cloud, and enterprise systems, see the ",[25,766,452],{"href":451},{"title":455,"searchDepth":456,"depth":456,"links":768},[769,770,771,772],{"id":531,"depth":459,"text":532},{"id":605,"depth":459,"text":606},{"id":686,"depth":459,"text":687},{"id":432,"depth":459,"text":433},{"type":774,"title":775,"description":776},"contact","Need help fixing your Modbus setup?","If your system is still dropping data or behaving unpredictably, reach out. We can help review your polling configuration and identify what is actually causing the instability.","2026-04-03","Most Modbus polling problems aren't hardware failures. They're three configuration mistakes made at commissioning and never revisited. Here's how to fix them.","\u002Fblog\u002F2026\u002F04\u002Fimages\u002Fmodbus-polling-best-practices.jpg",{"keywords":781,"excerpt":782},"Modbus polling, Modbus configuration, Modbus troubleshooting, Modbus scan rate, Modbus timeout, RS-485 communication, Modbus batching, industrial automation, Node-RED Modbus",{"type":12,"value":783},[784,788],[15,785,786],{},[84,787,511],{},[15,789,514],{},"\u002Fblog\u002F2026\u002F04\u002Fmodbus-polling-best-practices",{"title":503,"description":778},{"loc":790},"blog\u002F2026\u002F04\u002Fmodbus-polling-best-practices","The configuration decisions made at setup time that cause problems you'll blame on hardware",[497,498],"Most Modbus polling problems aren't hardware failures they're three configuration mistakes made at commissioning: polling all registers at a single scan rate instead of tiering by how fast data changes, setting timeouts based on intuition instead of measured device response times, and batching registers aggressively across gaps in the register map. Each mistake produces silent failures that trace back to configuration decisions that are straightforward to fix once identified.","Cx7Mj0Us8s4dRRfctNVQ1p2n0X7_ia1L1gKSh6xTzVw",{"id":799,"title":800,"authors":801,"body":802,"cta":1032,"date":1036,"description":1037,"extension":480,"image":1038,"lastUpdated":3,"meta":1039,"navigation":490,"path":1041,"seo":1042,"sitemap":1043,"stem":1044,"subtitle":1045,"tags":1046,"tldr":3,"video":3,"__hash__":1048},"blog\u002Fblog\u002F2026\u002F03\u002Fwhy-opcua-is-not-replacing-modbus-yet.md","Why OPC UA Is Not Replacing Modbus (Yet)",[10],{"type":12,"value":803,"toc":1022},[804,809,814,817,824,827,838,841,845,848,851,854,862,865,869,872,875,878,881,884,887,890,894,897,900,903,906,909,913,916,919,922,925,928,931,935,938,941,944,947,950,953,957,960,963,966,969,972,975,979,982,985,988,991,994,997,1000,1004,1007,1010,1013,1016,1019],[15,805,806],{},[84,807,808],{},"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.",[15,810,811],{},[84,812,813],{},"Modbus is still winning.",[15,815,816],{},"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.",[15,818,819,820,823],{},"In January, we wrote about ",[25,821,822],{"href":526},"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.",[15,825,826],{},"Both camps are right. And that's exactly the problem.",[15,828,829,830,833,834,837],{},"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 ",[46,831,832],{},"can"," do and what most facilities ",[46,835,836],{},"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.",[15,839,840],{},"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.",[31,842,844],{"id":843},"the-promise-vs-the-reality","The Promise vs. The Reality",[15,846,847],{},"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.",[15,849,850],{},"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.",[15,852,853],{},"None of that happened.",[15,855,23,856,861],{},[25,857,860],{"href":858,"rel":859},"https:\u002F\u002Fwww.futuremarketreport.com\u002Findustry-report\u002Fmodbus-communication-module-market",[63],"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\u002FOT gateways. At the field device level, Modbus still dominates.",[15,863,864],{},"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.",[31,866,868],{"id":867},"the-complexity-tax-nobody-talks-about","The Complexity Tax Nobody Talks About",[15,870,871],{},"OPC UA's biggest competitor isn't Modbus. It's its own specification.",[15,873,874],{},"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.",[15,876,877],{},"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.",[15,879,880],{},"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.",[15,882,883],{},"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.",[15,885,886],{},"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.",[15,888,889],{},"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.",[31,891,893],{"id":892},"the-skills-gap-on-the-floor","The Skills Gap on the Floor",[15,895,896],{},"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.",[15,898,899],{},"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.",[15,901,902],{},"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.",[15,904,905],{},"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.",[15,907,908],{},"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.",[31,910,912],{"id":911},"the-hardware-reality","The Hardware Reality",[15,914,915],{},"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.",[15,917,918],{},"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.",[15,920,921],{},"OPC UA has a different story. A properly implemented OPC UA server needs a real processor capable of running a TCP\u002FIP 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.",[15,923,924],{},"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.",[15,926,927],{},"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.",[15,929,930],{},"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.",[31,932,934],{"id":933},"where-opc-ua-actually-wins","Where OPC UA Actually Wins",[15,936,937],{},"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.",[15,939,940],{},"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.",[15,942,943],{},"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.",[15,945,946],{},"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.",[15,948,949],{},"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.",[15,951,952],{},"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.",[31,954,956],{"id":955},"the-gateway-middle-ground","The Gateway Middle Ground",[15,958,959],{},"The industry didn't wait for OPC UA to win. It built a workaround and quietly made it the standard architecture.",[15,961,962],{},"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.",[15,964,965],{},"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.",[15,967,968],{},"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.",[15,970,971],{},"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.",[15,973,974],{},"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.",[31,976,978],{"id":977},"what-would-actually-accelerate-opc-ua-adoption","What Would Actually Accelerate OPC UA Adoption",[15,980,981],{},"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.",[15,983,984],{},"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.",[15,986,987],{},"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.",[15,989,990],{},"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.",[15,992,993],{},"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.",[15,995,996],{},"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.",[15,998,999],{},"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.",[31,1001,1003],{"id":1002},"conclusion-the-yet-has-a-deadline-but-nobody-knows-it","Conclusion: The \"Yet\" Has a Deadline, But Nobody Knows It",[15,1005,1006],{},"OPC UA will win. That part isn't in dispute.",[15,1008,1009],{},"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.",[15,1011,1012],{},"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.",[15,1014,1015],{},"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.",[15,1017,1018],{},"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.",[15,1020,1021],{},"Modbus will be there when you get back.",{"title":455,"searchDepth":456,"depth":456,"links":1023},[1024,1025,1026,1027,1028,1029,1030,1031],{"id":843,"depth":459,"text":844},{"id":867,"depth":459,"text":868},{"id":892,"depth":459,"text":893},{"id":911,"depth":459,"text":912},{"id":933,"depth":459,"text":934},{"id":955,"depth":459,"text":956},{"id":977,"depth":459,"text":978},{"id":1002,"depth":459,"text":1003},{"type":1033,"title":1034,"description":1035},"demo","Bridge Modbus and OPC UA Without Ripping Out Your Infrastructure","FlowFuse connects your legacy Modbus devices to modern SCADA, cloud, and analytics systems using Node-RED at the edge. No hardware replacement. No production downtime. Just the data your modern systems need from the equipment already running your plant.","2026-03-30","OPC UA has every technical advantage. Modbus is still winning. Here's why the replacement hasn't happened and what would actually change that.","\u002Fblog\u002F2026\u002F03\u002Fimages\u002Fopcua-is-not-replacing-modbus-yet.png",{"keywords":1040},"opc ua, modbus, industrial automation, protocol comparison, field devices, scada, mes, industrial protocols, gateway architecture, edge computing, node-red, mqtt, industrial security, certificate management, interoperability","\u002Fblog\u002F2026\u002F03\u002Fwhy-opcua-is-not-replacing-modbus-yet",{"title":800,"description":1037},{"loc":1041},"blog\u002F2026\u002F03\u002Fwhy-opcua-is-not-replacing-modbus-yet","Why your next device will still ship with Modbus, and what OPC UA needs to fix before that changes",[497,1047,498],"opcua","zGoIYxHV6dJg57-_1G-lzhSBh_imALBtvUBEN9IDzsU",{"id":1050,"title":1051,"authors":1052,"body":1053,"cta":1249,"date":1252,"description":1253,"extension":480,"image":1254,"lastUpdated":3,"meta":1255,"navigation":490,"path":1262,"seo":1263,"sitemap":1264,"stem":1265,"subtitle":1266,"tags":1267,"tldr":1268,"video":3,"__hash__":1269},"blog\u002Fblog\u002F2026\u002F02\u002Fmodbus-tcp-vs-modbus-rtu.md","Modbus TCP vs Modbus RTU: Reliability, Latency, and Failure Modes",[10],{"type":12,"value":1054,"toc":1238},[1055,1061,1064,1067,1071,1074,1077,1080,1086,1089,1093,1096,1099,1102,1105,1111,1114,1117,1121,1124,1128,1131,1134,1137,1142,1146,1149,1152,1155,1161,1176,1179,1183,1186,1189,1198,1201,1205,1208,1211,1214,1217,1221,1224,1227,1230,1233],[15,1056,1057,1058,453],{},"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 ",[25,1059,1060],{"href":526},"separate article",[15,1062,1063],{},"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.",[15,1065,1066],{},"That gap is what most people miss. And it is exactly what this post is about.",[31,1068,1070],{"id":1069},"they-are-not-the-same-protocol-in-different-clothes","They Are Not the Same Protocol in Different Clothes",[15,1072,1073],{},"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.",[15,1075,1076],{},"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.",[15,1078,1079],{},"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.",[15,1081,1082],{},[41,1083],{"alt":1084,"src":1085,"title":1084},"Image showing Modbus RTU on RS-485 and Modbus TCP on Ethernet.","\u002Fblog\u002F2026\u002F02\u002Fimages\u002Fmodbus-rtu-and-tcp-physical-layer.png",[15,1087,1088],{},"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.",[31,1090,1092],{"id":1091},"latency-what-the-numbers-actually-mean-on-the-floor","Latency: What the Numbers Actually Mean on the Floor",[15,1094,1095],{},"RTU latency is predictable almost to the microsecond. That sounds like a strength until you realize how slow predictable can be.",[15,1097,1098],{},"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.",[15,1100,1101],{},"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.",[15,1103,1104],{},"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.",[15,1106,1107],{},[41,1108],{"alt":1109,"src":1110,"title":1109},"Chart comparing Modbus RTU polling latency with Modbus TCP network latency","\u002Fblog\u002F2026\u002F02\u002Fimages\u002Fmodbus-rtu-tcp-latency.png",[15,1112,1113],{},"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.",[15,1115,1116],{},"RTU offers better worst-case latency. TCP offers better average latency. In industrial control, worst-case is usually what you design for.",[31,1118,1120],{"id":1119},"failure-modes-what-breaks-how-it-breaks-and-whether-you-will-know","Failure Modes: What Breaks, How It Breaks, and Whether You Will Know",[15,1122,1123],{},"This is where the two protocols diverge most sharply, and where choosing wrong costs the most.",[52,1125,1127],{"id":1126},"rtu-failures-are-loud-and-physical","RTU Failures Are Loud and Physical",[15,1129,1130],{},"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.",[15,1132,1133],{},"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.",[15,1135,1136],{},"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.",[15,1138,1139],{},[84,1140,1141],{},"But at least you know it is down.",[52,1143,1145],{"id":1144},"tcp-failures-are-quiet-and-strange","TCP Failures Are Quiet and Strange",[15,1147,1148],{},"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.",[15,1150,1151],{},"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.",[15,1153,1154],{},"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.",[15,1156,1157],{},[41,1158],{"alt":1159,"src":1160,"title":1159},"Half-open TCP socket failure where the master waits on a connection that never responds.","\u002Fblog\u002F2026\u002F02\u002Fimages\u002Fmodbus-tcp-open-connection-failure.png",[15,1162,1163,1164,1169,1170,1175],{},"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 (",[25,1165,1168],{"href":1166,"rel":1167},"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc793",[63],"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 (",[25,1171,1174],{"href":1172,"rel":1173},"https:\u002F\u002Fliterature.rockwellautomation.com\u002Fidc\u002Fgroups\u002Fliterature\u002Fdocuments\u002Fat\u002Fenet-at003_-en-p.pdf",[63],"Rockwell Automation, ENET-AT003",").",[15,1177,1178],{},"RTU tends to fall over cleanly. TCP tends to degrade quietly. Degraded is harder to catch than broken.",[52,1180,1182],{"id":1181},"tcp-introduces-a-failure-mode-that-rtu-never-had-security","TCP Introduces a Failure Mode That RTU Never Had: Security",[15,1184,1185],{},"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.",[15,1187,1188],{},"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.",[15,1190,1191,1192,1197],{},"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 ",[25,1193,1196],{"href":1194,"rel":1195},"https:\u002F\u002Fwww.dragos.com\u002Fblog\u002Fprotect-against-frostygoop-ics-malware-targeting-operational-technology\u002F",[63],"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.",[15,1199,1200],{},"RTU is not inherently secure either, but attacking it requires being physically present on the wire. TCP removes that requirement entirely.",[31,1202,1204],{"id":1203},"choosing-between-them","Choosing Between Them",[15,1206,1207],{},"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.",[15,1209,1210],{},"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.",[15,1212,1213],{},"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.",[15,1215,1216],{},"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.",[31,1218,1220],{"id":1219},"what-to-actually-do-differently-based-on-this","What to Actually Do Differently Based on This",[15,1222,1223],{},"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.",[15,1225,1226],{},"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.",[15,1228,1229],{},"If you are maintaining a hybrid gateway architecture, resist the urge to rationalize it away. It is doing work.",[15,1231,1232],{},"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.",[15,1234,1235,1236,453],{},"For a practical guide to connecting Modbus PLCs, alongside OPC UA, EtherNet\u002FIP, and Siemens S7, to MQTT, cloud, and enterprise systems, see the ",[25,1237,452],{"href":451},{"title":455,"searchDepth":456,"depth":456,"links":1239},[1240,1241,1242,1247,1248],{"id":1069,"depth":459,"text":1070},{"id":1091,"depth":459,"text":1092},{"id":1119,"depth":459,"text":1120,"children":1243},[1244,1245,1246],{"id":1126,"depth":462,"text":1127},{"id":1144,"depth":462,"text":1145},{"id":1181,"depth":462,"text":1182},{"id":1203,"depth":459,"text":1204},{"id":1219,"depth":459,"text":1220},{"type":475,"title":1250,"description":1251},"Stop Debugging Modbus at 2 AM","FlowFuse supports both Modbus RTU and TCP across the full OT\u002FIT stack, with the monitoring, logging, and fleet management to catch problems before they take down the line.","2026-02-20","A practical engineering guide to choosing between Modbus RTU and Modbus TCP, covering real latency numbers, failure modes that hide in plain sight, and how each protocol behaves when things go wrong.","\u002Fblog\u002F2026\u002F02\u002Fimages\u002Fmodbus-rtu-vs-tcp.png",{"excerpt":1256},{"type":12,"value":1257},[1258],[15,1259,1057,1260,453],{},[25,1261,1060],{"href":526},"\u002Fblog\u002F2026\u002F02\u002Fmodbus-tcp-vs-modbus-rtu",{"title":1051,"description":1253},{"loc":1262},"blog\u002F2026\u002F02\u002Fmodbus-tcp-vs-modbus-rtu","What nobody tells you until the line goes down",[497,498],"Modbus RTU and Modbus TCP share the same data model but make entirely different assumptions about the network, failure modes, and latency. RTU failures are loud and physical while TCP failures tend to degrade silently, and TCP's exposure on Ethernet introduces security risks that serial never had choosing between them requires understanding these tradeoffs, not just swapping protocols.","XIIHl1KrrcTZVqWpoJqRldTPamtbEpjNNYDqb7O_xKs",{"id":1271,"title":1272,"authors":1273,"body":1274,"cta":1521,"date":1524,"description":1525,"extension":480,"image":1526,"lastUpdated":1527,"meta":1528,"navigation":490,"path":1534,"seo":1535,"sitemap":1536,"stem":1537,"subtitle":1538,"tags":1539,"tldr":1540,"video":3,"__hash__":1541},"blog\u002Fblog\u002F2026\u002F01\u002Fwhy-modbus-still-exist.md","Why Modbus Refuses to Die",[10],{"type":12,"value":1275,"toc":1513},[1276,1279,1282,1285,1289,1292,1312,1315,1323,1327,1330,1333,1336,1339,1343,1346,1349,1352,1355,1358,1362,1365,1371,1377,1383,1389,1395,1401,1407,1410,1414,1417,1420,1423,1426,1434,1437,1440,1462,1465,1468,1476,1479,1482,1485,1488,1491,1495,1498,1501,1504,1507],[15,1277,1278],{},"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\u002FIP, MQTT, Profinet: modern protocols with semantic modeling, encryption, and real-time capabilities arrived backed by billions in vendor investment and industry standardization efforts.",[15,1280,1281],{},"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.",[15,1283,1284],{},"What's keeping a protocol from 1979 alive when everything about industrial automation has changed?",[31,1286,1288],{"id":1287},"the-installed-base-reality","The Installed Base Reality",[15,1290,1291],{},"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?",[15,1293,1294,1295,1300,1301,337,1306,1311],{},"The equipment wasn't designed for short lifecycles. ",[25,1296,1299],{"href":1297,"rel":1298},"https:\u002F\u002Fwww.indmall.in\u002Ffaq\u002Fhow-long-do-plc-components-typically-last\u002F",[63],"Industrial PLCs typically last around 10 to 20 years"," depending on environment and maintenance. Process industry equipment like pumps, transmitters, and valves often ",[25,1302,1305],{"href":1303,"rel":1304},"https:\u002F\u002Fwww.automationworld.com\u002Fproducts\u002Fcontrol\u002Farticle\u002F13311314\u002Fplc-lifecycle-management",[63],"hits 20-30 years before replacement becomes necessary",[25,1307,1310],{"href":1308,"rel":1309},"https:\u002F\u002Fwww.manufacturing.net\u002Foperations\u002Farticle\u002F13057130\u002Fis-the-united-states-ready-to-take-manufacturing-back",[63],"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.",[15,1313,1314],{},"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.",[15,1316,1317,1318,1322],{},"The numbers show how big this problem is. ",[25,1319,1321],{"href":858,"rel":1320},[63],"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.",[31,1324,1326],{"id":1325},"it-costs-almost-nothing","It Costs Almost Nothing",[15,1328,1329],{},"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.",[15,1331,1332],{},"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.",[15,1334,1335],{},"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.",[15,1337,1338],{},"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.",[31,1340,1342],{"id":1341},"the-vendor-neutral-advantage","The Vendor-Neutral Advantage",[15,1344,1345],{},"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.",[15,1347,1348],{},"Industrial automation is full of protocol wars where vendors push their preferred standards. Rockwell champions EtherNet\u002FIP. 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.",[15,1350,1351],{},"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.",[15,1353,1354],{},"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.",[15,1356,1357],{},"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.",[31,1359,1361],{"id":1360},"the-technical-case-for-modbus","The Technical Case for Modbus",[15,1363,1364],{},"Beyond the strategic and economic reasons, Modbus delivers real technical advantages that matter when you're building and maintaining industrial systems:",[15,1366,1367,1370],{},[84,1368,1369],{},"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.",[15,1372,1373,1376],{},[84,1374,1375],{},"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.",[15,1378,1379,1382],{},[84,1380,1381],{},"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.",[15,1384,1385,1388],{},[84,1386,1387],{},"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.",[15,1390,1391,1394],{},[84,1392,1393],{},"Universal compatibility."," Same protocol on RS-485, RS-232, TCP\u002FIP, 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.",[15,1396,1397,1400],{},[84,1398,1399],{},"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.",[15,1402,1403,1406],{},[84,1404,1405],{},"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.",[15,1408,1409],{},"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.",[31,1411,1413],{"id":1412},"when-modern-protocols-actually-win","When Modern Protocols Actually Win",[15,1415,1416],{},"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.",[15,1418,1419],{},"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.",[15,1421,1422],{},"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.",[15,1424,1425],{},"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.",[15,1427,1428,1429,1433],{},"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 ",[25,1430,1432],{"href":1431},"\u002Fblog\u002F2025\u002F11\u002Fbuilding-hmi-for-equipment-control\u002F","HMI"," experiences, OPC UA's semantic layer isn't optional overhead: it's the foundation that makes complexity manageable.",[15,1435,1436],{},"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.",[15,1438,1439],{},"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.",[15,1441,1442,1446,1447,1451,1452,1456,1457,1461],{},[25,1443,1445],{"href":1444},"\u002Fblog\u002F2025\u002F07\u002Freading-and-writing-plc-data-using-opc-ua\u002F","OPC UA"," provides TLS encryption, certificate-based authentication, role-based access control, and detailed audit logging. ",[25,1448,1450],{"href":1449},"\u002Fblog\u002F2024\u002F06\u002Fhow-to-use-mqtt-in-node-red\u002F","MQTT"," with ",[25,1453,1455],{"href":1454},"\u002Fblog\u002F2024\u002F08\u002Fusing-mqtt-sparkplugb-with-node-red\u002F","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 ",[25,1458,1460],{"href":1459},"\u002Fnode-red\u002Fprotocol\u002Fmodbus\u002F","Modbus",". The protocol has no security model to extend.",[15,1463,1464],{},"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.",[15,1466,1467],{},"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.",[15,1469,1470,1471,1475],{},"MQTT's publish-subscribe model eliminates polling overhead entirely. Profinet and ",[25,1472,1474],{"href":1473},"\u002Fblog\u002F2025\u002F10\u002Fusing-ethernet-ip-with-flowfuse\u002F","EtherNet\u002FIP"," use producer-consumer architectures that scale better. When data volume grows beyond simple polling scenarios, Modbus becomes the bottleneck.",[15,1477,1478],{},"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.",[15,1480,1481],{},"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.",[15,1483,1484],{},"Modbus works great until you need asset monitoring, predictive maintenance, cloud integration, or advanced analytics. Then you're ripping out infrastructure you just installed.",[15,1486,1487],{},"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.",[15,1489,1490],{},"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.",[31,1492,1494],{"id":1493},"the-hybrid-reality","The Hybrid Reality",[15,1496,1497],{},"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.",[15,1499,1500],{},"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.",[15,1502,1503],{},"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.",[15,1505,1506],{},"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.",[15,1508,1509,1510,453],{},"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. See ",[25,1511,1512],{"href":451},"how FlowFuse connects Modbus PLCs, and every other PLC brand, to MQTT, cloud, and enterprise systems",{"title":455,"searchDepth":456,"depth":456,"links":1514},[1515,1516,1517,1518,1519,1520],{"id":1287,"depth":459,"text":1288},{"id":1325,"depth":459,"text":1326},{"id":1341,"depth":459,"text":1342},{"id":1360,"depth":459,"text":1361},{"id":1412,"depth":459,"text":1413},{"id":1493,"depth":459,"text":1494},{"type":1033,"title":1522,"description":1523},"Modernize Without the Rip and Replace","FlowFuse connects your legacy Modbus devices to modern systems without replacing what already works. See how teams are bridging old and new infrastructure on the same platform.","2026-01-26","Learn why Modbus, a 47-year-old protocol with zero security, still dominates industrial automation despite billions invested in modern alternatives","\u002Fblog\u002F2026\u002F01\u002Fimages\u002Fwhy-modbus-wont-dia.png","2026-06-17",{"keywords":1529,"excerpt":1530},"Modbus, industrial automation, PLC, OPC UA, EtherNet\u002FIP, MQTT, legacy systems, industrial protocols, factory automation, FlowFuse",{"type":12,"value":1531},[1532],[15,1533,1278],{},"\u002Fblog\u002F2026\u002F01\u002Fwhy-modbus-still-exist",{"title":1272,"description":1525},{"loc":1534},"blog\u002F2026\u002F01\u002Fwhy-modbus-still-exist","Why your factory's newest equipment still speaks a 47-year-old language",[497,498],"Modbus persists in 2026 not because it is technically superior but because it solves real problems with minimal friction. It is open and vendor-neutral, costs only a few dollars to implement with zero licensing, and is simple, reliable, and universally compatible across decades of installed equipment. Its weaknesses (no security, no semantic modeling, and poor scaling for motion control or high data volumes) are increasingly addressed through a hybrid approach where edge gateways bridge legacy Modbus to secure modern protocols like OPC UA and MQTT.","hYg6ixoflLDULBozpe86yM5CWc0B3QwWJSP-ISGJM2U",{"id":1543,"title":1544,"authors":1545,"body":1546,"cta":3,"date":2051,"description":2052,"extension":480,"image":2053,"lastUpdated":1527,"meta":2054,"navigation":490,"path":2060,"seo":2061,"sitemap":2062,"stem":2063,"subtitle":2064,"tags":2065,"tldr":2068,"video":3,"__hash__":2069},"blog\u002Fblog\u002F2025\u002F10\u002Fplc-to-mqtt-using-flowfuse.md","How to Connect Any PLC to MQTT in Under an Hour",[10],{"type":12,"value":1547,"toc":2041},[1548,1551,1554,1557,1561,1564,1567,1570,1573,1576,1579,1583,1586,1600,1605,1608,1615,1618,1622,1625,1628,1631,1673,1684,1688,1694,1697,1708,1715,1718,1721,1725,1728,1733,1736,1739,1746,1753,1758,1767,1772,1775,1785,1790,1793,1800,1804,1807,1810,1813,1816,1824,1829,1845,1854,1857,1863,1868,1871,1874,1881,1884,1910,1915,1933,1936,1948,1956,1973,1981,1988,1996,2004,2008,2011,2014,2017,2020,2023,2027,2036],[15,1549,1550],{},"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.",[15,1552,1553],{},"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.",[15,1555,1556],{},"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.",[31,1558,1560],{"id":1559},"why-plc-to-cloud-gets-so-complicated","Why PLC-to-Cloud Gets So Complicated",[15,1562,1563],{},"Before diving into the solution, it's worth understanding why this is so difficult.",[15,1565,1566],{},"First, there's the proprietary protocols. Factory floors have PLCs from different manufacturers, each speaking their own language: Modbus, OPC-UA, Ethernet\u002FIP, Profinet, FINS, etc. Getting data out means dealing with all of them at once, maintaining multiple drivers and troubleshooting different failure modes.",[15,1568,1569],{},"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.",[15,1571,1572],{},"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.",[15,1574,1575],{},"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.",[15,1577,1578],{},"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.",[31,1580,1582],{"id":1581},"prerequisites","Prerequisites",[15,1584,1585],{},"Before you start, make sure you have the following:",[567,1587,1588,1591],{},[570,1589,1590],{},"A properly configured and fully operational PLCs, located on the same network as the edge device that will be reading its data.",[570,1592,1593,1594,1599],{},"A running FlowFuse instance on your edge device. If you do not have an account, ",[25,1595,1598],{"href":1596,"rel":1597},"https:\u002F\u002Fflowfuse.com\u002Fblog\u002F2025\u002F09\u002Finstalling-node-red\u002F",[63],"sign up for a free trial"," and set up your instance following the instructions in this article.",[1601,1602,1604],"h1",{"id":1603},"getting-started","Getting Started",[15,1606,1607],{},"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.",[1609,1610],"lite-youtube",{"videoid":1611,"params":1612,"style":1613,"title":1614},"vptAoDR78Cc","rel=0","margin-top: 20px; margin-bottom: 20px; width: 100%; height: 480px;","YouTube video player",[15,1616,1617],{},"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.",[31,1619,1621],{"id":1620},"step-1-extract-data-from-your-plc","Step 1: Extract Data from Your PLC",[15,1623,1624],{},"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\u002FIP, 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.",[15,1626,1627],{},"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.",[15,1629,1630],{},"The Node-RED ecosystem that powers FlowFuse offers comprehensive protocol support. You'll find nodes available for every major PLC manufacturer, including:",[567,1632,1633,1640,1646,1652,1658,1664,1670],{},[570,1634,1635,1639],{},[1636,1637,1638],"code",{},"node-red-contrib-modbus"," – Modbus RTU\u002FTCP PLCs and devices",[570,1641,1642,1645],{},[1636,1643,1644],{},"node-red-contrib-s7"," – Siemens S7-300\u002F400\u002F1200\u002F1500",[570,1647,1648,1651],{},[1636,1649,1650],{},"node-red-contrib-opcua"," – OPC UA servers",[570,1653,1654,1657],{},[1636,1655,1656],{},"node-red-contrib-cip-ethernet-ip"," – Allen-Bradley PLCs",[570,1659,1660,1663],{},[1636,1661,1662],{},"node-red-contrib-mcprotocol"," – Mitsubishi PLCs",[570,1665,1666,1669],{},[1636,1667,1668],{},"node-red-contrib-omron-fins"," – Omron PLCs",[570,1671,1672],{},"and many more",[15,1674,1675,1676,1679,1680,1683],{},"Adding a protocol node to your FlowFuse instance takes just a few clicks. Open the palette manager from the hamburger menu, select ",[84,1677,1678],{},"Manage palette",", go to the ",[84,1681,1682],{},"Install"," tab, and search for the node you need.",[31,1685,1687],{"id":1686},"convincing-the-it-team","Convincing the IT Team",[15,1689,1690,1691,453],{},"When talking to people in the IIoT community, one recurring challenge always comes up, ",[84,1692,1693],{},"convincing the IT team",[15,1695,1696],{},"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.",[15,1698,1699,1700,1703,1704,1707],{},"FlowFuse solves this with an ",[84,1701,1702],{},"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 ",[84,1705,1706],{},"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.",[15,1709,1710,1711,1714],{},"From a security standpoint, this changes everything. Your firewall configuration does not change.",[1712,1713],"br",{},"\nNo new inbound rules. No DMZ setup. No VPN tunnels to maintain.",[15,1716,1717],{},"The device agent behaves like any other business application making secure outbound HTTPS requests, something your network already allows.",[15,1719,1720],{},"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.",[31,1722,1724],{"id":1723},"step-2-transform-and-structure-your-data","Step 2: Transform and Structure Your Data",[15,1726,1727],{},"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.",[15,1729,1730],{},[84,1731,1732],{},"Visual Transformation with Change Nodes and JSONata",[15,1734,1735],{},"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.",[15,1737,1738],{},"Plant engineers can work directly with these visual tools, no programming required.",[15,1740,1741,1742,1745],{},"For example, suppose you are receiving a pressure sensor value as ",[1636,1743,1744],{},"msg.payload"," but it lacks context.",[15,1747,1748,1749,1752],{},"You can use a ",[84,1750,1751],{},"Change"," node to:",[567,1754,1755],{},[570,1756,1757],{},"Add contextual information such as the machine ID, facility, or sensor location, unit",[15,1759,1760,1764],{},[41,1761],{"alt":1762,"dataZoomable":455,"src":1763},"Change node adding context to data","\u002Fblog\u002F2025\u002F10\u002Fimages\u002Fchange-node-adding-context.png",[46,1765,1766],{},"Change node used to convert temperature and add machine context",[15,1768,1769],{},[84,1770,1771],{},"Function Nodes for Custom Logic",[15,1773,1774],{},"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.",[15,1776,1777],{},[46,1778,1779,1780,1784],{},"Tip: Use the ",[25,1781,1783],{"href":1782},"\u002Fblog\u002F2025\u002F07\u002Fflowfuse-ai-assistant-better-node-red-manufacturing\u002F","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.",[15,1786,1787],{},[84,1788,1789],{},"Pre-built Community Nodes",[15,1791,1792],{},"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.",[15,1794,1795,1796,1799],{},"For example, a popular node I'm using in my demo for parsing and transforming data is ",[1636,1797,1798],{},"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.",[31,1801,1803],{"id":1802},"step-3-set-up-mqtt-with-flowfuse","Step 3: Set Up MQTT with FlowFuse",[15,1805,1806],{},"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.",[15,1808,1809],{},"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.",[15,1811,1812],{},"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.",[15,1814,1815],{},"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.",[15,1817,1818,1822],{},[41,1819],{"alt":1820,"dataZoomable":455,"src":1821},"Enabling FlowFuse MQTT Broker","\u002Fblog\u002F2025\u002F10\u002Fimages\u002Fset-broker.png",[46,1823,1820],{},[15,1825,1826],{},[84,1827,1828],{},"Configure Publishing",[1830,1831,1832,1839,1842],"ol",{},[570,1833,1834,1835,1838],{},"Drag a ",[84,1836,1837],{},"FlowFuse MQTT Out"," node onto your canvas.",[570,1840,1841],{},"Open the node configuration. It will automatically pick up its configuration.",[570,1843,1844],{},"Set the topic following ISA-95 hierarchy:",[1846,1847,1852],"pre",{"className":1848,"code":1850,"language":1851},[1849],"language-text","company\u002Fsite\u002Farea\u002Fline\u002Fcell\u002Fdevice\u002Fmeasurement\n","text",[1636,1853,1850],{"__ignoreMap":455},[15,1855,1856],{},"For Example:",[1846,1858,1861],{"className":1859,"code":1860,"language":1851},[1849],"acme\u002Fplant-a\u002Fassembly\u002Fline1\u002Fpress-1\u002Fpressure01\u002Fbar\n",[1636,1862,1860],{"__ignoreMap":455},[15,1864,1865],{},[84,1866,1867],{},"Why ISA-95 for MQTT Topics",[15,1869,1870],{},"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.",[15,1872,1873],{},"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.",[15,1875,1876,1877,1880],{},"ISA-95 makes this possible because it maps to how factories actually operate. ",[1636,1878,1879],{},"company\u002Fsite\u002Farea\u002Fline\u002Fcell"," 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.",[15,1882,1883],{},"This enables powerful wildcard subscriptions:",[567,1885,1886,1892,1898,1904],{},[570,1887,1888,1891],{},[1636,1889,1890],{},"acme\u002F#"," - all company data",[570,1893,1894,1897],{},[1636,1895,1896],{},"acme\u002Fchicago\u002F#"," - single site",[570,1899,1900,1903],{},[1636,1901,1902],{},"+\u002F+\u002Fassembly\u002F#"," - assembly operations everywhere",[570,1905,1906,1909],{},[1636,1907,1908],{},"acme\u002Fchicago\u002Fassembly\u002Fline2\u002F#"," - one production line",[15,1911,1912],{},[46,1913,1914],{},"Note: Use lowercase with hyphens for multi-word names.",[1830,1916,1917,1927],{"start":456},[570,1918,1919,1920,1923,1924,453],{},"Set ",[84,1921,1922],{},"QoS"," to ",[84,1925,1926],{},"1",[570,1928,1929,1930,453],{},"Click ",[84,1931,1932],{},"Deploy",[15,1934,1935],{},"After deploying the flow, the MQTT client for your device will be automatically created. To configure access:",[1830,1937,1939,1942],{"start":1938},6,[570,1940,1941],{},"Double-click the MQTT Out node.",[570,1943,1929,1944,1947],{},[84,1945,1946],{},"Configure Access Control",". You will be redirected to the platform's broker client management section, filtered to show the client created for this instance.",[15,1949,1950,1954],{},[41,1951],{"alt":1952,"dataZoomable":455,"src":1953},"Configure MQTT Client Access Control","\u002Fblog\u002F2025\u002F10\u002Fimages\u002Fconfigure-access-control.png",[46,1955,1952],{},[1830,1957,1959],{"start":1958},8,[570,1960,1961,1962,1965,1966,1969,1970,453],{},"Click the client ",[84,1963,1964],{},"edit",", select ",[84,1967,1968],{},"Publish",", and then click ",[84,1971,1972],{},"Confirm",[15,1974,1975,1979],{},[41,1976],{"alt":1977,"dataZoomable":455,"src":1978},"Configuring Client Access Control","\u002Fblog\u002F2025\u002F10\u002Fimages\u002Fclient-access-control.jpg",[46,1980,1952],{},[15,1982,1983,1984,1987],{},"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 ",[84,1985,1986],{},"Open Schema",", you can view the auto-generated schema document created by FlowFuse.",[15,1989,1990,1994],{},[41,1991],{"alt":1992,"dataZoomable":455,"src":1993},"FlowFuse Topic Hierarchy View","\u002Fblog\u002F2025\u002F10\u002Fimages\u002Fmqtt-topic-hierarchy.png",[46,1995,1992],{},[15,1997,1998,2002],{},[41,1999],{"alt":2000,"dataZoomable":455,"src":2001},"Topic schema auto-generated by FlowFuse","\u002Fblog\u002F2025\u002F10\u002Fimages\u002Fmqtt-topic-schema-document.png",[46,2003,2000],{},[31,2005,2007],{"id":2006},"bridging-the-expertise-gap-and-cutting-costs","Bridging the Expertise Gap and Cutting Costs",[15,2009,2010],{},"Now let's talk about the remaining problems: the expertise gap and cost. FlowFuse solves both by changing how the work gets done.",[15,2012,2013],{},"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.",[15,2015,2016],{},"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.",[15,2018,2019],{},"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.",[15,2021,2022],{},"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.",[31,2024,2026],{"id":2025},"get-started","Get Started",[15,2028,2029,2030,2035],{},"Connect your first PLC today. ",[25,2031,2034],{"href":2032,"rel":2033},"https:\u002F\u002Fapp.flowfuse.com\u002F",[63],"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.",[15,2037,2038,2039,453],{},"MQTT is one of several ways FlowFuse connects PLCs to the modern industrial stack. For a full view of supported protocols, OPC UA, EtherNet\u002FIP, Siemens S7, Modbus, and more, see the ",[25,2040,452],{"href":451},{"title":455,"searchDepth":456,"depth":456,"links":2042},[2043,2044,2045,2046,2047,2048,2049,2050],{"id":1559,"depth":459,"text":1560},{"id":1581,"depth":459,"text":1582},{"id":1620,"depth":459,"text":1621},{"id":1686,"depth":459,"text":1687},{"id":1723,"depth":459,"text":1724},{"id":1802,"depth":459,"text":1803},{"id":2006,"depth":459,"text":2007},{"id":2025,"depth":459,"text":2026},"2025-10-27","Learn how to extract data from Siemens, Allen-Bradley, Omron, Mitsubishi, OPC UA, and Modbus, transform it, and publish to MQTT using FlowFuse, without expensive gateways or consultants.","\u002Fblog\u002F2025\u002F10\u002Fimages\u002Fplc-to-mqtt.png",{"keywords":2055,"excerpt":2056},"MQTT, PLC, Siemens, S7, Allen-Bradley, EtherNet\u002FIP, Omron, FINS, Mitsubishi, MC Protocol, Modbus, Modbus-RTU, Modbus-TCP, OPC-UA, FlowFuse, Node-RED, Industrial IoT, IIoT",{"type":12,"value":2057},[2058],[15,2059,1550],{},"\u002Fblog\u002F2025\u002F10\u002Fplc-to-mqtt-using-flowfuse",{"title":1544,"description":2052},{"loc":2060},"blog\u002F2025\u002F10\u002Fplc-to-mqtt-using-flowfuse","Connect any PLC to MQTT without the typical complexity, costs, and expertise requirements",[497,498,2066,2067],"mqtt","plc","This tutorial shows how to publish PLC data to MQTT using FlowFuse and Node-RED without expensive gateways or consultants. You extract data from any PLC protocol (Modbus, OPC UA, EtherNet\u002FIP, Siemens S7, and more) using pre-built connectors, transform and contextualize it into consistent JSON with Change, Function, or community nodes, then publish it to the built-in FlowFuse MQTT broker using an ISA-95 topic hierarchy with proper access controls. FlowFuse's edge-first architecture keeps firewalls closed to inbound traffic, letting plant engineers ship production flows in under an hour.","iXlNoqWxawYlRLfLHSUTlUMBAtOb9J8uyDRM0dnYmlI",{"id":2071,"title":2072,"authors":2073,"body":2074,"cta":3,"date":2780,"description":2781,"extension":480,"image":2782,"lastUpdated":3,"meta":2783,"navigation":490,"path":2789,"seo":2790,"sitemap":2791,"stem":2792,"subtitle":2793,"tags":2794,"tldr":2795,"video":3,"__hash__":2796},"blog\u002Fblog\u002F2025\u002F09\u002Fusing-modbus-with-flowfuse.md","Modbus RTU (RS485\u002FRS422\u002FRS232) Communications with FlowFuse",[10],{"type":12,"value":2075,"toc":2766},[2076,2079,2082,2086,2093,2096,2100,2103,2129,2135,2139,2142,2162,2172,2179,2181,2184,2186,2189,2238,2242,2245,2274,2282,2348,2356,2365,2369,2376,2379,2511,2527,2531,2538,2563,2574,2579,2657,2660,2671,2681,2685,2688,2720,2724,2731,2748,2755,2762],[15,2077,2078],{},"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).",[15,2080,2081],{},"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.",[31,2083,2085],{"id":2084},"understanding-modbus-rtu-basics","Understanding Modbus RTU Basics",[15,2087,2088,2089,2092],{},"Modbus RTU operates on a ",[84,2090,2091],{},"master–slave system",". Unlike its TCP counterpart, it runs over serial connections (RS485\u002FRS422\u002FRS232), 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.",[15,2094,2095],{},"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.",[52,2097,2099],{"id":2098},"device-data-types","Device Data Types",[15,2101,2102],{},"Devices organize data into four main types, each with a specific purpose:",[567,2104,2105,2111,2117,2123],{},[570,2106,2107,2110],{},[84,2108,2109],{},"Coils (Digital Outputs)"," – Remote switches you can turn on\u002Foff from FlowFuse, used for motors, pumps, relays, or alarms.",[570,2112,2113,2116],{},[84,2114,2115],{},"Discrete Inputs (Digital Inputs)"," – Read-only status points that indicate the state of buttons, doors, or alarms.",[570,2118,2119,2122],{},[84,2120,2121],{},"Input Registers (Analog Inputs)"," – Read-only values representing measurements such as temperature, pressure, or flow.",[570,2124,2125,2128],{},[84,2126,2127],{},"Holding Registers (Analog Outputs\u002FSettings)"," – Read\u002Fwrite values for setpoints, timers, and configuration parameters.",[15,2130,2131,2134],{},[84,2132,2133],{},"Note:"," Coils and discrete inputs are single-bit (ON\u002FOFF), while registers store 16-bit values that may require scaling depending on the device.",[52,2136,2138],{"id":2137},"register-addressing","Register Addressing",[15,2140,2141],{},"Addressing can be confusing because manufacturers document it differently:",[567,2143,2144,2150,2156],{},[570,2145,2146,2149],{},[84,2147,2148],{},"Zero-based"," – Modbus standard (first register = 0).",[570,2151,2152,2155],{},[84,2153,2154],{},"One-based"," – Some manuals start counting at 1 (subtract 1 in FlowFuse).",[570,2157,2158,2161],{},[84,2159,2160],{},"Offset-based"," – Registers like 40001 or 30001 require subtracting the base number to get the actual address.",[15,2163,2164,2167,2168,2171],{},[84,2165,2166],{},"Example:"," If a manual shows “Temperature = 40001,” FlowFuse should use address ",[84,2169,2170],{},"0",". Always refer to the device’s “Register Map” for clarity.",[15,2173,2174,2175,2178],{},"By understanding the ",[84,2176,2177],{},"master-slave control, data types, and addressing",", you can reliably communicate with your devices and make the most of Modbus RTU in FlowFuse.",[31,2180,1604],{"id":1603},[15,2182,2183],{},"Let’s start by setting up the basics before connecting Modbus RTU devices to FlowFuse.",[52,2185,1582],{"id":1581},[15,2187,2188],{},"Before diving in, make sure you have the following ready:",[567,2190,2191,2202,2210,2216],{},[570,2192,2193,2196,2197,2201],{},[84,2194,2195],{},"Node-RED instance"," – A running Node-RED instance. The quickest way to get one ready for production is with FlowFuse. Simply [sign up]({% include \"sign-up-url.njk\" %}) and ",[25,2198,2200],{"href":2199},"\u002Fblog\u002F2025\u002F09\u002Finstalling-node-red\u002F","create and set up a remote instance",", and you’ll have a managed Node-RED environment running in minutes.",[570,2203,2204,2207,2208,1175],{},[84,2205,2206],{},"Node-RED Modbus nodes"," – Installable via the Palette Manager (",[1636,2209,1638],{},[570,2211,2212,2215],{},[84,2213,2214],{},"Modbus-enabled device"," – Such as a sensor, PLC, or meter, along with its register map documentation.",[570,2217,2218,2221,2222,2225,2226,2229,2230,2233,2234,2237],{},[84,2219,2220],{},"Serial interface"," – For example, a USB-to-RS485 converter to physically connect your Modbus devices. Connect the ",[84,2223,2224],{},"A (+)"," and ",[84,2227,2228],{},"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., ",[1636,2231,2232],{},"\u002Fdev\u002FttyUSB0"," on Linux or ",[1636,2235,2236],{},"COM1"," on Windows).",[31,2239,2241],{"id":2240},"reading-data","Reading Data",[15,2243,2244],{},"Reading data from Modbus slaves in FlowFuse is straightforward. The process is the same regardless of which data type you want to read.",[1830,2246,2247],{},[570,2248,2249,2250,2253,2254,2257,2258,2261,2262,2265,2266,2269,2270,2273],{},"Drag the ",[84,2251,2252],{},"Modbus Read"," node onto the FlowFuse canvas. Double-click it to open the configuration. Enter the ",[84,2255,2256],{},"Unit ID"," (slave address), select the ",[84,2259,2260],{},"data type"," you want to read, specify the ",[84,2263,2264],{},"starting address",", set the ",[84,2267,2268],{},"quantity"," of values to read, and define the ",[84,2271,2272],{},"poll rate"," (how often data should be read).",[15,2275,2276,2280],{},[41,2277],{"alt":2278,"dataZoomable":455,"src":2279},"Modbus Read node configured to read data from a slave device.","\u002Fblog\u002F2025\u002F09\u002Fimages\u002Fmodbus-read.png",[46,2281,2278],{},[1830,2283,2284,2295],{"start":459},[570,2285,2286,2287,2290,2291,2294],{},"Click the ",[84,2288,2289],{},"+"," icon next to the ",[46,2292,2293],{},"Server"," field to add Modbus connection details.",[570,2296,2297,2298,2345,2347],{},"In the server configuration window:",[567,2299,2300,2308,2320],{},[570,2301,1919,2302,1923,2305,453],{},[84,2303,2304],{},"Type",[46,2306,2307],{},"Serial",[570,2309,2310,2311,2314,2315,2233,2317,2319],{},"In the ",[84,2312,2313],{},"Serial Port"," field, use the dropdown or search option to see all available ports (e.g., ",[1636,2316,2232],{},[1636,2318,2236],{}," on Windows). Select the port to which your Modbus device is connected.",[570,2321,2322,2323],{},"Configure the communication settings to match your device:",[567,2324,2325,2330,2335,2340],{},[570,2326,2327],{},[84,2328,2329],{},"Baud Rate",[570,2331,2332],{},[84,2333,2334],{},"Data Bits",[570,2336,2337],{},[84,2338,2339],{},"Stop Bits",[570,2341,2342],{},[84,2343,2344],{},"Parity",[1712,2346],{},"These values must match exactly with the Modbus device’s configuration; otherwise, the communication will fail.",[15,2349,2350,2354],{},[41,2351],{"alt":2352,"dataZoomable":455,"src":2353},"Serial port and communication settings for the Modbus device.","\u002Fblog\u002F2025\u002F09\u002Fimages\u002Fmodbus-configuration.png",[46,2355,2352],{},[1830,2357,2358],{"start":456},[570,2359,2360,2361,2364],{},"Connect the Modbus Read node to a ",[84,2362,2363],{},"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.",[31,2366,2368],{"id":2367},"writing-data","Writing Data",[15,2370,2371,2372,2375],{},"Modbus RTU allows you to ",[84,2373,2374],{},"write data back to devices",", enabling control of motors, relays, setpoints, and other outputs directly from FlowFuse.",[15,2377,2378],{},"Follow these steps to configure and test writing:",[1830,2380,2381,2387,2457,2505],{},[570,2382,2249,2383,2386],{},[84,2384,2385],{},"Modbus Write"," node onto the canvas. This node will send data to your Modbus device.",[570,2388,2389,2390,2441,2443,2447,2449,2451,2455],{},"Double-click the node and set:",[567,2391,2392,2397,2429,2435],{},[570,2393,2394,2396],{},[84,2395,2256],{}," – the slave address of your device.",[570,2398,2399,2402,2403],{},[84,2400,2401],{},"Data type"," – choose one of:",[567,2404,2405,2411,2417,2423],{},[570,2406,2407,2410],{},[46,2408,2409],{},"Force Single Coil"," – write one digital output.",[570,2412,2413,2416],{},[46,2414,2415],{},"Force Multiple Coils"," – write several digital outputs at once.",[570,2418,2419,2422],{},[46,2420,2421],{},"Preset Single Register"," – write one analog\u002Fconfig value.",[570,2424,2425,2428],{},[46,2426,2427],{},"Force Multiple Registers"," – write several analog values at once.",[570,2430,2431,2434],{},[84,2432,2433],{},"Address"," – the target coil or register.",[570,2436,2437,2440],{},[84,2438,2439],{},"Quantity"," – only for multiple writes, set the number of values you will send.",[1712,2442],{},[41,2444],{"alt":2445,"dataZoomable":455,"src":2446},"Writing a single coil using the Modbus Write node.","\u002Fblog\u002F2025\u002F09\u002Fimages\u002Fwrite-single-coil.png",[46,2448,2445],{},[1712,2450],{},[41,2452],{"alt":2453,"dataZoomable":455,"src":2454},"Writing multiple coils using the Modbus Write node.","\u002Fblog\u002F2025\u002F09\u002Fimages\u002Fwrite-multi-coils.png",[46,2456,2453],{},[570,2458,2459,2460,2463,2464,2486,2488,2491],{},"Connect an ",[84,2461,2462],{},"Inject"," node to the Modbus Write node to send values:",[567,2465,2466,2480],{},[570,2467,2468,2471,2472,2475,2476,2479],{},[84,2469,2470],{},"Single Coil\u002FRegister:"," send a boolean (",[1636,2473,2474],{},"true","\u002F",[1636,2477,2478],{},"false",") for coils or a number for registers.",[570,2481,2482,2485],{},[84,2483,2484],{},"Multiple Coils\u002FRegisters:"," send an array corresponding to each value.",[1712,2487],{},[84,2489,2490],{},"Examples:",[567,2492,2493,2499],{},[570,2494,2495,2498],{},[1636,2496,2497],{},"[true, false, true]"," → Coils 0, 1, 2",[570,2500,2501,2504],{},[1636,2502,2503],{},"[25, 50, 75]"," → Holding Registers 0, 1, 2",[570,2506,2507,2508,2510],{},"Deploy the flow and press ",[84,2509,2462],{},". The Modbus device should update immediately.",[15,2512,2513,2516,2517,2520,2521,2526],{},[84,2514,2515],{},"Tip:"," Use a ",[84,2518,2519],{},"UI input (slider, switch, or numeric box)"," from the ",[25,2522,2525],{"href":2523,"rel":2524},"https:\u002F\u002Fdashboard.flowfuse.com\u002F",[63],"FlowFuse Dashboard"," instead of an Inject node for real-time control via a web interface.",[31,2528,2530],{"id":2529},"scaling-and-interpreting-values","Scaling and Interpreting Values",[15,2532,2533,2534,2537],{},"Raw Modbus values often don’t make sense until you apply ",[84,2535,2536],{},"scaling factors"," or unit conversions.",[567,2539,2540,2550,2560],{},[570,2541,2542,2543,2546,2547,453],{},"A temperature register might return ",[1636,2544,2545],{},"235",", which actually means ",[84,2548,2549],{},"23.5 °C",[570,2551,2552,2553,2556,2557,453],{},"An energy meter might output ",[1636,2554,2555],{},"12345",", representing ",[84,2558,2559],{},"12.345 kWh",[570,2561,2562],{},"A pressure sensor could use two consecutive registers (32-bit values) that need decoding.",[15,2564,2565,2566,2569,2570,2573],{},"You can handle these conversions with simple ",[84,2567,2568],{},"Function nodes"," or ",[84,2571,2572],{},"Change nodes"," in FlowFuse.",[15,2575,2576],{},[84,2577,2578],{},"Example Function Node:",[1846,2580,2584],{"className":2581,"code":2582,"language":2583,"meta":455,"style":455},"language-javascript shiki shiki-themes material-theme-lighter material-theme material-theme-palenight","\u002F\u002F Convert raw register value to temperature in °C\nlet raw = msg.payload[0];\nmsg.payload = raw \u002F 10;\nreturn msg;\n","javascript",[1636,2585,2586,2595,2626,2647],{"__ignoreMap":455},[2587,2588,2591],"span",{"class":2589,"line":2590},"line",1,[2587,2592,2594],{"class":2593},"sHwdD","\u002F\u002F Convert raw register value to temperature in °C\n",[2587,2596,2597,2601,2605,2609,2612,2614,2617,2620,2623],{"class":2589,"line":459},[2587,2598,2600],{"class":2599},"spNyl","let",[2587,2602,2604],{"class":2603},"sTEyZ"," raw ",[2587,2606,2608],{"class":2607},"sMK4o","=",[2587,2610,2611],{"class":2603}," msg",[2587,2613,453],{"class":2607},[2587,2615,2616],{"class":2603},"payload[",[2587,2618,2170],{"class":2619},"sbssI",[2587,2621,2622],{"class":2603},"]",[2587,2624,2625],{"class":2607},";\n",[2587,2627,2628,2631,2633,2636,2638,2640,2642,2645],{"class":2589,"line":462},[2587,2629,2630],{"class":2603},"msg",[2587,2632,453],{"class":2607},[2587,2634,2635],{"class":2603},"payload ",[2587,2637,2608],{"class":2607},[2587,2639,2604],{"class":2603},[2587,2641,2475],{"class":2607},[2587,2643,2644],{"class":2619}," 10",[2587,2646,2625],{"class":2607},[2587,2648,2649,2653,2655],{"class":2589,"line":456},[2587,2650,2652],{"class":2651},"s7zQu","return",[2587,2654,2611],{"class":2603},[2587,2656,2625],{"class":2607},[15,2658,2659],{},"This takes the raw register, divides it by 10, and gives you a clean, human-readable temperature.",[15,2661,2662,2664,2665,2667,2668,453],{},[84,2663,2515],{}," You do not need to know JavaScript, simply use the ",[84,2666,1783],{},", 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: ",[25,2669,2670],{"href":1782},"FlowFuse Expert for Manufacturing",[15,2672,2673,2676,2677,2680],{},[84,2674,2675],{},"Best Practice:"," Always keep a copy of the device’s ",[84,2678,2679],{},"Register Map documentation"," handy. It tells you which addresses map to which variables, and how to interpret them.",[31,2682,2684],{"id":2683},"troubleshooting-tips","Troubleshooting Tips",[15,2686,2687],{},"If things do not work on the first attempt, avoid frustration. Modbus is straightforward, but even small configuration mismatches can disrupt communication.",[567,2689,2690,2697,2704,2710,2717],{},[570,2691,2692,2693,2696],{},"Verify the ",[84,2694,2695],{},"serial port"," is correct and not already in use.",[570,2698,2699,2700,2703],{},"Double-check ",[84,2701,2702],{},"baud rate, data bits, stop bits, and parity",". Even a single mismatch will block communication.",[570,2705,2706,2707,2709],{},"Ensure the ",[84,2708,2256],{}," matches your device’s slave address.",[570,2711,2712,2713,2716],{},"Keep your wiring neat. For longer cables, use ",[84,2714,2715],{},"termination resistors"," and twisted-pair shielded cables.",[570,2718,2719],{},"Use a Modbus simulator or diagnostic tool to test the setup if the hardware isn’t responding.",[31,2721,2723],{"id":2722},"conclusion","Conclusion",[15,2725,2726,2727,2730],{},"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 ",[84,2728,2729],{},"modern superpowers",":",[567,2732,2733,2736,2739,2742],{},[570,2734,2735],{},"Collect real-time data from sensors and machines.",[570,2737,2738],{},"Control devices directly from a web dashboard.",[570,2740,2741],{},"Combine Modbus with MQTT, REST APIs, or databases to share data across your entire organization.",[570,2743,2744,2745,453],{},"Scale from a single sensor to a ",[84,2746,2747],{},"factory-wide monitoring and control system",[15,2749,2750,2751,2754],{},"The real value comes when you stop treating Modbus as just a communication protocol and start using FlowFuse as the ",[84,2752,2753],{},"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.",[15,2756,2757,2758,2761],{},"Modbus is one of several protocols FlowFuse uses to connect PLCs, see ",[25,2759,2760],{"href":451},"how FlowFuse connects any PLC to MQTT, cloud, and enterprise systems"," for the full picture.",[2763,2764,2765],"style",{},"html pre.shiki code .sHwdD, html code.shiki .sHwdD{--shiki-light:#90A4AE;--shiki-light-font-style:italic;--shiki-default:#546E7A;--shiki-default-font-style:italic;--shiki-dark:#676E95;--shiki-dark-font-style:italic}html pre.shiki code .spNyl, html code.shiki .spNyl{--shiki-light:#9C3EDA;--shiki-default:#C792EA;--shiki-dark:#C792EA}html pre.shiki code .sTEyZ, html code.shiki .sTEyZ{--shiki-light:#90A4AE;--shiki-default:#EEFFFF;--shiki-dark:#BABED8}html pre.shiki code .sMK4o, html code.shiki .sMK4o{--shiki-light:#39ADB5;--shiki-default:#89DDFF;--shiki-dark:#89DDFF}html pre.shiki code .sbssI, html code.shiki .sbssI{--shiki-light:#F76D47;--shiki-default:#F78C6C;--shiki-dark:#F78C6C}html pre.shiki code .s7zQu, html code.shiki .s7zQu{--shiki-light:#39ADB5;--shiki-light-font-style:italic;--shiki-default:#89DDFF;--shiki-default-font-style:italic;--shiki-dark:#89DDFF;--shiki-dark-font-style:italic}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":455,"searchDepth":456,"depth":456,"links":2767},[2768,2772,2775,2776,2777,2778,2779],{"id":2084,"depth":459,"text":2085,"children":2769},[2770,2771],{"id":2098,"depth":462,"text":2099},{"id":2137,"depth":462,"text":2138},{"id":1603,"depth":459,"text":1604,"children":2773},[2774],{"id":1581,"depth":462,"text":1582},{"id":2240,"depth":459,"text":2241},{"id":2367,"depth":459,"text":2368},{"id":2529,"depth":459,"text":2530},{"id":2683,"depth":459,"text":2684},{"id":2722,"depth":459,"text":2723},"2025-09-26","Learn how to connect Modbus RTU devices to Node-RED with FlowFuse. This guide covers Modbus basics, serial setup, register mapping, and reading\u002Fwriting data for industrial automation and IIoT.","\u002Fblog\u002F2025\u002F09\u002Fimages\u002Fmodbus-rtu.png",{"keywords":2784,"excerpt":2785},"modbus rtu, modbus 485, modbus rs485, modbus 485 rtu, modbus communications, rs232, rs485, node-red, flowfuse, industrial automation, iiot",{"type":12,"value":2786},[2787],[15,2788,2078],{},"\u002Fblog\u002F2025\u002F09\u002Fusing-modbus-with-flowfuse",{"title":2072,"description":2781},{"loc":2789},"blog\u002F2025\u002F09\u002Fusing-modbus-with-flowfuse","Step-by-step guide to using Modbus RTU with FlowFuse for industrial automation.",[497,498],"Modbus RTU is one of the most widely used industrial communication protocols, running over serial connections in a master-slave architecture where FlowFuse acts as master and devices such as sensors, PLCs, and meters act as slaves. This guide covers Modbus data types, register addressing conventions, and step-by-step setup of the node-red-contrib-modbus nodes in FlowFuse to read and write device data.","CutuaczTzimqz3h4usV0xIs7048XcKHSNjvUNqkBL-M",{"id":2798,"title":2799,"authors":2800,"body":2801,"cta":3,"date":3963,"description":3964,"extension":480,"image":3965,"lastUpdated":3966,"meta":3967,"navigation":490,"path":3973,"seo":3974,"sitemap":3975,"stem":3976,"subtitle":3977,"tags":3978,"tldr":3980,"video":3,"__hash__":3981},"blog\u002Fblog\u002F2024\u002F12\u002Fpublishing-modbus-data-to-uns.md","How to Bridge Modbus to MQTT: Step-by-Step Guide",[10],{"type":12,"value":2802,"toc":3954},[2803,2806,2809,2812,2816,2819,2822,2825,2837,2840,2843,2847,2850,2858,2860,2863,2896,2900,2903,2908,2915,2920,2923,2951,2956,2967,3069,3077,3085,3098,3103,3106,3133,3136,3142,3151,3155,3159,3162,3165,3170,3173,3181,3188,3220,3223,3226,3252,3261,3266,3320,3328,3343,3348,3394,3402,3414,3419,3463,3471,3483,3488,3532,3540,3552,3558,3562,3565,3570,3573,3578,3623,3630,3635,3638,3686,3694,3745,3753,3762,3777,3782,3790,3795,3801,3828,3831,3842,3847,3900,3908,3911,3945,3948],[15,2804,2805],{},"Converting Modbus to MQTT unlocks the value trapped in legacy industrial equipment. Industrial facilities worldwide face a persistent challenge: their Modbus-based sensors, PLCs, and controllers generate valuable operational data, but that data remains isolated in local control networks, unable to feed modern cloud analytics, remote dashboards, or predictive maintenance systems.",[15,2807,2808],{},"We've built Modbus to MQTT bridges for manufacturing plants ranging from small production lines to enterprise-scale facilities, and the root problem is always the same protocol mismatch. Modbus requires a master-slave architecture with polling, one device requests data, another responds. MQTT enables publish-subscribe messaging, devices push data to a central broker where any authorized application can subscribe. These are fundamentally incompatible communication patterns.",[15,2810,2811],{},"The proven solution is protocol bridging with Node-RED. This guide shows you how to build a reliable Modbus to MQTT gateway that reads holding registers from your devices, transforms raw sensor readings into human-readable formats, and publishes structured data to a Unified Namespace using FlowFuse's integrated MQTT broker. You'll bridge the OT\u002FIT gap and enable cloud integration, real-time monitoring, and data-driven decision-making across your operations.",[31,2813,2815],{"id":2814},"why-bridge-modbus-to-mqtt","Why Bridge Modbus to MQTT?",[15,2817,2818],{},"Modbus handles local device communication effectively. A PLC polls sensors, reads holding registers, writes control signals, standard automation workflows that have proven reliable for decades. The limitation appears when you need that same data elsewhere: in a cloud database, on a remote dashboard, or feeding a predictive maintenance algorithm.",[15,2820,2821],{},"The constraint is architectural. Modbus requires a master-slave relationship. One device initiates requests, others respond. You can't have multiple systems independently accessing the same Modbus device without coordination, and you can't push data, only pull it through polling. This creates the operational technology (OT) and information technology (IT) integration gap.",[15,2823,2824],{},"MQTT removes these constraints through its broker-based architecture. Devices publish data once to the broker. Any authorized system, whether on-premises or cloud-based, subscribes to relevant topics and receives updates. No polling loops, no master-slave coordination, no point-to-point connections to manage.",[15,2826,2827,2828,2832,2833,2836],{},"This is where the ",[25,2829,2831],{"href":2830},"\u002Fblog\u002F2024\u002F11\u002Fbuilding-uns-with-flowfuse\u002F","Unified Namespace"," concept becomes practical. Instead of data scattered across disconnected Modbus networks, PLCs, and SCADA systems, you establish a single MQTT broker as the central data hub. All operational data flows through standardized topics organized by facility hierarchy: ",[1636,2834,2835],{},"enterprise\u002Fsite\u002Farea\u002Fline\u002Fequipment",". Applications consume what they need through subscriptions.",[15,2838,2839],{},"Consider a production line running legacy Modbus equipment, VFDs controlling motor speeds, pressure transmitters monitoring hydraulic systems, temperature sensors on critical bearings. Historically, this data stays within the local control network. Bridge it to MQTT, and suddenly the maintenance team accesses real-time vibration data on their tablets, the operations dashboard displays line efficiency metrics, and the cloud analytics platform builds predictive models from historical trends, all from the same data stream.",[15,2841,2842],{},"FlowFuse provides both the Node-RED runtime for building these bridges and the MQTT broker infrastructure for the Unified Namespace. The integration is straightforward: Node-RED flows poll Modbus devices and publish to FlowFuse's MQTT broker, where any authorized application can subscribe.",[31,2844,2846],{"id":2845},"how-to-bridge-modbus-to-mqtt","How to Bridge Modbus to MQTT",[15,2848,2849],{},"Let's look at the steps to bridge Modbus data to MQTT using FlowFuse, leveraging Node-RED's capabilities. The process involves retrieving data from a Modbus device (For Practical example, we are using OpenSim to simulate Modbus data), transforming and processing the data (e.g., scaling raw sensor data into human-readable formats), and sending it to your Unified Namespace.",[15,2851,2852,2856],{},[41,2853],{"alt":2854,"dataZoomable":455,"src":2855},"Bridging Modbus Data to MQTT using Node-RED","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Fbridging-modbus-data-to-mqtt.png",[46,2857,2854],{},[31,2859,1582],{"id":1581},[15,2861,2862],{},"Before you start, make sure you have:",[567,2864,2865,2871,2886],{},[570,2866,2867,2870],{},[84,2868,2869],{},"Modbus data source",": An actual Modbus device or a simulator like ModSim.",[570,2872,2873,2876,2877,2881,2882,2885],{},[84,2874,2875],{},"Node-RED Instance",": The easiest and production-ready option is FlowFuse, run Node-RED on edge devices, manage and build flows remotely with your team. Deploy, scale, and secure hundreds or thousands of instances with built-in team collaboration, version control, and production-grade features. ",[25,2878,2880],{"href":2032,"rel":2879},[63],"Sign up here"," and follow ",[25,2883,2884],{"href":2199},"this guide to run Node-RED with FlowFuse on your edge device",". Alternatively, install Node-RED locally on hardware with access to your Modbus network.",[570,2887,2888,2891,2892,2895],{},[84,2889,2890],{},"MQTT Broker",": You need broker connection details (host, port, credentials). If you're using FlowFuse Pro or Enterprise, there's an integrated broker at ",[1636,2893,2894],{},"broker.flowfuse.cloud",", just create a client in the platform and you're done.",[52,2897,2899],{"id":2898},"step-1-collect-data-from-modbus-devices","Step 1: Collect Data from Modbus Devices",[15,2901,2902],{},"The first step is to collect data from your Modbus devices. To do this, you'll need to run Node-RED on your Device. If your Modbus device communicates via a serial port, Node-RED will need access to that port, which you can manage with the appropriate configuration. If you're using Modbus TCP and both Node-RED and your Modbus device are on the same network, the connection is straightforward.",[15,2904,2905],{},[84,2906,2907],{},"Step 1.1: Running the FlowFuse device agent on your edge device",[15,2909,2910,2911,2914],{},"To run Node-RED on your edge device with just a few simple steps, you can use the ",[25,2912,2913],{"href":2199},"FlowFuse Device Agent",". This allows you to run Node-RED locally and also connect it to FlowFuse Cloud for remote monitoring and management, making it easier to keep track of your devices and workflows from anywhere.",[15,2916,2917],{},[84,2918,2919],{},"Step 1.2: Install Modbus Nodes",[15,2921,2922],{},"While Node-RED doesn't include Modbus nodes by default, adding them to your palette is simple. Installing the necessary Modbus nodes from the Node-RED library will enable communication with your Modbus devices, whether they’re connected via serial or TCP. This step ensures you can start reading data from your Modbus devices and processing it for further integration.",[1830,2924,2925,2934,2940,2945],{},[570,2926,2927,2928,2931,2932,453],{},"Open the ",[84,2929,2930],{},"Palette Manager"," by clicking the menu icon in the top-right corner of Node-RED and selecting ",[84,2933,2930],{},[570,2935,2936,2937,2939],{},"In the Palette Manager, search for ",[1636,2938,1638],{}," in the search bar.",[570,2941,1929,2942,2944],{},[84,2943,1682],{}," to add the Modbus nodes to your Node-RED environment.",[570,2946,2947,2948,2950],{},"Once installed, the nodes appear in the left-side palette under the ",[84,2949,1460],{}," category. These nodes will allow you to interact with Modbus devices in your flow.",[15,2952,2953],{},[84,2954,2955],{},"Step 1.3: Configure the Modbus Connection",[15,2957,2958,2959,2962,2963,2966],{},"Next, you'll need to configure the Modbus connection based on your device type. Modbus devices can communicate using two primary protocols: ",[84,2960,2961],{},"Modbus RTU"," (over serial) or ",[84,2964,2965],{},"Modbus TCP"," (over Ethernet\u002FWi-Fi). The specific choice depends on the type of Device you are working with.",[1830,2968,2969,2974,2980,3028],{},[570,2970,1834,2971,2973],{},[84,2972,2252],{}," node onto your Node-RED Canvas.",[570,2975,2976,2977,2979],{},"Double-click on the ",[84,2978,2252],{}," node to open its configuration.",[570,2981,2982,2983],{},"In the configuration window:\n",[567,2984,2985,2994,3009,3016,3022],{},[570,2986,2987,2988,2990,2991,2993],{},"Enter the ",[84,2989,2256],{}," (this is the device address, typically ",[84,2992,1926],{},", but it may vary depending on your device).",[570,2995,2996,2997,3000,3001,3004,3005,3008],{},"Choose the ",[84,2998,2999],{},"Function"," you need, such as ",[84,3002,3003],{},"Read Holding Registers",", ",[84,3006,3007],{},"Read Input Registers",", etc. (this depends on the type of data you want to read).",[570,3010,3011,3012,3015],{},"Specify the ",[84,3013,3014],{},"Start Address"," (the address of the first register you want to start reading).",[570,3017,3018,3019,3021],{},"Set the ",[84,3020,2439],{}," (the number of registers to read).",[570,3023,3011,3024,3027],{},[84,3025,3026],{},"Poll Rate"," (e.g., how often you want to collect data, such as every 1 second).",[570,3029,2310,3030,3032,3033,3035,3036],{},[84,3031,2293],{}," field, click the ",[84,3034,2289],{}," button to add a new Modbus server, and select the type.\n",[567,3037,3038,3054,3064],{},[570,3039,3040,3041,3043,3044,2225,3047,3050,3051,1175],{},"For ",[84,3042,2965],{},": Enter the ",[84,3045,3046],{},"IP address",[84,3048,3049],{},"Port"," (the default Modbus TCP port is ",[84,3052,3053],{},"502",[570,3055,3040,3056,3058,3059,2233,3061,3063],{},[84,3057,2961],{},": If you're using a serial connection, you'll need to specify the serial port (such as ",[1636,3060,2232],{},[1636,3062,2236],{}," on Windows), as well as the baud rate and other serial settings.",[570,3065,3018,3066,3068],{},[84,3067,2256],{}," (again, this should match the Unit ID you entered earlier).",[15,3070,3071,3075],{},[41,3072],{"alt":3073,"dataZoomable":455,"src":3074},"Image showing Modbus node configuration for reading holding registers","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Fmodbus-connection-configuration.png",[46,3076,3073],{},[15,3078,3079,3083],{},[41,3080],{"alt":3081,"dataZoomable":455,"src":3082},"Image showing Modbus client node configuration","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Fmodbus-connection-config.png",[46,3084,3081],{},[1830,3086,3088],{"start":3087},5,[570,3089,3090,3091,3094,3095,453],{},"Once the connection details are filled in, click ",[84,3092,3093],{},"Add"," to save the configuration, then click ",[84,3096,3097],{},"Done",[15,3099,3100],{},[84,3101,3102],{},"Step 1.4: Test the Modbus Connection",[15,3104,3105],{},"After configuring the connection, it's time to test the data collection.",[1830,3107,3108,3113,3122,3127],{},[570,3109,1834,3110,3112],{},[84,3111,2363],{}," node onto the canvas.",[570,3114,3115,3116,3118,3119,3121],{},"Connect the ",[84,3117,2252],{}," node's output to to the input of ",[84,3120,2363],{}," node.",[570,3123,1929,3124,3126],{},[84,3125,1932],{}," in the top-right corner of Node-RED to deploy your flow.",[570,3128,2927,3129,3132],{},[84,3130,3131],{},"Debug Panel"," on the right side of the Node-RED interface. If the connection is successful, you should see the raw data from your Modbus device in the Debug Panel.",[15,3134,3135],{},"If no data appears, check the connection settings (IP address, Unit ID, port, etc.) and ensure your Modbus device is correctly configured and accessible. If you use a simulator like ModSim, ensure it’s running and properly configured to send data.",[15,3137,3138,3139,453],{},"For more information on using Modbus with Node-RED, please read our tutorial on ",[25,3140,3141],{"href":1459},"Using Modbus with Node-RED",[15,3143,3144,3145,3150],{},"If you prefer a video explanation, ",[25,3146,3149],{"href":3147,"rel":3148},"https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fwago-kurt-braun\u002F",[63],"Kurt Braun"," from WAGO demonstrates how to collect Modbus data using Node-RED in FlowFuse:",[1609,3152],{"videoid":3153,"params":1612,"style":1613,"title":3154},"PdVdGg__zUM","Bridging Modbus to MQTT with Node-RED",[52,3156,3158],{"id":3157},"step-2-transforming-modbus-data-for-uns","Step 2: Transforming Modbus Data for UNS",[15,3160,3161],{},"After collecting data from your Modbus device, the next step is transforming it into a usable format for cloud-based IoT applications. Modbus data typically comes in raw register values, and you may need to convert these values into human-readable formats like temperature, pressure, or other measurements.",[15,3163,3164],{},"Let's walk through the transformation process step by step.",[15,3166,3167],{},[84,3168,3169],{},"Step 2.1: Parsing and Converting Raw Modbus Data",[15,3171,3172],{},"Modbus devices often return data in registers that need to be interpreted. For example, a temperature sensor might return a register value like 350, which represents 35.0°C if the sensor stores values in tenths of degrees.",[15,3174,3175,3179],{},[41,3176],{"alt":3177,"dataZoomable":455,"src":3178},"The ModSim interface, generating simulated Modbus data","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Fmodsim.png",[46,3180,3177],{},[15,3182,3183,3184,3187],{},"Here’s an example of the raw Modbus data I am receiving from ModSim: ",[1636,3185,3186],{},"[225, 1013, 29, 50, 603]",". These values represent the following:",[567,3189,3190,3196,3202,3208,3214],{},[570,3191,3192,3195],{},[1636,3193,3194],{},"225",": Temperature (in tenths of degrees, which would be 22.5°C)",[570,3197,3198,3201],{},[1636,3199,3200],{},"1013",": Part 1 of the pressure value (higher register)",[570,3203,3204,3207],{},[1636,3205,3206],{},"29",": Part 2 of the pressure value (lower register)",[570,3209,3210,3213],{},[1636,3211,3212],{},"50",": Vibration (in tenths of degrees, which would be 5g)",[570,3215,3216,3219],{},[1636,3217,3218],{},"603",": Humidity (in tenths of degrees, which would be 60.3%)",[15,3221,3222],{},"We must convert these raw register values into human-readable formats for cloud integration. For instance, we divide the temperature and vibration by 10 to get the actual values in degrees Celsius and g, respectively, and similarly for other parameters like humidity. For pressure, the higher and lower register values are combined to compute the complete value accurately.",[15,3224,3225],{},"To determine how to process raw Modbus data, such as dividing by a specific value, concatenating, or applying other transformation formulas, refer to the manual of the sensor you use for specific instructions.",[15,3227,3228,3229,3233,3234,3238,3239,3243,3244,3246,3247,3251],{},"In Node-RED, you can use various nodes for transformation. You can choose the ",[25,3230,3232],{"href":3231},"\u002Fnode-red\u002Fcore-nodes\u002Ffunction\u002F","Function node"," for advanced processing, the ",[25,3235,3237],{"href":3236},"\u002Fnode-red\u002Fcore-nodes\u002Fchange\u002F","Change node"," for simpler operations, or the ",[25,3240,3242],{"href":3241},"\u002Fnode-red\u002Fcore-nodes\u002Ftemplate\u002F","Template node"," for defining schemas. For more complex data parsing scenarios, such as handling multiple data types (floats, 32-bit integers, strings), dealing with big-endian\u002Flittle-endian conversions, or performing byte swapping, consider using the ",[1636,3245,1798],{}," node. This specialized node simplifies parsing Modbus buffers into various data formats without writing custom code. Learn more in our guide on ",[25,3248,3250],{"href":3249},"\u002Fblog\u002F2025\u002F12\u002Fnode-red-buffer-parser-industrial-data\u002F","using Buffer Parser for industrial data",". In this article, I will demonstrate a low-code approach using the Change node to process the data cleanly.",[15,3253,3254,3255,2225,3258,453],{},"Additionally, for better organization and accessibility, I will send each metric separately and include additional metadata such as the ",[1636,3256,3257],{},"timestamp",[1636,3259,3260],{},"unit",[15,3262,3263,2730],{},[84,3264,3265],{},"For Temperature",[1830,3267,3268,3272,3275],{},[570,3269,1834,3270,3112],{},[84,3271,1751],{},[570,3273,3274],{},"Double-click the node to open its configuration panel.",[570,3276,3277,3278,3281,3282],{},"Set the following in the ",[84,3279,3280],{},"Set"," rules:\n",[567,3283,3284,3291,3298,3304,3312],{},[570,3285,1919,3286,1923,3289,453],{},[1636,3287,3288],{},"msg.data",[1636,3290,1744],{},[570,3292,1919,3293,1923,3295,453],{},[1636,3294,1744],{},[1636,3296,3297],{},"{}",[570,3299,1919,3300,3303],{},[1636,3301,3302],{},"msg.payload.timestamp"," to the timestamp function of the Change node.",[570,3305,1919,3306,1923,3309,453],{},[1636,3307,3308],{},"msg.payload.value",[1636,3310,3311],{},"data[0] \u002F 10",[570,3313,1919,3314,1923,3317,453],{},[1636,3315,3316],{},"msg.payload.unit",[1636,3318,3319],{},"'c'",[15,3321,3322,3326],{},[41,3323],{"alt":3324,"dataZoomable":455,"src":3325},"Image showing the Change node rules transforming temperature data","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Ftemperature-data-tranformation.png",[46,3327,3324],{},[1830,3329,3330,3335],{"start":456},[570,3331,1929,3332,3334],{},[84,3333,3097],{}," to save the configuration.",[570,3336,3337,3338,3340,3341,3121],{},"Connect the first output of the ",[84,3339,2252],{}," node to the input of this ",[84,3342,1751],{},[15,3344,3345,2730],{},[84,3346,3347],{},"For Pressure",[1830,3349,3350,3355,3357],{},[570,3351,3352,3353,3112],{},"Drag another ",[84,3354,1751],{},[570,3356,3274],{},[570,3358,3277,3359,3281,3361],{},[84,3360,3280],{},[567,3362,3363,3369,3375,3379,3387],{},[570,3364,1919,3365,1923,3367,453],{},[1636,3366,3288],{},[1636,3368,1744],{},[570,3370,1919,3371,1923,3373,453],{},[1636,3372,1744],{},[1636,3374,3297],{},[570,3376,1919,3377,3303],{},[1636,3378,3302],{},[570,3380,1919,3381,1923,3383,3386],{},[1636,3382,3308],{},[1636,3384,3385],{},"$number($string(data[1]) & $string(data[2]))"," as a JSONata expression.",[570,3388,1919,3389,1923,3391,453],{},[1636,3390,3316],{},[1636,3392,3393],{},"'ppm'",[15,3395,3396,3400],{},[41,3397],{"alt":3398,"dataZoomable":455,"src":3399},"Image showing the Change node rules transforming pressure data","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Fpressure-data-transformation.png",[46,3401,3398],{},[1830,3403,3404,3408],{"start":456},[570,3405,1929,3406,3334],{},[84,3407,3097],{},[570,3409,3337,3410,3340,3412,3121],{},[84,3411,2252],{},[84,3413,1751],{},[15,3415,3416],{},[84,3417,3418],{},"For Vibration",[1830,3420,3421,3425,3427],{},[570,3422,3352,3423,3112],{},[84,3424,1751],{},[570,3426,3274],{},[570,3428,3277,3429,3281,3431],{},[84,3430,3280],{},[567,3432,3433,3439,3445,3449,3456],{},[570,3434,1919,3435,1923,3437,453],{},[1636,3436,3288],{},[1636,3438,1744],{},[570,3440,1919,3441,1923,3443,453],{},[1636,3442,1744],{},[1636,3444,3297],{},[570,3446,1919,3447,3303],{},[1636,3448,3302],{},[570,3450,1919,3451,1923,3453,3386],{},[1636,3452,3308],{},[1636,3454,3455],{},"data[3] \u002F 10",[570,3457,1919,3458,1923,3460,453],{},[1636,3459,3316],{},[1636,3461,3462],{},"'g'",[15,3464,3465,3469],{},[41,3466],{"alt":3467,"dataZoomable":455,"src":3468},"Image showing the Change node rules transforming vibration data","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Fvibration-data-transformation.png",[46,3470,3467],{},[1830,3472,3473,3477],{"start":456},[570,3474,1929,3475,3334],{},[84,3476,3097],{},[570,3478,3337,3479,3340,3481,3121],{},[84,3480,2252],{},[84,3482,1751],{},[15,3484,3485],{},[84,3486,3487],{},"For Humidity",[1830,3489,3490,3494,3496],{},[570,3491,3352,3492,3112],{},[84,3493,1751],{},[570,3495,3274],{},[570,3497,3277,3498,3281,3500],{},[84,3499,3280],{},[567,3501,3502,3508,3514,3518,3525],{},[570,3503,1919,3504,1923,3506,453],{},[1636,3505,3288],{},[1636,3507,1744],{},[570,3509,1919,3510,1923,3512,453],{},[1636,3511,1744],{},[1636,3513,3297],{},[570,3515,1919,3516,3303],{},[1636,3517,3302],{},[570,3519,1919,3520,1923,3522,3386],{},[1636,3521,3308],{},[1636,3523,3524],{},"data[4] \u002F 10",[570,3526,1919,3527,1923,3529,453],{},[1636,3528,3316],{},[1636,3530,3531],{},"'%'",[15,3533,3534,3538],{},[41,3535],{"alt":3536,"dataZoomable":455,"src":3537},"Image showing the Change node rules transforming humidity data","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Fhumidity-data-transformation.png",[46,3539,3536],{},[1830,3541,3542,3546],{"start":456},[570,3543,1929,3544,3334],{},[84,3545,3097],{},[570,3547,3337,3548,3340,3550,3121],{},[84,3549,2252],{},[84,3551,1751],{},[15,3553,3554,3555,3557],{},"Once you have configured and connected all the Change nodes, add a ",[84,3556,2363],{}," node to each Change node's output to verify that the transformed data appears as expected. Deploy the flow, then check the output in the Debug Panel to ensure that each metric is correctly formatted with the appropriate timestamp, value, and unit.",[52,3559,3561],{"id":3560},"step-3-publishing-modbus-data-to-mqtt","Step 3: Publishing Modbus Data to MQTT",[15,3563,3564],{},"After transforming the Modbus data into a human-readable format, the next step is to publish it via MQTT to build your Unified Namespace (UNS). The UNS is created by organizing your MQTT topics into a standardized hierarchy, when you publish data to these structured topics, you're establishing the namespace that other systems can subscribe to.",[15,3566,3567],{},[84,3568,3569],{},"Step 3.1: Preparing Your MQTT Broker",[15,3571,3572],{},"As mentioned in the prerequisites, FlowFuse provides an integrated MQTT broker service for Team and Enterprise users. The broker uses username and password authentication, you create clients on the platform with credentials that control topic access.",[15,3574,3575],{},[84,3576,3577],{},"To create MQTT clients:",[1830,3579,3580,3587,3593,3603,3610,3616],{},[570,3581,3582,3583,3586],{},"Navigate to the FlowFuse platform and click ",[84,3584,3585],{},"Broker"," in the left sidebar.",[570,3588,2286,3589,3592],{},[84,3590,3591],{},"Create Client"," button.",[570,3594,3595,3596,2225,3599,3602],{},"Enter a ",[84,3597,3598],{},"username",[84,3600,3601],{},"password"," for the client.",[570,3604,3605,3606,3609],{},"Configure ",[84,3607,3608],{},"topic access control patterns"," if needed, specifying which topics the client can publish to or subscribe from.",[570,3611,1929,3612,3615],{},[84,3613,3614],{},"Save"," to create the client.",[570,3617,3618,3619,3622],{},"Once saved, copy the ",[84,3620,3621],{},"Client ID"," from the client list and save it for the next step.",[15,3624,3625,3626,453],{},"For more details about the FlowFuse MQTT broker service, refer to the ",[25,3627,3629],{"href":3628},"\u002Fblog\u002F2024\u002F10\u002Fannouncement-mqtt-broker\u002F","MQTT Broker Service Announcement",[15,3631,3632],{},[84,3633,3634],{},"Step 3.2: Configure MQTT Nodes",[15,3636,3637],{},"Now you'll configure Node-RED to publish your transformed Modbus data to the MQTT broker.",[1830,3639,3640,3646],{},[570,3641,3642,3643,3112],{},"In the Node-RED editor, drag an ",[84,3644,3645],{},"mqtt out",[570,3647,3648,3649,2290,3651,3653,3654],{},"Double-click the node, then click the ",[84,3650,2289],{},[84,3652,2293],{}," field to add a new broker connection:\n",[567,3655,3656,3664,3669,3674,3680],{},[570,3657,3658,3660,3661,3663],{},[84,3659,2293],{},": Enter ",[1636,3662,2894],{}," (for FlowFuse MQTT).",[570,3665,3666,3668],{},[84,3667,3049],{},": Use the default MQTT port (1883 for non-TLS, 8883 for TLS).",[570,3670,3671,3673],{},[84,3672,3621],{},": Paste the Client ID you copied earlier.",[570,3675,3676,3679],{},[84,3677,3678],{},"Username",": Enter the username you created.",[570,3681,3682,3685],{},[84,3683,3684],{},"Password",": Enter the password you created.",[15,3687,3688,3692],{},[41,3689],{"alt":3690,"dataZoomable":455,"src":3691},"MQTT broker node configuration","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Fmqtt-broker-config-node.png",[46,3693,3690],{},[1830,3695,3696,3701],{"start":462},[570,3697,1929,3698,3700],{},[84,3699,3093],{}," to save the broker configuration.",[570,3702,3703,3704],{},"Back in the mqtt out node configuration:\n",[567,3705,3706,3716,3739],{},[570,3707,3708,3711,3712,3715],{},[84,3709,3710],{},"Topic",": Enter a topic following the ISA-95 equipment hierarchy, such as ",[1636,3713,3714],{},"plant2\u002FArea4\u002FCell2\u002FDeviceA\u002Ftemperature",". This naming convention organizes data by enterprise, site, area, line, and equipment, making it easier to filter, manage, and scale your system as it grows.",[570,3717,3718,3720,3721],{},[84,3719,1922],{},": Select the appropriate Quality of Service level:\n",[567,3722,3723,3728,3733],{},[570,3724,3725,3727],{},[84,3726,2170],{}," (At most once) - Fastest, but no delivery guarantee",[570,3729,3730,3732],{},[84,3731,1926],{}," (At least once) - Ensures delivery, possible duplicates",[570,3734,3735,3738],{},[84,3736,3737],{},"2"," (Exactly once) - Slowest, but guarantees single delivery",[570,3740,3741,3744],{},[84,3742,3743],{},"Retain",": Enable this if you want the broker to store the last message for new subscribers.",[15,3746,3747,3751],{},[41,3748],{"alt":3749,"dataZoomable":455,"src":3750},"MQTT Out node configuration for temperature data","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Fmqtt-client-config-temperature.png",[46,3752,3749],{},[15,3754,3755],{},[46,3756,3757,3758,453],{},"Note: This example uses environment variables for sensitive configuration data to prevent accidental exposure when sharing flows. For more information, refer to ",[25,3759,3761],{"href":3760},"\u002Fblog\u002F2023\u002F01\u002Fenvironment-variables-in-node-red\u002F","Using Environment Variables with Node-RED",[1830,3763,3764,3769],{"start":3087},[570,3765,1929,3766,3768],{},[84,3767,3097],{}," to save the node configuration.",[570,3770,3771,3772,3774,3775,3121],{},"Connect the output of the ",[84,3773,1751],{}," node (which transforms your temperature data) to the input of this ",[84,3776,3645],{},[15,3778,3779],{},[84,3780,3781],{},"Using FlowFuse MQTT Nodes",[15,3783,3784,3785,453],{},"If you're using the FlowFuse MQTT broker, FlowFuse provides specialized MQTT nodes that simplify configuration. These nodes automatically configure the broker connection details when you drop them onto the canvas, no manual setup of server address, Client ID, username, or password required. You also won't need to manually create clients in the broker; they're automatically created when you use these nodes. This streamlines the development process and reduces configuration errors. Learn more about ",[25,3786,3789],{"href":3787,"rel":3788},"https:\u002F\u002Fflowfuse.com\u002Fnode-red\u002Fflowfuse\u002Fmqtt\u002F",[63],"FlowFuse MQTT nodes",[15,3791,3792],{},[84,3793,3794],{},"Step 3.3: Configure MQTT Nodes for Remaining Metrics",[15,3796,3797,3798,3800],{},"Repeat the configuration process for each metric (pressure, vibration, humidity), creating separate ",[84,3799,3645],{}," nodes with unique topics:",[567,3802,3803,3812,3820],{},[570,3804,3805,3808,3809],{},[84,3806,3807],{},"Pressure",": ",[1636,3810,3811],{},"plant2\u002FArea4\u002FCell2\u002FDeviceA\u002Fpressure",[570,3813,3814,3808,3817],{},[84,3815,3816],{},"Vibration",[1636,3818,3819],{},"plant2\u002FArea4\u002FCell2\u002FDeviceA\u002Fvibration",[570,3821,3822,3808,3825],{},[84,3823,3824],{},"Humidity",[1636,3826,3827],{},"plant2\u002FArea4\u002FCell2\u002FDeviceA\u002Fhumidity",[15,3829,3830],{},"Each mqtt out node should:",[567,3832,3833,3836,3839],{},[570,3834,3835],{},"Use the same broker configuration (click the pencil icon next to Server and select your existing broker)",[570,3837,3838],{},"Have its own unique topic",[570,3840,3841],{},"Be connected to the corresponding Change node output",[15,3843,3844],{},[84,3845,3846],{},"Step 3.4: Deploy and Verify the Connection",[1830,3848,3849,3854,3880],{},[570,3850,1929,3851,3853],{},[84,3852,1932],{}," in the top-right corner of Node-RED to activate your flow.",[570,3855,3856,3857,3859,3860],{},"Check the status indicator beneath each ",[84,3858,3645],{}," node:",[567,3861,3862,3868,3874],{},[570,3863,3864,3867],{},[84,3865,3866],{},"Green dot with \"connected\"",": Successfully connected and publishing data",[570,3869,3870,3873],{},[84,3871,3872],{},"Red dot with \"disconnected\"",": Connection failed, check your broker credentials and network connectivity",[570,3875,3876,3879],{},[84,3877,3878],{},"Yellow dot",": Connecting or waiting for data",[570,3881,3882,3883],{},"To verify data is flowing to your UNS:",[567,3884,3885,3891,3897],{},[570,3886,3887,3888,3890],{},"Navigate to the ",[84,3889,3585],{}," section in the FlowFuse platform",[570,3892,2286,3893,3896],{},[84,3894,3895],{},"Hierarchy"," tab to view your topic structure",[570,3898,3899],{},"You should see your topics organized by the ISA-95 hierarchy you defined",[15,3901,3902,3906],{},[41,3903],{"alt":3904,"dataZoomable":455,"src":3905},"FlowFuse topic hierarchy interface showing UNS structure","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Fflowfuse-mqtt-topic-hierarchy-monitoring.png",[46,3907,3904],{},[15,3909,3910],{},"Once your flow is successfully publishing data, you've established your Unified Namespace. Other systems can now subscribe to these MQTT topics to consume the data for:",[567,3912,3913,3919,3927,3933,3939],{},[570,3914,3915,3918],{},[84,3916,3917],{},"Cloud analytics platforms"," for historical analysis and reporting",[570,3920,3921,3926],{},[84,3922,3923],{},[25,3924,2525],{"href":2523,"rel":3925},[63]," for real-time monitoring and visualization",[570,3928,3929,3932],{},[84,3930,3931],{},"Predictive maintenance systems"," for equipment health monitoring",[570,3934,3935,3938],{},[84,3936,3937],{},"Business intelligence tools"," for operational insights",[570,3940,3941,3944],{},[84,3942,3943],{},"Alert and notification systems"," for automated responses to threshold breaches",[15,3946,3947],{},"This setup effectively bridges legacy Modbus devices with modern IoT infrastructure, enabling data-driven decision-making and unlocking the full potential of your industrial operations.",[15,3949,3950,3951,453],{},"For more information on using MQTT with Node-RED, please read ",[25,3952,3953],{"href":1449},"Using MQTT with Node-RED",{"title":455,"searchDepth":456,"depth":456,"links":3955},[3956,3957,3958],{"id":2814,"depth":459,"text":2815},{"id":2845,"depth":459,"text":2846},{"id":1581,"depth":459,"text":1582,"children":3959},[3960,3961,3962],{"id":2898,"depth":462,"text":2899},{"id":3157,"depth":462,"text":3158},{"id":3560,"depth":462,"text":3561},"2024-12-04","Learn how to bridge Modbus data to MQTT in 2026 and publish it to a Unified Namespace (UNS) using FlowFuse for real-time monitoring and cloud integration.","\u002Fblog\u002F2024\u002F12\u002Fimages\u002Fhow-to-bridge-modbus-to-mqtt.png","2025-12-19",{"keywords":3968,"excerpt":3969},"modbus to mqtt, mqtt to modbus, node-red as gateway, bridging modbus to mqtt, modbus to uns, modbus data to unified namespace",{"type":12,"value":3970},[3971],[15,3972,2805],{},"\u002Fblog\u002F2024\u002F12\u002Fpublishing-modbus-data-to-uns",{"title":2799,"description":3964},{"loc":3973},"blog\u002F2024\u002F12\u002Fpublishing-modbus-data-to-uns","Build a Production-Ready Modbus to MQTT Bridge with Node-RED",[497,3979,498],"uns","Bridging Modbus to MQTT with Node-RED solves the OT\u002FIT integration gap by translating the Modbus master-slave polling model into an MQTT publish-subscribe architecture. The guide walks through reading Modbus holding registers, transforming raw register values into human-readable metrics, and publishing them to a Unified Namespace via FlowFuse's integrated MQTT broker.","Krz806jlNth1sruNRYpFvTv-NoIlMUW8kdoJRoRV46k",{"id":3983,"title":3984,"authors":3985,"body":3987,"cta":4198,"date":4201,"description":4202,"extension":480,"image":4203,"lastUpdated":4204,"meta":4205,"navigation":490,"path":4211,"seo":4212,"sitemap":4213,"stem":4214,"subtitle":4215,"tags":4216,"tldr":4220,"video":3,"__hash__":4221},"blog\u002Fblog\u002F2023\u002F05\u002Fintegrating-modbus-with-node-red.md","Best Practices Integrating a Modbus Device With Node-RED (2026)",[3986],"andrew-lynch",{"type":12,"value":3988,"toc":4189},[3989,3992,3995,3998,4002,4005,4011,4014,4020,4023,4029,4033,4036,4042,4046,4049,4055,4058,4064,4067,4073,4076,4080,4093,4098,4101,4107,4110,4115,4118,4124,4131,4135,4138,4142,4155,4161,4167,4173,4177,4180,4186],[15,3990,3991],{},"The world of industrial automation is slow to adopt new technology. With legacy equipment already working and in place, paralyzing down-time costs, and fears of introducing instability into a plant, technology change has a cautious pace.",[15,3993,3994],{},"Node-RED provides a way to extend the capabilities of the simpler, proven technology, allowing connections with modern systems.  However, the same fundamentals that have made industrial equipment dependable, must be incorporated into your Node-RED architecture.  And, inversely, the same abstraction and simplicity that makes a low-code, Node-RED environment fast, and easy to work with, can also make it difficult to interface with a lower-level system.",[15,3996,3997],{},"Modbus is a widely adopted protocol for accessing data from existing legacy manufacturing equipment. Node-RED makes it very easy to connect to Modbus enabled equipment. However, there are some best practices we have developed to maintain system integrity when integrating Modbus devices with Node-RED:",[52,3999,4001],{"id":4000},"add-watchdogs-to-node-red-flows","Add Watchdogs to Node-RED Flows",[15,4003,4004],{},"To keep your automation system running with peace of mind and little human intervention, use a watchdog timer.  A watchdog timer is typically used to detect and recover from system malfunctions. In Node-RED a watchdog timer can be tied to a broadcast messaging system to get push alerts directly to cell phones, as well as to an auto-reset to try to get your Flows back online automatically.  A simple implementation of this is to just put two Trigger nodes in a loop, the first one to send an alert when it hasn’t seen any recent events, and the second to to reset the first one.",[15,4006,4007],{},[41,4008],{"alt":4009,"src":4010,"title":4009},"Example watchdog flow","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-3.png",[15,4012,4013],{},"Each of the trigger nodes are setup with similar parameters, only the delay values differ.",[15,4015,4016],{},[41,4017],{"alt":4018,"src":4019,"title":4018},"Trigger node configuration","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-14.png",[15,4021,4022],{},"Sending a payload of {\"connectorType\":\"TCP\"} to the Modbus Flex Connector is enough to reset the connection without needing to send all the other parameters.",[15,4024,4025],{},[41,4026],{"alt":4027,"src":4028,"title":4027},"Change node configuration","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-10.png",[52,4030,4032],{"id":4031},"choosing-a-safe-poll-rate","Choosing a Safe Poll Rate",[15,4034,4035],{},"Be careful when adding new traffic to an industrial network, which might not be able to handle the extra load.  Some networks have low-bandwidth, especially at large plants that might be using antiquated IP devices and long-distance, Wi-Fi bridges in electrically noisy environments.  Furthermore, some PLCs and other Modbus devices have limits as to how many other devices can connect to them, and a new connection might not work, or worse, bump off an old connection.  A PLC’s general operation is to poll its inputs every cycle and react accordingly, running logic and triggering outputs as quickly as possible. The general use-case for Node-RED with a PLC is to create an HMI or broader, SCADA system.  A poll rate of every second suffices for a simple HMI.  For dashboards published to a greater audience, rather than just the operator, poll rates of several minutes to hours might be adequate.  If this is a new integration, it’s better to start slow and make sure the current infrastructure can handle the extra load.",[15,4037,4038],{},[41,4039],{"alt":4040,"src":4041,"title":4040},"Modbus node configuration","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-7.png",[52,4043,4045],{"id":4044},"coilregister-grouping","Coil\u002FRegister Grouping",[15,4047,4048],{},"Modbus works more efficiently when it is reading and writing addresses as groups.  Creating banks of consecutively numbered coils or registers can help with this.  If Modbus is already in use, perhaps for an existing HMI, but for your Node-RED dashboard you just want a selection of these addresses and they are too scattered to be read all at once, pick a starting address numbered far higher than what you will use for any HMI work and create a new bank of coils or registers just for the Node-RED dashboard.  The PLC can handle this easily and it greatly simplifies the polling for your Node-RED dashboard.  On the Node-RED side of the connection, it’s a good idea to parse and to filter this data as soon as it enters the flow.  Below, the first node creates an appropriate message for each coil, with a topic name and a true\u002Ffalse payload.  This message is then filtered by the “block unless value changes” mode in the filter node and finally a switch (by topic) node separates out each message.  In this example, every Tag coming in from the PLC only triggers downstream nodes when there is a change and each Tag has its own output to connect a wire, and subsequent nodes to.",[15,4050,4051],{},[41,4052],{"alt":4053,"src":4054,"title":4053},"Using a switch node to separate the messages","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-5.png",[15,4056,4057],{},"The filter node blocks redundant data from triggering subsequent nodes.",[15,4059,4060],{},[41,4061],{"alt":4062,"src":4063,"title":4062},"Filter node configuration","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-12.png",[15,4065,4066],{},"The function node, “modbusMapArray,” creates messages that are much more user-friendly in the Node-RED environment.",[15,4068,4069],{},[41,4070],{"alt":4071,"src":4072,"title":4071},"Modbus function node","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-1.png",[15,4074,4075],{},"Quick tip: If your PLC environment has limits on the number of addresses allowed and you want to read a lot of coils, you can work with registers bitwise and stuff 16 coils into one register.",[52,4077,4079],{"id":4078},"reading-data-types","Reading Data Types",[15,4081,4082,4083,4086,4087,4092],{},"No matter what data type the PLC is sending over Modbus, it’s going to be sent using the 16-bit registers.  For example, to send 1234.5678 as a 32-bit Float (little-endian), the payload from the PLC will be a seemingly unhelpful array, ",[2587,4084,4085],{},"21035,17562",".  I can simulate this with the ",[25,4088,4091],{"href":4089,"rel":4090},"https:\u002F\u002Fwww.automationdirect.com\u002Fadc\u002Foverview\u002Fcatalog\u002Fsoftware_products\u002Fprogrammable_controller_software\u002Fproductivity_suite_programming_software",[63],"Productivity Suite Programming Software"," from Automation Direct set to simulator mode.  Below, I have created a 32-bit float “Tag,” named “mySampleFloat32,” using modbus registers 40001 and 40002, and set the “Init Value” to 1234.5678.",[15,4094,4095],{},[41,4096],{"alt":4091,"src":4097,"title":4091},"\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-11.png",[15,4099,4100],{},"Node-RED is typically used at a much higher level, but luckily there is still a way to work with this low-level data.  Node-RED uses the Buffer Class to work with this type of data stream, but it’s a little tricky.  First the 16-bit registers have to be broken into 8-bit chunks, here we use msg.responseBuffer.buffer to retrieve each octet.  Once our buffer is properly filled, there are many built-in functions to reconstruct the data into the actual number you are looking for.",[15,4102,4103],{},[41,4104],{"alt":4105,"src":4106,"title":4105},"Using msg.responseBuffer.buffer to retrieve each octet","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-4.png",[15,4108,4109],{},"Notice below that to read these 2 registers at 400001 and 400002 I have set my Modbus-Read node to start at “Address” 0 and ready “Quantity” 2 registers.  Unfortunately, there are two different standards for writing Modbus addresses and my PLC uses the traditional convention (400001 to 465536) and this Modbus node uses the hexadecimal convention (4x0000 to 4xFFFF).",[15,4111,4112],{},[41,4113],{"alt":4040,"src":4114,"title":4040},"\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-8.png",[15,4116,4117],{},"In this example the byte order from msg.responseBuffer.buffer doesn’t quite match the data type, so we have to rebuild the buffer.",[15,4119,4120],{},[41,4121],{"alt":4122,"src":4123,"title":4122},"Mapping the data in a function node","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-13.png",[15,4125,4126,4127,453],{},"Amazingly after all that work we get the response: 1234.5677490234375.  This is the shortcoming of the 32-bit float data type.  Although it can handle a huge range of values, they aren’t very accurate.  For this reason, many times PLCs will send a number as an integer, say 12345678, and the documentation will prescribe 4 decimal place accuracy to bring the number back to 1234.5678.  Find out more ways to work with a Buffer at ",[25,4128,4129],{"href":4129,"rel":4130},"https:\u002F\u002Fnodejs.org\u002Fdist\u002Flatest-v10.x\u002Fdocs\u002Fapi\u002Fbuffer.html",[63],[52,4132,4134],{"id":4133},"general-architecture","General Architecture",[15,4136,4137],{},"Although you can off-load some of the higher-level logic from the PLC into Node-RED, it’s important to remember that Node-RED augments, but doesn’t create a replacement for a PLC’s IDE and the IEC 61131-3 suite of languages.  Make a conscious distinction between the type of work the PLC should handle and what you expect from Node-RED.  Any real-time responses to inputs should strictly be handled by the PLC.",[52,4139,4141],{"id":4140},"security","Security",[15,4143,4144,4145,4150,4151],{},"Connecting Node-RED to your PLC also creates a larger attack surface for cyber threats.  Make sure that you follow the guidelines found on the Node-RED.org site at ",[25,4146,4149],{"href":4147,"rel":4148},"https:\u002F\u002Fnodered.org\u002Fdocs\u002Fuser-guide\u002Fruntime\u002Fsecuring-node-red",[63],"Securing Node-RED",".  Node-RED’s strength is its ability to make connections where they weren’t possible before, but this can be taken advantage of by a hacker.  For instance, maybe it’s tempting to make Node-RED a transparent gateway and make a RESTful API fully exposing a modbus-flex-write node.  This is amazingly easy and powerful with Node-RED, but anyone who can access your IP could send http:\u002F\u002F",[4152,4153,4154],"your-ip",{},":1880\u002Fcareful?value=true&fc=15&unitid=1&address=0&quantity=10 and remotely turn on and off whatever they wanted.",[15,4156,4157],{},[41,4158],{"alt":4159,"src":4160,"title":4159},"Example endpoint flow","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-6.png",[15,4162,4163,4164],{},"Instead, a better practice would be to more narrowly define what you want to accomplish and only allow Node-RED to do exactly that. In this case you might send http:\u002F\u002F",[4152,4165,4166],{},":1880\u002FhonkTheLunchHorn?honk=true",[15,4168,4169],{},[41,4170],{"alt":4171,"src":4172,"title":4171},"Locking down the endpoint","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-2.png",[52,4174,4176],{"id":4175},"final-thoughts","Final Thoughts",[15,4178,4179],{},"If not done right, there could be some hard lessons, so it’s best to monitor the processes to help track down bugs.  Add a log, keep your eyes out, and as a community let’s work to create stable systems.",[15,4181,4182],{},[41,4183],{"alt":4184,"src":4185,"title":4184},"Logging failures","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fintegrating-modbus-9.png",[15,4187,4188],{},"How readily upper management gives an “okay” to this new technology comes with how well it is implemented.  There will be some growing pains, but by the end, you will have supercharged your plant, bringing it into the 21st century.",{"title":455,"searchDepth":456,"depth":456,"links":4190},[4191,4192,4193,4194,4195,4196,4197],{"id":4000,"depth":462,"text":4001},{"id":4031,"depth":462,"text":4032},{"id":4044,"depth":462,"text":4045},{"id":4078,"depth":462,"text":4079},{"id":4133,"depth":462,"text":4134},{"id":4140,"depth":462,"text":4141},{"id":4175,"depth":462,"text":4176},{"type":475,"title":4199,"description":4200},"Connect Modbus Devices to the Cloud with FlowFuse","FlowFuse gives you a secure, managed platform for deploying Node-RED flows that connect your legacy Modbus equipment to modern systems, dashboards, and cloud services.","2023-05-16","Modbus is a widely adopted protocol for accessing data from existing legacy manufacturing equipment. Node-RED makes it very easy to connect to Modbus enabled equipment. However, there are some best practices we have developed to maintain system integrity when integrating Modbus devices with Node-RED","\u002Fblog\u002F2023\u002F05\u002Fimages\u002Fmodbus2.jpg","2026-06-03",{"keywords":4206,"excerpt":4207},"modbus node-red, node-red modbus integration, node-red modbus tcp, modbus best practices, node-red industrial automation",{"type":12,"value":4208},[4209],[15,4210,3991],{},"\u002Fblog\u002F2023\u002F05\u002Fintegrating-modbus-with-node-red",{"title":3984,"description":4202},{"loc":4211},"blog\u002F2023\u002F05\u002Fintegrating-modbus-with-node-red","Integrate Modbus with Node-RED",[4217,4218,4219,498],"posts","node-red","how-to","Integrating Modbus with Node-RED requires more than just connecting nodes industrial reliability demands watchdog timers for auto-recovery, conservative poll rates to avoid overloading legacy networks, grouped coil\u002Fregister addressing for efficiency, and correct handling of multi-register data types like 32-bit floats. This article walks through each best practice with example flows and node configurations.","77YhHHX8TKYaGPCWTj0LRN0T87yXH75wtlWMtlb58lM",1785528680486]