[[Uebersicht|← Zurück zur Homepage]] # Batterie-Füllgrad-Planung (Konzept-Entwurf) > [!warning] Status: Entwurf – noch nicht implementiert > Diese Note beschreibt die geplante **Entscheidungslogik**, die den in > [[30 Batterien-Ladepreis-Buchhaltung]] geführten tatsächlichen Einkaufspreis > nutzbar macht. Sie ist ein **Konzept**, keine laufende Automation. Umgesetzt ist > bisher nur die Buchhaltung (Kostenbasis je Akku) und die preisniveau-basierte > [[11 Akku-Lade-Sperre|Akku-Lade-Sperre]]. > [!note] Teil des Marstek-Lade-Systems > 1. **Analyse** – [[31 Batterieladen-Wirtschaftlichkeit]]: Break-Even (25,7 ct) & Ladefenster > 2. **Steuerung** – [[11 Akku-Lade-Sperre|Akku-Lade-Sperre]]: schaltet Laden/Entladen nach Preisniveau > 3. **Buchhaltung** – [[30 Batterien-Ladepreis-Buchhaltung]]: echter Einkaufspreis je Akku > 4. **Planung → du bist hier:** verknüpft Buchhaltung + Prognose zu einer Füllgrad-Strategie --- ## Ziel Heute entscheidet die [[11 Akku-Lade-Sperre|Akku-Lade-Sperre]] rein nach **Preisniveau** (`very_cheap` → laden, `cheap` < 23,7 ct → laden, sonst entladen). Sie kennt aber **nicht**, zu welchem Preis der aktuelle Akku-Bestand geladen wurde und **wie voll** die Akkus über den Tag sein sollten. Diese Planung soll zwei Dinge ergänzen: 1. **Kostenbasis-Abgleich** – lade/entlade abhängig vom tatsächlichen `ladepreis_durchschnitt` je Akku, nicht nur vom Preisniveau. 2. **Füllgrad-Vorausplanung** – halte einen Ziel-Füllstand, der zur PV-Prognose und zu den teuren Abendstunden passt (nicht unnötig teuer nachladen, was die PV morgen ohnehin liefert; nicht leer sein, wenn der Strom am teuersten ist). --- ## Ausgangsdaten (alle vorhanden) | Größe | Sensor | Einheit | |---|---|---| | Bestandspreis je Akku | `sensor.mtv0X_ladepreis_durchschnitt` | ct/kWh | | Gespeicherte Energie je Akku | `sensor.mtv0X_stored_energy` | kWh | | Aktueller Netzpreis | `sensor.daheim_aktueller_strompreis` | ct/kWh | | Aktuelles Preisniveau | `sensor.daheim_aktuelles_preisniveau` | Klasse | | PV-Prognose heute | `sensor.solcast_pv_forecast_prognose_heute` | kWh | **Rahmen:** 3× Marstek Venus E v3 à 5 kWh = **15 kWh brutto**, davon **13,2 kWh nutzbar** (1,8 kWh ≈ 12 % müssen im Akku verbleiben, sonst Zellschädigung); 4,95 kW Gesamtladeleistung; Tagesverbrauch ~10 kWh; Round-Trip-Effizienz 77,9 % → Break-Even **25,7 ct** (hergeleitet in [[31 Batterieladen-Wirtschaftlichkeit]]). --- ## Kernidee Zwei getrennte Entscheidungen, beide gegen den **Break-Even** bzw. den **eigenen Bestandspreis** gerechnet: ### A) Entladen vs. Netzbezug (laufende Verbrauchsdeckung) Sobald der Akku geladen ist, sind die Ladekosten *versenkt* (Sunk Cost, siehe [[31 Batterieladen-Wirtschaftlichkeit]]). Für die reine Frage „Akku nutzen oder Netzstrom kaufen?" gilt daher: > **Entladen, solange Netzpreis > 0.** Netzbezug ist fast immer teurer als der bereits > gespeicherte Strom. Das entspricht der heutigen Logik – hier ändert sich wenig. Der `ladepreis_durchschnitt` ist für diese Entscheidung **nicht** ausschlaggebend, dient aber als Transparenz-/Reporting-Wert und für Entscheidung B. ### B) Nachladen aus dem Netz (Ziel-Füllgrad) Hier wird der Bestandspreis relevant. Nachladen lohnt sich nur, wenn der **aktuelle Netzpreis** unter dem liegt, was die gespeicherte Energie später ersetzt – gedeckelt durch den Break-Even: | Situation | Regel | | -------------------------------------------------------- | ------------------------------------------------------- | | Netzpreis < Break-Even (25,7 ct) **und** Füllgrad < Ziel | **Nachladen** | | Netzpreis ≥ Break-Even | **Nicht nachladen** (später aus Akku/PV decken) | | Netzpreis < eigener `ladepreis_durchschnitt` | Nachladen **senkt** den Mischpreis → besonders sinnvoll | | PV-Prognose deckt Restbedarf des Tages | **Ziel-Füllgrad absenken** (kein Netz-Nachladen) | | | | --- ## Ziel-Füllgrad über den Tag Der Ziel-Füllstand ist **nicht** konstant 100 %, sondern richtet sich nach dem Restbedarf bis zum nächsten günstigen Ladefenster: ``` Rest-Netzbedarf = max(0, Restverbrauch_bis_morgen − PV-Prognose_Rest) Ziel-Füllgrad = Rest-Netzbedarf / 13,2 kWh (auf 0–100 % begrenzt) ``` > [!note] Warum 13,2 kWh und nicht 15 kWh > Der Nenner ist die **maximal verfügbare** Kapazität (Nutzerangabe 17.07.2026), nicht die > Bruttokapazität. Die 1,8 kWh Reserve lassen sich nicht entnehmen und dürfen deshalb nicht > in den Ziel-Füllgrad eingehen: Mit 15 kWh im Nenner ergäbe ein Rest-Netzbedarf von 13,2 kWh > nur 88 % Ziel-Füllgrad – tatsächlich wäre der Speicher dann bereits am Anschlag. > Die Formel würde also systematisch zu wenig nachladen, und zwar umso stärker, je voller > der Zielzustand ist. **Beispiele:** - Sonniger Tag, PV deckt den Rest → Ziel niedrig, **kein** teures Nachladen. - Trüber Tag, teurer Abend voraus → Ziel hoch, in der günstigen Nacht/Mittagszone auffüllen. So wird nur so viel aus dem Netz geladen, wie PV **nicht** liefern wird – und das nur, wenn der Preis unter dem Break-Even liegt. --- ## Abgrenzung zur bestehenden Akku-Lade-Sperre | | [[11 Akku-Lade-Sperre|Akku-Lade-Sperre]] (live) | Diese Planung (Entwurf) | |---|---|---| | Basis | Preisniveau + fester 23,7-ct-Puffer | Bestandspreis + PV-Prognose + Ziel-Füllgrad | | Blick | nur „jetzt" | vorausschauend über den Tag | | Füllgrad | nicht berücksichtigt | Kernparameter | **Migrationsidee:** Die Planung könnte den festen 23,7-ct-Schwellwert der Akku-Lade-Sperre durch einen **dynamischen** Zielwert ersetzen (aus Break-Even − Puffer, moduliert per PV-Prognose), statt die Automation komplett zu ersetzen. --- ## Offene Fragen / nächste Schritte - [ ] **Restverbrauch-Prognose:** Woher kommt „Restverbrauch bis morgen"? Fixwert (10 kWh anteilig) oder aus Verbrauchshistorie/Tagesprofil? - [ ] **PV-Rest-Prognose:** Aus Solcast den *verbleibenden* Tagesertrag ableiten (Prognose gesamt − bereits erzeugt). - [ ] **Steuergröße:** Schaltet die Planung dieselben `allow_charge`-Switches, oder setzt sie Marstek-Leistungs-/SOC-Grenzwerte (`number.mtv0X_*`)? - [ ] **Balancing/Temperatur-Vorrang** wie in der Akku-Lade-Sperre übernehmen. - [ ] **Test-Zeitraum** definieren und gegen die reine Preisniveau-Logik gegenrechnen (Ersparnis?). - [ ] Entscheidung: eigene Automation **oder** Erweiterung von `1751200000001` (Akku-Lade-Sperre). --- ## Tags `#homeassistant` `#marstek` `#tibber` `#ladepreis` `#planung` `#konzept` `#entwurf` --- ## Versionshistorie | Version | Datum/Uhrzeit | Änderung | |---|---|---| | v0.1 | 2026-07-14 13:45 | Konzept-Entwurf erstellt: Entscheidungslogik (Netzpreis vs. Bestandspreis) + Ziel-Füllgrad aus PV-Prognose. Noch nicht implementiert. | | v0.2 | 2026-07-17 11:05 | Rahmen präzisiert (Nutzerangabe): 15 kWh sind **brutto**, nutzbar ca. 13 kWh (12–15 % Reserve). Neuer Warnhinweis: Die Ziel-Füllgrad-Formel teilt durch die Brutto-Kapazität – vor der Umsetzung ist zu klären, ob die SOC-Sensoren brutto oder netto melden. Formel bewusst **nicht** geändert (Entwurf, gehört in die Umsetzung) | | v0.3 | 2026-07-17 12:05 | **Offene Frage aus v0.2 geklärt (Nutzerangabe: max. verfügbare Kapazität = 13,2 kWh):** Nenner der Ziel-Füllgrad-Formel von 15 kWh (brutto) auf **13,2 kWh** (nutzbar) geändert. Begründung ergänzt: Die 1,8 kWh Reserve sind nicht entnehmbar; mit 15 kWh im Nenner hätte die Formel systematisch zu wenig nachgeladen – bei 13,2 kWh Restbedarf nur 88 % Ziel-Füllgrad, obwohl der Speicher dann schon am Anschlag wäre. Warnhinweis durch Erklärung ersetzt | --- [[Impressum|Impressum]] | [[Datenschutzerklärung|Datenschutz]]