Where Did My Solar Units Go?

Rooftop solar can quietly lose 3 to 10% of its energy to heat, dust, wiring and outages, and owners only find out from the bill. WattBack compares what a roof should have made with what it really made, splits the gap into named losses and says what to fix first. Built for Environmental Hacks on AWS Elastic Beanstalk, SNS and DynamoDB.
Rohit Durbha

Published Oct 11, 2026
Last modified Oct 13, 2026
Your solar panels never tell you when they are having a bad day.
They just make a little less. A bit of dust here, a hot afternoon there, a loose wire, a power cut you did not notice. And you only find out months later, when the electricity bill is higher than you expected.
Here is a real month. A 56.6 kWp roof in Punjab made 4,917 kWh in September 2026. Was that good? On its own, that number cannot say. WattBack says the roof should have made 5,710 kWh, and shows where the other 793 went.
I built WattBack to fix that. Give it a rooftop and it answers one question: what should this system have produced today, and exactly where did each missing unit go?
﻿
The problem: a loss nobody can see
Rooftop solar is booming in India. On 31 August 2026 the country had 32.59 GW of grid-connected rooftop solar (MNRE). In the first half of 2026 alone, about 6.4 GW was added, more than double the same period last year. Under PM Surya Ghar, more than 39 lakh homes have installed a system.
But most owners see only one number: what the roof made today. They never see what it should have made. And a rooftop loses energy in many quiet ways:
Heat. Panels lose about 0.4 to 0.5% of their power for every degree above 25 °C. A panel on a hot day can be far hotter than the air. At 60 °C, that is a loss of about 14%.
Dust. NREL estimates that dust (soiling) can cost anywhere from 0 to 7% of yearly output in the US. One 2019 study put the world's soiling loss at 3 to 4% of all solar energy in 2018. And light rain can spread dust instead of washing it off.
Wires, inverter, shade and power cuts. Each one is small, but together they add up, and nobody is watching them.
Step
Number
where it comes from
Rooftop solar in India
32.59 GW
MNRE, 31 Aug 2026
Yearly output at 1,650 units per kW
about 53.8 TWh
Calculated
3% lost
about 1.6 TWh a year
Calculated
Value at ₹6.8 per unit
about ₹1,100 crore a year
Calculated
I estimate these quiet losses at 3 to 10% of output. Let's use the careful end of that range, 3%:
Rooftop solar in India: 32.59 GW (MNRE, 31 Aug 2026)
Yearly output at 1,650 units per kW (my assumption): about 53.8 TWh
3% lost: about 1.6 TWh a year
Value at ₹6.8 per unit (my assumption): about ₹1,100 crore a year
That is roughly ₹1,100 crore of clean energy thrown away every year, even at the low end. Rooftop solar is one of the named problems in the Waste and Energy track, so this is where WattBack belongs.
﻿
The solution: WattBackWattBack works like a health check-up for a solar roof. It does three things:
It works out what the roof should have made, hour by hour, using weather data (ERA5) and solar physics (the pvlib library).
It compares that with what the roof really made. I tested it on two real systems from PVOutput: a 56.6 kWp system in Punjab (nearly six years of data) and a 3.09 kWp home system in South India (over three years).
It splits the gap into named losses, so every missing unit has an address.
Here is the answer for the Punjab system in September 2026. It should have made 5,710 kWh. It made 4,917 kWh, which is 13.9% less.
﻿
Figure 1. Where the missing units went (WattBack loss engine, 1 to 29 September 2026). Clipping was 0%.
Look at the two colours in the chart. Heat and sunlight angle are mostly weather and physics. Inverter, dust and cables are things an owner can inspect, clean or fix. WattBack keeps the two apart, so you stop worrying about losses nobody can change and start acting on the ones you can.
The story also adds up, with one honest note. Less than 1% of the gap was left unexplained (0.1% on the Punjab system, 0.7% on the small one). The named losses plus the unexplained part equal expected minus actual, and the tests check that. But that is partly by design: "unexplained" is whatever is left over, and I fit two correction numbers on the same month. So read it as a consistency check, not as proof. The real test comes next.
On top of the physics, a small LightGBM model learns what the physics misses. In a walk-forward test, where it only ever sees the past, it cut the error by about a third compared with a simple "same as last week" guess (0.246 against 0.368, on 3,143 predictions it had never seen). This is the out-of-sample evidence.
﻿
Figure 2. The same story on the live dashboard.
Who uses it, and howWattBack is made for people who are not solar engineers: a home owner, a housing society secretary, a small shop owner. So I kept three rules: ask for little, speak in rupees, and say what to do next.
﻿
Three steps to start. Pick a location (tap "use my location" or choose one of ten ready-made Indian presets). Enter three numbers from the installer's paper: size in kWp, tilt and direction. Then check the satellite map, the expected output and the shading view.
A plain answer on cleaning. The cleaning page compares "wash now" with "wait for rain" and shows what a wash is worth in rupees.
An action ladder. Five checks: soiling, shading, wiring, inverter and grid. Each is marked OK, WATCH or ACT, and the first ACT is the job for today.
Alerts by email. When output suddenly drops, WattBack can alert the owner by email through Amazon SNS, along with a daily digest. Currently, I run the alert command manually, but scheduling it is my next step. I chose email because bulk SMS in India requires additional DLT registration, which would be too much overhead for a weekend project.
Nothing to install. It is a website. No app and no hardware.
﻿
Figure 3. Adding a roof takes three steps.
﻿
Figure 4. The cleaning page says what to do today.
Try before you decide: the Solar Digital PlannerOne of my favourite parts is the Solar Digital Planner. It shows a roof in 2D on a grid map as a simulator. Slide the clock or change the season and the sun moves across the sky. Place a tree, a wall or a water tank and the shadows fall in the right place; shaded panels turn red. Switch on rain and the dust washes off. Switch on clouds and the light drops.
It answers a question every owner asks: "Will that tree hurt my panels?"
﻿
Figure 5. The Solar Digital planner: simulator to build the surroundings around you to find out the best spot for your panel.
Under the hood: architecture and tech stackHere is what WattBack is made of:
Web app: Python, Django, gunicorn and WhiteNoise. Server-rendered pages plus a JSON API.
Solar physics: pvlib for sunlight on the panel, incidence angle, cell temperature and the dust (soiling) model.
Data and ML: pandas, NumPy, SciPy, scikit-learn and LightGBM.
Data sources: ERA5 weather (via Open-Meteo), CAMS air quality for dust, PVGIS from the European Commission, Global Solar Atlas, and PVOutput for real generation.
Digital Twin: Three.js for the 3D scene and MapLibre for the satellite map.
Quality: pytest, with 60 automated tests.
AI help: I used the opencode AI coding agent for scaffolding, tests and docs. I reviewed the code and checked it with pytest.
How I used AWS: deployed, not just localWattBack is deployed on AWS in the Mumbai region (ap-south-1). The live site is a real Elastic Beanstalk environment, and these services are doing real work:
Elastic Beanstalk on EC2 (t3.micro, free tier): runs the Django app behind nginx and gunicorn. One command,  eb deploy , ships a new version.
S3: stores every deploy bundle (Beanstalk application versions).
CloudWatch: collects app and server logs, kept for 7 days.
SNS: sends outage alerts and the daily digest by email. On 11 October 2026 it published 10 outage alerts and a digest.
DynamoDB: keeps a copy of every onboarded system (table  wattback-systems , pay-per-request billing).
IAM: a deploy-only user and the Beanstalk service role.
You can check each one yourself. The Elastic Beanstalk environment shows green health in the console. S3 holds one bundle for every  eb deploy . CloudWatch has the app and server log groups. The SNS topic has an email subscription and received the alerts above. The DynamoDB table  wattback-systems  gets an item each time a roof is saved.
﻿
Figure 6. How the pieces fit together.
Why Elastic Beanstalk and not Lambda?Many AWS projects reach for Lambda first. I did not, for three reasons:
The physics runs on long hourly series. Dust builds up hour after hour, so the model is one long chain, not many small separate jobs. The data is cached on disk right next to the app.
The libraries are heavy. pvlib, pandas and LightGBM together made me expect slow cold starts, and onboarding must answer in seconds. A warm server is already ready.
Simple wins. WattBack is one Django app. Three commands deploy it:  eb init ,  eb create wattback --single  and  eb deploy .
Serverless is my upgrade path when traffic grows. It was not a day-one need.
One design choice I like: AWS is optionalSaving to DynamoDB is a bonus, never a requirement. If AWS credentials exist, WattBack copies the system to DynamoDB. If not, it quietly carries on with the local database. The same code runs on the live site, on a judge's laptop and in tests. (Shortened from  dashboard/storage.py .)
Python
def save_system(payload):
    has_aws = os.environ.get("AWS_ACCESS_KEY_ID") or os.environ.get("AWS_PROFILE")
    if not has_aws:
        return {"mode": "db-only"}      # no AWS? keep going locally
    try:
        client = boto3.client("dynamodb", region_name="ap-south-1")
        client.put_item(TableName="wattback-systems", Item={...})
        return {"mode": "dynamodb"}
    except Exception as exc:
        log.warning("DynamoDB mirror skipped: %s", exc)
        return {"mode": "db-only"}      # never block onboarding
