Subscribing

A reader gets messages by subscribing: it tells the broker which topics it wants, once, when it connects. From then on the broker sends it a copy of every message posted to those topics, until it unsubscribes or leaves.

One in, many out

Three subscribers to home/kitchen/temp means one message from the sensor and three copies out of the broker. The sensor posts exactly the same message whether nobody is subscribed or a hundred readers are. It is never told who they are, and it has no way to ask.

That is the point of the whole arrangement. A logger, a dashboard and a phone can be added in an afternoon, and the sensor's program is not touched once.

Nobody listening

A message to a topic with no subscribers reaches the broker and is thrown away. In MQTT 3.1.1, the version most small boards speak, the sender is not told: there is no error for it, and a board posting at QoS 0 gets no reply of any kind. MQTT 5 added a way for the broker to say "no matching subscribers" in the receipt of a QoS 1 or 2 message, for clients that speak it.

So the most common reason an MQTT project does nothing at all is a topic nobody subscribes to — usually one that is wrong by a single character.

Both ways

Any client can post and subscribe at the same time. A lamp subscribes to home/lamp/set and a phone posts on to it: the command goes down the same way the readings come up, through the broker, and the phone does not need the lamp's address either.

Common mistakes

• Subscribing after the message was sent. A subscriber only gets what is posted while it is subscribed. What happened before is gone — unless it was retained, which is lesson five.
• Subscribing once, before connecting. A subscription is made on a connection. A board that reconnects after a Wi-Fi drop has to subscribe again, unless it asked the broker to keep its session.
• Expecting an error for an empty topic. Nothing comes back. Check the subscriber with a tool such as mosquitto_sub before suspecting the sensor.