Das Kernproblem ist, dass ich wirklich zu wenig Daten habe. Wie bekannt: ist die gesamte Integration lokal bei euch auf dem Rechner verortet.
Bei mir selbst tritt das Problem auf keinem der 3 Testsysteme auf - was aber nicht zwangsläufig bedeutet, dass es nicht ein verdecktes Problem gibt.
Bisher sind mir 4 Nutzer bekannt, die von diesem Problem berichtet haben.
Was ich schon klar formulieren kann, ist das bei Custom-Cards die auf die falsche Stelle in der DB zeigen das Problem logisch ist. Jedoch zeigt sich das Problem auch in STATS, das sauber codiert ist.
Einen Kontext mit TFS schließe ich aus, da es sich nur um einen Layer handelt.
Ich untersuche gerade den Code in Richtung der Quantille (P10 - P90) ob die zu früh gekappt werden (oder zu spät) und so zu einem Overfit auf der Zeitachse führen. Daher auch der Hinweis mit den Nullstellen.
Daszu habe ich eines meiner Testsysteme mit Mock-Daten gefüttert um einen sauberen Traceback zu haben.
Ganz genau @Kaysen899 es geht um den abendlichen Buckel-BUG bei einigen Systemen und dessen Grund. Liegt es in SFML oder Stats, ist es ein TFS oder Quantil-Problem, ist es reproduzierbar.
mal daran gedacht, das vielleicht nur die sonne von irgendwas reflektiert wird (fenster oder sonst was von nachbargebäuden).
finde das ist logisch bei ost/west anlagen, wenn der winkel und die höhe der sonne passt.
Unterschied: System 1 hat von Anfang an alle Sensoren (Ecowitt)
System 2 hat seit 1 Woche eine Wetterstation, voher nur Temp, Feuchte, Druck
System 3 hat nur Temp, Feuchte, Druck
So ich denke ich habe es gefunden! Im kommenden Update ist ein Fix enthalten. Aber ich kann nicht 100% bestätigen das es abschließend gefixt ist! Wir müssen das gemeinsam im Auge behalten.
@Kaysen899 kannst Du das bitte auf Deinem Live-System und deinem Test-System nach dem Update beobachten?
@alteMade → deinen wirkich heftigen Buckel von vor ein paar Tagen sollte es in der Zukunft nicht mehr geben.
Ich hake den BUG dann nun erstmal ab.. aber bleibt bitte dran!
Wttr (Icon) hat die Struktur seiner Daten geändert. Das sollte eigentlich mit der aktuellen Version behoben sein! Kannst Du mir bitte sagen, welche Version das ist?
@Tom-HA kleiner Schönheitsfehler, oder wie auch immer man das bezeichnen mag:
Kannst du ggf. beim nächsten Update die Kommastellen der Prozentangaben auf eine kürzen? das wird bissl unübersichtlich
Ich weiß, dass kann ich auch selbe in der Einstellung der Anzeigegenauigkeit, hab aber das Gefühl, dass es sich nach jedem Update wieder zurück stellt…
Mit der aktuellen Version 20.4.0 habe ich immer noch das Problem, dass sich die Werte beim Drift Monitor nicht ändern, bis auf die Anzahl der Drift Events.
Hallo @Tom-HA ich greife das Thema noch einmal auf, weil ich heute erneut einen hohen Buckel habe, auch gestern war er wieder - leichter - zu sehen. Du hattest irgendwo geschrieben, das es eventuell nur ein Anzeigefehler ist, wenn ich mir jedoch die Fläche unter dem Buckel ansehe, so ist es in etwa der Betrag den mir die Prognose zu viel anzeigt. Meine Überlegungen dazu:
Ja, ich habe in der ganzen Zeit Sensoren geändert
Ja, ich habe in der Zeit die Konfiguration geändert (1 Gruppe “Total” auf zwei Guppen geändert). Das war am 16.2.
Du schriebst irgendwo, das die morgendlichen und abendlichen Stunden vom lernen ausgeschlossen werden, kann das ein Grund dafür sein das SFML die Randstunden nicht korrekt lernen kann?
Ich hatte bis zum 1.1. einen falsch konfigurierten Sensor drin, der mir die Energieabgabe des Speichers mit in die Solarerzeugung addiert hat (AC-Sensor bei DC-Batterie).
Mein erstes Diagramm, welches ich mir anzeigen lassen kann, ist vom 29.11.
Vorhersage heute: der Buckel hat eine Höhe von 5,34 kWh von 82,3kWh → max. 6,5% Fehlermöglichkeit in der Prognose:
Ich reite nur deshalb auf dem Buckel rum, weil es ja immer wieder mal vor kommen kann, das man die Konfiguration ändert, ein Sensor defekt ist, …
In dem Fall wäre es ärgerlich, wenn man die Datenbank komplett löschen müßte und man alle gesammelten Daten verliert. Ich für meinen Teil werde wegen der Buckel nicht die Datenbank löschen, ich kann damit gut leben.
Sehe meinen Beitrag hier nicht als Kritik, sondern als einen Versuch SFML besser zu härten.
Ich bin mal auf dein “Korrekturtool” gespannt, von dem du geredet hast und ob man damit dieses und auch andere Probleme gut mit lösen kann.
vielen Dank für die Verlinkung des Beitrags. Ich habe ihn gelesen, aber konnte nicht entnehmen, warum z.B. der 7 Tage MAE dauerhaft statisch bleiben und sich nicht verändern soll, so wie es bei mir der Fall. Seitdem ich die Integration im Februar eingerichtet habe, haben sich diese Werte noch nie verändert.
… Kleiner Bonus-Fact: Wttr lässt nur noch Polls für 3 Std zu also nicht mehr für 72 Std.
