Wer „PR Performance“ im Zusammenhang mit Photovoltaik und Anlagen-Monitoring sucht, meint die Performance Ratio (PR). Sie setzt den tatsächlich eingespeisten Ertrag einer Anlage ins Verhältnis zu dem Ertrag, den die gemessene Einstrahlung theoretisch ermöglicht hätte. Ein Monat mit 80 % PR bedeutet: Vier Fünftel der physikalisch verfügbaren Energie sind im Zähler angekommen. Der Rest ging durch Wärme, Kabel, Wechselrichter, Verschattung, Verschmutzung oder Ausfälle verloren. Entscheidend ist dabei nicht die Formel, sondern die Qualität der Einstrahlungsdaten dahinter.
Der Suchbegriff ist mehrdeutig. „PR“ steht auch für Public Relations, für einen persönlichen Rekord im Sport oder in der Forschung für „Performance Representatives“, etwa beim Benchmarking von KI-Beschleunigern an der Universität Tübingen. Dieser Artikel behandelt die Kennzahl aus der Solartechnik – aus der Perspektive von jemandem, der solche Werte in Dashboards und Datenpipelines ausrechnet und dabei regelmäßig über schlechte Rohdaten stolpert.
So wird die Performance Ratio berechnet
Die PR gehört zu den Kennzahlen, die im PV-Monitoring als Branchenstandard gelten. Der Monitoring-Anbieter meteocontrol beschreibt PR und Verfügbarkeit in seinem Fachbeitrag zu KPIs im VCOM-Portal als etablierte Marktstandard-KPIs. Die Rechnung selbst ist kurz.
Die drei Größen der Formel
- Endertrag (Final Yield, Yf): eingespeiste Energie in kWh geteilt durch die installierte Nennleistung in kWp. Einheit: Stunden, genauer „Volllaststunden“.
- Referenzertrag (Reference Yield, Yr): Einstrahlungssumme in Modulebene in kWh/m² geteilt durch die Bezugseinstrahlung von 1 kW/m² unter Standard-Testbedingungen. Auch das ergibt Stunden.
- Performance Ratio: PR = Yf ÷ Yr.
Weil beide Größen in Stunden vorliegen, ist die PR dimensionslos. Genau das macht sie nützlich: Sie ist weitgehend unabhängig von Anlagengröße und Standort und lässt sich deshalb zwischen Anlagen vergleichen – solange die Einstrahlung sauber gemessen wurde.
Rechenbeispiel für einen Novembermonat
Eine fiktive Dachanlage mit 9,8 kWp speist im November 330 kWh ein. Der Einstrahlungssensor in Modulebene summiert für denselben Monat 42 kWh/m².
| Schritt | Rechnung | Ergebnis |
|---|---|---|
| Endertrag Yf | 330 kWh ÷ 9,8 kWp | 33,67 h |
| Referenzertrag Yr | 42 kWh/m² ÷ 1 kW/m² | 42,00 h |
| Performance Ratio | 33,67 ÷ 42,00 | 80,2 % |
Auf den ersten Blick ein ordentlicher Wert. Ob er stimmt, hängt an zwei Stellen, an denen Monitoring-Projekte in der Praxis am häufigsten scheitern: am Sensor und an der Temperatur.
Wo die PR im Dashboard lügt
Die Formel ist robust. Die Eingangsdaten sind es nicht. Wer PR-Werte in einer Web-App oder einem Reporting anzeigt, sollte drei Fehlerquellen kennen, bevor er einer Kurve glaubt.
Sensorfehler schlagen fast eins zu eins durch
Die Einstrahlung steht im Nenner. Misst der Sensor 5 % zu viel – durch Kalibrierdrift, eine leicht falsche Neigung oder weil er an einer anderen Dachfläche montiert ist als die Module –, sinkt die PR im Beispiel von 80,2 % auf 76,4 % (33,67 ÷ 44,1). Ein reiner Messfehler von fünf Prozent verschiebt die Kennzahl also um rund 3,8 Prozentpunkte. Das ist mehr als der Unterschied, den viele Betreiber zwischen einer gut und einer mäßig gewarteten Anlage erwarten würden.
Praktische Regel: Eine PR-Veränderung unter vier Prozentpunkten ist kein Befund, solange der Sensor nicht nachweislich kalibriert ist. Erst den Sensor prüfen, dann die Anlage.
Noch ungenauer wird es, wenn gar kein Sensor vor Ort hängt und die Einstrahlung aus Satelliten- oder Wetterdiensten kommt. Das ist legitim, aber dann gehört die Datenquelle sichtbar neben die Kennzahl ins Dashboard.
Kalte Module schönen die Winterwerte
Module arbeiten bei niedrigen Temperaturen effizienter; ihre Leistung ändert sich laut Datenblatt mit einem Temperaturkoeffizienten, der bei vielen kristallinen Modulen im Bereich von einigen Zehntelprozent pro Kelvin liegt. Den genauen Wert liefert das Datenblatt des eingesetzten Moduls – nicht eine Faustregel.
Nehmen wir für das Beispiel −0,35 %/K an und eine mittlere Modultemperatur von 5 °C im November. Die Abweichung zu den 25 °C der Standard-Testbedingungen beträgt −20 K. Daraus ergibt sich ein Korrekturfaktor von 1 + (−0,0035 × −20) = 1,07. Die temperaturkorrigierte PR liegt damit bei 80,2 % ÷ 1,07 = 75,0 %.
Der rohe Novemberwert sieht also gut fünf Punkte besser aus, als die Anlage technisch ist. Im Sommer passiert das Gegenteil: Heiße Module drücken die rohe PR, obwohl nichts defekt ist. Wer Monatswerte ohne Temperaturkorrektur nebeneinanderstellt, sieht deshalb häufig ein Saisonmuster, das nur aus der Physik stammt – und sucht im Juli nach einem Fehler, den es nicht gibt.
Datenlücken, die niemand bemerkt
Bei 15-Minuten-Intervallen liefert ein Tag 96 Messpunkte. Fehlen davon acht, etwa weil der Datenlogger nach einem Router-Neustart hing, fehlen 8,3 % des Tages. Das Tückische: Fällt die Lücke gleichzeitig beim Zähler und beim Sensor aus, bleibt die PR nahezu unverändert. Fällt nur eine der beiden Reihen aus, springt sie – nach oben oder unten, je nachdem, welche Reihe fehlt.
November und Dezember: die schwierigsten PR-Monate
Die dunkle Jahreszeit ist für die Kennzahl die unzuverlässigste. Das liegt nicht an der Anlage, sondern an den Bedingungen, unter denen gemessen wird.
| Wintereffekt | Wirkung auf die PR | Wie man ihn erkennt |
|---|---|---|
| Schnee auf den Modulen | PR fällt stark, teils gegen null | Einstrahlung normal, Ertrag nahe null, Modultemperatur unter 0 °C |
| Schnee auf dem Sensor, nicht auf den Modulen | PR steigt unplausibel über 100 % | Ertrag vorhanden, Einstrahlung nahe null |
| Niedrige Einstrahlung, Teillast | Wechselrichter kann im unteren Lastbereich weniger effizient arbeiten | viele Stunden mit geringer Leistung in den Rohdaten |
| Tiefe Sonne, lange Schatten | Verschattung durch Nachbargebäude oder Bäume, die im Sommer keine Rolle spielt | Ertragseinbruch zu festen Uhrzeiten, reproduzierbar an klaren Tagen |
| Kalte Module | rohe PR wirkt besser als die Anlage | Temperaturkorrektur zeigt den Abstand |
Dazu kommt die kleine Datenbasis. Bei 42 Stunden Referenzertrag im Monat verschieben wenige schlechte Tage die Monats-PR stärker als im Juni, wenn ein Vielfaches an Einstrahlung zusammenkommt. Für Vergleiche über das Jahr eignen sich deshalb rollierende Zwölf-Monats-Werte besser als ein einzelner Wintermonat.
Wer im November oder Dezember ein Monitoring neu aufsetzt oder eine Anlage abnimmt, sollte die Winter-PR nicht als Referenzwert festschreiben. Eine sinnvolle Grenze: Monate mit einem Referenzertrag unter 50 Stunden werden im Dashboard angezeigt, aber nicht für Alarmschwellen verwendet.
PR-Berechnung in einer eigenen Monitoring-App umsetzen
Viele Wechselrichter-Portale zeigen eine PR an, erklären aber selten, welche Einstrahlungsquelle dahintersteckt und ob Lücken oder Schneetage herausgefiltert wurden. Wer eigene Auswertungen baut – etwa in einer Web-App mit Next.js und PostgreSQL –, kann diese Entscheidungen offenlegen statt sie zu verstecken.
Filter vor der Division
Die eigentliche Arbeit steckt nicht in der Division, sondern in den Ausschlussregeln davor. Ein minimaler Ansatz in TypeScript:
```ts type Interval = { energyKwh: number | null; // Zählerwert im Intervall irradianceKwhM2: number | null; // Einstrahlung Modulebene im Intervall moduleTempC: number | null; };
export function performanceRatio( intervals: Interval[], kWp: number, tempCoeffPerK: number // z. B. -0.0035 aus dem Datenblatt ) { // Nur Intervalle, in denen BEIDE Reihen vorliegen const valid = intervals.filter( (i) => i.energyKwh !== null && i.irradianceKwhM2 !== null ); // Schwachlicht ausschließen: unter 50 W/m² bei 15 min = 0,0125 kWh/m² const usable = valid.filter((i) => i.irradianceKwhM2! >= 0.0125);
const yf = usable.reduce((s, i) => s + i.energyKwh!, 0) / kWp; const yr = usable.reduce((s, i) => s + i.irradianceKwhM2!, 0) / 1; const pr = yr > 0 ? yf / yr : null;
const temps = usable.map((i) => i.moduleTempC).filter((t): t is number => t !== null); const avgTemp = temps.length ? temps.reduce((s, t) => s + t, 0) / temps.length : null; const prCorr = pr !== null && avgTemp !== null ? pr / (1 + tempCoeffPerK * (avgTemp - 25)) : null;
return { pr, prCorr, coverage: valid.length / intervals.length, // Anteil vollständiger Intervalle referenceYieldH: yr, }; } ```
Zwei Details verdienen Aufmerksamkeit. Erstens: Der Durchschnitt der Modultemperatur ist hier ungewichtet. Für eine sauberere Korrektur sollte man ihn mit der Einstrahlung gewichten, weil ein kaltes Intervall mit kaum Licht den Ertrag kaum beeinflusst. Zweitens: Die Schwachlichtschwelle von 50 W/m² ist eine Annahme für dieses Beispiel. Sie gehört als Konfigurationswert in die Datenbank, nicht fest in den Code, damit spätere Auswertungen nachvollziehbar bleiben.
Was ins Dashboard gehört
Eine einzelne PR-Zahl ohne Kontext führt zu falschen Entscheidungen. Neben dem Wert sollten sichtbar sein:
- Datenabdeckung in Prozent. Unter 90 % vollständiger Intervalle wird der Wert grau markiert.
- Einstrahlungsquelle: Sensor vor Ort, Satellit oder Wetterdienst – und für den Sensor das Datum der letzten Kalibrierung.
- Roh- und temperaturkorrigierte PR nebeneinander, damit Saisoneffekte nicht als Defekt gelesen werden.
- Referenzertrag in Stunden, damit sofort erkennbar ist, ob ein Monat genug Licht für eine belastbare Aussage hatte.
Mit diesen vier Feldern wird aus einer hübschen Kurve ein Werkzeug, mit dem ein Betreiber entscheiden kann, ob er einen Servicetechniker schickt oder abwartet.
Wann ein PR-Abfall ein echter Befund ist
Nicht jeder Rückgang verlangt eine Reaktion. Eine Entscheidungsregel, die sich aus den obigen Fehlerquellen ableiten lässt:
- Nur ein Monat, Winter, Referenzertrag unter 50 h: beobachten, nichts unternehmen.
- Rückgang unter 4 Prozentpunkten bei unkalibriertem Sensor: zuerst Sensor und Montageort prüfen.
- Rückgang in der temperaturkorrigierten PR über mehrere Monate mit guter Datenabdeckung: Anlage prüfen lassen – Strings, Wechselrichter, Verschmutzung, neue Verschattung.
- PR über 100 %: fast sicher ein Messproblem, kein Wunder. Schnee auf dem Sensor, falsch konfigurierte Nennleistung oder vertauschte Einheiten (W statt kW) sind die üblichen Verdächtigen.
Der letzte Punkt klingt banal. In selbst gebauten Auswertungen ist die falsch hinterlegte Nennleistung aber einer der häufigsten Gründe für eine unplausible PR – etwa wenn nach einer Erweiterung der Anlage die neuen Module nie im Stammdatensatz angekommen sind. Diese Plausibilitätsprüfung lässt sich mit einer einzigen Bedingung im Code automatisieren und spart die Diskussion, ob die Anlage plötzlich besser arbeitet als physikalisch möglich.