IOT LAB (EC-705) - Unit 3 Short Notes

UNIT 3: IoT Device Programming, Communication & Cloud Integration (Lab-Focused Notes)

3.1 Advanced Microcontroller/SoC Programming for IoT

Focus: Writing efficient, resource-conscious firmware for devices like ESP32/Arduino/Raspberry Pi Pico.

3.1.1 Interfacing with Sensors

• Digital Sensors: Communicate via protocols like I2C (e.g., BMP280 pressure), SPI (e.g., SD card), or simple GPIO (e.g., PIR motion). Use libraries (Wire.h for I2C) to handle bus communication.

• Analog Sensors: Measure continuous voltage (e.g., LDR, MQ-series gas). Requires ADC (Analog-to-Digital Converter). Key concept: Resolution (e.g., 10-bit ADC → 1024 levels, $$\displaystyle V_{ref} $$ typically 3.3V or 5V).

  • Formula: digital_value = (analog_voltage / V_ref) * (2^resolution - 1)

• Common Sensors: DHT22 (Temp/Humidity - single-wire digital), MQ-135 (Air Quality - analog), HC-SR501 (PIR Motion - digital GPIO).

3.1.2 Actuator Control

• GPIO: Simple ON/OFF control (e.g., LED, relay module for high-voltage appliances).

• PWM (Pulse Width Modulation): Simulate analog output to control speed/brightness. Key parameter: Duty Cycle = (ON_time / Period) * 100%. Used for servo motors (angle control) and DC motor speed.

3.1.3 RTC & Interrupts

• RTC (Real-Time Clock): Independent timekeeping (e.g., DS1307/DS3231 via I2C). Crucial for time-stamping data.

• Interrupts: Hardware/software events that pause normal code execution. Critical for low-power & responsiveness (e.g., wake on button press, sensor threshold).

  • Types: Pin-change, Timer, External.

  • Lab Focus: Avoid delay(); use millis() for non-blocking timing. Structure code as a state machine.

3.1.4 Low-Power Modes & Battery Management

• Sleep Modes: lightSleep, deepSleep (ESP32). CPU/ peripherals shut down, wake on interrupt/RTC.

• Strategies: Reduce sensor polling frequency, turn off unused radios (Wi-Fi/BLE), use RTC memory for state retention.

• Battery: Calculate duty cycle. Example: If device draws 80mA for 1 sec every 60 sec, avg current ≈ (80mA * 1s) / 60s = 1.33mA.

[!TIP] Exam Focus: Be ready to convert a delay()-based blinking LED code into a non-blocking millis()-based state machine. Know how to calculate average current for battery life estimation.

3.2 IoT Communication Protocols & Middleware

Focus: MQTT as the de facto standard for IoT; understanding trade-offs.

3.2.1 MQTT Protocol Deep Dive

• Architecture: Broker (central server) + Clients (publishers/subscribers). Topic (string hierarchy, e.g., home/livingroom/temp).

• QoS (Quality of Service):

  | Level | Guarantee | Use Case | | :--- | :--- | :--- | | 0 (At most once) | Fire-and-forget. Fast, may lose messages. | Non-critical sensor data (e.g., ambient temp). | | 1 (At least once) | Acknowledged. May get duplicates. | Command & control (e.g., "turn on light"). | | 2 (Exactly once) | 4-step handshake. Slow, reliable. | Critical transactions (e.g., financial, metering). |

• LWT (Last Will & Testament): Message broker publishes if client disconnects ungracefully. Used for "offline" status.

• Retained Message: Broker stores last message on a topic. New subscribers get it immediately.

