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.