MQTT vs HTTP vs Modbus TCP vs OPC UA for Industrial IoT Gateways

Quick Answer: For industrial IoT gateways, choose MQTT for broker-based telemetry, HTTP POST for a defined web receiving endpoint, Modbus TCP for register access by a PLC or SCADA client, and OPC UA when the receiving system needs structured industrial data. The choice depends on the gateway's supported role, firmware and security functions. RS485 Modbus RTU at the sensor side does not determine the upstream protocol.

The same sensor data can be delivered in different ways

A sensor does not determine the final cloud or SCADA protocol. RS485 Modbus RTU is commonly used at the field layer, while the gateway translates or repackages that data for the application layer. The correct upstream protocol depends on who initiates communication, where the data is stored, whether commands must return to the device and what software the customer already operates.

These are common integration arrangements, not limits on everything the protocols can do. For example, OPC UA also has PubSub mechanisms, and HTTP supports methods other than POST. A gateway purchase should identify the specific implementation needed. A protocol name printed in a feature list does not establish support for every role or optional function.

MQTT: suitable for cloud-oriented publish/subscribe systems

MQTT separates the sender and receiver through a broker. The gateway publishes sensor data to a topic, while one or more applications subscribe to that topic. This is useful for distributed monitoring sites because the gateway does not need to know every final consumer of the data.

A correct MQTT configuration normally includes broker address, port, client ID, authentication and topic rules. A common mistake is to assume that device online means data arrived. Connection status only establishes the session; acquisition, publishing, subscription and database processing still need separate checks.

The OASIS MQTT specification defines case-sensitive topic names: changing case or adding a slash changes the topic. Telemetry and command topics should have deliberate routing and permissions. The protocol does not prescribe a universal sensor JSON structure, so agree on units, types and missing-value representation with the receiving application.

QoS also needs careful interpretation. QoS 0 allows message loss; QoS 1 can produce duplicates; QoS 2 provides exactly-once delivery at the MQTT protocol exchange level, not an automatic guarantee that a business database records each measurement once. Retained messages are not a historical archive. Include the acquisition time and a record identifier when stale data or duplicates would affect reporting.

MQTTS and certificate compatibility

MQTTS commonly means MQTT over TLS. Port 8883 is conventional, but selecting that port does not enable encryption by itself. Verify the firmware's TLS support, trusted certificate authorities, server-name validation and any required client certificate. The device clock must also support certificate-validity checks.

Test the exact broker before ordering a fleet. Include certificate renewal and device replacement in that test plan. Disabling certificate validation to make a trial connection work leaves a different security configuration from the one the project intended. Credentials and certificate files should be supplied through the project's approved security process, not embedded in public examples.

HTTP POST: use when the customer owns a receiving endpoint

HTTP is often straightforward when the customer has a server application that can receive POST requests. A compatible gateway acts as an HTTP client and periodically sends measurements to a target URL. This suits custom backends where the software team already operates an API and does not need a separate messaging broker.

A typical payload can contain a timestamp, station ID and an object containing sensor values. The field names are an application convention. Agree on content type, authentication headers, numeric precision, units and a response that the gateway can interpret. The upload function does not automatically make the gateway an HTTP server that the customer can browse.

A timeout does not prove that the server rejected the data. The server may have stored the request before the response was lost. HTTP semantics in RFC 9110 therefore matter when designing retries: POST is not inherently idempotent. Make repetition safe through an agreed record key or endpoint behavior instead of blindly retrying every failed request. A 202 response means accepted for processing, not necessarily completed storage; define what the application should verify next.

Modbus TCP: use when the plant system reads registers

Modbus TCP carries the Modbus data model over TCP/IP. It is often suitable when a PLC, HMI or SCADA application is already designed as a Modbus client. A compatible gateway may bridge requests to RS485 devices or expose cached measurements through its own register map. Those two behaviors are different: a cache can respond even when the underlying sensor has stopped updating.

Specify the server/client role, function codes, unit identifiers and register offsets. For multi-register values, agree on signedness, word order and scaling. Include data age or validity where the register design permits it. A successful response containing yesterday's temperature is not a successful live measurement.

Polling over TCP/IP does not guarantee deterministic response time. Network congestion, gateway scheduling, serial retries and the number of connected clients affect latency. Test the complete scan under the intended load. If several SCADA clients trigger serial reads through one bridge, their combined traffic may exceed the field bus capacity even though each client's individual polling rate looks reasonable.

Ordinary Modbus TCP should not be exposed directly to an untrusted network. Segmentation, access controls and a suitable protected connection are system-design decisions. The Modbus Organization also defines a separate TLS-based Modbus Security protocol; its existence does not mean every Modbus TCP gateway implements it.