• Topic Design: Use hierarchical, meaningful names. Avoid wildcards (+, #) in client publishes.

3.2.2 HTTP/REST for IoT

• Method: GET (retrieve), POST (send data). Stateless.

• Payload: JSON is standard. Parsing JSON on constrained devices (using ArduinoJson lib) is memory-intensive.

• Trade-off vs MQTT: HTTP is request-response (client-heavy), MQTT is pub/sub (broker-light, async). MQTT better for frequent, small updates from many devices.

3.2.3 CoAP (Constrained Application Protocol)

• Designed for very low-power, lossy networks (like 6LoWPAN).

• RESTful like HTTP but uses UDP (lighter, no connection). Supports observe (long-polling substitute).

• Use: Often in Thread or Zigbee networks.

[!TIP] Common Pitfall: Using HTTP GET for frequent sensor pushes (inefficient). MQTT publish is preferred. Know when to use each QoS level.

3.3 Edge Computing & Local Processing

Focus: Move logic to device to save bandwidth, reduce latency, improve privacy.

3.3.1 Data Pre-processing

• Filtering: Remove noise (e.g., moving average for temp sensor).

• Aggregation: Compute hourly average from minute readings before sending.

• Compression: Send delta (change) from last value instead of absolute.

3.3.2 Simple Rule Engine

• If-Then logic on device: if (temp > 30) { digitalWrite(FAN_PIN, HIGH); }.

• Implementation: Use switch/case or state machine for multiple rules. Avoid complex logic on 8-bit MCUs.

3.3.3 Edge Frameworks (Conceptual)

• AWS IoT Greengrass / Azure IoT Edge: Run Lambda functions or containers on gateway devices (Raspberry Pi). Sync with cloud, run offline.

• Lab Focus: Understand the gateway pattern: sensors → local MCU (Arduino) → gateway (Pi) → cloud.

[!TIP] Exam Question: "Why process data at the edge?" → Reduce cloud costs, faster response, offline operation, data privacy.

3.4 Cloud IoT Platforms & Data Management

Focus: End-to-end data flow from device to dashboard.

3.4.1 Platform Overview

• AWS IoT Core: Device "Thing" registry, MQTT broker, Device Shadow (JSON document syncing desired/reported state).

• Azure IoT Hub: Device Twins (similar to shadow), Endpoints (Event Hub-compatible for data).

• Google Cloud IoT Core: Device Manager, MQTT/HTTP bridges, Cloud Pub/Sub.

3.4.2 Device Provisioning & Management

• Identity: X.509 Certificates (most secure) or Pre-shared Keys (less secure).

• Device Shadow/Twin: JSON document storing device state. Cloud app updates desired, device reports reported. Synchronization handles offline buffering.

  
  // Example Shadow Document
  
  {
  
    "state": {
  
      "desired": {"led": "ON"},
  
      "reported": {"led": "OFF", "uptime": 120}
  
    }
  
  }
  
  

3.4.3 Data Pipeline: Ingest → Store → Visualize

1. Ingest: Device → Cloud MQTT Broker (via TLS).

2. Store:

   • Raw: Cloud Storage (AWS S3, Azure Blob).

   • Time-Series: InfluxDB, AWS Timestream, Azure Time Series Insights. Optimized for timestamped data.

   • NoSQL: DynamoDB (AWS), Cosmos DB (Azure) for flexible device metadata.

3. Visualize:

   • Grafana: Connect to time-series DB (InfluxDB, Prometheus) for rich dashboards.

   • Cloud-Native: AWS QuickSight, Azure Power BI.

3.4.4 Lab Focus

• Steps: 1) Register device & upload certificate. 2) Connect device to cloud broker (Paho MQTT). 3) Publish sensor data to topic. 4) Create rule to store data in DB. 5) Build Grafana dashboard querying the DB.

[!TIP] Critical Concept: Device Shadow is for state sync, not for high-frequency data logging. Use it for configuration (e.g., "set interval to 5 min"), not for storing every temperature reading.

3.5 IoT Security Fundamentals (Practical Lab Perspective)

Focus: Implementing security, not just theory.

3.5.1 Device Identity & Authentication

• X.509 Certificate: Device holds private key, cloud has root CA. Most secure method for cloud platforms.

• Pre-shared Key (PSK): Symmetric key stored on device & cloud. Simpler but riskier if key leaks.

• Provisioning: Secure initial key/certificate loading (manufacturing phase).

3.5.2 Encrypted Communication

