Amortisation von PV, Wärmepumpe & Akku live in Home Assistant tracken

Eine PV-Anlage, eine Wärmepumpe und ein Batteriespeicher sind erstmal vor allem eins: eine große Investition. Mit Home Assistant tracke ich die Amortisation aller drei Systeme live statt einmal im Jahr mit Excel zu rechnen. Bei mir kommen PV, Wärmepumpe und Akku zusammen auf 13.729 €. Mich interessiert dabei nicht „spart das irgendwann Geld?“. Mich interessiert: Wie viel genau, und wann habe ich die Investition wieder raus?

Eine einzige Milchmädchenrechnung beantwortet das nicht. Drei Systeme beeinflussen sich gegenseitig. Sie sind zu unterschiedlichen Zeitpunkten gestartet. Mein Stromtarif kann sich ändern. Und für manche Monate fehlen mir rückwirkend saubere Messdaten. All das macht die Amortisation zu einem Bewegungsziel statt zu einer festen Zahl. Deshalb tracke ich sie live in Home Assistant, statt einmal im Jahr mit Excel und alten Stromrechnungen zu hantieren. So wird die Zahl jeden Tag ein bisschen genauer.

In diesem Artikel zeige ich das Übersichts-Dashboard, das den Gesamtfortschritt aller drei Systeme zusammenfasst. Ich erkläre die Grundlogik dahinter – inklusive der Fehler, die ich selbst gemacht habe. Für die einzelnen Komponenten folgen dann eigene, tiefere Artikel:

• PV-Anlage im Detail (Formel, Eigenverbrauch, Einspeisung, rückwirkende Schätzung)
• Wärmepumpe im Detail (Vergleich zu Fernwärme, PV-Zuordnung)
• Akku im Detail (Lade-/Entladelogik, Ersparnis aus Eigenverbrauchssteigerung)

Ausgangslage: drei Systeme, ein Budget

Bevor es an die Technik geht, kurz die Zahlen, um die es geht:

System	Investition	Inbetriebnahme
PV-Anlage	2.232,85 €	Frühjahr
Wärmepumpe	10.307,15 €	Winter davor
Akku/Batteriespeicher	1.189,00 €	Sommer
Gesamt	13.729,00 €	–

An dieser Stelle ein wichtiger Hinweis, bevor jemand die Summe als Maßstab nimmt: 13.729 € ist für PV-Anlage, Wärmepumpe und Akku zusammen ein sehr niedriger Betrag. Der kommt nur zustande, weil ich als Handwerker den Großteil der Arbeiten selbst gemacht habe – von der Installation bis zur Verkabelung. Wer die Montage komplett an Fachbetriebe vergibt, muss realistisch mit deutlich höheren Kosten rechnen. Die Zahlen in diesem Artikel sind also meine ganz persönliche Ausgangslage, keine allgemeine Preisorientierung.

Auffällig: Die drei Systeme sind zu sehr unterschiedlichen Zeitpunkten gestartet. Die Wärmepumpe lief schon einige Monate, bevor die PV-Anlage überhaupt ans Netz ging. In dieser Zeit musste sie komplett mit Netzstrom rechnen. Erst mit der Inbetriebnahme der PV-Anlage kam PV-Deckung dazu, zunächst mit Nulleinspeisung. Einige Monate später lief sie dann mit Überschusseinspeisung. Diese zeitliche Verschiebung ist einer der Gründe, warum eine pauschale „Amortisation in X Jahren“-Rechnung von Anfang an nicht funktioniert hätte. Ein datengetriebenes, kontinuierlich mitlaufendes Dashboard lohnt sich deshalb.

Warum ein eigenes Amortisations-Dashboard?

Die drei Systeme hängen finanziell eng zusammen. PV-Überschuss lädt den Akku. Die Wärmepumpe läuft teilweise mit PV-Strom statt Netzstrom. Einspeisevergütung, Eigenverbrauch und Netzbezug wirken sich gegenseitig auf die Rechnung aus. Ein Dashboard, das das alles korrekt trennt statt es zu vermischen, ist überraschend knifflig – dazu weiter unten mehr im Detail.

