How to choose MQTT or HTTP for equipment telemetry
Choose MQTT or HTTP for equipment telemetry only after you write who publishes a reading, who receives it, and who takes a disconnect. MQTT is publish and subscribe between a client and a server. HTTP is a stateless request and response. The reading still has to land in the same equipment record.
On this page
Write where the reading has to go
Write four facts for each kind of reading: which asset, which field, who receives it, and who takes a disconnect or a failed request. Leave any of the four blank and there is nothing yet to choose a protocol for.
How a reading meets maintenance or rental you already run is an Assessment, prototypes, and integration question. The five rental records are in How to choose an equipment rental management system. Work orders are in How to do predictive maintenance for equipment. The asset identifier is in How to choose barcode or RFID for equipment tracking.
What MQTT 5.0 says it is
MQTT Version 5.0 is an OASIS Standard dated 7 March 2019. It replaces MQTT 3.1.1, dated 29 October 2014. The abstract calls MQTT a client-server publish/subscribe messaging transport that is light weight and open, and suited to machine-to-machine and Internet of Things settings where a small code footprint is required or network bandwidth is at a premium. The protocol runs over TCP/IP, or over other network protocols that provide ordered, lossless, bidirectional connections.
The same standard defines three qualities of service. At most once, messages are delivered by the best efforts of the operating environment and loss can occur. The standard’s example is ambient sensor data, where a lost reading is acceptable because the next one is published soon after. At least once, messages are assured to arrive and duplicates can occur. Exactly once, messages are assured to arrive exactly once. The standard’s example is a billing system, where a duplicate or a lost message could apply an incorrect charge. The standard also says the transport is agnostic to the payload, and that interested parties are notified when an abnormal disconnection occurs. This note does not turn the billing example into your charging rule, and it does not add a distance or a battery figure the standard does not state.
What RFC 9110 says HTTP is
RFC 9110 is HTTP Semantics, STD 97. The abstract calls HTTP a stateless application-level protocol for distributed, collaborative, hypertext information systems. The same section describes HTTP as a family of stateless request/response protocols: a request can be considered in isolation, and the server does not have to bind it to a predetermined sequence of steps.
The same document dates the companion specifications HTTP/1.1 (RFC 9112), HTTP/2 (RFC 9113), and HTTP/3 (RFC 9114) to June 2022. The extracted header does not print a publication line for RFC 9110 itself. This note uses the companion dates as the date of that set, and it cites RFC 9110 only for the request and the response. This note does not add a latency or a throughput figure the page does not state.
Match the protocol to the handoff
When one reading must reach more than one subscriber, and a single lost ambient reading can wait for the next, the step matches MQTT’s publish/subscribe and the standard’s own at-most-once example. Write the topic, the broker, and who is told of an abnormal disconnection. The standard leaves the payload open, so you put the asset identifier and the unit into the payload, matching the same record in the software.
When a person or another system asks for one record, and the response answers only that request, such as whether an asset can be rented now, the step matches HTTP’s request and response. Write the URL, the method, which field a success updates, and who retries a failure. The two can sit together: periodic readings on MQTT, a single lookup on HTTP. This note does not make that split mandatory.
Duplicates and disconnects need an owner
If you choose at least once, the standard says a message can arrive twice. The software has to treat that reading as one write, using the asset identifier plus the reading time, or another key you have already named. Without that rule, a board shows the same reading twice.
With MQTT, the abnormal-disconnect notice has to land on a list that has an owner, not only in the broker log. With HTTP, a failed request lands on that same list. When nobody reviews the list on a fixed cycle, leave both protocols off the live equipment.
When to leave MQTT off
When nobody operates a broker, the topic is still unnamed, or the only consumer occasionally asks for one record, leave MQTT off for that lookup. Ask for the record with one HTTP request, and write who retries a failure.
Consider exactly once only when a loss or a duplicate would cause an error you have already written down. The standard’s example is billing. An ambient reading without that consequence stays at most once, or at least once with the duplicate rule written in the software. This note does not state bandwidth saved or battery saved.
When to leave HTTP off
When the device must hold a connection, a disconnect must be announced, and the only design you can write is the server asking each asset in turn, read the abnormal-disconnect notice in the MQTT standard before you decide on publish/subscribe. If you can write the polling URL, the interval, and the owner of a failure, HTTP can stay on the short list. The interval has to come from your own maintenance rule, with a date. This note does not fill in a number of seconds.
When the identifier is unset, the reading has no unit, and nobody hands a failure to a work order, leave both protocols off the equipment. Write those three first. Until a trial transmission exists, check the telemetry by whether every reading carries an identifier, whether a disconnect or a failure has an owner, and whether a duplicate reading is stored once.