Anyone can tell a battery
when to charge.
What it actually takes to run a residential battery fleet for a Texas retailer — and why the decision layer is where the money is.
The job, stated honestly
A retail electricity provider in ERCOT signs up thousands of homes with batteries. Every fifteen minutes, each one of those batteries should be charging, holding, or discharging. Get it right and the fleet earns. Get it wrong and you have bought a very expensive way to move electricity around a garage.
Put like that, it sounds like a scheduling problem. Set some time blocks, charge overnight, discharge at the evening peak, done. That is what most of the market sells — and it is why most distributed fleets underearn.
An aggregated distributed energy resource (ADER) program in ERCOT needs more than scheduling. It needs a decision layer that can see market prices, weather, load, state of charge, and your hedge position all at once — and act on all of them every fifteen minutes.
Where fleet software stops
The value chain has four parts, and they are easy to confuse. Manufacturers make the battery. Fleet software moves commands to it. Somebody has to decide what the command should be. And then somebody has to settle the result on a bill.
Fleet software is good plumbing. It is not optimization — it moves the instruction it is given and has no opinion about whether the instruction was right. That distinction gets glossed over constantly, and the gloss is expensive, because the decision layer is where the money is.
The alternative most operators fall back on is people. That works at ten batteries. At ten thousand meters, with solar output, weather, price forecasts, state of charge, and hedge position all moving at once, nobody is pulling those levers by hand.
The four-part value chain
What the state of charge tells you
On the same fleet — same batteries, same rooftops, same grid — schedules driven by a manufacturer GUI using time blocks peaked the batteries at roughly 50% state of charge. Direct, API-driven optimization on that same fleet peaked at roughly 95%, with deeper troughs on the discharge side.
Nothing physical changed. The hardware did not improve, the sun did not get better, the market did not shift. The only variable was what decided the move.
A note on what we are not going to tell you. We are not going to put a dollar figure on that gap yet. The attribution work — separating what the fleet earned under our control from what it earned under someone else’s — is still in progress, and a number produced before that analysis lands would be marketing, not measurement. When it is finished we will publish it with the method attached. Until then, the behavior is the claim.
The unglamorous sixty percent
Before anything can be optimized, the data has to be real. This is the part nobody puts on a slide, and it is most of the work.
Telemetry, per battery, retained
With attribution for which periods ran under our control and which did not. Without that split there is no honest measurement later.
Identity mapping
Meter to battery to program membership, kept current as customers join and leave the ADER.
Enrollment pipelines
Capacity rates and state-of-charge floors, refreshed rather than set once.
Smart-meter data
In Texas, built bottoms-up from Smart Meter Texas rather than estimated from a class profile.
Staleness detection
A feed that silently stops is worse than a feed that never started. Dirty utility data quietly erodes margin, and it is a permanent condition rather than a one-time cleanup.
Optimization is not a project. It is an operation. Fleets drift — customers churn, hardware is replaced, feeds break, enrollments lapse. Something has to keep pace with that or the model is optimizing a fleet that no longer exists.
What actually decides the move
On top of clean data sits the modeling. Load forecast at the individual meter, not the class average. Solar output modeled per array, because two rooftops four streets apart are not the same asset. Battery characteristics modeled per unit. Clustering by zone, profile, and sizing. Line losses accounted for, so a spread that looks profitable on a screen is tested against the full loss chain — arbitraging a margin narrower than round-trip and line losses is losing money with extra steps.
And, critically for a retailer: the hedge and the dispatch are modeled together. A battery reshapes the load you are hedging. Optimize the battery in one system and hedge the book in another, and you end up hedging load that never shows up. That is a real cost, and it is invisible until settlement.
Execution, and why the interface matters
Decisions reach the hardware through direct API command and control, not by filling in GUI time blocks. The schedule is translated into API calls and then validated — the translation step is where silent failures live, and an operator working through a graphical scheduler never sees theirs.
Charging is solar-first, with grid backfill when the roof cannot cover it. Negative prices are a live opportunity rather than an anomaly to ride out: when the market pays you to absorb energy, you want to be absorbing it, and a fixed time block structurally cannot notice that it is happening.
The platform runs across more than one manufacturer and more than one connectivity layer — proven in production on Sonnen and on Flip, including Duracell hardware reached through the Flip API. Different vendors, different APIs, different quirks, one decision layer.
That matters commercially as much as technically: a bespoke integration marries you to whichever vendor you picked first.
Then you have to prove it
A dispatch chart is not proof. Proof is a number on a bill.
Intervals become billing determinants, delivered into the retailer’s billing system — bidirectionally, across ESG, Vertex One, and homegrown platforms. Settlements are validated in dollars, and performance is attributed by comparing periods under our control against periods that were not. That is what lets a CFO ask what the fleet earned and get an answer instead of a graph.
Where this is running
Abundance Energy is a Texas retail provider with a residential battery fleet. ennrgy.com provides its risk management, scheduling, and battery charge and discharge optimization — the decision and settlement layers described above. The battery hardware and its vendor control layer come from the manufacturer side of the stack; the residential assets are separately owned; Abundance is the load-serving entity in ERCOT.
As we continue scaling our residential battery storage and virtual power plant programs across ERCOT, we’re building far more than a traditional retail energy company — we’re building an intelligent energy platform that helps homeowners lower costs, improve resilience during outages, and actively participate in supporting the grid.
The short version
Telling a battery when to charge is the easy part, and it is the part everyone sells. The work is in the layers underneath: the data nobody wants to own, the modeling that decides why rather than when, an execution path that does not fail quietly, and a settlement trail that turns behavior into dollars on a bill.
Risk360 is your system of record. Asset Optimizer is your system of action.
Questions about VPP optimization
What is an ADER in ERCOT?
What is the difference between fleet software and an optimization platform?
Does Asset Optimizer work with any battery manufacturer?
How does battery optimization affect a retailer’s hedge book?
Where is ennrgy.com’s VPP optimization currently operating?
If you run a book with batteries on it, the useful next step is not a demo.
Let’s model your book.