Solar Forecast ML - Ich brauche Hilfe Sammelthread

[TobiB80]

@Tom-HA Da wir im Bug-Tracker Thread nicht diskutieren soll, ich aber immer noch Probleme habe, die verworfenen Stunden zu verstehen, schreibe ich nochmal hier.

Zunächst zu deiner Antwort hier BUG-TRACKER Solar Forecast STATS - #401 von Tom-HA . Greift der Tagesverlauf je Modulgruppe dann auf andere Daten zu als die Wochenübersicht? Zum Beispiel gestern sind es wieder einmal 4 h Akku-Curtailment und einmal 4 h MPPT-Drosselung. Damit müssen die gleichen Stunden gemeint sein, denn nur diese wurden ausgeschlossen. Ich finde das für den Benutzer verwirrend und als Software-Entwickler gehe ich davon aus, dass ich im log die Wahrheit finde und dort steht suspected_battery_curtailment.

Das ist mir jetzt aber auch nicht so wichtig. Mir ist es nur aufgefallen und ich wollte es mitteilen. Wenn du sagst, dass ist genau richtig, habe ich kein Problem damit.

Ich habe aber auch noch ein anderes Problem und denke, dass bei mir irgendwie etwas falsch läuft. Zunächst eine Verständnisfrage. Diese ausgeschlossenen Stunden bedeuten doch schon, dass die KI diese Stunden vom Lernen ausschließt, oder verstehe ich da etwas falsch?

Wenn das so ist, dann sehe ich es bei mir als problematisch an, dass immer wieder die dauerhaft verschatteten Abendstunden aus für mich nicht verständlichen Gründen vom Lernen ausgeschlossen werden. Ich würde einfach gerne verstehen, ob das an einem Konfigurationsfehler liegt, an fehlenden oder unvollständigen Daten oder vielleicht doch noch an einem kleinen Bug in der Ausschlusslogik.

Für mich passt einfach nicht zusammen, dass im End of Day Workflow, Stunden immer wieder aus Gründen ausgeschlossen werden, die nicht zu meinen Einstellungen passen.

2026-07-29 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-07-29 H17: actual=1.164 kWh, theoretical=2.820 kWh, reason=suspected_battery_curtailment
2026-07-29 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-07-29 H18: actual=0.319 kWh, theoretical=1.961 kWh, reason=suspected_battery_curtailment
2026-07-29 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-07-29 H19: actual=0.224 kWh, theoretical=1.124 kWh, reason=suspected_battery_curtailment
2026-07-29 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - Curtailment learning quarantine 2026-07-29 H20: actual=0.091 kWh, theoretical=0.294 kWh, reason=suspected_battery_curtailment

Entweder im log steht nicht der wirkliche Grund für den Ausschluss oder irgendetwas stimmt nicht. Der Grund suspected_battery_curtailment macht einfach ohne Akku keinen Sinn.

[Tom-HA]

@TobiB80

Diese ausgeschlossenen Stunden bedeuten doch schon, dass die KI diese Stunden vom Lernen ausschließt, oder verstehe ich da etwas falsch?

Aktiviere bitte mal Nulleinspeisung und gebe den max Output deines WR ein

[TobiB80]

@Tom-HA

Aktiviere bitte mal Nulleinspeisung und gebe den max Output deines WR ein

Wieso Nulleinspeisung, die habe ich doch gar nicht?

Du meinst das, oder? Das ist schon konfiguriert.

[Astrofreak85]

Frage am Rande:

Wenn ich meinen Akku (Solarcon One) so konfiguriert hab, das er “Nulleinspeisung” machen soll, aber sobald der Akku voll ist auch Netzeinspeisung machen darf, wie sind dann die Haken richtig zu setzen?

Der lädt ja immer mit maximalem Input, bis ca. 90% SOC, dann wird die Leistung von den Panelen gedrosselt, wenn voll werdne die Panele auf max. 800W gedrosselt…

So wie hier:

[Tom-HA]

Das ist dann technisch keine Nulleinspeisung. Eine klassische Nulleinspeisung, also keine Energie ins öffentliche Netz schaut so wie beim @suedschwede und / bei mir aus:

Du müsstest also die Nulleinspeisung nicht markieren aber die Max-Leistung die dein WR ausgibt / bzw. einspeisen kann / darf angeben. Dann sollte es funktionieren.

[koma78]

Kann mir jemand einen Tipp geben wie ich Hubble helfen kann? Bis zum letzten Update kam der Fehler nicht. SFML läuft jetzt seit März

[Tom-HA]

Hallo @koma78

ich bin an dem Thema schon dran. Es hängt mit der neuen Logik zusammen, die bzgl der Schattenerkennung kommt. - Aktuell ist es nur ein Anzeigefehler, der nervt aber mit dem kommenden Update verschwunden ist. - bitte ignorieren.. Hubble geht noch mal zu Schule

[Johnny_1993]

