MQTT is a messaging protocol in which publishers send messages and subscribers receive messages on relevant topics. It can connect an industrial collector to applications. It does not define how a sensor is measured, which unit a value uses or what should trigger an alarm; those belong to the application’s data contract.
Broker and topic design
A broker routes published messages to subscribers. Publishers do not need to know every receiver directly, but broker access, capacity, permissions and connection health become operational responsibilities. Giving every device permission to publish to every topic is not a sound default.
Topic names should reflect a clear equipment hierarchy. An illustrative name is site-a/line-2/machine-7/state; it is not a real facility address. Separate a stable equipment identity from its display name so renaming a machine does not fragment its history. Avoid putting secrets or personal information into topic names.
Payloads can carry the value, unit, source timestamp, quality and schema version. Document size limits and optional fields. Different consumers should interpret the same message consistently instead of each guessing the source register’s meaning.
What QoS actually covers
The OASIS MQTT 5.0 standard defines three QoS levels. Their delivery behaviour concerns the relevant protocol communication leg. They do not automatically guarantee a single database write or a physical action performed only once.
| Level | Protocol delivery behaviour | Application question |
|---|---|---|
| QoS 0 | At most once | Can this observation be lost? |
| QoS 1 | At least once | How are repeated records recognised? |
| QoS 2 | Exactly once on the protocol leg | What happens in downstream services? |
A subscriber may process a message and then lose its database acknowledgement. Retrying can repeat the application operation. Stable event identity, uniqueness constraints and transaction boundaries therefore matter beyond the MQTT configuration. QoS 2 is not an unlimited end-to-end exactly-once business guarantee.
Retained does not mean current
A retained message can give a new subscriber the last stored message for a topic. That value may be old. The interface must inspect the source timestamp and freshness policy. Receiving a message immediately after connection does not prove that the device is currently healthy.
Last Will can provide a connection-loss signal, but it does not diagnose every field failure. A connected collector may have lost access to one sensor. Keep device availability, collector health and application connectivity distinguishable.
Illustrative temperature workflow
Assume a collector buffers timestamped temperature records while its upstream connection is unavailable. After reconnection it sends them with their original event identities. The application deduplicates repeats, places late measurements in history and avoids replacing the current display with an older replayed point.
The queue has a finite capacity. Define the supported outage duration, storage alarms and behaviour if storage fails. Test many devices reconnecting at once, and limit replay so current measurements and field polling remain usable. Bounded backoff helps avoid worsening a recovering network.
Discovery questions
- Where will the broker run, and who operates it?
- How are device identities and topic permissions managed?
- Which fields are required for a valid message?
- How are buffering, replay and duplicates tested?
- What happens when credentials or certificates are renewed?
MQTT does not replace a good data model or an operating plan. Validate a small flow through normal operation, disconnection and duplicate delivery before extending it to additional equipment.
An application-level duplicate example
Imagine a collector publishing a temperature observation with the identifier observation-1042. The receiving application stores it, but its processing acknowledgement does not reach the collector. On retry, the collector uses the same observation identifier and the same original timestamp. The receiver can recognise the existing record instead of adding a second sample. Assigning a new identifier for the retry would remove this evidence that both deliveries refer to one observation.
A separate consumer may evaluate an alarm from that record. Its own processing state needs consideration: preventing duplicate measurements does not automatically prevent duplicate notifications. Store the relationship between the input event, alarm transition and notification job. If the delivery provider times out, retain an uncertain outcome instead of confidently declaring that nothing was sent. This is an application design example, not an additional promise made by the MQTT protocol.
Decide how rejected messages are handled as well. An unknown schema version, an invalid unit or an impossible equipment identity should be diagnosable. Blindly retrying a permanently malformed message can occupy resources without producing usable data. Provide a bounded rejection process and an operational view of the affected source. Do not include credentials or unrestricted message bodies in error logs merely to simplify debugging.
Commission permissions and recovery
Test a device identity against the topics it is allowed to publish and subscribe to. Attempt access outside that scope and verify rejection. Test a replaced credential and a decommissioned device separately from an ordinary reconnection. These checks establish whether the intended access rules operate; a successful connection alone says little about the limits of that connection.
For the recovery exercise, interrupt the upstream connection while collection continues, then reconnect with both historical and current observations. Verify original timestamps, record identities and the age shown on the dashboard. Inspect what happens if local storage reaches its configured limit. A buffer-full condition must be visible even when the broker later becomes available again. Document the chosen MQTT version, supported session behaviour and the application’s acknowledgement rules with the actual client and broker configuration. Bring this operating record, a sample payload and the proposed topic hierarchy to the integration review. They make the boundaries of reliability assessable without claiming that one QoS selection solves every delivery problem.