Arduino and IoT Projects

Analogy categoryAnalogies

What Makes an Arduino Project 'IoT'

An Internet-of-Things project is any embedded device that senses or actuates the physical world and exchanges that data over a network with other devices or a cloud service. A classic Arduino Uno has no networking, so IoT work typically uses a connected board like the ESP8266 or ESP32, an Arduino with a Wi-Fi or Ethernet shield, or an Arduino Nano 33 IoT. The device reads sensors, packages the readings, and pushes them upstream — and may listen for commands coming back down, such as a phone tapping a button to switch a relay. The defining shift from a standalone sketch is that your code now participates in a distributed system with latency, disconnections, and other actors.

🏏

Cricket analogy: Like the shift from backyard cricket to an international match with a third umpire, DRS, and broadcast feeds — the game now talks to a wider network of systems rather than staying self-contained on the pitch.

MQTT: The Language of IoT Messaging

MQTT is the dominant lightweight messaging protocol for IoT because it fits constrained devices and flaky networks. It uses a publish/subscribe model: devices connect to a central broker (like Mosquitto or a cloud broker) and publish messages to named topics such as home/livingroom/temperature, while any interested client subscribes to that topic to receive them. Neither side needs to know about the other, which decouples sensors from dashboards. MQTT adds Quality-of-Service levels 0, 1, and 2 that trade delivery guarantees against overhead, plus a 'last will and testament' message the broker sends on your behalf if your device drops off unexpectedly — perfect for detecting a sensor that has gone offline.

🏏

Cricket analogy: Like a scoreboard operator (the broker) receiving score updates from the umpires and relaying them to every spectator, commentator, and app subscribed to that match — publishers and viewers never talk directly.

cpp

#include <WiFi.h>            // ESP32
#include <PubSubClient.h>

const char* ssid     = "myNetwork";
const char* password = "secret";
const char* broker   = "broker.example.com";

WiFiClient wifi;
PubSubClient mqtt(wifi);

void onMessage(char* topic, byte* payload, unsigned int len) {
  // command received: e.g. toggle a relay
  if ((char)payload[0] == '1') digitalWrite(2, HIGH);
  else                          digitalWrite(2, LOW);
}

void reconnect() {
  while (!mqtt.connected()) {
    // 'last will': broker publishes 'offline' if we vanish
    if (mqtt.connect("esp32-sensor", "user", "pass",
                     "home/sensor/status", 1, true, "offline")) {
      mqtt.publish("home/sensor/status", "online", true);
      mqtt.subscribe("home/sensor/relay");   // listen for commands
    } else {
      delay(2000);
    }
  }
}

void setup() {
  pinMode(2, OUTPUT);
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) delay(500);
  mqtt.setServer(broker, 1883);
  mqtt.setCallback(onMessage);
}

void loop() {
  if (!mqtt.connected()) reconnect();
  mqtt.loop();                          // must call to service MQTT
  float t = 22.5;                       // read real sensor here
  char buf[8];
  dtostrf(t, 4, 1, buf);
  mqtt.publish("home/livingroom/temperature", buf);
  delay(5000);
}

MQTT topics are hierarchical, slash-delimited strings. Subscribers can use wildcards: '+' matches one level (home/+/temperature catches every room), and '#' matches all remaining levels (home/# catches everything under home). Design a clear topic hierarchy up front — it is much harder to change once many devices are deployed.

Security: The Part Everyone Skips

IoT devices are notoriously insecure because they ship with default passwords, unencrypted connections, and no update path — the Mirai botnet weaponized hundreds of thousands of such devices. At minimum, connect to your broker over TLS (MQTT on port 8883) rather than plaintext 1883, give each device unique credentials instead of a shared password, and never hard-code Wi-Fi and broker secrets in a sketch you might commit to a public repo. On the ESP32, use the WiFiClientSecure class with the broker's CA certificate to verify you are talking to the real server. Treat the device as a target: it sits on your home network and a compromised sensor can become a pivot point for an attacker.

🏏

Cricket analogy: Like leaving your stumps ungUarded while backing up too far — a run-out waiting to happen; an unsecured IoT device is that undefended wicket an opponent will punish instantly.

Never hard-code Wi-Fi passwords, API keys, or broker credentials directly in a sketch you plan to share or push to GitHub. Store them in a separate, git-ignored config header, use the board's flash/preferences storage, or a provisioning flow. Leaked embedded credentials are one of the most common real-world IoT breaches.

IoT means an embedded device sensing/actuating the physical world and exchanging data over a network, usually with a cloud service.
Standard Unos have no networking; use ESP8266/ESP32, a Nano 33 IoT, or a Wi-Fi/Ethernet shield.
MQTT's publish/subscribe model decouples devices via a broker and named topics, ideal for constrained, unreliable networks.
QoS levels 0/1/2 trade delivery guarantees for overhead; the 'last will' message flags devices that drop offline.
Topic wildcards '+' (one level) and '#' (all levels) let subscribers filter flexibly; design the hierarchy carefully.
Secure devices with TLS on port 8883, unique per-device credentials, and never hard-code secrets in shared sketches.
Your code now lives in a distributed system, so handle reconnection, latency, and remote commands explicitly.