Project Overview and Technical Analysis

flux

Below is a copy-ready project specification draft for the ESP32 HVAC controller based on the PDF.
Project Specification ESP32 HVAC Controller for Campus Air-Conditioning Energy Management Project Name
ESP32 HVAC Controller — Smart Air-Conditioning Control and Energy Efficiency System
Project Context
This project is based on the proposal “Controle, Gestão e Eficiência Energética dos Sistemas de Ar-Condicionado do Campus Avaré”, which aims to reduce energy waste from air-conditioning systems at IFSP Campus Avaré through IoT-based monitoring, automation, and data-driven management.
The system will monitor room conditions, detect occupancy, control air-conditioning operation, and send data to a central dashboard for real-time supervision and historical reporting.
1. Purpose
The purpose of this project is to design a low-cost, scalable ESP32-based HVAC controller that helps reduce unnecessary air-conditioning usage in classrooms, laboratories, and administrative rooms.
The controller should:
  • Monitor room temperature and humidity.
  • Detect room occupancy.
  • Communicate with a central server using Wi-Fi and MQTT.
  • Allow remote monitoring through a web dashboard.
  • Support automatic or semi-automatic control of air-conditioning units.
  • Generate data for energy-efficiency analysis.
  • Support future expansion to multiple rooms across the campus.
The project also has an educational purpose, giving students hands-on experience with embedded systems, IoT, energy management, automation, and sustainability.
2. Goals and Success Criteria 2.1 Primary Goals
  • Reduce unnecessary operation of air-conditioning units.
  • Improve visibility of HVAC usage across campus rooms.
  • Provide real-time environmental and occupancy data.
  • Enable automated control decisions based on occupancy and temperature.
  • Support historical reporting for energy-efficiency evaluation.
2.2 Target Outcome
The initial deployment should be a functional prototype installed in at least three campus environments.
A target energy reduction of approximately 20% is expected for monitored air-conditioning systems, depending on room usage patterns and control policies.
2.3 Success Criteria
The project is considered successful if:
  • Each controller reliably reads temperature, humidity, and occupancy data.
  • Data is transmitted to the MQTT broker over Wi-Fi.
  • The dashboard displays room status in real time.
  • The system records historical usage data.
  • The controller can command or influence AC operation safely.
  • The system demonstrates measurable reduction in unnecessary AC runtime.
  • Users can override or adjust operation when needed.
  • The system does not significantly reduce occupant comfort.
3. System Overview
The proposed system consists of distributed ESP32-based controller nodes installed in individual rooms. Each node collects sensor data and communicates with a central MQTT broker. A server-side application subscribes to MQTT topics, stores data in a database, and presents the information through a web dashboard.
The controller can also receive commands from the dashboard or from an automation engine, allowing centralized or semi-autonomous HVAC control.
3.1 High-Level Architecture 
Text
[Temperature/Humidity Sensor]       [Presence Sensor]
              |                           |
              v                           v
        [ESP32 HVAC Controller Node]
              |
              | Wi-Fi / MQTT
              v
        [MQTT Broker / Server]
              |
      -----------------------
      |                     |
      v                     v
 [Database]          [Web Dashboard]
      |
      v
[Reports and Energy Analysis]

Optional:
[Dashboard / Automation Logic]
              |
              | MQTT Command
              v
[ESP32 HVAC Controller]
              |
              v
[AC Control Interface]
4. Core Functional Requirements 4.1 Environmental Monitoring
The controller shall measure:
  • Ambient temperature.
  • Relative humidity.
Initial sensor option:
  • DHT22 temperature/humidity sensor.
Recommended production alternatives:
  • SHT31.
  • SHT40.
  • BME280.
The sensor should be placed away from direct AC airflow, sunlight, windows, and heat-generating equipment.
4.2 Occupancy Detection
The controller shall detect whether the room is likely occupied.
Initial sensor option:
  • PIR motion sensor.
Potential improved options:
  • mmWave presence sensor.
  • Door sensor.
  • CO₂ sensor.
  • Schedule-based occupancy estimation.
  • Manual room status input.
