Solar Rooftop Monitor.

Project Overview

Tracks what a rooftop solar array actually generates against what it should — catching the underperformance from shading, soiling and faults that quietly steals a big share of your energy.

A rooftop solar array is a silent investment: it sits on the roof, generates power, and — unless you are watching closely — you have no idea whether it is producing what it should. And often it is not. Panels get shaded by a new tree or a chimney, dust and bird droppings build up and cut output, a string develops a fault, an inverter derates, a bypass diode fails — and because the system keeps producing something, these losses are invisible. Studies repeatedly find real-world arrays running well below their potential for exactly these reasons. This project builds a monitor that catches that lost generation by comparing what the array actually produces against what it should, given the sun available.

The key idea is expectation, not just measurement. Measuring generation alone tells you the array made 18 kWh today — but was that good or bad? The monitor measures generation (per string where possible, using current/voltage sensors) and the available sunlight (irradiance) and panel temperature, so it can compute the performance ratio — actual output versus the output the array should have produced under those conditions. A performance ratio that is healthy means the array is fine; one that is low, or falling over time, means energy is being lost, and the monitor can often say why: a sudden drop points to a fault, a gradual decline to soiling, a daily shadow pattern to shading, one string lagging its neighbours to a string-level problem.

Per-string (or per-panel) monitoring is what turns "the array is underperforming" into "string 2 is the problem", because comparing strings that should behave identically instantly localises a fault or a shadow. The monitor logs and trends everything, alerts on abnormal underperformance, and quantifies the lost energy (and money) so a cleaning or a repair can be justified and its benefit verified. It is honest that accurate performance-ratio needs a decent irradiance/temperature reference and that string comparison is the most practical fault signal for a DIY build. But as a monitor that measures generation against expectation, it converts a silent, opaque investment into one you can actually manage — catching the shading, soiling and faults that would otherwise quietly erode your returns for years.

What this project does

• Measures solar generation (per string where possible) via current/voltage
• Measures irradiance and panel temperature to compute expected output
• Computes performance ratio — actual vs expected generation
• Detects underperformance from shading, soiling, faults and derating
• Localises faults by comparing strings that should behave identically
• Trends generation and quantifies lost energy/money
• Alerts on abnormal underperformance and verifies fixes/cleaning

Real-World Applications

Deployment contexts where a build of this kind earns its keep.

Features & Capabilities

• Performance ratio (generation vs expectation), not just kWh
• Per-string comparison to localise faults/shading
• Irradiance + temperature reference for true expectation
• Soiling/shading/fault discrimination from the pattern
• Lost-energy quantification and cleaning/repair verification
• Trending and abnormal-underperformance alerts
• Honest about reference-sensor needs

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• DC current/voltage measurement per string
• Irradiance and panel-temperature sensing
• Performance-ratio and expected-output computation
• String comparison for fault localisation
• Trending, lost-energy quantification and alerting

Bill of Materials

Every part below is commonly available from Indian and international hobby-electronics suppliers. Prices are indicative 2026 retail figures in Indian rupees and will drift — treat them as a budgeting guide, not a quotation.

Estimated total: ₹6,890, excluding tools, shipping and consumables.

Tools and consumables

• Soldering iron (temperature controlled, 350 °C) with 0.8 mm 60/40 or lead-free solder
• Digital multimeter — continuity, DC volts and current ranges
• Wire strippers, flush cutters and a small set of precision screwdrivers
• Heat-shrink tubing and a heat gun (or a lighter, carefully)
• A laptop with a USB port and the toolchain listed above

Hardware Specifications

Consolidated electrical and interface specifications for every active part in the build.

Power Budget & Supply Sizing

Add up the typical active current of every part, then size the supply with at least 50 % headroom so transmit bursts and motor inrush never brown out the controller.

Summed typical draw is 3292.69 mA. With a 1.5× design margin the supply should deliver at least 5000 mA continuously at the stated rail voltage.

Software Requirements & Development Environment

Reference toolchain: Arduino IDE 2.3.x with the ESP32 board package 3.x (or PlatformIO on VS Code). Anything newer normally works; anything older may lack the board definitions used here.

