Hallo @klausn
Bitte keine LOG-Dateien öffentlich im Thread / Forum anhängen. Sie enthalten persönliche / vertrauliche Daten. Ich habe einen Moderator gebeten diese zu löschen.
LOG Daten bitte nur nach Aufforderung per PN.
Zu Deinem “Peak” immer zur vollen Stunde +5 Min wird die vorangegangene Stunde berechnete (Actual IST) wenn in der Zeit neugestartet wird, dann wird es addiert.. das ist kein Problem.. sieht nur unschön aus. Du musst nichts machen
die waren anonymisiert. Keine Location enthalten. Sonst hätte ich die nicht angehange.
aber das sieht aus, als wurde der ganze tag aufaddiert, nicht nur die stunde.
by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)
SFML mag offensichtlich keine Reboots - gleicher Effekt bei mir heute.
Was in der einen Stunde/Phase fehlt, wird in der Nächsten offensichtlich aufaddiert.
Viel mehr Fragezeichen habe ich bei der täglichen Prognose - gleichbleibend ählich gutes und stabiles sonniges Wetter die letzten Tage, aber die tägliche Prognose geht nicht hoch.
Das ist in der Tat schon bekannt.. schau mal bitte ins Update-LOG wurde schon gefixt
schließe mich hier an.
es werden täglich 1-3h täglich vom lernen ausgeschlossen wegen (Schnee/Frost), ob wohl nur nacht, flacher sonnenwinkel und geringe einstrahlung als verschattung angezeigt werden.
Gleicher Punkt.. wurde bereits gefixt schau mal bitte ins Update Release da ist es drin:
ca. 10 bis 11 Sekunden
Das Veröffentlichungs-Intervall ist auf 10 Sekunden eingestellt.
Betrifft alle Sensoren, die per MQTT von EMS-ESP kommen
Ich hab das gleiche Problem. Während des EOD Task bricht die Modbus Verbindung zu meinem Huawei Inverter ab. Außerdem funktioniert die Integration von meinem Auto währenddessen nicht mehr. Dort bricht auch die Verbindung ab (ClientConnectionResetError - Cannot write to closing transport). Die Sensoren bleiben so lange bei mir nicht verfügbar bis der EOD Task beendet ist. Sobald er fertig ist, geht es wieder. Prozessorauslastung während des EOD liegt bei mir bei 30% und Arbeitsspeicher ist auch noch genügend verfügbar. System: Raspberry 4
Schaut bitte in das Update-LOG 
Ich habe einen Zwischenstep im Eventloop eingeführt. → brauch nicht mehr weiter gepostet zu werden. Fix ist bereits gemacht
Wurde der Fehler „Unusually high hourly production for group“ in der neuen Version 18.0.0 auch behoben oder steht er noch auf der to-do Liste? Ich konnte den Release Notes das nicht entnehmen bzw. hab auch nicht alles verstanden.
Hab mit Version 16.8.6 immer noch diese Meldung wie bei Vally. Konfiguration wurde schon überprüft. Bei mir hat er es heute ab einer Produktion von 10,3 kWh pro Stunde gemeldet. Die Anlage ist aber eine 18 kWp Anlage. Im Sommer habe ich noch höhere Erträge pro Stunde als nur 10 kWh.
Bei mir ist das Gleiche. Ich hab eine 10,4 kWp Anlage und laut Prognose die letzten Tage (seit Update) nur max. 5,1 kWh 
(an den Sensoren hab ich nichts geändert)
Schick mir bitte mal dein LOG ich denke Du hast ein anderes Problem!
Same here.. bitte via PN das LOG
Ums es noch zu vervollständigen. Es ist tatsächlich so, dass der Ertrag vom gestrigen Tag aufsummiert wurde und demzufolge doppelt so hoch ist, wie er sein sollte bzw. überhaupt sein kann.
Das führt natürlich zur Verfälschung der Statistik
In solchen Fall, ist es sinnvoll, wenn du es gestern noch gesehen hast. Einmal den Schalter “Lernen pausieren” zu aktivieren, damit er den Tag nicht lernt.
Geht natürlich nur an dem Tag und nicht rückwirkend.
Dieser Fehler stammt von einer benutzerdefinierten Integration
Logger: custom_components.solar_forecast_ml.data.db_manager
Quelle: runner.py:289
Integration: Solar Forecast ML (Dokumentation, Probleme)
Erstmals aufgetreten: 4. März 2026 um 10:17:00 (3 Vorkommnisse)
Zuletzt protokolliert: 4. März 2026 um 16:31:30
DB locked (attempt 1/5), retrying in 0.29s: database is locked
DB locked (attempt 1/5), retrying in 0.22s: database is locked
DB locked (attempt 1/5), retrying in 0.26s: database is locked
2026-03-05 10:00:00 - custom_components.solar_forecast_ml.data.data_weather_pipeline_manager - DEBUG - Pipeline: Tracked actual weather - temp=3.2C, clouds=52%
2026-03-05 10:05:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - DEBUG - Executing hourly update
2026-03-05 10:05:00 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - DEBUG - Panel group actuals for hour 9: {'Gruppe 1': 0.4985, 'Gruppe 2': 0.1679}
2026-03-05 10:05:00 - custom_components.solar_forecast_ml.production.production_morning_routine - DEBUG - Panel group actuals updated for 2026-03-05_09: 2 groups
2026-03-05 10:05:00 - custom_components.solar_forecast_ml.production.production_morning_routine - DEBUG - Shadow detection for 2026-03-05_09: heavy (30.3%)
2026-03-05 10:05:00 - custom_components.solar_forecast_ml.core.core_helpers - DEBUG - ensure_local: Naive datetime, localizing to local timezone
2026-03-05 10:05:00 - custom_components.solar_forecast_ml.data.data_weather_kalman - DEBUG - Kalman update: residual=53.5, bias=17.8, K=0.131, P=97.1, R_eff=742.8, updates=3
2026-03-05 10:05:30 - custom_components.solar_forecast_ml.data.db_manager - WARNING - DB locked (attempt 1/5), retrying in 0.28s: database is locked
2026-03-05 10:08:29 - custom_components.solar_forecast_ml.forecast.forecast_weather - DEBUG - Background forecast update starting...
2026-03-05 10:08:29 - custom_components.solar_forecast_ml.forecast.forecast_weather - INFO - Force update - fetching from Open-Meteo API...
2026-03-05 10:08:29 - custom_components.solar_forecast_ml.data.data_open_meteo_client - INFO - Saved 72 hours to weather_cache_open_meteo table (RAW)
2026-03-05 10:08:29 - custom_components.solar_forecast_ml.data.data_open_meteo_client - INFO - Fetched 72 hours from Open-Meteo (GHI: 0 - 562 W/m2)
2026-03-05 10:08:29 - custom_components.solar_forecast_ml.forecast.forecast_weather - INFO - Force update successful: 72 hours
2026-03-05 10:08:29 - custom_components.solar_forecast_ml.forecast.forecast_weather - DEBUG - Background update complete: 72 hours
Könnte man nicht einen separaten Parameter in der Konfig einfügen mit der man das maximal mögliche der eigenen Anlage (bei mir hier 21.93kWh) als Begrenzungswert nimmt und dann alles was höher ist automatisch ausblendet/vom Lernen ausschließt?
Hier mal meine Daten von 01/2025 an bis heute.
Man könnte das sogar über eine automation triggern. Aber ob das sinnvoll ist. Hmmm
@Tom-HA dein Part.
Ggf. Die Diskussion in einen extra Thread besprechen? Damit der Bug Tacker frei bleibt?
Man gibt doch bereits den Wert bei der Panelgruppe ein!
Aber: Auch wenn eine Anlage auf 21.93kWh theoretisch ausgelegt ist, so machen die Anlagen auch gerne mal etwas mehr oder weniger. So wie ich Zara verstanden habe verwirft er bei sehr hohen Abweichungen sowieso die Werte, aber nicht bereits hart bei der Grenze.
Jede Panele ist mit einer Leistungsangabe versehen, aber mit einer gewissen Toleranzangabe.
Wir hatten das auch einmal in einem Lifetalk Thematisiert, aber im Grunde wollte niemand einen harten Schnitt.
Gruß Ralf
Das passiert bereits! Das machen die Safeguards!