Sozusagen müsste es dann in den Einstellungen so aussehen?

Hast du das mit der Einführung des “Max-Einspeisewertes” geändert, denn vorher hies es doch dachte ich bei BKW mit mehr Modulleistung nulleinspeisung aktivieren, damit SFML den Cut von z.b. 2 kW auf 0,8 kW erkennt

[suedschwede]

Ja, so schaut bei mir die Nulleinspeisung aus, Module werden abgeregelt und es wird nur noch der Hausbedarf durchgeleitet, in das Netz gingen heute 50Wh

[Astrofreak85]

OK dann hab ich das schon richtig gemacht, wollte nur nochmal sicher gehen

[suedschwede]

@Tom-HA
Ich sehe gerade das bei Dir und bei @Astrofreak85 der SOC beim erreichen von 100% bestehen bleibt bis wieder entladen wird.
Bei meinem Maxxisun System ist es so das der SOC nur für kurze Zeit von 15min auf 100% geht und danach über mehrere Stunden bei 99% verweilt bis wieder entladen wird, das bringt doch bestimmt das System durcheinander, oder?

[Tom-HA]

Nein, keine Sorge, ich habe extra eine Hysterese eingebaut, um dauerndes Schalten zu vermeiden und den Akku + BMS zu schonen. Alles gut!

Generell ist Hubble und der Code an sich an zahlreichen Stellen “gedämpft” um nicht in Panik zu agieren oder zu springen.

Der Code ist auch abgesichert gegen Ausfälle von Anbieter-Clouds. Eine typische Fehlermeldung:

Dieser Fehler stammt von einer benutzerdefinierten Integration

Logger: custom_components.sfml_stats.core.battery_tracker
Quelle: core.py:915
Integration: Solar Forecast STATS (Dokumentation, Probleme)
Erstmals aufgetreten: 18:09:11 (1 Vorkommnis)
Zuletzt protokolliert: 18:09:11

Battery tracker gap detected: 4.12 hours exceeds limit 4.00 hours, capping interval

Das bringt SFML bzw Hubble nicht aus dem Tritt. - Du erinnerst Dich bestimmt an die Veränderungen die ich zum Erhalten der Datenqualität eingebaut habe.. genau das wird in solchen Momenten getriggert und vergiften die Lernbasis nicht. → Wir beide hatten doch mal über das Logging gesprochen.. solche Dinge habe ich nicht entfernt, da sie dem Nutzer zeigen " Hey Achtung deine Daten aus der Cloud / MQTT / ModBus / .. weisen Lücken auf, die wurden erkannt. → in diesem konkreten Fall ist die Integration eines BKW abgestorben und hat via Cloud keine Daten mehr gesendet.

Fazit: Zurücklehnen und Tee trinken.. Hubble macht das schon. Home Assistant ist keine Labor Umgebung und hat selber auch zahlreiche BUG´s und Fehler / Hic Ups.. das wird kompensiert so gut es geht

[Astrofreak85]

ich hab bei meinen beiden Akkus 95% als maximum drin. die von beiden Herstellern empfohlene dauerhaft maximalladung, entladen wird jeweils bis 10%

[Erol82]

Ich habe auch den Fehler drin.

Wenn man Neustart von HA macht geht es weg. Gut das es in den nächsten Update weg ist.

[KeePon]

Schönes Projekt, Solar Forecast ML gefällt mir sehr gut!

Ich habe ein Balkonkraftwerk mit zwei Marstek-BD2500-Speichern, die parallel betrieben werden. Jeder Speicher verfügt über eigene Solarpanels, beide speisen jedoch über denselben Wechselrichter mit zwei Strings ein.

Nun möchte ich Solar Forecast ML optimal integrieren, um intelligente Lade- und Entladestrategien umzusetzen.

Kann ich beide Speicher als separate Batterien konfigurieren? Das wäre mir wichtig, da sie unterschiedliche SoC-Werte haben können und die Einspeisung in dem Speicher möglicherweise früher abgeregelt wird als beim anderen. Auch die Nutzung eines Überschusses könnte dadurch bei einem Speicher früher beginnen als beim anderen.

Eine Zusammenfassung der Sensoren in einem Template-Sensor halte ich daher nicht für zielführend.

Vielen Dank für jeden Hinweis!

[gobbli]

@KeePon

rojekt, Solar Forecast ML gefällt mir sehr gut!

Problem habe ich auch. Wenn ich Tom richtig verstanden habe, ist es ein Bug welcher in dem nächsten Release behoben wird.

[lemuba]

@KeePon

Kann ich beide Speicher als separate Batterien konfigurieren?

Nein das geht nicht, es wird aktuell nur eine Batterie unterstützt.
Ich habe 2 Marstek Venus, welche über mqtt steuerbar sind - wie schaut das bei Deinen Speichern aus?
Kannst Du die schon einzeln in HA steuern? Laut KI sollte das ja über hm2mqtt funktionieren?
Ein Vorschlag laut KI:

