SFML: Bug? Samples erhöhen sich nicht mehr wie gewohnt

Guten Morgen,

ich habe folgendes “Problem” auf meinem Live System seit dem Update auf 18.2.0. (oder kurz davor 18.03.)

Es werden pro Tag nur noch 4-5 Samples Produziert und nicht mehr um die 13.

Auf dem Pi wird weiterhin der Counter um 13 erhöht.

Ist das auch bei anderen und woran kann das liegen?

Danke und Gruß

Guten Morgen @Kaysen899

danke für die detaillierte Aufstellung — das hilft sehr bei der Analyse.

Was die “Samples”-Zahl bedeutet: Das ist die Anzahl der Trainingsdatenpunkte, die beim täglichen Modell-Training verwendet werden. Pro Tag kommen normalerweise ~13 neue Stunden dazu (= Produktionsstunden am Tag).

Warum nur 4-5 auf x86: SFML hat einen Learning-Filter, der Stunden mit ungünstigen Bedingungen vom Training ausschließt — z.B. bei Wetteralarmen (plötzliche Wolken), Inverter-Clipping, oder MPPT-Abregelung (z.B. durch Batterie/Zero-Export). Auf schnellerer Hardware (x86) kann es durch Timing-Unterschiede im HA Event-Loop dazu kommen, dass diese Exclusion-Flags häufiger gesetzt werden als auf dem langsameren Pi.

Zur Diagnose — könntest du bitte folgendes SQL auf deinem x86-System ausführen?

SELECT target_date,
       COUNT(*) as total,
       SUM(CASE WHEN actual_kwh > 0 THEN 1 ELSE 0 END) as mit_produktion,
       SUM(CASE WHEN exclude_from_learning = 1 THEN 1 ELSE 0 END) as excluded,
       SUM(CASE WHEN has_weather_alert = 1 THEN 1 ELSE 0 END) as wetter_alert,
       SUM(CASE WHEN mppt_throttled = 1 THEN 1 ELSE 0 END) as mppt_gedrosselt,
       SUM(CASE WHEN inverter_clipped = 1 THEN 1 ELSE 0 END) as clipped
FROM hourly_predictions
WHERE target_date >= '2026-03-17'
GROUP BY target_date ORDER BY target_date;

Zugriff: sudo sqlite3 /config/solar_forecast_ml/solar_forecast.db

Damit sehe ich exakt, welche Stunden ausgeschlossen werden und warum. Ich vermute, dass auf dem x86 deutlich mehr Stunden mit has_weather_alert oder mppt_throttled geflaggt sind als auf dem Pi.

Hast du auf dem x86-System eine Batterie oder Zero-Export konfiguriert, die auf dem Pi fehlt? Das wäre der häufigste Grund für den Unterschied. - Ist es die Anker-Integration die in den letzen Tagen / Wochen öfter mal nicht erreichbar gewesen ist.

Das Training selbst funktioniert korrekt — es werden nur weniger Samples verwendet.

Kein Zero Export und keine MPPT Drosselung aktiv!

Das Training geht ohne Fehler durch, es sind einfach nur weniger Samples pro Tag mehr als sonst.

Möglich kann auch das sein.
Neuerdings werden Wolken als “Verschattung” erkannt. Hier ein Beispiel von heute, am Vormittag bedeckt, jetzt Sonne.

@Tom-HA ein Update.

Leider weiterhin das gleiche Bild. Es werden nur 5 Samples generiert.
Auf dem Pi weiterhin 14

Bei mir sind es auch aktuell immer so 3 - 5 Samples die nur generiert werden.

Ich habe im Schnitt gerade nur 2 Samples auf 2 Rechnern (1x Proxmox, 1x Bare) mit 18.6.0, davor aber auch nur wenige Samples nie arg viel mehr.
Sogar -1 Sample hatte ich die Tage mal.

Wenn das Wetter stabil ist und es wenig Änderungen gibt werden die Samples auch weniger würde ich sagen.

Bitte auch die früheren Antworten beachten.

Da ja mein Pi lustig 14 Samples dazurechnet hat es nichts mit dem Wetter zu tun.

Korrekt.. dein " Live-System" läuft länger und kennt daher mehr.. ich glaube ich schalte die Sample-Anzeige wieder ab, wie schon mal im Beta-Test das scheint nur zu verwirren und das Verständnis wie sie generiert werden, bzw wann scheint trotz zahlreicher Erklärungen irgendwie nicht korrekt verstanden zu werden. :frowning: oder meine Erklärungen sind nicht verständlich genug.. ich versuche es noch einmal:

Sample wird nur gelernt / taucht auf wenn eine signifikante Veränderung erkannt wurde.

  • 3 Tage gleiches Wetter = Null Samples
  • Bekanntes Wetter = Null Samples
  • Unbekannte Situation = Sample
  • Unbekanntes Wetter = Sample
  • System ohne externe Sensoren = mehr Samples bis Situation klar ist
  • System mit externen Sensoren = weniger Samples da eindeutiger
  • EOD ohne externe Sensoren = länger rechnen da “Actuals” berechnet werden (Sensoren simuliert)
  • EOD mit exterenen Sesoren = kürzerer EOD da keine “Actuals” berechnet werden müssen:-)
  • einfache Anordnung der Panels = wenige Samples
  • komplexe Anorderun der Panels = mehr Samples
  • 1 Gruppe = weniger Samples
  • x Gruppen = mehr samples

viele Samples = Unbekanntes Wetter + Unbekannte Situation + Keine externen Sensoren + komplexe Anordung + x Gruppen + Frisch aufgesetzt

Weniger Samples = Ki gut Kalibriert ect.. pp

Fazit
Wenn die Sample-Amzahl abnimmt.. Epochen abnehmen → Alles perfekt KI hat gelernt Varianz + Loss + MAE passt und es ist aktuell keine Verbesserung mit den aktuellen Meßdaten zu erwarten.. Sample wird verworfen → Selbstschutz (early stopping)

Bei gleichem System

4 „Gefällt mir“

Dann habe ich deinen ersten Antwort Post falsch verstanden.

Zusätzlich hab ich dann das Update falsch verstanden. Da hattest du geändert, das nach 30 Tagen Samples verworfen wurden.

In meiner Logik hab ich dann verortet, dass dann alles gesammelt wird, trotz gleichem Wetter.

1 „Gefällt mir“

Ahh.. okay nun verstehe ich was Du meinst! Ja es werden keine Samples mehr verworfen, um den Lernfortschritt / das Gelernte nicht mehr zu vergessen und alle 30 Tage wieder von vorn zu beginnnen.. Zum beispiel plötzliche Wintereinbruch im April oder warme Tage im März.. das ist ja auch genau der Grund warum die Samples deutlich höher sind.

2 „Gefällt mir“

Dann passt es ja.

Dann komme ich mit dem x86 System langsam an die Schallmauer.

Und der Pi, dadurch das er keine “externen Sensoren” nutzt brauch viel mehr Samples. :+1:

2 „Gefällt mir“