India Put Solar Panels on Millions of Roofs. Who's Watching the Roofs? Nobody
What if your rooftop could do more than just save you money? India’s solar revolution has a blind spot, and we built an AI agent on AWS to fix it. Meet SuryaSaathi: turning wasted electricity into energy recovered, bills into savings, and existing rooftops into smarter power plants. After this, you might also want a solar panel. Built in four days for the AWS Bharat Builds Tour Environmental Hacks, SuryaSaathi explores how AI agents can help India recover clean energy from infrastructure it already has.
Picture a family in Dwarka with a 3 kW system on the roof. In the first year, it cut their electricity bill to almost nothing. By the second winter, the bill has crept back up. They call the vendor, and the vendor says what every vendor in Delhi says in November: "It's the pollution."
Sometimes that's true. Often it isn't. The panels are under a grey film of dust, or the inverter has been tripping since Diwali. Both are the vendor's job to fix, for free, for five years. But nobody can prove which one it is, so nobody claims it.
We built SuryaSaathi to answer that one question for every roof, every day: was it the sky, or was it something the vendor owes? It's live at main.danjquy1xcblp.amplifyapp.com , the code is on GitHub , and as of today the deployed agent has watched 5 simulated Delhi rooftops for 30 days, filed 7 maintenance cases, escalated 2 to the DISCOM and verified 5 fixes.
You can also check how it works and the problem it solves on Youtube .
The short version: India is putting solar on lakhs of roofs and almost nobody checks them after the installer leaves. SuryaSaathi compares what each roof made with what it should have made, tells smog, dust and faults apart, and makes the vendor fix what they owe. The family gets one WhatsApp message. We built it in four days on AWS, and the most important thing we learned is that a good monitoring system is quiet almost all the time.
Part one: 50 lakh roofs, and nobody watching
India has put solar on more than 50 lakh homes under PM Surya Ghar , about 14.8 GW of capacity. Installation gets the photo op. Year two gets nothing. Industry estimates say 99% of users stop monitoring once the installer leaves.
That would be fine if panels looked after themselves. But in North India, they don't. Dust settling on the glass costs 0.3–0.6% of output a day, and systems here can lose 17–25% of a year's output to it. A failing inverter can halve production overnight.
When output drops, there are three usual suspects, and they leave three different fingerprints:
Cause | What the data shows | Whose problem |
|---|---|---|
Smog | Expected and actual fall together, and recover together | Nobody's. No action |
Dust | The gap widens every dry day; rain resets it | The vendor's: free cleaning |
Fault | Output collapses overnight while the sunlight doesn't | The vendor's: free repair |
On an electricity bill, all three look identical: a smaller saving. That's the whole trick behind "it's the pollution." A single number can't separate them. You need a second number: what that exact roof should have made that day.
Part two: the duty exists, the tool doesn't
The timing turned out to matter as much as the idea.
On 17 September 2026, Delhi notified the Delhi Solar Energy Policy 2023 (Second Amendment) . Most coverage was about money. Eligible households using up to 400 units a month can now get a 3 kW system at zero upfront cost . The Centre's ₹78,000 subsidy is matched by Delhi's ₹78,000, with a top-up for whatever is left.
The quieter change was about who watches the roofs afterwards. The amendment makes DISCOMs responsible for monitoring plant performance, identifying under-performing installations and supporting action against non-performing vendors. Every system gets a Digital Solar Asset Identification Number (DSAIN), a permanent record of its specifications, warranty and generation. And vendors still owe five years of free operation and maintenance, now with someone checking.
Then look at the scale. Delhi had 10,073 rooftop systems when the policy was approved. The gazette targets 2.20 lakh new residential installations. That's more than twenty times as many roofs to watch, in about eighteen months, with no tool built for the job.
The policy points DISCOMs at net-metering and generation data. But a generation number can't tell a smoggy week from a dusty one. That gap is where SuryaSaathi fits.
Part three: one number that tells the sky apart from the vendor
Every morning, SuryaSaathi works out how much each roof should have made the day before. It uses satellite sunlight from NASA POWER , air quality and weather from Open-Meteo , and pvlib to model that roof's size and location. The important detail is that the expected value already includes the day's haze.
Then it divides:
latex
\text{Performance} = \frac{\text{actual kWh}}{\text{expected kWh}}
A healthy roof sits in the high 90s on a clear day and on a smoggy one, because smog lowers both numbers together. That single property is what makes the three causes separable. The agent stops asking "did output drop?" and starts asking "did output drop more than the sky explains?"
The rules on top are deliberately simple, so a vendor or a DISCOM engineer can check every decision by hand:
- Smog: expected is low, but performance stays above 90%. No action.
- Dust: the 3-day average is below 91% and falling over 5 dry days. File a free cleaning. If overnight rain brings performance back, the case closes itself, with no visit and no false claim against the vendor.
- Fault: performance falls below 60% overnight, or the inverter reports a fault code. File a free repair.
- Verified fix: performance is back above 93% in a new reading. Close the case.
We made one design decision early and never regretted it: the rules decide, the model explains. The agent on top can only take the action the rules allow. Its job is to turn that decision into a reason a vendor or engineer can read, and to act through tools. Here is a real one from our deployed agent:
JSON
{"systemId": "SS-SIM-0003","date": "2026-09-24","diagnosis": "fault","action": "open_case","reason": "System SS-SIM-0003 produced 3.62 kWh today versus 11.85 kWh expected under normal sunlight, a sudden collapse to just 30.5 percent of expected output. This indicates an inverter or wiring fault, not dirt or weather.","reasonSource": "agent"}
That
reasonSource field turned out to be one of the most important lines in the project. More on that in Part six.Part four: following one reading from the roof to a fixed panel
The best way to explain SuryaSaathi is to follow one reading from that 3 kW roof in Dwarka.
- The roof reports itself - A**** DISCOM data logger reads the inverter every 15 minutes and publishes the day's total to AWS IoT Core over MQTT. Roofs without a logger can use the inverter maker's cloud, a small camera clip that photographs the inverter screen, or, as a fallback, a WhatsApp photo from the family. Either way, the family does nothing.
- It's compared with what the sun allowed - the day's expected output for that roof is already waiting, computed overnight from sunlight and haze.
- The agent diagnoses it - When the performance is 88.8% and has been sliding for five dry days. Smog is ruled out because the expected already accounts for it. A fault is ruled out because there's no fault code and no sudden drop that leaves dust.
- A case is filed - The vendor gets a free-cleaning claim with the chart, the readings and the rupees lost so far, citing the five-year maintenance duty; that's when a three-day clock starts.
- The deadline is chased - No visit in three days, so the case escalates to the DISCOM with the same evidence, automatically.
- The fix is verified, not assumed - When new readings show performance back above 93%, the case closes.
- Then the family hears one WhatsApp message, in Hindi -
आपके panels पर धूल थी। हमने vendor से मुफ्त सफाई करवा दी। (Vendor देर कर रहा था, इसलिए DISCOM से करवाया।) Output वापस 96% पर है।
That message is the entire user interface for the family. No app, no dashboard, no login. Everything else happens between the agent, the vendor and the DISCOM.
The DISCOM sees the other side of it: a console with roof health and money being lost by zone, a vendor leaderboard showing who is slow and who is overdue, and an escalation queue where every case arrives already investigated. You can watch a whole month of this on one roof, including an escalation, in the live demo , and see the real deployed backend on the Live page .
Part five: how we built it on AWS
SuryaSaathi has to watch lakhs of roofs, wait days for vendors, and stay cheap enough for a DISCOM to run. Those three constraints shaped every choice. The whole stack is serverless and defined in AWS CDK, one stack per service.
- AWS IoT Core brings readings in. Each data logger or camera clip gets its own X.509 certificate and a policy that only lets it publish its own readings. An IoT rule hands each message to AWS Lambda, which validates it against a shared JSON schema and stores it.
- Amazon EventBridge runs the clock. Every night it triggers the expected-output job for every roof, and a rollup job that summarises readings and cases by vendor, zone and day.
- Amazon DynamoDB is the memory: systems, readings, cases and the expected-output cache. New readings stream straight to the diagnosis agent. Because of the nightly rollups, the DISCOM console never scans raw readings, even at 20 lakh systems.
- Strands Agents runs the diagnosis agent, with Amazon Bedrock as its default model provider, called through the Converse API. To keep costs down, the model is only asked on days something happens. In our 30-day run, that was 11 model calls out of 130 decisions.
- AWS Step Functions handles the part that takes days. A vendor deadline is a wait measured in days, which is exactly what Step Functions is good at. Every case is one execution, named after the case: notify the vendor, wait, recheck, then verify or escalate and wait again. Each step's input and output is visible in the console, so the accountability trail is something you can actually show.
- Amazon CloudWatch logs every decision as structured JSON: the diagnosis, the action, the case, and whether the reason came from the model or the rules. Amazon Cognito handles sign-in for the vendor and DISCOM views, Amazon API Gateway serves the console and the public Live feed, AWS Secrets Manager holds credentials, and AWS Amplify Hosting serves the site and the console.
Nothing is billed by the hour. There's no VPC, no NAT gateway, no database waiting for traffic. We went further and wrote tests that fail the build if anything hourly-billed sneaks into the stack: tables must be on-demand and log groups must have short retention. Between readings, SuryaSaathi costs almost nothing, because between readings it does almost nothing.
Part six: what broke, and what four days taught us
We pushed 119 commits in four days. Most of them did what we expected. The ones worth writing about are the times the system told us we were wrong.
The agent that was never actually thinking
We built the agent so it could never stall a case. If the model is unavailable, the rules still decide and the reason falls back to a template. It felt like good engineering, and it nearly hid our biggest bug.
Our first version reached Bedrock through a client endpoint that returned a 404 for every model name on our account. Nothing crashed. Cases were filed, escalated and verified exactly as designed. The agent just quietly fell back to its templates on every single call. The model never answered once, and the demo looked perfect.
We only caught it because every decision log
reasonSource : "agent" if the model wrote the reason, "rules" if the template did. One column full of "rules" told us more than any error would have.The fix took two steps. First we moved to Strands' own Bedrock model, which calls the Converse API, and addressed Claude by its cross-region inference profile. Then we hit the next wall: Bedrock still refused calls until our account's Anthropic use-case form was approved. With the deadline close, we added one flag that points the same Strands agent, tools and rules at the Anthropic API instead. The key lives in Secrets Manager and never touches the CloudFormation template, and two tests make sure of it. Bedrock stays the default, fully wired, so switching back is one flag.
The lesson: a graceful fallback is also a silent one. If you build a fallback, log which path ran, every time.
Two implementations that had to agree.
The browser demo runs a full simulated month in TypeScript, in your browser. The backend runs the same rules in Python on Lambda. If they disagreed by even one day, the demo would be showing a story the real system wouldn't tell.
So we exported five "golden" scenarios from the TypeScript engine and wrote parity tests that replay all of them through the Python rules. They assert the same diagnosis, the same case state and the same decision wording every day. That meant matching JavaScript's own rounding (
Math.round and toFixed ) in Python, because 88.75% rounding differently on two sides changes the sentence the family reads.The tests paid off immediately. A scripted rain day in one scenario wasn't washing the panels, so dust kept building through the rain. In the real world, that would have been a false claim against a vendor who hadn't done anything wrong.
The most important day is the boring one!
When we first pointed the Live page at the deployed backend, it showed fifteen rows of "No action". The simulated month ended on a healthy stretch, so every reason the model had written was pushed off the page.
It looked like a bug. It was actually the product working. Out of 130 decisions in our 30-day run, the model was needed for 11. Most days, a roof is fine, and the right thing to do is nothing. We changed the feed so eventful days come first, and we stopped treating a quiet agent as a broken one.
Three things we'd tell ourselves on day 1 :
- Let rules decide and models explain - A DISCOM engineer has to be able to check every claim against a vendor by hand. Keeping the decision in plain rules made the system auditable and made the model's job small enough to be cheap.
- Log the path, not just the result - Our worst bug produced correct-looking output. The one field that told the truth was the one recording how the output was made.
- Design for the day nothing happens - A monitoring system that wants attention every day gets muted, like the family WhatsApp group nobody reads. Ours speaks to the family once, when there's good news.
Part seven: what this changes for Delhi
Per roof, the numbers are small; however, across a city, they're not.
A 3 kW roof in Delhi makes about 4,700 kWh a year. Unchecked dust and faults can quietly take 15–18% of that. Recovering it is 700–850 kWh a year, which is ₹5,000–6,000 back for one family at ₹7 a unit. That's real money for a household that went solar specifically to cut its bill. On top of that comes five years of free maintenance that would otherwise go unclaimed.
Scale that to the 2.20 lakh roofs Delhi plans to add, and it becomes roughly 150–190 GWh a year of clean electricity recovered from panels already on rooftops. That's about ₹110–130 crore a year staying with Delhi households. At India's grid emission factor of roughly 0.7 kg of CO₂ per kWh, it's also around 1.1–1.3 lakh tonnes of CO₂ avoided every year. Across India's 14.8 GW of rooftop solar, recovering even a tenth of the roughly 20 TWh it makes is about 2 TWh a year.
The environmental case is the one we find most convincing. Every unit SuryaSaathi recovers comes from hardware that already exists. There are no new panels to manufacture, no new land, no new grid connection. It's the cheapest clean energy there is: the energy you were already supposed to be getting. And a panel that's kept clean and repaired lasts its full 25-year life instead of being written off early as "not worth it", which means less e-waste.
It also changes who has power in the conversation. Today a family has no way to argue with "it's the pollution." With SuryaSaathi, the evidence arrives before the argument does, and the DISCOM gets cases that are already investigated instead of complaints it has to chase.
Where it meets the Sustainable Development Goals
SDG | How SuryaSaathi contributes |
|---|---|
SDG 7: Affordable and clean energy | Keeps installed rooftop solar producing at full capacity, raising the real renewable share (target 7.2) and keeping bills low |
SDG 13: Climate action | Every recovered unit displaces mostly coal-fired grid power |
SDG 11: Sustainable cities | Gives Delhi's DISCOMs the tool to run a city-scale rooftop programme the policy now requires |
SDG 12: Responsible consumption and production | Gets the full lifetime value out of panels already made, reducing early replacement and e-waste |
SDG 9: Industry, innovation and infrastructure | Turns lakhs of scattered rooftops into monitored, accountable infrastructure |
The money and energy figures are our estimates, worked from the assumptions above. Every system, reading and case on the site is simulated, built on real Delhi weather patterns.
What's next?
Four days got us a working loop: a reading in, a diagnosis, a case chased to a verified fix, and one message home. Next on our list:
- WhatsApp in both directions through AWS End User Messaging Social, including the photo fallback, where the family sends a picture of the inverter screen and the model reads the numbers.
- Hindi voice notes for families who'd rather listen than read.
- Cedar policies enforced on every agent tool call, so vendors see only their own customers and readings are used only with the household's consent.
- The camera clip in the field: an ESP32-CAM on FreeRTOS that photographs any brand of inverter, for roofs with no logger and no cloud.
- A pilot with real DSAIN-linked systems, because simulated roofs can only teach you so much. Real data always has a few surprises waiting.
The duty is already written into Delhi's policy. Lakhs of new roofs are already on their way. What was missing was something to watch them, and to make sure the free maintenance families are owed actually reaches their roofs.
SuryaSaathi was built in four days by Team Mythos ( Rahul Sain , Yukti Mehra and Mayank Dhokal ) for Environmental Hacks, Waste and Energy track, on the Bharat Builds Tour by WeMakeDevs and AWS. Try the live demo , see the deployed backend , watch the film , or read the code .
Sources
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article