What Is MQTT? A Practical Guide for Industrial Automation

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. 

Three applications where this approach shines in real plants are condition monitoring, remote assets, and energy visibility.

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.