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:

WhatsApp Image 2025-12-22 at 8 48 37 AM

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:

  1. Safety Priority:
    • If rain exceeds a threshold OR air quality is poor β†’ Servo forces shutter CLOSED, buzzer activates.
  2. Comfort Priority:
    • If safety conditions are clear β†’ Light level determines shutter position (Day = Open, Night = Close).
  3. Manual Override:
    • Commands from the web dashboard override all automation logic and lock the servo position.

Connections:

WhatsApp Image 2025-12-22 at 8 50 14 AM

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.

WhatsApp Image 2025-12-22 at 9 03 29 AM WhatsApp Image 2025-12-22 at 9 03 29 AM WhatsApp Image 2025-12-22 at 9 03 46 AM WhatsApp Image 2025-12-22 at 9 04 04 AM WhatsApp Image 2025-12-22 at 9 04 19 AM


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