This course is about devices on real networks, and a web page can reach neither. So every page is plain about where its claims come from: what a machine checked when the site was built, what was recorded from real software, and what only your own board on your own network can show. This last section explains those labels, the ways to do a lab, and the shorter routes through the chapters.
Three ways to do a lab
A lab here is a project you download and run yourself, on your own computer and boards. Each lab tells you which of three lab modes suits it.
Simulate means doing the lab without a board. Usually that's a small Python program on your computer that pretends to be the device. It sends made-up readings and responds to commands, just as the real firmware would. It lets you check everything except the radio and the sensor.
Some websites can pretend to be a whole ESP32 board, too. One, Wokwi, can even pretend to join Wi-Fi. But its pretend Wi-Fi sends your data out through the company's own servers. Read their rules first, and never send a real password through it.
Build means putting the program on your real board, on your own lab network. Only this shows you what real radios do: a weak signal in the far corner of the garden, or a router that forgets quiet devices.
Both means simulate first, then build. If the real board then misbehaves, you already know the computer side works, so the problem is on the board or in the air.
How to use this course comes down to three choices: how you do each lab, how you read each page's labels, and which chapters you read. A lab in this course is a project you download and run on your own computer, your own boards and your own lab network. Every lab names one of three lab modes:
- Simulate. Run the lab with no board. In this course that usually means a simulated device: a short Python program on your computer that publishes made-up readings and obeys commands exactly as the firmware would, talking to your own Mosquitto. Chapter 9's presence lab works this way. It tests your broker setup, your topics and your server-side code; it can't test radio range, Wi-Fi joining or a sensor. Online board simulators also exist. As of October 2026, Wokwi simulates the ESP32-S3 and ESP32-C6, including a simulated Wi-Fi network, but that network's traffic leaves through Wokwi's own servers, so read its documentation and terms before sending anything through it, and never send a real secret.
- Build. Flash the firmware to your own board on your lab network. This is the only mode that meets real radio behaviour: a weak signal, a router that drops idle devices, an access point on a channel the board can't use.
- Both. Simulate first to get the messages and the back end right, then build. When a lab has a device and a server, this is the most reliable route: when the real board misbehaves, you already know the server side works.
Worked example
Choosing a mode for the first MQTT lab
-
1
A learner's ESP32-S3 is still in the post, and they want to start Chapter 9's labs this weekend. What can they do?
-
2
This weekend: simulate. Mosquitto and the Python clients run on the laptop. A simulated device can publish readings and receive commands, so every topic, message and back-end check can be worked out now.
-
3
When the board arrives: build. The firmware joins the lab network and talks to the same broker. Only the radio and the sensor are new.
-
4
Result: both, and a working server side to compare against when the board doesn't behave.
What "checked" means on these pages
People say code "works" when they mean very different things. This course keeps four claims apart.
- Compiled for ESP32-S3 and ESP32-C6. The code was turned into a program for each of those boards with the real tools, and it built without errors. That proves it's written correctly and only uses things those boards have. It doesn't prove it does what you want, or that it can join your Wi-Fi.
- Captured from a real broker. When a diagram shows messages passing through a message server, those messages really happened. Real software sent them on the machine that built this site, and the build checks the recording still matches. That proves what that server does. A different server, or a bad network, might behave differently.
- Host-tested. A lab's logic came with tests, and they passed on an ordinary computer, called the host. That proves the logic is right. It doesn't prove anything about radios.
- Not hardware-tested by us. Nobody here ran it on a real board. When a page says what your screen "should" show, that is what to expect, not a recording. Any diagram that imitates a network says so, and says what it leaves out.
Unless a page says otherwise, the firmware here is compiled and host-tested, but not tried on hardware by us.
Four labels appear on code, widgets and labs. They make different claims.
- Compiled for ESP32-S3 and ESP32-C6. Every Arduino sketch was built with the real toolchain (Arduino-ESP32 core 3.3, with ArduinoJson and esp-mqtt) for each named board when the site was built. That proves the code is valid and that every function it calls exists for that board. It does not prove it does the right thing, joins your Wi-Fi or reaches your broker.
- Captured from a real broker. An MQTT exchange shown in a widget is a record: real Mosquitto 2.1.2 and real paho-mqtt 2.1.0 clients ran the exchange on the build machine's loopback address, and the build checks that the record still matches. It proves what that broker does with those messages. It doesn't prove what a cloud broker, a different version or a lossy network would do.
- Host-tested. A lab project's board-free logic (a backoff schedule, an offline queue, a payload encoder) or its Python service ran its tests on an ordinary computer, the host, some of them against a local Mosquitto. That proves the logic and the server side, not the radio.
- Not hardware-tested by us. No board ran it and no radio was involved. When a page says what the Serial Monitor should print or what a dashboard should show, that is the expected behaviour, not a recorded run. Every widget that models a network, such as a lossy link or a reconnect schedule, says on its face that it is a model and what it leaves out.
Unless a page says otherwise, firmware here is compiled and host-tested, and not hardware-tested by us. No page runs code or pretends to be a board or a network.
Every hardware example names its board. Where code differs between the ESP32-S3 and the ESP32-C6, a board switch shows each version; pick yours once and every switch like it follows.
ESP32-S3-DevKitC-1. Two Xtensa cores, Wi-Fi 4 on 2.4 GHz, BLE 5. The C++ sketches run here unchanged; Rust needs the forked toolchain.
ESP32-C6-DevKitC-1. One RISC-V core, Wi-Fi 6 on 2.4 GHz, BLE 5 and an 802.15.4 radio. The same C++ sketches compile for it, and the Rust chapters use it.
What does each label prove?
Sort each statement by the weakest label that already proves it. Decide before you drag, then check.
Loading interactive…
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
What this task checks
Structure checked automatically. Whether your ideas are convincing isn't graded, so reread with the checklist.
The compiler says
A model answer
Correct answer
Also accepted:
Why
Why
Worked example
Compiled, but it never connects
-
1
A learner flashes a sketch labelled compiled for ESP32-S3 and ESP32-C6 to an S3. The Serial Monitor prints
joining the lab networkforever, and nothing reaches the broker. "But it compiled," they say. -
2
Read the claim. Compiled means the code is valid for the board. The SSID, the password, the band and the broker's address are all things a compiler can't check.
-
3
Check the bench. The lab SSID is a 5 GHz network. The S3's radio is 2.4 GHz only, so it never sees it.
-
4
Fix it. Join a 2.4 GHz SSID. The code was never the problem.
Routes through the course
The chapters are written to be read in order. If networking is new to you, do exactly that. If you have a particular goal, you can follow a shorter route, a suggested list of chapters:
- Connect my device: chapters 0 to 5, then 8 and 9, the first four sections of 12, the first two of 15, and the weather-station project in chapter 27.
- IoT architect (someone who designs whole systems): chapters 1, 9 to 13, 19, 21 and 26, then two of the big projects in chapter 27.
- Back-end developer (someone who writes server programs) new to devices: chapters 0, 1 and 9 to 15, chapter 16 if you use C#, then the project that mixes languages.
- Security and production: chapters 10, 19 to 22 and 25, then the update-fleet and production projects.
- Embedded Rust: chapters 0, 17 and 18, then 8, 9 and the first four sections of 21.
- Edge AI (small machine-learning models on the device): chapters 0, section 4 of chapter 1, 23 and 24, then the AI sensor project.
A route is only a suggestion. Every page stays open to you. If a later page uses a word you don't know, the chapter you skipped is where to look.
The chapters are written to be read in order, and a reader new to networking should do that. Readers with a goal can take a route, a suggested subset:
- Connect my device: Chapters 0–5 (from Before you start to HTTP and REST from a device), 8 (Staying connected), 9 (MQTT), 12 §1–4 (Telemetry data), 15 §1–2 (Dashboards, users, and alerts), then Chapter 27 §2, the Wi-Fi environmental station.
- IoT architect: Chapters 1, 9–13 (MQTT through End-to-end architecture), 19 (Threats and trust), 21 (Over-the-air updates), 26 (Application domains), then Chapter 27 §5 and §9.
- Back-end developer new to devices: Chapters 0, 1, 9–15 (MQTT through Dashboards, users, and alerts), 16 (C# and .NET in IoT) if you work in .NET, then Chapter 27 §12, the cross-language system.
- Security and production: Chapters 10 (Securing and choosing message protocols), 19–22 (Threats and trust through Production engineering), 25 (Engineering practice), then Chapter 27 §7 and §13.
- Embedded Rust: Chapters 0, 17–18 (Rust on microcontrollers, Rust firmware on the ESP32), 8, 9, 21 §1–4, then Chapter 27 §12 with Rust firmware.
- Edge AI: Chapters 0, 1 §4, 23 (Processing at the edge), 24 (TinyML), then Chapter 27 §8, the embedded AI sensor.
A route is a reading guide, not a lock: every page stays open, and a skipped chapter is where to look when a later page uses a term you don't know.
Which route?
A web developer who writes Python services at work wants to build the server side of a sensor network for a farm, and has never touched a microcontroller. Answer each question to land on a route.
Loading interactive…
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
What this task checks
Structure checked automatically. Whether your ideas are convincing isn't graded, so reread with the checklist.
The compiler says
A model answer
Correct answer
Also accepted:
Why
Worked example
A route with a gap
-
1
A learner takes the Embedded Rust route: Chapters 0, 17, 18, 8 and 9. Chapter 9 §5 opens with "TCP already delivers bytes reliably, so it's fair to ask why MQTT needs delivery levels at all." What should they do?
-
2
Name the gap. TCP is taught in Chapter 3, which this route skips.
-
3
Read just enough. Chapter 3 §2 and §3 cover connections and retransmission; those two sections fill the gap.
-
4
The habit. A route saves time when you already know the skipped material. When a term is new, the skipped chapter is the place to look.
Check your understanding (counts toward your progress)
A page says the Serial Monitor should print joining the lab network. What kind of claim is that?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Nothing on these pages was recorded from a board.
A page can't know your router.
Host tests check board-free logic, not Serial output on a board.
Why
Firmware here is not hardware-tested by us, so a described output is what to expect, not what was seen.
Which label means no board ran it?
In this course, what does simulating a lab usually mean?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
A simulation is something you run and change, not something you watch.
No page runs firmware or pretends to be a board.
Simulating is a full way to do a lab, minus the radio and sensor.
Why
A simulated device publishes made-up readings and obeys commands, so the server side can be built and tested without a board.
Chapter 9's presence lab is the example.
A widget shows an exchange labelled captured from a real broker. What does that tell you?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Captured means recorded from real software, not written by hand.
It shows what that broker version did. Other brokers may differ.
No page connects to anything, your laptop included.
Why
A capture is a record of real software on the build machine's loopback address, re-checked on every build.
Where and when was the exchange recorded?
Why should a learner think twice before sending real data through an online board simulator's simulated Wi-Fi?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Speed isn't the concern; where the data goes is.
A simulator never touches a real board.
The band of a simulated network is beside the point.
Why
A third party's servers see what passes through them. Read their terms first, and never send a real secret.
Where does a simulated network's traffic go?
Practice: Labels, lab modes and routes (5 problems · doesn’t affect your progress)
Which label is the strongest claim a page here can make about firmware it shows?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Firmware here is not hardware-tested by us.
Captures come from brokers on the build machine, not boards.
No page can know your router.
Why
Compiled plus host-tested is the most the build proves. Hardware results are yours.
Compiled and host-tested
A lab has firmware and a Python service. The board hasn't arrived. Which mode lets the learner finish the most of it now?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Waiting wastes the part that doesn't need a board.
Only the radio and sensor need the board.
Both starts with simulating, not with the board.
Why
Simulating covers the service, topics and messages; the board adds the radio later.
Simulate: a simulated device feeds the service
Sort each claim by what would prove it.
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
What this task checks
Structure checked automatically. Whether your ideas are convincing isn't graded, so reread with the checklist.
The compiler says
A model answer
Why
Encoders are board-free logic; building is the compiler's job; broker behaviour is captured; a real router reboot needs your own board.
Correct answer
Also accepted:
Why
A security engineer wants the course's update and threat chapters without the networking basics. Which route?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
That route is the networking basics.
That route is about on-device processing.
That route is about the Rust language.
Why
The security route covers protocol security, threats, hardware trust, updates and production.
Security and production: Chapters 10, 19–22 and 25
On a route that skips Chapter 3, a page mentions retransmission. What should the reader do?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
The page builds on the term; skipping loses the point.
A technical term rarely means its everyday sense exactly.
One section fills the gap; there's no need to restart.
Why
A route is a guide, not a lock. A skipped chapter is where to look when a term is new.
Read the Chapter 3 section that teaches it, then carry on
Where this goes next
The first compiled sketches that join Wi-Fi are in Chapter 4. The first captured broker traces are in Chapter 9 §1, and Chapter 9 §6 has the first lab with a simulated device and tests that run against your own Mosquitto. Chapter 8 §3 has the first host-tested firmware logic, the offline queue. Chapter 27's capstones each end with a hardware checklist: that step is what earns the label hardware-tested, on your own bench.