What fought backHackathons are never smooth. Three problems taught me the most.
1. A model that fits too well proves nothingIt is easy to make a model match one month perfectly: give it a fudge number for every day. Then it explains everything and proves nothing. So I allowed exactly two fudge numbers per window, one for clear-sky days and one for cloudy days, and nothing per day. Days when the system was down are left out of the fitting.
Even with that strict rule, the model matched the Punjab system to within 0.12% in September. But I learned to be careful with that number and challenge 2 shows why.
2. Light rain does not clean panelsMy first version treated any rain as a wash. That is not how roofs behave. A drizzle under 1 mm can smear dust into mud spots. Rain of 1 to 10 mm removes only part of it (I used about 30%). Only rain above 10 mm fully resets the panel.
Here is what the rule changed for the same Punjab month (1 to 29 September 2026), with everything else fixed:
Any rain washes the panel: dust loss 0.32%
Rain over 1 mm washes it fully: dust loss 0.73%
Three tiers (what WattBack uses): dust loss 1.36%
The dust number grew more than four times. Yet the model matched the real output almost the same each time: the unexplained part was 0.07%, 0.09% and 0.12%. One month cannot tell these rules apart, because the two correction numbers soak up the difference. So the dust split is an estimate and not a measurement. I chose the three tiers because they match how rain behaves on roofs and I added a wash log so owners can correct the model with their real cleaning dates.
3. Deployment day: three bugs, one config fileThe app worked on my laptop. On Elastic Beanstalk, three things broke in a row.
Bug 1: The database was empty after every deploy.
Why: Beanstalk replaces the app folder on each deploy, and my SQLite file lived inside it.
Fix: I moved the database outside the app folder. Migrate and load now run after each deploy.
Bug 2: Every page returned an error (500 or 502).
Why: The database file was created by root, but the web server runs as another user, so writing failed ("readonly database").
Fix: I set the file owner to the web user right after creating it.
Bug 3: The live site looked unstyled.
Why: Static files returned 404. This platform does not collect them automatically.
Fix: I added a  collectstatic  step to the deploy config and checked that the CSS and JS now load.
All three fixes live in one small file,  .ebextensions/99_wattback.config , so every future deploy repeats them by itself.
Where things standThe hackathon says "one feature that runs beats five that almost do." So here is an honest list.
What works right nowLive on AWS Elastic Beanstalk, open to anyone.
The full missing-units breakdown on two real systems, with nearly six years of Punjab data and over three years from the small home system.
An outage detector that finds real gaps in the record, for example 9 days in July 2024 at the Punjab site.
The cleaning advisor, the action ladder, email alerts, the DynamoDB copy, the SolarCraft planner and the Digital Twin.
60 automated tests.
Email alerts through SNS, run by a command (10 alerts and a digest on 11 October 2026).
What it does not do yetA brand-new roof gets the expected-output baseline, the shading view and the Digital Twin. Its full breakdown needs its real output. For now owners can type in kWh by hand. Easier ways to bring data in (paste a PVOutput link, upload a CSV, connect Enphase or Growatt) are still on my list.
I tested on one hard month. September is monsoon season, so one month is not a full year.
Dust is estimated from air-quality data, not from sensors or cameras. The wash log lets owners correct it.
Rain timing follows the site's past rain pattern, not a real forecast.
It runs on one small server with SQLite and plain HTTP. Fine for a demo, not for thousands of users.
Alerts and the daily digest are run by a command, not by a timer yet.
If I had more timeCheck the model against a full year of PVGIS data, in every season.
A one-click "add my roof": paste a link or a CSV, then connect inverters directly.
A real weather forecast behind the wash-or-wait advice.
Messages in local languages, such as Telugu and Hindi.
Run the alerts on a schedule (EventBridge Scheduler plus a small Lambda that calls the app), so owners get the email without me typing a command.
HTTPS with CloudFront, a bigger database such as Aurora, and Lambda for scheduled alerts once traffic grows.
Try itOpen the live demo, or run it on your laptop. The data ships with the repo, so no AWS account is needed:
Bash
pip install -r requirements.txt
python manage.py migrate
python manage.py load_wattback
python manage.py runserver
Sunlight is free. Losing it quietly should not be. WattBack's job is simple: make every missing unit visible, so the owner can get it back.
Video:  youtu.be/Ue1WJ5L-FlM 
Live demo:  wattback.eba-yjd2vepx.ap-south-1.elasticbeanstalk.com 
Code:  github.com/rohitsagar9/wattBack 
SourcesIndia rooftop solar capacity (MNRE data, 31 Aug 2026) and PM Surya Ghar installs:  SolarQuarter 
Rooftop additions in the first half of 2026:  JMK Research 
Dust (soiling) losses of 0 to 7% in the US (NREL):  Clean Power 
Global soiling loss of 3 to 4% in 2018 (review of Ilse et al.):  PubMed Central 
Panel temperature coefficient and heat loss:  Sinovoltaics 
Data and tools: ERA5 via Open-Meteo, CAMS, PVGIS (European Commission), Global Solar Atlas, PVOutput and pvlib. The loss numbers are from my own run of the  WattBack engine  on 11 October 2026.
﻿
﻿
Step	Number	where it comes from
Rooftop solar in India	32.59 GW	MNRE, 31 Aug 2026
Yearly output at 1,650 units per kW	about 53.8 TWh	Calculated
3% lost	about 1.6 TWh a year	Calculated
Value at ₹6.8 per unit	about ₹1,100 crore a year	Calculated