Im Übersichtsartikel zum Amortisations-Dashboard und im PV-Detailartikel ging es um Formeln, die letztlich alle auf denselben Netzstrompreis zurückgreifen. Bei der Wärmepumpe ist das anders: Die Wärmepumpe-Amortisation in Home Assistant vergleicht nicht gegen „was hätte ich für Netzstrom bezahlt“, sondern gegen „was habe ich vorher für Fernwärme bezahlt“. Dieser Unterschied zieht sich durch die ganze Berechnung – und bringt eine eigene Reihe von Herausforderungen mit sich.
Warum Fernwärme der richtige Vergleichsmaßstab ist
Vor der Wärmepumpe heizte ich mit Fernwärme. Ich zahlte dafür pauschal 320 € im Monat, unabhängig von der Jahreszeit – ein Fixbetrag ohne saisonale Staffelung, wie es bei manchen Fernwärme-Anbietern üblich ist. Für die Amortisationsrechnung ist das mein „Was wäre wenn“-Szenario: Hätte ich die Wärmepumpe nicht gebaut, würde ich weiterhin diesen Betrag zahlen.
Die Kernformel für die WP-Ersparnis lautet deshalb:
Ersparnis = Fernwärme-Vergleichskosten − tatsächliche WP-Stromkosten
Die „tatsächlichen WP-Stromkosten“ bestehen wiederum aus zwei Teilen: dem Netzstrom-Anteil (zum Netzstrompreis von 25 ct/kWh) und dem PV-gedeckten Anteil, der nichts kostet. Genau dieser zweite Teil – wie viel PV-Strom tatsächlich in die Wärmepumpe fließt – ist der komplizierteste Baustein der ganzen Rechnung, dazu weiter unten mehr.
Woher die echten WP-Stromkosten kommen
Für den reinen Stromverbrauch der Wärmepumpe verlasse ich mich nicht auf Schätzungen, sondern auf einen dedizierten Energiezähler direkt am WP-Stromkreis (ein Shelly Pro 3EM). Dieser Sensor misst unabhängig davon, ob der Strom aus dem Netz oder von der PV-Anlage kommt – er zeigt einfach den Gesamtverbrauch der Wärmepumpe. Die Aufteilung in „davon PV“ und „davon Netz“ passiert erst im nächsten Schritt, über die PV-Zuordnung.
Diese Trennung – ein Sensor für den Gesamtverbrauch, ein separater Mechanismus für die PV-Zuordnung – hat sich als robuster erwiesen, als zu versuchen, PV-Anteil und Netzanteil direkt in einer einzigen Formel zu berechnen. Fällt einer der beiden Bausteine aus oder liefert kurzzeitig unplausible Werte, merke ich das sofort, weil ich beide Werte getrennt plausibilisieren kann.
Technischer Aufbau der Wärmepumpe-Amortisation in Home Assistant
Wie schon beim PV-Teil baue ich auch die WP-Ersparnis nicht direkt in der Dashboard-Card zusammen, sondern über einen eigenen Template-Sensor, der die Formel einmal zentral berechnet. So kann ich denselben Wert sowohl in der Kachel als auch an anderer Stelle (z. B. in der Gesamt-Amortisation) wiederverwenden, ohne die Formel mehrfach zu pflegen:
template:
- sensor:
- name: "WP Ersparnis mit PV"
unique_id: wp_ersparnis_mit_pv
unit_of_measurement: "€"
state: >
{% set vergleich = states('sensor.fernwaerme_vergleichskosten_monat') | float(0) %}
{% set verbrauch_kwh = states('sensor.wp_stromverbrauch_gesamt') | float(0) %}
{% set pv_anteil_kwh = states('sensor.wp_pv_energie_gesamt_seit_pv_start') | float(0) %}
{% set netz_kwh = verbrauch_kwh - pv_anteil_kwh %}
{% set netzkosten = netz_kwh * 0.25 %}
{{ (vergleich - netzkosten) | round(2) }}Code-Sprache: JavaScript (javascript)Auf dem Dashboard zeigt dann eine Mushroom-Card genau diesen einen Sensor an – dieselbe Card-Struktur wie im Übersichtsartikel, nur mit der WP-Entität statt der PV-Entität:
type: custom:mushroom-template-card
primary: "WP Ersparnis (mit PV)"
secondary: "{{ states('sensor.wp_ersparnis_mit_pv') }} €"
icon: mdi:heat-pump
tap_action:
action: more-infoCode-Sprache: JavaScript (javascript)Für den Monatswechsel nutze ich dasselbe guarded Template-Muster wie beim PV-Sensor: ein Helper input_number.wp_ersparnis_basis_vormonat für den laufenden Monat, ein „Frozen-Value“-Helper pro abgeschlossenem Monat (z. B. input_number.wp_ersparnis_august_final), und eine tägliche Automation, die am Monatsersten den alten Monat einfriert und die Basis für den neuen Monat zurücksetzt:
alias: WP Ersparnis Monatswechsel
trigger:
- platform: time
at: "00:15:00"
condition:
- condition: template
value_template: "{{ now().day == 1 }}"
action:
- service: input_number.set_value
target:
entity_id: input_number.wp_ersparnis_august_final
data:
value: "{{ states('sensor.wp_ersparnis_august') | float }}"
- service: input_number.set_value
target:
entity_id: input_number.wp_ersparnis_basis_vormonat
data:
value: "{{ states('sensor.wp_ersparnis_mit_pv') | float }}"
mode: singleCode-Sprache: JavaScript (javascript)Das entspricht strukturell exakt der Automation aus dem PV-Artikel – nur mit den WP-Entitäten statt der PV-Entitäten. Genau diese Wiederverwendbarkeit des Musters war der eigentliche Gewinn aus dem Bugfix im PV-Teil: Einmal sauber gebaut, ließ sich dieselbe Logik hier direkt übernehmen, statt sie erneut von Grund auf zu entwickeln.
Meine Home-Assistant-Instanz läuft auf einem Raspberry Pi 4. Da bei solchen Amortisationsberechnungen langfristige Verlaufs- und Monatsdaten wichtig sind, nutze ich 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.
Saisonale statt flache Verteilung der Fernwärme-Vergleichskosten
Die Jahressumme für die Fernwärme-Vergleichskosten ist einfach: 320 € × 12 Monate = 3.840 €. Die Frage ist nur, wie sich dieser Betrag auf die einzelnen Monate verteilt. Eine flache Verteilung – jeden Monat exakt 320 € – wäre die einfachste Lösung gewesen, hätte aber die Realität verzerrt: Im Winter heize ich deutlich mehr als im Sommer, und ein realistischer monatsgenauer Vergleich sollte das widerspiegeln, auch wenn die historische Fernwärme-Abrechnung nur eine Jahrespauschale kannte, keine Monatswerte.
Ich habe mich deshalb für eine saisonale Gewichtung entschieden, die den typischen Heizverlauf eines Jahres nachbildet: hohe Werte in den kalten Monaten, niedrige Werte im Sommer, wenn nur Warmwasser anfällt. Die Verteilung sieht so aus (Januar bis Dezember):
| Monat | Vergleichskosten |
|---|---|
| Januar | 600 € |
| Februar | 550 € |
| März | 500 € |
| April | 350 € |
| Mai | 250 € |
| Juni | 150 € |
| Juli | 100 € |
| August | 100 € |
| September | 150 € |
| Oktober | 300 € |
| November | 350 € |
| Dezember | 440 € |
Diese Zahlen sind eine plausible Schätzung, kein gemessener Wert – echte monatliche Fernwärme-Abrechnungen aus der Zeit vor der Wärmepumpe gibt es bei mir schlicht nicht. Wichtig ist mir dabei vor allem die Konsistenz: Die Summe aller zwölf Monate ergibt weiterhin exakt die bekannte Jahrespauschale von 3.840 €. Die Verteilung ändert also nur, wie sich der bekannte Gesamtbetrag über das Jahr verteilt, nicht die Gesamtsumme selbst.
Die PV-Zuordnung zur Wärmepumpe: von Schätzung zu Live-Daten
Der kniffligste Teil der ganzen WP-Ersparnisrechnung ist die Frage: Wie viel des WP-Stromverbrauchs kam von der PV-Anlage statt aus dem Netz? Seit Kurzem beantwortet ein eigener Sensor diese Frage live und exakt. Für die Monate davor – bevor dieser Sensor existierte – gibt es aber keine Möglichkeit, das nachträglich exakt zu bestimmen.
Warum die erste Schätzung zu optimistisch war
Meine erste Annahme für die Sommermonate lautete: Die Wärmepumpe lief in dieser Zeit zu 100 % PV-gedeckt, verursachte also keine Netzstromkosten. Das klang zunächst plausibel – viel Sonne, wenig Heizbedarf, nur Warmwasserbereitung. Bei näherer Betrachtung stellte sich diese Annahme aber als zu optimistisch heraus: Auch im Sommer läuft die Wärmepumpe nicht ausschließlich dann, wenn die Sonne scheint, sondern auch nachts oder an bewölkten Tagen – und dann eben doch mit Netzstrom.
Das Gewichtungsmodell als bessere Schätzung
Statt einer pauschalen 100-%-Annahme nutze ich für die betroffenen Monate jetzt ein Gewichtungsmodell, das sowohl die PV-Erzeugung als auch den WP-Verbrauch des jeweiligen Monats berücksichtigt. Vereinfacht gesagt: Je mehr PV-Strom in einem Monat erzeugt wurde und je geringer der WP-Verbrauch in diesem Monat war, desto höher der geschätzte PV-Deckungsanteil – und umgekehrt. Für die betroffenen Monate (März bis Juli) ergab dieses Modell folgende geschätzte Ersparniswerte: 445 €, 323 €, 230 €, 140 € und 91 €, ein deutlich moderaterer und realistischerer Verlauf als die ursprüngliche Annahme.
Diese Schätzung bleibt dauerhaft eine Schätzung – Messdaten für diesen Zeitraum werden nicht nachträglich entstehen. Ab dem Monat, in dem der dedizierte PV-Zuordnungssensor aktiv wurde, läuft die Berechnung dagegen live und exakt, und das automatisch auch für alle folgenden Monate.
Zwei Fehler, die auch die Wärmepumpe-Amortisation in Home Assistant betrafen
Zwei der im Übersichtsartikel beschriebenen Stolpersteine hingen direkt mit der Wärmepumpen-Berechnung zusammen. Kurz zur Einordnung, mit dem Fokus auf das, was WP-spezifisch war:
Die doppelte Abrechnung: Weil sowohl die PV-Ersparnis als auch eine WP-Berechnung auf denselben PV-Strom zugriffen, wurde ein Teil der Akku-Ladung fälschlich zweimal gegengerechnet. Für die Wärmepumpe bedeutete das konkret: Die WP-Berechnung durfte den PV-Strom, der in den Akku floss, gar nicht eigenständig berücksichtigen – diese Zuordnung gehört exklusiv in den PV-Ersparnis-Sensor.
Der Mitternachts-Sprung: Der Sensor „WP Ersparnis heute“ sprang nachts abrupt auf einen zu hohen Wert, weil ein Template sich auf einen fehleranfälligen Vortagesreferenzwert bezog. Die Lösung – ein Basis-Vormonate-Helper plus eine tägliche Automation zum sauberen Setzen des Referenzwerts – funktioniert nach demselben Prinzip wie das guarded Template-Muster im PV-Artikel, nur eben für die Wärmepumpe statt für die PV-Monatswerte.
Lehren aus dem WP-Teil des Dashboards
Zwei Erkenntnisse aus diesem Teilprojekt gehen über die Wärmepumpe hinaus:
- Ein einziger Gesamtverbrauchssensor plus separate Zuordnungslogik ist robuster als eine kombinierte Formel. Trenne ich „wie viel verbraucht“ von „wie viel davon war PV“, kann ich beide Werte unabhängig voneinander prüfen und Fehler leichter eingrenzen.
- Eine grobe, aber begründete Schätzung schlägt eine bequeme Pauschalannahme. „100 % PV-gedeckt“ war einfacher zu programmieren als das Gewichtungsmodell – aber auch spürbar ungenauer. Der Mehraufwand für ein realistisches Modell lohnt sich, sobald die Zahl tatsächlich Entscheidungen beeinflusst.
Im nächsten und letzten Detailartikel zur Amortisation in Home Assistant geht es um den Akku: den kleinsten Baustein der Investition, aber denjenigen, der am engsten mit den beiden anderen Systemen verzahnt ist.
* 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.