G6 : Smart Home Control System - shalan/CSCE4301-WiKi GitHub Wiki

Project Title: 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
- Division of Labor
- Timeline
Progress Status
- Implementation Progress
- Photos and Video of Current Status
Appendices & References

1. The Proposal

Abstract / Elevator Pitch:

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.

Project Objectives & Scope

Minimum Viable Product (MVP)

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

Functional Requirements

#	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. System Architecture

2.1 High-Level Block Diagram:

Entrance/Exit Detection and Occupancy Counting

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.

Ultrasonic Atomizer

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.

Speaker

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.

Lights

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.

Wi-Fi Connectivity

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.

3. Hardware Design

Component Selection

Sourcing will be through RAM Electronics and the CSCE department primarily.

Component	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)

Schematics & Wiring

Schematic — Entrance/Exit and Occupancy Counting Subsystem

Schematic — Ultrasonic Atomizer Pushbutton Bypass

Final Breadboard Layout — View 1

Final Breadboard Layout — View 2

Final Breadboard Layout — View 3

Power Budget:

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.

4. Software Implementation

4.1 Software Architecture:

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 xQueueReceive to 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_ON or MUSIC_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.

4.2 Development Environment:

ESP-IDF, Kiel, and STM-CubeMX

5. Testing, Validation & Debugging

5.1 Unit Testing:

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:

5.2 Integration Testing:

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.

https://github.com/user-attachments/assets/06513260-aaf8-4326-953b-ea074e909a5c

5.3 Challenges & Solutions:

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.

6. Results & Demonstration

6.1 Final Prototype:

High-quality photos of the completed build can be found in the schematics section.

6.2 Video Demonstration:

Demo 1 — System Operation Without Wi-Fi:

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.

https://github.com/user-attachments/assets/06513260-aaf8-4326-953b-ea074e909a5c

Demo 2 — Wi-Fi Remote Control:

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.

https://github.com/user-attachments/assets/2d3b9c3e-730f-42ab-958f-c35762a349fc

6.3 Performance Metrics:

We implemented everything except scaling this to multiple rooms and the AC controlling.

7. Project Management

7.1 Division of Labor:

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

7.2 Timeline:

Milestones

April 14 — Milestone 1 (Team Formation)

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

April 15 — Milestone 2 (Proposal Presentation)

Delivered in-class proposal presentation
Prepared hardware/software block diagram
Refined proposal according to comments and feedback

April 20 — Checkpoint A

Finalize problem statement & proposed solution
Prepare component list and confirm sourcing
Define functional and non-functional requirements

April 29 — Milestone 3

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

May 6 — Checkpoint B

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

May 13 — Milestone 4

Add WiFi remote control; allow pre-arrival environment adjustment
Finalize mobile app interface and complete wiki & final presentation

8. Progress Status

Implementation Progress

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

Photos and Video of Current Status

Demo video (Google Drive)

Refer to Schematics and Wiring for the breadboard layout.

9. Appendices & References

9.1 Source Code Repository: