How does a sensor tell a phone?
A door sensor, a thermometer and your phone are three different devices. The sensor should not need to know your phone exists, and the phone should not have to keep asking. A small messaging system called MQTT solves it: devices drop messages with a middle-man and anyone who is interested picks them up.
By the end of this lesson
Note
I can read the messages that devices publish to an MQTT broker, using topics.
Key words
- Broker: the middle-man that receives every message and passes it on.
- Publish: to send a message to the broker, labelled with a topic.
- Subscribe: to tell the broker which topics you want to hear.
- Topic: the label on a message, written like a path, such as
home/door/state. - Retained message: the last message on a topic, which the broker keeps and gives to anyone who subscribes later.
- Wildcard: a symbol in a subscription that matches more than one topic.
Starter: what you already know
Note
Answer in your head. 1. What is the path /home/kim/notes.txt made of? 2. If you post a letter, do you need to know who will read it? 3. What does the * in *.txt stand for when you list files? You will meet all three ideas again in this lesson. Answers: the names of folders and a file, separated by slashes; no, you only need the address; any characters at all.
Before you start
Note
Press Start the lab on the bar at the top of this lesson and wait until it says it is running. There are two containers: sensors, which keeps publishing, and broker, which passes the messages on. Nothing opens in a browser, so use the terminal, where docker exec broker runs one command inside the broker. Each Run button below types its command into your lab's terminal, one after another in the same session. To watch them, or to type your own, press Open terminal on the bar.
A subscriber hears what is published
This command subscribes to home/#, which means every topic below home. -v prints the topic before each message, -C 8 stops after 8 messages and -W 10 stops after 10 seconds, so it always ends. Each line is a topic, a space and a value. You will see the four topics from the sensors: the two temperatures and the humidity are whole numbers, and the door state is open or closed. The first lines to arrive are retained messages, a reason you will meet below. The exact numbers depend on the second you pressed Run, so yours will differ.
docker exec broker mosquitto_sub -t 'home/#' -v -C 8 -W 10Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
A topic is a path, and a wildcard matches part of it
The topics are written level by level, like folders. # matches every level below, as you just used. + matches exactly one level. So home/+/temperature matches the temperature in any room: three lines, each starting home/kitchen/temperature or home/livingroom/temperature and ending in a whole number. The humidity and the door are not shown, because they do not fit the pattern.
docker exec broker mosquitto_sub -t 'home/+/temperature' -v -C 3 -W 10Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
A retained message waits for a late subscriber
This one listens to the door and wants only one message. It answers at once, one line, home/door/state followed by open or closed, because the door sensor marks its messages retained: the broker keeps the last one and hands it to anybody who subscribes. Now compare the humidity, which is not retained. A new subscriber hears nothing until the sensor next publishes, so the answer can take up to a second longer, and then it is one line with a whole number.
docker exec broker mosquitto_sub -t home/door/state -v -C 1 -W 5Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
docker exec broker mosquitto_sub -t home/livingroom/humidity -v -C 1 -W 5Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Check
Tip
Why did the door answer straight away and the humidity wait? Answer: the door messages are retained, so the broker already held the last one, while the humidity is only delivered as it is published.
You can publish too
Anyone who can reach the broker can publish. This command publishes hello from me to a topic of your own, home/notes/first, and -r makes it retained. It prints nothing. Then read it back: the answer is exactly home/notes/first hello from me, every time, because yours is the last message on that topic.
docker exec broker mosquitto_pub -t home/notes/first -r -m 'hello from me'Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
docker exec broker mosquitto_sub -t home/notes/first -v -C 1 -W 3Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
A common mistake
Warning
Many people think a subscriber asks the sensor for a reading. It does not. The sensor publishes when it likes, and the broker only passes the message on to whoever is subscribed at that moment, which is why a retained message exists. And "retained" does not mean "kept for ever": the next message on that topic replaces it, and this lab's broker forgets everything when it stops.
What is left out here
A real device connects to a broker across a network. It signs in with a name and a password or a certificate, and the connection is encrypted, so that nobody on the way can read or change the messages. This lab leaves all of that out: the broker lets anyone inside your copy read and write anything. That is safe here only because nothing outside your copy can reach it. Do not set up a real broker like this.
Exit check
Tip
Answer without looking back. 1. Who does a sensor send its message to? 2. What is a topic? 3. What does home/+/temperature match, and what does home/# match? 4. What does a retained message do? Answers: the broker, never directly to a subscriber; the label on a message, written like a path; the temperature in any one room, and every topic below home; the broker keeps the last one and gives it to anyone who subscribes later.
For teachers
Tip
This lesson is a small example of a lesson worked in a lab: the steps and the Run buttons are the lesson, and the lab is each student's own copy. The lab is two containers on one network, a stock MQTT broker and a script of pretend sensors, and nothing here marks itself: the student hands in the commands they ran and what they printed, and a sentence on what a retained message is for. Key learning points: 1. A broker sits between publishers and subscribers. 2. A topic is a path and + and # are wildcards. 3. A retained message is the last one, kept for late subscribers. Common mistake: thinking a subscriber asks the sensor for a value. Equipment: the lab and its terminal. Tip: ask students to predict how many lines a wildcard will print before they run it. The readings come from a fixed cycle, but where it has got to depends on when a student presses Run, so two students see different numbers. The lab leaves out the sign-in and the encryption a real network needs, which is a good question to ask the class. Copy it into your own module and change it, or build one from scratch with the Lab menu in the lesson builder.