[[Uebersicht|← Zurück zur Homepage]] # Strompreis nach Preisniveau — Wochenauswertung ## Vorgabe Berechne für jeden Zustand von `sensor.daheim_aktuelles_preisniveau` den Mittelwert von `sensor.daheim_aktueller_strompreis` pro Woche der letzten 2 Monate. **Sensoren:** - `sensor.daheim_aktueller_strompreis` — aktueller Tibber-Strompreis (€/kWh) - `sensor.daheim_aktuelles_preisniveau` — Preisniveau-Klassifikation (very_cheap / cheap / normal / expensive / very_expensive) **Methode:** Für jede Zustandsänderung des Preisniveaus wird der zeitgleiche Strompreis abgelesen und den entsprechenden (Woche, Niveau)-Bucket zugeordnet. Mittelwert pro Bucket. **Zeitraum:** 2026-05-02 bis 2026-07-11 --- ## Ergebnis (Stand 2026-07-11) ### KW24 | Niveau | Mittel | Min | Max | |----------------|-----------|-----------|-----------| | very_cheap | 15,45 ct | 11,76 ct | 18,07 ct | | cheap | 22,27 ct | 15,20 ct | 30,45 ct | | normal | 31,40 ct | 23,51 ct | 38,27 ct | | expensive | 34,59 ct | 23,23 ct | 43,03 ct | | very_expensive | 45,30 ct | 44,97 ct | 46,59 ct | ### KW25 | Niveau | Mittel | Min | Max | |----------------|-----------|-----------|------------| | very_cheap | 18,23 ct | 18,07 ct | 19,50 ct | | cheap | 22,00 ct | 17,71 ct | 30,49 ct | | normal | 31,68 ct | 21,78 ct | 41,49 ct | | expensive | 33,42 ct | 26,17 ct | 43,37 ct | | very_expensive | 42,63 ct | 30,86 ct | **82,89 ct** ⚠ | ### KW26 | Niveau | Mittel | Min | Max | |----------------|-----------|-----------|-------------| | very_cheap | 19,24 ct | 17,96 ct | 23,42 ct | | cheap | 28,42 ct | 19,07 ct | 34,49 ct | | normal | 34,20 ct | 26,67 ct | 48,82 ct | | expensive | 38,81 ct | 33,84 ct | 53,90 ct | | very_expensive | 66,05 ct | 39,31 ct | **106,97 ct** ⚠ | ### KW27 (vollständige Woche, korrigiert — vorherige Auswertung endete mitten in der Woche) | Niveau | Mittel | Min | Max | |----------------|-----------|-----------|------------| | very_cheap | 20,53 ct | 20,01 ct | 21,05 ct | | cheap | 27,22 ct | 19,58 ct | 33,44 ct | | normal | 32,51 ct | 23,06 ct | 39,43 ct | | expensive | 38,16 ct | 31,39 ct | 45,86 ct | | very_expensive | 49,91 ct | 49,48 ct | 50,34 ct | ### KW28 (bis 2026-07-11, laufende Woche) | Niveau | Mittel | Min | Max | |----------------|-----------|-----------|------------| | very_cheap | – | – | – | | cheap | 25,01 ct | 23,69 ct | 26,99 ct | | normal | 30,91 ct | 25,70 ct | 36,32 ct | | expensive | 34,50 ct | 30,95 ct | 40,83 ct | | very_expensive | 41,91 ct | 41,83 ct | 41,98 ct | *Alle Werte in ct/kWh* --- ## Beobachtungen - **KW26** bleibt die bisherige Preisspitze in allen Kategorien; KW27/KW28 pendeln sich wieder auf niedrigerem Niveau ein - `very_expensive` fiel von 66 ct (KW26) über 50 ct (KW27) auf 42 ct (KW28) — deutliche Entspannung - `very_cheap` in KW28 (bisher) nicht vorhanden, war aber in KW27 wieder aufgetreten (Mittel 20,53 ct) - **Max-Werte `very_expensive` deutlich beruhigt:** KW26: 106,97 ct, KW27: 50,34 ct, KW28: 41,98 ct - Sensor `daheim_aktuelles_preisniveau` seit ~Mitte Juni 2026 aktiv (KW24), inzwischen 5 KW Datenbasis (KW28 noch laufend, Stand 2026-07-11 ca. 07:30 Uhr) --- ## Wirtschaftlichkeit — Batterieladen ### Tatsächliche Marstek Round-Trip-Effizienz (Stand 2026-07-11) | Batterie | Geladen (kWh) | Entladen (kWh) | Effizienz | |---|---|---|---| | MTV01 | 173,12 | 132,73 | 76,7 % | | MTV02 | 158,92 | 122,09 | 76,8 % | | MTV03 | 264,75 | 209,80 | 79,2 % | | **Gesamt** | **596,79** | **464,62** | **77,9 %** | ### Break-Even Ladepreis Formel: `Break-Even = Entladepreis × η` (η = 0,779) | Entlade-Szenario | Break-Even Ladepreis | Passendes Niveau | | ------------------------------------ | -------------------- | --------------------------------- | | Entladen bei normal (~33 ct) | bis **25,7 ct** | nur `very_cheap` ✅ | | Entladen bei expensive (~38 ct) | bis **29,6 ct** | `very_cheap` + teils `cheap` ✅ | | Entladen bei very_expensive (~54 ct) | bis **42,1 ct** | `very_cheap`, `cheap`, `normal` ✅ | ### Fazit - Laden bei `very_cheap` (~20 ct, KW27/28) lohnt sich **immer** - Laden bei `cheap` (19,58–33,44 ct, KW27) lohnt sich nur unterhalb des Break-Even — die Kategorie allein reicht nicht als Signal - Laden bei `normal`/`expensive`/`very_expensive` lohnt sich grundsätzlich nicht (das sind die vorgesehenen Entlade-Niveaus) - **Korrektur 2026-07-11:** Die Automation (siehe [[Akku-Lade-Sperre]]) prüfte bisher tatsächlich nur einen festen 25-ct-Schwellenwert auf den Rohpreis — **nicht** das Preisniveau, wie hier fälschlich behauptet. Umgestellt auf: `very_cheap` → immer laden; `cheap` → nur laden wenn Rohpreis zusätzlich < 23,7 ct (2 ct Sicherheitspuffer unter dem 25,7-ct-Break-Even für `normal`); `normal`/`expensive`/`very_expensive` → entladen. Live getestet und aktiviert (war seit 2026-07-10 22:00 deaktiviert, unabhängig von dieser Änderung). - **Klarstellung 2026-07-11 (Break-Even gilt nicht als Entlade-Blocker):** Der Break-Even (Ladepreis × η) bewertet ausschließlich, ob sich das **Laden** zu einem bestimmten Preis gelohnt hat. Für die Entlade-Entscheidung ist er nicht relevant — sobald der Akku geladen ist, sind die Ladekosten versunken (sunk cost); die einzig relevante Frage ist "Akku nutzen vs. Netzstrom kaufen", und das ist praktisch immer günstiger als Netzbezug. Die Automation bleibt daher bewusst rein niveau-basiert (kein Preis-Floor auf das Entladen) — geprüft und verworfen am 2026-07-11. --- ## Preisverteilung — Zeitanteil (2026-05-02 bis 2026-07-11) Zeitgewichtete Auswertung von `sensor.daheim_aktueller_strompreis` (748 h, ca. 2944 Datenpunkte): | Preisbereich | Zeitanteil | Stunden | |--------------------|-----------|---------| | **< 26 ct** (Ladezone) | **25,0 %** | 187 h | | 26–29 ct (Grauzone) | 10,3 % | 77 h | | **> 29 ct** | **64,8 %** | 485 h | **Hinweis:** Sensor speichert Werte direkt in ct/kWh (nicht €/kWh). **Interpretation:** - Günstiges Laden (< 26 ct) war inzwischen genau **1 von 4 Stunden** möglich (leichte Verbesserung gegenüber Stand 07-02) - Knapp zwei Drittel der Zeit lag der Preis über 29 ct — weiterhin klares Entlade-Fenster - Die Grauzone (26–29 ct) ist je nach erwartetem Entladepreis grenzwertig --- ## Optimales Ladezeit-Fenster (Stand 2026-07-11) Berechnung: Für jeden Tag wird aus PV-Ertrag und Fixverbrauch (10 kWh/Tag) der Netzbedarf ermittelt. Daraus folgt die Ladezeit bei 3 × 1,5 kW = 4,5 kW Gesamtladeleistung. Die günstigsten Stunden des Tages werden als Ladefenster gewählt. **Auswertung: 2026-06-10 bis 2026-07-10 (31 Tage, laufender 2026-07-11 wegen Tagesbeginn noch ausgeklammert)** *Korrektur: Die vorherige Fassung hatte 2026-06-18 bis 06-26 pauschal als "PV deckt Verbrauch" zusammengefasst — 06-19 und 06-23 hatten tatsächlich geringen Netzbezug. Tabelle jetzt Tag für Tag, auch 06-28 (zuvor versehentlich ausgelassen) ergänzt.* | Datum | PV (kWh) | Netzbedarf | Ladezeit | ∅ Ladepreis | |---|---|---|---|---| | 2026-06-10 | 6,39 | 3,61 kWh | 1 h | 26,4 ct | | 2026-06-11 | 6,88 | 3,12 kWh | 1 h | 22,1 ct | | 2026-06-12 | 3,43 | 6,57 kWh | 2 h | 24,4 ct | | 2026-06-13 | 10,02 | — | 0 h | PV deckt Verbrauch | | 2026-06-14 | 5,94 | 4,06 kWh | 1 h | **15,0 ct** | | 2026-06-15 | 8,43 | 1,57 kWh | 1 h | 17,8 ct | | 2026-06-16 | 6,47 | 3,53 kWh | 1 h | 23,8 ct | | 2026-06-17 | 8,63 | 1,37 kWh | 1 h | 25,4 ct | | 2026-06-18 | 11,00 | — | 0 h | PV deckt Verbrauch | | 2026-06-19 | 9,13 | 0,87 kWh | 1 h | 19,3 ct | | 2026-06-20 | 10,97 | — | 0 h | PV deckt Verbrauch | | 2026-06-21 | 10,62 | — | 0 h | PV deckt Verbrauch | | 2026-06-22 | 10,72 | — | 0 h | PV deckt Verbrauch | | 2026-06-23 | 9,60 | 0,40 kWh | 1 h | 24,9 ct | | 2026-06-24 | 10,70 | — | 0 h | PV deckt Verbrauch | | 2026-06-25 | 10,65 | — | 0 h | PV deckt Verbrauch | | 2026-06-26 | 10,03 | — | 0 h | PV deckt Verbrauch | | 2026-06-27 | 8,72 | 1,28 kWh | 1 h | 18,1 ct | | 2026-06-28 | 10,10 | — | 0 h | PV deckt Verbrauch | | 2026-06-29 | 7,59 | 2,41 kWh | 1 h | 27,7 ct | | 2026-06-30 | 8,09 | 1,91 kWh | 1 h | 29,2 ct | | 2026-07-01 | 10,79 | — | 0 h | PV deckt Verbrauch | | 2026-07-02 | 7,55 | 2,45 kWh | 1 h | 17,8 ct | | 2026-07-03 | 11,41 | — | 0 h | PV deckt Verbrauch | | 2026-07-04 | 9,87 | 0,13 kWh | 1 h | 16,7 ct | | 2026-07-05 | 5,24 | 4,76 kWh | 2 h | 17,9 ct | | 2026-07-06 | 6,96 | 3,04 kWh | 1 h | 18,4 ct | | 2026-07-07 | 9,35 | 0,65 kWh | 1 h | 20,2 ct | | 2026-07-08 | 4,95 | 5,05 kWh | 2 h | 18,8 ct | | 2026-07-09 | 9,25 | 0,75 kWh | 1 h | 22,0 ct | | 2026-07-10 | 10,65 | — | 0 h | PV deckt Verbrauch | **Gesamt (19 von 31 Tagen mit Netzbezug):** | | Wert | |---|---| | ∅ PV-Ertrag | 8,71 kWh/Tag | | ∅ Netzbedarf | 1,53 kWh/Tag | | ∅ Ladezeit | **0,7 h/Tag** (≈ 43 Min.) | | **∅ Preis im Ladefenster** | **21,4 ct/kWh** | **Fazit:** - An **12 von 31 Tagen** war kein Netzbezug nötig (PV ≥ 10 kWh/Tag) - Wenn geladen werden muss: im Schnitt nur **1 Stunde** — alle 3 Batterien parallel - 21,4 ct liegt unter dem aktualisierten Break-Even von 25,7 ct → Laden im Optimumfenster **lohnt sich weiterhin immer** - Skript: `/config/tools/Ko.py` (diesmal via HA REST-History-API nachgebildet, siehe Datenquelle) --- ## Datenquelle HA SQLite DB: `/config/home-assistant_v2.db` Auswertung ursprünglich via `/config/tools/Ko.py` (Ultraplan, 2026-07-03). **Update 2026-07-11:** Direkter SQLite-Zugriff über den Samba-Mount (`H:\home-assistant_v2.db`) schlug fehl (`sqlite3.DatabaseError: file is not a database`) — vermutlich WAL-Konsistenzproblem beim Lesen einer aktiv beschriebenen DB über SMB. Ausweichend über HA REST-History-API (`/api/history/period`, Long-Lived Token) abgefragt und die Ko.py-Logik (Trapez-/Delta-Aggregation, Einheiten-Autoerkennung) in Python nachgebildet. Ergebnisse für den überschneidenden Zeitraum (2026-06-10 bis 07-02) stimmen exakt mit den vorherigen Werten überein — Methode verifiziert. Für ältere Wochen (KW24–26) wurde bewusst **nicht** neu abgefragt, da die REST-History für weiter zurückliegende Preisniveau-Wechsel bereits durch den HA-Recorder-Purge ausgedünnt war (sichtbar an reduzierten Stichprobenzahlen); die ursprünglich dokumentierten KW24–26-Werte (erfasst vor dem Purge) gelten daher weiterhin als verbindlich. --- ## Tags `#homeassistant` `#tibber` `#strompreis` `#marstek` `#wirtschaftlichkeit` `#auswertung` --- ## Versionshistorie | Version | Datum/Uhrzeit | Änderung | |---|---|---| | v1.4 | 2026-07-03 | Note erstellt (entspricht Repo-Doku `docs/Strompreis-nach-Preisniveau-Wochenauswertung.md`) | | v1.4 (übernommen) | 2026-07-10 | Aus Repo-Doku in Obsidian übernommen | | v1.5 | 2026-07-11 07:30 | Statistik aktualisiert: KW27 vollständig neu berechnet (vorher nur bis Mittwoch), KW28 (laufend) ergänzt; Preisverteilung/Zeitanteil, Marstek-Effizienz, Break-Even und Ladezeit-Fenster auf aktuellen Stand gebracht; Ladezeit-Fenster-Tabelle korrigiert (06-18–06-26 fälschlich als "PV deckt Verbrauch" gruppiert, 06-28 fehlte) und bis 07-10 erweitert; Datenquelle auf HA REST-History-API umgestellt, da SQLite-Zugriff über Samba fehlschlug | | v1.6 | 2026-07-11 07:50 | Konsistenzprüfung gegen die HA-Automation `Akku Lade-Sperre bei Tibber-Preisniveau`: Fazit-Aussage war falsch (Automation nutzte tatsächlich festen 25-ct-Schwellenwert statt Preisniveau). Automation auf echte Preisniveau-Logik umgestellt (very_cheap immer laden, cheap nur < 23,7 ct Puffer, sonst entladen), Snapshot vor Änderung erstellt, Config-Check + Live-Template-Test gegen Ist-Daten erfolgreich, reloaded und aktiviert (war seit 07-10 22:00 unabhängig davon deaktiviert). Fazit-Text hier entsprechend korrigiert. | | v1.7 | 2026-07-11 08:10 | Geprüft, ob die Break-Even-Ladepreise als Preis-Floor fürs Entladen in die Automation einfließen sollten. Ergebnis: nein — Break-Even bewertet nur die Wirtschaftlichkeit des Ladens, nicht des Entladens (Ladekosten sind beim Entladen bereits versunken; Akku nutzen ist praktisch immer günstiger als Netzstrom kaufen). Automation bleibt unverändert (rein niveau-basiertes Entladen). Klarstellung im Fazit ergänzt. | --- [[Impressum|Impressum]] | [[Datenschutzerklärung|Datenschutz]]