MQTT Smart Home Project Multi-Room Control Dashboard

Build a complete smart home control system using MQTT protocol that connects multiple ESP32 devices across different rooms, enabling centralized control through a custom web dashboard with real-time status updates.

Project Architecture

System Architecture

Understanding MQTT Protocol

Publish-Subscribe Model

MQTT uses a fundamentally different communication model than HTTP. In HTTP, a client requests data from a server (request-response). In MQTT, devices publish messages to topics, and other devices subscribe to topics they are interested in. A central broker manages all the routing.

Think of it like a newspaper system. Publishers (sensors) send articles (data) to the newspaper office (broker) tagged with section names (topics). Readers (dashboard, other devices) subscribe to sections they care about. The newspaper office ensures every subscriber gets every relevant article without publishers needing to know who the readers are.

MQTT Topic Hierarchy

Topics in MQTT use a hierarchical slash-separated structure, similar to file paths:

Quality of Service Levels

MQTT provides three QoS levels that trade reliability against overhead:

For our smart home, sensor readings use QoS 0 (if one reading is lost, the next one comes in seconds). Control commands (turn light on/off) use QoS 1 to ensure they always reach the device.

MQTT Broker Setup

Mosquitto on Raspberry Pi

The MQTT broker is the central nervous system of our smart home. We use Eclipse Mosquitto — an open-source, lightweight broker that runs efficiently on a Raspberry Pi. The broker handles:

• Client connections — Manages TCP connections from all ESP32 devices and dashboard
• Topic routing — Matches published messages to subscribed clients
• Retained messages — Stores the last message on a topic so new subscribers immediately get current state
• Last Will and Testament — Publishes a predefined message if a device disconnects unexpectedly
• Authentication — Username/password protection for security

Retained Messages Explained

Without retained messages, if you open your dashboard after a device has already published its status, you would see nothing until the device publishes again. Retained messages solve this — the broker keeps the last message on each topic and immediately sends it to new subscribers. When an ESP32 publishes home/living-room/light1/status = "ON" with the retain flag, any dashboard that connects later immediately knows the light is currently on.

Last Will and Testament (LWT)

When an ESP32 connects to the broker, it registers a "will" message. If the device crashes or loses WiFi unexpectedly, the broker automatically publishes this will message. We configure it as: Topic: home/living-room/status, Message: "OFFLINE". This way, the dashboard immediately shows which rooms have connectivity issues.

Device Implementation

ESP32 MQTT Client

Each room's ESP32 performs dual roles — it publishes sensor data and subscribes to control commands. The operational loop:

1. Connect to WiFi — Join home network
2. Connect to MQTT broker — Authenticate and subscribe to command topics
3. Publish sensor data — Temperature, motion, light level every 10 seconds
4. Listen for commands — Callback function triggers when a subscribed topic receives a message
5. Execute commands — Toggle relays, adjust servo position, change PWM for dimming
6. Maintain connection — Send keepalive pings every 30 seconds

Relay Control Logic

Each relay module is controlled by a GPIO pin (HIGH = relay ON = device ON). When the dashboard publishes "ON" to home/living-room/light1/command, the ESP32's callback function:

1. Receives the message on the subscribed topic
2. Parses the payload ("ON" or "OFF")
3. Sets the corresponding GPIO pin HIGH or LOW
4. Publishes confirmation to home/living-room/light1/status (with retain flag)

This confirmation step is critical — it creates a feedback loop so the dashboard always shows actual device state, not just what was commanded.

Dashboard with Node-RED

Node-RED is a visual programming tool that creates the web dashboard. Its flow-based interface connects MQTT subscriptions to visual widgets (buttons, gauges, charts) without writing complex code. The dashboard provides:

• Toggle switches for each light and fan
• Sliders for dimmer control (0-100%)
• Temperature gauges with color coding (blue = cold, red = hot)
• Motion timeline showing activity patterns
• Alert notifications for gas detection or door opening
• Energy usage charts showing daily patterns

Wireless Communication Concepts

Security Considerations

A smart home system requires security to prevent unauthorized access:

Scalability and Extensions

The beauty of MQTT's publish-subscribe model is scalability. Adding a new room requires only:

1. Flash a new ESP32 with the room's topic prefix
2. Subscribe the dashboard to the new topics
3. No changes needed to existing devices or broker configuration

Compare this to a direct HTTP model where adding a device would require updating every other device that needs to communicate with it. With MQTT, devices are completely decoupled — they only know about topics, not about each other.

Key Takeaways

1. MQTT's publish-subscribe model decouples devices from each other, enabling scalable IoT architectures
2. The broker acts as a central router — devices never communicate directly, simplifying network topology
3. Three QoS levels let you choose the right reliability-overhead trade-off for each data type
4. Retained messages and Last Will Testament provide state synchronization and health monitoring
5. Topic hierarchies (home/room/device/property) create intuitive, scalable addressing
6. MQTT overhead is minimal — a publish packet can be as small as 2 bytes of header plus payload
7. Combined with WiFi, MQTT provides sub-second latency for real-time home control from anywhere