Reduce building energy consumption by 30% with AI control

AI smart building: when automation runs idle

Engineering systems in most buildings are controlled by schedules and rigid setpoints established during commissioning. Air handling units, fan coils, and the heating unit maintain preset values regardless of whether people are in the room and how the facade behaves in the sun.

The automation works properly — and that is precisely why the building's energy consumption barely changes for years.

This leads to heat overconsumption: at night, on weekends, and in the shoulder season, the system heats empty rooms, and after ventilation restores the previous curve with a margin.

The sun has warmed the south side — cooling is supplied based on a sensor located on the north side. Individually these are trifles; together they are a stable share of annual consumption.

Legacy dispatching reinforces the picture: the heating unit, air handling units, and cooling supply each live in their own loop. The dispatcher sees alarms but not overconsumption — data is not consolidated anywhere into an overall building picture.

Schedule-based control remains the only mode because there is simply no actual data on where and when heat and cooling are needed.

An AI smart building starts from the opposite: telemetry from engineering systems is linked with weather, occupancy, and room modes, and control is shifted from a schedule to actual demand. We break down how this is covered and what it delivers in numbers.

Predictive climate control: measurable effect

Predictive climate control is built not on "schedule-based" setpoints but on load forecasting: the model takes into account the building's thermal inertia, solar radiation, the number of people according to access data, and a weather forecast for 6–12 hours ahead.

The controller reduces or increases the capacity of the air handling ventilation and chiller in advance — the loop's inertia responds without overshoot, and the indoor microclimate remains within the specified range.

We connect to existing engineering systems via open BACnet; there is no need to change sensors or automation cabinets.

Reducing energy consumption without losing comfort

Before implementation, heat and cooling were supplied cyclically, according to the working hours schedule: load increased in steps, peaks coincided, and equipment ran at increased capacity longer.

Load forecasting for engineering systems provides a preemptive start — by the time people arrive, the air is already at the right level rather than ramping up in the first hours.

At sites with continuous measurement, heating and cooling consumption fell by 27–34% over the season, and temperature deviations decreased from ±2.5 °C to ±0.8 °C.

Fewer equipment failures and unplanned callouts

Equipment failures almost always signal themselves in advance: compressor current rises, time to reach mode lengthens, pressure drop across the filter falls.

The model tracks these trends and creates a work order before emergency protection trips — maintenance shifts from emergency to planned.

Unplanned callouts were halved, microclimate downtime decreased from 40 hours per year to 6–8, and pump service life increased due to fewer starts under load.

Deployment options: cloud, local module, hybrid

The platform on which the model computes determines what happens to control if the channel breaks.

Cloud-based building control keeps all logic on the service side, a local computing module moves computation to the site, and a hybrid scheme divides tasks between levels — and each of them sets its own requirements for communication channels and storage of site data.

How to choose the mode: criteria and limitations

Calculate three values: the number of polling points, the allowable pause in response, and the depth of history for model retraining.

The first sets requirements for communication channels and the redundancy scheme, the second answers whether computation is needed on site, and the third determines storage of site data — how much is kept locally and what goes to the center.

For a single site with a backup channel, it is reasonable to start with the cloud; for dense telemetry and sensitive data, with a local module; for multiple sites and consolidated reporting, with a hybrid.

Implementation stages: audit, scheme, configuration, handover

Implementation proceeds in stages, and each ends with a verifiable result: a report, a scheme, a working loop. Until a loop has passed the pilot, we do not replicate the solution to the entire building — the error remains local.

1. Audit of engineering systems. Equipment composition, actual operating modes, data collection points, quality of existing dispatching. The output is a load map and a list of loops with control potential.
2. Integration scheme. We determine where data comes from and how control actions are returned: new sensors, existing controllers, gateways. We agree responsibility boundaries with the operations service.
3. Configuration of control loops. Setpoints, priorities, and constraints — by temperature, humidity, occupancy schedule. Every automation decision retains an explanation understandable to an engineer.
4. Pilot on one loop. The model learns on real site data, not on averaged assumptions.
5. Hypothesis validation. We compare consumption before and after over comparable periods and weather conditions, and cut off seasonality. If the gain is not confirmed, we correct the logic rather than expand the scope.
6. Replication. We transfer the proven rules to the remaining loops, adjusted for their inertia and mutual influence.
7. Operations handover. We train the service, provide documentation, and keep manual control available at any time.

What we do during the pilot stage on one loop

We select the loop with the highest load and clear telemetry. For two to three weeks, the automation proposes setpoints, the engineer confirms or rejects them, and we analyze discrepancies — hypotheses are tested before the mode goes to autopilot.

What we hand over to the customer: configurations and regulations

Handing over a site is not a demonstration of a working model but the transfer of everything the operations service will use going forward. If, after the team leaves, control relies on someone's memory and the contractor's access, the system degrades within the first season. Therefore the package includes:

• Controller configurations: setpoints, schedules, scenarios for switching between automatic and manual mode, and the boundaries beyond which the logic enters a safe state.
• Metering point diagrams: mapping of each sensor and meter to the room, loop, and panel, units of measurement, and operating ranges — so that after equipment replacement the model does not "go blind."
• Model documentation: list of input features, forecast horizon, what is considered a deviation, and on what data the model is retrained.
• System access rights: roles, who can change setpoints, who can only view, who can export data, plus a user action log.
• Operation logs and metrics: indicators showing that control actually reduces consumption rather than merely running.

Documentation and operating regulations

A separate package includes texts for the operations service — they are read by the duty engineer, not the developer.

• Procedure for actions during failures: loss of communication with a sensor, forecast deviating from actuals, manual transfer of the building to normal mode.
• Procedure for changing setpoints and boundaries: which edits the engineer makes independently and which require coordination with us.

