SFML: Feedback und Problemberichte zum aktuellen Release

Solar Forecast ML Entwicklung & Bugs
954

Ich halte euch hier auf dem laufenden und antworte auf meinen eigenen Post.. dann kann derjenige von euch den es interesssiert hier gern mitverfolgen…

  1. Der Riemann (Tageszähler) weicht für saubere Daten enorm ab. Das summiert sich. Bei zum Beipeil 4 Gruppen sind es 5 unterschiedliche Werte. → hier liegt das erste Kernproblem.
  2. Es gibt zeitliche Sprünge in den 5 Sensoren die ebenfalls fatale Fehler verursachen.
  3. Gesamt-Power ist deutlich dynamischer als der Energy-Zähler in HA selber mitbekommt. SO weichen Cloud-Daten (Hersteller WR) von HA Daten ab. Beispiel: Stunde 15 von 0.74 auf ca. 0.8045 das summiert sich über alle 5 Sensoren und führt z.T zu einem negativen Dirft
  4. Dieser Drift potenziert sich dann über die Tage / Monate, da er jede Stunde auftritt.
  5. Dieses würde ggf auch erklären, warum bei einigen Nutzern die Prognosen trotz korrekter Sensoren nicht korrekt laufen. → Könnte auch auf Leistung des HOST basieren ein X86 ist schneller als ein PI oder Green… DAS MUSS ICH ÄNDERN

Es ist also richtig, sellbst zu rechnen in echtzeit anstatt auf HA Riemann zu vertrauen

Der Verdacht ist nun bewiesen:
wenn der Code es berechnet, werden die Fehler sichtbar (Stichproben heute):

  • Stunde 09: Power (Code) 0.4591 vs DB (HA Riemann)0.5900, deutliche Abweichung
  • Stunde 10: Power (Code) 0.9974 vs DB (HA Riemann)0.8600, deutliche Abweichung
  • Stunde 12: Power (Code) 1.1950 vs DB (HA Riemann)1.3300, deutliche Abweichung
  • Stunde 15: Power (Code)0.8045 vs DB (HA Riemann) 0.7400, deutliche Abweichung
  • Stunde 14: Power (Code) 1.1466 vs DB (HA Riemann) 1.1300, nah dran

Ein Test auf den gestrigen Tag zeigt eine gesamtabweichung von gerundeten 140 Wh bei einer 2kwP Anlage (!!!)

Damit ist es bewiesen: Es ist besser, der Code berechnet kWh anhand der Powersensoren selbst..