Der Lohn ist ein einziger Blick, der zeigt: Wo stehe ich insgesamt, und wo im Detail? Ganz praktisch: Ein Live-Dashboard motiviert mehr als eine Excel-Tabelle, die ich einmal im Quartal öffne. Wenn ich sehe, dass „heute schon 11,29 € gespart“ wurden, fühlt sich das anders an als eine trockene Zahl am Jahresende.

Aufbau des Gesamt-Dashboards

Das Übersichts-Dashboard ist bewusst kompakt gehalten. Es gliedert sich in vier Bereiche: Gesamt-Amortisation, PV-Anlage, Wärmepumpe und Akku – jeweils mit denselben Kennzahlen, damit sie direkt vergleichbar bleiben. Diese Wiederholung ist Absicht. Wer einmal versteht, was „Break-even“ oder „Restbetrag“ bei der PV-Anlage bedeutet, muss bei der Wärmepumpe nicht neu nachdenken, sondern erkennt sofort dieselbe Struktur wieder.

Gesamt-Amortisation (oben, über alle drei Systeme hinweg):

• Gesamtfortschritt als Balken in Prozent
• Bisher gespart (€)
• Restbetrag bis zur vollen Amortisation (€)
• Break-even-Datum (Hochrechnung, wann die Investition erwirtschaftet ist)
• Investition inkl. Zinsen
• Heute gespart (€)

Darunter folgen die drei Einzelbereiche PV-Anlage, Wärmepumpe und Akku mit exakt denselben Kacheln, nur eben pro Teilsystem. Jeder Bereich zeigt also:

1. Einen Fortschrittsbalken (z. B. „PV-Fortschritt 30,83 %“)
2. Bisher gespart – kumulierte Ersparnis seit Inbetriebnahme
3. Restbetrag – Investition minus bisher gespart
4. Break-even – Datum, an dem laut Hochrechnung die Investition voll erwirtschaftet ist
5. Investition (inkl. Zinsen bei der Gesamtübersicht, bzw. bar bezahlt beim Akku)
6. Heute gespart – Tageswert, der über den Tag hinweg wächst

Technischer Aufbau: Cards und Entitäten

Für die einzelnen Kennzahlen nutze ich Mushroom-Cards (custom:mushroom-template-card). Sie lassen sich flexibel mit Templates befüllen und bleiben optisch kompakt. Für die Fortschrittsbalken kommt eine Bar-Card zum Einsatz, die den Prozentwert farbig darstellt. Ein vereinfachtes Beispiel für eine solche Kachel:

type: custom:mushroom-template-card
primary: "Bisher gespart"
secondary: "{{ states('sensor.pv_ersparnis_gesamt') }} €"
icon: mdi:cash
tap_action:
  action: more-infoCode-Sprache: JavaScript (javascript)

Der tap_action: more-info ist ein kleines, aber nützliches Detail. Tippe ich auf die „Bisher gespart“-Kachel, öffnet sich die Standard-Detailansicht von Home Assistant mit dem Verlaufsdiagramm der zugrunde liegenden Entität. So sehe ich die Entwicklung über Zeit, ohne eine eigene History-Card einzubauen.

Wichtig ist dabei eine Entscheidung: Welche Werte bekommen eine eigene Entität, welche bleiben nur Templates in der Card? Meine „Bisher gespart“-Kachel läuft bislang nur über ein Inline-Template. Es summiert drei andere Sensoren (sensor.pv_ersparnis_gesamt, sensor.wp_ersparnis_mit_pv, sensor.akku_ersparnis_gesamt) statt über eine eigene Helper-Entität. Für die Anzeige reicht das. Für sauberes Historie-Tracking über die Zeit ist aber eine echte Entität die robustere Lösung – zum Beispiel ein Template-Sensor oder ein utility_meter. Inline-Templates speichern sich nämlich nicht „von selbst“ in der History.

Meine Home-Assistant-Instanz läuft auf einem Raspberry Pi 4. Da bei diesem Dashboard langfristige Verlaufs- und Statistikdaten eine wichtige Rolle spielen, nutze ich dafür zusätzlich eine externe SSD statt einer dauerhaft beschriebenen microSD-Karte.

Meine Home-Assistant-Hardware: Raspberry Pi 4* · externe SSD*

* Affiliate-Link: Wenn du über einen entsprechend gekennzeichneten Link etwas kaufst, erhalte ich möglicherweise eine Provision. Für dich ändert sich der Preis dadurch nicht. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.

