This article breaks down a production-style ESP32 platform I recently built, covering the device firmware, backend APIs, frontend dashboard, Firebase integration, and Azure IoT Hub telemetry pipeline. The goal was to design something that behaves like a real-world IoT system rather than a demo project.

Project Link (Live)

Github Repo

High-Level Architecture

At a high level, the system has five major components:

1. ESP32 Device (Firmware in C++)

2. Backend APIs (Next.js on Vercel)

3. Frontend Dashboard (Next.js App Router)

4. Firebase (Auth + Firestore)

5. Azure IoT Hub (Telemetry & Analytics)

The ESP32 never talks directly to Firebase or Azure.
Everything flows through the backend, which acts as a controlled gateway.

Device Onboarding Flow (Captive Portal → Cloud)

1. ESP32 Boots in Setup Mode

When powered on for the first time, the ESP32

• Starts a WiFi Access Point (ESP32-SETUP)

• Hosts a captive portal

• Waits for user configuration

The user provides:

• Home WiFi SSID & password

• Email & password (same credentials used on the dashboard)

2. Device Authentication & Linking

After connecting to WiFi, the ESP32 sends a request to the backend:

POST /api/device/login

The backend:

• Verifies credentials using Firebase Auth REST API

• Retrieves the user UID

• Links the device to the user in Firestore

• Returns success to the device

Important security decision:

• Credentials are never stored on the ESP32

• They are used once and immediately discarded

At this point, the device switches to normal operation mode.

Normal Device Operation

Heartbeat Mechanism

Every 30–60 seconds, the ESP32 sends a heartbeat:

POST /api/device/heartbeat

This updates:

• Device online/offline status

• Last seen timestamp in Firestore

This allows the dashboard to show real-time device status without WebSockets.

Command Polling (Server → Device)

Since ESP32 cannot receive inbound requests reliably behind NATs, the system uses polling.

Every few seconds, the device calls:

POST /api/device/poll

If a command exists:

• Backend returns it

• Marks the command as delivered

• ESP32 executes it locally

This approach is simple, reliable, and production-friendly.

Remote Sensor Switching (Key Feature)

One of the most important design decisions was multi-sensor support without reflashing firmware.

Supported Sensors

• Soil Moisture

• DHT11 / DHT22

• LDR

• BMP280

The active sensor type:

• Is stored in ESP32 flash (Preferences / NVS)

• Can be changed remotely via dashboard commands

• Persists across reboots

Flow

1. User selects a sensor from the dashboard

2. Backend queues a command (SENSOR_DHT11, SENSOR_LDR, etc.)

3. ESP32 polls and receives the command

4. Firmware switches logic and telemetry format dynamically

This turns a single ESP32 into a remotely configurable sensor node.

Device Groups: Managing IoT at Scale

As the number of devices grows, managing them individually becomes inefficient. Real-world IoT platforms rarely operate on a single-device model. Instead, devices are organized into groups based on location, purpose, or integration requirements.

To address this, the platform introduces a Device Group feature, allowing users to logically organize and manage multiple ESP32 devices together.

Firestore Group Data Model

A simplified schema:

groups/
├── {groupId}/
│   ├── name: "Farm Sensors"
│   ├── uid: "user_12345"
│   ├── hasAzureIoT: true
│   ├── azureConnectionString: "HostName=..."
│   ├── createdAt: Timestamp
│
groupDevices/
├── {autoId}/
│   ├── groupId: "group_abc"
│   ├── deviceId: "ESP32_XYZ"
│   ├── addedAt: Timestamp

Groups and Azure IoT Hub Integration

Groups are the control point for Azure integration.

When telemetry arrives from an ESP32:

1. Backend checks which group the device belongs to

2. If the group has Azure IoT enabled:

   • Device is auto-registered in Azure IoT Hub

   • Telemetry is forwarded to Azure

3. If not:

   • Data is stored only in Firestore

This avoids hardcoding cloud credentials per device and keeps sensitive Azure credentials off the ESP32.

Design Principles Behind the Group Feature

The group system follows three core principles:

1. Firmware simplicity
   ESP32 firmware remains generic and reusable.

2. Backend-driven control
   All orchestration happens server-side.

3. Cloud-agnostic design
   Today it’s Azure. Tomorrow it could be AWS or GCP without touching devices.

Telemetry Flow (ESP32 → Backend → Azure)

Step 1: Device Sends Telemetry

The ESP32 sends sensor data to the backend:

POST /api/device/telemetry

Payload structure depends on the active sensor but always includes:

• deviceId

• timestamp

• sensor_type

• sensor-specific values

Step 2: Backend Processing

The backend:

1. Stores telemetry in Firestore

2. Checks if the device belongs to an Azure-enabled group

3. Registers the device automatically in Azure IoT Hub (if needed)

4. Forwards telemetry to Azure IoT Hub

The ESP32 remains completely unaware of Azure.

Step 3: Azure IoT Hub

Once in Azure IoT Hub, the data can be:

• Visualized using Azure Metrics

• Streamed to Power BI

• Processed via Azure Functions

• Routed using Stream Analytics

This separation keeps firmware simple while enabling enterprise-grade analytics.

Frontend Dashboard (Next.js)

The dashboard is built using Next.js 14 App Router and provides:

• User authentication (Firebase Web SDK)

• Device listing with online/offline state

• Last seen timestamps

• Command sending interface

• Sensor switching via quick commands

All API calls from the frontend:

• Use Firebase ID tokens

• Are verified server-side using Firebase Admin SDK

This ensures users can only control their own devices.

Backend API Design

The backend is structured into two API categories:

Device APIs (No Auth Token)

Used only by ESP32 devices:

• /api/device/login

• /api/device/poll

• /api/device/heartbeat

• /api/device/telemetry

User APIs (Auth Required)

Used by the dashboard:

• /api/user/devices

• /api/user/send-command

Ownership checks are enforced at every step.

Firestore Data Model

The database schema is intentionally simple:

• users/{uid}

• devices/{deviceId}

• deviceCommands/{commandId}

This allows:

• Horizontal scaling

• Easy debugging

• Clear ownership boundaries

Why This Architecture Works

This design solves several real-world IoT problems:

• Devices behind NATs

• Secure user-device linking

• Remote device control

• Firmware simplicity

• Cloud scalability

• Vendor lock-in avoidance

Final Thoughts

This project taught me that IoT is more about systems design than sensors. The ESP32 is just one part of a much larger pipeline involving authentication, security, reliability, and data flow.