The occupancy logic should include a timeout period to prevent the AC from turning off immediately when motion is not detected.
4.3 HVAC Control
The controller shall support an interface to control or influence air-conditioning operation.
Possible control methods:
  1. Infrared transmitter
    • Sends IR commands to mimic the AC remote control.
    • Non-invasive.
    • Good for split AC units.
    • Requires command learning or protocol decoding.
  2. Relay or contact control
    • Can switch a control signal or power path.
    • Requires strict electrical safety.
    • Not recommended for directly switching high-power mains unless designed and certified appropriately.
  3. Smart plug or external energy-control module
    • Easier energy monitoring.
    • May not support all AC units.
    • Must be rated for compressor load.
  4. Manufacturer interface
    • Most reliable if available.
    • Depends on AC model compatibility.
4.4 Communication
The controller shall communicate wirelessly using:
  • Wi-Fi.
  • MQTT protocol.
The MQTT system should support:
  • Telemetry publishing.
  • Command subscription.
  • Device status reporting.
  • Last-will/offline detection.
  • Room/device identification.
4.5 Dashboard Integration
The system shall provide data to a web dashboard that displays:
  • Room name or ID.
  • Temperature.
  • Humidity.
  • Occupancy state.
  • AC state.
  • Device online/offline status.
  • Historical trends.
  • Energy or runtime estimates.
  • Alerts or abnormal conditions.
4.6 Data Logging
The backend shall store:
  • Timestamped temperature readings.
  • Timestamped humidity readings.
  • Occupancy events.
  • AC state changes.
  • Manual overrides.
  • Device online/offline events.
  • Estimated or measured energy consumption.
5. Non-Functional Requirements 5.1 Reliability
The controller should:
  • Reconnect automatically after Wi-Fi loss.
  • Reconnect automatically after MQTT broker loss.
  • Continue local control using fallback rules if the network is unavailable.
  • Use a watchdog timer to recover from firmware lockups.
  • Report device health periodically.
5.2 Safety
The controller must not expose users to unsafe voltages.
If mains power or AC compressor control is involved:
  • Use proper isolation.
  • Use certified power supplies.
  • Use fuses or protection as required.
  • Use enclosure-rated hardware.
  • Avoid direct mains switching in student prototypes unless supervised by qualified personnel.
Preferred early prototype approach:
  • Use an isolated low-voltage ESP32 power supply.
  • Use IR control instead of switching mains power directly.
5.3 Security
The system should include:
  • MQTT authentication.
  • Unique credentials per device.
  • Restricted topic access.
  • Secure Wi-Fi credentials.
  • Optional TLS encryption where feasible.
  • Protected dashboard login.
  • Firmware update strategy.
5.4 Maintainability
The system should support:
  • Unique device IDs.
  • Configurable room names.
  • Configurable temperature thresholds.
  • Configurable occupancy timeout.
  • OTA firmware updates if possible.
  • Modular firmware structure.
  • Clear wiring and installation documentation.
5.5 Scalability
The architecture should support expansion from 3 prototype rooms to many campus rooms.
Scalability requirements:
  • Standard MQTT topic naming.
  • Centralized device registry.
  • Consistent room metadata.
  • Dashboard filtering by room, building, floor, or department.
  • Database structure suitable for long-term logging.
6. Proposed Hardware Architecture 6.1 Main Controller
Recommended controller:
  • ESP32 module or development board.
Preferred features:
  • Integrated Wi-Fi.
  • Enough GPIO for sensors and control output.
  • OTA firmware capability.
  • Low cost.
  • Strong educational ecosystem.
Example options:
  • ESP32-WROOM-32 module.
  • ESP32 DevKit for prototype.
  • Custom ESP32 PCB for final deployment.
6.2 Sensors Temperature/Humidity Sensor
Initial prototype:
  • DHT22.
Recommended upgrade:
  • SHT31 or SHT40 for better accuracy and reliability.
Typical connection:
  • 3.3 V power.
  • Ground.
  • One digital data line.
  • Pull-up resistor on data line if required by selected sensor.
Occupancy Sensor
Initial prototype:
  • PIR motion sensor.
Typical connection:
  • Power, usually 3.3 V or 5 V depending on module.
  • Ground.
  • Digital output to ESP32 GPIO.
If a 5 V PIR module outputs 5 V logic, level shifting or voltage limiting is required before connecting to ESP32 GPIO.
6.3 HVAC Control Interface
Recommended initial approach:
  • IR LED transmitter circuit controlled by ESP32.
Possible implementation:
  • ESP32 GPIO drives a transistor or MOSFET.
  • Transistor switches current through one or more IR LEDs.
  • Carrier frequency generated in firmware, commonly around 38 kHz depending on AC remote protocol.
Alternative interface:
  • Relay module or solid-state relay for control signaling only, not direct compressor power unless properly designed and certified.
