Study guide — what to focus on

This module is curated — the teaching is a top free course (linked in the card above); our job is to point you at the right things, make you prove it, and certify you.

The plan

1. Watch the course (the card above). You don't need to memorise it — aim to understand the ideas below.
2. Focus on these — they're what the check tests and what you'll use for real:
   • WiFi / connectivity — station mode (WiFi.begin), and how the ESP32 sends readings out (an HTTP request or an MQTT publish to a server/broker).
   • Connecting sensors — digital sensors (like a BME280) talk over a bus; simple analog sensors are read with analogRead on an ADC pin.
   • I2C — a two-wire bus (SDA + SCL), many devices sharing the lines by address, with pull-up resistors because the bus is open-drain.
   • SPI — faster, more wires (MOSI, MISO, SCK) and a chip-select per device.
   • UART — asynchronous serial, no clock, both ends set to the same baud rate, TX↔RX crossed over.
   • The ESP32 as the brain — it reads inputs over these interfaces and drives outputs; WiFi/BLE is what makes it IoT.
3. Prove it in Forge (next section) — apply the input → brain → output pattern to a real connected device.
4. Take the K-Check to earn your certificate.

Why this connects to building real products

An IoT product is three roles wired together: a sensor (the input), a microcontroller (the ESP32 — the brain running this kind of code), and a way for the data to leave (WiFi/BLE to a server). The interfaces above — I2C, SPI, UART, ADC — are simply how the brain talks to the sensor. Once you can name which bus a part uses and how WiFi carries the result out, you can read why Forge picks the parts and pins it does when you describe a connected device — and, later, write the firmware for the boards you design.

Time to apply it. The course showed you the ESP32's IoT surface — sensors on a bus, the ESP32 as the brain, and WiFi to carry the data out; now use it to design a real connected device.

Send the prompt below in Forge Design and watch it choose a temperature/humidity sensor (the input, on an I2C or single-wire link), an ESP32 (the brain — the thing your code runs on and that owns the WiFi), and how it powers and connects them into a design with an orderable parts list.

As you read Forge's answer, connect it back to the course: which interface does the sensor use to reach the ESP32, and where would WiFi (WiFi.begin, then an HTTP or MQTT call) push the readings? That mapping — part ↔ bus ↔ network — is the whole point.