• beide BD2500 separat per hm2mqtt anbinden,
• Solar Forecast ML die Prognose erstellen lassen,
• in Home Assistant entscheiden,
  • welcher Speicher zuerst lädt,
  • welcher zuerst entlädt,
  • wann Netzladen erlaubt ist,
  • wann wegen der Prognose Kapazität freigehalten wird.

Auch vielleicht ein Punkt mit nur einem WR - tbc:

Da beide Speicher über denselben Wechselrichter einspeisen, sieht Home Assistant netzseitig nur die Summe. Für eine wirklich getrennte Regelung brauchst du daher zusätzlich die individuellen Leistungswerte der beiden Speicher. Andernfalls kann eine Regelung zwar die Entladefreigaben getrennt setzen, aber nicht zuverlässig erkennen, welcher Speicher gerade welchen Anteil liefert.

P.S. Hast Du von beiden Panel die getrennten DC Leistungswerte (Watt)? Die wären ja ggf. auch erstmal eine grundlegende Vorraussetzung für eine SFML Prognose… ??? @Tom-HA

[KeePon]

Ja, beide Speicher sind bei mir bereits separat über MQTT steuerbar.

Ich nutze ebenfalls Tibber. Mich hat es irgendwann genervt, dass der Strom mittags am günstigsten war, ich aber nichts aus dem Netz zugekauft habe, weil das Balkonkraftwerk meinen gesamten Verbrauch gedeckt hat – teilweise sogar mit Überschuss.

Abends musste ich dann teureren Strom beziehen, obwohl ich den günstigen Mittagsstrom hätte speichern können. Genau deshalb habe ich angefangen, mich mit einer Lade- und Entladesteuerung zu beschäftigen. Wäre natürlich cool, wenn ich mein eigenes Skript irgendwann durch SFML ersetzen könnte.

Aktuell lade ich die Speicher bei Bedarf sogar tagsüber mit günstigem Netzstrom nach. An jedem BD2500 hängt an einem Eingang ein 600-W-LED-Netzteil, das ich über eine smarte Steckdose automatisch einschalte. Das passiert nur dann, wenn sich der Strompreis lohnt und die Prognose erkennen lässt, dass der Speicher allein durch die PV voraussichtlich nicht mehr voll wird.

Ich nutze aktuell das Nulleinspeise-Skript von Simon, das ursprünglich für einen einzelnen BD2500 entwickelt wurde. Dieses habe ich so angepasst, dass beide Speicher gemeinsam arbeiten.

Durch das Skript habe ich außerdem einen Sensor, der den aktuellen Einspeisebedarf ermittelt. Das Skript verteilt und regelt die benötigte Ausgangsleistung anschließend auf beide Speicher. Die Ein- und Ausgangswerte des gemeinsamen Wechselrichters sind für meine Regelung daher aus meiner Sicht nicht relevant und müssten nicht zusätzlich berücksichtigt werden. Entscheidend sind für mich die individuellen Werte und Steuerungsmöglichkeiten der beiden Speicher.

Dabei wird nicht zuerst ein Speicher entladen, während der andere nichts macht. Stattdessen entladen beide Speicher immer parallel. Dadurch verteilt sich die Leistung gleichmäßiger und die Spitzenbelastung der einzelnen Speicher fällt geringer aus.

Außerdem hat jeder BD2500 seine eigenen PV-Module. Wenn beide Speicher morgens einen ähnlichen SoC haben, können sie sich gleichzeitig über ihre jeweils eigenen Panels wieder aufladen. Würde dagegen ein Speicher nahezu voll bleiben und der andere deutlich stärker entladen werden, könnte es bei wenig Sonne passieren, dass der stärker entladene Speicher nicht mehr voll wird, obwohl an den Panels des anderen Speichers noch Leistung zur Verfügung stünde. Die Panels regelmäßig umzustecken, ist für mich keine praktikable Lösung.

Genau deshalb fände ich die Unterstützung mehrerer Batterien in SFML sehr interessant. Jeder Speicher verfügt über einen eigenen SoC, eine eigene PV-Eingangsleistung und eine separat regelbare Ausgangsleistung.

[home-assist-ab]

Bei mir wird das Gleiche angezeigt.

Allerdings wird auch angezeigt, dass das letzte Training am 28.07. durchgeführt wurde. Das könnte die Zeit gewesen sein, als die Version 40 erschienen ist. Ich installiere eigentlich immer direkt alle Updates.

Ich sehe auch im Temperaturverlauf der Pi-CPU, dass der Peak um 23:30 nicht mehr da ist. Also wird wohl tatsächlich nicht mehr trainiert. An den Einstellungen habe ich nichts geändert. Und in STATS sind unter Optionen „Sensoren“, „Hubble“ und „System“ grün.

[home-assist-ab]

Ich sehe gerade, dass es ein Update gibt. Wenn heute Abend wieder nicht trainiert wird, melde ich mich noch einmal.