Mein HA-Energiesystem: Automatisches Laden bei Niedrigpreis & Entladen zur Preisspitze
Kurzer Überblick, was bei mir in den letzten Tagen dazugekommen ist – vielleicht als Anregung für den ein oder anderen mit ähnlichem Setup.
Ausgangslage
-
7,7 kWp PV (Fronius)
-
sonnenBatterie ECO 8 (~8 kWh, Custom-Integration
ha_sonnenbatterie) -
Tibber dynamischer Tarif +
tibber_prices(Custom-Integration von jpawlowski) für Preisprognosen -
Solcast für PV-Prognosen
-
LG Therma V Wärmepumpe + Vaillant Solarthermie (3 m² Kollektor)
-
Alles läuft in HA auf einem Ugreen NAS
Bisher hab ich mich bewusst gegen sonnenVPP entschieden – die Teilnahme am virtuellen Kraftwerk hätte mir die Steuerhoheit über die Batterie teilweise entzogen, und die dynamischen Tarife von sonnen selbst sind aktuell nicht mit VPP kombinierbar. Stattdessen: eigene Automation, volle Kontrolle, keine Abo-Kosten ab Jahr 2.
Netzladen (günstig) – neu
Jeden Tag um 15:00 Uhr (nachdem Tibber die Preise für morgen veröffentlicht hat) prüft ein Script:
-
Reicht die PV-Prognose morgen? (Solcast) – wenn ja, passiert nichts.
-
Wie viel fehlt der Batterie bis zum Ziel-SOC?
-
Für die berechnete Ladedauer wird über
tibber_prices.find_cheapest_blockdas günstigste zusammenhängende Zeitfenster im Tagesverlauf gesucht. -
Zum Fensterstart schaltet die Batterie auf manuellen Lademodus (
sonnenbatterie.set_operating_mode+sonnenbatterie.charge_battery), zum Ende zurück auf Automatik.
Besonders im Winter, wenn PV kaum liefert, lädt die Batterie so gezielt nur in der günstigsten Stunde – statt zufällig oder teuer.
Teuerzeit Entladen – das Gegenstück
Spiegelbildlich dazu: Ist genug Kapazität über einer Reserve-Grenze (Standard 30 %) vorhanden, sucht ein zweites Script per tibber_prices.find_most_expensive_block das teuerste Zeitfenster von morgen und lässt die Batterie dort gezielt entladen (sonnenbatterie.discharge_battery), um Netzbezug in der Preisspitze zu vermeiden.
Beide Automationen sind komplett eigenständig, mit eigenen Einstell-Helfern (Lade-/Entladeleistung, Schwellenwerte, Master-Schalter) und wurden vor der Live-Schaltung erst manuell getestet (kurzer Lade-/Entladebefehl, Wirkung am Akkustand geprüft, dann sauber zurückgesetzt) – bevor man sowas scharf schaltet, sollte man IMO den kompletten Pfad einmal live verifizieren, nicht nur die Planungslogik.
Kleine Stolperfalle für alle, die die sonnenbatterie-Integration nutzen: Der power-Parameter bei charge_battery/discharge_battery muss als String übergeben werden, nicht als Integer – sonst gibt’s einen 400er-Fehler. Hat mich fast erwischt.
Dashboard
Mit apexcharts-card (+ card-mod für Feinschliff) hab ich ein Energie-Dashboard mit:
-
Live-Wärmepumpen-Status inkl. Solar-Vorrang/Tibber-Boost-Logik
-
Solarthermie-Ertrag mit 24h-Max-Werten (Vorlauf, Rücklauf, ΔT-Gewinn) über
statistics-Helfer -
Tibber-Preisverlauf (heute + morgen) im Look des nativen HA-History-Graphen
-
Status-Karten für beide neuen Batterie-Automationen inkl. “zuletzt ausgeführt”
Sonstige Fixes unterwegs
-
Wetterstation (Bresser 7-in-1) hing beim Weather-Underground-Upload fest → Stromlos-Neustart der Konsole hat’s gelöst
-
Zwei Shelly-H&T-Sensoren wurden physisch getauscht, Namen aber behalten – Dashboard entsprechend nachgezogen
-
Doppelten
http:-Key in derconfiguration.yamlbereinigt -
IP-Reservierungen für alle wichtigen Geräte in der Fritzbox gesetzt (Sonnenbatterie, Fronius, Shellys)
-
Frigate-Integration entfernt (verwaist, keine echte Kamera mehr dahinter)
Wärmepumpe: Fußbodenheizung & Warmwasser
Fast vergessen, dabei läuft die schon länger mit: eine LG Therma V (Leasing-Vertrag, deshalb bewusst keine Modbus-Eingriffe direkt am Gerät – die Steuerung läuft komplett über die vorhandenen HA-Schnittstellen drumherum).
Eine Automation (“WP Steuerung: Dorfen Preis-Automatik”) entscheidet laufend zwischen drei Modi, sichtbar direkt im Dashboard:
-
Solar-Vorrang – wenn der Solarthermie-Kollektor (Vorlauf ≥ 45 °C) gerade genug liefert, hat die Sonne Vorrang vor der Wärmepumpe -
Tibber-Boost – bei günstigem Strompreis (unter Anker-Schwelle) läuft die WP bevorzugt -
Sparmodus – sonst wird zurückgehalten
Die Entscheidung berücksichtigt zusätzlich Außentemperatur und zwei Innenraum-Sensoren (Shelly H&T in Wohnzimmer und Einliegerwohnung), damit nicht geheizt wird, wenn’s drinnen eh schon warm genug ist. Kleiner Wartungshinweis dazu: Nach einem Geräte-Tausch bei den Shellys (Hardware physisch versetzt, Namen aber beibehalten) mussten die Sensor-IDs in der Automation nachgezogen werden – falls bei euch mal Konditionen mit “unknown entity” ins Log wandern, checkt zuerst, ob sich dahinter ein umbenanntes/getauschtes Gerät versteckt.
Für Warmwasser gibt’s zusätzlich:
-
Eine Dusch-Bereitschaft-Anzeige basierend auf geglätteter Speichertemperatur (
filter-Helfer, um Messrauschen rauszunehmen) -
Einen 30-Minuten-Boost-Knopf für spontanen Warmwasserbedarf, unabhängig von der Preis-Logik
Damit greifen Fußbodenheizung, Warmwasser, Solarthermie und die beiden Batterie-Automationen (siehe oben) ineinander – alles hängt letztlich an denselben Preis- und Temperatursignalen.
Fazit
Der Umweg über eigene HA-Automation statt sonnenVPP war definitiv mehr Aufwand, aber jetzt läuft’s transparent, kostenlos und exakt auf meine Anlage zugeschnitten. Wer die tibber_prices-Integration von jpawlowski nutzt: die find_cheapest_block/find_most_expensive_block-Services sind Gold wert für sowas, spart einem komplett die eigene Preis-Sortier-Logik.
Fragen gerne her damit, teile auch gern die Automation-YAMLs, falls Interesse besteht.
