hi zusammen,
kurzes feedback zu der aktuellen diskussion: ich werde die änderung nach meinem urlaub wieder rückgängig machen. es ist kein bug!!!
mein ziel war es eigentlich, sowohl den live-wert als auch den letzten riemann-lauf der vollen stunde anzuzeigen. aus entwicklersicht und mit dem technischen hintergrundwissen, wie home assistant den riemann-integral aktualisiert, ergab das für mich sinn. mir ist jetzt aber klar geworden, dass diese kombination eher verwirrt, weil nicht jeder auf dem schirm hat, dass der riemann-wert nur zur vollen stunde aktualisiert wird.
entschuldigt bitte das missverständnis, das war keine absicht. alternativ überlege ich aktuell, so etwas zukünftig eher als pro-version für power-user anzubieten ich kümmere mich direkt nach dem urlaub darum!
Wie wäre es, wenn es erst einmal nur genauer beschrieben wird?
Hubble * Ich schaue mit * Livedaten
Tagesprognose vs. Ist * Stundenbasiert
Das müßte Platzmässig doch passen. Die Grafik bei der Tagesprognose ist ja ebenfalls Stundenbasiert. Vielleicht verstehen es die User dann von alleine.
auf dem pc ja.. mobil eher nicht.. aber du hast im kern einen guten punkt. ich befürchte nur, dass es trotzden verwirrend ist für die nutzer die nicht wissen was der unterschied zwischen riemann und echtzeit (in diesem fall riemann delta) ist.
zu anfang hieß der text " live" und die diskussion war die selbe.. daher denke ich es macht mehr sinn es ganz raus zu nehmen und in eine pro-version zu packen. das problem ist auch die außenwirkung… “geht” nicht oder “fehler” erweckt den eindruck das es “nicht geht” aber der code ist in diesem spezillen fall m.e. aktuell nicht das problem. das löst auch keine andere beschriftung.
du hast natürlich 100% recht, stats ist stundenbasiert, anders geht es auch nicht! der code arbeitet auf stundenbasierten vergleichen. vergleich bedeutet es müssen werte vorhanden sein um vergleich zu können. da kwh leistung pro std ist muss die stunde erst “vergangen” sein und ha muss den riemann berechnet haben.. live ist das direkte delta im riemann - eben live.. wobei das auch nicht ganz korrekt ist, da das delta bei live auch erst berechnet wird (alle 60 sek).
hubble schaut also im 60sek takt und stats zwangsläufig im std. - wie du korrekt gesagt hast.
die idee dahinter war besser abschätzen zu können wohin entwickelt es sich und das hubble warnen kann - schneller reagieren kann. z.b. " achtung deine solaranlage ist ausgefallen" .. oder achtung etwas stimmt nicht"" .. dafür ist ein blick in die vergangenheit von 1 std einfach zu lang. echtes live mit echten live wetterdaten wäre natürlich premium, würde aber erheblich mehr leistung kosten..da sind wir dann wieder bei sinnvoll / wunsch / leistung und realität.
seit dem stimmen beide Anzeigen (SFML und STATS wieder überein. Die angezeigten 31,1 und 23,44kWh entsprechen den Vorhersage (heute) Sensor von heute morgen und jetzt. Was heute morgen bei STATS stand, kann ich aber nicht mehr sagen. Laut Log müsste es 22.07kWh gewesen sein…
Das Problem wie @Heatseeker habe ich heute auch, ich glaube, das gab es in den letzten Tagen auch schon mal.
Tagesprognose im Sensor in ML zeigt einen deutlich anderen Wert als der Maximalwert des Heute (Rest) Sensors und die Anzeige in Stats. Dabei scheint mir der Maximalwert des Heute (Rest) Sensors und der Wert in Stats beim heutigen Schmuddel-Wetter passender zu sein. Auf meinem zweiten Test-System habe ich das Problem witziger Weise nicht. Beide SFML Stats und ML Version: 26.4.0
Kommt hier vielleicht irgendwas wegen Nebenläufigkeit oder so durcheinander? Bei meinem Testsystem (hat den Fehler nicht) sehe ich den Hinweis ✓✓✓ ALL MORNING TASKS COMPLETED SUCCESSFULLY! ✓✓✓ ganz am Ende, also als letzte 5:00 Uhr Log-Eintrag, da geht es dann um 5:05 weiter. Hier auf dem Echt-System mit dem Problem liegt er mittendrin, anschließend noch drei Forecast complete Meldungen, die erste mit 10,80 kWh und gefolgt von custom_components.solar_forecast_ml.data.data_manager - DEBUG - Saved forecast day: 10.80 kWh (source: fallback_open_meteo_startup_recovery), die anderen beiden mit 4.19 kWh ohne Saved forecast day Einträge.
@Tom-HA : wenn ich irgendwelche größeren Logausschnitte bereitstellen soll, sag gern bescheid.
hab gerade gesehen, dass es wieder ein neues Release gibt, welches gerade installiert. Ist damit das Problem, welches ich und auch @pmcl gesehen hatten, dass die Prognose in Stats und SFML nicht übereinstimmten behoben? Man könnte das so reininterpretieren…
Heute hatte ich es zumindest wieder gehabt, dass die beiden Prognosen auseinander gingen…
aber das habe ich auch gelesen. Wenn du nun den ganzen Text verlinkst hilft das auch nichts wenn ich es überlesen haben sollte. Oder willst du mir sagen, dass es nicht behoben wurde da es dort nicht steht???
Die Änderung mit den Riemann kann es nicht sein, einzig und allein, dass SFML nun das führende Element ist und Stats sich aus der DB bedient.
Aber bei uns war ja eher das Problem, dass es laut SFML Log zwei unterschiedliche Prognosen hintereinander im SFML Log gab welche dann bei SFML und Stats angezeigt wurden, also für mich immernoch unklar.
Falls ich es überlesene haben sollte gerne den entsprechenden Ausschnitt posten.
Hintergrund zu mehreren Forecasts:
Das Log-File gibt bewusst die rohen, zeitlich versetzten Forecast-Einträge aus, bevor diese durch den Blend-Algorithmus in der Morning-Routine gelockt oder durch ein Re-Forecast verarbeitet werden. Diese hohe Detailstufe im Datenstrom ist im DEBUG- oder INFO-Level essenziell für das Tracing von Code-Pfaden und die Performance-Optimierung während der Testphasen. Für Endanwender ohne tiefes Verständnis der Codebase ist dieser Output nicht relevant; für die Fehlersuche und Beta-Tester ist er jedoch unverzichtbar.
Ist TFS-HA aktiv, landet im Blend (LOG) zusätzlich der RAW-Layer kumuliert auf 72 Stunden. Dabei handelt es sich um die 4 -Head Transformer-Ausgabe.
Verwendung (Single Source of Truth):
Für die reguläre Home Assistant / STATS-Anzeige ist ausschließlich der finale Wert entscheidend, den Solar Forecast ML an den SOT-Sensor (Source of Truth) publiziert und der dort fixiert wird.
Coordinator-Fallback-Verhalten:
Der Coordinator triggert unter spezifischen Bedingungen (wie asynchronen Update-Lags, I/O-Timeouts oder SQL-Exceptions) gezielt redundante Backbone-Forecasts. Dadurch wird die Datenintegrität der Integration auch bei blockierenden Prozessen oder HA-Fehlern sichergestellt.
Bezug zum Riemann-Problem:
Während des Coordinator-Update-Zyklus wird der Drift zwischen den einzelnen Panelgruppen und dem kumulierten Gesamt-SOT-Yield mathematisch überwacht und abgeglichen, um Berechnungsfehler bei der Integralbildung zu minimieren. Daher war genau das auch ein zentrales Thema des großen Refactorings.
Fazit:
Kein Bug, sondern gewolltes Logging-Verhalten für Entwickler, Beta-Tester und Coder – für den täglichen Betrieb der normalen Nutzer ist das nicht relevant.
ich fürchte, hier sind ein paar Dinge Durcheinander geraten. Das Problem, was @Heatseeker und ich haben, sind keine unterschiedlichen Logmeldungen, sondern, dass das Ergebnis am Ende eben nicht konsistent abgelegt wird. Am einfachsten sieht man das an den Sensoren “Vorhersage (heute)” und “Vorhersage (heute Rest)”. Diese sollten sich ja am spätestens wenn die finale Vorhersage finalisiert wurde, initial nicht unterscheiden (bis die ersten Produktion rein kommt).
Bei mir unterscheiden sie sich auf dem Produktionssystem aber regelmäßig, ich meine aber auch nicht täglich. Und nein, das Problem ist mit Version 32 leider nicht behoben. Zur Verdeutlichung hier noch mal die beiden Verläufe:
Bisher hatte mein Testsystem diese Problematik nicht gehabt, trotz gleicher Konfiguration und Eingangsdaten, wie ich aber gerade feststellen habe, zeigt sich das Problem da heute ebenso (10,37 kWh vs. 7,54 kWh).
Ich hatte auch kurz die Hoffnung, dass es durch die SOT gefixed ist, aber auch bei mir heute ist erneut eine Diskrepanz zwischen den von dir genannten Werten und natürlich auch wieder zu Stats. Stats und Rest heute sagen: 38.8kWh und SFML sagt 42,4 kWh heute…
Das ist eine super Darstellungsform. Bei mir sieht es halt anders aus. Scheinbar seit dem 13.06.2026 ein Glücksspiel, ob die Werte in etwa übereinstimmen oder eben vollkommen auseinander liegen. In meinem Bild machen einige Neustarts es etwas unruhiger, dennoch denke ich ist klar zu sehen, dass es seit dem immer wieder falsch liegt, aber eben auch nicht immer.
Es gibt keine Glücksspiele! Code ist immer logisch, die Frage ist, wo bei Dir der Fehler liegt, was in deinem System anders läuft als z.b. @suedschwede und meinen Testsystemen - oder ob es eine logische Erklärung im Code selbst gibt
