Hallo,
Sorry, ich dachte wenn ich mich an den offenen Fall mit anhänge ist das ok und es braucht keine neue Anfrage.
Ich gehe davon aus, dass dies die Zeile im Log trifft:
2026-04-24 23:30:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks
- INFO - Excluded hours info for 2026-04-24: 10/24 (41.7%), reasons: {‘mppt_throttled’: 10}
und 10 Stunden weil von 14:00 Uhr bis Mitternacht gerechnet, oder?
Auch mit der aktuellen Version V20.2.2 tritt die Fehlermeldung bei großen Anlagen weiterhin auf. Offenbar konnte bislang keine Lösung gefunden werden. Ich geb‘s jetzt auf.
Ich warte seit fast zwei Monaten auf die Rückmeldung von den Logs. Ich denke das ist ausreichend Geduld. Das soll auch keine Kritik sein. Wenn der Fokus mittlerweile woanders liegt, ist das auch ok. Dann brauch ich bloß nicht bei jeder neuen Version eine Rückmeldung geben, ob das Update den Fehler behoben hat. Dann kann ich mir die Arbeit auch sparen.
Bei mir läuft Solar Forecast ML nun seit etwas mehr als 2 Wochen. Anfänglich waren die Prognosen relativ gut, aber in den letzten 5 Tagen sind sie durchweg viel zu hoch. Meine Anlage hat 6 kW Peak und schafft zu Spitzenzeiten knapp über 40 kWh. Schon für die letzten 3 Tage und auch für die nächsten Tage wurden bzw. werden geradezu absurd hohe Werte prognostiziert. Sollte ich SFML vielleicht neu aufsetzen? Hier ein Screenshot (oben Solcast, unten SFML).
Hier die aktuelle Prognose für heute. Zwischen 11 und 17 werden konstant 6 kW vorhergesagt. Und dann nochmal der Buckel um 19 Uhr mit 4.6 kW. Wo sollen die um diese Zeit noch herkommen?
Warte erst einmal ab.
Den Buckel haben momentan mehrere, woher er kommt ist aktuell noch nicht ganz klar.
Die Genauigkeit hat bei mehreren nachgelassen, auch hier ist noch nicht klar warum.
Donnerstag Nacht soll ein Update kommen, hier sollen Entitäten und Attribute hinzu kommen, die das Problem eingrenzen soll.
Hallo @Rainman67
Danke für deinen Screenshot, aber ich verstehe ihn nicht - er sagt mir nichts.. kannst Du bitte die Orgiginal IST/ Prognose aus Stats zeigen, damit ich sehe wie hoch die Abweichung gewesen ist? Bitte auch welches System Du nutzt, es ist nun mehrfach bei Proxmox zu bisher nicht erklärbaren Abweichungen gekommen. Ralf hat recht ich versuche gerade die Fälle einzugrenzen. Daher bitte zusätzlich die Information:
der obere Screenshot zeigt im oberen Teil die Prognose von Solcast, der untere Teil zeigt die derzeit von SFML prognostizierten Werte. Das Ganze wurde nur über eine spezielle Karte ansprechend visualisiert.
Die Frage mit der Original IST/Prognose ist eine gute, denn ich kann diese in STATS nicht finden, obwohl ich sie konfiguriert habe.
Mit den Begriffen “Inverter-Clipping” und “Mppt-Throtteling” kann ich ehrlich gesagt nichts anfangen.
Ich nutze Home Assistant, der nativ auf einem Mini PC läuft (ohne Proxmox).
vielen Dank für deine schnelle Antwort! Selbstgebaute Karten sind wirklich toll, und ich habe großen Respekt vor jedem der sich die Mühe macht. Allerdings ist es so, dass nicht alle auf die korrekten DB-Werte zugreifen, ich nicht weiß woher die Werte kommen.
Bei der Fehlersuche, ist es daher wirklich wichtig das ich die original Werte von SFML sehe (Prognose vs IST) Du findest sie an vielen Stellen in Stats zum Beipiel hier:
Bitte lass dich nicht von einer abweichenden Ansicht des Screenshots irritieren, das ist bereits eine Fortgschrittenene Version die auch den Verlust durch MPPT-Throtteling ausgibt.
MPPT-Throtteling = Wenn Du Nulleinspeisung angeklickt hast
Inverter Clipping = Wenn Du ein maximale Einspeiseleistung angegeben hast - was nur in sehr seltenen Fällen wirklich nötig ist
Ich habe weder Nulleinspeisung angeklickt, noch eine maximal Einspeiseleistung.
Nachtrag: wenn die für heute, morgen und übermorgen vorhergesagten Werte so bleiben, dann werden auch da wieder sehr große Abweichungen erzielt werden.
Alles klar, dass hilft mit schon einmal weiter! Also die Prognose ist nicht stabil, sondern schwankt sehr stark. Alles im Bereich von 0 - 15 % Abweichung ist mehr als gut.. dazu habe ich einen ausführlichen Artikel geschrieben. Alles über 20% deutet auf ein Problem hin (wie bei Dir zu sehen).
Wichtig Du kannst nicht SolCast mit SFML vergleichen, das habe ich auch in dem Artikel beschrieben - wo die Unterschiede liegen.
Also lass uns mal ein wenig tiefer eintauchen, wass bei Dir ein Problem sein könnte. Kannst Du mir dazu bitte das LOG von SFML (per PN) schicken? Du findest es unter config/solar_forecast_ml/logs - bitte nicht hier öffenltich im Chat
Ich habe es mir nun zum wiederholten Male im Code angesehen, offensichtlich haben die Core-Änderungen nicht das gewünschte Ergebniss gebracht. Im kommenden Release habe ich noch einmal nachgeschärft. Sollte das Problem dann noch immer bestenen, müssen wir tiefer in deine Konfiguration einsteigen.
Ich habe mir die “Buckelwal” Problematik noch einmal im Code angesehen und auch mit Timmy gesprochen
Es ist ein Phänomen, dass ich bisher noch nicht klar eingrenzen konnte. Aktuell schaut es danach aus, dass es mehr ein Darstellungsfehler ist, dessen Grund ich noch nicht verifizieren konnte / eindeutig belegen. - Besonders, da es nur vereinzelnt auftritt und mir nicht genügend Daten vorliegen um es klar einzugrenzen. Es ist die berühmte Suche nach der Nadel im Heuhaufen. Bitte etwas Geduld ich habe es auf dem Zettel, aber bin noch keinen Schritt weiter.
Erster Ansatz (Test) Rand-Nullen nicht als echte Datenpunkte setzen.. ob das die finale Endlösung ist, kann ich nicht 100% abschätzen.
Alles gut, ich sehe das auch nicht als Kriegsentscheidend an - es sei denn so krass wie zuletzt
Wenn ich dir bei der Suche helfen kann, sag bitte Bescheid.
Ich wollte mir mal einen ApexChart erstellen, der die Werte aus der hourly_predictions zu den von fsml Tatsächlichen Werten und Vorhersagen aufzeigt. Ich verspreche mir davon eine bessere Übersicht über die ermittelten Werte TFS, AI, Phsics, LSTM und Ridge und wie die sich auswirken. - Auch in Bezug auf schlechtere Genauigkeiten. Du zeigst die Werte ja bereits im Popup des Graphen an, aber ich würde das gerne mal im Zeitstrahl sehen.
Könnte das was bringen?
Nur leider komme ich diese Woche kaum dazu - Rentner haben nie Zeit, ich habe das auch immer angezweifelt…
Prinzipiell ist es eine gute Idee, aber die Gewichtung der einzelnen Prognose-Layer ist pro Panegruppe, pro Stunde unterschiedlich. Daher ist das nicht so einfach umzusetzen.
Auch darf man nicht vergessen, dass z.B. die TFS-Werte (wie auch alle anderen) RAW-Werte ohne jedwede Anpassung sind. Daher ist es eher zweifelthaft was es bringt diese anzuzeigen.
Ein seperates DB-Feld für die " auf die Anlage und Örtlichkeit" angepassten Layer gibt es nicht.
Dieses einzuführen, würde durch die Berechnung vermutlich für einen Großteil der Nutzersysteme überlassten (einzelne Berechnung pro Layer / Gruppe / Stunde/..) daher ist der Gesamtgraph auch nur eine P50 Quantille und nicht die exakte Darstellung der Werte, das würde nicht funktioineren!
Daher.. ehrliche Tipp: Lass es und spare Dir die Mühe, das Ergebniss ist eher zweifelhaft und keine belastbare Aussage..
Aber ein BUG ist das nicht.. daher hier etwas “falsch”
Moin aus dem Norden @Tom-HA …
ich habe mir das “Timmy-Buggel”-Problem mal bei mir angesehen. Wie du ja weißt nutze ich zur Visualisierung nicht die SFML-Stats. Du schreibst, dass es nach einem Darstellungsproblem ausschaut. Dieses dürfte dann doch aber nur in SFML-Stats auftreten - oder?
meine Beobachtung:
Bis 23.04. (also vor Installation TFS) war die Prognose ziemlich genau und steigend. Ab 24.04. ist eine kontinuierliche Abnahme der Vorhersagegenauigkeit zu erkennen.
22.04. … 79,13%
23.04. … 79,29%
24.04. … 79,06%
25.04. … 79.02%
26.04. … 78,58%
27.04. … 78.01%
Auch hatte ich den Eindruck, dass bis zum 23.04. SFML sogar das Einsetzen der Nulleinspeisung berücksichtigte (Batterien voll geladen - Abnahme der tatsächlichen Erzeugung). Dies ist in den Graphen gut erkennbar.
Nach der TFS-Installation, ab 24.04. ist das nicht mehr so.
Es drängt sich also der Verdacht auf, dass “Timmy” etwas mit der TFS-Installation zu tun hat.
Vielleicht hilft meine Beobachtung ja bei der Fehlereingrenzung.
DB kann ich zusenden … einfach melden wenn nötig
by HarryP: Code-/Logzeilen formatiert (bitte immer in </> einbinden)
