Im Übersichtsartikel zum PV-Lastmanagement habe ich vier Bausteine beschrieben, die alle nach demselben Prinzip funktionieren: Sie reagieren auf den aktuellen PV-Überschuss. Das funktioniert gut, hat aber eine Grenze – jeder Baustein weiß immer erst im Moment selbst, ob gerade Überschuss da ist, nie vorher. Genau diese Lücke schließt der fünfte Baustein: eine Solcast-Prognose, die nicht nur auf den Ist-Zustand reagiert, sondern vorausschauend steuert.
In diesem Artikel zeige ich, wie ich die Solcast-Integration in Home Assistant eingebunden habe, wie ich die Prognose mit den bestehenden Automationen kombiniere – und warum sie die Sicherheitslogik aus den anderen Bausteinen nicht ersetzt, sondern ergänzt.
Warum reine Ist-Wert-Steuerung an ihre Grenzen stößt
Ein Beispiel aus der Praxis: Der Überschuss steigt langsam an, der Heizstab am Bad springt gerade erst in seinen Hysterese-Bereich, da zieht eine Wolkenfront auf. Der Überschuss bricht ein, bevor der Heizstab überhaupt nennenswert Wärme abgegeben hat – kurz danach schaltet er wieder ab. Für die Schaltkontakte und für die Effizienz ist das nicht ideal.
Eine Prognose löst dieses Problem nicht komplett, aber sie verändert die Ausgangslage: Wenn ich vorher weiß, dass die nächste Stunde voraussichtlich eher bewölkt wird, kann ich Verbraucher mit langer Anlaufzeit gar nicht erst anspringen lassen – oder umgekehrt, bei einer sicheren Prognose für einen sonnigen Nachmittag, das Warmwasser schon etwas früher und aggressiver hochfahren, weil ich weiß, dass genug Überschuss nachkommt.
Solcast-Integration in Home Assistant einrichten
Solcast ist ein Prognosedienst, der auf Basis von Standort, Ausrichtung, Neigung und Anlagengröße eine stündlich aufgelöste PV-Ertragsprognose liefert – für heute und die kommenden Tage. Für Privatanwender gibt es ein kostenloses Kontingent, das für den Hausgebrauch in der Regel ausreicht.
Die Einbindung in Home Assistant läuft über die Solcast PV Forecast Integration, die sich über HACS installieren lässt. Nach der Einrichtung mit API-Key und den Eckdaten der eigenen Anlage (Standort, Ausrichtung, Neigung, installierte Leistung) stehen mehrere Sensoren zur Verfügung, unter anderem:
sensor.solcast_pv_forecast_prognose_heute– die Gesamtprognose für den laufenden Tag in kWhsensor.solcast_pv_forecast_prognose_morgen– die Prognose für den Folgetag- ein Forecast-Attribut mit stündlicher Detailauflösung, aus dem sich Templates für einzelne Zeitfenster bauen lassen
Ich rufe die Prognose zweimal täglich automatisch ab (früh morgens und am Vorabend), damit sie tagsüber nicht unnötig oft aktualisiert wird und trotzdem stets aktuell genug ist.
Home Assistant selbst läuft bei mir auf einem Raspberry Pi 4. Da darüber inzwischen neben Solcast auch meine PV-, Wärmepumpen- und weiteren Smart-Home-Automationen laufen, nutze ich zusätzlich eine externe SSD statt einer dauerhaft beschriebenen microSD-Karte.
Meine Home-Assistant-Hardware: Raspberry Pi 4* · externe SSD*
* Affiliate-Link: Wenn du über einen entsprechend gekennzeichneten Link etwas kaufst, erhalte ich möglicherweise eine Provision. Für dich ändert sich der Preis dadurch nicht. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.
Die Prognose sinnvoll in bestehende Automationen einbauen
Der wichtigste Designentscheid war für mich, die Prognose nicht als alleinigen Trigger zu verwenden, sondern als zusätzliche Bedingung neben dem bestehenden Ist-Wert:
Die Prognose entscheidet, ob ein Verbraucher heute überhaupt eine Chance hat – der Ist-Wert entscheidet, wann genau geschaltet wird.
Konkret heißt das: Der Warmwasser-Boost aus Baustein 1 bekommt eine zusätzliche Bedingung, die prüft, ob die Tagesprognose einen bestimmten Schwellenwert übersteigt. Ist das nicht der Fall, bleibt die bestehende SG-Ready-Logik unverändert – sie reagiert weiterhin rein auf den aktuellen Überschuss. Ist die Prognose aber vielversprechend, wird die Mindest-Haltezeit vor dem Einschalten etwas verkürzt, weil das Risiko eines kurzen Fehlstarts geringer ist.
alias: Warmwasser-Boost Schwelle je nach Prognose
trigger:
- platform: numeric_state
entity_id: sensor.pv_ueberschuss
above: input_number.warmwasser_boost_schwelle
condition:
- condition: template
value_template: >
{{ states('sensor.solcast_pv_forecast_prognose_heute') | float(0) > 15 }}
action:
- service: input_number.set_value
target:
entity_id: input_number.warmwasser_boost_haltezeit
data:
value: 60
mode: singleCode-Sprache: JavaScript (javascript)Fällt die Tagesprognose dagegen niedrig aus, bleibt die reguläre, vorsichtigere Haltezeit bestehen – die Automation verhält sich dann genau wie vor Einführung der Prognose.
Umgang mit Prognoseabweichungen
Wichtig ist mir dabei: Die Solcast-Prognose ist eine Wahrscheinlichkeit, kein Versprechen. An Tagen mit wechselhaftem Wetter weicht sie in meiner Erfahrung deutlich stärker vom tatsächlichen Verlauf ab als an klaren oder komplett bedeckten Tagen. Deshalb bleibt die bestehende Hysterese- und Sicherheitslogik aus den anderen Bausteinen vollständig erhalten. Die Prognose verändert nur, wie aggressiv die bestehenden Regeln reagieren – sie hebelt sie nie aus. Fällt der reale Überschuss plötzlich weg, greifen weiterhin dieselben Nothalt-Bedingungen wie zuvor, unabhängig davon, was die Prognose vorhergesagt hatte.
Praxisbeispiel – ein Tag mit und ohne Prognose
An einem Tag mit sicherer, hoher Prognose lief der Warmwasser-Boost bei mir spürbar früher an als an einem vergleichbar sonnigen Tag ohne Prognose-Bedingung – einfach weil die verkürzte Haltezeit früher zuschlagen durfte. An einem Tag mit stark schwankender Prognose blieb die Automation dagegen im vorsichtigeren Standardverhalten und verhielt sich kaum anders als vorher. Genau dieses Verhalten war das Ziel: Die Prognose soll an guten Tagen Vorteile bringen, an unsicheren Tagen aber nicht ins Risiko gehen.
Das Gesamtsystem im Überblick
| Verbraucher | Trigger | Prognose-Einfluss |
|---|---|---|
| Warmwasser (Wärmepumpe) | SG-Ready-Signal | Verkürzte Haltezeit bei hoher Tagesprognose |
| Heizung (Vorlauf) | Vorlauf-Offset | Bisher ungenutzt, geplant für spätere Feinabstimmung |
| Heizstab (Bad) | Hysterese-Schaltung | Sicherheitslogik unverändert, keine Prognose-Kopplung |
| Priorisierung | übergreifende Logik | Reagiert weiterhin ausschließlich auf Ist-Werte |
Bewusst habe ich die Prognose bislang nur an einer einzigen Stelle eingebaut, statt sie sofort überall einzusetzen. So kann ich beobachten, wie sie sich im Alltag schlägt, bevor ich sie auf weitere Bausteine ausweite.
Was ich beim Einbinden der Prognose gelernt habe
- Prognose ergänzt, ersetzt aber keine Sicherheitslogik. Hysterese, Mindestlaufzeiten und Nothalt-Bedingungen bleiben in jedem Fall Pflicht.
- Nicht zu oft abrufen. Zwei Abrufe pro Tag reichen für den Hausgebrauch völlig aus und schonen das kostenlose Kontingent.
- Lieber an einer Stelle testen als überall gleichzeitig. So lässt sich das Verhalten der Prognose in der Praxis beurteilen, bevor man sich von ihr an mehreren Stellen gleichzeitig abhängig macht.
- Fallback einplanen. Ist der Solcast-Sensor mal nicht verfügbar (z. B. bei einem API-Ausfall), sollte die Automation automatisch auf das alte, rein reaktive Verhalten zurückfallen, statt hängen zu bleiben.
Wie es weitergeht
Als Nächstes geht es um die reale Leistungsmessung vs. Netzbezug – also darum, wie sich aus präzisen Momentanwerten robustere Entscheidungsgrundlagen für das gesamte Lastmanagement bauen lassen, unabhängig davon, ob eine Prognose vorliegt oder nicht.
Nutzt du schon eine Wetter- oder PV-Prognose in deiner Automation, oder steuerst du bislang rein reaktiv? Schreib mir gerne, wie du das Thema angehst!