G6 : Smart Home Control System
| Name | GitHub |
|---|---|
| Mostafa Gaafar | 900214463 |
| Omar Saqr | 900223343 |
| Farida Bey | 900212071 |
Github Repo: https://github.com/mostafa21314/Guest-Comfort-Management-System
- The Proposal
- System Architecture
- Hardware Design
- Software Implementation
- Testing, Validation & Debugging
- Results & Demonstration
- Project Management
- Progress Status
- Appendices & References
Walking into a poorly lit, stuffy, cold, or hot room is a common experience, especially if we forgot to open the windows or adjust the thermostat. Adjusting lights, temperature, and air quality manually is inconvenient and slow to take effect. Despite the rise of smart homes, most solutions either require constant manual control or are overly complex and expensive for everyday needs. No unified system handles presence awareness, automated control, and energy savings together.
We propose a Presence-Aware Home Control System that automatically manages the ambience of a space based on occupancy and environmental conditions, with remote control for effects that take time. As soon as someone enters, the system welcomes them, turns on the lights, and activates the air atomizer. When the space is vacated, the system automatically powers down all actuators to conserve energy. Users can also remotely pre-configure the environment(especially temperature) before arrival via a WiFi-connected mobile interface.
- Detect human presence using sensors
- Automatically turn on lights when someone enters
- Play a welcome message/music through a speaker
- Activate an air freshener system upon entry
- Count the number of people entering and leaving the room
- Automatically turn off lights, speaker, and air freshener when the room is empty
- Remote control via Wi-Fi to allow users to set the environment before arriving
- Mobile app interface for user-friendly control
| # | Requirement | Description |
|---|---|---|
| FR-1 | Presence Detection | Detect guest entry/exit and maintain an accurate room occupancy count |
| FR-2 | Automated Lighting | Turn on LED/Desk Lamp when occupied and dim; turn off when empty |
| FR-3 | Climate Control(stretch goal) | Activate AC remotely and report temperature readings from DHT22 |
| FR-4 | Air Quality Control | Activate air atomizer based on occupancy or user command; deactivate when room is empty |
| FR-5 | Audio Feedback | Play welcome sound or music on first entry |
| FR-6 | Remote Control | Allow user to send manual override commands and receive live status updates via WiFi/MQTT |
| FR-7 | Auto Shutdown | Power down all actuators automatically when room is unoccupied |
Stretch Goals:
- Start an AC using the remote control feature
- Multi-room extension by replicating the sensor/actuator setup across more than one room simultaneously
## 2.2 System Visualization:
## 2.3 Subsystem Breakdown
This subsystem detects people entering or leaving the room and maintains an accurate count of occupants. It consists of:
- Two IR transmitter–receiver pairs configured as beam-break sensors, mounted on the door frame, one on the exterior side and one on the interior side. The order in which the beams are broken determines the direction of movement (entry vs. exit).
- A PIR (passive infrared) motion sensor used to validate detections and filter out false triggers, such as pets passing through or accidental beam interruptions.
- An occupancy counter that increments on confirmed entries and decrements on confirmed exits, maintaining a real-time count of people inside the room.
This subsystem controls an ultrasonic atomizer that disperses air freshener into the room. It activates automatically when people begin entering, or on demand when the homeowner enables it remotely before arriving home, and it shuts off automatically once the room is empty. It consists of:
- An ultrasonic atomizer module that generates a fine mist to release scent and add humidity to the air.
- A dedicated driver module that supplies the high-frequency drive signal required by the atomizer.
- An NPN transistor wired to bypass the module's onboard pushbutton, allowing the MCU to switch the atomizer on and off electronically rather than mechanically.
This subsystem plays welcoming, calming music for occupants as they enter the room, and stops automatically once everyone has left. It consists of:
- A DFPlayer Mini module that handles audio decoding and playback, controlled by the MCU over a serial (UART) interface.
- A speaker connected to the DFPlayer Mini's amplified output to reproduce the audio.
- A microSD card that stores the welcome and ambient music tracks read by the DFPlayer Mini.
This subsystem automatically switches the room lighting on and off according to occupancy, turning the lights on when the room is occupied and off when it is empty. It consists of:
- A relay module driven by the MCU to safely switch the mains-powered lighting load.
- A lamp that serves as the controlled lighting source.
This subsystem provides remote monitoring and control by linking the system to the cloud. The ESP32 connects to a local Wi-Fi network and authenticates with a Firebase backend, where it publishes its operational logs (occupancy count, sensor readings, and actuator states) and listens for commands issued by the user. This allows the homeowner to view live status and pre-configure the environment before arriving. It consists of:
- The ESP32's onboard Wi-Fi radio, used to join the local network and maintain an internet connection.
- A Firebase backend, which the ESP32 logs into to upload status data and from which it retrieves user commands.
- A bidirectional data link: the ESP32 publishes logs upward to Firebase and subscribes to command updates pushed down from the user-facing interface.
Sourcing will be through RAM Electronics and the CSCE department primarily.
| Component | Image | Category | Purpose | Cost | Datasheet |
|---|---|---|---|---|---|
| IR Beam Break |  |
Sensor | Detect entry/exit direction, count occupants | 50 EGP | — |
| PIR Sensor |  |
Sensor | Supplementary presence detection | — | HC-SR501 Datasheet |
| DHT22 |  |
Sensor | Monitor ambient temperature and humidity | 150 EGP | DHT22 Datasheet |
| ESP32 |  |
Processing | Run all logic, FreeRTOS tasks, WiFi/MQTT | ~$6 (≈300 EGP) | ESP32-WROOM-32 Datasheet |
| STM32 Nucleo (if needed) |  |
Processing | Secondary MCU for distributed control | ~$15 (≈750 EGP) | STM32 Nucleo-64 User Manual |
| Relay Module |  |
Actuator | Switch lights and mist maker | $2 (≈100 EGP) | SRD-05VDC Relay Datasheet |
| TSOP382 IR Receiver |  |
Actuator | Receive IR signals | 30 EGP | TSOP382 Datasheet |
| TSAL6200 IR Emitter |  |
Actuator | Send IR commands to AC unit | 5 EGP | TSAL6200 Datasheet |
| Ultrasonic Atomizer |  |
Actuator | Scent and humidity control | 250 EGP | — |
| DFPlayer Mini |  |
Actuator | Welcome/goodbye audio playback via MicroSD | ~$5.50 (≈275 EGP) | DFPlayer Mini Datasheet (DFRobot) |
The system is currently powered from three separate power sources, with the option to consolidate two of them onto a single supply:
- Power Source 1 — LED Lamp Relay: drives the relay that switches the mains-powered lighting load.
- Power Source 2 — ESP32: powers the main controller, which in turn runs the FreeRTOS tasks and Wi-Fi connectivity.
- Power Source 3 — STM32 Nucleo: powers the secondary MCU, which is responsible for driving the IR emitters. Power Sources 1 and 2 operate at compatible voltage levels and can be grouped onto a single shared supply, reducing the system to two effective power sources. Power Source 3 is kept separate to isolate the IR emitter circuitry on the Nucleo.
Component-level power distribution:
- The speaker (DFPlayer Mini) and the relay module are powered from the 5V terminal of the ESP32, drawing directly from the board's regulated rail.
- The ultrasonic atomizer is powered directly from its own power source via a micro-USB connection, since its peak current draw is best kept off the MCU rail. A full peak-current tabulation of every component will be added once all subsystems are finalized, to confirm that each supply can comfortably handle the combined worst-case load.
The firmware is built on FreeRTOS, structured as two cooperating tasks that communicate through a FreeRTOS queue. This separates time-critical sensor processing from slower, blocking network operations, so that Firebase communication never stalls presence detection.
Task 1 — Sensor Task (main loop)
This is the app_main while(1) loop, which executes every 10 ms using vTaskDelay. Its sole responsibility is real-time presence detection: it reads the IR beam-break sensors and the PIR sensor, debounces the signals, and advances the directional detection state machine. When an entry or exit is confirmed, it packages the result into an event struct and posts it to the shared queue via xQueueSend, then immediately resumes polling. This task never performs any network activity, keeping its loop fast and deterministic.
Task 2 — Network Task (Firebase I/O)
This task is created with xTaskCreate at priority 5 and runs its own loop with a 100 ms vTaskDelay. It handles all cloud communication and performs two independent jobs:
-
Publishing events: It calls
xQueueReceiveto wait for detection events from the Sensor Task and publishes the updated state to Firebase — room status, occupancy count, light state, atomizer state, and music state. -
Polling for commands: Every 3 seconds it independently checks Firebase for remote commands such as
LIGHTS_ONorMUSIC_OFF, executes the requested action, and then deletes the command from Firebase so it is not processed again. This division of labor ensures that the latency-sensitive detection logic in Task 1 is never blocked by the slower, network-bound operations in Task 2.
ESP-IDF, Kiel, and STM-CubeMX
We tested each component separately by running it in isolation for 5 seconds. We did not use a real-time operating system at this stage — we were only concerned with verifying the basic logic and functionality of each component on its own. Videos of each component running separately can be found below:
Speaker_Demo.mp4
Ultrasonic_Demo.mp4
Lights_Demo.mp4
We followed an incremental, bottom-up integration strategy. First, each module was verified independently — the speaker, the lights, the ultrasonic atomizer, the IR beam/PIR detection, and the Wi-Fi connectivity were all tested in isolation to confirm that each one behaved correctly on its own.
Once a module passed its individual test, it was added into the complete workflow one piece at a time. After each addition, we re-ran the full system to confirm that the newly integrated subsystem worked correctly alongside the existing ones and did not interfere with detection timing, power, or the FreeRTOS task behavior. Building up the system gradually in this way made it easy to isolate the source of any new fault to the subsystem that had just been added.
Demo_No_Wifi.mp4
Over the course of development we encountered several hardware and integration issues. The major ones, and how we resolved them, are logged below.
Ultrasonic atomizer driver controlled by a pushbutton. The atomizer's driver module was designed to be operated manually through an onboard pushbutton, with no direct logic-level input for the MCU to use. To make it controllable from firmware, we wired an NPN transistor across the pushbutton terminals so that driving the transistor from a GPIO pin electronically "presses" the button, allowing the MCU to switch the atomizer on and off.
Firebase Wi-Fi integration errors. During Wi-Fi integration we repeatedly hit errors when communicating with Firebase. After debugging, we traced the failures to an insufficient buffer size for the payloads being sent to Firebase — the data exceeded the allocated buffer. Increasing the buffer size to accommodate the full payload resolved the errors.
Speaker shutting off unprompted. The speaker subsystem initially behaved unreliably, cutting out on its own during playback. We found the cause was the volume being set too high for the supply voltage available to the DFPlayer Mini; the resulting current demand caused the module to brown out and switch off. Lowering the playback volume to a level the supply could sustain produced stable, continuous playback.
Replicating the AC's IR control signals. Implementing remote AC control proved far more difficult than expected. We attempted to capture the signals from a real AC remote, but the captured data varied significantly between readings. On investigation, we learned that AC remotes do not send simple per-button codes like a TV remote; instead, each transmission encodes the AC's entire state at once (mode, temperature, fan speed, etc.), followed by an inverted copy of that data that acts as a checksum. We were unable to reliably capture and reconstruct this full state-plus-checksum frame, which is why AC climate control remained a stretch goal rather than a completed feature.
High-quality photos of the completed build can be found in the schematics section.
A short video showing the core automation working locally: presence detection, occupancy counting, lighting, atomizer, and speaker, all triggered by people entering and leaving the room.
Demo_No_Wifi.mp4
A short video showing the remote-control features: sending commands through Firebase to control the lights, atomizer, and music, and pre-configuring the environment before arrival.
Demo_Wifi.mp4
We implemented everything except scaling this to multiple rooms and the AC controlling.
| Name | Contribution |
|---|---|
| Mostafa Gaafar | Project Proposal, Sensors and Actuators needed, Speaker subsystem, Ultrasonic subsystem and bypassing the button, Relay subsystem |
| Omar Saqr | System Architecture, Timeline, Wifi, altering the impleemntation to follow a rtos design, and integration testing |
| Farida Bey | System Architcture, Project Proposal, Relay Subsystem, individual modules testing |
- Formed team of three: Mostafa Gaafar, Omar Mokhtar, and Farida Bey
- Decided on project idea: Presence-Aware Guest Comfort Management System
- Submitted team formation through the wiki page
- Delivered in-class proposal presentation
- Prepared hardware/software block diagram
- Refined proposal according to comments and feedback
- Finalize problem statement & proposed solution
- Prepare component list and confirm sourcing
- Define functional and non-functional requirements
- Implement guest presence detection (IR beams)
- Implement ultrasonic mist maker control
- Implement LED lighting control via relay
- Implement DFPlayer speaker for greeting
- Implement temperature regulation using DHT22 and AC IR emitter
- Add humidity sensing to regulate mist output
- Implement temperature regulation using DHT22 and AC IR emitter
- Implement people counter with entry/exit logic
- Report integration status; run scenario tests & power check
- Add WiFi remote control; allow pre-arrival environment adjustment
- Finalize mobile app interface and complete wiki & final presentation
| Subsystem | Status |
|---|---|
| Entrance/exit detection and occupancy counting | Done |
| Mist maker control | Partially done |
| Speaker control | To be done |
| Lights control | To be done |
| Wi-Fi connectivity | Partially done |
| Temperature control | To be done |
Refer to Schematics and Wiring for the breadboard layout.
Github Repo: https://github.com/mostafa21314/Guest-Comfort-Management-System
Embedded Project Proposal SP26.pdf
Link to control the system through WIFI https://embeddedpro-573f6.web.app/
| Component | Reference |
|---|---|
| ESP32-WROOM-32 | ESP32-WROOM-32 Datasheet (Espressif, official PDF) |
| STM32 Nucleo-64 (MB1136) | UM1724 User Manual — STM32 Nucleo-64 boards (ST, official PDF) |
| DHT22 / AM2302 | DHT22 Datasheet (Sparkfun, official PDF) |
| HC-SR501 PIR Sensor | HC-SR501 Datasheet (PDF) |
| TSOP382 IR Receiver | TSOP382 / TSOP384 Datasheet (Vishay, official PDF) |
| TSAL6200 IR Emitter | TSAL6200 Datasheet (Vishay, official PDF) |
| SRD-05VDC-SL-C Relay | SRD-05VDC-SL-C Datasheet (PDF) |
| DFPlayer Mini | DFPlayer Mini Wiki (DFRobot) |
| Tool | Reference |
|---|---|
| ESP-IDF (Espressif IoT Development Framework) | ESP-IDF Documentation |
| ESP-IDF FreeRTOS | FreeRTOS on ESP32 — ESP-IDF Programming Guide |
| STM32CubeMX | STM32CubeMX Product Page (ST) |
| Keil MDK | Keil MDK Documentation |
| Firebase Realtime Database | Firebase Realtime Database Documentation |