Capstone: Build Your Own IoT Device

By the end of this project, you will:

• Combine a sensor, an actuator, and a network service into one device that does something a person would actually want.
• Scope a build to the time available, which is the skill that decides whether a demo works.
• Start from a template and extend it, the way most embedded work really begins.
• Debug a system with several moving parts by testing one at a time.
• Explain your design to a room: the problem, the solution, and what you would do next.

In a team, build a device that does all three:

1. Senses with at least one sensor (DHT11, PIR, LDR, potentiometer, an obstacle‑avoidance module)
2. Acts with at least one output (LED, RGB LED, active or passive buzzer, relay, OLED)
3. Connects to the cloud: a Ubidots dashboard (Project 11) and/or a Telegram bot (Project 12)

• Open the starter sketch. It already connects to Wi-Fi and Ubidots, publishes one value, and reacts to one command. Follow the TODO 1/2/3 markers.
• Steal freely from earlier projects: wiring and code for each part are in the Project Hub and the Components Glossary.
• Give your device a unique DEVICE_LABEL so your data does not mix with another team's.

The starter is Project 11 with the project-specific parts hollowed out. It compiles and runs as it stands, publishing a constant 0.0, so you can confirm the cloud half works before you touch a sensor. Three TODO markers say where your code goes.

TODO 1: read your sensor

#include "UbidotsEsp32Mqtt.h"
// TODO 1: add your sensor library includes here, e.g.:
// #include <Adafruit_Sensor.h>
// #include <DHT.h>

float readMySensor() {
  // TODO 1: replace this with a real reading from your sensor.
  //   return analogRead(SENSOR_PIN);      // potentiometer / LDR
  //   return dht.readTemperature();       // DHT11
  return 0.0;
}

Everything about your measurement is behind one function. That is deliberate: the rest of the sketch never needs to know whether the number came from an ADC pin, a DHT11, or a calculation across three sensors. Change readMySensor() and the whole device follows.

There are three places to touch for a new sensor, and forgetting the third is the usual bug: the include, the object (for example DHT dht(DHTPIN, DHTTYPE);), and the begin() call in setup().

TODO 2: publish what you care about

// TODO 2: add every variable you want to see in the dashboard.
ubidots.add(VAR_SENSOR, value);
ubidots.publish(DEVICE_LABEL);

One add() per variable, then a single publish(). Add a second reading by adding a second const char *VAR_... at the top and a second add() here. Rename VAR_SENSOR to what you are actually measuring (soil, lux, temperature): that name is what appears in Ubidots, so a good one makes the dashboard explain itself.

TODO 3: decide what a command means

void callback(char *topic, byte *payload, unsigned int length) {
  ...
  float v = atof(value);

  // TODO 3: decide what a command means for your project.
  digitalWrite(OUTPUT_PIN, (v >= 0.5) ? HIGH : LOW);
  Serial.printf("[CLOUD] command -> %.1f\n", v);
}

The payload arrives as a number, so a command does not have to be on/off. v could be a brightness for ledcWrite() (Project 3), a target temperature to compare against, or an index selecting which message to show on the OLED (Project 10). Keep the callback short: set a variable or write a pin, and let loop() do anything slow.

What the template already handles for you

Pre-demo integration checklist

Work through this once each part works alone, before you trust the whole loop:

• Sensor prints a sensible value on Serial (not nan, not stuck at one number)
• Actuator responds to a hardcoded test value before it responds to the sensor
• Wi‑Fi connects, and reconnects if you toggle the router or walk out of range
• The cloud side (Ubidots dashboard or Telegram chat) shows the first real reading
• A cloud command reaches the board and the actuator reacts within a few seconds
• The whole loop, sense → cloud → actuator, still works after pressing EN/RESET
• DEVICE_LABEL (or CHAT_ID) is unique to your team, not left at the default
• Credentials (WIFI_PASS, UBIDOTS_TOKEN, BOT_TOKEN) are filled in, not still placeholders

If a step fails, go back to the single project it came from (Project 9 for a sensor, Project 11 or 12 for the cloud link) and confirm it still works in isolation before debugging the combination.

1. What problem does your device solve, and for whom?
2. Show it working: trigger the sensor, watch the actuator and the dashboard or chat respond.
3. One thing that was harder than expected, and how you handled it.
4. One thing you would add with another day.

Bonus (up to 2): a cloud alert/event, a clean OLED display, or a genuinely creative idea.

• Wire and test one part at a time, confirm good Serial values before adding the cloud.
• Use millis(), not delay(), so Wi-Fi and MQTT stay responsive.
• Keep a known-working version before adding the next feature.

Look back at the week. Every project was one idea, and the capstone is where they stop being separate:

• Read the world, decide, act on the world (Project 1). Everything since has been a richer version of that loop.
• Digital or analog, raw counts or physical units (Projects 2, 3, 9). Knowing which kind of sensor you have tells you how much interpreting is your job.
• millis(), never delay() (Project 4). Not a style rule: it is what lets a device do two things at once, and every networked project since has depended on it.
• The board can serve a page (Projects 5 to 9): great on the local network, invisible from outside it.
• State has to be kept honest (Project 8). When two interfaces control one output, they both have to be told the truth.
• Local output has its place (Project 10). Not everything needs a phone.
• Publish/subscribe reaches anywhere (Project 11), and an existing app can be your UI (Project 12).

Now try

• OTA updates: Add over-the-air update capability so you can upload new sketches without connecting the USB cable.
• Web dashboard: Add a simple web page (like Project 9) that shows the same sensor data as the Telegram bot, giving you two ways to view the data.

The engineering habits matter as much as the APIs: check that hardware started, guard against bad readings, keep credentials out of your code's public life, print enough on Serial to see what is happening, and keep a version that works before adding the next thing.

That is a real IoT skill set. The next device you build is the same shape, with different parts.