Mein Strom-Dashboard ist jetzt Open Source: Was es kann, was es nicht kann

Vor ein paar Monaten hab ich einen API-Key in meinem Stromanbieter-Portal gefunden und daraus ein Dashboard gebaut, das mir jeden Morgen meinen Stromverbrauch zeigt. Seitdem hab ich drei E-Mails von Lesern bekommen, die nach dem Code gefragt haben. Jetzt liegt er auf GitHub. Kostenlos, MIT-lizenziert, mit einer Einschränkung, die ich nicht klein schreiben will: Das Ding ist exakt auf die Salzburg-Netz-API zugeschnitten und für nichts anderes getestet. Was du in diesem Artikel bekommst: eine ehrliche Einordnung, was das Dashboard kann, wie die Installation läuft und warum ich überhaupt Code verschenke, den ich für mich selbst gebaut habe. Schauen wir uns das Repository im Detail an.

Ein selbstgebautes Tool für die eigene Infrastruktur zu veröffentlichen bedeutet nicht, dass es für jeden sofort funktioniert, sondern dass jemand anderes nicht bei null anfangen muss.

Kurz erklärt: die drei Begriffe, die du kennen musst

Smart-Meter-API: Eine Schnittstelle, über die Netzbetreiber wie Salzburg Netz deinen Stromverbrauch in 15-Minuten-Intervallen als Rohdaten bereitstellen. Zeitstempel, Bezug in kWh, bei PV-Anlage auch Einspeisung.

PWA (Progressive Web App): Eine Webseite mit Manifest-Datei und Service Worker, die sich wie eine native App installieren lässt. Kein App Store, kein Review-Prozess, läuft trotzdem auf dem Homescreen.

MIT-Lizenz: Eine sehr permissive Open-Source-Lizenz. Du darfst den Code nehmen, verändern, kommerziell nutzen, weitergeben. Einzige Bedingung: der Lizenzhinweis bleibt erhalten. Die vollständigen Lizenzbedingungen sind bei der Open Source Initiative nachzulesen.

Was ist das Strom-Dashboard eigentlich?

Ich hab die Entstehungsgeschichte schon einmal ausführlich erzählt, in meinem Artikel über den gefundenen API-Key. Kurzfassung für alle, die das verpasst haben: Salzburg Netz bietet Smartmeter-Kunden im Serviceportal einen API-Zugang an, mit dem du deine eigenen Verbrauchsdaten abrufen kannst. Die meisten Leute wissen das gar nicht, ich gehörte bis vor einem Jahr selbst dazu.

Aus dieser API hab ich mit Claude Code ein PHP-Projekt gebaut, das die Rohdaten in eine MySQL-Datenbank schreibt und als Dashboard visualisiert. Tagesverbrauch, Wochenvergleich, eine 365-Tage-Heatmap, monatliche Spitzenlast, ein Kostenrechner auf Basis des eigenen Tarifs und eine Energiefluss-Visualisierung, die zeigt, wie Strom vom Netz ins Haus fließt. Alles als installierbare PWA, dunkel und hell, mobile-first. Genau das Setup, das ich in meinem Beitrag über mein automatisiertes Zuhause beschrieben habe: Ich seh jeden Morgen auf einen Blick, was bei uns Strom zieht, ohne im Kundenportal nachschauen zu müssen.

Das Repository heißt Strom-Dashboard-Salzburg-AG und liegt unter meinem GitHub-Account. PHP macht 97,8 Prozent des Codes aus, der Rest ist JavaScript für den Service Worker. Kein Framework, kein Node.js, kein Build-Schritt. Genau das, was auf meinen Mittwald-Webspaces läuft, ohne Docker und ohne Komplikationen.

Warum nur für Salzburg AG getestet?