Das Break-even-Datum: mehr als nur eine Hochrechnung

Die Break-even-Kachel ist für mich die spannendste im ganzen Dashboard, weil sie nicht nur eine Zahl zeigt, sondern eine Prognose. Grob gerechnet nehme ich dafür die aktuelle Ersparnisrate – zum Beispiel die durchschnittliche Ersparnis pro Tag der letzten Wochen – und rechne sie auf den Restbetrag hoch. Das bedeutet auch: Das Datum „wandert“. Ein sonniger Sommer mit hoher PV-Ersparnis zieht das Break-even-Datum nach vorne. Ein grauer Winter mit viel Netzbezug schiebt es nach hinten. Genau dieses „Atmen“ der Prognose macht das Dashboard für mich lebendiger als eine starre Excel-Zelle.

Die Grundformel: Ersparnis = vermiedene Netzstromkosten

So unterschiedlich PV, WP und Akku auch sind – die Grundidee der Berechnung bleibt bei allen dreien gleich: Ersparnis ist das, was ich nicht für teuren Netzstrom bezahlen muss, plus eventuelle Einspeisevergütung. Ich rechne dabei bewusst nicht mit einem dynamischen Stromtarif, sondern mit einem festen Netzstrompreis von 25 ct/kWh. Ich habe keinen Tibber-Vertrag mit variablen Preisen mehr, sondern einen Fixtarif bei einem anderen Anbieter. Den Tibber Pulse nutze ich zwar noch – aber nur als reines Messgerät zum Auslesen der Verbrauchsdaten, nicht zur Tarifsteuerung. Das vereinfacht die Formeln erheblich, weil ich nicht mit stündlich schwankenden Preisen rechnen muss.

Die PV-Formel im Detail

Bei der PV-Anlage sieht die Kernformel so aus:

Ersparnis = Eigenverbrauch × 0,25 €/kWh + Einspeisung × 0,08 €/kWh − Akku-Ladung × 0,17 €/kWh

Drei Preise, drei unterschiedliche Bedeutungen:

• 0,25 €/kWh ist der Netzstrompreis. Jede Kilowattstunde, die ich dank PV nicht aus dem Netz beziehe, spart diesen Betrag.
• 0,08 €/kWh ist die Einspeisevergütung. Strom, den ich einspeise statt selbst zu verbrauchen, bringt deutlich weniger, aber immer noch ein Plus.
• 0,17 €/kWh ist der Wert, mit dem ich Strom in den Akku „hineinrechne“ – nicht der volle Netzstrompreis, sondern ein Zwischenwert. Er berücksichtigt, dass diese Energie erst beim späteren Entladen zu einer echten Ersparnis wird.

Der letzte Term ist der wichtigste: Strom, der in den Akku fließt, ist noch keine „realisierte“ Ersparnis. Die kommt erst, wenn der Akku ihn wieder abgibt. Deshalb rechne ich ihn in der PV-Formel heraus (subtrahiere ihn) und verbuche ihn stattdessen beim Akku als eigene Ersparnis:

Akku-Ersparnis = Entladung × 0,17 €/kWh

Warum die beiden Formeln symmetrisch sind

Ich baue diese beiden Formeln bewusst symmetrisch auf: Was die PV-Formel als Akku-Ladung abzieht, taucht in der Akku-Formel als Entladung wieder auf. Nur durch diese Symmetrie summieren sich die Einzel-Ersparnisse am Ende sauber zur Gesamt-Ersparnis. So zähle ich Energie weder doppelt noch verliere ich sie irgendwo dazwischen. Übersehe ich diesen Zusammenhang beim Bauen der Sensoren, bekomme ich fast immer eine von zwei Fehlerarten: doppelte Zählung oder verschwundene Energie.

Die Wärmepumpen-Formel funktioniert nach demselben Grundprinzip, hat aber eine Besonderheit: Statt nur gegen den Netzstrompreis zu vergleichen, vergleiche ich gegen das, was ich vorher für Fernwärme bezahlt habe – dazu mehr im WP-Detailartikel.

Stolpersteine, die ich selbst gebaut habe