6.4 Power Supply
Prototype options:
  • USB 5 V adapter powering an ESP32 development board.
  • 5 V wall adapter with onboard 3.3 V regulation.
Custom PCB option:
  • 5 V input.
  • 3.3 V regulator for ESP32 and sensors.
  • Input protection.
  • Decoupling capacitors.
  • Status LEDs.
Power supply must be sized for:
  • ESP32 Wi-Fi current peaks.
  • Sensors.
  • IR LED transmit current.
  • Any relay or actuator current if used.
6.5 User Interface
Optional local indicators:
  • Power LED.
  • Wi-Fi/MQTT status LED.
  • Occupancy LED.
  • AC command/activity LED.
  • Manual override button.
Optional local controls:
  • Enable/disable automatic mode.
  • Force AC off.
  • Force AC on.
  • Pair/provision button.
7. Firmware Requirements 7.1 Firmware Responsibilities
The ESP32 firmware shall:
  • Initialize sensors.
  • Connect to Wi-Fi.
  • Connect to MQTT broker.
  • Publish periodic telemetry.
  • Subscribe to command topics.
  • Apply local control rules.
  • Drive the AC control interface.
  • Handle offline fallback behavior.
  • Store configuration where needed.
  • Support safe restart and watchdog recovery.
7.2 Operating Modes
The controller should support:
  1. Monitoring-only mode
    • Reads sensors.
    • Publishes telemetry.
    • Does not control AC.
  2. Manual remote-control mode
    • Receives commands from dashboard.
    • Executes AC on/off or setpoint commands.
  3. Automatic mode
    • Uses occupancy and temperature logic to decide AC behavior.
  4. Fallback mode
    • Used when Wi-Fi or MQTT is unavailable.
    • Maintains safe local behavior.
7.3 Example Control Logic
Basic rule example:
  • If room is occupied and temperature is above upper threshold, AC may be enabled.
  • If room is unoccupied for longer than a configured timeout, AC should be turned off.
  • If temperature is below lower threshold, AC should not be activated.
  • Manual override should temporarily bypass automation.
Example parameters:
Text
occupied_temperature_threshold: 25 °C
unoccupied_timeout: 10 to 20 minutes
minimum_ac_on_time: 5 minutes
minimum_ac_off_time: 3 minutes
manual_override_duration: 30 to 120 minutes
These values should be configurable after pilot testing.
8. MQTT Interface 8.1 Topic Structure
Recommended topic format:
Text
campus/avare/hvac/{building}/{room}/{device_id}/telemetry
campus/avare/hvac/{building}/{room}/{device_id}/status
campus/avare/hvac/{building}/{room}/{device_id}/command
campus/avare/hvac/{building}/{room}/{device_id}/config
campus/avare/hvac/{building}/{room}/{device_id}/event
8.2 Telemetry Payload Example 
Json
{
  "device_id": "hvac-room-101",
  "room": "101",
  "temperature_c": 24.8,
  "humidity_percent": 58.2,
  "occupied": true,
  "ac_state": "on",
  "mode": "automatic",
  "wifi_rssi_dbm": -61,
  "timestamp": "2026-06-03T12:00:00Z"
}
8.3 Command Payload Example 
Json
{
  "command": "set_mode",
  "mode": "automatic"
}
Other possible commands:
Json
{
  "command": "ac_off"
}
Json
{
  "command": "ac_on",
  "setpoint_c": 24
}
Json
{
  "command": "set_config",
  "occupied_temperature_threshold_c": 25,
  "unoccupied_timeout_minutes": 15
}
8.4 Status Payload Example 
Json
{
  "device_id": "hvac-room-101",
  "online": true,
  "firmware_version": "0.1.0",
  "ip_address": "192.168.1.42",
  "mqtt_connected": true,
  "uptime_seconds": 86400
}
9. Backend and Dashboard Requirements 9.1 Backend Services
The backend should include:
  • MQTT broker, such as Mosquitto.
  • Data ingestion service.
  • Database.
  • Dashboard/web application.
  • Optional automation/rules engine.
9.2 Database Data Types
The database should store:
  • Devices.
  • Rooms.
  • Sensor readings.
  • AC state history.
  • Occupancy events.
  • Commands.
  • Configuration changes.
  • Energy estimates or measured energy.
  • User overrides.
