Hier mal lesen 
Danke!!
Das hatte ich nicht gesehen.
@Tom-HA Das Verhalten hat sich leider auch mit den letzten Updates noch nicht geändert. Bei mir werden die stark verschatteten Stunden ausgeschlossen, genauso als ob ich Nulleinspeisung aktiviert habe. An Tagen mit Wolken, werden die Stunden nicht ausgeschlossen.
Wenn ich nun Nulleinspeisung aktivieren würde, obwohl ich keine habe, dann wäre das aktuelle Verhalten, diese Stunden auszuschließen, ja richtig. Aber ich möchte ja gerade, dass diese Stunden gelernt werden, damit die dauerhafte starke Verschattung am Nachmittag/Abend gelernt wird.
Auch wenn ich nur langsam UpToDate komme,
habe ich mal heute die Logs Überflogen.
Sind folgende Punkte auf dem Schirm?
EOD:
2026-08-05 23:30:09 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric global/7/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:09 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric global/14/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:09 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric global/30/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:09 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric global/60/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:09 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric Gruppe 1/7/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:10 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric Gruppe 1/14/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:10 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric Gruppe 1/30/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:10 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric Gruppe 1/60/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:10 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric Gruppe 2/7/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:10 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric Gruppe 2/14/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:10 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric Gruppe 2/30/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:10 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - DEBUG - Rolling metric Gruppe 2/60/None failed: ‘NoneType’ object has no attribute ‘rowcount’
2026-08-05 23:30:10 - custom_components.solar_forecast_ml.ai.ai_drift_monitor - INFO - Drift detection complete: 12 metrics saved, 7 events created
2026-08-05 23:30:01 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - AI model training skipped: candidate shadow evaluation pending for c06363b8-e3f9-487e-a417-d83f791eb880
Das schaut verdammt nach der alten Version aus! Hast Du 42.0.2 dann würde es bedeuten das der DB-Vertrag und auch das zentralisierte Schreiben noch nicht stabil ist
Ich habe darüber auch mit @wagner-heist gesprochen. Der wichtige Punkt ist, erst nach dem EOD heute Abend ist 100% klar ob der Fix greift. Ein vorab simulieren des EOD bringt an dieser Stelle wenig, da ich auch wissen muss ob der sheduler automatisch und korrekt funktioniert. - Aber was ich simulieren kann, das habe ich auch getan.. aber spannend ist der EOD heute.
Es sollte auch das Problem von @greteOne lösen.
Welcome back 
Ja, ist auf dem Schirm.
Deswegen das Update auf V42.0.2.
Hier hat es Tom auch schon erklärt:
https://community.simon42.com/t/bug-solar-to-house-kwh-solar-to-battery-kwh-uebersteigt-solar-yield-kwh/90302?u=johnny_1993
suprise, dieses olle HACS.
dann schnell das Update laden.
bin auf 42.0.0.0
Denn Thread hab ich gelesen @Johnny_1993 aber nicht connected!
1 Woche Urlaub und diese Woche 53h und immer ab 3 Uhr dienst. Mein Hirn ist mariniert in Melatonin.
kenn ich.. ich habe auch keinen Urlaub mehr.. ist komplett für SFML draufgegangen und ich kann / muss immer nach Feierabend fixen - oder / und in der Mittagspause antworten 
geteiltes Leid ist halbes Leid…
Hallo und danke für die Aufnahme.
Ich hoffe ich bin hier richtig mit meiner Frage.
Bei mir fehlen ende Juni einige Tage. Da war nach einem Update ein wechsel eines Sensors nötig und das hatte ich erst ein paar Tage später bbemerkt.
Nun ist eine Differenz zum HA Energie Dashboard im Juni von knapp 900kWh.
Diese 900kWh fehlen nun bei SFML-Stats.
Gibt es für einen “nicht Crack” eine Möglichkeit dies zu korrigieren?
Würde mich freuen wenn jemand Hilfestellung geben kann.
Gruß Renso - aus dem Welzheimer Wald.
Hallo @Renso willkommen in Simons Forum!
Nein eine derartige Möglichkeit gibt es leider nicht. Das hängt damit zusammen das Home Assistant Sensoren anhand von selbstvergebenen sog. Meta-ID in seiner Datenbank speichert. Ebenso (je nach Einstellung durch Dich) auch über mehrere Tabellen und Spalten hinweg.
Ich und einige andere haben bereits im November 2025 als SFML das Licht der Welt erblickte versucht mittels kleinen Python-Skripten Daten zu importieren. - Das ist im völligen Chaos geendet.
Ich experimentiere aktuell mit einer Hilfstabelle, stehe aber wieder vor dem selben Problem.
Sorry
Gibt es eigentlich irgendwo hier eine Einrichtungsanleitung? Online Doku ist ja leider offline.
Ich hab das Ganze soweit installiert, dass es unter Einstellungen - Devices & Service - Devices auftaucht, aber dann hörts bei mir auf…
Gruß
Torsten
Hallo Torsten, willkommen in Simons Forum,
ja es gibt ein Handbuch das findest du auf der Startseite von STATS direkt unter Hubbles Erklärungen und Wirkungsgrad.
Zara
Ich bin zu doof, kannst Du es mir verlinken?
Hallo in die SFML-Runde!
Ich bin vor ein paar Wochen von iobroker auf Home Assistant umgestiegen. SFML war auch ein Grund dafür. Diese Integration macht Spaß, auch wenn sie für mein Setup wohl noch einiges lernen muss.
Allerdings ich habe ein Regen-Problem. Verwendet wird der Netatmo Regenmesser, der eine Tages-Summe und die aktuelle Niederschlagsmenge in mm als Sensor zur Verfügung stellt. Die Anbindung an SFML hat von Anfang an nicht richtig funktioniert. Werte kamen nur sporadisch und unvollständig. Mit dem Update auf 42.0.2 sind die historischen Werte verschwunden. Neue kommen nicht mehr nach, egal welchen Sensor ich einbinde.
Außerdem habe soll es hier täglich 5-12 mm Regen geben mit Hinweis auf widersprüchliche Quelldaten. Laut Kachelmann passiert hier bis nächsten Sonntag in Sachen Niederschlag gar nichts.
Wo könnte das Problem liegen?
Home Assistant läuft hier als Hyper-V VM. Derzeitiger Stand ist 2026.8.1 für HA und 42.0.8 für SFML.
Danke schon mal im voraus für die Hilfe und Entschuldigung, falls die Lösung schon irgendwo steht und ich sie übersehen habe. 
Ich meine es benötigt einen Event-Rain-Sensor - also mm/h, z.B. wie z.B. von Froggit/Ecowitt bereitgestellt.
Bei netatmo; mal kommen die Werte nach 45 Minuten, mal gar nicht.
Genau so ist es.
Lieber keinen Sensor angeben, als einen, der schlechte Werte liefert. Das vergiftet die Datenbank und damit dann SFML.
Ich Glaube, das liegt an Hubble, also der KI. Wenn ich es richtig interpretiert habe, prüft diese alle Sensoren und Werte auf Plausiblität und ob diese korrekt sind. Dies wird zum Schutz vorm lernen falscher Werte / Zustände gemacht.
Ist jetzt die Frage, wie viele Wochen du schon gelernt hast.
Was du machen kannst: Frage bitte @Tom-HA, ob er deine Datenbank einmal analysieren kann, wie Stark das bisher Einfluss auf die gelernten Sachen hat. Im besten Fall kann er deine Datenbank korrigieren und die falschen Daten entfernen.
Im schlechtesten Fall musst du noch einmal neu Starten mit dem Lernen.
Gruß
Johnny
Vielen Dank schon einmal für Eure Antworten.
Ich hatte bisher nicht beobachtet, dass die Daten für den Sensor unzuverlässig kamen.
Den Hinweis auf mm/h hatte ich auch schon einmal gelesen und es mit einem Hilfssensor versucht, der mm in mm/h umrechnen sollte.
Wenn der Netatmo-Regensensor grundsätzlich nicht funktioniert, muss ich das so akzeptieren und mich eventuell nach einer Alternative dazu umschauen.
Keine Verschlimmbesserung Hilfssensoren für SFML, nur valide Reale…