Das ist der Punkt, an dem ich ehrlich sein muss, auch wenn es die Reichweite des Projekts einschränkt. Die Datei fetch-api.php ist nicht generisch geschrieben. Sie kennt die exakten Endpunkte der Salzburg-Netz-API, die genauen Feldnamen in den JSON-Antworten und das spezifische Datumsformat, das dort verwendet wird. Wenn dein Netzbetreiber Tinetz, Wien Energie oder Energie Graz heißt, wird das Skript ohne Anpassungen wahrscheinlich nicht laufen. Die Datenstruktur unterscheidet sich von Anbieter zu Anbieter, manchmal nur in Kleinigkeiten, manchmal grundlegend.

Ich hätte das Projekt generisch konfigurierbar bauen können, mit einem Adapter-Pattern für verschiedene Netzbetreiber. Hab ich nicht gemacht, aus einem einfachen Grund: Ich hab nur Zugriff auf meine eigenen Vertragsdaten. Ohne echte Testdaten von einem anderen Netzbetreiber würde ich blind Code schreiben, der vielleicht funktioniert oder vielleicht nicht. Das wäre für mich kein seriöses Open-Source-Projekt, das wäre Show. Wer das Dashboard für einen anderen Anbieter anpassen will, findet in fetch-api.php zumindest eine vollständige Referenzimplementierung, an der man sich orientieren kann.

Was übrigens viele nicht wissen: Der Zugang zu diesen Schnittstellendaten ist keine Kulanz des Netzbetreibers, sondern gesetzlich geregelt. Netzbetreiber sind laut den rechtlichen Grundlagen der E-Control zum Smart Metering verpflichtet, Kundinnen und Kunden binnen fünf Werktagen kostenlosen und diskriminierungsfreien Zugriff auf die Schnittstellenspezifikationen ihres intelligenten Messgeräts zu gewähren. Du musst also niemanden um Erlaubnis bitten, du musst nur wissen, dass es diesen Zugang gibt.

Was steckt technisch unter der Haube?

Hier wird es konkret, für alle, die selbst PHP-Hosting betreiben. Das Repository besteht aus elf Dateien, die wichtigsten davon:

1. index.php ist die eigentliche Dashboard-Oberfläche, inklusive der PWA-Manifest-Einbindung und dem Kostenrechner-Objekt TARIF, das du auf deinen eigenen Vertrag anpasst.
2. data.php liefert die Daten als JSON-Endpoint ans Frontend, abgesichert über das DASHBOARD_SECRET.
3. fetch-api.php holt die Rohdaten von Salzburg Netz und schreibt sie in die Datenbank. Diese Datei läuft per Cron, idealerweise einmal täglich, weil Salzburg Netz die Lastprofildaten ohnehin nur einmal in 24 Stunden aktualisiert. Der Code drosselt zusätzlich selbst auf maximal eine erfolgreiche Profilabfrage pro Kalendertag, damit niemand aus Versehen die API mit Anfragen zumüllt.
4. login.php regelt den Passwortschutz mit Auto-Logout nach acht Stunden.
5. schema.sql legt vier Tabellen an: load_profiles, api_cache, meter_readings, peak_loads.

Die Installation läuft in sechs Schritten:

1. Repository klonen oder die Dateien in den Web-Root deiner (Sub-)Domain hochladen. Wichtig dabei: Die PWA ist auf den Domain-Root ausgelegt, manifest.json und sw.js funktionieren nicht zuverlässig aus einem Unterordner heraus.
2. config.example.php zu config.php kopieren und mit deinen Daten befüllen: API-Key, GP-Nummer und Zählpunkt aus dem Salzburg-Netz-Serviceportal, deine MySQL-Zugangsdaten, ein Dashboard-Passwort und ein langes Zufalls-Secret, das du dir am einfachsten mit openssl rand -hex 32 generierst.
3. Eine MySQL-Datenbank mit UTF8MB4-Encoding anlegen und das Schema aus schema.sql importieren.
4. Einmal manuell im Browser fetch-api.php?secret=DEIN_SECRET&action=all aufrufen, damit die Erstbefüllung passiert.
5. Einen täglichen Cron-Job oder einen n8n-Workflow einrichten, der dieselbe URL aufruft, idealerweise mit dem Secret im Header X-Cron-Secret statt sichtbar in der URL.
6. index.php öffnen, einloggen, fertig.

