When every home saves money at the same time, the transformer pays for it
Murmuration is a neighbourhood simulator. It builds a synthetic neighbourhood (by default 500 homes on five 200 kW transformers, with EVs in 30% of homes).
The problem: cheap hours create a new peak
India is moving households to Time-of-Day electricity tariffs. Under the Electricity (Rights of Consumers) Amendment Rules, 2023, power costs more in the evening peak and at least 20% less during solar hours. The idea is sound: move demand away from the evening, when the grid is stressed and the power is dirtiest.
The trouble starts when every home responds in the same way. If the cheapest window opens at midnight, every EV charger, geyser and washing machine with a timer starts at the same moment. The old evening peak shrinks and a new, sharper one appears. Researchers call this a rebound or shadow peak. A 2024 field experiment (NBER Working Paper 32886) found that time-of-use pricing moved EV charging off-peak but created new and larger peaks of simultaneous charging.
The street transformer does not care about the price. It only cares how much load it carries at once. So a tariff that works for the grid as a whole can overload the equipment at the end of your lane.
What we built: Murmuration
Murmuration is a neighbourhood simulator. It builds a synthetic neighbourhood (by default 500 homes on five 200 kW transformers, with EVs in 30% of homes) and runs the same day three ways:
- Today. Every appliance runs at its usual time.
- Each home alone. Every home moves its flexible appliances to the cheapest allowed time, without knowing what the neighbours do.
- FlockShield. One scheduler places the same appliances, with the same comfort limits, but it also watches the load on each transformer.
The name comes from starling flocks: thousands of birds, no collisions, because each one reacts to its neighbours.
What the default scenario shows
| Today | Each home alone | FlockShield |
|---|---|---|---|
Highest demand | 934 kW at 21:30 | 1,115 kW at 05:30 | 647 kW at 05:30 |
Transformers overloaded | 2 of 5 | 5 of 5 | 0 of 5 |
Daily bill, all homes | Rs 62,097 | Rs 48,803 | Rs 48,803 |
Three things stand out:
- Optimizing alone makes the grid worse. The peak rises from 934 kW to 1,115 kW and all five transformers overload.
- Coordination costs households nothing. FlockShield's bill is the same as optimizing alone, 21% below today. No home pays more than it does today.
- Nobody gives up comfort. Geysers still have hot water by the usual time, EVs are charged by 07:00, and air conditioners are never moved.
We also added the question a utility asks before paying for an upgrade: how many EVs can these transformers take? In this scenario the answer is EVs in up to 20% of homes today and up to 40% with FlockShield. Same transformers, twice the EVs.
How FlockShield decides
FlockShield is a greedy scheduler, on purpose. It works through the neighbourhood in rounds, placing the most constrained appliances first. For each appliance it lists every start time that respects the home's sanctioned load and the transformer's capacity, then picks the cheapest. When several times cost the same, it picks the one where the transformer is least loaded. That tie-break is the whole trick: on a ToD tariff many slots cost the same, so spreading load across them is free.
Every decision is written down with its reason, for example "one of 15 equally cheap start times, chosen because transformer T01 is least loaded then". The dashboard shows this log.
The AWS stack
Everything runs serverless in the Mumbai region:
- AWS Lambda runs the engine: a Python 3.11 FastAPI app wrapped with Mangum. A 500-home run takes about a second.
- Amazon API Gateway (HTTP API) fronts the Lambda, with throttling at 10 requests a second so an anonymous caller cannot run up a bill.
- Amazon DynamoDB stores saved household profiles, with a 90-day expiry on each item.
- AWS Amplify Hosting serves the React dashboard.
- AWS SAM CLI defines and deploys the backend from one template. GitHub Actions deploys the front end on every push, using an OIDC role, so no AWS keys are stored anywhere.
For a small team this mattered. There is no server to keep alive during judging, and the whole project fits inside the free credits.
Honest limitations
- The data is synthetic. No real meter data was used. The homes, appliances and habits are generated from stated assumptions, and the tariff is illustrative, not any DISCOM's published rate.
- The scheduler is a greedy heuristic. It is fast and explainable, but not provably optimal. In our high-EV scenario (60% of homes) it could not find a slot for 18 appliances; an exact optimizer might place some of them.
- This is not grid protection. Nothing here controls a real appliance or a real transformer, and it is not certified for that. It is a planning and demonstration tool.
- Households would have to agree. Coordination needs homes to share their flexible loads with a scheduler. We show it can be free for them; we have not shown they would sign up.
What we would do next
Test against real smart-meter data, add a forecast for the load we cannot control, and compare the greedy scheduler with an exact optimizer on the tight cases.
The lesson we took from the build: a price signal tells every home the same thing at the same time. Someone still has to make sure they do not all act on it at once.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article