Automated Shutter & Environmental Monitor - shalan/CSCE4301-WiKi GitHub Wiki
Submitted By:
- Mohamed Ayoub - 900212213
- Noureldeen Allama - 900202115
- Sabry Ahmed - 900214356
GitHub Repository:
Abstract:
The Automated Shutter & Environmental Monitor is a comprehensive Internet of Things (IoT) solution engineered to enhance indoor safety and comfort. Leveraging the ESP32 microcontrollerβs dual-core processing capabilities, the system continuously monitors five critical environmental parameters: air quality, temperature, humidity, rain presence, and ambient light intensity. The final implementation features a fully integrated servo motor actuation mechanism that automatically controls window shutters in real timeβclosing during rainfall or poor air quality conditions and opening based on ambient light levels. Additionally, the system employs Wi-Fi telemetry to stream live sensor data to a custom-built web dashboard, enabling remote monitoring, visualization, and manual override control.
Introduction & Background:
Problem Statement:
Unpredictable weather patterns and increasing urban pollution pose significant risks to indoor environments. Sudden rain can cause water damage when windows are left open, while poor air quality can negatively impact occupant health. Furthermore, manual control of shutters for thermal and lighting comfort is inefficient and often overlooked.
Project Objectives:
- Multi-Parametric Sensing: Simultaneous acquisition of temperature, humidity, rain, light intensity, and air quality data.
- Automated Actuation: Immediate mechanical control of window shutters using a servo motor in response to environmental hazards.
- Remote Visualization: A fully functional web dashboard displaying real-time readings for all sensors.
- Alert System: Integrated buzzer alarms and LCD notifications for critical events.
Proposed Components
| Component | Role |
|---|---|
| ESP32-WROOM-32 | Main controller for sensor data acquisition, decision logic, and Wi-Fi communication |
| DHT22 | Temperature and humidity sensing |
| Raindrop Sensor | Rain detection to trigger safety shutter closure |
| LDR Module | Ambient light intensity measurement (day/night detection) |
| Air Quality Sensor (MQ-135 / Dust Sensor) | Monitoring air pollution levels to ensure indoor safety |
| Servo Motor | Physical actuation of the window shutter (open/close control) |
| Active Buzzer | Audible alerts during rain or poor air quality events |
| LCD Display (I2C) | Local display of system status and sensor readings |
| Acebot Wooden House Kit | Physical prototype enclosure and mounting structure |
System Architecture:
High-Level Design:
The system adopts a centralized polling architecture where the ESP32 acts as the core controller, interfacing with both digital and analog sensors. Sensor data is processed locally to make actuation decisions while simultaneously being transmitted over Wi-Fi to a web-based dashboard using WebSocket communication.
System Block Diagram:
Controller Selection Rationale: ESP32 vs STM32 Nucleo
| ESP32 (Why We Chose It) | Shared Capabilities | STM32 Nucleo |
|---|---|---|
| Built-in Wi-Fi & Bluetooth | 32-bit microcontroller architecture | Requires external Wi-Fi module |
| Dual-core processor (up to 240 MHz) | GPIO, ADC, PWM, I2C, SPI, UART | Single-core MCU |
| Native HTTP / WebSocket support | RTOS support (FreeRTOS) | RTOS supported (CMSIS-RTOS) |
| Lower cost for IoT applications | Sensorβactuator system compatibility | Higher cost when networking is added |
| Strong IoT-focused community & libraries | Embedded C / HAL-based development | Strong industrial HAL ecosystem |
Software Stack:
- Framework: ESP-IDF (FreeRTOS)
- Language: C
- Communication Protocols:
- Wi-Fi (Station Mode)
- WebSocket (Real-time dashboard updates)
- PWM / LEDC (Servo motor control)
- I2C (LCD communication)
Hardware Implementation:
Component Selection & Analysis:
- Controller (ESP32-WROOM-32): Selected for its dual-core architecture, built-in Wi-Fi, and robust ADC and PWM capabilities.
Dual-core 32-bit microcontroller with built-in Wi-Fi and Bluetooth. It serves as the main controller responsible for sensor data acquisition, decision-making logic, servo motor control, and real-time web communication.
Interfaces used: GPIO, ADC, PWM, I2C, UART
- Servo Motor (SG90 / MG995): Chosen for precise angular control, enabling defined shutter positions (0Β° closed, 90Β°/180Β° open).
Precision-controlled actuator that rotates to a defined angular position to physically open or close the window shutter.
Interface used: PWM (via GPIO)
- Air Quality Sensor: Configured to detect hazardous gas or particulate concentration spikes, triggering an immediate safety response.
Gas and air pollution sensor used to detect harmful concentrations of pollutants, triggering safety-based automation responses.
Interface used: ADC
- LDR Module: Implemented using a voltage divider circuit connected to the ESP32 ADC to detect day/night conditions.
Light-sensitive resistor whose resistance varies with ambient light intensity, allowing the system to distinguish between day and night conditions.
Interface used: ADC
- DHT22: Used to measure Temp & humidity.
Digital sensor used to measure ambient temperature and relative humidity, providing environmental comfort data to the system.
Interface used: GPIO (single-wire digital protocol)
- Raindrop-Sensor + Control Module: Used to measure water weight.
Resistive rain detection sensor that outputs an analog signal proportional to surface wetness, enabling fast detection of rainfall events.
Interface used: ADC
- Active Buzzer: Sound Notification
Sound-emitting device used to generate audible alerts during rain events or hazardous air quality conditions.
Interface used: GPIO (digital output)
- LCD: Used for Numerical Display.
Character LCD equipped with an I2C backpack for efficient pin usage, displaying live system status and sensor readings.
Interface used: I2C
Software Logic:
Automation Loop:
The system logic operates as a prioritized state machine:
- Safety Priority:
- If rain exceeds a threshold OR air quality is poor β Servo forces shutter CLOSED, buzzer activates.
- Comfort Priority:
- If safety conditions are clear β Light level determines shutter position (Day = Open, Night = Close).
- Manual Override:
- Commands from the web dashboard override all automation logic and lock the servo position.
Connections:
Control Logic Flowchart:
Automated Shutter Control System β Flow Description
1. System Start & Initialization
- The system powers on.
- All sensors, communication modules, and actuators are initialized.
- After successful setup, the system enters the main control loop, which runs continuously.
2. Sensor Data Collection (Main Loop)
During each iteration of the loop, the controller gathers inputs from multiple sources:
- Rain sensor β detects rainfall conditions.
- Light sensor (LDR) β determines ambient light levels (day/night).
- Temperature and humidity sensor β monitors environmental comfort.
- System status checks β verifies connectivity, power availability, and actuator state.
- Manual user input β listens for override or direct control commands.
3. Decision Logic
The controller evaluates all inputs in parallel to determine the system state:
Rain Detection
- If rain is detected, a high-priority safety condition is triggered.
Light Level Evaluation
- Determines whether current conditions indicate day or night.
Manual Override Check
- If manual mode is enabled, user commands can bypass automatic behavior.
Environmental Comfort Logic
- Temperature and humidity values are assessed to support comfort-based decisions.
4. Action Determination
Based on the evaluated conditions, the system decides the shutter position:
- Open
- Close
- Remain in the current position
Decision rules include:
- Rain or unsafe conditions force shutter closure.
- Normal daylight conditions may allow shutters to open.
- Conflicting conditions are resolved using priority rules:
Safety > Automation > Comfort.
5. Actuation
- The selected command is sent to the shutter motor or actuator.
- The system checks whether the action was executed successfully.
6. Feedback & Status Update
- The current shutter state (open/closed) is updated.
- Logs or notifications may be generated.
- The system confirms whether the operation completed normally.
7. Loop Continuation
- After completing one full cycle, the system returns to the main loop.
- Monitoring, decision-making, and control continue indefinitely.
Key Characteristics of the System
- Continuous monitoring with no single-run execution.
- Safety-first design, prioritizing rain detection.
- Manual override support for user control.
- Clear separation of concerns between sensing, decision-making, and actuation.
Prototype:
The Acebot wooden house model serves as a physical prototype for integrating all project components. It allows realistic testing of automation behaviors and environmental responses.
Data Analytics Dashboard:
The web dashboard functions as the central command interface for the system. It displays real-time sensor data using dynamic gauges and indicators, including temperature, humidity, rain status, light intensity, and air quality classification (Good / Moderate / Hazardous).
A dedicated servo control section allows users to remotely open or close the shutter, with the interface reflecting the current shutter state. Connection status indicators confirm active WebSocket communication with the ESP32.
Challenges Faced:
- Servo Power Stability: Initial servo current draw caused ESP32 brownouts. This was resolved using an external power supply with a shared ground.
- ADC Calibration: Multiple analog sensors required careful ADC channel selection and 11 dB attenuation configuration to ensure accurate, non-overlapping readings.
- Sensor Fusion Logic: Establishing a strict priority hierarchy (e.g., rain overriding light-based logic) required robust conditional design.
Code Organization:
File Structure:
Automated-Shutter-System/
βββ .vscode/
β βββ launch.json (VS Code debug configuration)
β βββ settings.json (VS Code workspace settings)
β
βββ build/ (ESP-IDF build artifacts)
β
βββ dashboard/
β βββ mock_server/
β β βββ node_modules/ (Node.js dependencies)
β β βββ package.json (Mock server dependencies & scripts)
β β βββ package-lock.json (Dependency lock file)
β β
β βββ screenshot.js (Dashboard screenshot / test script)
β βββ server.js (Node.js backend / WebSocket server)
β βββ API.md (Dashboard API documentation)
β βββ app.js (Frontend dashboard logic)
β βββ index.html (Dashboard UI layout)
β βββ styles.css (Dashboard styling)
β βββ README.md (Dashboard documentation)
β
βββ main/
β βββ CMakeLists.txt (ESP-IDF component build configuration)
β βββ hello_world_main.c (ESP32 main application entry point)
β
βββ .clangd (Clang language server configuration)
βββ CMakeLists.txt (Top-level ESP-IDF project configuration)
βββ pytest_hello_world.py (Python test script)
βββ README.md (Project-level documentation)
βββ sdkconfig (ESP-IDF configuration file)
βββ sdkconfig.ci (CI-specific ESP-IDF configuration)
Implementation Highlights:
A. Servo Motor Control (PWM):
static void set_servo_angle(int angle) {
uint32_t duty = convert_angle_to_duty(angle);
ledc_set_duty(LEDC_HIGH_SPEED_MODE, SERVO_CHANNEL, duty);
ledc_update_duty(LEDC_HIGH_SPEED_MODE, SERVO_CHANNEL);
}
B. Multi-Sensor Reading & Decision Logic
The main application loop aggregates readings from all connected sensors before executing the automation logic. Safety conditions (rain or poor air quality) are given the highest priority, followed by comfort-based decisions using ambient light levels.
void app_main() {
init_all_sensors();
init_servo();
while (1) {
read_dht11(&temp, &hum);
read_rain_adc(&wetness);
read_light_adc(&lux);
read_air_adc(&air_quality);
send_websocket_json(temp, hum, wetness, lux, air_quality);
if (wetness > 50 || air_quality > THRESHOLD) {
set_servo_angle(0); // Close shutter
} else if (lux > DAY_THRESHOLD) {
set_servo_angle(90); // Open shutter
}
vTaskDelay(2000 / portTICK_PERIOD_MS);
}
}
C. Video:
https://drive.google.com/file/d/1aZY-URjOM_eQmHa7-sO8mBxfJoHnhBqo/view?usp=sharing