PV-
Dashboard

Ein Bild statt drei Portale

Die Betriebsdaten der Photovoltaik-Anlage lagen verteilt vor: zwei Wechselrichter mit jeweils eigener Weboberfläche, die Zählerwerte in der Homematic-Gebäudesteuerung, die Wetterlage nirgends. Wer wissen wollte, wie viel Strom erzeugt, selbst verbraucht und eingespeist wurde, musste drei Quellen einzeln aufrufen und die Werte gedanklich zusammenrechnen.

Das Dashboard löst das, indem es alle Quellen serverseitig einsammelt, auf ein gemeinsames Datenmodell normalisiert und als REST-API bereitstellt. Darauf setzt ein React-Frontend auf, das im Firmennetz über den Browser erreichbar ist: ohne Installation, ohne Herstellerkonto, ohne Datenabfluss nach außen.

Das Backend spricht mit den Geräten, das Frontend nur mit der API

Das Projekt habe ich vollständig eigenverantwortlich von Grund auf umgesetzt: Anforderungsaufnahme, Analyse der Geräteschnittstellen, Entwurf des Datenmodells, Backend, Frontend und Betrieb. Kollegen habe ich punktuell zu einzelnen Detailfragen konsultiert. Die technischen Entscheidungen, die Architektur und die Umsetzung lagen durchgehend bei mir.

Das schloss auch die unspektakulären Teile ein: herausfinden, welche Endpunkte die Geräte überhaupt anbieten, in welchem Format und in welchem Takt sie antworten, und was passiert, wenn eines davon nicht antwortet.

Neuer Stack. Mein Hintergrund ist Systemadministration, nicht Anwendungsentwicklung. Node, React und die zugehörige Toolchain habe ich mir im Verlauf des Projekts erarbeitet. Der Anspruch war von Anfang an ein System, das im Regelbetrieb läuft, nicht ein Prototyp.

Wie ich es gebaut habe

Drei Zeitraster auf einer Achse

Drei Schnittstellen, drei Datenwelten. CSV über HTTP, XML aus der Gebäudesteuerung, JSON aus einer öffentlichen Wetter-API: keine davon war für diesen Zweck gedacht, keine folgt einer gemeinsamen Konvention. Der eigentliche Aufwand lag nicht im Abrufen, sondern im Normalisieren auf ein Datenmodell, das im Frontend ohne Sonderfälle nutzbar ist.

Unterschiedliche Zeitraster. Momentanwerte im Sekunden- bis Minutentakt, Wechselrichter-Aggregate pro Tag, Monat und Jahr, Wetterprognose in Stundenauflösung. Diese Reihen auf einer gemeinsamen Zeitachse darzustellen, erfordert saubere Behandlung von Zeitzone und Sommer-/Winterzeitumstellung. Sonst entstehen Lücken oder doppelte Messpunkte an genau zwei Tagen im Jahr, die niemand beim Testen erwischt.

Geräte sind nicht immer erreichbar. Wechselrichter liefern nachts keine oder degenerierte Werte, die CCU ist bei Neustarts kurzzeitig weg. Das Dashboard musste so gebaut sein, dass ein Ausfall einer Quelle die übrigen Anzeigen nicht mitreißt: Fehlertoleranz je Quelle statt eines gemeinsamen Absturzes.

Abweichungen fallen auf, nicht erst mit der Abrechnung

Zählerlogik statt Zahlenanzeige. Aus HT-/NT-Zählerständen, Einspeisezähler und momentaner Netzleistung ergeben sich Eigenverbrauch und Autarkiegrad erst durch korrekte Vorzeichenbehandlung und die richtige Unterscheidung zwischen Zählerständen und Momentanleistung. Ein Vorzeichenfehler ist hier besonders tückisch, weil das Ergebnis weiterhin plausibel aussieht.

Geräte schonen. Jeder Browser-Request durfte nicht direkt zu einer Geräteabfrage führen. Das Backend sammelt in festem Takt und liefert aus dem Zwischenspeicher. Damit bleibt die Last auf Wechselrichtern und CCU unabhängig von der Zahl der geöffneten Dashboards konstant.

• Abweichungen fallen auf. Ertragseinbrüche, ausgefallene Strings oder ein stillstehender Wechselrichter werden sichtbar, statt erst mit der nächsten Abrechnung aufzufallen.
• Wetterprognose als Kontext. Ein schwacher Ertragstag lässt sich sofort gegen die Prognose plausibilisieren. Geringe Einstrahlung oder echter Defekt wird unterscheidbar.

Keine Cloud, keine Lizenzkosten, eine erweiterbare Basis

• Ein Bild statt drei Portale. Erzeugung, Netzbezug, Einspeisung und Eigenverbrauch stehen erstmals nebeneinander in einer Oberfläche. Die Frage „läuft die Anlage wie erwartet?" ist damit in Sekunden beantwortet statt in mehreren Klickwegen.
• Keine Cloud, keine Lizenzkosten. Sämtliche Daten bleiben im Firmennetz. Es gibt keine Abhängigkeit von einem Herstellerportal und keine laufenden Kosten.
• Erweiterbare Basis. Die REST-API ist bewusst als eigenständige Schnittstelle gebaut und kann weitere Auswertungen, Exporte oder Anbindungen bedienen, ohne dass das Frontend angefasst werden muss.