MQTT QoS and Application Duplicates: Delivery Level Does Not Define Every Business Event

Keep the assurance boundary

OASIS MQTT 5 specifies QoS 1 as at-least-once delivery. A protocol packet identity is not a permanent business-event identity. Primary reference: MQTT 5 section 4.3.2.

A hypothetical repeated event

Imagine one physical observation receives application event ID batchA-42 and is published through a proposed monitoring service. The receiving application sees two deliveries carrying that same event identity. Counting deliveries would produce two entries for one defined observation unless the consumer’s agreed duplicate handling says otherwise.

Now imagine two genuinely distinct observations happen to carry equal measured values. Removing the second solely because its value matches the first would discard a real event. The useful identity must distinguish repeated delivery from a new occurrence. A timestamp or equal payload is not automatically sufficient for that project contract.

Specify what the receiver should preserve

Record topic, declared delivery level, publisher/event identity, occurrence time, receipt time and expected duplicate interpretation. Ask how identities survive reconnects and producer restarts and which relevant components retain them. A working broker connection does not answer those application questions.

Keep transport acknowledgment distinct from database commit and from the physical action represented by the record. The project’s acceptance example should include repeated delivery and two distinct equal-valued events. This guide changes no QoS settings and gives no machine-command procedure. It claims no MQTT interface on HM equipment; it defines the evidence needed before a delivery count is described as a production-event count.

Customer Questions

Primary References

These references support the technical principles discussed in this guide. The worked examples and review questions are educational.

• Primary reference: MQTT 5 section 4.3.2