It’s not the pollution: how SuryaSaathi tells smog, dust and faults apart

The short version

When a rooftop solar system makes less, there are three usual suspects: smog, dust on the panels, or an inverter or wiring fault. On the electricity bill they look identical.
Only smog is nobody’s fault. Dust and faults are the vendor’s to fix, free, for five years under PM Surya Ghar.
SuryaSaathi compares what each roof made with what it should have made that day, reads the shape of the gap, and files the free cleaning or repair with evidence.
It runs on AWS: IoT Core brings readings in, Lambda and Bedrock-powered agents decide, Step Functions chases the deadline, and DynamoDB remembers everything.

The winter excuse

India has put solar on more than 50 lakh homes under PM Surya Ghar, about 14.8 GW of capacity. Installation gets all the attention. What happens in year two, when output starts slipping, gets almost none: industry experts estimate that 99% of users stop monitoring once the installer leaves.

So when a family in Delhi does notice a smaller saving, and calls the vendor, the answer every winter is the same: “it’s the pollution.” Sometimes it is. Smog really does cut the sunlight reaching a panel. But dust settling on the glass costs 0.3–0.6% of output per day in Delhi, and North Indian systems can lose 17–25% of a year’s output to it even with monthly cleaning. A failing inverter can halve production overnight. Those two are the vendor’s problem, and the free maintenance the family is owed goes unclaimed because nobody can prove which one it was.

Why the bill can’t tell the difference

A monthly bill, or even a daily kWh figure, is a single number. A smoggy week and a dusty week both show up as “less.” To tell them apart you need a second number: how much that exact roof should have produced on that exact day, given the sunlight and the haze.

That’s the whole idea behind SuryaSaathi. Every reading arrives with its own baseline, so the agent isn’t asking “did output drop?” but “did output drop more than the sky explains?”

One number: performance

For every roof and every day, SuryaSaathi works out an expected output from satellite sunlight data (NASA POWER) and air-quality and weather data (Open-Meteo), modelled with pvlib for that roof’s location and size. Crucially, the expected value already includes the day’s haze. Then:

Performance = actual ÷ expected.

A healthy roof sits in the high 90s on a clear day and on a smoggy one, because smog lowers both numbers together. That is what makes the three causes separable.

Three signatures

Each cause leaves a different shape in the gap between expected and actual. The rules are deliberately simple, so a vendor or a DISCOM engineer can check every decision:

Cause	What the data shows	What SuryaSaathi does
Smog	Expected is low, but performance stays above 90%	Nothing. Output recovers when the air clears
Dust	3-day average below 91% and falling over 5 dry days; rain resets it	Files a free cleaning with the vendor
Fault	Performance drops below 60% overnight, or the inverter reports a fault code	Files a free repair with the vendor

Rain matters: overnight rain washes the panels, so a dust case closes on its own if the next reading is back to normal. No visit needed, and no false claim against the vendor. A fix only counts as verified when performance is back above 93% in a new reading.

From a diagnosis to a fixed roof

Diagnosis is only useful if something happens next. For dust or a fault, SuryaSaathi:

Files a case with the vendor, with the readings and chart as evidence, citing the five-year operation and maintenance duty.
Starts a 3-day clock. If the next readings show the problem fixed, the case is verified.
Escalates to the DISCOM if the deadline passes, with the same evidence.
Tells the family once, in their language, when it’s fixed:

आपके panels पर धूल थी। हमने vendor से मुफ्त सफाई करवा दी। (Vendor देर कर रहा था, इसलिए DISCOM से करवाया।) Output वापस 96% पर है। Case SS-142

The family never installs an app. That one message is the whole user interface for them. You can watch a full month of this, including an escalation, in the live demo.

How AWS makes this work

SuryaSaathi has to watch lakhs of roofs, wait days for vendors, and stay cheap enough for a DISCOM to run. That shaped every choice in the stack, which is defined end to end in AWS CDK.

Getting readings in: AWS IoT Core and Lambda

Data loggers and camera clips publish one reading a day over MQTT to AWS IoT Core, each with its own X.509 certificate and a policy that only allows publishing its own readings. An IoT rule hands each message to a Lambda function that validates it against a shared JSON schema, checks the system has consent on record, and stores it. Inverter clouds will be pulled once a day on an Amazon EventBridge schedule.

Reasoning you can audit: Amazon Bedrock and Strands Agents

The diagnosis agent is built with Strands Agents and calls Claude on Amazon Bedrock. The split of responsibilities is deliberate: the rules decide, the model explains. The agent can only take the action the rules allow; Bedrock writes the plain-language reason a vendor or engineer reads. If the model is unavailable, the rules still decide and the reason falls back to a template, so cases never stall. To keep costs down, the model is only asked on days something happens: between one and four calls per system in a 30-day scenario.

Deadlines that don’t forget: AWS Step Functions

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, which makes the accountability trail easy to show.

Memory: Amazon DynamoDB

Systems, readings, cases and the expected-output cache live in DynamoDB. New readings stream straight to the agent, and a nightly job rolls readings and cases into summaries by vendor, zone and day, so the DISCOM console never scans raw readings, even at 20 lakh systems.

Consent and visibility: Cedar and Amazon CloudWatch

Access rules are written as Cedar policies: vendors see only their own customers, and readings are used only with the household’s consent. Every agent decision is logged to CloudWatch as structured JSON, with the diagnosis, the action, the case and whether the reason came from the model or the rules, ready for Logs Insights.

Cost

Everything is serverless, so idle costs are close to zero and the system scales with the number of roofs rather than with servers. The main variable cost is Bedrock, and the agent only calls it when something changes.

What’s next

This is the first post in a series. Next we’ll go deeper into how expected output is modelled from sunlight and haze, how the camera clip reads an inverter screen, how the case workflow handles vendors who don’t respond, and what the DISCOM console shows. WhatsApp delivery and Hindi voice notes are on the roadmap. The code is all on GitHub.

Frequently asked questions

Isn’t lower output in winter just the smog?

Sometimes. Smog lowers the sunlight, so it lowers expected output too, and performance (actual ÷ expected) stays above 90%. When performance falls below that while the sky explains it, something else is wrong: dust or a fault.

Who pays for cleaning and repairs?

For PM Surya Ghar systems, the vendor owes free operation and maintenance for five years. SuryaSaathi files the claim with readings as evidence and escalates to the DISCOM if the vendor misses the deadline.

Does the family need an app or new hardware?

No app. SuryaSaathi reads data from a DISCOM data logger or the inverter maker’s cloud where one exists, or from a small camera clip that reads the inverter screen. A WhatsApp photo is the fallback.

What does the AI actually decide?

Nothing on its own. Simple, explainable rules decide the diagnosis and the action; the agent on Amazon Bedrock explains the decision in plain language. Every decision is logged with its reason.

What happens when it rains?

Rain washes dust off the panels. If an open dust case’s next reading is back to normal after overnight rain, the case closes without a visit.

Is the data in the demo real?

No. Every system, reading and case in the demo and on this site is simulated, built on real Delhi weather patterns.

Sources

See it on a roof

Watch a whole month on one roof in Dwarka, in your browser.

Try the live demo Read the code