How Machine Learning Turned the Home Battery Into a Forecasting Problem

A homeowner in Chandler, Arizona installs a battery, watches the utility bill for the next few months, and gets a number that doesn’t match the sales pitch. The battery is working fine. The solar panels are producing as expected. The bill is still $150 to $200 higher than the estimate promised. Nothing is broken. The problem is timing, and figuring out timing turns out to be a genuinely interesting forecasting problem, not just a hardware one.

Here’s what’s actually happening. Most residential customers are billed per kilowatt-hour: total energy consumed over the month, multiplied by a rate. But a growing number of utilities, particularly in states with hot summers and strained peak capacity, bill a second way on top of that. They charge based on the single highest burst of power a household draws in any 15- or 60-minute window during the billing period, regardless of total energy used that month.

As EnergySage explains, demand charges exist because utilities have to build and maintain infrastructure sized for peak load, not average load, and they want customers to feel that cost directly. Two households that use identical total electricity can end up with wildly different bills if one of them happens to run the air conditioner, the dryer, and an EV charger at the same moment on one afternoon in July. On SRP’s E-27 plan in Phoenix, for instance, that peak-hour charge escalates in tiers: $7.89 per kW for the first 3 kW over baseline, $14.37 for the next 7, and $27.28 per kW beyond that during the summer peak window, according to the utility’s own rate filing. A single avoidable spike is real money, not a rounding error.

This changes what a home battery is actually for. If you’re only fighting a per-kWh rate, a battery just needs to hold enough charge to cover the expensive hours. But if you’re fighting a demand charge, the battery has to be discharging at exactly the right five-minute window, every time, because a single miss erases the savings for the entire month. Storage capacity stops being the constraint. Prediction becomes the constraint. The system needs to know, a few minutes before it happens, that the house is about to spike.

Forecasting the next hour of your own house

That’s a harder problem than it sounds, because a household’s power draw is really the sum of several loosely correlated processes: a compressor cycling on a thermostat, an EV charger that starts at a fixed clock time, a dryer that someone runs whenever laundry piles up, cloud cover moving across a solar array. None of these are independently predictable, but together they follow patterns that are learnable from enough historical data.

A 2024 evaluation in Frontiers in Energy Research compared five forecasting approaches, including support vector machines, standard recurrent networks, and long short-term memory (LSTM) networks, against five years of real consumption data. LSTM won clearly across every metric the researchers tracked, with error rates 23 to 84 percent lower than the other models depending on the comparison. That’s not a surprising result to anyone who works with sequential data; LSTMs are built to weigh recent history more heavily while still remembering longer patterns, which is roughly the shape of a household’s energy use. But the size of the gap matters here in a way it wouldn’t in a lot of forecasting applications, because the cost of being wrong is denominated in dollars on next month’s bill, not in an abstract accuracy score.

The constraint nobody puts in the paper

Academic forecasting work is usually evaluated on offline accuracy: train on a slice of historical data, test on a held-out slice, report the error. A production system managing a Powerwall in someone’s garage doesn’t get that luxury. It has to sample the gridsample grid draw roughly once a minute, decide in real time whether a spike is forming, and dispatch the battery before the peak actually lands, all on a home internet connection with no meaningful local computercompute. There’s also a cold-start problem: a battery installed three weeks ago has almost no usage history to learn from, and the model has to be useful anyway. And the underlying pattern drifts; a family buys an EV, has a baby, starts working from home, and the household’s signature changes underneath the model.

There’s a second wrinkle. This isn’t really a forecasting problem in the classic sense, where the goal is to predict a value as accurately as possible. It’s closer to anomaly detection or fraud scoring, where the goal is to predict whether a threshold will be crossed, and the two kinds of error cost completely different amounts. Dispatching the battery a little early, when no spike was actually coming, costs almost nothing; the household just used stored energy slightly ahead of schedule. Missing a real spike costs the entire month’s demand-charge savings in five minutes. A system built for this has to be tuned with that asymmetry in mind, which pushes toward deliberately conservative thresholds rather than raw predictive accuracy.

