IoT Lab (IT-705) - Unit 3 Short Notes

3.0 Unit Objectives & Key Concepts

• Core Transition: Move from theoretical IoT concepts to hands-on system building and integration.

• Integration Pillars: Successfully connect sensors/actuators → microcontrollers → communication protocols → cloud platforms.

• Practical Security: Implement foundational security measures at the device, communication, and cloud layers.

• System Thinking: Design, troubleshoot, and document a complete end-to-end IoT application.

3.1 Hardware Platform Deep Dive & Interfacing

Microcontroller/Board Selection & Setup

Lab Focus: Blink LED, read serial monitor, control GPIO pins.

Sensor & Actuator Interfacing

• Sensors:

  • Digital: On/Off or discrete values (e.g., PIR motion, Soil Moisture digital output). Use digitalRead().

  • Analog: Continuous voltage range (e.g., DHT11 humidity/temp, LM35 temp, Potentiometer). Use analogRead() (0-1023 → 0-5V/3.3V).

  • Communication Protocols: I2C (multiple devices, 2 wires: SDA/SCL), SPI (high-speed, 4+ wires), UART/Serial (point-to-point).

• Actuators:

  • Relays: Switch high-voltage/current loads. Use transistor driver (e.g., ULN2003) with flyback diode.

  • Servo Motors: Precise angle control. Use Servo.h library (PWM signal).

  • DC Motors: Speed/direction control. Must use driver module (L293D, TB6612) for current isolation.

• Power Management:

  • Board Power: USB (5V) or VIN (7-12V).

  • Peripherals: Check voltage/current requirements. Use external power supply for motors/relays. Use voltage regulators (e.g., 7805) if needed.

  • ⚠️ Common Pitfall: Drawing too much current from board's 5V/3.3V pin can damage it.

Lab Focus: Read DHT11 data, trigger relay when PIR detects motion, control servo based on potentiometer.

3.2 IoT Communication Protocols (Implementation Focus)

Short-Range Wireless

• Bluetooth Classic vs. BLE:

  | | Bluetooth Classic | Bluetooth Low Energy (BLE) | | :--- | :--- | :--- | | Use Case | High-throughput audio, file transfer | Low-power, intermittent data (sensors) | | Connection | Pairing (bonding) | Advertising (broadcast) + Connection | | Power | High | Very Low | | IoT Fit | Poor | Excellent (beacons, sensor data) |

  • BLE Terms: Peripheral (device like sensor), Central (phone/gateway). Services (collection of data), Characteristics (individual data points).

• Wi-Fi:

  • Modes: Station (STA) - connect to router; Access Point (AP) - create hotspot.

  • Implementation: Use WiFi.h (ESP) or wireless tools (RPi). Connect via SSID/Password.

  • Protocols: HTTP (client request/response), Web Server (host simple HTML page on device).

Long-Range / LPWAN

• LoRa (Long Range):

  • Concept: Chirp Spread Spectrum modulation. Excellent range (>10km), low power, low data rate.

  • Module: SX1278 (common with ESP32).

  • Key Parameter - Spreading Factor (SF): SF7 to SF12.

    • ↑ SF → ↑ Range, ↑ Time-on-Air, ↓ Data Rate.

    • ↓ SF → ↓ Range, ↓ Time-on-Air, ↑ Data Rate.

  • Data Rate Formula (approx):

$$ \text{Data Rate (bps)} \propto \frac{\text{Bandwidth}}{2^{SF}} $$

*   **Topology:** Star-of-stars (all nodes to gateway).

• NB-IoT: Cellular-based. Requires SIM, network operator. Good coverage, moderate data rate, higher power than LoRa.

Application Layer Messaging

MQTT Deep Dive:

• Broker: Central server (e.g., Mosquitto, cloud broker).

• Topic: Hierarchical string (e.g., home/livingroom/temp).

• QoS Levels:

  • 0 (At most once): Fire-and-forget. Fast, possible loss.

  • 1 (At least once): Guaranteed delivery, possible duplicates.

  • 2 (Exactly once): Guaranteed, no duplicates. Highest overhead.

• LWT: Message broker publishes if client disconnects ungracefully (e.g., home/sensor/status = offline).

Lab Focus: Publish sensor data to sensors/temp (QoS1), subscribe to cmd/led to toggle onboard LED.

3.3 Edge-to-Cloud Integration

Cloud IoT Platform Selection & Configuration

• Major Platforms: AWS IoT Core, Azure IoT Hub, Google Cloud IoT Core, ThingsBoard (open-source), Blynk (mobile-focused).

• Common Concepts:

  1. Device Registry/Thing: Register device with unique ID.

  2. Authentication: X.509 Certificates (most secure) or Pre-shared Keys (PSK).

  3. Device Shadow / Twin: JSON document storing desired (from cloud) and reported (from device) state. Enables offline sync.

  4. Rules/Triggers: Define actions on incoming data (e.g., WHERE temperature > 30 → SNS:SendEmail).

Data Pipeline