9.3 Dashboard Features
The dashboard should provide:
  • Real-time room status.
  • Historical temperature/humidity graphs.
  • Occupancy history.
  • AC runtime reports.
  • Estimated energy consumption.
  • Device online/offline indicators.
  • Manual control buttons.
  • Configuration interface.
  • Reports by room, shift, period, or building.
10. Energy Measurement and Analysis 10.1 Initial Estimation Method
For early prototypes, energy savings may be estimated from AC runtime:
Text
Estimated Energy = AC Rated Power × Runtime
Example:
Text
1.5 kW AC × 4 hours = 6 kWh
10.2 Improved Measurement Method
For more accurate results, add real energy monitoring using:
  • Current transformer sensor.
  • Smart plug with power metering.
  • DIN-rail energy meter.
  • Dedicated power-monitoring IC/module.
10.3 Measurement Methodology
The project should define:
  • Baseline energy use before deployment.
  • Pilot period after deployment.
  • Similar comparison periods.
  • Weather/season adjustment if possible.
  • Room occupancy normalization.
  • Comfort feedback survey.
11. Design Choices and Trade-Offs 11.1 ESP32 vs ESP8266
ESP32 is preferred because it offers:
  • More GPIO.
  • Better processing capability.
  • Bluetooth capability if needed later.
  • More robust development options.
  • Better long-term scalability.
ESP8266 may be cheaper but is less flexible.
11.2 DHT22 vs Higher-Accuracy Sensors
DHT22 is acceptable for educational prototypes because it is simple and inexpensive.
However, for reliable control, SHT31 or SHT40 is preferred because they generally offer better accuracy, stability, and response.
11.3 PIR vs Advanced Presence Detection
PIR is low cost and simple, but it detects motion rather than true presence.
A person sitting still may not be detected. For real classrooms, PIR should be combined with timeout logic, schedules, or better sensors.
11.4 IR Control vs Relay Control
IR control is safer and less invasive because it does not require modifying mains wiring or internal AC electronics.
Relay control may offer stronger control authority but introduces electrical safety, legal, and reliability concerns.
For a student prototype, IR control is the recommended first implementation.
11.5 Centralized vs Local Automation
Centralized control simplifies dashboard logic and policy management.
Local control improves resilience when the network is down.
Recommended approach:
  • Local ESP32 handles basic safety and fallback rules.
  • Server/dashboard handles reporting and higher-level policy.
12. Safety Considerations
The system should avoid direct mains switching during early prototyping.
If the final design interfaces with mains-powered HVAC equipment:
  • Use certified isolation.
  • Use properly rated relays/contactors.
  • Use fuses and surge protection.
  • Use flame-retardant enclosure materials.
  • Follow local electrical codes.
  • Require qualified supervision for installation.
The ESP32, sensors, and user-accessible controls should remain on SELV/low-voltage circuits.
13. Security Considerations
The system should not expose open MQTT control topics on an unsecured network.
Minimum security requirements:
  • MQTT username/password authentication.
  • Unique credentials per device.
  • Dashboard login.
  • Network segmentation if possible.
  • Restrict command topics.
  • Disable anonymous broker access.
  • Avoid hardcoding shared credentials in public firmware repositories.
Future security improvements:
  • TLS MQTT.
  • Certificate-based authentication.
  • Secure OTA updates.
  • Signed firmware.
  • Device provisioning workflow.
14. Performance Considerations
Important performance parameters:
  • Sensor update interval.
  • MQTT publish interval.
  • Wi-Fi reconnection time.
  • Command response latency.
  • Dashboard refresh latency.
  • Database write frequency.
  • MQTT broker capacity.
  • ESP32 memory usage.
  • OTA update reliability.
Suggested starting values:
Text
Sensor sample interval: 10 to 30 seconds
Telemetry publish interval: 30 to 60 seconds
Status publish interval: 60 to 300 seconds
Occupancy timeout: 10 to 20 minutes
Dashboard refresh: 5 to 30 seconds
15. Prototype Implementation Plan Phase 1: Requirements and Survey
  • Identify target rooms.
  • Record AC models and rated power.
  • Identify control method for each AC unit.
  • Interview users about comfort requirements.
  • Define pilot success metrics.
Phase 2: Bench Prototype
  • Build ESP32 prototype with temperature/humidity sensor.
  • Add PIR sensor.
  • Connect to Wi-Fi.
  • Publish MQTT telemetry.
  • Display data in simple dashboard.
