Ein Batteriespeicher macht von sich aus etwas ziemlich Unkluges: Er lädt mit der ersten Kilowattstunde Überschuss am Morgen und ist an einem Sonnentag schon zu Mittag voll. Genau dann, wenn die PV-Anlage am meisten liefert, geht alles ins Netz. In diesem Artikel zeige ich, wie ich mit Home Assistant, einer PV-Prognose und ein paar Modbus-Registern meinen Fronius GEN24 dazu bringe, die BYD-Batterie vormittags warten zu lassen und sie trotzdem jeden Tag sicher vollzuladen. Mit Schritt-für-Schritt-Anleitung, allen YAML-Blöcken, Rechenbeispielen und einem Dashboard.
Die Idee
Die Steuerung beantwortet alle 15 Minuten eine einzige Frage: Reicht die restliche Sonne heute noch, um das Haus zu versorgen und die Batterie trotzdem vollzumachen? Wenn ja, und es bleibt sogar noch etwas übrig, darf die Batterie mit dem Laden warten. Der Strom geht in der Zwischenzeit ins Netz. Sobald es knapp wird, spätestens aber um 13:00, wird das Laden der Batterie gestartet.
Was das bringt:
- Die Batterie ist nicht schon vormittags voll und kann die Mittagsspitze aufnehmen. Das entlastet das Netz und hilft, wenn der Netzbetreiber die Einspeiseleistung begrenzt.
- Die Batterie verbringt weniger Stunden bei 100 %, was ihrer Lebensdauer guttut.
- Es geht keine Kilowattstunde verloren: Sie wird nur zu einer anderen Uhrzeit eingespeist.
Wichtig ist, was die Steuerung nicht tut. Sie begrenzt nur das Laden. Das Entladen bleibt unverändert, die Batterie versorgt das Haus also weiter, wenn die PV nicht reicht. Die untere Grenze ist dabei immer das Minimum, das im Batteriemanagement des GEN24 eingestellt ist.
Meine Anlage
| Komponente | Daten |
|---|---|
| Wechselrichter | Fronius GEN24 mit Fronius Smart Meter |
| Batterie | BYD, 22,1 kWh |
| PV | 13,9 kWp, ein Dach, Azimut 70°, Neigung 5° |
| Wallbox (optional) | Fronius Wattpilot, in der App mit dem GEN24 gekoppelt |
| Home Assistant | HA Green im selben LAN |
Die Anleitung funktioniert genauso für andere Anlagengrößen. Angepasst werden müssen nur die Batteriekapazität und die Daten für die PV-Prognose.
Voraussetzungen
- Fronius GEN24 mit angeschlossener Batterie, Zugriff auf die Weboberfläche als Techniker oder Kunde mit Modbus-Rechten
- Home Assistant mit Zugriff auf die
configuration.yaml - HACS mit den Integrationen
SunSpec(von CJNE) und für das Dashboardpower-flow-card-plus - Die eingebaute Integration
Forecast.Solar - Alle verwendeten Geräte haben eine fix zugeordnete IP (bei mir werden diese über einen DHCP-Server am Router verwaltet)
Ein Hinweis vorab: Die Skripte schreiben direkt in Register des Wechselrichters. Ich habe sie an meinem GEN24 getestet. Bevor du schreibst, prüfe unbedingt, ob das Lese-Register für den Ladestand denselben Wert zeigt wie die Fronius-App (Schritt 4). Stimmt das nicht, liegen die Register bei dir woanders und du solltest nichts schreiben.
Anmerkung: Ich habe mich für die Modbus-Schnittstelle entschieden, da ich so direkt über mein lokales Netzwerk auf den Wechselrichter zugreifen kann.
Schritt 1: Modbus am GEN24 einschalten
In der Weboberfläche des GEN24 unter Kommunikation, Modbus:
- Modbus-Server über TCP: an, Port 502
- SunSpec Model Type:
int + SF - Zähleradresse: 200
- Wechselrichter-Steuerung über Modbus: an
Der letzte Punkt ist die Voraussetzung dafür, dass Home Assistant die Ladeleistung begrenzen darf.
Schritt 2: Werte in Home Assistant holen
Für die Anzeige nutze ich die SunSpec-Integration. Unter Einstellungen, Geräte & Dienste, SunSpec, Eintrag hinzufügen:
- Host: IP des GEN24, Port 502, Unit ID 1
- Read models:
103,160,124(Wechselrichter, MPPT, Speicher) - Ein zweiter Eintrag mit Unit ID 200 liefert den Smart Meter (Modell 203).
Achtung: Wer später im Optionen-Dialog etwas ändert, etwa das Abfrageintervall, muss dort die Read models erneut prüfen. Bei mir war danach Modell 124 abgewählt und der Ladestand fehlte.
Danach benenne ich die Entitäten so um, dass die IDs sprechend sind (Entität öffnen, Zahnrad, Entitäts-ID):
| Neue Entitäts-ID | Quelle in SunSpec |
|---|---|
sensor.pv_leistung |
Summe der MPPT-Module 0 und 1 (Template) |
sensor.batterie_laden |
MPPT module 2 DC Power |
sensor.batterie_entladen |
MPPT module 3 DC Power |
sensor.byd_ladezustand |
Storage ChaState (Ladezustand in
%) |
sensor.netz_leistung |
Zähler: AC Meter Watts |
SunSpec zählt die MPPT-Module ab 0. Module 0 und 1 sind die beiden PV-Strings, Module 2 und 3 die Batterie. Nicht verwechseln: ChaState ist der Ladezustand in Prozent, ChaSt nur der Ladestatus als Zahl.
Schritt 3: Modbus-Hub für die Steuerung
Zum Schreiben braucht Home Assistant die eingebaute Modbus-Integration. Der folgende Block kommt in die configuration.yaml. Gibt es dort schon einen modbus:-Schlüssel, wird nur der Teil ab - name: darunter angehängt.
modbus:
- name: gen24
type: tcp
host: 192.168.1.80 # lokale IP deines GEN24
port: 502
sensors:
- name: GEN24 Speicher Ladestand Modbus
slave: 1
address: 40351
input_type: holding
data_type: uint16
scale: 0.01
precision: 1
unit_of_measurement: "%"
scan_interval: 30
- name: GEN24 Speicher Steuermodus
slave: 1
address: 40348
input_type: holding
data_type: uint16
scan_interval: 30
- name: GEN24 Speicher Ladeleistung Limit
slave: 1
address: 40356
input_type: holding
data_type: int16
scale: 0.01
precision: 0
unit_of_measurement: "%"
scan_interval: 30
- name: GEN24 Speicher Rueckfallzeit
slave: 1
address: 40358
input_type: holding
data_type: uint16
unit_of_measurement: "s"
scan_interval: 30
Die vier Register stammen aus dem SunSpec-Speichermodell 124:
| Register | Name | Bedeutung |
|---|---|---|
| 40348 | StorCtl_Mod |
0 = normal, 1 = Ladeleistung begrenzen |
| 40351 | ChaState |
Ladezustand in % (nur lesen, zur Kontrolle) |
| 40356 | InWRte |
erlaubte Ladeleistung in 0,01 % (10000 = 100 %) |
| 40358 | InOutWRte_RvrtTms |
Rückfallzeit in Sekunden |
Die Rückfallzeit ist das Sicherheitsnetz: Hört der GEN24 eine Stunde lang nichts mehr von Home Assistant, kehrt er von selbst in den Normalbetrieb zurück.
Nach dem Speichern die Konfiguration prüfen und Home Assistant neu starten. Modbus-Änderungen brauchen einen Neustart.
Schritt 4: Register prüfen
Bevor irgendetwas geschrieben wird, vergleiche in den Entwicklerwerkzeugen (HA Einstellungen - Werkzeuge - Zustände):
sensor.gen24_speicher_ladestand_modbusmuss denselben Wert zeigen wiesensor.byd_ladezustandund die Fronius-App.sensor.gen24_speicher_steuermodussollte 0 sein.sensor.gen24_speicher_ladeleistung_limitsollte 100 % zeigen.
Erst wenn das passt, geht es weiter.
Schritt 5: PV-Prognose mit Forecast.Solar
Einstellungen, Geräte & Dienste, Integration hinzufügen, Forecast.Solar. Pro Dachfläche ein Eintrag mit Breite, Länge, Neigung, Azimut und Modulleistung. Liegen zwei Dachflächen in verschiedene Richtungen, werden es zwei Einträge.
Von jedem Eintrag brauche ich nur eine Entität: "Geschätzte verbleibende Energieproduktion heute". Ich benenne sie nach dem Schema sensor.prognose_rest_<dach> um, bei mir also sensor.prognose_rest_dach. Der folgende Template-Sensor summiert automatisch alle Entitäten mit diesem Präfix.
Schritt 6: Der Prognose-Überschuss
Das Herzstück ist ein Template-Sensor, der ausrechnet, wie viel Energie heute übrig bleibt, wenn Haus und Batterie versorgt sind:
Überschuss = Restprognose × Sicherheit
− Grundlast × Stunden bis Sonnenuntergang
− (100 % − Ladezustand) × Kapazität ÷ Wirkungsgrad
Der Block kommt unter den bestehenden template:-Schlüssel. Wichtig: Es darf in der configuration.yaml nur einen template:-Schlüssel geben. Gibt es zwei, gewinnt der letzte und die Sensoren des ersten verschwinden kommentarlos.
template:
- sensor:
- name: "PV Prognose Rest"
unique_id: pv_prognose_rest
unit_of_measurement: "kWh"
device_class: energy
availability: >
{{ states.sensor
| selectattr('entity_id', 'match',
'sensor\.prognose_rest_')
| selectattr('state', 'is_number')
| list | count > 0 }}
state: >
{{ states.sensor
| selectattr('entity_id', 'match',
'sensor\.prognose_rest_')
| map(attribute='state') | map('float', 0)
| sum | round(1) }}
- name: "PV Prognose Ueberschuss"
unique_id: pv_prognose_ueberschuss
unit_of_measurement: "kWh"
availability: >
{{ has_value('sensor.byd_ladezustand')
and has_value('sensor.pv_prognose_rest') }}
state: >
{% set kapazitaet = 22.1 %}
{% set wirkungsgrad = 0.95 %}
{% set sicherheit = 0.7 %}
{% set grundlast_kw = 0.5 %}
{% set soc =
states('sensor.byd_ladezustand') | float %}
{% set rest =
states('sensor.pv_prognose_rest') | float %}
{% set sunset =
state_attr('sun.sun', 'next_setting') %}
{% if is_state('sun.sun', 'above_horizon')
and sunset %}
{% set sek = as_timestamp(sunset)
- as_timestamp(now()) %}
{% set stunden = [sek / 3600, 0] | max %}
{% else %}
{% set stunden = 0 %}
{% endif %}
{% set fehlend = (100 - soc) / 100
* kapazitaet / wirkungsgrad %}
{% set verbrauch = grundlast_kw * stunden %}
{{ (rest * sicherheit - verbrauch - fehlend)
| round(1) }}
Die vier Stellschrauben oben im Template:
| Wert | Bei mir | Bedeutung |
|---|---|---|
kapazitaet |
22,1 kWh | nutzbare Kapazität der Batterie |
wirkungsgrad |
0,95 | Ladeverluste: für 1 kWh in der Batterie braucht es 1,05 kWh PV |
sicherheit |
0,7 | es werden nur 70 % der Prognose geglaubt |
grundlast_kw |
0,5 kW | durchschnittlicher Hausverbrauch tagsüber |
Der Sicherheitsfaktor ist bewusst vorsichtig. Prognosen liegen an wechselhaften Tagen gern daneben, und eine Batterie, die abends nicht voll ist, ärgert mehr als eine, die eine Stunde zu früh lädt.
Danach Entwicklerwerkzeuge, YAML, Template-Entitäten neu laden.
Schritt 7: Zwei Skripte zum Pausieren und Freigeben
Einstellungen, Automationen & Szenen, Skripte, Skript erstellen, drei Punkte, In YAML bearbeiten. Zwei Skripte anlegen:
alias: Batterieladung pausieren
sequence:
- action: modbus.write_register
data:
hub: gen24
slave: 1
address: 40358 # Rückfallzeit 1 Stunde
value: 3600
- action: modbus.write_register
data:
hub: gen24
slave: 1
address: 40356 # Ladeleistung 0 %
value: 0
- action: modbus.write_register
data:
hub: gen24
slave: 1
address: 40348 # Begrenzung aktivieren
value: 1
mode: single
alias: Batterieladung freigeben
sequence:
- action: modbus.write_register
data:
hub: gen24
slave: 1
address: 40348 # Normalbetrieb
value: 0
- action: modbus.write_register
data:
hub: gen24
slave: 1
address: 40356 # Ladeleistung 100 %
value: 10000
- action: modbus.write_register
data:
hub: gen24
slave: 1
address: 40358 # Rückfallzeit aus
value: 0
mode: single
Die Reihenfolge ist Absicht: Beim Pausieren wird zuerst die Rückfallzeit gesetzt, damit die Sperre nie ohne Sicherheitsnetz aktiv ist. Beim Freigeben wird zuerst der Steuermodus zurückgesetzt.
Testen am besten bei Sonne: "pausieren" ausführen, die Ladeleistung der Batterie fällt auf 0 und der Steuermodus zeigt 1. "freigeben" ausführen, die Batterie lädt wieder und der Steuermodus zeigt 0.
Ein Stolperstein: Neuere HA-Versionen schlagen in der Doku teils device_address statt slave vor. Bei modbus.write_register hat meine Installation das abgelehnt, mit slave funktioniert es.
Schritt 8: Schalter und Automation
Zuerst unter Einstellungen, Geräte & Dienste, Helfer einen Schalter "Batteriesteuerung aktiv" anlegen (input_boolean.batteriesteuerung_aktiv). Damit lässt sich die Steuerung jederzeit abschalten.
Dann die Automation. Sie kennt zwei Arten von Auslösern: die Prüfung alle 15 Minuten und eine Reihe von Ereignissen, bei denen immer freigegeben wird.
alias: Batteriesteuerung nach Prognose
description: >-
Pausiert die Batterieladung vormittags, solange die
PV-Prognose reicht, um Haus zu versorgen und die
Batterie trotzdem vollzuladen. Gibt spätestens um
13:00, bei Sonnenuntergang, nach HA-Neustart und
beim Ausschalten wieder frei.
mode: single
triggers:
- trigger: time_pattern
minutes: "/15"
id: pruefen
- trigger: homeassistant
event: start
id: freigeben
- trigger: time
at: "13:00:00"
id: freigeben
- trigger: sun
event: sunset
id: freigeben
- trigger: state
entity_id: input_boolean.batteriesteuerung_aktiv
to: "off"
id: freigeben
actions:
- choose:
- conditions:
- condition: trigger
id: pruefen
- condition: state
entity_id: input_boolean.batteriesteuerung_aktiv
state: "on"
- condition: sun
after: sunrise
- condition: time
before: "13:00:00"
- condition: template
value_template: >
{% set u = states(
'sensor.pv_prognose_ueberschuss')
| float(-99) %}
{% set pausiert = states(
'sensor.gen24_speicher_steuermodus')
| int(0) == 1 %}
{{ u > 2 or (pausiert and u > 1) }}
# Optional, nur mit Wallbox:
# nicht pausieren, solange das Auto lädt
- condition: template
value_template: >
{% set w = 'sensor.wallbox_leistung' %}
{% set p = states(w) | float(0) %}
{% set e = state_attr(w,
'unit_of_measurement') %}
{{ (p * 1000 if e == 'kW' else p) < 100 }}
sequence:
- action: script.batterieladung_pausieren
- conditions:
- condition: trigger
id: freigeben
sequence:
- action: script.batterieladung_freigeben
default:
- if:
- condition: template
value_template: >
{{ states('sensor.gen24_speicher_steuermodus')
| int(1) != 0 }}
then:
- action: script.batterieladung_freigeben
Wer keine Wallbox hat, löscht die zweite Template-Bedingung samt Kommentar.
Den Schalter erst einschalten, wenn der Überschuss-Sensor plausible Werte zeigt.
Die Regeln auf einen Blick
Pausiert wird nur, wenn alle vier Bedingungen erfüllt sind. Trifft bei der 15-Minuten-Prüfung eine nicht mehr zu und läuft gerade eine Pause, gibt der default-Zweig die Ladung frei. Zusätzlich gibt es feste Freigaben um 13:00, bei Sonnenuntergang, nach einem Neustart von Home Assistant und beim Ausschalten des Schalters.
Zwei Details verdienen eine Erklärung:
- Hysterese: Eine neue Pause beginnt erst ab 2 kWh Überschuss, eine laufende Pause wird aber bis 1 kWh gehalten. Ohne diesen Abstand würde die Steuerung bei einem Wert um 2 kWh im Viertelstundentakt hin und her schalten.
- Erneuern: Jede Prüfung, die die Pause bestätigt, schreibt die Rückfallzeit von einer Stunde neu. Solange Home Assistant läuft, läuft die Pause also weiter. Fällt es aus, ist nach spätestens einer Stunde wieder Normalbetrieb.
Rechenbeispiele
Am besten versteht man die Steuerung an konkreten Zahlen. Alle Beispiele nutzen meine Werte: 22,1 kWh Kapazität, Wirkungsgrad 0,95, Sicherheit 0,7 und Grundlast 0,5 kW.
Eine Faustregel vorweg: Jedes Prozent Ladezustand entspricht 0,221 kWh in der Batterie oder 0,233 kWh PV-Energie, um es nachzuladen.
Beispiel 1: Sonniger Morgen, Batterie halb leer
Ein echter Wert von meinem Dashboard, um 08:56 an einem sonnigen Oktobertag. Die Batterie steht bei 32 %, Forecast.Solar erwartet noch 44,5 kWh, Sonnenuntergang ist um etwa 18:32.
| Schritt | Rechnung | kWh |
|---|---|---|
| Glaubwürdige Prognose | 44,5 × 0,7 | 31,15 |
| Hausverbrauch bis Sonnenuntergang | 0,5 kW × 9,6 h | − 4,80 |
| Bis zur vollen Batterie | 68 % × 22,1 ÷ 0,95 | − 15,82 |
| Prognose-Überschuss | = 10,53 |
10,5 kWh sind deutlich über 2 kWh, die Ladung wird pausiert. Die PV deckte zu diesem Zeitpunkt mit 3,7 kW den Hausverbrauch von 3,3 kW, die Batterie stand still, 431 W gingen ins Netz.
Beispiel 2: Bewölkter Tag
Gleiche Uhrzeit, aber nur 18 kWh Prognose, Batterie bei 40 %:
| Schritt | Rechnung | kWh |
|---|---|---|
| Glaubwürdige Prognose | 18 × 0,7 | 12,60 |
| Hausverbrauch bis Sonnenuntergang | 0,5 kW × 9,6 h | − 4,80 |
| Bis zur vollen Batterie | 60 % × 22,1 ÷ 0,95 | − 13,96 |
| Prognose-Überschuss | = −6,16 |
Negativ heißt: Die Sonne reicht heute voraussichtlich nicht einmal für eine volle Batterie. Es wird nicht pausiert, die Batterie lädt wie gewohnt ab der ersten Kilowattstunde.
Beispiel 3: Batterie fast voll
Die Batterie steht morgens noch bei 95 %, weil es in der Nacht kaum Verbrauch gab. Die Prognose ist mit 12 kWh nur mäßig:
| Schritt | Rechnung | kWh |
|---|---|---|
| Glaubwürdige Prognose | 12 × 0,7 | 8,40 |
| Hausverbrauch bis Sonnenuntergang | 0,5 kW × 9,6 h | − 4,80 |
| Bis zur vollen Batterie | 5 % × 22,1 ÷ 0,95 | − 1,16 |
| Prognose-Überschuss | = 2,44 |
Auch an einem mittelmäßigen Tag wird pausiert, weil der Batterie nur noch gut eine Kilowattstunde fehlt. Die holt sie sich am Nachmittag.
Beispiel 4: Wie viel Prognose braucht eine Pause?
Die Rechnung lässt sich auch umdrehen. Damit um 09:00 bei 32 % Ladezustand pausiert wird, muss der Überschuss über 2 kWh liegen:
Restprognose > (2 + 4,75 + 15,82) ÷ 0,7 = 32,2 kWh
Bei einer leeren Batterie braucht es also einen richtig guten Tag. Jedes Prozent weniger Ladezustand erhöht die nötige Prognose um etwa 0,33 kWh. Darum entlädt sich die Batterie während einer Pause auch nie nennenswert: Sinkt der Ladestand, steigt der Fehlbetrag, der Überschuss schrumpft, und unter 1 kWh wird freigegeben.
Beispiel 5: Die Freigabe im Laufe des Vormittags
Während der Pause fallen zwei Dinge: Die Restprognose sinkt, weil die Sonne ja schon scheint und die Energie ins Netz geht, und die Zeit bis Sonnenuntergang wird kürzer. Der erste Effekt ist stärker, darum schrumpft der Überschuss bis zum Mittag. Auf dem simulierten Beispieltag weiter unten sieht das so aus:
| Uhrzeit | Rest | Ladezustand | Rechnung | Überschuss | Entscheidung |
|---|---|---|---|---|---|
| 09:00 | 45,2 | 24,6 % | 31,64 − 4,75 − 17,54 | 9,3 | Pause |
| 11:45 | 32,8 | 24,6 % | 22,96 − 3,38 − 17,54 | 2,0 | Pause halten (> 1) |
| 12:00 | 31,0 | 24,6 % | 21,70 − 3,25 − 17,54 | 0,9 | Freigabe |
Um 11:45 würde eine neue Pause nicht mehr starten (nicht über 2 kWh), die laufende wird aber noch gehalten. Um 12:00 fällt der Wert unter 1 kWh und die Batterie lädt los. Das ist genau der Moment, in dem die verbleibende Sonne gerade noch für eine volle Batterie reicht, mit 30 % Reserve.
Beispiel 6: Das Auto lädt
Meine Wallbox ist mit dem Wechselrichter gekoppelt und lädt das Auto mit PV-Überschuss. Würde die Batterie pausieren, während das Auto lädt, könnte das Auto auch den Nachmittag verbrauchen und die Batterie würde nicht voll. Darum gilt: Zieht die Wallbox mehr als 100 W, wird nicht pausiert. Fängt das Auto während einer Pause an zu laden, gibt die nächste Prüfung frei.
Ein simulierter Sonnentag
Um den Effekt zu zeigen, habe ich einen sonnigen Tag mit 46 kWh PV durchgerechnet, einmal ohne und einmal mit Steuerung. Die Automation ist dabei exakt nachgebildet, die Prognose ist der Einfachheit halber perfekt.
| Kennzahl | ohne Steuerung | mit Steuerung |
|---|---|---|
| Batterie voll um | 12:45 | 14:30 |
| Höchste Einspeisung | 7,5 kW | 6,0 kW |
| Einspeisung gesamt | 21,9 kWh | 21,9 kWh |
| Ladezustand am Abend (19:30) | 89 % | 89 % |
Die Energiemenge ist gleich, nur die Uhrzeit verschiebt sich. Ohne Steuerung landet die volle Mittagsspitze im Netz, mit Steuerung fängt die Batterie sie ab. Vormittags, wenn die Leistung noch niedrig ist, geht der Strom dafür ins Netz.
Nach der Freigabe steigt der Überschuss wieder, weil die Batterie schnell voller wird. Eine neue Pause gibt es trotzdem nicht: Bis 13:00 bleibt der Wert unter 2 kWh, danach ist ohnehin Schluss.
Schritt 9: Das Dashboard
Damit man sieht, was die Steuerung gerade tut, habe ich ein Dashboard mit Energiefluss, Verläufen und einem Abschnitt für die Steuerung. Neues Dashboard anlegen, Raw-Konfigurationseditor öffnen und einfügen. Der Energiefluss braucht power-flow-card-plus aus HACS. Ohne Wallbox fällt der Block individual weg.
views:
- title: PV LIVE
path: pv
type: sections
max_columns: 4
sections:
- type: grid
column_span: 4
cards:
- type: heading
heading: Live
icon: mdi:solar-power-variant
- type: custom:power-flow-card-plus
grid_options:
columns: full
entities:
battery:
entity:
consumption: sensor.batterie_entladen
production: sensor.batterie_laden
state_of_charge: sensor.byd_ladezustand
grid:
entity: sensor.netz_leistung
solar:
entity: sensor.pv_leistung
display_zero_state: true
individual:
- entity: sensor.wallbox_leistung
name: Wallbox
icon: mdi:car-electric
display_zero: true
clickable_entities: true
display_zero_lines: true
use_new_flow_rate_model: true
kilo_decimals: 1
max_expected_power: 15000
min_expected_power: 0.01
- type: grid
column_span: 4
cards:
- type: heading
heading: Verlauf 24 h
icon: mdi:chart-line
- type: horizontal-stack
grid_options:
columns: full
cards:
- type: history-graph
title: PV-Leistung
hours_to_show: 24
entities:
- entity: sensor.pv_leistung
name: PV gesamt
- type: history-graph
title: Netz
hours_to_show: 24
entities:
- entity: sensor.netz_leistung
name: Bezug (+) / Einspeisung (−)
- type: history-graph
title: Batterie-Ladezustand
hours_to_show: 24
entities:
- entity: sensor.byd_ladezustand
name: BYD
- type: history-graph
title: Prognose-Überschuss
hours_to_show: 24
entities:
- entity: sensor.pv_prognose_ueberschuss
name: Überschuss
- type: grid
column_span: 4
cards:
- type: heading
heading: Batteriesteuerung
icon: mdi:battery-sync
- type: tile
entity: input_boolean.batteriesteuerung_aktiv
name: Steuerung nach Prognose
icon: mdi:weather-sunny-alert
color: amber
icon_tap_action:
action: toggle
- type: markdown
content: >
{% set modus = states(
'sensor.gen24_speicher_steuermodus') %}
{% set wb = states('sensor.wallbox_leistung') %}
{% if modus | int(0) == 1 %}
### ⏸️ Ladung pausiert
PV-Überschuss geht ins Netz,
Freigabe spätestens 13:00
{% elif wb | float(0) > 0.1 %}
### 🚗 Auto lädt
Keine Ladepause, Batterie und Wallbox
teilen sich den Überschuss
{% else %}
### 🔋 Ladung frei
Batterie lädt normal
{% endif %}
- type: tile
entity: sensor.pv_prognose_ueberschuss
name: Prognose-Überschuss
icon: mdi:chart-bell-curve-cumulative
color: blue
- type: tile
entity: sensor.pv_prognose_rest
name: Restproduktion heute
icon: mdi:solar-power
color: amber
Das Bild am Anfang des Artikels zeigt das Ergebnis mit Demo-Daten um 10:00: Die PV liefert 4,0 kW, das Haus braucht 0,5 kW, 3,5 kW gehen ins Netz, die Batterie steht bei 25 % still und wartet.
Erfahrungen nach den ersten Tagen
Am ersten sonnigen Tag hat die Steuerung um 09:00 pausiert. Um 11:00 hat Forecast.Solar die Prognose von 27 auf 14 kWh gesenkt, worauf sofort freigegeben wurde. Um 12:45 gab es noch eine kurze Pause, um 13:00 die feste Freigabe. Um 15:00 war die Batterie voll. Genau so soll es sein: Die Steuerung reagiert, wenn die Prognose schlechter wird, und der Sicherheitsfaktor sorgt dafür, dass es trotzdem reicht.
Drei Dinge, über die ich gestolpert bin:
- Wenn SunSpec und der Modbus-Hub gleichzeitig abfragen, sind manche Werte kurz "nicht verfügbar". Ein Abfrageintervall von 60 Sekunden in der SunSpec-Integration hat das beruhigt.
- Nach jeder Änderung im SunSpec-Optionen-Dialog die Read models prüfen, sonst fehlt der Ladezustand und der Überschuss-Sensor ist nicht verfügbar.
- Ein zweiter
template:-Schlüssel in derconfiguration.yamllässt die Sensoren aus dem ersten still verschwinden.
Wer die Steuerung nachbaut, sollte die ersten Tage den Verlauf von sensor.gen24_speicher_steuermodus neben den Ladezustand legen. Dort sieht man sofort, wann pausiert und wann freigegeben wurde, und kann Sicherheitsfaktor oder Grundlast an das eigene Haus anpassen.