MQTT

Most important commands to remember

• mosquitto_sub — subscribe to a topic.
• mosquitto_pub — publish one message to that topic.

Commands and flags

Command or option	Meaning
-h localhost -p 1883	Select the existing local plaintext broker.
-t 'lab/temperature'	Use this exact topic name.
-q 1	Request QoS 1 for the subscription / publication.
-v	Print topic and payload in the subscriber.
-C 1 -W 30	Stop after one received message or the subscriber’s thirty-second wait limit.
-m '21.5'	Publish these text bytes as the payload.

The payload’s temperature unit is an application agreement, not something MQTT derives from the number. Neither command requests retained publication or a persistent offline session.

The concepts that matter

1. Publishers and subscribers meet through topics

MQTT is a lightweight publish/subscribe messaging protocol. A publisher sends to a topic name, and the broker routes the message to matching subscriptions. The publisher does not need a direct connection to every subscriber.

Topic names are case-sensitive. Hierarchical-looking names help organize messages, and subscription filters can match multiple topics. Routing by a topic does not define the payload schema: both applications must agree what the bytes mean.

2. QoS describes protocol delivery

MQTT defines delivery levels: QoS 0 is at most once, QoS 1 is at least once, and QoS 2 provides exactly-once delivery at the protocol level. Higher levels exchange more state and acknowledgment traffic.

The publisher-to-broker and broker-to-subscriber legs are separate. A publication acknowledgment does not prove that a subscriber updated a database or operated a device. Retried business commands still need application-level identity and duplicate handling where appropriate.

3. A retained message is a current value, not a history

A retained publication lets the broker keep the latest retained message for a topic and deliver it to later matching subscribers under the protocol’s rules. This can help a newly connected dashboard discover a current state.

It is not an event log of every previous temperature reading. A client that receives a value immediately after subscribing may be seeing retained state rather than a newly published observation. The application must decide whether old state is still useful.

4. Sessions and wills address connection changes

Session settings determine which subscription and delivery state can survive disconnection. A persistent session is different from a retained message: one concerns a client’s ongoing interaction, the other a topic’s stored value.

A Last Will lets the broker publish a configured message when a client connection ends unexpectedly under the protocol’s conditions. It is a useful signal, not perfect proof that the device is powered off. Network loss, detection delays, and session policy affect what observers see.

One small example

Optional: run the first block in terminal A. While it waits, run the second block in terminal B within thirty seconds. Use the dedicated test topic only; the broker must already be running.

mosquitto_sub -h localhost -p 1883 -t 'lab/temperature' -q 1 -v -C 1 -W 30

mosquitto_pub -h localhost -p 1883 -t 'lab/temperature' -q 1 -m '21.5'

Terminal A should print the topic followed by 21.5, then exit. If publishing happened before the subscription was ready, repeat the exercise with the subscriber started first. A timeout is not proof that the broker rejected the publication.

No retained value is created by this publisher, so a subscriber started only afterward should not receive this sample merely because it was published earlier. QoS 1 permits duplicates, although the subscriber stops after one message. The example does not prove offline delivery or device action, and leaves no retained message to clear.

Keep this idea: MQTT routes topic messages through a broker; delivery quality, retained state, and application effects are different guarantees.