MQTT, HTTP, or Modbus TCP? Choosing the Right Protocol for Your Data Logger

Your sensors are reading, the data logger is recording, and the cellular link is up — but the data logger communication protocol carrying that data to your server determines how much bandwidth each transmission consumes, how gracefully the system handles connectivity interruptions, and how easily the data integrates with modern cloud platforms. Selecting the wrong application-layer protocol can mean excessive data costs, gaps in your monitoring record, or weeks of integration rework.

This article compares the three protocols most commonly encountered in monitoring station telemetry: MQTT, HTTP/REST, and Modbus TCP.

Why the Protocol Between Data Logger and Server Matters

The physical connectivity layer — cellular, satellite, or Ethernet — is the pipe that carries data. The communication protocol running on top of that link determines how sensor data is structured, delivered, and acknowledged, independent of the physical connection. Two stations on identical cellular modems can have vastly different bandwidth efficiency depending on whether they use MQTT or HTTP.

When a station transmits every minute instead of every 15 minutes, the per-message overhead of the chosen protocol accumulates significantly. For solar-powered stations in remote locations, this overhead directly affects modem on-time and power consumption.

MQTT: Publish-Subscribe for Efficient Telemetry

MQTT (Message Queuing Telemetry Transport) operates on a publish-subscribe model: the data logger publishes sensor readings to named topics on a broker, and any authorized subscriber — server, dashboard, alarm service — receives them.

Key advantages for monitoring station telemetry:

• Minimal header overhead: MQTT’s fixed header starts at just 2 bytes, making it one of the most bandwidth-efficient protocols for transmitting small sensor payloads.
• Persistent connection: MQTT keeps a TCP connection open between the data logger and broker, avoiding the overhead of establishing a new connection for each data transmission.
• Three QoS levels: QoS 0 delivers messages without confirmation (fire-and-forget), QoS 1 guarantees at-least-once delivery with acknowledgment, and QoS 2 ensures exactly-once delivery through a four-step handshake.
• Persistent sessions: With persistent sessions and QoS 1 or 2, an MQTT broker can queue messages for a disconnected data logger and deliver them upon reconnection — reducing data loss during connectivity interruptions.
• Last Will and Testament (LWT): A data logger can register a “gone offline” message that the broker automatically publishes if the connection drops, enabling immediate disconnection alerts on the dashboard.

Major cloud IoT platforms — including AWS IoT Core and Azure IoT Hub — use MQTT as their primary device protocol. HTTP is supported as a secondary option, while Modbus TCP is not natively supported and requires a protocol gateway.

HTTP/REST: Familiar but Heavy for Constrained Links

HTTP operates on a request-response model: the data logger initiates each data transmission as an HTTP POST request, and the server responds with a status code. It is the default choice for teams coming from web development backgrounds, but this familiarity comes with tradeoffs for telemetry.

• Large header overhead: A typical HTTP request carries 200 to 800 or more bytes of headers — method line, host, content-type, authorization, and other fields — before the actual sensor payload. Compare this to MQTT’s 2-byte minimum header.
• No built-in publish-subscribe: Standard HTTP does not support server-initiated push notifications to the data logger. The device must poll the server or use extensions like WebSocket for bidirectional communication.
• No built-in store-and-forward: HTTP provides no native message queuing mechanism. If a POST request fails due to a connectivity interruption, the data logger firmware must handle retry logic and local buffering independently.

HTTP remains a valid choice when monitoring stations connect to existing web infrastructure with stable connections, or when a REST API is mandated by the receiving platform.

Modbus TCP: Extending the Field Bus to the Network

Modbus TCP wraps standard Modbus application data units inside TCP/IP packets, using port 502 by default. For engineers already working with Modbus RTU on the field bus, Modbus TCP feels like a natural extension — but there are important differences for upstream telemetry.

• Master-slave polling model: The server or SCADA system polls the data logger for specific register values, rather than the data logger pushing data on its own schedule.
• Designed for local area networks: Modbus TCP was designed for reliable local area networks in industrial plants, where connections are persistent and latency is low.
• No disconnection handling: Modbus TCP provides no built-in publish-subscribe messaging, message queuing, or graceful disconnection handling. If the TCP connection drops, the polling cycle breaks until reconnection.

Modbus TCP remains strong for scenarios where a data logger connects via LAN to a local SCADA or HMI system. For WAN transmission over intermittent cellular connections, these limitations become significant.

Protocol Comparison: Bandwidth, Reliability, and Platform Support

Criterion	MQTT	HTTP/REST	Modbus TCP
Communication model	Publish-subscribe	Request-response	Master-slave polling
Minimum header overhead	2 bytes	200–800+ bytes	7 bytes (MBAP header)
Connection	Persistent	Per-request (HTTP/1.1)	Persistent (LAN)
Built-in QoS	3 levels (0, 1, 2)	None	None
Store-and-forward	Yes (via broker)	None	None
Disconnection handling	LWT + persistent session	Manual retry	None
Cloud platform support	Native (AWS, Azure, etc.)	Supported (secondary)	Not native (requires gateway)
Suited for intermittent links	Excellent	Adequate (with retry logic)	Not ideal

Published research indicates that MQTT can use significantly less bandwidth per message than HTTP for small sensor payloads, primarily due to its compact binary headers versus HTTP’s text-based headers.

Choosing the Right Protocol for Your Monitoring Station

Protocol selection depends on deployment conditions and integration requirements:

MQTT — the strong choice for most remote, solar-powered monitoring stations on intermittent cellular connections. The combination of QoS 1 and persistent sessions offers reliable data delivery with low bandwidth overhead. Well-suited for remote AWLR, extensometer, weather station, and AQMS deployments.

HTTP/REST — appropriate when monitoring stations integrate with existing web infrastructure and a stable connection is available. Also useful when the monitoring platform mandates a specific REST API format for data submission.

Modbus TCP — remains the standard for stations connected via LAN to local SCADA or HMI systems in plant and factory environments. Not recommended as the sole upstream protocol for remote WAN transmission.

Regulatory monitoring platforms may specify the data submission format or API, which can constrain protocol choice — verify platform requirements before finalizing the protocol.

When to Consider a Protocol Gateway

Many deployments use a hybrid approach: Modbus RTU on the field bus for sensor-to-data-logger communication, then MQTT or HTTP for upstream transmission to the cloud. A protocol gateway or multi-protocol data logger can bridge both sides — running Modbus RTU on the field interface while using MQTT for cloud communication.

Fortuna Argatech provides data loggers and gateways that handle upstream data transmission across all product lines — from SPARING wastewater monitoring to AWLR flood early warning stations. Selecting the right protocol for your specific field conditions is part of monitoring station connectivity planning that should be considered from the system design stage.

For technical consultation on telemetry architecture and protocol selection for your monitoring project, contact the Fortuna Argatech engineering team.