Sammelthread für Fragen zu Solar Forecast STATS

Ich habe eine Frage zu STATS.
Wann wird smart charging in STATS aktiviert und deaktiviert, am Tag ist es ja deaktiviert?

Da ich eine eigene Regelung habe die mir den Akku schön langsam nach PV Prognose (SFML)
bis abends läd, möchte ich verhindern das 2 Steuerungen die Batterie steuern.
Meine Steuerung läuft über Modbus, bei STATS weiß ich das ja nicht.

Ich möchte gerne per Automation dann Nachts meine Regelung abschalten und Morgens wieder einschalten.
Kann mir jemand sagen, wann sich smart laden einschaltet und wann aus geschaltet wird?

@freo so wird der Schalter von Hubble geschaltet:

Smart Charge (SMC)

SMC entscheidet, ob und wann der Hausakku aus dem Netz geladen wird. Ziel ist nicht ein voller Akku, sondern die niedrigsten Stromkosten. Ein niedriger Preis allein startet keine Ladung.

So funktioniert SMC

  1. SMC prüft alle fünf Minuten Akku-SoC, erwarteten Verbrauch, verbleibende PV heute, PV morgen und die Strompreise der nächsten 36 Stunden.
  2. Es berechnet nur die Energiemenge, die nach vorhandenem Akku und erwarteter PV voraussichtlich noch fehlt.
  3. Der aktuelle Einkaufspreis wird um Lade-, Entlade-, Wechselrichter- und Eigenverbrauchsverluste korrigiert. Entscheidend ist der tatsächliche Preis einer später aus dem Akku gelieferten Kilowattstunde.
  4. Zukünftige Ladefenster werden nach Preis sortiert. Das günstigste Fenster erhält zuerst die benötigte Energiemenge, danach das zweitgünstigste.
  5. Das aktuelle Fenster lädt nur den Rest, der später nicht mehr rechtzeitig günstiger geladen werden kann.

Die drei Entscheidungen

Entscheidung Bedeutung
Laden Später droht teurer Netzbezug und die günstigeren Zukunftsfenster reichen nicht aus. SMC lädt jetzt nur die fehlende Restmenge.
Warten Ein späteres günstigeres Fenster kann den Bedarf rechtzeitig decken oder die Preisprognose reicht für eine sichere Entscheidung noch nicht aus.
Nicht laden Akku und PV reichen voraussichtlich aus oder notwendige Daten wie SoC, Verbrauch oder PV-Prognose fehlen.

Benötigte Sensoren und Daten

Sensor oder Wert Status Anforderung Aufgabe Wenn er fehlt
Akku-SoC erforderlich Sensor, numerisch 0–100 % Ermittelt vorhandene Energie und Ladebedarf Automatische Ladung wird sicher blockiert
Netzlade-Schalter für automatische Steuerung erforderlich switch-Entity des Akkus/Wechselrichters Schaltet die Netzladung ein oder aus Nur Analyse und Empfehlung, keine Schaltaktion
Aktueller Gesamtstrompreis erforderlich Endpreis in ct/kWh inklusive Steuern und Entgelten Bewertet die Kosten einer Ladung im aktuellen Fenster Entscheidung „Nicht laden“; die automatische Ladung bleibt aus
Zukünftige Strompreise für die Planung erforderlich Endpreise des dynamischen Preisservice für die nächsten 36 Stunden Liefert und sortiert die späteren Ladefenster Entscheidung „Warten“, bis eine belastbare Preisplanung möglich ist
Solarprognose erforderlich Rest-PV heute und PV morgen in kWh Verhindert unnötige Netzladung und hält Platz für Solarstrom frei Automatische Ladung wird sicher blockiert
Verbrauchshistorie erforderlich Durchschnittlicher Hausverbrauch der letzten Tage Schätzt den kommenden Energiebedarf Keine sichere Bedarfsberechnung

Notwendige Konfiguration