Ein Dashboard wie dieses läuft selten beim ersten Versuch fehlerfrei. Die eigentliche Arbeit steckt gar nicht im Dashboard-Layout, sondern in der Sensor- und Template-Logik dahinter. Vier Dinge kosteten mich einiges an Fehlersuche:

1. Doppelte Abrechnung zwischen PV- und WP-Ersparnis

Bei einer KI-gestützten Analyse der Entitäten stieß ich auf einen doppelten Abrechnungsfehler. Die Akku-Ladung tauchte an zwei Stellen als Gegenrechnung auf: einmal implizit in der PV-Ersparnis, einmal in einer WP-Berechnung, die ebenfalls auf denselben PV-Strom Bezug nahm. Dadurch zählte ich einen Teil der Ersparnis faktisch doppelt, und die Gesamtzahl war zu optimistisch. Die Lösung: Ich verankere die Akku-Ladung-Gegenrechnung jetzt konsequent nur an einer einzigen Stelle im PV-Ersparnis-Sensor (siehe Formel oben) und nehme sie aus allen anderen Berechnungen komplett heraus.

Lehre daraus: Greifen mehrere Sensoren auf dieselbe zugrunde liegende Energiemenge zu – hier: PV-Strom, der potenziell sowohl der WP als auch dem Akku zugerechnet werden könnte – brauche ich eine klare, einmalige Zuordnungsregel. Sonst entstehen schleichend Doppelzählungen, die erst bei einer Plausibilitätsprüfung der Gesamtsumme auffallen.

2. Der Mitternachts-Sprung

Wenig später fiel mir auf: Der Sensor „WP Ersparnis heute NEU“ sprang nachts um 1 Uhr abrupt von 0 € auf 58,06 €, statt kontinuierlich über den Tag zu wachsen. Kein neues Problem – ein ähnlicher Sprung war schon einmal an anderer Stelle im Dashboard aufgetaucht und behoben, kehrte hier aber in neuer Variante zurück.

Die Ursache: Ein Template bezog sich auf einen Referenzwert vom Vortag („Fernwärme seit WP-Start“). Es aktualisierte diesen Wert zur falschen Zeit mit einer zu komplexen Formel, wodurch kurzzeitig ein falscher Zwischenstand entstand. Meine Lösung bestand aus drei Teilen:

• ein neuer Basis-Vormonate-Helper, der den Stand zu Beginn des laufenden Zeitraums fixiert,
• eine tägliche Automation, die diesen Referenzwert sauber zum Tageswechsel setzt, statt ihn implizit im Template mitlaufen zu lassen,
• ein vereinfachtes Template für „Fernwärme seit WP-Start“ ohne die fehleranfällige Vortagesreferenz.

Lehre daraus: Werte mit festem Zeitbezug („Stand zu Tagesbeginn“, „Stand zu Monatsbeginn“) gehören in einen eigenen Helper, den ich explizit per Automation setze – nicht in ein Live-Template, das bei jeder Neuberechnung erneut raten muss, welcher Referenzwert gerade richtig ist.

3. Feste statt dynamische Monatswerte

Beim Prüfen des „PV-Ersparnis 2026“-Balkendiagramms fiel auf: Die Monate September bis Dezember rechneten sich gar nicht dynamisch, sondern beruhten auf festen, geschätzten Startwerten (650 €, 780 €, ein fehlender Wert, 960 €). Diese Platzhalter trug ich beim ursprünglichen Aufbau ein – und vergaß sie schlicht, durch echte Berechnungen zu ersetzen.

Der Fix brachte eine sauberere Architektur:

• Ein Helper input_number.pv_ersparnis_basis_vormonat hält den Wert zu Beginn des jeweils laufenden Monats fest.
• Je ein „Frozen-Value“-Helper pro abgeschlossenem Monat (z. B. input_number.pv_ersparnis_august_final) friert den finalen Monatswert dauerhaft ein.
• Ein „guarded“ Template-Muster berechnet nur den aktuell laufenden Monat live. Vergangene Monate zeigen ihren eingefrorenen Wert, zukünftige Monate zeigen 0 €.
• Eine neue Automation „PV Ersparnis Monatswechsel“ prüft täglich um 00:15 Uhr, ob heute der 1. eines Monats ist. Wenn ja, schreibt sie den Wert des abgelaufenen Monats in dessen Frozen-Helfer und setzt die Basis für den neuen Monat zurück.