What the data actually looks like in practice

Anyone who has worked with real sensor data can guess what happens next: the data is worse than the paper. Powerwall telemetry typically reports in short but not perfectly regular intervals, and a brief internet outage at the gateway means a gap in exactly the window you needed. Net metering complicates the picture further for solar households, since the meter reports the difference between generation and consumption rather than either one directly, so a cloud passing overhead can look identical, from the meter’s point of view, to someone turning on a space heater. Untangling those two cases matters, because the correct response is completely different: one calls for discharging the battery, the other doesn’t need any response at all.

Backtesting is its own headache. A demand-charge dispatch model can’t just be validated against a random held-out sample of minutes, because the thing being predicted is a monthly maximum, and a model that’s accurate on 99 percent of five-minute windows can still miss the one window that sets the entire bill. Walk-forward validation against historical tariff data is closer to what’s needed, and even then, SRP’s tiered structure (a few dollars per kW for the first few kilowatts over baseline, a much steeper rate beyond that) means a small miss and a large miss aren’t equally bad; the loss function has to reflect the tariff’s actual shape, not just whether the cap was crossed at all. None of this is exotic in isolation. It’s the same discipline that goes into any deployed forecasting system with a skewed cost function. It’s just rarely discussed in the context of a battery in someone’s garage.

A narrow, oddly specific product category

This gap has produced a small category of software built around exactly one question: is this specific house, right now, about to exceed its demand-charge threshold? Tesla’s own app handles firmware updates and basic time-based charging schedules, but it isn’t built around real-time demand-charge prediction. Third-party tools such as Grid Getter have grown up around that specific gap, sampling a Powerwall’s grid draw on a short interval and shifting discharge automatically to keep peak draw under a set cap for owners on demand-charge tariffs like SRP’s E-27 or APS’s R-3 plans. It’s a narrow tool. It doesn’t coordinate EV charging or control other smart-home devices, the way broader home-energy platforms try to. It solves one forecasting-and-control loop reasonably well instead of a dozen loosely, which is its own kind of design decision worth noting: in a domain full of ambitious whole-home automation platforms, there’s a case for building something that does less.

Why this is bigger than one appliance

The pattern shows up well beyond batteries. Utilities running demand-response programs are moving away from asking customers to voluntarily cut usage during peak events, and toward paying for automated load shifting instead: EV chargers that respond to grid price signals, water heaters used as thermal batteries that pre-heat before a rate window, HVAC systems that pre-cool a house an hour before the expensive period starts. In each case, a physical asset that used to run on a fixed schedule or a simple thermostat rule is being handed over to a small forecasting model making a live financial decision.

Tesla’s own virtual power plant programs with PG&E in California and with utilities in Texas are the aggregated version of the same idea: instead of one household’s forecasting model deciding when to protect that house from a demand spike, a fleet-level model decides when to draw down thousands of Powerwalls at once to help the grid avoid a peak, then pays participants for the capacity. The forecasting problem barely changes shape between the two cases. What changes is who the prediction is serving, one household’s bill or an entire region’s grid stability, and that’s mostly a question of whose electricity meter the model is optimizing against.

For anyone doing applied machine learning, that’s what makes this domain worth a second look. It’s streaming, not batch. The inference budget is tight. The training data is noisy and different for every household. And the cost of an error is concrete enough to explain to a non-technical stakeholder in one sentence, which is more than can be said for a lot of forecasting work. A model that’s two percent more accurate on paper but ten times slower to run isn’t obviously better here, because slow means the spike has already happened by the time the prediction lands. That’s a different set of trade offs than the ones most forecasting tutorials teach, and it’s a useful reminder that the interesting constraints in machine learning aren’t always about accuracy. Sometimes they’re about how fast a model has to be right, and how expensive it is when it isn’t.