Wert Bedeutung
SMC aktiviert Schaltet die Berechnung und – mit konfiguriertem Schalter – die automatische Netzladung ein.
Akkukapazität Gesamtkapazität des Akkus in kWh. Sie wird benötigt, um SoC in verfügbare Energie umzurechnen.
Min-SoC Gewünschte Mindestreserve. SMC plant diese Reserve ein, lädt sie aber nicht zwingend sofort.
Max-SoC Harte Obergrenze für das Ladeziel. SMC lädt nur bis zum errechneten Bedarf und nicht automatisch bis zu diesem Wert.
Maximalpreis Orientierungswert für einen günstigen Preis. Im wirtschaftlichen SMC-Pfad ist er kein Ein-/Ausschalter: Ein Preis darunter kann abgelehnt, ein Preis darüber bei später noch höheren Kosten akzeptiert werden.
Force-Charge-Preis Kompatibilitätswert der früheren Schwellwertlogik. Er erzwingt im wirtschaftlichen SMC-Pfad keine Vollladung.
SoC-Sensor Liefert den aktuellen Ladezustand des Akkus.
Netzlade-Schalter Schaltet die Netzladung am Wechselrichter ein oder aus. Ohne ihn zeigt SMC nur die Empfehlung.
Gesamtpreissensor Optionaler aktueller Endpreis. Werte müssen als ct/kWh vorliegen.

Nutzungsbeispiel

Die Preisschwelle liegt bei 30 ct/kWh. In zwei Stunden kostet Strom 28 ct/kWh, in vier Stunden nur 10 ct/kWh. Reicht das 10-ct-Fenster für den Bedarf, wartet SMC über das 28-ct-Fenster hinweg. Reicht das günstigste Fenster nur für 1 kWh bei 2,3 kWh Bedarf, reserviert SMC dort 1 kWh und lädt vorher nur die fehlenden 1,3 kWh.

Wichtig: SMC steuert derzeit einen Ein-/Aus-Schalter. Die berechnete Energiemenge ist kein direkter kWh-Sollwert für den Wechselrichter. SMC prüft deshalb alle fünf Minuten neu und beendet die Ladung, sobald der verbleibende Bedarf durch Akku und reservierte günstige Fenster gedeckt ist.

Mit anderen Worten:
Es ist komplex und nicht nur ein “Schalter” der nach Strompreis geschaltet wird, sondern Hubble sorgt dafür den Akku Effizient zu laden / entladen maßgeschneidert auf deinen Verbrauch, deine Anlage, deine Kapazität. Es macht nämlich überhaupt keinen Sinn nur den Einkaufspreis des Stroms zu betrachten, da beim Zurückspeisen aus dem Akku weitere Kosten entstehen. Keine Automation in HA kann das abbilden!

  • Umwandlungsverluste beim Speichern
  • Umwandlungsverluste beim Entladen
  • Wechslrichterverluste ja nach Lastzustand (Teillastbereich ist ein WR sehr ineffizient)
  • uvm…

