CONNECTED TECHNOLOGY. CLEARLY EXPLAINED.
MQTT
Plan MQTT around broker ownership, topic permissions and application behavior. Separate message delivery from a useful, current observation or completed action.
MQTT is client/server publish-and-subscribe messaging. Clients publish messages and subscribe through a server commonly called a broker. The application defines the payload’s meaning. Start with the information or action required, then document the message path and the people responsible for operating it.
Write the application contract first
Define the observation or action
Name the sender, intended receiver, topic structure and payload meaning. Specify identifiers, units, timestamps and schema version. Agree how missing or invalid data is represented; a message arriving successfully does not establish that its contents are useful or correct.
Define each access boundary
Name who operates the broker and manages client identities. Document who may publish and subscribe to each topic group, and how credentials are replaced. Keep secrets out of examples and diagnostic screenshots; use a suitable test arrangement to review the intended permissions.
Define the acceptance result
Decide what counts as success in the receiving application. For an observation, show freshness and validity. For a command, distinguish acceptance, execution and observed resulting state. Retain the proposed failure cases and the actual evidence from a bounded integration test.
Keep transport and application outcomes distinct
Broker and client responsibilities
Record the broker product, supported protocol version, client libraries and intended connection settings. Name the operational owner for each part. A hosted endpoint and a local broker can have different service and maintenance arrangements; include availability, support and retirement in the choice.
QoS has a defined scope
MQTT delivery levels are at most once, at least once and exactly once. They describe protocol delivery, not completion of a downstream business action. Choose the supported settings and separately define how the application handles repeats, failures and an action whose result is unknown.
Retained data needs a timestamp
A retained message can supply a previously published value to a new subscription, subject to protocol and subscription behavior. Treat that value as an observation with an age. Decide when it becomes stale and how the interface distinguishes it from a newly sampled reading.
Identity, permissions and encryption
Eclipse Mosquitto documents listener security, authentication and topic-access controls as configurable features. Check the actual broker version and deployed configuration. Successful login is not evidence of correct topic permissions; verify the intended identities and publication boundaries in the agreed test environment.
Reconnects and persisted state
Document the client and broker settings that govern what survives a restart and what is discarded. Mosquitto’s persistence configuration is a specific implementation example. Test recovery against the supported version and storage arrangement rather than assuming that reconnecting restores every observation or application outcome.
Observe the complete processing path
Track when an observation is sampled, published, received and processed. Define gaps, retry limits and a practical incident owner. Keep dashboards and operational decisions aware of old data, schema changes and a disconnected sender; an open connection alone is an incomplete health signal.
A proposed temperature-message trial
Use a non-sensitive sample containing an observation identifier, temperature unit and sampling time. Arrange normal delivery, a repeated observation and an acceptable interruption. Ask the receiver to show freshness and avoid repeating a business action unexpectedly. The interoperability guide adds the broader contract. IoTPapa has not connected a broker or run this trial.
From gateway to application
The industrial-gateway guide helps name where data is collected, transformed and forwarded. Treat a command path into operating equipment as a separately approved integration; this page does not supply production credentials or control instructions.
Primary sources
OASIS: MQTT 5.0 standard, 7 March 2019 supplies protocol definitions and delivery behavior. Eclipse Mosquitto: configuration reference supplies implementation examples for access, listeners and persistence. This guide does not certify a client, broker configuration or end-to-end application.
By Admin · Reviewed 18 October 2026. Sourced messaging explainer and proposed integration checklist; no broker deployment, message-throughput test, delivery SLA or end-to-end certification. Return to Interoperability and application protocols.
Put messaging inside the complete system
EXPLORE FURTHER
Interoperability and application protocols
Define data meaning and an acceptance boundary.
EXPLORE FURTHER
Industrial gateways
Trace collection, transformation and the application path.