AI energy consumption optimization: where a building loses energy
Excess energy consumption in a building is almost never uniform — it resides in specific modes. Air handling units go into a night run because the schedule was set during commissioning and has not been revised since.
Manual operational setpoints are changed in response to complaints about stuffiness, not based on sensors. Individually, each episode looks like a minor thing.
The most expensive is the opposing operation of loops: fan coils reheat air that the central chiller has just cooled. Losses on ventilation and heating are not visible in monthly reporting — the facility consumes as if at full load, even when no one is inside.
The electrical load graph shows this more accurately than a meter. At the surveyed office facility, the morning peak was twice the average daily level, and the hours when the building was empty accounted for almost a quarter of the annual consumption for ventilation and heating.
Standard automation of the Schneider Electric level allowed most of this to be removed — what was missing was logic that makes decisions based on actual data.
That is, the bottlenecks of engineering systems lie not in hardware but in rules: schedules, loop priorities, setpoints. Below we analyze how AI energy consumption optimization closes them based on telemetry, not on regulations.
What changes after implementation: metrics before and after
Before implementation, the building lives by a schedule and fixed setpoints: equipment goes into mode by the clock, not by actual demand. Because of this, peaks add up — ventilation, cooling, and lighting operate at maximum simultaneously, and power has to be kept with a reserve.
After switching to control based on actual load, simultaneous operation of loops is separated in time. Peak load is reduced by 15–25% without loss of comfort: temperature and air quality remain within the permissible range in all zones.
This is the main contribution to the building's energy efficiency — the effect comes not from a single device but from coordinating modes between systems.
The second metric is reaction time to deviation. Previously, a discrepancy in temperature or flow was noticed during rounds or from complaints, and the reaction took hours.
Now the model compares the actual with the forecast and adjusts setpoints within minutes, and each deviation leaves a trace in the log.
The share of manual adjustments shows how much the system is trusted. If the operator corrects modes by hand every day, the model is not trained on the real profile of the facility.
After tuning on accumulated data, interventions drop to isolated cases, and decisions remain explainable: it is visible which parameter deviated and what the automation changed.
We calculate metrics on a comparable seasonal profile and the same facility boundaries — otherwise the before-and-after comparison proves nothing.
Methods of microclimate control and their limitations
Microclimate almost everywhere relies on three basic mechanisms: a schedule, weather-compensated automation, and local controllers.
Each solves its own task but operates according to an averaged scenario and does not see the actual load of the building — hence overheating in the transitional season and simultaneous heating and cooling in adjacent zones.
| Option | When suitable | Limitations |
|---|---|---|
| System operation schedule | Stable facility schedule: office, academic building, warehouse | Does not react to weather and actual occupancy; when the mode changes, manual reconfiguration of setpoints is needed |
| Weather-compensated automation | Facility where losses occur mainly through the building envelope | Takes into account only outdoor temperature — ignores solar and internal heat gains, thermal inertia of walls |
| Local controllers | Point maintenance of temperature in individual rooms | Loops are not coordinated with each other: one heats, the second cools, equipment wear increases |
| Adaptive model | Variable load, heterogeneous zones, there is telemetry from sensors | Requires data quality and a complete set of sensors, safety boundaries and verification on historical modes are needed |
The mechanisms do not compete but complement each other: the schedule sets basic windows, the weather-compensated curve sets the supply temperature, and local controllers set room-level cutoffs.
Adaptive microclimate control is built on top and shifts setpoints only within limits set by the engineer — therefore it is compatible with already installed automation and does not require its replacement.
Hence the practical conclusion: where there is little data or the facility operates in a stable mode, it is more reasonable to leave the standard automation and get the most out of it with settings.
We connect the model where there is telemetry and variable load — and always with the ability to return to the original setpoints.
How implementation proceeds: from audit to handover
The work proceeds sequentially, and each stage ends with a verifiable result. The point is for the algorithm to learn not from "raw" readings but from a model verified against the actual behavior of heating, ventilation, and cooling loops.
Otherwise, optimization begins to conflict with standard automation — the building goes into overshoot, and the operator disables the mode within a week.
Work procedure
- Audit of engineering systems: we inspect the heating point, air handling units, chillers, and control assemblies, record actual setpoints and daily schedules. The output is a map of zones with excess consumption and a list of loops where there is freedom of control without loss of comfort.
- Metering point scheme: we determine the composition of sensors, the averaging period, and how data is consolidated into a single loop. We separately record gaps and "noisy" channels so that the model does not learn from artifacts.
- Digital building model: we assemble a thermal engineering model with the inertia of the building envelope and zones of different loads. On it, we test the algorithm before going to a live facility.
- Setup of setpoints and loops: we link control actions with existing automation, set priorities, the minimum control step, and hard boundaries that the system does not exceed under any forecasts.
- Verification on real scenarios: we run night unloading, morning warm-up, peak load, and the building exiting weekend mode. We compare deviations in room temperature with the permissible range.
- Handover to operations: we provide documentation, regulations, and training to the engineer — including the procedure for returning to standard control if the system's behavior raises questions.
Schemes, setpoints, and maintenance regulations
What remains at the facility is not an interface but a set of documents by which the operations service runs the system itself: returns a loop to its previous state, finds the cause of a discrepancy in readings, and onboards a new operator. Without it, the algorithm turns into a black box that is simply switched off at the first failure.
We provide everything in an editable form: configuration exports are readable by a text editor, schemes are in generally accepted formats, and instructions are tied to specific cabinets and loops.
- Metering point scheme — assignment of a sensor to the installation location, cabinet, input channel, and conversion formula: a discrepancy in readings is found in minutes, not over a shift.
- Configuration of control loops — setpoints, dead bands, minimum supply limits, priorities between heating, ventilation, and cooling; the export is deployed on a backup controller.
- Operator access rights — roles of operator, engineer, and administrator, log of setpoint changes with author and time.
- Operating instructions — actions in case of sensor failure, transfer of a loop to manual mode, list of deviations considered emergency.
- Maintenance regulations — frequency of sensor verification, inspection of actuators, cleaning of heat exchangers tied to the season.
- Failure map and rollback procedure — how to return the facility to the previous control logic in one operation, plus a list of adjacent systems to which we send data.
Case study: administrative building with round-the-clock load
The facility is an administrative building with a load that does not drop around the clock: server rooms, engineering systems, shifts.
Control relied on rigid setpoints: air handling units and chillers operated according to a schedule and fixed temperatures, regardless of the actual floor occupancy.
Some rooms overheated, and equipment ran at full power during hours when there were almost no people in the building.
What the measurements showed before
The energy efficiency case began with a two-week measurement of standard operation: data was taken with calibrated Fluke instruments and standard data loggers.
The building's consumption followed a flat schedule without a drop during night hours, and in a third of the rooms the temperature went above the comfort range.
Formulations from the report: "Setpoints have not changed since commissioning — the system sees neither the load nor the weather outside" and "At night the load drops almost by half, while the equipment operates in the same mode."
What was changed and what became
The model predicts thermal load based on the schedule, occupancy sensor data, and weather forecast, and recalculates setpoints by zone every quarter of an hour; hard thresholds remained only as emergency boundaries.
Comparison of measurements before and after shows: building consumption decreased by 27%, peak power — by 19%, the share of hours with room overheating decreased from 31% to 4%.
Rollback to the previous logic is one mode switch, so changes were introduced in stages, by equipment groups.
How does adaptive optimization differ from schedule-based operation?
A fixed schedule works on an assumption: at a given time the building behaves predictably.
The controller raises the supply setpoint according to the weather curve, turns on the supply air, and keeps the unit in this mode until the end of the window — the scheme is cheap, the logic is readable without data, and setup comes down to a calendar. As long as the actual load matches the planned one, this is sufficient.
The cost manifests in deviations. A meeting ran two hours late, some meeting rooms are empty, while the supply air runs at full; on another day people occupied a room outside the plan — and the air in it will be renewed only by the next window.
The controller does not know that things changed, it has no feedback based on actual conditions, and the error is not compensated until the engineer manually edits the setpoints.
Adaptive optimization is built around reaction to load changes.
The model compares readings from temperature and air quality sensors, metering data by unit, and the room occupancy calendar, adds a weather forecast for the coming hours, and recalculates setpoints not once a day but as actual data arrives. The mode changes before it becomes uncomfortable or costly.
The key difference is in the architecture. A schedule is a set of constants; optimization is a closed loop forecast — setpoint — actual — correction, where the model learns from the history of a specific building: its thermal mass, facade orientation, system inertia.
It understands that a hall will not cool instantly and reduces supply in advance, not by a timer call.
A schedule answers the question "what time is it," while an adaptive system answers "what is happening now and what will happen in two hours." The former is stable where the load is even; the latter pays off where it changes day to day — and continues to refine modes without human involvement.
Technical doubts to close before the start
Before the start, the customer checks not the model but its behavior at the boundaries: what will happen in an abnormal week, who controls the building if the channel breaks, how the system will coexist with already operating dispatch. We close these questions during design, before the first write to the controller.
How accurate is the load forecast?
The model is trained on the facility's archive: consumption, weather, occupancy schedule, ventilation mode. Over a daily horizon, the average forecast error stays within 5-8%; by the end of the week it grows to 10-12%.
If the archive is patchy, for the first weeks the system only accumulates data and does not issue setpoints — accuracy is more important than an early start.
What happens if communication with the server is lost?
The controller remains autonomous: it holds the last confirmed setpoints and a safe scenario; during a long break, it returns to the standard schedule.
Telemetry is buffered locally and sent after the channel is restored — there are no gaps in the history, and the model does not lose context.
How does the system integrate into existing dispatch?
We do not replace it but build on top: the optimization service writes setpoints through the standard controller interfaces, while safety logic, priorities, and emergency scenarios remain in the dispatch system. The scope of the system's rights is explicitly limited.
Are manual actions of personnel taken into account?
Manual intervention by the operator has unconditional priority and blocks automatic setpoints for a specified interval. Such periods are marked in the log as manual and excluded from training — otherwise the model begins to consider deviations as the norm. The log is available to the operations service.
Let's discuss the task and come back with an estimate and plan
For the scope estimate and implementation plan to be based on the facility, not on averaged assumptions, we need initial data on the building. At the start, what is already available in operations is enough: data sheets, schemes, exports from the dispatch system.
From them it is visible where telemetry is suitable for the AI energy consumption optimization model and where gaps will first have to be closed.
- System schemes — heating, ventilation, cooling, lighting: metering points, sensor types, equipment composition.
- Consumption archives for a year or more, with the step at which telemetry is actually stored — by zones, panels, and large consumers.
- Building operating modes: working hours, night and weekend setpoints, periods of low load, seasonal switchovers.
- Control loops: what is already regulated by automation, what is manual, where variable frequency drive control is installed and what limits it.
- Setpoints and constraints: comfortable ranges of temperature, humidity, and air quality, requirements for air exchange.
- Read access to the dispatch system and alarm logs — to assess the completeness and connectivity of data, not just the volume.
- Known bottlenecks: rooms with complaints about microclimate, equipment with frequent failures.
With this set, we will come back with an estimate and plan: stages of work, scope of tasks by loop, control points, and a list of data that will need to be collected along the way.
If part of the archives is unavailable — tell us right away: we will allocate time for telemetry recovery rather than build the model on guesses.
