[[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 > [[08 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 > [[04 Akku-Lade-Sperre|Akku-Lade-Sperre]]. > [!note] Teil des Marstek-Lade-Systems > 1. **Analyse** – [[Batterieladen-Wirtschaftlichkeit]]: Break-Even (25,7 ct) & Ladefenster > 2. **Steuerung** – [[04 Akku-Lade-Sperre|Akku-Lade-Sperre]]: schaltet Laden/Entladen nach Preisniveau > 3. **Buchhaltung** – [[08 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 [[04 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 Akkus × 5 kWh = **15 kWh** Kapazität; 4,95 kW Gesamtladeleistung; Tagesverbrauch ~10 kWh; Round-Trip-Effizienz 77,9 % → Break-Even **25,7 ct** (hergeleitet in [[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 [[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 / 15 kWh (auf 0–100 % begrenzt) ``` **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 | | [[04 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. | --- [[Impressum|Impressum]] | [[Datenschutzerklärung|Datenschutz]]