In this guide
How a Virtual Power Plant Turns Home Batteries into One Power Plant
A virtual power plant is not a building, a turbine, or a single big battery. It is an agreement plus a control system: many small batteries, each in a different home, are linked over a network and dispatched together as if they were one power plant. When demand peaks in the evening, the coordinator tells the fleet to discharge together. When solar output is high and demand is low, it tells the fleet to charge. No single home battery could move a grid, but a coordinated fleet can shift real power at the time it matters most.
This guide explains the idea from first principles, the three operating modes every virtual power plant uses, and how a student can model the whole thing honestly on a bench rig — including the measurement that turns a demonstration into a result.
Why homes, and why now
A home battery on its own is a backup box. It charges from rooftop solar or from the grid at night, and it discharges when its own home needs power. Its decisions are local: it knows its own state of charge and its own load, and nothing else.
A virtual power plant changes the decision-maker. A coordinator sees the whole fleet — every battery's state of charge, every home's load, and the grid condition — and issues one dispatch decision to all of them. That is the whole conceptual leap: the resource is no longer one battery, it is the sum of the fleet, and the coordinator is the plant operator.
The idea made headlines on 29 October 2026, when DTE Energy and sonnen launched Michigan's first residential battery virtual power plant pilot at Veridian at County Farm in Ann Arbor, a reported two-year pilot virtually connecting nearly 100 homes with sonnen battery systems in a community that also uses geothermal heating, heat pumps and rooftop solar. Those pilot figures are reported context only. They describe a commercial programme, not a student build, and no savings or performance figure from the pilot should ever be quoted as a result of a bench project.
How a virtual power plant works
A virtual power plant has four parts, and every part must work for the fleet to behave as one plant.
1. The fleet. Each home contributes a battery, an inverter, and a meter that reports power flow. The fleet does not need identical batteries — in fact, real fleets are mixed — but the coordinator must know each battery's usable capacity and its current state of charge before it can issue a fair dispatch command.
2. The communication link. The coordinator and the homes exchange small status messages: state of charge, solar power, load power, and grid import, in one direction; dispatch commands in the other. Student rigs do this over local Wi-Fi with MQTT, a lightweight publish-and-subscribe protocol in which each node publishes its readings to a topic and subscribes to dispatch commands. Commercial fleets use managed cloud connections, but the message pattern is the same, and a local-network version demonstrates it completely.
3. The coordinator. This is the brain. It adds up fleet solar output and fleet load, compares them with the selected mode, and sends one command: charge, discharge, or hold. The critical design choice is that the command is fleet-wide but capacity-aware — a battery that is nearly empty must not be ordered to discharge at the same rate as a full one, and the coordinator must respect each battery's limits.
4. The grid interface. The fleet still connects to the grid through each home's normal supply. The virtual power plant does not replace the grid; it changes how much the fleet draws from it, and when. That is why the honest measurement of any virtual power plant build is grid import in watts before and after dispatch, recorded on the same rig under the same load.
The three modes, in plain physics
Solar-charge mode. When the sun is strong and home loads are small, each battery charges from its own solar surplus. The physics is simple: energy stored equals power multiplied by time, so a panel producing more watts than the home load can store the difference. The coordinator's job here is mostly to stay out of the way and let each node charge, while watching that no battery is overcharged.
Peak-shave mode. This is the mode that justifies the whole concept. In the evening, solar output falls while home demand rises, and grid import climbs to a peak. The coordinator orders the fleet to discharge together, and the batteries carry part of the load, so grid import falls. The result is not a feeling — it is two numbers: grid import in watts before dispatch, and grid import in watts after dispatch, measured with the same loads running. The difference between them is the peak-shaving result for that session, on that rig, and it must be reported that way, per session, because light levels, battery age and load size all change it.
Island mode. When the grid connection is lost, a fleet that can island keeps its loads running from batteries alone, with zero grid import. Islanding is a switching and safety problem as much as a power problem: the system must detect the loss, disconnect cleanly from the grid, and carry only the loads its batteries can support. A bench rig simulates this with a grid switch, which is the right way to demonstrate the logic without touching real mains wiring. A student rig must never be connected to a real home supply or presented as a grid installation.
State of charge: the measurement that drifts
State of charge is the percentage of usable energy left in a battery, and it is the number every dispatch decision depends on. The common student method is coulomb counting: measure current over time and add up the charge that went in and out. It works, but it drifts, because every small measurement error accumulates over repeated partial cycles, and the estimate slowly walks away from reality.
The fix is recalibration. At full charge, the battery voltage gives a known reference point, so the build checks its state-of-charge estimate against a voltmeter reading at full charge and resets the estimate there. Any write-up that reports state of charge without this caveat is overstating its accuracy. A good viva answer names the drift, explains why it happens, and shows the recalibration step.
Communication failures are part of the design
A fleet that only works when the network is perfect is not a finished design. Nodes lose Wi-Fi, messages arrive late, and a relay that switches on every flapping connection will chatter and wear out. A robust student build handles this explicitly: automatic reconnection, and a relay failsafe that holds the last safe load state instead of switching on every reconnect. Demonstrating the failure and the fix is stronger viva material than pretending the network never drops.
Modelling it on a bench rig
A bench virtual power plant uses the same four parts at tabletop scale: three nodes, each with a small solar panel, a battery pack, a power sensor and a relay-switched lamp load standing in for a home load, plus one coordinator dashboard. The lamps make the physics visible: a shed load goes dark, a discharging fleet keeps lamps lit while grid import falls, and the dashboard shows per-node power flows in watts.
The companion project for this guide builds exactly that rig, with solar-charge, peak-shave and island modes and a CSV dispatch log: https://projectech.in/projects/residential-virtual-power-plant-home-battery-peak-shaving-esp32/ It is the practical companion to the theory above — read this guide to understand why the fleet discharges together, then build the rig to measure what that decision actually achieves.
Frequently asked questions
Is a virtual power plant the same as a microgrid? No, though they overlap. A microgrid is a local network that can disconnect from the main grid and run on its own generation and storage. A virtual power plant is a coordination layer: it aggregates distributed batteries that may sit in different places and dispatches them as one resource, usually while they stay grid-connected. A fleet can be both — a microgrid with a virtual power plant coordinator — but the two terms describe different things, and mixing them up is an easy viva mistake.
Does a virtual power plant save money? It can reduce grid import at peak times, and in real markets that sometimes has value, but a student bench rig cannot claim bill savings. Its loads are lamps, its grid is a bench supply, and its result is a measured watt difference, not a tariff calculation. Any project that quotes household savings from a lamp rig is inventing its conclusion.
Why dispatch the whole fleet together instead of letting each battery decide? Because the peak is a fleet problem. One battery discharging while its neighbour charges cancels out. Coordinated discharge is what makes the fleet's combined power large enough to matter, and coordinated charging is what stops the fleet from accidentally creating a new peak when everyone charges at once.
What is the hardest part to get right? Honest measurement. The dispatch logic is a few lines, the wiring is straightforward, and the dashboard is the visible part. The hard part is recording before-and-after grid import under identical loads, recalibrating state of charge, and reporting the result with its limits — per session, on this rig, with these loads.
Limitations of the bench model
A bench rig demonstrates coordination, dispatch, islanding logic and measured peak comparison. It does not demonstrate grid-scale behaviour, real tariff economics, or backup power for a real home. Its batteries carry lamp loads for a demonstration window, not a household evening. Its solar output depends on bench lighting, so results differ between sessions and must be reported per session. Lithium batteries need supervision, correct polarity and a protected holder, and the rig must stay on low-voltage loads, never on household mains.
Read the companion build here: https://projectech.in/projects/residential-virtual-power-plant-home-battery-peak-shaving-esp32/