Batteriespeicher-Amortisation in Home Assistant: die Formel im Detail

Nach dem Übersichtsartikel, dem PV-Detailartikel und dem Wärmepumpen-Detailartikel fehlt für die Akku-Amortisation in Home Assistant noch der kleinste, aber am engsten mit den anderen beiden verzahnte Baustein: der Akku. Mit einer Investition von nur 1.189 € ist er finanziell das Leichtgewicht im Dashboard – aber gerade weil seine Formel direkt von der PV-Formel abhängt, lohnt sich ein genauer Blick.

Die Akku-Formel: die andere Hälfte der PV-Rechnung

Im PV-Artikel ging es schon um den Akku-Ladung-Term, den ich von der PV-Ersparnis abziehe, weil geladener Strom noch keine realisierte Ersparnis ist. Die Akku-Formel ist die logische Fortsetzung davon:

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

Der Wert 0,17 €/kWh ist kein Zufallswert, sondern ein bewusster Mittelweg. Würde ich für die Akku-Entladung den vollen Netzstrompreis von 0,25 €/kWh ansetzen, würde ich denselben Strom im Grunde zweimal zum vollen Preis bewerten – einmal beim Laden (implizit, weil er der PV-Formel als Einspeisung „entgeht“), einmal beim Entladen. Der reduzierte Wert bildet ab, dass ein Teil der Ladeverluste (Umwandlung, Speicherverluste) real ist und die Ersparnis dadurch etwas geringer ausfällt als bei direktem Eigenverbrauch. Der Akku ist nie so effizient wie der direkte Verbrauch von PV-Strom im Moment der Erzeugung, und die Formel bildet das ehrlich ab, statt es zu beschönigen.

Warum diese Symmetrie wichtig ist

PV-Formel und Akku-Formel gehören untrennbar zusammen. Was die PV-Formel als Akku-Ladung abzieht, taucht hier als Entladung wieder auf. Rechne ich nur eine der beiden Seiten, ergibt die Gesamtsumme entweder zu viel (wenn ich die Akku-Ladung in der PV-Formel vergesse abzuziehen) oder zu wenig (wenn ich die Entladung beim Akku vergesse zu verbuchen). Genau dieser Zusammenhang war es auch, der im Übersichtsartikel zum doppelten Abrechnungsfehler führte, als eine dritte Stelle – die WP-Berechnung – versehentlich ebenfalls auf denselben PV-Strom zugriff.

Für mich ist die Lehre daraus: Sobald zwei Formeln über eine gemeinsame Energiemenge miteinander verknüpft sind, sollte ich sie auch gemeinsam denken und testen – nicht nacheinander isoliert bauen und hoffen, dass sich am Ende alles zufällig richtig summiert.

Technischer Aufbau: Sensor, Card und Monatswechsel

Genau wie bei PV und Wärmepumpe läuft auch die Akku-Ersparnis über einen zentralen Template-Sensor, statt die Formel direkt in der Dashboard-Card zu berechnen. Voraussetzung dafür ist, dass die Entladung des Akkus überhaupt als eigene Energie-Entität vorliegt – dazu mehr in der Home-Assistant-Dokumentation zur Batterie-Integration, die verschiedene Wege beschreibt, Lade- und Entladewerte ins System zu bekommen (per Hersteller-API oder über einen CT-Clamp-Sensor).

template:
  - sensor:
      - name: "Akku Ersparnis Gesamt"
        unique_id: akku_ersparnis_gesamt
        unit_of_measurement: "€"
        state: >
          {% set entladung_kwh = states('sensor.akku_entladung_gesamt') | float(0) %}
          {{ (entladung_kwh * 0.17) | round(2) }}Code-Sprache: JavaScript (javascript)

Auf dem Dashboard zeigt eine Mushroom-Card wieder genau diesen einen Sensor – dieselbe Struktur wie bei PV und Wärmepumpe, nur mit der Akku-Entität:

type: custom:mushroom-template-card
primary: "Akku Ersparnis"
secondary: "{{ states('sensor.akku_ersparnis_gesamt') }} €"
icon: mdi:battery-charging-high
tap_action:
  action: more-infoCode-Sprache: JavaScript (javascript)

Für den Monatswechsel kommt dasselbe guarded Template-Muster zum Einsatz wie bei PV und Wärmepumpe: ein Helper input_number.akku_ersparnis_basis_vormonat für den laufenden Monat, ein „Frozen-Value“-Helper pro abgeschlossenem Monat, und eine tägliche Automation, die am Monatsersten einfriert und zurücksetzt:

alias: Akku 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.akku_ersparnis_august_final
    data:
      value: "{{ states('sensor.akku_ersparnis_august') | float }}"
  - service: input_number.set_value
    target:
      entity_id: input_number.akku_ersparnis_basis_vormonat
    data:
      value: "{{ states('sensor.akku_ersparnis_gesamt') | float }}"
mode: singleCode-Sprache: JavaScript (javascript)

