Wireless HVAC Health Sensor (FreeRTOS)

Prelude

I am now a senior year (electrical) engineering student at BCIT. Most of my time this year is being consumed by an industry-sponsored capstone project. Hence, when it came time to choose a project for ELEX 7820: Real-Time Embedded Systems, I was very aware of my own bandwidth.

I will be the first one to admit that this is not an exciting project. A wireless HVAC health sensor is about as uninspiring as it gets in terms of novelty, and I knew that going in. The goal here was not to invent something flashy, but to pick a concept that was simple enough to execute reliably while still forcing me to learn the core mechanics of a real RTOS-based embedded system.

I teamed up with Teylor Wong for this project, so a big shoutout to him! 🤝

Introduction

For this project, we designed a real-time wireless HVAC health monitoring system for smart buildings using two Raspberry Pi Pico 2W boards running FreeRTOS. The system employs a distributed embedded architecture with Bluetooth Classic communication.

The first Pico 2W acts as a sensor node (SPP server), collecting operational data relevant to HVAC performance from multiple I²C sensors. These measurements provide key insights into system health: temperature tracks indoor climate conditions, barometric pressure helps detect air circulation and ventilation issues, and vibration analysis monitors fan or motor operation for potential mechanical faults.

The second Pico 2W functions as a display node (SPP client), receiving the sensor data via Bluetooth Classic SPP ( Serial Port Profile) communication and presenting it on an OLED screen connected through I²C. The display node automatically discovers and connects to the sensor node, featuring retry logic with exponential backoff and watchdog-based system recovery after four failed connection attempts. The system includes real-time alarm functionality through a buzzer that activates when temperature or pressure readings exceed safe operating ranges or when vibration thresholds are exceeded. A pushbutton allows manual alarm reset.

GitHub Repo: https://github.com/raghavmarwah/ELEX7820_Project

High-Level Architecture

The system is split into two independent embedded nodes:

Sensor Node

The sensor node is responsible for all data acquisition. It continuously monitors three key indicators of HVAC health:

1. Temperature (BME280)
2. Barometric pressure (BME280)
3. Mechanical vibration (ADXL345 accelerometer)

A DS1307 RTC provides battery-backed timestamps so each data packet is time-aligned, even across power cycles. Vibration is sampled at high frequency and reduced to meaningful metrics (RMS and peak magnitude) over one-second windows. If vibration exceeds 0.35 g, it is immediately flagged as a potential mechanical fault.

All sensor data is packaged into structured packets and transmitted once per second to the display node over Bluetooth Classic SPP.

Display Node

The display node is the system’s user interface. It:

1. Automatically discovers and connects to the sensor node.
2. Displays live data on a 128×64 SSD1306 OLED.
3. Indicates sensor faults and out-of-range conditions.
4. Triggers an audible alarm when thresholds are violated.
5. Recovers from Bluetooth failures without manual reset.

PS: In the diagrams above and the final build below the passive buzzer is replaced with a red LED.

Failure Detection & Recovery

Sensor Fault Handling

Each sensor read cycle begins with an I²C bus scan. If a device disappears:

• Its values are replaced with -1
• The display shows #FAULT#
• The rest of the system keeps running When the sensor reappears, it’s automatically reinitialized, no reboot required.

Out-of-Range Detection

Valid data is still checked against operating thresholds:

• Temperature: -5°C to 50°C
• Pressure: 96–105 kPa
• Vibration peak: > 0.35 g

Violations trigger both a visual #RANGE# warning and an audible alarm. The alarm must be acknowledged via the pushbutton, following fail-safe design principles.

Bluetooth Robustness

The display node implements:

• Automatic device discovery by name
• RFCOMM reconnection with exponential backoff
• Detection of stale ACL connections
• Watchdog-based reboot after four failed retries

This was critical, Bluetooth stacks can and do deadlock, especially on small embedded systems.

Final Build

Demo Video

Closing Thoughts

This project is not something I would point to as my most creative work, and honestly, that is kind of the point. It is a very basic idea, executed deliberately slowly and carefully, with a lot of attention paid to the unglamorous parts of embedded systems: what happens when a sensor disappears, when Bluetooth decides to have a bad day, or when the system needs to recover without anyone watching it.

If anything, this project reinforced for me that interesting embedded work usually hides behind boring problem statements. Nobody gets excited about HVAC monitoring, but the design constraints are real, the failure modes matter, and the system still has to behave sensibly at 2 a.m. when no one is there to reset it.

The lessons from this project will be directly applicable to the industry-sponsored capstone project I am doing this year, where these same concerns around reliability, recovery, and system behavior under failure actually matter. Stay tuned to learn more!