1. Introduction — Two Protocols, Two Completely Different Purposes

In industrial automation, Modbus and MQTT are among the most widely used communication protocols.
They are not competitors — instead, they serve different layers in a factory communication system:

• Modbus → Device-level communication (PLC, VFD, sensors)
• MQTT → Cloud-level communication (IoT platforms, dashboards, remote monitoring)

Choosing the right protocol depends on where the data is going, how fast it must be exchanged, and the network environment.

This article explains the core differences, use cases, and engineering best practices for both protocols.

---

2. Modbus — How It Works

Modbus is a master–slave (RTU) or client–server (TCP) protocol widely used in industrial devices.

2.1 Master–Slave or Client–Server Architecture

• One master polls multiple slaves
• Slaves cannot communicate on their own
• Works with PLCs, VFDs, meters, and sensors

---

2.2 Register-Based Communication

Common register types:

• Coils (0xxxx) – Digital ON/OFF
• Discrete Inputs (1xxxx) – PLC input signals
• Holding Registers (4xxxx) – Parameters, setpoints
• Input Registers (3xxxx) – Measurement values (current, voltage, speed)

---

2.3 Polling Mechanism

The master continuously reads/writes registers in a fixed cycle:

Master → read/write → Slave
Master → read/write → Slave

No data is sent unless requested.

---

3. MQTT — How It Works

MQTT is a publish/subscribe IoT protocol designed for cloud and remote communication.

3.1 Topic-Based Structure (No Registers)

Messages are organized as “topics”:

• factory1/machine01/status
• line2/temperature
• alerts/motor_overload

Devices publish and subscribe to topics.

---

3.2 Publish/Subscribe Model

• Publisher sends data to broker
• Subscriber receives data
• Broker handles routing

MQTT supports lightweight communication with minimal bandwidth usage.

---

3.3 Broker Architecture

A central message server (Mosquitto, EMQX, HiveMQ) manages all communication.

Benefits:

• Asynchronous
• Scalable
• Secure (TLS)
• Perfect for cloud services

---

4. Direct Comparison of Modbus vs MQTT

Feature	Modbus	MQTT
Layer	Device layer	Cloud/IoT layer
Real-time capability	Strong	Medium
Network dependency	Low	High (needs stable network)
Data flow	Master polls slaves	Devices publish data
Direction	Mostly one-way	Two-way messaging
Use case	PLC, VFD, instruments	IoT cloud, dashboards, alerts

---

5. Real Industrial Application Scenarios

5.1 Modbus Applications

Used for:

• VFD control
• Sensor reading
• Energy meter data
• PLC-to-PLC communication
• Temperature controller interfaces

Modbus is ideal for local factory devices.

---

5.2 MQTT Applications

Used for:

• Remote monitoring
• Alarm push notifications
• Cloud dashboards
• Multi-site data aggregation
• Real-time production visualization

MQTT is perfect for cross-site or cloud applications.

---

6. Engineering Problems and Causes

6.1 Modbus Delay

Caused by:

• Too many slaves being polled
• Low baud rate (9600)
• Long wiring distances
• High noise environments

---

6.2 MQTT Broker Instability

Causes include:

• Weak network
• Cellular signal loss
• Incorrect TLS certificates
• Server overload

---

6.3 Topic Conflict in MQTT

Occurs when:

• Multiple devices publish to the same topic
• Topic naming not standardized
• Duplicate Client IDs

---

7. Best Practices

Modbus Best Practices

• Keep wiring short
• Use shielded cables
• Avoid 485 A/B reversal
• Use higher baud rates
• Minimize the number of slaves per master

---

MQTT Best Practices

• Use structured topic conventions
• Avoid duplicate client IDs
• Enable TLS encryption
• Use QoS1 or QoS2 for critical data
• Use persistent sessions

---

Combined Use Recommendation

The practical approach in most factories:

Use Modbus locally

PLC / VFD / sensors / meters → Modbus

Use MQTT for cloud upload

Gateway → MQTT → Cloud

This hybrid model provides:

• Reliable local control
• Stable cloud monitoring
• Scalable architecture