Dir fehlt dann die 6 Uhr Prognose… das ist der Grund. Alle die gestern noch installiert haben, sollten relativ nah dran sein. Bei mir kommt allerdings hinzu, dass es aus Testgründen schon etwas länger läuft als es bei euch der Fall ist - sein kann. - Das wird bei dem “echten Update” anders sein, es wird eine Art Initialisierung und Reset geben, da ich dank euch nun weiß das V1 komplette ignoriert wird .. eine sehr wichtige / wertvolle Erkenntnis! Ebenso das ich die Race-Condition noch anpassen muss.
um Mitternacht werden die Cache aktualisiert und eine Rotation durchgeführt - die fehlt Dir. Es wurde also mehr oder weniger “blind” geraten. Das ist aber in der Update-Version anders… hier war es notwendig zu testen
a) Was passiert ohne Daten
b) Was passiert wenn Datenreste vorhanden sind
c) Was passiert wenn die Files nicht alle beim Start angelegt werden
d)…
Gerade bei Systemen die „lernen“ und etwas prognostizieren, sollte man sicherlich ein paar Tage warten bevor man ein sinnvolles Ergebnis erwartet. Einfach mal laufen lassen und ein paar Tage beobachten
Inwieweit wird denn die Leistung der Solar-Module in die Vorhersagen gewichtetet. Ich glaube nicht das die Intelligenz die Ausrichtung der Module kurzfristig einschätzen kann. Meine Prognose ist auch weit vor der Produktion.
Die Ausrichtung der Anlage spielt für die Integration absolut gar keine Rolle. Da sie alle 30 Minuten insgesamt 24 Datenpunkte erfasst, die nur mit der tatsächlichen Produktionsleistung der Anlage zu tun haben.
Vier Dinge stechen hierbei heraus:
Die von Dir eingegebenen KWP, dass setzt den physikalischen Rahmen und ist die Grundlage für eine komplexe Mathematische Berechnung
Max Peak Rekord die Obergrenze des tatsächlich machbaren
Astronomische Daten und der Verifikation
Wettereinflüsse
hinzu kommen noch 22 Weitere Datepunkte die ausschließlich in Beziehung zu allen 48 Datenpunkten gesetzt werden um die Anlage “kennenzulernen”. Hierbei geht es auch um regelmäßigen Schattenwurf, Leistungsabfall, uvm…
Es ist also völlig egal wie die Anlage ausgerichtet ist, sie wird IMMER live-berechnet.
Das ist falsch, es ist ein sehr wichtiger Wert, wie ich weiter oben schon versucht habe zu erklären. Daran wird die Leistung der Module die physikalische maximal mögliche ist ermittelt. Hier wird mit Standart-Parametern wie 22,5% Effizient, Durschnittlicher Temperatur, echt pp.. eine sehr komplexe Berechnung durchgeführt.
Das ist auch eine Art “Clipping” damit die Integration sich selber heilt und vor Unsinn bewahrt, auch um die Range zu bestimmen in der die Anlage sich theoretisch bewegen kann. nimmt man dann die tatsächlichen Werte (live) und den Max-Peak hinzu sowie astronomische Daten - um nur einige Datenpunkte zu nennen - lässt sich voraussagen bei welchem Sonnenstand, zu welcher Jahreszeit, bei welchen Wetterbedingungen, … muss sich die Range von X-Y bewegen.
ahh okay.. nun verstehe ich was du meinst.. !!! Nein, das ist nicht der Grund! Die Ausreisser in den ersten 3-4 Tagen kommen eben genau aus dem Grund das ein Lern-Prozess stattfindet. Damit diese Ausreißer (in Wirklichkeit sind es Schätzungen, da nicht genügend Daten vorhanden sind) nicht uferlos werden, ist die KWP von entscheidender Bedeutung
um nun alle völlig zu verwirren Das ist nur einer der Schutzmechanismen .. es gibt eben auch noch Safeguard 2.0 der ML basiert ist und anhand der KWP und Vergleichen eingreift um ML zu dämpfen…
2025-11-13 20:54:36.405 INFO (MainThread) [custom_components.solar_forecast_ml.forecast.forecast_orchestrator] ML accuracy (94.8%) below threshold (75%). Applying aggressive ML damping: 13.9% ML / 86.1% Rule-Based (raw_weight=0.927)
2025-11-13 20:54:36.405 INFO (MainThread) [custom_components.solar_forecast_ml.forecast.forecast_orchestrator] 🛡️ SAFEGUARDS ACTIVE: Diversity | Final ML weight: 5.0% (protecting against poor predictions)
So ich veröffentliche gleich den Release-Candidate… der erstellt die korrekte Struktur, das Logging ist auf normal -level und die Fehler sind gefixt… den sollten wir alle dann mal bis Sonntag laufen lassen (es sei denn es ist etwas Kritisches) und mal schauen..
Er wird auch die "nicht mehr kompatiblen Samples entfernen und ML Reset durchführen.. damit ist denn der finale Schritt zum DB-Wechsel vollzogen und alle kritischen und wichtigen Daten werden lokal mit Historie gespeichert.
ACHTUNG: DIESES IST EINE BREAKING-CHANGE VERSION!
Ziel: sauberes Sammeln und speichern von Sample aktuell im November ca. 10 Stk pro Tag und keine i/o Blocking-Fehler mehr
Es wurde also mehr oder weniger “blind” geraten. Das ist aber in der Update-Version anders… hier war es notwendig zu testen