OPC UA: use structured values when the application needs them

OPC UA can present measurements as named nodes with data types and associated information rather than only numeric register locations. This suits industrial applications that need to browse available data and maintain subscriptions. Confirm whether the gateway is an OPC UA server, client or both, and which profiles the receiving software requires.

The OPC UA DataValue structure includes a value, status and timestamps. During integration, check that a sensor fault becomes an appropriate non-good status and that source time is not replaced indiscriminately by upload time. A gateway cannot recover acquisition timing that was never recorded at the field layer.

OPC UA security still needs configuration: certificate trust, endpoint policy and user authorization must agree on both sides. Also test subscription limits and reconnect behavior. If the selected NiuBoL logger does not implement the required OPC UA role, an appropriate edge computer or separate server may be needed. Do not assume that purchasing a more expensive logger automatically supplies this function.

Do not mix up field protocol and upstream protocol

A system can use RS485 Modbus RTU from sensors to the gateway and MQTT from the gateway to the cloud at the same time. Analog 4-20 mA sensors require suitable input conversion before their values can be published or mapped into registers. The physical input and application protocol are separate selection decisions.

For a station serving both local SCADA and a remote portal, establish whether one acquisition process feeds both destinations. Independently polling the same serial bus from two hosts can cause conflicts. Confirm simultaneous protocol operation, not just the availability of two mutually exclusive configuration modes. Then disconnect the cloud route and check that the local application still receives fresh measurements.

Troubleshooting a connected gateway with no usable data

1. Read the measurements inside the gateway. If field acquisition fails, resolve sensor power, addressing and register settings before debugging the cloud.
2. Compare the local value and timestamp with the outgoing message or register response. Look for stale caches, wrong units and missing channels.
3. For MQTT, subscribe with an independent authorized test client to the exact telemetry topic. Check publish permissions and duplicate client identifiers.
4. For HTTP, inspect the request and response together. Distinguish endpoint rejection from DNS, network or TLS failure.
5. For Modbus TCP or OPC UA, test the required role and address or node with a suitable client, then compare it with the plant configuration.
6. Follow one test record into the final application. Reception at a broker or API does not prove that parsing, storage and display are correct.

Acceptance should include recovery, not only a clean connection. Use a controlled network interruption, restart the gateway and examine duplicate handling, record timestamps and fault indication. For example, a hypothetical station storing one record per minute needs capacity for 720 records during a 12-hour outage, before allowing for metadata and storage overhead. That arithmetic is a sizing example, not a claim about a particular NiuBoL device.

When requesting a NiuBoL gateway or data logger, provide the field-device list and the receiving system's actual interface requirements. A sample payload, register list or required OPC UA profile is more useful than asking for cloud compatibility. Specify outage retention, authentication, power and simultaneous connections so the proposed hardware and firmware can be checked together.

Project Decision FAQ

Q1. Is MQTT always preferable to HTTP for remote sensors?

No. MQTT fits a broker-based service with subscriptions and multiple consumers. HTTP POST may require less integration work when a suitable receiving API already exists. Compare the installed gateway capabilities and the software team's operating requirements, including authentication and recovery.

Q2. Does MQTT QoS 1 remove the need for duplicate checks?

No. Duplicate delivery is possible. Use a stable measurement identifier or an agreed combination of station, channel and acquisition time when repeated records would distort totals or reports. Test how the receiving database handles retransmission.

Q3. Can the gateway send data to local SCADA and the cloud together?

Only if its hardware, firmware and configuration support concurrent operation. Test both paths with all intended sensors active and repeat the test with one destination unavailable. Two protocol names in a specification do not establish simultaneous service.

Q4. Why does a Modbus reading remain normal after unplugging a sensor?

The gateway may be serving a cached register. Inspect the update interval, timeout policy and data-age or quality fields. The receiving application must distinguish a current measurement from a retained value.

Q5. What must be agreed before an HTTP upload trial?

Provide the endpoint, method, headers, authentication and payload schema, plus response and retry rules. Include a test that loses the response after data is accepted, so repeated requests cannot silently create duplicate records.

Q6. Does protocol conversion add to the gateway quotation?

It can. Required drivers, input modules, local storage, certificates, commissioning and software licensing may differ by configuration. Request a quote against the exact protocol roles and data flow. Do not assume OPC UA, TLS or custom payload processing is included in every model.

Summary

The practical MQTT vs HTTP vs Modbus TCP vs OPC UA decision starts at the receiving application and ends with a tested data path. Choose the required role, agree on value and timestamp handling, and verify faults and recovery with the actual gateway firmware. That prevents a successful network connection from being mistaken for a completed monitoring integration.