• TLS/SSL: Mandatory for MQTT (mqtts:// port 8883) and HTTP (https://).

• On Device: Use libraries that support TLS (e.g., WiFiClientSecure in ESP32). Verify broker certificate (fingerprint or CA).

• Lab: Compare mosquitto_sub -h broker.hivemq.com -t test (unencrypted, port 1883) vs -p 8883 --cafile ca.crt (encrypted).

3.5.3 Principle of Least Privilege

• Device IAM policy: Grant only iot:Publish to its specific topic, not *.

• Cloud rule: Store data only to specific DB table.

3.5.4 Basic Security Testing (Wireshark)

• Capture on port 1883 (unencrypted MQTT): See plaintext topics/payloads.

• Capture on port 8883 (TLS MQTT): See only TLS handshake, payload is encrypted.

• Key Takeaway: Always use TLS in production.

[!TIP] Viva Question: "How do you securely store keys on a device?" → Use hardware secure element (ATECC608A) or secure flash partition. Never hardcode in source code.

3.6 System Integration & Project Prototyping

Focus: Assembling a complete, functional system.

3.6.1 End-to-End Architecture

[Sensors] → [MCU (ESP32)] → [Wi-Fi] → [Cloud MQTT Broker] → [Rule Engine] → [Time-Series DB] → [Grafana Dashboard]

• Edge Layer: MCU handles sensing, local logic, secure comms.

• Cloud Layer: Broker, storage, analytics.

• Application Layer: Dashboard, mobile app.

3.6.2 Integration Tools: Node-RED

• What: Flow-based programming tool for wiring together hardware devices, APIs, and online services.

• Nodes: mqtt in/out, function (JavaScript), dashboard (UI widgets), http request.

• Lab Use: Rapid prototyping. Connect MQTT topic → function (parse/transform) → chart node. No code needed for basic flows.

3.6.3 Debugging Distributed Systems

• Device-Side: Serial monitor (Serial.println()), LED status codes (blink patterns for Wi-Fi/MQTT state).

• Cloud-Side: Check broker logs, cloud rule execution logs, DB query results.

• Tool: Wireshark for network, MQTT.fx or mosquitto_cli for manual testing.

3.6.4 Mini-Project Example: Smart Weather Station

• Hardware: ESP32 + DHT22 + BMP280.

• Code: Read sensors every 5 min, publish JSON to weather/station1.

• Cloud: AWS IoT Core rule → store in DynamoDB.

• Dashboard: Grafana panel showing temp/humidity trends.

• Edge Logic: If temp > 35°C, publish "alert":"heatwave" to separate topic.

[!TIP] Project Tip: Start with a single sensor → MQTT broker → screen (serial/OLED). Then add cloud, then dashboard. Test each layer separately.

3.7 Common Troubleshooting & Best Practices

Focus: Debugging and maintaining IoT systems.

3.7.1 Diagnosing Connectivity Issues

• Wi-Fi: Check SSID/password, signal strength (WiFi.RSSI()), IP address (WiFi.localIP()).

• MQTT Broker: Ping broker IP. Check port (1883/8883) not blocked. Verify client ID unique.

• Common: Connection Refused: Not authorized → Check certificate/key or token.

3.7.2 Data Format Mismatches

• JSON Parsing Errors: Use ArduinoJson deserializeJson() and check return value (DeserializationError::ok). Validate JSON structure with online formatter.

• Topic Mismatch: Ensure publisher and subscriber use exact same topic string.

3.7.3 Power Consumption Analysis

• Tool: Joulescope or cheap USB power meter.

• Measure: Current in different states (sleep, Wi-Fi connect, transmit, deep sleep).

• Optimize: Increase sleep duration, reduce transmit power, use modem-sleep if possible.

3.7.4 Firmware Updates (OTA)

• Concept: Upload new binary to cloud storage; device downloads and flashes itself.

• ESP32: Use ArduinoOTA library (simple) or custom HTTP-based OTA with partition table.

• Critical: Always have a fallback OTA (e.g., button-triggered recovery mode) to avoid bricking.

3.7.5 Documentation & Version Control

• Git: Track code (main branch), config files (secrets.h in .gitignore), and schematic diagrams.

• Document: Pin mapping, power source, cloud topic names, credentials location.

• Lab Report: Include architecture diagram, code snippets (key functions), test results (latency, power).

[!TIP] Best Practice: Never commit secrets (Wi-Fi passwords, cloud keys) to Git. Use environment variables or separate config file ignored by Git. Document everything in a README.md.