Device (MQTT/HTTP) → Cloud Broker → Rules Engine → (Action: DB/Function/Alert)

                                      ↓

                                Dashboard (Visualization)

Lab Focus: Register ESP32 in AWS IoT Core, attach certificate, connect using PubSubClient library, view data in AWS IoT SiteWise dashboard.

3.4 IoT Security Fundamentals (Practical)

Device-Level Security

• Secure Boot: Verify firmware signature on boot.

• OTA Updates: Signed, encrypted firmware updates over-the-air.

• Credential Storage: Never hardcode keys/certs in source code. Use:

  • Secure Element/TPM chip (e.g., ATECC608A).

  • Encrypted flash partitions.

  • Environment variables (less secure).

Communication Security

• TLS/SSL: Mandatory for MQTT (MQTTS, port 8883) and HTTPS.

• Authentication:

  • Certificate-Based (X.509): Most secure. Device holds private key, cloud has CA.

  • Token-Based (JWT/OAuth): Temporary tokens, good for mobile apps.

• ⚠️ Critical Pitfall: Using unencrypted MQTT (port 1883) exposes all data and credentials.

Cloud/Platform Security

• Principle of Least Privilege: Device policies/roles should have only necessary permissions (e.g., iot:Connect, iot:Publish to specific topic).

• Secure API Keys: Rotate regularly, store in secrets manager (AWS Secrets Manager, Azure Key Vault), never in client code.

Lab Focus: Generate certificate in AWS IoT, convert to .pem format, configure WiFiClientSecure in ESP32 code to connect to mqtts://<endpoint>:8883.

3.5 Data Management & Visualization

Local Storage

• SD Card Module: Use SD.h library.

• Format: Simple CSV (Comma Separated Values) for easy import.

  
  timestamp,temperature,humidity
  
  2023-10-27 10:00:00,25.5,60
  
  

Cloud Database Options

Visualization Tools

• Platform-Native: AWS IoT SiteWise/QuickSight, Azure IoT Central dashboards.

• External:

  • Grafana: Industry standard. Connects to InfluxDB, Prometheus, MQTT, APIs. Highly customizable.

  • Node-RED Dashboard: Flow-based, easy UI widgets. Integrates with MQTT, HTTP, databases.

Lab Focus: Configure InfluxDB output in Node-RED, build Grafana dashboard with time-series graphs and stat panels.

3.6 System Integration & Mini-Project

End-to-End System Design

1. Define Requirements: What to measure? Where to send data? What action? (e.g., "Monitor soil moisture, alert if <30%").

2. Select Stack:

   • Hardware: ESP32 (Wi-Fi + enough GPIO).

   • Sensor: Capacitive Soil Moisture Sensor (analog).

   • Protocol: MQTT (QoS1) to cloud broker.

   • Cloud: ThingsBoard (open-source, easy rules/dashboards).

   • Actuation: Rule → send MQTT command → relay → water pump.

3. Architecture Diagram (Conceptual):

   
   [Soil Sensor] → [ESP32 (MQTT Pub)] → [ThingsBoard Cloud]
   
                                         ↓
   
                                 [Rule Engine] → [MQTT Sub] → [Relay] → [Pump]
   
                                         ↓
   
                                 [Dashboard: Moisture Graph + Alert]
   
   

Common IoT Application Scenarios

• Smart Agriculture: Sensor (Soil Moisture) → LoRa (long range) → Gateway → MQTT → Cloud → SMS/Email Alert (via Twilio/SendGrid rule).

• Home Automation: BLE sensor (Door contact) → Mobile App (Central) → MQTT → Cloud → Rule → MQTT → Smart Plug (Relay).

• Environmental Monitoring: Multi-sensor (DHT11, BMP180, MQ-135) → ESP32 → HTTPS POST to custom Flask server → Database → Grafana.

Troubleshooting Methodology

1. Isolate the Layer: Device → Network → Cloud → Application.

2. Serial Debug: Serial.println() at every step (sensor read, connect, publish).

3. Network Analysis: Use Wireshark to see MQTT/HTTP packets (filter mqtt or http).

4. Cloud Logs: Check platform's device logs, rule engine logs, connection logs.

5. Common Failure Points:

   • Power: Insufficient current for sensors/motors.

   • Wiring: Loose connections, wrong pins (check pinout!).

   • Network: Wrong SSID/password, firewall blocking ports (1883/8883).

   • Credentials: Expired certificates, mismatched device ID.

   • Code: Blocking delays (delay()), not handling Wi-Fi/MQTT reconnects.

Lab Focus (Mini-Project): Document complete project: Bill of Materials (BOM), Fritzing diagram, code snippets (init, loop, callback), cloud setup screenshots, final dashboard, troubleshooting log.

Exam Tip: Be prepared to draw a system architecture diagram for a given scenario (e.g., "Design a smart lighting system"). Label all components and protocols clearly. Know the difference between MQTT QoS levels and when to use each. Understand LoRa's trade-off (SF vs. Data Rate). Always mention TLS for any production-level communication.