Machine Learning for Buildings

Machine learning is the practice of learning a pattern from data rather than hand-coding a rule. You show an algorithm examples, and it fits a model that generalises to new cases. In buildings, two flavours cover most of the ground. Supervised learning learns from labelled examples: give it historical inputs paired with the answer - weather and calendar paired with the energy that resulted - and it learns to predict the answer for new inputs. Forecasting is the classic supervised task. Unsupervised learning works with no labels: it finds structure on its own - clustering similar days, similar zones or similar load shapes, or flagging the points that do not fit any cluster. Anomaly detection and pattern discovery are its home turf.

The distinction matters practically because buildings rarely come with labels. Almost nobody has a tidy dataset of here are a thousand examples of a leaking valve. That scarcity of labelled faults is why unsupervised anomaly detection - learn what normal looks like, flag the abnormal - is often the realistic first step in a building, while richly supervised approaches are easier for things you can label cleanly, like metered energy against weather. Knowing which flavour a problem needs tells you immediately whether you even have the data to attempt it.

There is a spectrum in between worth naming, because vendors blur it. Semi-supervised methods learn mostly from unlabelled data with a few labels to guide them; reinforcement learning, much hyped for building control, learns by trial and reward and is genuinely hard to apply safely in a real building where you cannot experiment freely on people's comfort. For most practical building work, though, the honest supervised-versus-unsupervised split is enough to reason with - and enough to ask the one question that cuts through a sales pitch: what is this model learning from, and do we actually have that data? If the answer is a labelled history the building has never collected, the impressive demo will not survive contact with your building.

Three uses stand out as consistently worth it. Forecasting is the strongest: predicting a building's electrical load, heating and cooling demand, or occupancy for the hours and days ahead. A good load or occupancy forecast is the fuel for smarter control - pre-cooling before a demand peak, staging plant ahead of an occupied morning, participating in demand response. It is genuinely hard to do well with a fixed rule because it depends on weather, calendar, occupancy and the building's own quirks all at once, which is exactly what a learned model handles.

Anomaly detection is the second: learning the normal envelope of a meter, a runtime or a temperature and flagging what falls outside it - often the first hint of a fault, a leak or a change in use, including faults no rule anticipated. Pattern discovery is the third: clustering thousands of days or zones to reveal groupings a human would never spot - which zones behave alike, which days are truly abnormal, how the building's signature shifts across seasons. Notice the common thread: ML earns its place where the pattern is genuinely complex, multivariate, or unknown in advance - precisely where a rule runs out of road.

Now the honest half. A great deal of building ML is oversold, and recognising the pattern protects you. First, simple rules often win: catching simultaneous heating and cooling, plant left running at night, or a temperature out of range needs a threshold, not a neural network - and the rule is faster, cheaper, explainable and does not need training data. Reaching for ML here adds cost and opacity for no benefit. Second, ML needs data you may not have: models are only as good as their history, and a building with drifting sensors, gaps, or only a few months of records cannot support a trustworthy model - garbage in, confident-looking garbage out.

Third, and most dangerous, is the black box. A model that flags an anomaly but cannot say why, in a domain where operators must trust and act on it, often gets ignored - killing the very value it promised. In buildings, explainability is not a luxury; an alert an engineer cannot interrogate is an alert they will mute. And beware the deepest trap: a model can be accurate and useless at once if its output serves no decision. The professional test is unchanged from lesson one - what decision does this serve, is a rule enough, and do we have the data and the trust to act on the output? If ML clears that bar, use it. If it does not, the simpler tool is the smarter one.

If a problem genuinely calls for machine learning, a few disciplines keep it honest. Start from the decision, not the algorithm: name the action the forecast or anomaly flag will drive before you build anything. Baseline against a simple rule: if a threshold or a linear fit does nearly as well, ship that instead - simplicity is a feature. Insist on clean, well-tagged data: the metadata schemas from the last lesson, Brick and Haystack, are what let a model be trained once and deployed across many buildings without hand-wiring every point. Report honest error: a forecast without an error band is a guess wearing a suit; a model that is wrong in new conditions must fail visibly, not silently.

And keep a human in the loop where stakes are real. ML in buildings is at its best as an assistant to judgement - surfacing the forecast, the anomaly, the cluster - not as an unaccountable autopilot, especially for anything touching safety, security or occupant wellbeing, where statutory sign-off stays with qualified professionals. Used this way, machine learning is a genuinely valuable member of the analytics toolkit. Used as a magic word, it is an expensive way to make a chart look clever. The difference is entirely in the judgement you bring to it - which is the thing no model can supply.

Take the strongest use - forecasting - and make it concrete. A retail building is on a tariff with demand charges: a large slice of the monthly bill is set by the single highest half-hour of electrical demand, which for this building lands on hot afternoons when the cooling plant runs flat out just as shoppers pack in. Shaving that peak is worth real money, but you can only shave a peak you can see coming. A fixed rule cannot: the peak depends on tomorrow's weather, the day of the week, a promotion, and the building's own thermal quirks, all interacting.

This is where a supervised load forecast earns its place. Trained on history - past load paired with weather and calendar - the model predicts tomorrow's demand curve, peak and all. That forecast then drives an action: pre-cool the building in the cooler morning hours so its thermal mass carries it through the afternoon with the plant backed off during the costly window, and stage equipment ahead of the ramp rather than scrambling to catch it. The saving is measurable on the demand charge.

Notice what makes this legitimate ML rather than theatre. The forecast serves a specific decision (when to pre-cool, how hard); a rule genuinely could not express the multivariate pattern; the building has the metered history to train on; and the output comes with an honest error band, so operators know how much to trust it and a human stays in the loop. It also sits right on the border of the next module's territory - model predictive control, where such forecasts feed an optimiser that plans the building's moves automatically. Good forecasting is the bridge from analysing a building to actively, intelligently running it.