Basics of IoT: Sensors, Connectivity, Security, and Your First Device

The Internet of Things (IoT) connects physical objects—sensors and actuators—to the internet so they can collect data and trigger actions. This tutorial walks through the core building blocks (sensing, connectivity, and security) and guides you to build a simple Wi‑Fi temperature/humidity sensor that publishes to an MQTT broker. Along the way, you’ll learn best practices and common pitfalls encountered by intermediate practitioners.

Core components of an IoT system

Sensors and actuators

• Sensors convert real-world phenomena to electrical signals. Common examples: temperature (DHT22, BME280), humidity, light (photodiode, LDR), motion (PIR), acceleration (MPU6050), gas (MQ-135), and proximity (ultrasonic).
• Digital vs. analog:
  • Analog sensors output voltage; you’ll sample with an ADC and often need calibration (offset/scale).
  • Digital sensors (I2C/SPI/1-Wire) provide calibrated readings with less noise, but require bus configuration.
• Actuators perform actions: relays (switch mains loads), motors/servos, LEDs/buzzers, solenoids. Always consider isolation (optocouplers, MOSFETs, relays) and flyback protection for inductive loads.

Key considerations:

• Sampling rate: Choose based on signal dynamics and power budget (e.g., temperature can be 10–60 s; vibration may need kHz).
• Accuracy and precision: Check sensor datasheets for tolerance, drift, and required warm-up.
• Calibration: Environmental sensors benefit from baseline calibration (e.g., humidity offset) and occasional re-calibration.

Edge compute: MCU vs. SBC

• Microcontrollers (MCUs) like ESP32, STM32, nRF52 are low-power, cost-effective, and ideal for simple tasks, often using C/C++ or MicroPython. Memory is limited; design for constraints.
• Single-board computers (SBCs) like Raspberry Pi run Linux and support higher-level languages (Python/Node.js), but consume more power and take longer to boot.

Connectivity options and trade-offs

• Wi‑Fi: High throughput, ubiquitous, moderate range, higher power. Good for home/office sensors with mains or big batteries.
• BLE: Very low power, short range; great for wearables or smartphone-to-device interactions.
• Zigbee/Thread: Mesh networking, low power, requires coordinator; ideal for smart homes.
• LoRaWAN: Very long range, very low data rate; excellent for remote sensors with tiny payloads and long battery life.
• Cellular (LTE‑M/NB‑IoT): Wide-area coverage, moderate power; requires SIM, data plan, and careful power management.

Decision hints:

• Small payloads, infrequent: LoRaWAN or NB‑IoT.
• Interactive devices in a building: Wi‑Fi or Zigbee/Thread.
• Smartphone companion: BLE.

Data models and message formats

• JSON: Human-readable; good for debugging; heavier on constrained links.
• CBOR/MessagePack: Binary, compact; better for low-bandwidth links.
• Include essential fields: device_id, timestamp (UTC epoch), measurement units, and version. Example JSON: {"device_id":"esp32-7afc","ts":1711048275,"temp_c":23.8,"hum_pct":43.1,"fw":"1.0.2"}

Networking and IoT protocols

MQTT in practice

MQTT is a lightweight pub/sub protocol widely used by IoT devices.

• Components: Clients (devices/apps) and a broker (central server).
• Topics: Hierarchical strings, e.g., building/2/floor/1/room/42/temp.
• QoS:
  • 0: at most once (fast, may drop).
  • 1: at least once (may duplicate; ensure idempotency).
  • 2: exactly once (heaviest; rarely needed on constrained devices).
• Retained messages: Broker stores last message; useful for current state.
• Last Will and Testament (LWT): Broker publishes a message if a client disconnects unexpectedly.

Good topic design:

• Use stable hierarchies that reflect physical layout or function.
• Avoid putting sensitive info (e.g., credentials) in topics or payloads.

When to use HTTP/REST or CoAP

• HTTP/REST: Great for command/control and occasional sensor posts. Heavier than MQTT but ubiquitous.
• CoAP: Lightweight request/response (UDP-based) for constrained devices; supports observe (like pub/sub). Useful in low-power mesh networks.

Device identity and provisioning

• Assign globally unique IDs (e.g., derived from MAC/unique_id).
• Provision credentials per device (X.509 certificate or symmetric key) and store securely.
• Automate onboarding with a device registry and just-in-time or bulk provisioning workflow.

Security fundamentals for IoT