Case study: how energy consumption was reduced in an office center

Office center: four loops — supply ventilation, cooling supply, heating point, and common-area lighting. Control followed a schedule with setpoints established at commissioning and manual adjustments by operations.

This led to overheating in the shoulder season, simultaneous heating and cooling in the supply air, 9 emergency callouts per month, and energy consumption that did not match the calculation.

First, we collected history: telemetry from controllers and data from the existing building automation over a full season.

The analytics layer was deployed on top of the operating Schneider Electric EcoStruxure Building Operation system — without replacing equipment or stopping operations.

The demand model calculates heating and cooling requirements by hour, weather, and building occupancy.

Setpoints change preemptively, with a horizon of up to 4 hours, damper actuators operate in a "dead band" and do not oscillate, and a "setpoint / actual" discrepancy becomes a service request while it is still a deviation rather than an emergency.

Over the heating season, consumption decreased by 31%, peak capacity by 18%, emergency callouts from 9 to 2 per month, and response to deviation from several hours to 15 minutes. The investment paid back in 14 months through reduced consumption.

Where the effect exceeded expectations

Nights and weekends delivered the most: the building's inertia turned out to be higher than calculated, and preemptive capacity reduction worked where the schedule was useless.

In the shoulder season, the "heating and cooling at the same time" mode — the most costly — was eliminated. The load on operations also decreased: some requests are closed before a crew visit.

How predictive control differs from a schedule

A schedule is a rigid grid of setpoints by hour: in the morning, supply turns on; in the evening, it goes into night mode. The scheme is predictable and understandable to the operations service, but it knows nothing about the building itself.

One hall is full, the neighboring one is empty, and the system heats both according to the same scenario — heat and electricity are wasted.

Weather-dependent correction adds outdoor feedback: the setpoint shifts along a curve based on outdoor air temperature. This is already a reaction to the environment rather than the calendar, and it removes some overheating on warm days.

But the curve is built on outdoor conditions, not the building — solar gains, wall inertia, and heat from people are not included in it.

Predictive control appears where there is a model of the site's thermal behavior.

It takes the weather forecast, actual room occupancy, and sensor readings, calculates the trajectory to the required state, and changes the setpoint in advance: not "it got cold — we added" but "in an hour it will drop — we are raising it now." Preemption removes peak spikes and guides the building along the lower boundary of the range.

The model is also alive: adaptation is based on the discrepancy between forecast and actuals.

Temperature, humidity, and carbon dioxide sensors and occupancy meters show where the scenario did not work — coefficients are recalculated rather than remaining at the commissioning level.

Setpoints and tolerances remain with the engineer: the model moves the operating point only within the permitted range, and everything else is cut off by constraints.

Therefore the mode does not run away and remains verifiable — it is clear what exactly changed and based on what data.

Limitations: where AI control will not replace an engineer

The model does not replace an engineer where there is no reliable data or where the cost of an error is measured not by temperature deviation but by equipment shutdown.

If the telemetry archive contains gaps, and rare modes — startup after downtime, seasonal switchovers, emergency situations — are not described in it, the forecast remains averaged over the normal process.

Therefore, before starting, we fix responsibility zones: automation handles established modes, while humans make decisions on non-standard situations, planned shutdowns, and setpoint changes.

If communication with the control loop is lost, the system enters a safe mode — equipment returns to local automation with conservative setpoints. Below are the technical concerns that we most often resolve before work begins.

How does the system behave when communication is lost or a sensor fails?

Fail-safe mode is built into the architecture: upon loss of communication, unreliable readings, or going beyond the permissible range, control is transferred to local automation, and equipment returns to pre-agreed setpoints.

No "last successful" commands are sent to the loop — this is a separate requirement that we verify during acceptance tests.

Who is responsible for decisions, and can we return to manual control?

Responsibility is divided: the algorithm proposes and maintains the mode within agreed boundaries; the engineer approves setpoints and actions in non-standard situations. Switching to manual control is a standard operation available at any time.

All setpoint changes and operator interventions are logged so that deviation analysis relies on the log rather than memory.

How compatible is the solution with the existing building automation?

We work on top of the existing dispatching: we connect to controllers and sensors via open communication channels without replacing the standard controls.

If some equipment does not provide data, we install additional measurements only where they are indispensable, and we describe how this affects control accuracy.

Let's discuss the task and come back with an estimate and plan

To start the discussion, a finished technical specification, tender documentation, and approvals at the operations service level are not required.

What already exists in the project and in dispatching is enough: from this data we understand what volume of loops can actually be controlled, where existing sensors are sufficient, and where additional equipment will be required.

The more complete the site's source data, the more accurate the project estimate and the shorter the first stage.

Send us what you have — even a partial set provides a working picture:

• list of the site's engineering systems: ventilation and air handling units, heating, cooling supply, lighting, pump groups — indicating what currently controls them (controllers, dispatching, manual setpoints);
• export of historical data from meters and sensors: temperature, flow, capacity, equipment status — for several months, at the interval at which the system writes the archive;
• metering point diagram: which sensors are installed, in which zones, in what units they transmit values, and at what frequency;
• current modes and setpoints: zone operating schedules, night and weekend setbacks, system priorities during conflicts;
• floor plans or zoning (PDF, DWG, scans) — to match rooms with the systems serving them;
• operational restrictions: what cannot be changed, requirements of tenants, service organizations, and current regulations.

The procedure is as follows: we review what you send, clarify what is missing in one short call, calculate the achievable percentage of energy consumption reduction for your profile, and come back with a project estimate and implementation plan — with stages, control points, and what will be required from your team. Describe the task and send the source data — we will come back with an estimate and plan.