Hallo zusammen,vielleicht habe ich da was überlesen,aber ist es richtig,das der Button ”Erweiterte Analyse-Charts” im SFML Stats Dahboard keine Funktion hat ?
Hier auch ohne Funktion
Wurde vor ca. 2-3 Stunden schon einmal erklärt… ich weiß das es hier langsam unübersichtlich wird, aber trotzdem sollte die Suche helfen. Es bringt nichts immer wieder die gleichen dinge zu posten / schreiben.. da verliere ich den Überblick und übersehe vielleicht einen wirklichen Fehler der im Code und nicht beim User liegt..
Ich habe schon mit einem Admin gesprochen wie man es besser organisieren kann
habe mal im Thread gesucht - denke das sollte noch stimmen:
Noch mal eine Erklärung von Tom dazu
Für den Sensor “Gesamt-Tagesverbrauch (kWh, optional)” benötigst du einen Sensor, der die gesamte Energiemenge misst, die dein Haus an diesem Tag verbraucht hat.
Hier sind die genauen Anforderungen:
Was er messen muss: Den Gesamtstromverbrauch deines Haushalts (nicht nur den Netzbezug, sondern alles, was verbraucht wurde).
Einheit: Die Einheit muss kWh (Kilowattstunden) sein.
Typ: Es muss ein Sensor sein, der seinen Wert täglich um Mitternacht zurücksetzt.
2 „Gefällt mir“
Danke Dir - auch wenn es für mich nach wie vor nicht ganz klar ist…
Ich würde es jetzt mal so verstehen, dass es ohne Netz zu Batterie ist (obwohl das ja eigentlich auch einen Verbrauch darstellt).
Die Sache mit der nicht funktionierenden “Erweiterte Analyse-Chart” hab ich tatsächlich nicht über die Suche gefunden und die letzten 4 Stunden hab ich durchsucht…
Bitteschön 
und in den Release-Notes zu 16.0 steht da auch noch was
hast du einen Lösungsvorschlag bekommen? Ich hatte schon vor Monaten Simon42 diesbezüglich kontaktiert, allerdings keine Antwort erhalten
Nein, @Tom-HA macht einen Vorschlag und ich setzt ihn nächstes Wochenende zusammen mit ihm um.
@Chris33
Wenn Du solche Anfragen über den „Melden“-Button machst, anstatt per Mail oder PN, dann bekommst Du vom TEAM schneller eine Antwort.
@simon42 hat viele andere Dinge um die Ohren und ist deshalb nicht so oft hier wie das Moderatoren-TEAM. 
Okay, dann ging es aber um eine neue Funktion im Forum bzw. der Forensoftware.
Was ich mit Tom besprochen habe, ist eine neue Struktur für sein Projekt und die Aufteilung in mehrere Threads - das kann ich mit Mod.-Rechten machen, für Deine Anfrage bedarf es leider Admin-Rechten. Sorry!
Im Netzbezug ist doch die Ladung der Batterie inkludiert wenn sie vom Netz kommt. Oder fällt der Strom vom Himmel? Oder ich verstehe nicht genau was du meinst.
Eben nicht Genau das war ja meine Frage! Dort den Netzbezug eintragen oder nur den Hausverbrauch.
Es wird nach Tagesverbrauch gefragt.
Netzbezug: Alles, das vom Netz bezogen wird (Grid Import) - entspricht aber nicht dem, was vom Dach kommt oder von der Batterie - außer, man addiert das in einem Sensor dazu - also Netzimport+Batterie zu Haus + PV zu Haus.
Hausverbrauch: Alles, was das Haus verbraucht - also von PV direkt, von der Batterie und vom Netz - aber dann ohne das, was vom Netz in die Batterie fliest, denn das ist erstmal kein Verbrauch - denn von der Batterie wird es ja dann später “nochmals” verbraucht…
So ganz klar ist das nicht - und das kann man so oder so interpretieren -macht aber einen riesigen Unterschied, wenn man die Batterie ständig vom Netz läd.
2 „Gefällt mir“
Aber einig sind wir uns darin, das im Netzbezug die Ladung der Batterie inbegriffen ist, wenn sie über das Netz stattfindet
Es ist eben die Frage, was er haben will… Gar nicht so einfach - es wundert mich, dass sich da anscheinend fast niemand Gedanken macht, denn für die Statistiken ist das elementar.
Was er messen muss: Den Gesamtstromverbrauch deines Haushalts (nicht nur den Netzbezug, sondern alles, was verbraucht wurde).
Das heißt für mich dann: Netzbezug nur dann, wenn er auch verbraucht wird!
Also in dem Fall nicht das, was zu Batterie fliest (denn das wird nicht verbraucht).
Das wäre ja dann sozusagen doppelt. weil es später von der Batterie ja nochmals verbrauch wird.
Ich habe jetzt den reinen Hausverbrauch eingetragen - also einen Sensor, der PV zu Haus, Batterie zu Haus und Netz zu Haus addiert. Nicht mit enthalten sind in diesem Sensor: Netz zu Batterie.
Das ist für mich der eigentliche Hausverbrauch.
Stand Bug-Fixes:
- Die Schatten-Erkennung wertet jetzt jede Panel-Gruppe einzeln aus, statt alle gleich zu behandeln
- Das AI-Training ignoriert jetzt Stunden mit fehlenden Wetterdaten, statt mit Nullen zu trainieren
- Die Strahlungskorrektur bei tiefem Sonnenstand wendet den gelernten Faktor jetzt auch wirklich an
- Der Sensor “Prognose Beste Stunde” wird jetzt nach jeder Morning Routine aktualisiert und bleibt nicht mehr stehen
- Der gelernte Solar-Korrekturfaktor wurde unter einem anderen Namen gespeichert als gelesen — dadurch war der Faktor immer 1.0 (keine Korrektur) und die Vorhersage systematisch zu hoch. Gleiches galt für den Temperatur-Offset
- Wenn die Globalstrahlung (GHI) per Korrekturfaktor reduziert wurde, blieben Direkt- und Diffusstrahlung (DNI/DHI) auf den unkorrigierten Rohwerten. Das führte zu physikalisch unmöglichen Zuständen und massiver Überschätzung der Physics Engine bei geneigten Panels
- Ein Datenbankfehler im Performance-Learning erzeugte bei jedem Lernzyklus neue Einträge statt bestehende zu aktualisieren. Die Lern-Tabellen liefen voll mit Duplikaten und lieferten veraltete Gewichtungen
Wichtige Verbesserungen:
- Die Frostklassifizierung unterscheidet jetzt korrekt zwischen leichtem und starkem Frost
- Die Schatten-Erkennung ist bei bewölktem Himmel strenger geworden, um Fehlalarme zu vermeiden
- Das LSTM-Modell fängt ungültige Werte (NaN/Inf) ab, bevor sie Unsinn produzieren
- Die maximale kWh-Grenze pro Stunde passt sich jetzt an die tatsächliche Anlagengröße an
- Der DNI-Tracker merkt sich den Höchstwert des Tages, statt ihn versehentlich zu überschreiben
- Die Ridge-Regression optimiert den Alpha-Wert jetzt über alle Panel-Gruppen hinweg
- Die Berechnung der besten Produktionsstunde funktioniert jetzt fehlerfrei mit der Datenbank
- Rolling Averages der Wetter-Precision schlossen Korrekturfaktoren mit dem exakten Wert 1.0 fälschlicherweise aus, was zu unvollständigen Durchschnittswerten führte
- Der Tagesenergiezähler wurde auch dann gespeichert, wenn kein passender Vorhersage-Eintrag existierte. Das kWh-Delta dieser Stunde ging dann unwiederbringlich verloren
- Vergiftete DNI-Maximalwerte aus der Zeit vor der Strahlungskorrektur werden beim Start automatisch erkannt und zurückgesetzt
- Bereits gespeicherte Tagesfaktoren mit fehlerhaften Werten werden beim Start aus den korrekten Stundenwerten neu berechnet
- Bestehende Duplikate in den Learning-Tabellen werden beim Start erkannt und einmalig zurückgesetzt, damit sie mit korrekten Daten neu aufgebaut werden
Feinschliff:
- Die Disagree-Penalty zwischen LSTM und Ridge passt sich jetzt proportional an die Abweichung an
- Der Schneeschmelz-Fortschritt berücksichtigt jetzt die Panel-Neigung bei steigenden Temperaturen
- Die Ridge-Regression hat eine leichte Bias-Regularisierung bekommen für mehr Stabilität
- Die Ensemble-Gewichtung nutzt jetzt einen Fallback über alle Gruppen, bevor sie auf Standardwerte zurückfällt
- Fehlende Attention-Gewichte werden erkannt und sauber deaktiviert statt zufällig zu bleiben
- Panel-Gruppen werden automatisch neu geladen, wenn sich die Konfiguration ändert
- Schneebedeckung wird früher aufgehoben, wenn ein Panel sichtbar produziert
- Outlier-Erkennung unterscheidet jetzt zwischen leichten und schweren Ausreißern
- Ein kleiner Type-Hint Fehler wurde korrigiert
STATS:
- Dashboard aktualisiert sich jetzt zuverlässig — Manchmal wurden neue Werte zwar geladen, aber nicht auf dem Bildschirm angezeigt. Das ist jetzt behoben.
- Grafiken werden wieder korrekt dargestellt — Einige SVG-Elemente im LCARS-Dashboard wurden vom Browser falsch interpretiert und sahen kaputt aus.
- Pop-ups sind wieder sichtbar — Dialogfenster konnten sich hinter anderen Elementen verstecken und waren nicht anklickbar. Jetzt erscheinen sie immer im Vordergrund.
- Fehlermeldungen bleiben sichtbar — Wenn ein Fehler auftritt, wird die Meldung jetzt auch dann angezeigt, wenn das Dashboard gerade neu lädt.
- Allgemeine Stabilität verbessert — Das Layout des LCARS-Dashboards wurde grundlegend überarbeitet, damit es auf verschiedenen Geräten zuverlässiger funktioniert. @Joachim-xo
- Komplette Überarbeitung des CSS und VUE um die CPU-Last zu reduzieren
- Memory-Leaks behoben
- Wettersymbole überarbeitet
- Tag/Nacht funktioniert wieder
HINWEIS:
Automatische Korrekturen beim Update
Folgende Reparaturen laufen beim ersten Start nach dem Update vollautomatisch ab — es ist kein manueller Eingriff nötig Start kann verzögert sein ja nach HW - kein Crash zu erwarten HA regelt die Tasks!
Proxmox-Nutzer bitte den Container im Auge behalten - ich habe es extra auf zwei Tasks aufgeteilt, damit er durchläuft und nicht denkt " HA hängt" 1x kurz beim Start und dann 1x Backgroud! Damit sollte verhindert sein das Proxmox abwürgt (fehlende Kommunikation zwischen HOST und HA
Sofort beim Start (Migration):
- Historische Tagesfaktoren der Wetter-Korrektur werden aus den vorhandenen Stundenwerten neu berechnet, da sie durch den Schlüssel-Fehler (Nr. 5) bisher falsch gespeichert waren
- Die Learning-Tabellen für Performance-Learning und Ensemble-Gewichtung werden einmalig zurückgesetzt, wenn Duplikate aus dem NULL-Bug (Nr. 7) erkannt werden
- Der DNI-Tracker prüft alle gespeicherten Maximalwerte und setzt unrealistisch hohe Einträge (>200 W/m²) automatisch auf Null zurück
Beim nächsten End-of-Day Lauf (23:30):
- Die Performance-Learning Tabelle wird mit korrekten Daten neu aufgebaut — basierend auf den jetzt sauberen Physics-Werten nach der Strahlungskorrektur (Nr. 6)
- Die Ensemble-Gewichtung (LSTM vs Ridge) lernt ebenfalls frisch, jetzt ohne Duplikat-Fehler
- Der DNI-Tracker sammelt ab sofort korrekte Werte und baut seine 7-Tage-Historie neu auf
Über die nächsten 7 Tage:
- Die Rolling Averages der Wetter-Precision füllen sich schrittweise mit korrekten Korrekturfaktoren
- Der Solar-Korrekturfaktor konvergiert auf den tatsächlichen Wert (statt 1.0)
- Die DNI-Tracker Historie erreicht nach 7 Tagen wieder volle Abdeckung
Zusammengefasst: Nach dem Update und einem HA-Neustart repariert sich das System selbstständig. Die Vorhersagegenauigkeit verbessert sich sofort deutlich und erreicht nach ca. 7 Tagen ihr volles Potenzial, wenn alle lernenden Komponenten ihre Historie neu aufgebaut haben.
STATUS: Testphase und Debugging laufen aktuell
5 „Gefällt mir“
Dann stellst du diese Erklärung in Frage. Da kann vermutlich nur einer etwas zu sagen. Ich verstehe aber dein Ansinnen
1 „Gefällt mir“
Vielen Dank!
Kurze Frage: Ist das hier ein kleiner Bug? Sensor liefert Werte. Da sollte doch aktuell was angezeigt werden, oder?
Ich kann deine Überlegungen gut nachvollziehen. Die Netzladung der Batterie wird in Kostal System ja zweimal als Hausverbrauch gezählt; einmal beim Netzladen und zum zweiten Mal bei der Endladung der Batterie, der Hausverbrauchssensor, weiß ja nicht aus welcher Quelle die Batterieladung kommt.
Ähnliche Probleme entstehen, bei der aktuell noch nicht möglichen Nutzung der Autobatterie, vehicle to grid(kann zuvor aus Netzstrom, PV oder extern geladen sein).
Ich denke inzwischen es gibt Grenzen der Darstellungsmöglichkeiten.
Zudem gibt es hier im Forum ja unterschiedlichste Schwerpunkte bzw. Interessenslagen.
Balkonanlagen versus größere PV Anlagen, hoch IT affine Proxmoxer(ich bitte vorab um Vergebung) versus Laptopnutzer.
Mit und ohne Batteriespeicher, e-Auto, Wärmepumpe, beheizter Pool und oder Fusionsreaktor.
EInfach mal abwarten…
2 „Gefällt mir“
Das Problem ist, dass es möglich ist es aufzusplitten aber das würde von dem Nutzer verlangen entsprechende Sensoren anzulegen.
STATS kann das nicht erledigen ohne Werte, da STATS keine eigenen Sensoren erstellen kann. Daher habe ich darauf zunächst verzichtet.
Aber das ist trotzdem nicht die Antwort auf seine Frage.. der Wert ist 0 weil keine Solar-Erzeugung in den Akku fließt..