Auf dem iPhone installierst du die PWA über Safari, Teilen-Button, „Zum Home-Bildschirm“. Eine Eigenheit dabei: Änderungen an den Meta-Tags für Statusleiste und Safe-Area greifen erst nach einer kompletten Neuinstallation der PWA, nicht nach einem einfachen Browser-Reload. Das hat mich beim eigenen Testen auch einmal kurz verwirrt.

Wer eine PV-Anlage hat, kann in config.php zwei zusätzliche Werte setzen: HAS_FEED_IN aktiviert die Einspeisung als zweite Datenspur, PV_KWP hinterlegt die Anlagenleistung für die Energiefluss-Visualisierung. Das Haus-Symbol auf dem Dashboard zeigt dann nicht nur Bezug vom Netz, sondern auch, wie viel Strom aus der eigenen Erzeugung kommt. Ich selbst hab keine PV-Anlage, dieser Teil des Codes ist also ungetestet von mir persönlich, aber die Datenfelder liefert die Salzburg-Netz-API ohnehin mit, wenn ein Zählpunkt eine Einspeisung registriert. Wer das ausprobiert und Bugs findet: Issues auf GitHub sind willkommen, auch wenn ich wie gesagt keinen Support-Vertrag anbiete.

Die Beschriftungen am Energiefluss-Haus und der Standortname, bei mir steht dort schlicht „Residenz Alex“, lassen sich direkt in index.php anpassen. Genauso das TARIF-Objekt für den Kostenrechner: Arbeitspreis, Grundpreis, Netzkosten, alles, was in deinem persönlichen Stromvertrag steht, trägst du dort händisch ein. Eine automatische Tarifabfrage gibt es bewusst nicht, weil sich Tarife ändern und ich keine zusätzliche externe Abhängigkeit einbauen wollte, nur um ein paar Cent pro Kilowattstunde aktuell zu halten.

Was du nicht erwarten solltest

Ich will hier nicht übertreiben. Das ist kein Produkt, das ist ein persönliches Werkzeug, das ich aus der Schublade geholt habe. Es gibt keinen Support, keine Roadmap, keine Garantie, dass ich auf Issues reagiere. config.php ist per .gitignore ausgeschlossen und darf niemals committed werden, weil dort dein API-Key, dein Datenbankpasswort und dein Dashboard-Secret liegen. Wer das Ding produktiv betreibt, sollte ausschließlich über HTTPS arbeiten und DEBUG_MODE auf false setzen. Das DASHBOARD_SECRET schützt zwei sehr direkte Endpunkte, data.php und fetch-api.php. Ist es zu kurz oder zu erraten, hat im schlimmsten Fall jemand Zugriff auf deine Verbrauchsdaten oder kann unnötige API-Calls gegen Salzburg Netz auslösen.

Und das Projekt ist kein Beispiel für sauberste Softwarearchitektur. Ich bin kein ausgebildeter Entwickler, ich hab das mit Claude Code im Gespräch gebaut, Schritt für Schritt, immer wieder mit Nachjustierungen, weil Proportionen nicht gepasst haben oder ein Wert falsch berechnet wurde. Das ist Vibe Coding in seiner ehrlichsten Form: Ich beschreibe, was ich will, die KI übernimmt die Implementierung, ich kontrolliere das Ergebnis. Wer cleanen, getesteten Enterprise-Code erwartet, wird enttäuscht sein. Wer ein funktionierendes Werkzeug für die eigene Stromtransparenz sucht, bekommt eines.

