ZHIYUAN AIoTZHIYUAN AIoT
Contact

Tech Explained

MQTT vs Modbus-RTU: Which Industrial IoT Protocol Should You Choose?

MQTT and Modbus are the two most common protocols in industrial IoT. Which fits your scenario? This article compares response speed, network overhead, and use cases to help you choose.

Tech ExplainedMQTTModbusIndustrial ProtocolsIoTDTU

Choosing Protocols Is Like Choosing Tools — The Wrong Scenario Wastes Everything

"Do you support MQTT?" "Can you connect via Modbus-RTU?" — These two questions come up in nearly every customer technical discussion. Many engineering contractors and factory IT managers face protocol confusion: should they use MQTT or Modbus?

The answer: **It depends on the scenario, not which protocol is "better." They complement, don't compete.**

Modbus-RTU: The "Universal Language" at Device Level

Born in 1979, Modbus is the de facto universal language in industrial automation. Nearly all PLCs, VFDs, and smart instruments support Modbus.

**Key characteristics:**

  • Master-slave architecture: master polls, slave responds
  • Physical layer: RS-485 bus, two-wire differential signaling
  • Range: 1,200m (without repeater)
  • Speed: 9,600-115,200 bps
  • One master, up to 32 slaves per bus

    • **Best for:**

    ✅ Local device acquisition — PLC reading VFD/instrument data

    ✅ Concentrated sensor collection within the same electrical cabinet

    ✅ High real-time requirements (100ms polling)

    ✅ Factories with existing RS-485 wiring

    **Not suitable for:**

    ❌ Long-distance cross-region transmission (1,200m bus limit)

    ❌ Scenarios needing active device reporting (master-slave, slaves can't initiate)

    ❌ Mobile network environments (TCP instability over 4G/5G)

    MQTT: The Cloud "Courier"

    MQTT was designed by IBM in 1999 for oil pipeline sensor monitoring — born IoT-ready.

    **Key characteristics:**

  • Publish/subscribe: devices actively report, cloud receives in real-time
  • TCP/IP-based: runs over Ethernet, WiFi, 4G/5G
  • Ultra-low bandwidth: minimum packet just 2 bytes
  • QoS three levels: 0=at most once, 1=at least once, 2=exactly once
  • Last Will mechanism: auto-notifies on device disconnection

    • **Best for:**

    ✅ Remote device data reporting (cross-city, cross-campus)

    ✅ Battery-powered low-power sensors (NB-IoT + MQTT)

    ✅ Scenarios needing device offline detection

    ✅ One-to-many data distribution (one data stream consumed by multiple systems simultaneously)

    **Not suitable for:**

    ❌ High-speed 100ms polling (pub/sub has latency)

    ❌ Pure local closed-loop control (MQTT requires Broker, unavailable when offline)

    The "Dual Protocol Stack" in Real Deployments

    The most common architecture in ZHIYUAN AIoT platform deployments:

    ```text

    Sensor → 4-20mA/RS-485 → Local DTU/Gateway → MQTT → Cloud Platform

    └── Modbus-RTU ──┘ └─ 4G/Ethernet ─┘

    ```

  • **Device to DTU**: Modbus-RTU (reliable, low-latency, network-independent)
  • **DTU to Cloud**: MQTT (cross-network, active reporting, auto-reconnect)

    • This leverages both strengths: local collection with Modbus for reliability and real-time, cloud transmission with MQTT for flexibility and scalability.

    **No protocol is inherently better — only better suited. The best approach: accept whatever protocol the field uses, unify to MQTT for cloud upload.**
    CallGet Plan