Publish temperature on a unique MQTT topic
Publish changing DHT22 readings every five seconds under the ESP32’s randomly generated MQTT topic root.

Broker Bex: I want you to follow one reading from its sensor value to its own topic and distinguish a publish result from subscriber delivery.
Predict the reading, then compare it with the measurement.
Wokwi ESP32
Third party ToolPublish changing DHT22 readings every five seconds under the ESP32’s randomly generated MQTT topic root.
Open the ESP32 editor, paste diagram.json, then paste sketch.ino.
Open Wokwi to paste in the files (new tab)Get the files
Use both prepared files. This is a paste-in setup; saving a project requires a Wokwi account.
sketch.ino
- Use the launch button above to open the ESP32 editor in Wokwi.
- Select the editor’s diagram.json tab and replace all its text with the supplied diagram.json.
- Select the sketch.ino tab, replace all its text with the supplied sketch.ino, then click Start Simulation.
Steps
Step 1
- Do
- Paste the diagram and sketch into Wokwi ESP32. Install PubSubClient and DHT sensor library in Library Manager. Inspect the sensor wiring.
- You will see
- The DHT22 data line uses GPIO 4 with a 10 kΩ pull-up to 3.3 V; its supply and ground are connected.
- Why it matters
- The host’s publisher role starts with a valid sensor reading. Wiring and library setup are part of making that reading reproducible.

Step 1 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 2
- Do
- Start the simulation at 115200 baud and wait for Wi-Fi and broker connection.
- You will see
- Wi-Fi connected appears, followed by a unique iotlab- ClientID, an iotclass/lab1/ topic root with a 12-hex-digit suffix, and Connecting to MQTT broker... Connected.
- Why it matters
- The broker accepts a client identity and routes publications by topic. The source’s per-boot identifiers prevent ordinary classroom ClientID collisions.

Step 2 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 3
- Do
- Wait for the first sensor publication and keep two consecutive output groups.
- You will see
- At the supplied settings the sketch prints Temperature: 24.00C OK and Humidity: 40.00% OK, separated into groups by ---, roughly every five seconds.
- Why it matters
- The ESP32 is the publisher; a dashboard would be a subscriber. OK here is PubSubClient’s publish result, not proof that a dashboard received the reading.

Step 3 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 4
- Do
- Select the DHT22 and set temperature to 30 °C while keeping humidity at 40%.
- You will see
- The next valid output group changes to Temperature: 30.00C OK while humidity remains 40.00%.
- Why it matters
- Changing one quantity makes the payload’s meaning visible. The host keeps sensing, broker routing, and display responsibilities separate.

Step 4 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 5
- Do
- Set humidity to 60% without changing the 30 °C temperature.
- You will see
- The next group reports Humidity: 60.00% OK alongside Temperature: 30.00C OK.
- Why it matters
- Temperature and humidity use separate topic suffixes, allowing subscribers to request the quantity they need.

Step 5 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 6
- Do
- Compare make_lab_identity and the publish calls in the sketch with the topic root printed in Serial Monitor.
- You will see
- The root has /temperature, /humidity, /status, and /command suffixes. Sensor publishes pass false for retained state, while the online status uses true.
- Why it matters
- Topic naming and retained state are distinct choices. This starter publishes sensor values at QoS 0; the Boolean argument is the retain flag, not a QoS setting.

Step 6 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 7
- Do
- Restore the DHT22 to 24 °C and 40% RH, confirm the readings, then stop and restart once.
- You will see
- The original sensor values return. Restart prints a new random ClientID and topic root, so the previous run’s subscription would need updating.
- Why it matters
- Public broker sessions are temporary teaching infrastructure. The host explains why availability, isolation, and production security cannot be inferred from a successful public test.

Step 7 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
Chapter checks
These questions refer to the chapter’s examples. Use the return links to review their answers.
In an MQTT-based temperature monitoring system, an ESP32 sensor node reads temperature data and sends it to a broker. A Python dashboard running on a laptop displays the readings. Which statement correctly identifies each component's role?
Return to the chapter’s knowledge checkThis chapter's 'Common Mistake' warning lists four dangers of using test.mosquitto.org in a production deployment. Which of the following is one of them?
Return to the chapter’s knowledge check