Security is non-negotiable. Threats include eavesdropping, device cloning, botnets, and data tampering.

Essentials:

• Transport security: Use TLS (port 8883 for MQTT) with server certificate validation. Prefer mutual TLS (mTLS) with client certs.
• Key management: Unique credentials per device; never hard-code shared secrets in firmware. Use secure elements (ATECC608A/TPM) or protected flash if available.
• Firmware integrity: Enable secure boot and sign firmware. Verify signatures before applying OTA updates.
• Principle of least privilege:
  • Brokers: Use per-device topics and ACLs (device X can only publish to sensors/x/#).
  • Cloud: Scope IAM roles tightly; rotate credentials periodically.
• Network segmentation: Put IoT devices on isolated VLANs; restrict outbound access; disable unnecessary services.
• Logging and monitoring: Device heartbeat topics, LWT messages, anomaly detection on publish rate and payload shape.
• Privacy: Minimize PII; anonymize where possible; encrypt sensitive payload fields end-to-end if required.

Common pitfalls:

• Using public test brokers in production.
• Skipping certificate validation to “get it working.”
• Static default passwords and open OTA endpoints.
• No plan for key rotation or firmware updates.
• Over-the-air updates without rollback or integrity checks.

Build a simple Wi‑Fi sensor that publishes via MQTT

You’ll build an ESP32-based temperature/humidity node that publishes JSON to an MQTT broker and verify data from your laptop.

Hardware you’ll need

• ESP32 DevKit (or ESP8266 NodeMCU, but examples use ESP32)
• DHT22 (AM2302) temperature/humidity sensor
• 10 kΩ pull-up resistor (if your DHT22 board doesn’t include one)
• Breadboard and jumper wires
• USB cable

Optional for production: BME280 (I2C, better accuracy), enclosure, conformal coating for humidity.

Wiring

• DHT22 VCC → ESP32 3.3V
• DHT22 GND → ESP32 GND
• DHT22 DATA → ESP32 GPIO4
• 10 kΩ pull-up between DATA and 3.3V (skip if your module includes it)

Firmware choice

We’ll use MicroPython for fast iteration. You can adapt the logic to Arduino/C++ later with PubSubClient.

Step 1: Flash MicroPython to the ESP32

1. Download a recent ESP32 MicroPython firmware (.bin) from micropython.org.
2. Erase and flash via esptool:
   • pip install esptool
   • Put ESP32 in bootloader mode (BOOT/EN buttons if required).
   • Erase: esptool.py --chip esp32 erase_flash
   • Flash: esptool.py --chip esp32 --baud 460800 write_flash -z 0x1000 esp32-xxxx.bin

Step 2: Connect to the board and set up Wi‑Fi

Use Thonny or mpremote to copy files.

Create boot.py with your Wi‑Fi credentials:

# boot.py
import network, time

def connect_wifi(ssid, password, timeout_s=15):
    wlan = network.WLAN(network.STA_IF)
    if not wlan.active():
        wlan.active(True)
    if not wlan.isconnected():
        wlan.connect(ssid, password)
        t0 = time.ticks_ms()
        while not wlan.isconnected():
            if time.ticks_diff(time.ticks_ms(), t0) > timeout_s * 1000:
                raise RuntimeError("Wi-Fi connection timeout")
            time.sleep(0.3)
    print("Wi-Fi OK, IP:", wlan.ifconfig()[0])

# Replace with your SSID/PASS
connect_wifi("YOUR_SSID", "YOUR_PASSWORD")

Copy to the board:

• mpremote cp boot.py :
• Or in Thonny, open boot.py on the device and paste/save.

Step 3: Write the MQTT sensor publisher

Create main.py:

# main.py
import time, machine, json, ubinascii
import dht
from umqtt.simple import MQTTClient

SENSOR_PIN = 4  # ESP32 GPIO4
sensor = dht.DHT22(machine.Pin(SENSOR_PIN))

CLIENT_ID = b"esp32-" + ubinascii.hexlify(machine.unique_id())
MQTT_BROKER = "test.mosquitto.org"  # For testing only (no TLS, public)
MQTT_PORT = 1883
TOPIC = b"lab/room1/env"

def connect_mqtt():
    # For TLS in production, use port=8883 and ssl=True (requires firmware with SSL)
    client = MQTTClient(CLIENT_ID, MQTT_BROKER, port=MQTT_PORT, keepalive=60)
    client.set_last_will(b"lab/room1/status", b"offline", retain=True)
    client.connect()
    client.publish(b"lab/room1/status", b"online", retain=True)
    return client

def read_sensor():
    sensor.measure()
    return sensor.temperature(), sensor.humidity()

def main():
    client = None
    while True:
        try:
            if client is None:
                client = connect_mqtt()
            t, h = read_sensor()
            payload = json.dumps({
                "device_id": CLIENT_ID.decode(),
                "ts": time.time(),
                "temp_c": t,
                "hum_pct": h
            })
            client.publish(TOPIC, payload)
            print("Published:", payload)
            # Sleep 10 seconds; for batteries, consider deep sleep
            time.sleep(10)
        except Exception as e:
            print("Error:", e)
            try:
                if client:
                    client.disconnect()
            except:
                pass
            client = None
            time.sleep(3)

main()

Notes:

• test.mosquitto.org is for quick experiments only; don’t ship devices against it.
• For TLS/mTLS in production, switch to a private broker and set ssl=True with CA certificate support, or use a robust MQTT library on C++/ESP-IDF.

Step 4: Run and verify

• Reset/reboot the board (power cycle or EN button).
• On your laptop:
  • Subscribe to the topic: mosquitto_sub -h test.mosquitto.org -t lab/room1/env -v
  • You should see JSON messages every 10 seconds.
• Sanity checks:
  • Touch the DHT22 to warm it slightly; temp should rise.
  • If you see checksum errors, lengthen the sampling interval (DHT22 prefers ≥2 s) and check wiring/pull-up.

Step 5: Optional cloud dashboards

• Adafruit IO or HiveMQ Cloud: Create a feed/topic; point your device to the broker and visualize values.
• DIY stack: Mosquitto + Telegraf + InfluxDB + Grafana. Transform JSON with Telegraf processors.

Power, reliability, and scaling

• Power budgeting:
  • Use deep sleep: On ESP32, machine.deepsleep(ms) can cut current to microamps; wake via timer or GPIO.
  • Batch transmissions: Accumulate readings and send one payload to reduce radio-on time.
  • Optimize Wi‑Fi: Static IP and shorter DTIM can improve connect time; beware of AP settings.
• Reliability:
  • Watchdog timers to recover from stalls.
  • Idempotent design for QoS1 duplicates: Include a monotonically increasing sequence or timestamp.
  • Time sync: NTP on boot; store an RTC offset for offline timestamps.
• Maintainability:
  • OTA updates with signed images and rollback partitions (ESP-IDF) or a bootloader strategy.
  • Telemetry on device health: battery voltage, RSSI, firmware version.
• Data quality:
  • Outlier detection and plausibility checks (e.g., −40–85°C for most DHT ranges).
  • Calibrate sensors and record calibration metadata with readings.

Best practices and common pitfalls

Best practices:

• Unique per-device credentials; rotate regularly.
• Least-privilege ACLs on brokers and cloud resources.
• Retained “status/online” messages and LWT for fleet awareness.
• Version your payload schema; include "schema":"env_v1".
• Use CBOR for constrained networks; keep payloads < 51 bytes for LoRaWAN.
• Separate control and telemetry topics (cmd/ and sensors/). Validate commands on-device.

Pitfalls to avoid:

• Hard-coding shared secrets in firmware images.
• Relying on public NTP without fallback; handle failed time sync.
• Over-sampling noisy sensors and flooding the broker.
• Ignoring brown-out: unstable readings when USB power is marginal; add capacitors and BOD configuration.
• Long blocking delays that prevent MQTT keepalive pings; use non-blocking loops or timers.

Where to go next

• Add TLS/mTLS: Use a private broker (Mosquitto with TLS, HiveMQ, EMQX) and provision per-device X.509 certs.
• Scale up: Introduce a device registry, fleet provisioning, and an update service (Mender, Hawkbit, or custom).
• Advanced connectivity: Try Thread/Matter for home automation, or LoRaWAN for remote cabins and farms.
• Edge intelligence: Run lightweight ML models (TinyML) to detect anomalies locally and send only events.
• Production hardening: Enclosures, conformal coating, waterproof connectors, and environmental testing (temperature cycles, vibration).

By understanding sensors, choosing the right connectivity, and building in security from the start, you can move from a single breadboard prototype to a robust fleet. Your simple MQTT sensor is a foundation—iterate on power management, reliability, and secure provisioning to turn it into a production-ready device.