What Is MQTT? A Practical Guide for Industrial Automation
Your packaging or manufacturing line generates tens of thousands of data points every minute, but getting the right data to the right people—maintenance, operations, management, corporate—means building custom integrations for every new system. Each connection adds network load, each project takes months, and your controls team hesitates to touch anything that might risk uptime.
MQTT changes that equation by flipping the traditional polling model: instead of systems constantly asking devices for updates, edge controllers publish meaningful information once, and every system that needs it subscribes. It's event-driven, bandwidth-efficient, and designed for exactly this problem.
Here's how it works and where it makes the most sense.
The problem isn't lack of data, but rather getting the right data to the right people. Maintenance needs vibration trends and temperature history, operations needs OEE and downtime reasons, management wants rolled-up KPIs, and corporate wants everything in the cloud. Every new requirement turns into another polling client hammering your PLCs and another integration project that drags on for weeks.
The symptoms are familiar. Network traffic keeps growing, but insight doesn't. Adding a new dashboard means adding more tags to the PLC, more reads from SCADA, and more risk that a minor change will ripple into an unexpected fault. Integrators warn you not to touch fragile code because "the line is finally stable," while IT pushes for more data to feed corporate tools. You're stuck between "don't touch anything" and "we need more visibility."
MQTT flips the script: devices publish information only when something meaningful happens, and the rest of the world subscribes.
An MQTT broker sits in the middle—on a server in your plant, in your data center, or in the cloud—and manages all message routing. Devices and edge controllers connect to that broker as clients. When an edge device has something to share, it publishes a message on a named topic like plant1/packaging/line3/capper1/temperature, and any system subscribed to that topic receives the update. When you add a new dashboard, it doesn't add load to plant-floor devices. It simply subscribes to data that's already being published.
Different subscribers can get just the information they want based on topics. For example, if several sensors are publishing to line1/oven1/temp, line1/oven2/temp, line1/oven3/temp, and so on, the SCADA system can subscribe to the topic filter line1/+/temp (where + is a single-level wildcard that matches the topic level between line1 and temp) and receive only the temperature data from those topics. This allows SCADA to retrieve just the data it needs, while another device can subscribe to a different topic filter such as line1/+/pressure (to which other sensors publish) and see only the pressure data.
This is the fundamental shift: publish once, and every system that needs the data subscribes. SCADA, historians, dashboards, and cloud platforms all receive the same message without creating additional load on your edge devices.
The model is event-driven instead of constantly chatty. A DXMR90 industrial controller or DXM wireless controller (such as the DXM1200) can read sensors as fast as needed but only publish when values change, cross a threshold, or hit a time-based summary. A stable temperature might send one message every few minutes, while a drifting vibration signal might trigger more frequent updates. You move from "ask everything all the time" to "send what matters when it matters," which dramatically reduces unnecessary traffic, especially over cellular or constrained links.
Quality of service (QoS) settings and retained messages—the broker's memory of the last value published—handle reliability without protocol theory. You can prioritize alarm topics so they get through even on flaky connections, while less critical trend data can drop during congestion without hurting operations. Retained messages mean a dashboard can connect and immediately see the latest value instead of waiting for the next event.
The best part is how MQTT decouples sources and consumers. Your PLC doesn't need to know whether data is going to SCADA, a historian, a cloud platform, or a mobile app. It can keep running the machine while Banner edge controllers take on the role of data publishers. That separation is what finally lets you say "yes" to new data consumers without opening up the control layer every time.
The challenge with MQTT in industrial settings isn't the protocol, but rather bridging from your existing sensors to that data layer. S15C in-line converters turn analog and discrete signals into Modbus or IO-Link. DXMR90 industrial controllers and DXM wireless controllers aggregate those signals, add logic, and publish MQTT data.
Condition Monitoring and Machine Health
Challenge:
You have a critical motor that has taken you down twice in a year, and you know you need better condition monitoring to see problems earlier. Someone adds a temperature sensor and maybe a vibration switch, but the readings live on a meter in the cabinet or on a few new PLC tags. Maintenance only sees the problem when an operator calls, and every request for "more data" turns into a conversation about scan time, tag limits, and who will rewrite the PLC code.
Solution:
You slide an S15C in-line converter onto that temperature sensor and vibration pickup, turning them into Modbus or IO-Link devices without touching PLC wiring. That step lets you use MQTT for condition monitoring instead of relying only on reactive alarms. Those smart signals feed a DXMR90 industrial controller in the panel, which calculates simple health indicators and publishes MQTT topics such as:
- plant1/packaging/conveyor1/motor3/temperature and
- plant1/packaging/conveyor1/motor3/vibration_health
to your broker. Maintenance subscribes through a browser-based dashboard or existing CMMS, with no new load on the PLC and no SCADA rework. Maintenance starts getting alerts two to three weeks before bearings fail instead of discovering the problem at 2 a.m. You avoid emergency rebuilds and weekend call-ins, while the PLC keeps doing what it was designed to do: run the machine. The only change on the control side is a clearer view of what's coming.
Remote and Distributed Assets
Challenge:
You have pumps in remote buildings, tank farms at the edge of the property, or assets in rented warehouse space that all need reliable remote asset monitoring. Operators drive around to check gauges and status lights. Alarms depend on someone hearing a noise or making a round at the right time. Extending your control network everywhere would be costly and risky, and past attempts at standalone telemetry left you with a patchwork of boxes nobody wants to maintain.
Solution:
You install a DXM wireless controller (such as the DXM1200) at each remote location and connect local sensors or wireless nodes for flow, level, pressure, and run status, creating a remote asset monitoring architecture. The DXM logs continuously, runs simple interlocks, and publishes MQTT messages like plant1/utilities/pumpstation3/status and plant1/utilities/pumpstation3/pressure over Ethernet or cellular to a central broker. SCADA, dashboards, and cloud tools all subscribe to the same topics, so they share a single, consistent view of each asset. Operators see remote equipment on the same screens as local machines, maintenance gets verified alarms instead of vague phone calls, and your team can trend performance without driving around with clipboards. Because DXM devices make outbound MQTT connections, IT can lock down inbound access to the control network, with no VPN tunnels into PLCs and no firewall exceptions that make security teams nervous.
Energy and Utility Monitoring
Challenge:
Power costs keep climbing, but energy data for energy monitoring lives in panel meters and monthly bills. You suspect certain lines and compressors are driving demand peaks, yet you can't prove it. When corporate asks for energy per unit produced by area, the answer is "we'll have to start a project," which usually means expensive metering and more custom integrations.
Solution:
You clamp current transformers around key feeders and wire them into S15C current transformer (CT) converters that output Modbus values, giving you the signal path you need for MQTT energy monitoring. A DXMR90 industrial controller aggregates those readings with run status and production counts, converts raw amps into kilowatts, kilowatt-hours, and power factor, and publishes them as MQTT topics that any dashboard can display immediately. Your energy management or BI platform subscribes and shows real usage by line and area. Operations sees which lines are actually driving demand spikes and adjusts scheduling accordingly, engineering spots a compressor that runs loaded overnight for no good reason and fixes it, and corporate finally gets the per-area energy data they've been asking for—without an integrator spending weeks writing custom drivers or touching PLC code.
Banner hardware handles the messy plant-floor realities so MQTT can stay clean and simple.
S15C in-line converters sit directly on existing sensors, turning legacy signals into Modbus or IO-Link without replacing working devices. The key is what they don't replace: the PLC keeps running its ladder logic, the HMI keeps showing the same screens, and safety circuits stay wired exactly as they are. You're not turning your PLC into an IIoT gateway. Instead, you're giving it a dedicated partner in a DXMR90 industrial controller or DXM wireless controller that handles data aggregation and MQTT publishing alongside the control system instead of inside it.
Most MQTT projects start small. You pick one critical asset—a hydraulic power unit that's failed twice this year or a conveyor drive that keeps overheating—and instrument it with S15C in-line converters feeding a DXMR90 or DXM controller. You publish five to ten MQTT topics that describe its health and performance, then watch how maintenance, operations, and management use that visibility over the next 30 days. Once that single asset proves its value, you repeat the pattern for similar pumps, motors, or lines. Within a few months, it's common to have 20 or 30 assets publishing into the same broker, all using the same topic conventions and edge hardware.
MQTT has been in industrial use for decades and powers major IIoT platforms from AWS, Azure, and Google Cloud—it's proven infrastructure, not a passing trend. With Banner's edge controllers bridging from your existing sensors to that MQTT layer, you can start with one asset, prove value quickly, and scale without becoming a protocol expert or rewiring your plant.
If your plant struggles to share machine data across systems, or if every new dashboard means another polling client, MQTT offers a cleaner path for condition monitoring, remote asset monitoring, and energy monitoring. With Banner edge controllers handling the translation and publishing, the outcome is better visibility, less network congestion, and data that actually reaches the people who can act on it.
Start with one critical asset—a pump, motor, or process point that's caused problems—and instrument it with S15C in-line converters feeding a DXMR90 or DXM controller. Publish 5–10 MQTT topics that describe its health. If that proves value in 30 days, extend the same pattern to similar assets. For help implementing MQTT into your operation, contact Banner Engineering to discuss your specific application.