Phase 3: AC Control Prototype
  • Implement IR transmitter or selected safe control interface.
  • Decode or reproduce AC remote commands.
  • Add manual override behavior.
  • Test AC control in a controlled environment.
Phase 4: Dashboard and Database
  • Store telemetry.
  • Display live status.
  • Add historical graphs.
  • Add runtime and energy reports.
  • Add manual command interface.
Phase 5: Pilot Deployment
  • Install in selected rooms.
  • Monitor system reliability.
  • Compare AC runtime and energy usage before/after.
  • Collect user feedback.
  • Tune control parameters.
Phase 6: Documentation and Dissemination
  • Produce user guide.
  • Produce installation guide.
  • Document firmware and dashboard.
  • Present results to the campus community.
  • Prepare educational materials for students.
16. Open Questions
The following items must be resolved before hardware finalization:
  1. Which AC models will be controlled?
  2. Do the AC units support IR remote control?
  3. Is direct electrical control required, or is IR control acceptable?
  4. Will actual energy be measured or only estimated?
  5. What dashboard technology will be used?
  6. What database will be used?
  7. Will the system run on the campus network or a dedicated IoT network?
  8. What cybersecurity requirements does the institution require?
  9. What enclosure and installation method will be used?
  10. Who will maintain deployed devices?
  11. Are manual wall controls required?
  12. What comfort temperature range should be used?
  13. What accessibility requirements must be considered for students with specific educational needs?
17. Recommended Hardware for First Prototype Required
  • ESP32 development board.
  • Temperature/humidity sensor.
  • PIR motion sensor.
  • IR LED transmitter circuit or selected AC control interface.
  • 5 V USB power supply.
  • Jumper wires or prototype PCB.
  • Enclosure.
Recommended Additions
  • Status LEDs.
  • Manual override button.
  • Buzzer or indicator for diagnostics, if appropriate.
  • Current sensor or smart meter for energy validation.
  • Better temperature/humidity sensor such as SHT31/SHT40.
  • Watchdog-enabled firmware.
  • OTA update support.
18. Future Enhancements
Potential future improvements include:
  • True energy metering per AC unit.
  • More accurate occupancy sensing.
  • CO₂-based air-quality monitoring.
  • Predictive control based on schedules.
  • Integration with institutional room-booking systems.
  • Weather-aware HVAC control.
  • Machine-learning-based optimization.
  • Mobile dashboard.
  • OTA firmware update platform.
  • Centralized device provisioning.
  • Multi-campus deployment.
  • Integration with building management systems.
  • Support for demand-response energy policies.
19. Risks and Mitigations

Table

RiskImpactMitigation
PIR misses stationary occupantsAC may turn off while room is occupiedUse timeout, schedule, manual override, or better presence sensor
Wi-Fi instabilityData/control interruptionAdd reconnect logic and local fallback
Unsafe AC controlElectrical hazardPrefer IR control; isolate all high-voltage interfaces
Inaccurate energy estimatesWeak savings claimAdd real energy measurement
Sensor placement errorPoor control decisionsDefine installation guidelines
MQTT security weaknessUnauthorized controlUse authentication and restricted topics
User discomfortLow adoptionInclude manual override and comfort surveys
Device maintenance burdenLong-term failureUse OTA updates, diagnostics, and modular deployment
20. Conclusion
The ESP32 HVAC Controller is a practical IoT system intended to improve energy efficiency in campus air-conditioning systems. It combines embedded sensing, Wi-Fi communication, MQTT messaging, dashboard visualization, and optional AC control.
The recommended first implementation should focus on a safe, non-invasive prototype using ESP32, temperature/humidity sensing, PIR occupancy detection, MQTT telemetry, and IR-based AC control. After validating the concept in a few rooms, the system can be expanded with better sensors, real energy measurement, secure device management, and scalable dashboard infrastructure.
Save project spec
One-page version
Add cost table
Translate to Portuguese
Schematic block diagram
Sign up to send

To get started, talk to Flux or create a New Document.

Documents

    Documents are markdown text files which describe project goals, capture details, or even simulation outputs.

    Assets

    No assets added.

    Vibe Coding Hardware

    Vibe Coding Hardware thumbnail
    Welcome to your new project. Imagine what you can build here.

    Properties

    Properties describe core aspects of the project.

    Pricing & Availability

    Distributor

    Qty 1

    Arrow

    $2.13

    Digi-Key

    $4.74

    LCSC

    $2.76

    Mouser

    $5.62

    Verical

    $2.25–$3.80

    Controls