• Install the Arduino IDE 2.3.x (or PlatformIO if you prefer a real editor and dependency locking).
• Add https://espressif.github.io/arduino-esp32/package_esp32_index.json under File → Preferences → Additional Board Manager URLs, then install esp32 from the Boards Manager.
• Set the correct port under Tools → Port. On Linux add yourself to the dialout group: sudo usermod -aG dialout $USER and log out and back in.
• Open the Serial Monitor at 115200 baud — every sketch here logs its state there.
• Keep File → Preferences → Show verbose output during: compilation switched on while you are debugging build errors.

Required libraries

Block Diagram

The block diagram shows the functional decomposition of the system — what senses, what decides, what acts, and where the data ends up.

Circuit Diagram & Wiring

Every signal line in the build is shown below, followed by a pin-by-pin connection table you can work through with a multimeter in hand.

Wire one row at a time and tick it off — most "it does not work" reports trace back to a single swapped pair.

Wiring explanation

• PV DC voltages are high and dangerous even in sunlight — use isolated, appropriately-rated sensing and have a qualified installer do or verify the DC-side connections.
• Sense current and voltage per string so strings can be compared to localise faults/shading.
• Place the irradiance reference in the same plane/orientation as the panels so "expected" reflects the sun the array actually sees.
• Fit a back-of-panel temperature sensor; panel output derates as temperature rises, so temperature is needed for a true expectation.
• Keep the low-voltage electronics isolated from the PV DC side.

System Architecture

Read the stack from the bottom up: physical hardware, the firmware that drives it, the transport that moves data off the device, and the software a human actually looks at.

Working Principle

