PV-Speicher erst mittags laden: Home Assistant Automation mit Solcast
Ein PV-Speicher ist eigentlich eine ziemlich einfache Sache: Tagsüber wird er mit Solarstrom geladen, abends und nachts versorgt er das Haus. In der Praxis ist das aber nicht immer optimal. Denn wenn der Speicher schon vormittags voll ist, landet der starke PV-Peak am Mittag oder Nachmittag komplett im Netz.
Genau das wollte ich bei meiner Anlage ändern. Auf eines meiner Videos hat sich dazu Simon aus meiner Community gemeldet und mir ein geniales Skript zur Verfügung gestellt, dass ich euch hier zeigen möchte.
Die Idee: Der Speicher soll nicht sofort mit den ersten Sonnenstrahlen vollgeladen werden. Stattdessen soll Home Assistant anhand der Solcast-Prognose berechnen, wann der beste Zeitpunkt zum Laden ist. Der Akku wird morgens zunächst gebremst und erst zur berechneten Startzeit wieder freigegeben.
Das Ziel ist nicht maximale Komplexität, sondern eine einfache, nachvollziehbare Logik:
Morgens Speicherladung stoppen, PV-Prognose auswerten, zum passenden Zeitpunkt wieder freigeben.
Im Video zeige ich die Einrichtung Schritt für Schritt direkt in Home Assistant. Dieser Artikel ergänzt das Video und enthält die Codeblöcke zum Kopieren.
Warum den Speicher überhaupt verzögert laden?
Viele PV-Speicher laden nach einem einfachen Prinzip: Sobald PV-Überschuss vorhanden ist, wird der Akku geladen. Das funktioniert zuverlässig, führt aber an guten Sonnentagen zu einem typischen Effekt.
Der Speicher ist schon am Vormittag voll. Danach produziert die PV-Anlage mittags oder nachmittags besonders viel Strom. Dieser Strom kann dann nicht mehr in den Akku und wird eingespeist.
Das ist nicht grundsätzlich falsch. Aber es kann je nach Anlage, Tarif und persönlichem Ziel sinnvoll sein, den Speicher etwas später zu laden.
Bei mir geht es vor allem um drei Dinge:
Erstens möchte ich die hohen PV-Leistungen des Tages besser nutzen. Zweitens will ich vermeiden, dass der Speicher schon früh voll ist und der stärkste Teil der Tagesproduktion nicht mehr in die Batterie passt. Drittens interessiert mich das Thema Netzdienlichkeit: Wenn sehr viele PV-Anlagen gleichzeitig mittags einspeisen, ist es zumindest ein sinnvoller Gedanke, den eigenen Speicher nicht schon vorher vollzumachen.
Wichtig: Diese Automation macht aus dem Speicher kein perfektes Energiemanagementsystem. Sie ist eher ein pragmatischer Eingriff in die tägliche Speicherladung.
Die Grundidee der Automation
Die Lösung besteht aus vier Teilen:
- Ein Template-Sensor berechnet die passende Speicher-Lade-Startzeit.
- Eine Automation sperrt morgens die Speicherladung.
- Eine Automation gibt die Speicherladung zur berechneten Startzeit wieder frei.
- Eine dritte Automation gibt die Speicherladung wieder frei, wenn der Schalter für verzögertes Laden deaktiviert wird.
Zusätzlich gibt es einen Helfer-Schalter in Home Assistant. Damit kann ich die Funktion jederzeit aktivieren oder deaktivieren.
Bei mir heißt dieser Schalter:
input_boolean.batterie_erst_mittags_laden
Wenn der Schalter aus ist, läuft die Anlage normal. Wenn der Schalter an ist, greift die Automation ein.
Was Solcast dafür liefert
Die Grundlage ist die PV-Prognose von Solcast. Solcast liefert nicht nur eine Tagesprognose, sondern auch Prognosewerte für einzelne Zeitabschnitte. In meinem Fall sind das 30-Minuten-Slots.
Ein Slot sieht vereinfacht so aus:
period_start: "2026-07-01T14:00:00+02:00"
pv_estimate: 7.4
Das bedeutet: Für diesen Zeitraum erwartet Solcast eine PV-Leistung von ungefähr 7,4 kW.
Der Template-Sensor nimmt diese Slots und sortiert sie nach der höchsten prognostizierten PV-Leistung. Dann rechnet er aus, wie viele dieser starken Slots benötigt werden, um den Speicher bis zum Zielwert zu laden.
Das klingt erstmal etwas abstrakt, deshalb zeige ich das im Video ausführlicher mit einer Animation. Entscheidend ist: Die Automation sucht nicht einfach eine feste Uhrzeit wie „ab 12 Uhr laden“, sondern berechnet die Startzeit jeden Tag neu aus Prognose und aktuellem Speicherstand.
Wie die Startzeit berechnet wird
Der Sensor fragt zuerst den aktuellen Ladezustand des Speichers ab. Bei mir kommt dieser Wert aus dem SolarEdge-Sensor:
sensor.solaredge25_battery_state_of_energy
Dann wird berechnet, wie viel Energie bis zum Ziel-Ladestand fehlt.
Beispiel:
Der Speicher hat 9,2 kWh Kapazität. Er steht morgens bei 50 Prozent. Ziel sind 98 Prozent.
Dann fehlen grob:
9,2 kWh × 48 Prozent = 4,4 kWh
Zusätzlich berücksichtigt der Code einen Lade-Wirkungsgrad. Denn nicht jede Kilowattstunde, die aus der PV-Erzeugung Richtung Speicher geht, landet verlustfrei in der Batterie.
Danach werden die Solcast-Slots nach Leistung sortiert. Die stärksten Slots werden so lange aufaddiert, bis genug Energie zusammenkommt. Aus diesen ausgewählten Slots wird anschließend der früheste Zeitpunkt genommen. Das ist dann die berechnete Startzeit.
Wenn also zum Beispiel fünf gute Slots rund um den PV-Peak benötigt werden und diese zeitlich von 11:30 bis 13:30 Uhr liegen, dann wird 11:30 Uhr als Startzeit zurückgegeben.
Warum die Slots erst nach Leistung und dann nach Zeit sortiert werden
Das ist der wichtigste Denkpunkt an der ganzen Logik.
Die erste Sortierung beantwortet diese Frage:
Welche Zeitfenster sind heute die besten zum Laden?
Die zweite Sortierung beantwortet danach:
Wann muss ich anfangen, damit ich diese besten Zeitfenster vollständig mitnehme?
Dadurch kann die Startzeit je nach Wetter, Speicherstand und Prognose jeden Tag anders liegen.
In meinem Video zeige ich diese Sortierung anhand einer Tabelle mit 30-Minuten-Slots, damit die Logik nachvollziehbar wird.
Welche Werte müssen angepasst werden?
Die Codeblöcke unten sind auf meine Anlage bezogen. Andere Nutzer müssen daher ein paar Werte anpassen.
Zwingend angepasst werden müssen:
- der Sensor für den Batterie-Ladezustand
- der Solcast-Prognosesensor
- die Speicherkapazität
- die maximale Ladeleistung des Speichers
- die Steuer-Entity, mit der die Ladeleistung begrenzt wird
Bei mir sind das zum Beispiel:
sensor.solaredge25_battery_state_of_energy
für den Speicher-Ladezustand und:
sensor.solcast_pv_forecast_prognose_heute
für die Solcast-Prognose.
Bei anderen Wechselrichtern und Integrationen heißen diese Entitäten natürlich anders.
Auch die Hardwarewerte müssen angepasst werden. Bei mir sind es:
- Speicherkapazität: 9,2 kWh
- maximale Ladeleistung: 5,0 kW
- Ziel-Ladestand: 98 Prozent
- angenommene Grundlast: 0,4 kW
- Lade-Wirkungsgrad: 0,92
Die Grundlast ist dabei ein Schätzwert. Sie wird von der PV-Prognose abgezogen, weil ein Teil der PV-Leistung ja direkt im Haus verbraucht wird und nicht für den Speicher zur Verfügung steht.
Code 1: Template-Sensor für die Speicher-Lade-Startzeit
Der erste Codeblock kommt in die configuration.yaml oder in die entsprechende Template-Datei, falls Home Assistant bei euch aufgeteilt ist.
Wichtig: Wenn es bereits einen template:-Block gibt, darf dieser nicht einfach doppelt angelegt werden. Dann muss der Sensor in den bestehenden Block integriert werden.
- name: "Speicher Peak-Lade-Startzeit"
unique_id: speicher_peak_lade_startzeit
device_class: timestamp
state: >
{% set soc = states('sensor.solaredge25_battery_state_of_energy') | float(0) %}
{# --- DEINE HARDWARE-WERTE --- #}
{% set cap = 9.2 %}
{% set target_soc = 98 %}
{% set base_load = 0.4 %}
{% set max_charge_power = 5.0 %}
{% set charge_efficiency = 0.92 %}
{# ---------------------------- #}
{% set e_needed = (cap * ([target_soc - soc, 0] | max) / 100) / charge_efficiency %}
{% set forecasts = state_attr('sensor.solcast_pv_forecast_prognose_heute', 'detailedForecast') %}
{% if forecasts and e_needed > 0 %}
{% set sorted_slots = forecasts | sort(attribute='pv_estimate', reverse=true) %}
{% set ns = namespace(accumulated_energy=0, peak_periods=[]) %}
{% for slot in sorted_slots %}
{% set start = as_datetime(slot.period_start) %}
{% if start is not none and (as_timestamp(start) + 1800) > as_timestamp(now()) and ns.accumulated_energy < e_needed %}
{% set pv = slot.pv_estimate | float(0) %}
{% set net_pv = [pv - base_load, 0] | max %}
{% set charge_power = [net_pv, max_charge_power] | min %}
{% set energy_in_slot = charge_power * 0.5 %}
{% if energy_in_slot > 0 %}
{% set ns.accumulated_energy = ns.accumulated_energy + energy_in_slot %}
{% set ns.peak_periods = ns.peak_periods + [start] %}
{% endif %}
{% endif %}
{% endfor %}
{% if ns.peak_periods | length > 0 %}
{{ (ns.peak_periods | sort | first).isoformat() }}
{% else %}
{{ today_at("06:00").isoformat() }}
{% endif %}
{% elif soc >= target_soc %}
{{ tomorrow_at("23:59").isoformat() }}
{% else %}
{{ today_at("06:00").isoformat() }}
{% endif %}
Nach dem Einfügen sollte die Konfiguration geprüft und die Template-Entitäten neu geladen werden. Alternativ kann Home Assistant neu gestartet werden.
Danach sollte ein neuer Sensor vorhanden sein:
sensor.speicher_peak_lade_startzeit
Dieser Sensor gibt einen Zeitstempel aus, also zum Beispiel:
2026-07-01T13:30:00+02:00
Das ist die berechnete Uhrzeit, ab der die Speicherladung wieder freigegeben werden soll.
Code 2: Automation zum Sperren der Speicherladung am Morgen
Die erste Automation setzt morgens kurz vor Sonnenaufgang die Speicher-Ladebegrenzung auf null.
Bei mir wird dafür diese Entity verwendet:
number.solaredge25_inverter_storage_charge_limit
Diese Entity arbeitet in Watt. Deshalb bedeutet 0: Speicherladung gesperrt. Und 5000: Speicher darf mit bis zu 5000 W laden.
Bei anderen Wechselrichtern kann das anders heißen oder auch eine andere Einheit haben. Das muss unbedingt vorher geprüft werden.
alias: "Verzögertes Laden: Morgens sperren"
description: >-
Sperrt die Batterieladung morgens, wenn Helfer-Schalter verzögertes Laden
aktiv ist.
triggers:
- trigger: sun
event: sunrise
offset: "-00:10:00"
conditions:
- condition: state
entity_id: input_boolean.batterie_erst_mittags_laden
state: "on"
actions:
- if:
- condition: numeric_state
entity_id: number.solaredge25_inverter_storage_charge_limit
above: 0
then:
- action: number.set_value
target:
entity_id: number.solaredge25_inverter_storage_charge_limit
data:
value: 0
mode: single
Diese Automation läuft nur, wenn der Helfer-Schalter aktiv ist:
input_boolean.batterie_erst_mittags_laden
Wenn der Schalter aus ist, wird morgens nichts verändert.
Code 3: Automation zum Freigeben zur berechneten Startzeit
Die zweite Automation ist der eigentliche Startpunkt für die verzögerte Speicherladung.
Sie prüft, ob die berechnete Startzeit erreicht oder überschritten wurde. Wenn ja, setzt sie die Ladebegrenzung wieder auf 5000 W.
alias: "Verzögertes Laden: Starten"
description: Gibt die Batterieladung zur berechneten Solcast-Startzeit wieder frei.
triggers:
- trigger: template
value_template: >
{% set startzeit = states('sensor.speicher_peak_lade_startzeit') |
as_datetime %} {{ startzeit is not none and now() >= startzeit }}
enabled: true
- trigger: time_pattern
minutes: /5
- trigger: homeassistant
event: start
conditions:
- condition: state
entity_id: input_boolean.batterie_erst_mittags_laden
state: "on"
- condition: template
value_template: >
{% set startzeit = states('sensor.speicher_peak_lade_startzeit') |
as_datetime %} {{ startzeit is not none and now() >= startzeit }}
- condition: numeric_state
entity_id: number.solaredge25_inverter_storage_charge_limit
below: 5000
actions:
- if:
- condition: numeric_state
entity_id: number.solaredge25_inverter_storage_charge_limit
below: 5000
then:
- action: number.set_value
target:
entity_id: number.solaredge25_inverter_storage_charge_limit
data:
value: 5000
mode: single
In dieser Automation gibt es bewusst mehrere Auslöser.
Der Template-Auslöser reagiert auf den Moment, in dem die berechnete Startzeit erreicht wird. Zusätzlich kann ein Zeitmuster sinnvoll sein, zum Beispiel alle fünf Minuten. Dadurch wird die Automation robuster, falls sich der Sensorwert verschiebt oder Home Assistant den exakten Umschaltmoment nicht sauber erwischt.
Wichtig ist aber: Durch die Bedingungen wird nicht alle fünf Minuten geschrieben. Es wird nur dann ein Schreibbefehl gesendet, wenn die Ladebegrenzung tatsächlich noch unter dem gewünschten Wert liegt.
Genau diesen Punkt erkläre ich im Video etwas ausführlicher, weil er für die Zuverlässigkeit der Automation wichtig ist.
Code 4: Automation zum Freigeben beim Ausschalten des Schalters
Die dritte Automation ist ein Ausschalter.
Wenn ich den Helfer-Schalter ausschalte, soll die Speicherladung wieder normal freigegeben werden. Sonst könnte es passieren, dass die Ladebegrenzung auf 0 stehen bleibt, obwohl die verzögerte Ladung gar nicht mehr aktiv sein soll.
alias: Verzögertes Laden deaktivieren (durch Schalter)
description: >-
Gibt die Batterieladung wieder mit maximaler Leistung frei, wenn verzögertes
Laden mittels Helferschalter ausgeschaltet wird.
triggers:
- trigger: state
entity_id: input_boolean.batterie_erst_mittags_laden
to: "off"
alias: Sobald "Batterie erst mittags laden" sich zu Aus ändert
conditions:
- condition: numeric_state
entity_id: number.solaredge25_inverter_storage_charge_limit
below: 5000
actions:
- action: number.set_value
target:
entity_id: number.solaredge25_inverter_storage_charge_limit
data:
value: 5000
mode: single
Damit kann die Funktion jederzeit sauber deaktiviert werden.
Warum ich nicht ständig nachregele
Man könnte diese Automation noch viel komplexer bauen. Zum Beispiel könnte Home Assistant die Speicher-Ladeleistung permanent dynamisch an die aktuelle PV-Erzeugung anpassen.
Ich habe mich bewusst dagegen entschieden.
Zum einen reicht mir eine einfache Tageslogik: morgens sperren, später freigeben. Zum anderen gibt es bei Modbus-Schreibzugriffen auf Wechselrichter eine technische Unsicherheit.
Es gibt Hinweise aus der SolarEdge-Welt, dass bestimmte einstellbare Modbus-Parameter für langfristige Speicherung gedacht sein könnten und häufige Schreibzugriffe theoretisch den Flash-Speicher belasten könnten. Ob und in welchem Umfang das für jede konkrete Residential-Anlage und genau diese Steuer-Entity gilt, ist nicht eindeutig belegt.
Deshalb behandle ich das Thema vorsichtig:
- Sensoren lesen ist unkritisch.
- Schreibzugriffe vermeide ich, wenn sie nicht nötig sind.
- Die Automation schreibt nur, wenn der Wert wirklich geändert werden muss.
- Es gibt keine Regelung im Sekunden- oder Minutentakt.
Für meine Anwendung heißt das: Im Normalfall gibt es nur wenige Schreibzugriffe pro Tag.
Was passiert, wenn die Prognose nicht passt?
Die Automation ist nur so gut wie die Eingangsdaten.
Wenn Solcast die PV-Erzeugung systematisch zu hoch oder zu niedrig prognostiziert, verschiebt sich auch die berechnete Startzeit. Bei einer Ost-West-Anlage ist es besonders wichtig, dass die Dachflächen korrekt in Solcast angelegt sind.
Bei mir waren dafür vor allem diese Werte wichtig:
- Ostfläche mit korrektem Azimuth
- Westfläche mit korrektem Azimuth
- echte Anzahl der Module
- richtige DC-Leistung je Dachfläche
- realistische Dachneigung
- sinnvoller Efficiency Factor
Ein typischer Fehler: West wird versehentlich mit Azimuth 180° eingetragen. Das ist aber Süd. Eine echte Westfläche liegt eher bei 270°. Bei mir ist die Westfläche mit 272° angegeben.
Wenn die Prognose nachmittags reproduzierbar zu hoch ist, sollte man also zuerst die Solcast-Konfiguration prüfen, bevor man am Home-Assistant-Code herumkorrigiert.
Auch diesen Punkt zeige ich im Video anhand meiner eigenen Prognosekurve.
Was diese Lösung kann — und was nicht
Diese Automation ist kein vollständiges Energiemanagementsystem.
Sie berücksichtigt nicht automatisch dynamische Strompreise, geplante Verbraucher, Wallbox-Ladungen oder Wetterunsicherheiten über mehrere Tage. Sie optimiert auch nicht permanent die Ladeleistung.
Was sie aber gut kann:
Sie verschiebt die Speicherladung grob in die besseren PV-Zeitfenster des Tages.
Für viele Anlagen reicht genau das schon aus, um zu verhindern, dass der Akku an sonnigen Tagen viel zu früh voll ist.
Zusammenfassung
Mit Home Assistant, Solcast und einer steuerbaren Speicher-Ladebegrenzung lässt sich eine einfache, aber wirkungsvolle Logik bauen:
Morgens wird die Speicherladung gesperrt. Ein Template-Sensor berechnet aus Speicherstand und PV-Prognose, wann genug gute PV-Zeitfenster übrig sind. Zur berechneten Startzeit wird die Speicherladung wieder freigegeben.
Die wichtigsten Anpassungen sind:
- eigener Batterie-SOC-Sensor
- eigener Solcast-Prognosesensor
- eigene Speicherkapazität
- eigene maximale Ladeleistung
- passende Steuer-Entity des Wechselrichters
Der Vorteil dieser Lösung ist, dass sie relativ einfach bleibt und trotzdem dynamisch auf den Tag reagiert. Sie lädt nicht stumpf immer ab derselben Uhrzeit, sondern abhängig von Wetterprognose und Speicherstand.
Den kompletten Aufbau und die Logik hinter den Prognose-Slots zeige ich im Video oben.


Schreibe einen Kommentar