Damit teilen sich alle drei Systeme – PV, Wärmepumpe und Akku – dieselbe technische Architektur: ein zentraler Template-Sensor pro System, eine einheitliche Mushroom-Card-Struktur und dieselbe Monatswechsel-Logik. Genau diese Wiederholung macht das Gesamt-Dashboard wartbar, weil ich einen einmal verstandenen Mechanismus dreimal wiederverwenden kann, statt ihn dreimal neu zu erfinden.

Home Assistant läuft bei mir auf einem Raspberry Pi 4. Für die langfristigen Verlaufs-, Energie- und Amortisationsdaten 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.

Warum der Akku-Fortschritt so langsam wächst

Ein Blick auf die aktuellen Zahlen zeigt etwas, das bei der Akku-Amortisation in Home Assistant auf den ersten Blick überrascht: Der Akku-Fortschritt liegt bislang nur bei knapp 2 %, deutlich niedriger als bei PV-Anlage oder Wärmepumpe zu vergleichbaren Zeitpunkten ihrer Laufzeit. Das hat einen strukturellen Grund, keinen technischen Fehler.

Der Akku steht in der Prioritätenkette ganz hinten. PV-Strom deckt zuerst den direkten Hausverbrauch (Eigenverbrauch), das ist immer die wirtschaftlichste Verwendung. Erst der Überschuss, der nicht sofort gebraucht wird, lädt den Akku. Und nur der Überschuss, der auch das nicht mehr kann – etwa weil der Akku bereits voll ist – wird eingespeist. Der Akku bekommt also grundsätzlich nur die „Reste“ der PV-Erzeugung, nachdem der Eigenverbrauch schon bedient ist. In den sonnenreichen Monaten mit hohem Überschuss füllt sich der Akku entsprechend gut, in den Übergangs- und Wintermonaten dagegen kaum, weil dort selten überschüssiger PV-Strom übrig bleibt.

Dazu kommt der Ladeverlust-Effekt aus der Formel oben: Weil die Entladung nur zu 0,17 statt 0,25 €/kWh bewertet wird, braucht der Akku spürbar mehr durchgeladene Kilowattstunden, um denselben Ersparnisbetrag zu erreichen wie ein direkter PV-Eigenverbrauch. Beide Effekte zusammen – wenige volle Ladezyklen außerhalb der Sommermonate plus der reduzierte Bewertungssatz – erklären, warum der Akku-Fortschritt langsamer wächst als bei den anderen beiden Systemen. Das ist kein Grund zur Sorge, sondern schlicht die Natur eines Speichers: Er verdient sein Geld nicht durch hohen Durchsatz, sondern durch das Verschieben von Energie in Zeiten, in denen sie sonst verloren ginge.

Eine Besonderheit bei der Investitionssumme

Bei der Gesamt-Amortisation im Übersichtsartikel taucht die Investition „inkl. Zinsen“ auf, weil ein Teil der Gesamtsumme über einen Kredit finanziert wurde. Der Akku ist davon ausgenommen: Ich habe ihn bar bezahlt, daher zeigt seine Kachel im Dashboard „Investition (bar bezahlt)“ statt eines zinsbereinigten Werts. Das ist ein kleines, aber wichtiges Detail für die Konsistenzprüfung des Dashboards – würde ich versehentlich auch beim Akku einen Zinsanteil einrechnen, obwohl keiner anfällt, würde die Gesamtsumme in der übergeordneten Kachel nicht mehr zur Summe der Einzelinvestitionen passen.

Lehren aus dem Akku-Teil des Dashboards

Zwei Punkte aus diesem letzten Baustein, die sich auf jedes Speicher-Tracking übertragen lassen:

  • Ein langsamer Fortschritt ist nicht automatisch ein Fehler. Bevor ich einen niedrigen Wert als Bug behandle, prüfe ich erst, ob die Systemlogik selbst ihn erklärt – beim Akku ist die niedrige Priorität in der Ladekette der Grund, kein defekter Sensor.
  • Verknüpfte Formeln gehören zusammen getestet. PV- und Akku-Formel lassen sich nicht unabhängig voneinander verifizieren, weil ein Fehler in der einen sich unweigerlich auf die andere auswirkt.

Fazit zur Akku-Amortisation in Home Assistant und zur Artikel-Serie

Damit ist die Serie zum Amortisations-Dashboard komplett: das Gesamtbild im Übersichtsartikel, die PV-Formel mit ihrem Platzhalter-Bug, die Wärmepumpe mit ihrem eigenen Vergleichsmaßstab gegen Fernwärme, und jetzt der Akku als das Bindeglied, das PV- und Gesamtrechnung erst konsistent macht. Was alle vier Artikel eint: Die größte Arbeit steckt selten im Dashboard-Layout, sondern in den Sensoren und Formeln dahinter – und darin, sie so zu bauen, dass sie sich gegenseitig plausibilisieren, statt sich blind aufeinander zu verlassen.

Schreibe einen Kommentar