HVAC Optimization: Where Systems Lose Energy
Energy overconsumption for ventilation and air conditioning is almost never associated with equipment wear. At most sites, equipment is operational and delivers design parameters, while consumption remains noticeably above design.
The reason lies in control logic: the automation faithfully follows setpoints that no one has revisited since commissioning.
The most common source of losses is desynchronization of schedules and setpoints. The air handling unit enters operating mode on one schedule, fan coils and terminal units on another, and heating and humidification follow a third.
While one system heats the supply air, another cools the same volume; heating coils and compressors work against each other. Manual setpoints set "by eye" during handover cement this conflict for the entire season.
A separate bottleneck of climate systems is transition periods.
Weather-compensated control along a rigid curve knows nothing about the building's thermal inertia: after a sunny day, the walls release heat for several more hours, while the automation continues to heat based on the outdoor sensor.
Hence overheating, open windows, and nighttime full-capacity runs when the load is already half as high.
Analyzing these losses is the first step in HVAC optimization. This is not about replacing equipment, but about rebuilding control logic for the actual load profile and inertia of a specific building.
What HVAC Optimization Delivers: Measurable Effects
The effect of HVAC optimization is measured not by feelings but by comparing two periods: the baseline — before intervention — and the current one, normalized to the same weather conditions.
Without such normalization, any savings figure remains a matter of dispute, so we calculate using the ASHRAE methodology: it provides a comparable baseline at different outdoor temperatures and different zone loads.
What changes at a site after the loop is brought into a controlled mode:
- Building energy consumption reduction — by 15–30%: at sites with pronounced inertia and daily load fluctuations, the effect is closer to the upper bound; on small loops, closer to the lower bound.
- Elimination of overheating and underheating: manual "by eye" setpoint selection goes away, and zone temperature no longer depends on the shift or who is on duty.
- Reduction of false starts: the number of unit starts and stops drops severalfold, and with it the wear of compressors, drives, and shutoff valves.
- Microclimate stability: deviation from setpoint stays within tenths of a degree instead of degrees, and complaints about stuffiness and drafts do not accumulate by midday.
- Time to reach mode after downtime, load change, or defrost is reduced — equipment reaches its operating point sooner and does not run "on the edge" for an extra hour.
A separate effect is predictability. Energy consumption stops growing with area and number of zones because the loop responds to actual load, not a calendar schedule.
It is on these metrics that we agree on acceptance: before start, we record the baseline; after, we take the same snapshot at the same metering points.
HVAC Control Modes: Comparison of Approaches
HVAC control modes differ in what the system considers input data: time, threshold, current sensor reading, or forecast.
This determines both the achievable energy effect and the scope of dispatching work, so it makes sense to compare approaches only together with their limitations.
| Approach | When it fits | Limitations |
|---|---|---|
| Fixed setpoints | One room, stable load, no sensors | Climate is maintained for the worst case: overheating and overcooling during transition periods of the year |
| Building schedule control | Regular schedule, predictable occupancy | Building inertia: reaching mode takes hours, and the schedule knows nothing about holidays and overtime |
| Actual load control | Zoned rooms, occupancy and air quality sensors available | Response occurs after load changes, sensors drift and require verification |
| Predictive climate control | Inertial building, variable load, telemetry archive available | Requires at least a season of data and a correct model; without a manual loop, forecast error creates overheating risk |
The limitations of automation are not removed by choosing a single approach.
In practice, the schedule remains the base layer, a predictive overlay works on top of it, and if sensors or communication fail, the system returns to fixed setpoints — this is the condition for a safe transition.
That is why we start with telemetry collection and assessment of loop inertia, not with replacing controllers: first we see how much each step delivers, then a decision is made on the depth of automation.
Implementation Stages: From Audit to Handover
HVAC optimization starts not with a model but with a picture of how the building operates now. Until the loops, setpoints, and actual equipment schedule are known, the model learns from noise and produces decisions that operations will disable in the first week.
Therefore, the stages of climate automation implementation are arranged so that each step relies on the verified result of the previous one.
-
Audit of engineering systems. We collect the actual scheme: which units serve which zones, what controls them, where sensors are installed, which loops are connected. We separately record points where data is unreliable.
-
Data collection and preparation. We export history on temperature, flow, valve position, and operating modes, and remove gaps and sensor drift.
-
Equipment control scheme. We agree on what the system is allowed to change: setpoints, fan speeds, damper positions. Critical components remain read-only.
-
Site-specific tuning. The model is adjusted to the building's inertia, heat losses, and load profile, not to an averaged set.
-
Testing on real modes. We launch in observation: the model provides recommendations, and the standard automation executes commands. We compare forecast with actual by zone and see where error grows when weather changes.
-
Handover to operations. Regulations, instructions for engineers, boundaries of manual intervention, and return to standard logic in one step.
Each stage ends with an artifact that can be checked: a scheme, a data quality report, a verification protocol. This is the point where the solution stops being an experiment.
Documentation and Settings Package Following the Work
The work ends not with a report but with a package of artifacts that the operations service can use without us. Everything configured in automation loops and in the control model is handed over in a form suitable for editing and transfer to the next contractor.
- Controller and setpoint configuration for each loop — ventilation, air handling units, fan coils, cooling supply — marked with what changes the algorithm and what is set manually.
- HVAC control schemes: loop logic, priorities, zones, responses to faults, and transitions between occupied and unoccupied modes.
- Access rights differentiation for automation: operations, dispatcher, and contractor roles, boundaries for editing setpoints, and escalation procedure for deviations.
- Climate maintenance regulations: seasonal checks, permissible ranges, sensor control points, and actions when parameters go out of bounds.
- Instructions for the operations service: how to read the panel, what to do when forecast diverges from actual, how to return to the previous set of settings.
- Documentation on engineering systems: mapping of sensors and actuators to I/O points, equipment list, areas of responsibility.
- Backup copies of configurations and change log: it is visible who edited setpoints and when, and rollback to a working state takes minutes.
This is insurance against the main risk: the effect holds only while settings match the real equipment. The package covers handover between shifts and contractors without a repeat survey of the system.
Case Study: How Overconsumption Was Eliminated in an Office Center
The site is an office center of about 18,000 m² with air handling units, chillers, and fan coils by zone. Control operated on a weekly schedule and setpoints set at startup: supply air was fixed, and zones were reheated by local terminal units.
Morning warm-up ran simultaneously with the cooling loop — overconsumption came from opposing heat and cold flows, not losses through the building envelope.
| Metric | Before implementation | After implementation | Observation period |
|---|---|---|---|
| Heating and cooling energy | baseline level | −27% per year | 12 months, full season |
| Hours of simultaneous heating and cooling | 1,240 per year | 90 per year | 12 months |
| Temperature spread in zones | ±2.5 °C | ±0.8 °C | 6 months |
| Nighttime operation of units | 9 h per day | 1.5 h per day | 9 months |
| Microclimate complaints | 40 per season | 6 per season | 12 months |
The control logic was rewritten on top of the existing automation: a weather-compensated curve instead of a fixed supply setpoint, nighttime temperature setback, deadband between heating and cooling, zone setpoints instead of one common setpoint.
The predictive model was trained on the sensor archive from previous seasons; data exchange uses the open BACnet standard — equipment did not have to be replaced.
The metrics were recorded for 12 months: the full heating and cooling season plus transition periods, where algorithms most often make mistakes.
The reduction was achieved not at the expense of microclimate — the temperature spread across zones decreased, and tenant complaints dropped severalfold. In the second season, consumption held at the same level without manual setpoint adjustment.
What to Do If Dispatching Is Already Deployed
We do not demolish or reflash anything: the existing building dispatching system remains the main control loop, and our overlay connects to it as another source of commands via BACnet and existing points.
First we take an actual picture — what setpoints, schedules, and write priorities live in the controllers today, and where the operator intervenes manually. Without this map, any intervention turns into guesswork.
We change exactly two classes of actions: temperature setpoints and equipment start-stop times. Control loops, freeze protection, emergency interlocks, and limit constraints remain untouched — the algorithm physically cannot go beyond the specified boundaries.
If communication with the overlay is lost, the controller continues to operate according to the last standard settings; the site does not remain without control.
We preserve manual modes by priority: operator override is always higher than our commands, and engineering mode at the panel completely removes the zone from algorithm control.
This is a deliberate choice — at sites with process operations and nonstandard layouts, such zones are simply excluded from the loop rather than fitted to the model.
Commissioning is staged: one or two zones or a floor, comparison with the baseline under the same weather and load, and only then expansion.
Rolling back changes means removing the overlay and returning the original setpoints: the list of points and their previous values is recorded in the log before start, so return takes minutes and does not require a site visit for reconfiguration.
Technical Doubts Before Starting Work
Before the start, the customer's technical team has the same questions: data quality from installed sensors, compatibility with existing automation, verifiability of the effect, and responsibility after handover.
Sensor data is incomplete or noisy — can we start?
A telemetry audit shows archive depth, share of gaps, and calibration drift. A short archive does not block the start: we build some loops on a physical model of the equipment, and sensors with unreliable signals are sent for verification.
Will the solution integrate with existing equipment?
We work through the standard interfaces of the existing automation and do not touch safety loops. The solution is installed as an overlay: it reads current state and sends setpoints within a range whose boundaries are specified in the configuration.
How can we be sure the effect is real and not seasonal?
Before launch, we record the baseline for comparable periods — outdoor air temperature, load, operating mode. We compare parallel loops, not "before and after": the report is assembled from the same data used for control.
Who is responsible for operation after handover?
We hand over configurations, schemes, switching policies, and documentation, and train operations. During the warranty period, we monitor model drift; after that, the site operates autonomously, and return to manual mode remains one command away.
Let’s Discuss the Task and Return with a Work Plan
To propose HVAC optimization with a measurable effect rather than a general "we will reduce consumption," we need input data for calculation: telemetry archive from sensors and controllers, current setpoints, schedules, loop schemes, and how the site is operated on weekdays and weekends.
From these, we calculate the baseline consumption profile and the margin built into current control scenarios.
In response, we return not with an "by eye" estimate but with a climate automation work plan: the composition of stages, what we do at each, what data is needed from your side, and where you accept the result.
- Telemetry audit: which points are collected, where gaps are, which loops are actually controllable.
- Baseline consumption model: current profile by fact, so the effect is calculated in percentages.
- Control scenarios: setpoints, schedules, nighttime and weekend modes, loop priorities.
- Implementation plan: pilot on one loop, then rollout, with a rollback zone at each step.
- Result control points: before-and-after snapshot, behavior during transition periods and at peaks.
- Risks and limitations: where automation will not deliver an effect without commissioning or equipment replacement.
We agree on each item with the operations service before start — so that changes do not break the modes on which the process depends. First we fix the composition of stages and control points; we tie timelines afterward.
Describe the task and the current climate control scheme — we will return with a work plan.
