Whole House HVAC Software Architecture & Systems Modeling

Published at 11/25/2024

#Programming
#Personal
#Software Engineering
#UML
#Node.js
#Docker
#MQTT

Overview

This project represents the complete Software Engineering specification and architecture for an intelligent, whole-house environmental monitoring and HVAC control system, developed as the capstone project for CSCI441: Software Engineering at Fort Hays State University.

While traditional thermostats measure simple dry-bulb air temperature at a single location, real human thermal comfort and building science depend heavily on psychrometrics (humidity, enthalpy, dew point, air density) and active ventilation balance (ERVs/HRVs, exhaust fans, and pressure differentials).

Rather than jumping directly to ad-hoc code, this project executed a rigorous, textbook software engineering lifecycle: from formal customer requirements and Use Case Point effort estimation to PlantUML conceptual domain modeling, system sequence diagrams, and object-oriented class specifications.

CSCI441 Final Engineering Specification (48 Pages)

Interactive Document Viewer • Fort Hays State University


1. Requirements Engineering & Effort Estimation

The specification decomposed the distributed ecosystem into six decoupled sub-problems:

  1. Sensor Nodes: Distributed STM32/ESP32 boards measuring multi-point environmental metrics.
  2. Control Nodes: Failsafe relay and hardware controllers interfacing physical HVAC equipment.
  3. Network & Message Bus: Lightweight, event-driven MQTT communication topology.
  4. Data Processor: Node.js microservice computing derived psychrometric metrics on the fly.
  5. Time-Series Storage: InfluxDB for long-term thermodynamic historical logging.
  6. User Interface: Home Assistant for dynamic web/mobile controls and Grafana for longitudinal analytics.

Use Case Point (UCP) Estimation

To forecast engineering effort before implementation, I applied formal Use Case Point analysis:

UCP = UUCP * TCF * ECF

(Where Unadjusted Use Case Points are scaled by the Technical Complexity Factor and Environmental Complexity Factor).

  • Unadjusted Actor Weight (UAW): 14 points (3 Simple, 4 Average, 1 Complex actor).
  • Unadjusted Use Case Weight (UUCW): 45 points across 7 formal use cases (UC-1 through UC-7).
  • Technical Complexity Factor (TCF): Calculated across 13 technical factors (T1 distributed systems, T8 portability, T5 code reusability) yielding a TCF of 0.90.
  • Environmental Complexity Factor (ECF): Assessed across 8 team/developer capability factors yielding 1.19.
  • Final Result: 63 Use Case Points, establishing a structured baseline for scheduling, sprints, and Gantt milestones.

2. Domain Analysis & Conceptual Modeling

In Section 6 of the report, the system domain was modeled using formal UML stereotypes (Boundary, Control, and Entity) in PlantUML to establish clean architectural boundaries:

  • Boundary Classes: SystemThresholdInterface, SystemModeInterface, StatusDisplay, and DataReviewDisplay separating presentation from internal state.
  • Control Classes: SystemController responsible for local threshold evaluation, equipment sequencing, and cold-start fallback states.
  • Entity Classes: SensorReader, SensorController, MessageDistributor (Mosquitto), DataProcessor, and LongTermStorage (InfluxDB).

Full Traceability Matrices mapped every functional and non-functional requirement directly to its implementing domain concepts and use case workflows, ensuring zero requirement drift.


3. Interaction & Sequence Diagrams

To prevent race conditions and unhandled network partitions, interaction diagrams modeled real-time messaging across low-level buses and high-level TCP streams:

  • Hardware Interconnects: Sensor breakouts communicating with STM32 microcontrollers over SPI and I2C buses.
  • Event-Driven Publish/Subscribe: Microcontrollers publish periodic heartbeats and raw telemetry over Ethernet via MQTT.
  • High Cohesion Delegation: Microcontrollers are responsible strictly for fast, low-overhead ADC sampling and SPI sensor reads. All computationally heavy floating-point thermodynamics math is offloaded to the Node.js Data Processor running in Docker on host hardware.

4. Object-Oriented Physics & Class Specification

The core computation engine in Node.js was specified via formal class diagrams:

PsyCalc & Value Classes

To prevent unit conversion errors (the classic “Mars Climate Orbiter” pitfall), all thermodynamic properties are wrapped in a strictly typed Value class:

  • Encapsulation: Automatically maintains raw floating-point values, display rounding, unit strings (e.g., Pa vs. kPa, °F vs. °C), and Home Assistant metadata symbols.
  • ASHRAE Thermodynamic Modeling: Implemented non-linear saturation vapor pressure formulations (ANSI/ASHRAE 41.6-2021) for both liquid water and solid ice regimes, calculating derived enthalpy, humidity ratio, and air density in real time upon packet arrival.

5. Architectural Outcomes & Deliverables

The project delivered a working, containerized vertical slice:

  • Dockerized Microservices: docker-compose topology packaging Eclipse Mosquitto, Node.js Data Processor, Home Assistant, and InfluxDB.
  • Hardware Firmware: C++ firmware on STM32 with W5500 SPI Ethernet and SD-card plain-text configuration parser.
  • Verification: Integration test suite verifying that synthetic sensor packets trigger valid psychrometric transformations with median-filtering to reject sensor noise outliers.

The complete report stands as an example of structured systems architecture, demonstrating how complex multi-node IoT and control problems are modeled, estimated, and proven before deployment.

Judson Hartley © 2023-2026