The core insight is that generation only has meaning against expectation. An array that made 18 kWh today is impossible to judge without knowing how much sun there was — 18 kWh on a bright day may be poor, on a cloudy day excellent. So the monitor measures not just output but the conditions that determine what output should be: the available irradiance (via a reference cell or pyranometer in the panels' plane) and the panel temperature (because PV output derates as cells heat up — a hot panel produces measurably less than a cool one at the same irradiance). From these it computes the performance ratio: actual generation divided by the generation the array should have produced under the measured sun and temperature. Performance ratio is the single number that tells you whether the array is healthy, independent of the weather.

A low or falling performance ratio is the signal that energy is being lost, and the pattern of the loss often reveals the cause. A sudden drop points to a fault — a tripped string, a failed inverter, a blown fuse or bypass diode. A gradual decline over weeks with no rain points to soiling — dust, pollen and droppings accumulating on the glass — which a good rain or a clean reverses (and the monitor can prove the reversal). A loss that recurs at the same time each day and grows with the seasons points to shading from a fixed obstruction whose shadow tracks the sun. And a persistent shortfall may be inverter derating or module degradation. Reading the shape of the underperformance turns "something is wrong" into a likely diagnosis.

The most powerful and practical diagnostic for a DIY build is per-string comparison. Strings of panels wired identically, in the same plane, under the same sun, should generate nearly identically — so when one string lags its neighbours, the problem is almost certainly in that string: a shadow falling on it, a fault, a failed diode, or heavier soiling. This differential approach is beautifully robust because it cancels out the weather entirely — you are not comparing to a model but to an identical sibling under identical conditions, so any divergence is real and localised. "The array is down 15%" becomes "string 2 is producing 30% less than string 1", which points a technician straight at the problem.

What makes the monitor pay is quantification and verification. By continuously comparing actual to expected, it can put a number on the lost energy — and its money value — from soiling or a fault, which is what justifies the cost of a cleaning or a repair (soiling losses often exceed cleaning costs, but only measurement tells you when). And the same measurement verifies the fix: clean the panels and the performance ratio jumps back up by the quantified amount, proving the cleaning paid for itself; repair a string and its output rejoins its neighbours. The design is honest about its needs — a genuinely accurate performance ratio depends on a decent irradiance and temperature reference, and DC-side sensing on a live PV system is hazardous and best left to qualified work — but within that, it transforms rooftop solar from a silent black box into a managed asset, catching the shading, soiling and faults that would otherwise quietly bleed away a meaningful fraction of the generation you paid for.

The maths behind it

Performance ratio

PR = actual energy / expected energy

expected ≈ (irradiance / STC_irradiance) · P_rated · η_temp
  η_temp = 1 + γ·(T_cell − 25°C)   (γ ≈ −0.4%/°C, negative)

PR near its healthy value = fine; low/falling PR = losses.
PR cancels weather, so it is comparable day to day.

Per-string comparison (differential)

Identical strings under identical conditions should match:

  ratio_i = P_string_i / mean(P_other_strings)

  fault/shade on string i if ratio_i << 1 (sustained)
Cancels weather entirely → any divergence is real & localised.

Lost energy / soiling

Loss vs expectation over a period:

  lost_kWh = Σ (expected − actual)
  lost_cost = lost_kWh · tariff (or feed-in rate)

Gradual PR decline (no rain) → soiling; step → fault.
Clean/repair → PR recovers by the quantified amount (verify).

Program Flowchart

The firmware is a single cooperative loop. Nothing blocks for long, so networking, sensing and the user interface all stay responsive.

Assembly Instructions

Build on a breadboard first and only commit to solder once the whole system has run for an hour without a fault.

1. Install per-string sensing safely

   Fit isolated, appropriately-rated current and voltage sensing on each string so strings can be compared. Have a qualified installer do or verify the PV DC-side work.

2. Add irradiance and temperature reference

   Mount an irradiance reference (reference cell/pyranometer) in the panels' plane and a back-of-panel temperature sensor, so expected output reflects the real sun and cell temperature.

3. Set up computation and reporting

   Compute expected output, performance ratio and per-string ratios; log and trend; and set up the dashboard and alerts.

Step-by-Step Implementation Guide

Work through these in order. Each step ends in something you can observe, so a failure is always localised to the step you just finished.

1. Compute expected output, PR and string ratios

   From irradiance and temperature compute expected output, divide actual by expected for PR, and compare strings to localise problems.

   cppsolar-performance.ino Copy Download

   #define P_RATED_W  3000.0f      // array/string rated power (STC)
   #define STC_IRR    1000.0f      // W/m2 at STC
   #define GAMMA     -0.004f       // -0.4%/degC temperature coefficient
   
   float expectedPower(float irr, float tCell){
     float etaTemp = 1.0f + GAMMA*(tCell - 25.0f);
     return (irr/STC_IRR) * P_RATED_W * etaTemp;
   }
   
   float performanceRatio(float actualW, float irr, float tCell){
     float exp = expectedPower(irr, tCell);
     return exp>1 ? actualW/exp : 0;
   }
   
   // Compare each string to the mean of the others (weather cancels out).
   int laggingString(float *p, int n){
     for (int i=0;i<n;i++){
       float sum=0; int c=0;
       for(int j=0;j<n;j++) if(j!=i){ sum+=p[j]; c++; }
       float others = c? sum/c : 0;
       if (others>1 && p[i] < 0.7f*others) return i;   // 30% below siblings
     }
     return -1;
   }

   float etaTemp = 1.0f + GAMMA*(tCell - 25.0f)Applies the negative temperature coefficient so the expected output accounts for a hot panel producing less — without this, a fine array on a hot day looks like it is underperforming.

   return exp>1 ? actualW/exp : 0Performance ratio is actual over expected, the weather-independent number that says whether the array is healthy.

   int laggingString(float *p, int n)Compares each string to the mean of the others; because they share the same weather, a string 30% below its siblings is a localised fault or shadow, not a cloudy patch.

2. Diagnose, quantify and verify

   Classify underperformance by its pattern (sudden fault, gradual soiling, daily shading), quantify lost energy/money, alert, and verify that cleaning/repairs restore performance ratio.

Complete Source Code

The listing below is complete and compiles as written — there are no elided sections. Read the annotations under each block before you upload it.

/* ═══════════════════════════════════════════════════════════════
   Solar Rooftop Monitor — ESP32

   Measures per-string generation against expected output (from
   irradiance + panel temperature), computes performance ratio,
   localises faults/shading by string comparison, and quantifies lost
   energy. DC-side sensing must be isolated/rated (safety).
   ══════════════════════════════════════════════════════════════════ */

#include <WiFi.h>
#include <PubSubClient.h>
#include <Wire.h>
#include <Adafruit_INA219.h>
#include <OneWire.h>
#include <DallasTemperature.h>
#include <BH1750.h>

#define NSTR 2
#define P_RATED_W 3000.0f
#define STC_IRR 1000.0f
#define GAMMA -0.004f

Adafruit_INA219 ina[NSTR];        // per-string (distinct I2C addr)
OneWire ow(4); DallasTemperature panelT(&ow);
BH1750 lux;                        // stand-in for irradiance ref (scaled)
WiFiClient net; PubSubClient mqtt(net);
float lostWh=0; uint32_t lastMs=0;

float expectedPower(float irr,float tCell){
  return (irr/STC_IRR)*P_RATED_W*(1.0f+GAMMA*(tCell-25.0f));
}

void setup(){
  Serial.begin(115200);
  Wire.begin(21,22);
  for(int i=0;i<NSTR;i++) ina[i].begin();     // addresses set per module
  panelT.begin(); lux.begin();
  WiFi.begin(WIFI_SSID,WIFI_PASS); mqtt.setServer(MQTT_HOST,1883);
  lastMs=millis();
}

void loop(){
  if(!mqtt.connected()&&WiFi.status()==WL_CONNECTED) mqtt.connect("solar-1");
  mqtt.loop();
  uint32_t now=millis(); float dtHr=(now-lastMs)/3600000.0f; lastMs=now;

  panelT.requestTemperatures();
  float tCell = panelT.getTempCByIndex(0);
  float irr   = lux.readLightLevel() * IRR_SCALE;   // → W/m2 (calibrated ref)

  float p[NSTR], total=0;
  for(int i=0;i<NSTR;i++){
    float v = ina[i].getBusVoltage_V();
    float i_a = ina[i].getCurrent_mA()/1000.0f;
    p[i] = v*i_a; total += p[i];
  }

  float expected = expectedPower(irr, tCell);
  float pr = expected>1 ? total/expected : 0;
  lostWh += fmaxf(0, expected-total) * dtHr;         // accumulate lost energy

  // per-string comparison
  int lag = -1;
  for(int i=0;i<NSTR && lag<0;i++){
    float others=0; int c=0;
    for(int j=0;j<NSTR;j++) if(j!=i){ others+=p[j]; c++; }
    if(c && others/c>1 && p[i] < 0.7f*(others/c)) lag=i;
  }

  const char* diag = nullptr;
  if (lag>=0) diag = "string lagging (fault/shade)";
  else if (pr < 0.7f && irr>200) diag = "array underperforming";

  char m[240];
  snprintf(m,sizeof m,
    "{\"total_W\":%.0f,\"pr\":%.2f,\"irr\":%.0f,\"tCell\":%.1f,"
    "\"lag\":%d,\"lost_Wh\":%.0f,\"diag\":\"%s\"}",
    total, pr, irr, tCell, lag, lostWh, diag?diag:"ok");
  mqtt.publish("solar/1/perf", m);
  if (diag) mqtt.publish("solar/1/alert", diag);

  delay(10000);                                      // 0.1 Hz
}

Configuration & Calibration

Configuration steps

• Set the rated power, temperature coefficient, and irradiance-reference calibration.
• Configure per-string sensing and the lagging-string threshold.
• Set underperformance/alert thresholds and the tariff for lost-energy costing.
• Configure logging/trending and the dashboard.

Calibration procedure

An uncalibrated sensor produces confident, precise, wrong numbers. Do this once per physical unit and record the constants.

1. Irradiance reference

   Calibrate the irradiance sensor/reference cell against a known reference in the panels' plane so expected output is accurate.

2. Per-string sensing

   Verify current/voltage per string against a reference and confirm identical strings read alike in clear sun.

3. Baseline PR

   Establish the array's healthy performance ratio on clean, clear days as the reference for detecting decline.

Network Architecture & Connectivity

Communication protocol

Generation, performance ratio, per-string data and lost-energy publish on a slow cadence; underperformance and lagging-string alerts publish on detection.

Message contract between the device and the broker.

Cloud platform configuration

A dashboard trends performance ratio and per-string generation, quantifies lost energy and cost, and verifies cleaning/repairs; alerts drive O&M.

Dashboard setup

Generation and PR trends, per-string comparison, irradiance/temperature, and lost-energy/cost with cleaning/repair markers.

Mobile app integration

Alerts on abnormal underperformance and lagging strings; cleaning-benefit summaries.

Security considerations

• Authenticate nodes; secure the energy data.
• Keep DC-side sensing isolated and safe.
• Alert on monitor silence.

Testing Procedure & Expected Output

Test from the bottom up. Confirm power, then each sensor in isolation, then the integrated loop — the first failing step tells you exactly where to look.

Bench-test checklist. If a row fails, stop and fix it before moving on.

Expected output

The dashboard shows generation, performance ratio, per-string comparison, irradiance/temperature, and lost-energy/cost, with alerts for underperformance and lagging strings.

{
  "total_W": 2180,
  "pr": 0.74,
  "irr": 920,
  "tCell": 52.0,
  "lag": 1,
  "lost_Wh": 3400,
  "diag": "string lagging (fault/shade)"
}

A performance ratio of 0.74 with string 1 lagging points to a localised problem on that string; the accumulated lost energy (3.4 kWh) quantifies what it is costing — turning silent underperformance into an actionable, costed fault.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Sample at a modest rate; PR and string comparison need conditions, not high speed.
• Compute PR with temperature correction for fair comparison across days.
• Trend PR and per-string ratios to catch decline and localise faults.
• Quantify lost energy so O&M is justified and verified.
• Replace every delay() with a millis() comparison — blocking delays are the single most common cause of dropped readings.
• Sample sensors on a fixed cadence and publish on a slower one; you almost never need to transmit at the sampling rate.
• Move networking into its own FreeRTOS task so a slow DNS lookup cannot stall the control loop.
• Use uint8_t / uint16_t where the range allows; on an 8-bit AVR a 32-bit add costs four times as much.
• Batch several samples into one MQTT publish. Radio time, not CPU time, dominates the energy budget.
• Set the MQTT keep-alive to a value that matches your reporting interval so the broker does not churn reconnections.
• For battery builds use deep sleep between samples: an ESP32 drops from ~160 mA awake to about 10 µA asleep, which is the difference between days and months of runtime.

Safety Precautions

• PV arrays produce dangerous DC voltage in any light and cannot simply be switched off — use isolated, rated sensing and qualified installers for DC-side work.
• Keep low-voltage electronics isolated from the PV DC side.
• Accurate performance ratio needs a decent irradiance/temperature reference; label estimates where the reference is rough.
• Follow rooftop and electrical safety for installation and cleaning.
• Wear eye protection when soldering or cutting, and solder in a ventilated space — rosin flux fumes are a respiratory irritant.
• Power the circuit through a bench supply with a current limit while you are testing. A 300 mA limit turns a wiring mistake into a beep instead of a dead board.
• Disconnect power before changing any wiring. Hot-plugging a sensor onto a live bus is the fastest way to lose a controller.

Maintenance

• Verify irradiance-reference calibration and per-string sensing periodically.
• Act on soiling/fault alerts; clean/repair and confirm PR recovery.
• Re-baseline PR after any array change.
• Keep DC-side connections inspected and safe.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Rotate the microSD card annually and keep an image of the working system. Cards used as loggers wear out silently.
• Keep the broker and dashboard containers patched, and rotate device credentials at least once a year.
• Recalibrate at the interval given in the calibration section, and keep the constants in a text file next to the firmware — not only in flash.
• Keep a short logbook of firmware versions and what changed. Six months later you will not remember why that constant is 1.083.

Future Improvements & Upgrades

A working v1 is a platform, not a finish line. These are the upgrades that add the most capability for the least rework.

• Add per-panel monitoring for finer localisation.
• Add I-V curve tracing for deeper fault diagnosis.
• Fuse a weather/forecast feed to predict expected generation.
• Estimate degradation rate over years for warranty/finance.
• Design a proper PCB. Once the breadboard version has run for a month, moving to a two-layer board removes the intermittent-contact failures that dominate prototype faults.
• Add over-the-air firmware updates so you never have to physically reach a deployed node again.
• Add persistent local storage (microSD or the on-chip flash) so a network outage does not create a hole in your data.
• Move configuration out of the source: a captive-portal setup page or a JSON config file makes the build reusable without a recompile.
• Add a battery and solar option so the unit survives a power cut and can be sited away from a socket.
• Write a small test harness that feeds synthetic sensor values through the decision logic, so you can validate thresholds without physically triggering the event.

Frequently Asked Questions

References & Learning Resources

These are the primary sources worth reading in full. Manufacturer datasheets always outrank forum posts when the two disagree.

1. Photovoltaic performance ratioReference
2. PV soiling and cleaningReference
3. PV temperature coefficientReference
4. PV DC safety (arc flash / live arrays)Reference
5. Solar monitoring and fault detectionReference