Hybrid Home Control

Hybrid Home Control is an ESP32-based smart-switchboard project. Instead of replacing appliances with smart ones, it adds electronic control to a conventional switchboard while keeping the physical switches fully functional. It was developed between May 5 and July 27, 2026, as a faculty-supervised academic internship. It is not industrial employment.

The internship report covers two connected threads: the design of the distributed node hardware, and the path by which an ESP32 is controlled from a user-facing platform. The second thread is the main focus of the report and of this case study.

Problem#

Commercial smart switchboards, such as the Legrand, Schneider, Havells and Tuya-based products compared in the report’s literature survey, tend to share a few limitations:

• Fixed, non-modular designs, so a single electronics failure often means replacing the whole unit.
• Dependence on proprietary ecosystems, a hub, or continuous internet access.
• Wi-Fi congestion when many devices connect directly to one household router.

The project set out to build a switchboard system that is modular, repairable, affordable, works without a hub, and is compatible with widely used platforms (Home Assistant, Alexa, Google).

System concept#

Each node is an ESP32 that controls the appliances on its own switchboard and also reads the conventional manual switches. In the multi-node design, one node acts as the gateway to the server and forwards commands to the others over a dedicated node-to-node link. If the gateway loses its connection, the remaining nodes are meant to take over that role in turn.

Design requirements recorded in the report:

• Manual control survives failure. Appliances stay operable from physical switches if the network or the hub fails.
• Local and remote control. Remote control through the active platform, and local control through manual switches or, where supported, a local Matter controller.
• Gateway failover and fault tolerance. One node’s failure should not disable the whole installation.
• Modular loads. Different switchboards can support different numbers and types of loads on the same architecture.
• Lighting and fan control. TRIAC-based phase-angle dimming for compatible AC lighting, and ON/OFF plus variable speed for compatible ceiling fans.
• State synchronization across the network.

Node hardware#

Each node combines the following modules.

Hardware design evolution#

The node design went through several iterations. Each one fixed a limitation of the previous design and introduced a new one.

Node discovery and address assignment#

For the nRF24L01 network, the report describes a discovery procedure that assigns each child node a unique address:

1. The parent (root) node broadcasts a discovery message on a default address.
2. Each child waits a random delay of 0–60 ms to avoid colliding on the parent’s receiver, then replies with a randomly generated address.
3. The parent stores the received addresses in a temporary vector. If they are all unique it records that round as an index, and it halts the procedure if the number of responding nodes changes.
4. The parent sends an assignment message carrying the index, and each child keeps the address it generated for that round as its permanent address.
5. The parent confirms with a check-up message and sends its own final address to each child.

Timeouts prevent indefinite waiting. A global uniqueness check against a list of used addresses is described as incomplete. It was intended for the case where child nodes are later promoted to parent.

Evolution of the communication approach#

Communication between the ESP32 and the user-facing platform moved through three approaches. Each was a working implementation, and they were compared on deployment cost, Wi-Fi provisioning, ease of use, interoperability and long-term maintainability. They were stages of research and implementation, not components running together in the final system.

1. Custom web-based control#

The first approach was a custom website hosted on Render’s free tier. The ESP32 connected to it over Wi-Fi and held a persistent WebSocket connection. Unlike request/response polling, this let the server push commands to the device and let the device report state changes back, so control was bidirectional and near-real-time.

• Interface and backend: HTML, CSS and JavaScript on the front end, with Flask providing the Python backend and routes.
• Messaging: Eclipse Mosquitto as the MQTT broker for publish/subscribe messaging and WebSocket-capable client connections.
• Deployment: Docker packaged the services into a reproducible environment for Render.

Backend security work#

The backend used a layered approach to protecting accounts and resources:

• Passwords stored as bcrypt hashes, with short-lived JWTs issued after login.
• Every authenticated request passing through rate limiting, JWT validation, user-status verification and role-based access control before reaching a protected endpoint.
• Audit logs for administrative actions: user registration, device registration and command issuance.
• A unique API key generated per registered device, shown once and stored only as a bcrypt hash, so the original credential cannot be recovered from the database.
• HTTPS intended for production traffic between the web interface and backend, and MQTT access controlled with Mosquitto broker credentials.

