How AI catches after-hours HVAC schedule drift

Walk through almost any school district’s energy data and you will find the same quiet problem: buildings running when nobody is in them. Not dramatically — a rooftop unit that never got the summer schedule, a weekend-event override that stuck, an exhaust fan wired to run continuously after a controls contractor left. Each one looks small. Together, after-hours waste routinely adds 10–20% to a school’s electric bill.

The frustrating part is that nobody chose this. Schedules drift.

Why nobody catches it

The monthly utility bill is one number. If the gym’s air handler starts running from 9 p.m. to 5 a.m., the bill goes up a few percent — well inside the noise of a hot month or a cold snap. A facilities director looking at a 6% increase has no way to know whether that’s weather, enrollment, rates, or a unit that never shuts off.

And walking every building at midnight isn’t a plan. Districts with thirty buildings and three HVAC techs do not have spare nights.

What interval data shows

Most utilities already record your electricity use in 15-minute intervals, and most will hand it over — in PG&E territory, for example, you can authorize third-party access through Share My Data, and many other utilities support the Green Button standard.

Plotted over a week, a healthy school building has a distinct shape: a morning ramp as HVAC and kitchens start, a daytime plateau, an evening ramp-down, and a flat overnight baseline — the refrigerators, network closets, and exit signs that legitimately never sleep.

Schedule drift shows up as a raised shelf where the flat line should be. A unit running all night doesn’t look like a spike; it looks like the floor of the whole graph moving up. Holiday weeks are the classic case: school is empty, but the load curve looks like a school day because nobody loaded the break into the BAS calendar.

Why simple threshold alerts fail

The obvious fix — “alert me if overnight load exceeds X kW” — fails in practice, and it’s worth understanding why:

• The right threshold is different for every building, and it moves with the seasons.
• Summer nights legitimately carry more load than winter nights in cooling climates.
• One threshold produces either constant false alarms or none at all. Either way, people stop reading the alerts within a month.

Alert fatigue is the death of most monitoring programs. The tool that cries wolf gets muted.

What a learned baseline does differently

This is the piece AI actually earns its keep on. Instead of a fixed threshold, a model learns each building’s expected load shape given the things that legitimately move it: outdoor temperature, day of week, time of year, and the school calendar. The question stops being “is overnight load above X?” and becomes “is this building behaving like itself?”

That framing catches drift a threshold never will — a building that runs 40 kW overnight in July might be perfectly normal, while the same 40 kW in October is a stuck schedule. And it stays quiet when a heat wave raises everyone’s load, because the model expected that.

A useful anomaly system then does two more things:

1. It waits for persistence. One odd night is noise. Four consecutive raised nights is a schedule problem.
2. It prices the deviation. “Anomaly detected” is ignorable. “The middle school has run ~180 kWh/night above its own baseline since Tuesday — roughly $47/night at your rate” is a work order.

What a good alert looks like

A facilities team should be able to act on an alert without opening a data tool. That means the alert names the building and meter, the dates the deviation started, the magnitude in kilowatt-hours and dollars, and the likely category — overnight shelf (schedule), weekend load (override), or holiday-as-weekday (calendar). The best ones note what changed nearby: “began the night after controls work on the 14th” is usually the whole diagnosis.

From there the checklist is short: compare the BAS schedule against the actual bell schedule, look for manual overrides that never expired, and confirm breaks are in the holiday calendar. Most drift is fixed in software in under an hour. That is what makes this category of savings so attractive — the fix is a schedule change, not a capital project.

Where to start

You don’t need a platform to check whether you have this problem. Pull one week of 15-minute data for your largest building and look at 12 a.m. to 4 a.m. on a school night. If that line isn’t close to your true baseload — the load you’d expect from refrigeration and IT alone — you’ve found your first project.

The harder part is staying caught up. Schedules will drift again next semester, after the next controls visit, after the next weekend event. That’s the case for having a model watch every building every night: not because the analysis is hard, but because nobody has time to do it thirty times a day, forever.