Bsp:
Kosten 15 Cent .. Entladung ins Haus Kosten (je nach Qualität des WR,BMS, Akku, Temperaturen, Elektronik im Mittel 20 Cent.. im (Teillastbereich des WR). im Vollastbereich ca. 16 Cent…
Aber Vorsicht, das kann von Anlage zu Anlage stark varrieren!

@freo beantwortet das Deine Frage?

1 „Gefällt mir“

Hallo @Tom-HA ,
Danke für die ausführliche Antwort, das ist alles super wie der Akku von STATS geregelt wird.

Was ich aber unbedingt vermeiden will, ist eine Steuerung des Akkus von 2 unabhängigen Steuerungen.
Jetzt im Sommer ist das kein Problem, im Winter wird das anders sein.

Da ich meinen AKKU tagsüber nur per PV schonend über den Tag mit angepasster Ladestärke voll mache, möchte ich tagsüber, nicht dass eine andere Steuerung dazwischen funkt, mehr nicht.
Habe ich eine Möglichkeit deine Steuerung tagsüber zu deaktivieren?

Ich meine Mal am Anfang der Einführung gelesen zu haben, dass smart laden tagsüber deaktiviert ist, um Platz für PV im Akku zu schaffen?

Klar, das hängt von deiner Automation ab, so wie du den “Schalter” von SMC nutzt.. Du kannst es so bauen wie Du es brauchst. Hubble schlatet nur den Schalter.. alles andere wie Du es nutzt / verwendest liegt bei Dir.

Ist es der Netzlade Schalter? muss der immer auf “ein” stehen?
So wie ich das verstanden habe wird der von STATS eigenständig an und aus gestellt, wenn geladen werden soll, oder nicht geladen?
Ich verstehe es nicht ganz, welchen Schalter ich dann für meine Automation nutzen kann :thinking:

Du kannst Natürlich auch nach Stunden “regeln” lassen.. STATS bietet Dir all diese Sensoren um eine Automation zu bauen, ganz wie Du es möchtest / brauchst..

1 „Gefällt mir“

Okay, dann bau ich die Entität als Bedingung in die Automation für meine Regelung.
Besten Dank und Gruß

1 „Gefällt mir“

Gibt es eine Lösung diesen Wert irgendwie auf Null zu setzten und von vorne zu starten?
Er ist durch einen Sensorfehler meinerseits zu Beginn entstanden:

Ich habe gerade das Update auf Version 42.0.0 ausgeführt, schaue mir nun die Daten an und bin mir nicht so ganz sicher, was ich sehe:

Gegen Mittag hat eine Erdrakete gleich 3 fette Versorgungskabel (je 3x160 mm²) in unserem kleinen Ort durchtrennt :slight_smile:. Dadurch fehlen mindestens 20 kWh Ertrag, die ansonsten gekommen wären (Siehe Delle). Trotzdem behauptet die SW, dass eine Prognosegüte von 88,1%. Kann es sein, dass diese Güte so berechnet wird:

(Ist bisher + noch zu erwarten) / Tagesprognose ? Dann könnte es vielleicht hinkommen.

Und hier nun noch zu Hubbel:

Diese Textausgabe finde ich eher drollig, als hilfreich, besonders der Tipp für die größeren Verbraucher. Ergibt das am Anfang des Tages vielleicht noch eine sinnvolle Aussage, ist es nach der Peak-Produktion schlicht Quatsch nach meinem Empfinden, weil der Zeitpunkt für große Verbraucher einfach immer weiter in die Zukunft geschoben wird. Halbwegs sinnvoll wäre zur aktuellen Uhrzeit noch eine Aussage wie “hätteste mal die großen Verbraucher um 11 Uhr laufen gelassen, nun ist es zu spät :laughing:“. Oder sachlicher: “Der günstigste Zeitraum war heute zwischen 10 und 12 Uhr.” Warum wird das nicht so gemacht?

Für mich wäre es schön, wenn ich z. B. dies Hubble-Fensterchen ausblenden könnte, da ich das nicht benötige. Ich empfinde es als Spielerei, mir reichen schlichte Zahlen und Graphen.

Die Idee bzw. der Wunsch, die Komponenten, die angezeigt werden sollen, einzeln auswählen zu können, wurde ja an anderer Stelle auch schon mal platziert, da schließe ich mich an. Könnte es sein, dass diese Möglichkeit noch kommt?

Und dann habe ich noch eine Frage zur Qualität der physikalischen Prognose. Wie hier beispielhaft zu sehen, liegt die sehr deutlich unter den anderen Prognosen, was im Prinzip für alle Tage so war:

Siehe hier der Verlauf des mittleren absoluten Fehlers:

Das die AI lokale Einflussfaktoren und Abweichungen einbezieht und die Prognosen abweichen, verstehe ich. Ich würde dann aber erwarten, dass im Mittel die physikalische Prognose über den Werten der AI liegt, weil die Schatten ja nicht kennen kann, aber das prognostizierte Wetter das selbe ist. Aber bei mir zumindest ist es genau umgekehrt. Die Physik liegt immer deutlich niedriger, ich habe mir schon viele Tagesdiagramme angeschaut. Nun habe ich aktuell praktisch keine Schatten, aber permanent so eine gewaltige Abweichung? Woran könnte das liegen? Bug oder Feature? :wink:

p.s. hier noch die Strahlungskalkulation und der Vergleich mit “ist”:

@thomasz

Die 88,1 % Prognosegüte werden nicht berechnet, indem zur bisherigen Produktion einfach der noch ausstehende Forecast addiert wird. Während des laufenden Tages werden nur die bereits abgeschlossenen und auswertbaren Stunden miteinander verglichen. Technisch beeinflusste Stunden, etwa durch MPPT-Begrenzung oder Akku-Curtailment, werden dabei nicht berücksichtigt. In deinem Screenshot sieht man, dass jeweils eine solche Stunde verworfen wurde. Deshalb wirkt sich der Stromausfall nicht vollständig auf die angezeigte Prognosegüte aus. Der Wert ist außerdem nur der Zwischenstand für den bisherigen Tag.

Bei Hubble wird immer das beste noch kommende Zeitfenster angezeigt. Ist das eigentliche Tagesmaximum bereits vorbei, wandert die Anzeige deshalb zum besten verbleibenden Zeitraum – auch wenn dort nur noch wenig Solarertrag zu erwarten ist. Ein bereits vergangenes Zeitfenster wird nicht als Empfehlung ausgegeben. Das entspricht der aktuellen Funktionsweise.

Hubble lässt sich nicht separat ausblenden. Eine individuell zusammenstellbare Ansicht der einzelnen Bereiche ist nicht vorgesehen. Alternativ kann man jedoch das Solar Cockpit nutzen. Stats ist dem Wesen nach eine Auswertung und Anzeige, kein Desktop.

Die Physik-Prognose ist keine unverschattete Obergrenze. In ihre Berechnung fließen unter anderem die Ausrichtung und Neigung der Module, die verschiedenen Einstrahlungswerte, die Temperatur, Anlagenverluste und gelernte Korrekturen ein. Deshalb kann die Physik-Prognose auch unter der KI-Prognose liegen. Das ist grundsätzlich so vorgesehen und anhand der gezeigten Werte kein Hinweis auf einen Fehler.

O.k., da habe bzw. hatte ich die falsche Erwartungshaltung :slight_smile:. Danke für die Korrektur!

“auch unter” würde ich sofort verstehen, aber “immer unter”? In der Tat ist ein String, der ~40% nominell liefern sollte, schon 13 Jahre alt und definitiv schon etwas degradiert. Dass die AI das mitbekommt, ist ja gerade die coole Idee deiner Lösung. Aber dann würde ich doch erwarten, dass die Physik im Schnitt etwas über der AI liegt, und nicht unter der AI, und das auch noch deutlich, weil sie die Degradation doch eben nicht mitbekommt und daher im Mittel zu optimistische, also zu hohe Prognosen liefern sollte.

Oder habe ich da einen Denkfehler?

SFML gibt es erst seit Feb 2026 Hubble ist sogar noch jünger.. woher sollte er also wissen, wie sehr deine Solar-Panele in den letzten 13 Jahren degeneriert haben :wink: .. was sie merkt: ist die Aktuelle Leistung! Das macht sie bei Dir auch sehr gut, wenn ich mir deine Ergebnisse anschaue. Der Stack ist viel viel komplexer als du es gerade denkst. Die Base-Line ist also der Zeitpunkt der Installation und nicht das Alter deiner Panels..

Hallo, ich habe leider seit dem letzten Update massive Verzögerungen im Zugriff auf Home Assistant (Companion App verliert ständig die Verbindung, Automationen werden verzögert ausgeführt). Mein Freund Mr. ChatGPT hat meine Protokolle analysiert und “mit hoher Wahrscheinlichkeit” die Gruppe der SFML Integrationen als Ursache ausgemacht. Die KI hat mir die aus ihrerSicht dafür relevantesten Protokolleinträge zusammen kopiert.

2026-08-03 23:01:47.777 DEBUG (MainThread) [custom_components.solar_forecast_ml.coordinator] Finished fetching solar_forecast_ml data in 60.564 seconds (success: False)2026-08-03 23:01:47.778 DEBUG (MainThread) [custom_components.solar_forecast_ml] First data refresh timed out after 60s - using cached data (normal during startup)

2026-08-03 23:02:05.549 WARNING (MainThread) [homeassistant.components.sensor] Setup of sensor platform solar_forecast_ml is taking over 10 seconds.

2026-08-03 23:02:36.741 DEBUG (MainThread) [custom_components.solar_forecast_ml.coordinator] Finished fetching solar_forecast_ml data in 40.482 seconds (success: True)

2026-08-03 23:02:40.501 WARNING (MainThread) [homeassistant.bootstrap] Waiting for integrations to complete setup: {(‘sfml_stats’, ‘01KV03Y622ZRYJMBBNME9G6XEZ’): 342.137276821}

2026-08-03 23:04:20.687 WARNING (MainThread) [homeassistant.core] Something is blocking Home Assistant from wrapping up the start up phase. We’re going to continue anyway.

The system is waiting for tasks:<Task pending name=‘Task-2066’ coro=<SurplusAvailableBinarySensor._async_refresh() running at :168>><Task pending name=‘Task-1994’ coro=<ActualLiveStateManager.async_refresh() running at :144>><Task pending name=‘solar_forecast_eai_weather_event_01KYHB71PWDDK1RGKB6GHQJ0QW’ coro=<EAIRuntime._async_update_weather_intelligence() running at :516>>

2026-08-03 23:05:07.487 DEBUG (MainThread) [custom_components.solar_forecast_ml.production.production_scheduled_tasks] Executing hourly update2026-08-03 23:05:40.858 DEBUG (MainThread) [custom_components.solar_forecast_ml.coordinator] Finished fetching solar_forecast_ml data in 75.147 seconds (success: True)

Any ideas? Ich habe (noch) einen HA Green aber bisher lief alles gut. Ich weiß leider nicht genau nach welcher Version das aufgetreten ist, ich installiere immer am Tag nach dem Update, es kann nicht mehr als 3-4 Tage her sein. Ich habe die SFMl Integrationen jetzt alle deaktiviert und es läuft wieder “normal”. Allerdings werden im Protokoll noch Verzögerungen von weather fusion ai angezeigt.

Danke

Thorsten

Hallo Thorsten,
kannst Du mir bitte ein paar mehr Informationen geben?

Host-System
Welche SFML Version
HW-Info

Dann kann ich es besser verstehen, eingrenzen.

Gerne. SFML 42.0, HA OS 18.2, HA Green.

Hallo Thorsten,

danke für die zusätzlichen Angaben. Der HA Green erklärt die langen Laufzeiten. SFML und die Zusatzkomponenten sind zwar für ARM freigegeben, der Green besitzt aber nur begrenzte Leistungsreserven und eine sehr schwache Hardware.
Wenn parallel weitere Integrationen / Automationen / Sensoren /.. laufen, kann die Gesamtlast für das System zu hoch werden.
Im Update 18.2 wurde zwar der Kernel aktualisiert, aber ob der wirklich stabil läuft kann / wird die Zeit zeigen.

Zu deinem LOG

Die Protokolle zeigen, dass einzelne Berechnungen zwischen 40 und 75 Sekunden benötigen und STATS beim Start mehrere Minuten auf noch laufende Aufgaben wartet.
Das ist ein Hinweis auf eine starke Gesamtauslastung, aber kein Beleg für einen Fehler in SFML. Auch die Angabe „MainThread“ bedeutet nicht automatisch, dass eine Integration Home Assistant blockiert. SFML ist bewusst nach den Vorgaben von Home Assistant von mir gebaut worden und blockiert weder den Thread noch ist es aggressiv. Alle Prozesse von SFML sind async und defensiv. → Es wurde auch kein Blocking-Call ausgelöst.

Meine Empfehlung für den HA Green ist:
STATS, EAI und die weiteren optionalen Zusatzkomponenten zu deinstallieren und nur Solar Forecast ML zu verwenden. Die Prognosen können dann ganz klassisch über die normalen Home-Assistant-Sensoren genutzt und in eigenen Karten oder Automationen eingebunden werden.

Der vollständige Stack ist deutlich rechenintensiver. Dafür ist ein leistungsfähigeres Home-Assistant-System mit entsprechenden Reserven die bessere Wahl. Wenn Du bei ARM-Basierten Systemen bleiben möchtest zum Beispiel ein Raspberry PI, der hat deutlich mehr Reserven und ist moderner (aber bitte nicht mit SD-Karte.. dazu gibt es hier im Forum sehr viele Beiträge.

Ich hoffe das hilft Dir weiter.. und beantwortet deine Frage

Gruß
Zara

Guten Morgen Tom, danke für dein Feedback. Das hatte ich schon befürchtet. Ich habe jetzt mal EAI raus genommen und den Rest aktiviert und das scheint zu laufen. Ich bin dabei mein IT-Setup grundlegend zu erneuern, u.a. mit dem Ziel mir einen Mini-PC mit Proxmox und ausreichend Power hinzustellen. Hardware für SFML anschaffen ;-). Dann muss ich das jetzt mal beschleunigen (die Alternative erst mal auf die Synology umzuziehen ist mir zu viel hin und her). Danke für deine Hilfe!

Hallo @Thorsten14 (Off-Topic)

Danke für das Feedback! Kleine Anmerkung / Tipp (in vollem Bewusstsein das es so viele Meinungen wie Sand am Meer gibt…)

  1. Ein Mini-PC in der unteren / mittleren Preisklasse hat in der Regel alte Restbestände an Laptop Hardware verbaut. Das ist aus Recycling-Gründen eine Gute Sache.. man muss es nur wissen. Also bitte genau prüfen welche CPU verbaut ist und ob es nicht eigentlich eine NoteBook CPU ist.

  2. Proxmox muss 100% korrekt konfiguriert werden / sein und wird immer Leistung kosten. Einfache Anleitungen aus dem Internet reichen da NICHT aus! Proxmox ist ein gutes System, bedarf aber tiefes Verständnis und Einarbeitung. Es gibt hier im Forum einige Spezialisten dafür. Auch wichtig es gibt immer wieder Probleme zwischen HA und Proxmox - bitte vorsichtig sein mit Home Assistant Updates. Grundsätzlich das Change-Log prüfen und den BUG-Tracker im Kontext zu Proxmox, Kernel, API, Container..

  3. Home Assistant benutzt immer nur einen Kern / Thread für den Event-Loop, daher ist es völlig unerheblich wieviele Keren eine CPU hat (für Home Assistant) → Größere CPU (mehr Kerne) bedeute nicht automatisch mehr Leistung!

  4. Wenn Du die Chance hast, schaue nach einem AMD nicht Intel! Mehrere Benchmarks haben gezeigt, das AMD deutlich schneller und effizienter ist (bei Home Assistant) - scheint so das auf HW -Ebene AMD doch mehrere Kerne nutzen kann.. IST NUR EINE BEOBACHTUNG. Auch scheint AMD in Datenbanken generell schneller und stabiler zu sein. - Ich sehe das immer beim KI-Training die Unterschiede sind massiv!

  5. Wenn Du eine USV willst, keine abgespeckte NoteBook-CPU dann würde ich immer einen Laptop bevorzugen, da die HW und Effizient auf die CPU abgestimmt. ist. → Mein eigener HA läuft auf einem 2018er Dell Laptop mit SSD und verbraucht im Tagesmittel mal gerade 5Watt

Das sind alles nur Tipps, die auf eigener Erfahrung beruhen.. da ich logischer Weise viele verschiedene Installationsarten nutzen muss um SFML zu optimieren.

Auch off Topic: Ich habe sonen Dell(i) Gamer Laptop von meinem Sohn geerbt: 2016 gekauft

Bildschirmfoto 2026-08-04 um 12.31.42

Und jetzt halte ich mich wieder raus :vulcan_salute:

Danke dir, nehme ich gerne mit, bin immer dankbar für Hinweise (und gehe das auch nicht alleine an).