Outcome. The prototype showed that an appliance on the ESP32 could be controlled through a remote web interface, with full control over server logic and UI. The weak point was provisioning. When the device moved to another network, or the household Wi-Fi password changed, the ESP32 had to be recompiled with the new credentials. A separate credential-update mechanism was possible but would have added custom setup and maintenance, so the approach was judged unsuitable for plug-and-play installation.

2. ESP RainMaker#

ESP RainMaker was evaluated as a managed alternative. It provides a ready-made device-management framework for ESP32 products, so the user only needs a RainMaker account and there is no custom cloud server to build or maintain. That also reduced cost.

It was not selected because commissioning, where the user pairs the ESP32 through the RainMaker app, followed a platform-specific setup flow that the report judged too complex for the intended users. That contradicted the goal of straightforward installation and daily use.

3. Matter and Home Assistant#

The third approach used Matter, a standard application-layer model meant to let devices from different manufacturers and ecosystems work together. It removed the dependence on one website or one proprietary cloud, and let the ESP32 work with established controllers such as Home Assistant and Google Home instead of needing a dedicated app per ecosystem.

Once commissioned, the ESP32 connected to Home Assistant and operated reliably as a Matter device, and its appliance controls were accessible from Home Assistant. The report notes that this design also makes other Matter-compatible controllers possible. Testing was done with Home Assistant.

Comparison of the three approaches#

Device configuration#

The Matter firmware is configuration-driven, so each hardware channel can be assigned a function without recompiling the C++ program. One firmware image can therefore support several hardware configurations, for example output A as a light bulb and output B as a ceiling fan.

At startup the firmware:

1. Loads the saved JSON configuration from persistent (NVS) storage. It defines each channel’s GPIO pair and the Matter device type to expose, such as a toggle switch or a slider.
2. Validates it, checking for valid GPIO pair values, supported device types and conflicting assignments.
3. Falls back to a default configuration held in persistent memory if the saved one is missing or invalid.
4. Initializes the GPIO pins and dynamically creates the Matter endpoints for each channel.
5. Starts the Matter stack so the device can advertise itself and accept commands from controllers such as Google Home, Apple Home or Home Assistant.

Configuration changes are validated before they are saved. An invalid change is discarded immediately, and the device keeps running on its last valid settings. A valid change is saved, the user is told a restart is required, and the ESP32 restarts and rebuilds its endpoints from the new configuration.

Final communication flow#

1. The ESP32 starts the Matter-enabled firmware and exposes the configured appliance-control endpoints.
2. A Matter controller commissions the device onto the user’s network and stores the operational credentials.
3. Home Assistant, or another compatible controller, sends a command to the matching Matter endpoint.
4. The ESP32 processes the command and updates the relevant appliance output.
5. A local change detected by the ESP32, such as a manual switch press, is reflected in the exposed device state so the controller stays in sync.

Engineering challenges#

• Reliable Wi-Fi provisioning, which the custom WebSocket prototype did not solve adequately.
• A RainMaker onboarding process with more user-facing steps than the target deployment could accept.
• A Matter toolchain and dependencies that were difficult to configure on Windows, and a move to Linux to get a stable build and flashing workflow.
• User-configurable outputs on the ESP32, such as assigning output A to a light and output B to a fan, when Matter provides no runtime changes to outputs.
• Preserving manual switching rather than relying only on network control.
• Communication between embedded devices and backend services, and debugging cross-layer issues spanning ESP32 firmware, messaging and application services.
• Collision-free node discovery and unique address assignment on a shared 2.4 GHz link.

Validation, outcome and limitations#

Testing was done progressively after each phase rather than only at the end:

• The WebSocket prototype verified bidirectional communication between the hosted website and the ESP32.
• RainMaker was evaluated for device control and commissioning. Its main issue was usability, not the communication model.
• The Matter build was flashed from the Linux environment, commissioned with Home Assistant, and used to control the exposed ESP32 functions.

The internship produced a working prototype and hands-on experience across embedded firmware, wireless networking and smart-home integration. The report names these areas for future work:

• Simpler commissioning for non-technical users.
• Documented recovery when the Wi-Fi network changes.
• Testing with more Matter controllers.
• Measuring command latency, state-synchronization delay, reconnection behavior and long-duration reliability, to turn the functional validation into a quantitative evaluation.
• Completing the mesh stage of the node network.

References#

• Matter overview, Connectivity Standards Alliance
• ESP-Matter Programming Guide, Espressif
• Matter integration, Home Assistant
• ESP RainMaker Programming Guide, Espressif