Ein anschließender Funktionstest bestätigte es: Der laufende Monat blieb weiterhin korrekt live berechnet, während der neue Monat korrekt bei 0 € startete statt bei der alten Fehlschätzung.

Lehre daraus: „Platzhalter, die ich später durch echte Werte ersetze“ sind in der Praxis eine der zuverlässigsten Fehlerquellen in einem wachsenden Dashboard, weil das „später“ leicht vergessen geht. Ein guarded Template-Muster mit klarer Monatswechsel-Logik verhindert das strukturell, statt sich auf die eigene Erinnerung zu verlassen.

4. Rückwirkende Schätzungen sind unvermeidlich

Nicht jeder Fehler war ein Bug – manche Werte sind schlicht Schätzungen, weil mir Messdaten fehlen. Für die Monate vor der Inbetriebnahme des passenden Sensors kann ich die PV-Zuordnung zur Wärmepumpe zum Beispiel nachträglich nicht exakt bestimmen. Der zuständige Sensor (sensor.wp_pv_energie_gesamt_seit_pv_start) liefert erst seit Kurzem Daten. Ursprünglich nahm ich für Juni/Juli an, die WP sei zu 100 % PV-gedeckt gewesen (0 € Netzstromkosten) – eine zu optimistische Annahme, wie sich zeigte. Meine überarbeitete Schätzung basiert stattdessen auf einem Gewichtungsmodell aus PV-Erzeugung und WP-Verbrauch gemeinsam (Ergebnis für März bis Juli: 445 €, 323 €, 230 €, 140 €, 91 €).

Lehre daraus: Fehlen echte Messdaten, hilft nur eine nachvollziehbare, dokumentierte Schätzmethode – und die Bereitschaft, sie später zu korrigieren, sobald ich es besser weiß. Solche geschätzten Zeiträume markiere ich mir bewusst als „dauerhaft geschätzt“, damit ich beim nächsten Blick aufs Dashboard nicht denke, dort stünden belastbare Live-Daten.

Was in den Detailartikeln folgt

Das Gesamt-Dashboard zeigt nur die Zusammenfassung. Spannender wird es in den einzelnen Teilsystemen, weil sich die Berechnungen dort deutlich genug unterscheiden, um einen eigenen Artikel zu verdienen:

PV-Anlage im Detail

• Wie ich Eigenverbrauch, Einspeisung und Akku-Ladung sauber in eigenen Entitäten trenne
• Warum ich für Monate ohne Messdaten eine saisonale Schätzung nutze, statt eine flache Verteilung über 12 gleiche Monate
• Wie das guarded Template-Muster mit Basis-Vormonate-Helper und Monatswechsel-Automation konkret aufgebaut ist

Wärmepumpe im Detail

• Warum ich nicht gegen „kein Netzstrom“ vergleiche, sondern gegen die vorher tatsächlich gezahlten Fernwärmekosten (320 €/Monat pauschal)
• Wie aus einer Jahressumme ein realistischer saisonaler Monatsverlauf wird, wenn echte historische Monatsdaten fehlen
• Wie die PV-Zuordnung zur WP ab August live über einen eigenen Sensor läuft, während Januar bis Juli dauerhaft geschätzt bleiben

Akku im Detail

• Wie die Lade-/Entlade-Logik mit der PV-Formel zusammenspielt, ohne Energie doppelt oder gar nicht zu zählen
• Warum der Akku trotz vergleichsweise geringer Investition (1.189 €) eine eigene, genaue Betrachtung braucht

Fazit

Das Amortisations-Dashboard ist für mich mehr als eine nette Spielerei. Es ist der ehrlichste Realitäts-Check, den ich für meine Investition in PV, Wärmepumpe und Akku habe – kein Verkaufsprospekt mit Wunschzahlen, sondern echte, tagesaktuelle Daten aus dem eigenen Zuhause. Der Weg dahin war holpriger, als ich anfangs dachte. Genau diese Stolpersteine sind es aber wert, dokumentiert zu werden, falls sie euch beim eigenen Nachbau ebenfalls begegnen.

* Mit * gekennzeichnete Links sind Affiliate-Links. Wenn du darüber etwas kaufst, erhalte ich möglicherweise eine Provision. Für dich entstehen dadurch keine zusätzlichen Kosten. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.