Ein Sicherheitshinweis, den ich nicht in einem Nebensatz abhandeln will: Wer das Dashboard auf einer öffentlich erreichbaren Domain betreibt, sollte zusätzlich zum DASHBOARD_SECRET auf Webserver-Ebene über Fail2Ban oder ein vergleichbares Tool gegen Brute-Force-Versuche auf login.php absichern. Das Skript selbst bringt kein Rate-Limiting für Login-Versuche mit, das ist eine bewusste Lücke, die ich hier offenlege statt sie zu verschweigen. Für ein privates Dashboard auf einer wenig bekannten Subdomain ist das Risiko überschaubar, für alles andere würde ich nachrüsten.

Warum verschenke ich das einfach so?

Das ist die Frage, die mir gerne gestellt wird, wenn ich über solche Projekte schreibe. Die ehrliche Antwort: weil der Aufwand für mich schon erledigt ist und für dich damit wegfällt. Ich hab vor einigen Wochen über ein GitHub-Projekt geschrieben, das mit Claude Code als Co-Entwickler entstanden ist und mich damals gefragt, was es bedeutet, wenn ein Einzelner mit KI-Unterstützung etwas baut, das früher ein Team gebraucht hätte. Bei meinem Strom-Dashboard ist die Ausgangslage harmloser, aber das Prinzip ist dasselbe. Die Hürde, ein eigenes Verbrauchsdashboard zu bauen, war für mich vor einem Jahr noch eine Wand. PHP, MySQL-Schema, sichere Secret-Verwaltung, PWA-Manifest, das alles selbst zu lernen, hätte ich nie gemacht. Mit Claude Code als Co-Entwickler war es ein Wochenende.

Wenn ich diesen Aufwand schon hinter mir hab, find ich es sinnlos, ihn für mich zu behalten. Open Source ist für mich kein Idealismus-Statement, sondern eine pragmatische Entscheidung: Es kostet mich nichts mehr, es zu teilen, es spart jemand anderem Zeit. Genau das ist auch der Kern dessen, was ich meinen EPU- und KMU-Kunden in der Beratung erkläre, wenn es um den Einsatz generativer KI geht. Der Wert entsteht nicht dadurch, dass das Werkzeug perfekt ist, sondern dadurch, dass es ein konkretes Problem löst und diese Lösung wiederverwendbar bleibt.

Für wen lohnt sich das überhaupt?

Realistisch gesehen für eine eingeschränkte Zielgruppe: Salzburg-AG-Kunden mit eigenem Webhosting, die PHP und MySQL grundsätzlich kennen oder bereit sind, sich da reinzufuchsen. Ich bin mir da nicht ganz sicher, aber mein Eindruck ist, dass die meisten, die das Repository klonen werden, eh schon eine eigene n8n- oder Home-Assistant-Installation laufen haben und das Dashboard dort andocken wollen. Für alle anderen ist der eigentliche Wert vielleicht weniger der Code selbst, sondern die Referenzarchitektur: Wie man eine Energieversorger-API sauber abfragt, Duplicate-Handling beim Datenimport macht, ein Secret-basiertes Auth-System für einen einzelnen Nutzer baut, und das alles ohne Overkill auf simplem PHP-Hosting.

Das macht Sinn, wenn man bedenkt, woher die meisten Anfragen kamen, die ich nach dem ursprünglichen Artikel bekommen hab: nicht „kannst du mir das für meinen Anbieter bauen“, sondern „zeig mir, wie du das gemacht hast“. Genau dafür ist das Repository jetzt da.

Du findest das komplette Repository unter github.com/7H3-CH053N/Strom-Dashboard-Salzburg-AG, MIT-lizenziert, mit README und Beispielkonfiguration. Wenn du Salzburg-AG-Kunde bist und ein eigenes PHP-Hosting hast: probier es aus. Wenn du einen anderen Netzbetreiber hast: nimm den Code als Bauplan und pass ihn an deine eigene API an. Und falls du selbst irgendwo einen vergessenen API-Key in einem Kundenportal findest, schreib mir, ich bin gespannt, was du draus machst.