Bei mir waren da noch nie Werte, in sofern alles gut…
EOD lief auch gut, ich mach mir nur etwas Sorgen da bei mir schon 4 Drift Events waren, vermutlich alles die Tage wohl nun die Sonne schien.
Auch scheint die Genauigkeit die letzten Tage auch wieder massiv gesunken zu sein wo nun wieder etwas mehr Sonne schien (gestern Prognose 10,2kwh, erzeugt über 25 kWh) aber ich schiebe es noch darauf das der die Sonne noch erst Kennenlernen muss.
Glaub ich muss mich jetzt dann von meinem „Green“ verabschieden 
EOD nach dem Update dauerte bis 00:49 Uhr ! Lief aber anscheinend durch.
Daraufhin konnte er um 00:30 natürlich auch keinen Forecast erstellen. Hat er heute Früh aber dann nachgezogen. Nur aktuell steht jetzt das Model wieder bei „ physics“.
Mal abwarten
hier auch alles super. Keine Fehler im Log erkennbar.
Kein DB lock oder sonstwas. Einwandfrei. Nur den PIN häte ich noch gern 
Hier muss die KI jeden Tag ordentlich dazu lernen. Die Prognose haut keinen Tag hin.
Mal startet die prognose zu spät und die sonne kommt zu früh, mal ist es genau andersrum. Mal erwartet die KI nur 10 kwh und es werden 25 … dann wieder genau umgedreht … erwartet werden 25 und es werden nur 5. Da ist noch Luft nach oben bzw. braucht dann doch deutlich mehr Lerndaten. Wahrscheinlich wird das erst mit einem stack von 1 Monat an Grunddaten einigermaßen genau und selbst dann ist noch viel Luft nach oben.
Gestern wars zum ersten Mal 85 % Genauigkeit. Bei mir lernt die KI seit 12 Tagen. Aber klar, das ganze sammelsurium von Variablen und deren minima, maxima und vor allem die kleinen abstufungen zwischendrin muss die KI erstmal lernen.
Ich werde den EOD aufsplitten, damit die Greens, Yellows und PI`s nicht so sehr daran “knabbern” müssen…
So, mit neuer Hardware war der gestrige EOD nur noch 63 Sekunden lang (Ryzen 5 7430U 6C/12T wovon HA 4 Kerne und 8GB RAM nutzen darf) - das ist doch mal was.
Schnee hat er mir auch genannt - stimmte auch - 25cm sind über Nacht gefallen - mal sehen wie er damit klar kommt, dass meine Panele nun trotzdem frei sind - ein Hoch auf Panele die an der Terrasse hängen und binnen 2 Minuten freigeräumt werden können. 
Pi5,8GB, SSD:
2026-02-19 23:30:50 - INFO - End-of-day workflow completed (15/15 steps, 50.7s)
2026-02-16 23:30:22 - INFO - End-of-day workflow completed (15/15 steps, 22.4s)
2026-02-17 23:30:14 - INFO - End-of-day workflow completed (15/15 steps, 13.8s)
2026-02-18 23:30:07 - INFO - End-of-day workflow completed (15/15 steps, 7.1s)
2026-02-19 23:30:39 - INFO - End-of-day workflow completed (15/15 steps, 39.2s)
Bei mir lief der EOD gestern abend 1118s 
(VM auf J5005)
Das Epoch Learning hat sehr viel Zeit in Anspruch genommen
J5005:
2026-02-17 23:32:30 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - End-of-day workflow completed (15/15 steps, 149.9s)
2026-02-18 23:33:06 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - End-of-day workflow completed (15/15 steps, 186.1s)`
2026-02-19 23:48:57 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - End-of-day workflow completed (15/15 steps, 1137.5s)
by HarryP: Code-/Logzeilen formatiert (bitte immer in </> einbinden)
s.a.: (Neues Update & Features - Hier in der Community 🫶)
by HarryP: Code-/Logzeilen formatiert (bitte immer in </> einbinden und nicht als Bild)
s.a.: (Neues Update & Features - Hier in der Community 🫶)
EOD 48,2s; NUC7I5BNK, 16 GB RAM
Hab ein Proxmox-System mit dem etwas schwächeren JD4105. Da hat’s 1472 s gedauert.
Auf Bare Metal (alter Ryzen Prozessor) war es heute aber auch deutlich länger als sonst (270sek vs. 30sek)
2026-02-19 23:34:29 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - End-of-day workflow completed (15/15 steps, 268.8s)
Der “ganz kleine” (alter LESv3), Bare_metal hat beim gestrigen EOD 2104s gebraucht, auch da haben die “custom_components.solar_forecast_ml.ai.ai_tiny_lstm” lange gebraucht.
vorher war der EOD auf der Kiste bei ~180s
mal schauen wie sich das entwickelt, vermute mal durch das Update hatte die Ki bissl mehr zu tun als sontst
by HarryP: Code-/Logzeilen formatiert (bitte immer in </> einbinden)
s.a.: (Neues Update & Features - Hier in der Community 🫶)
EOD ohne Problem.
End-of-day workflow completed (15/15 steps, 84.3s) 253 Samples.
status=success, state=ok
Proxmox VM
Nach Auswertung der Feedback-Mails zeigt sich ein klarer Trend. Die Performance-Unterschiede beim täglichen Abschluss-Task (EOD) hängen massiv an der Hardware-Infrastruktur und weniger am Skript selbst.
Fazit:
Es ist oft nicht der Task sondern das langsame Wegspeichern.. das kann man sehr gut erkennen, schaut man ins LOG und sieht beim EOD " Databank locked" und zig retries.. das geht die Zeit verloren und ist ein untrügliches Zeichen, dass man seine Konfiguration mal grundsätzlich überdenken sollte - um zukunftssicher und stabil unterwegs zu sein. - völlig unabhängig von SFML.
Kleiner Pro-Tip: Wenn es länger dauert mal ins LOG von SFML schauen config/solar_forecast_ml/log seht ihr da etwas von " Databank locked skipping…" dann ist es genau der Punkt “das system schaufelt die Daten nicht schnell genug weg” ihr solltet dann aber auch sehen, dass das Skript sich selbst " heilt" und es solange versucht bis es klappt. Oft ist es ein SWAP-File Problem durch zu wenig RAM.
Es ist kein Fehler.. sondern eine Info und zeigt das meine Skripte die korrekte Info an HA senden " Hey alles cool.. nicht abwürgen - ich brauche noch einen Moment"
Absolut richtige Einschätzung! Genauso ist es! Neue Lernmethoden, neue Parameter, Migration, ect… das will erstmal verarbeitet werden! - ist aber nur einmalig!
Eigentlich sollte sich jeder GLANCES unter HA einbinden. Das Tool zeigt das alles sehr übersichtlich an… Ich habe auch die Tage meinen RECORDER aufgeräumt. Die MARIADB war auf 7GB aufgebläht, jetzt sind es noch 1,8 GB. I/O-WAIT ist nicht Dein Freund!!! Die 7GB hatten mir einen heftige I/O-WAIT beschert!!! Ohne GLANCES hätte ich es nicht so schnell gemerkt.
GLANCES hat mir schon oft geholfen, wenn HA sich “merkwürdig” verhält!! 
Wenn MARIADB immer knapp unter 100% (manchmal auch drüber) liegt, habt Ihr definitiv ein Problem!!!
immer interessant zu sehen, wie die systeme “ackern” müssen … meiner dümpelt nur bei 1-2% rum … Frage mich dann immer, was die so machen !?
Ganz genau!!! Ich meine, klar KI Training braucht Ressourcen - logisch - sicherlich auch mehr als via Shelly eine Steckdose anzuschalten, aber der Kontext ist wichtig! Eine riesige zugemüllte HA DB oder am besten noch eine HA-DB + InFlux-DB und sind schon die Show-Stopper. Das sieht man auch gut an der DB von SFML die ist winzig mit ihren durchschnittlich 4MB - 20MB (nach einem Jahr) gegenüber den z.T. ineffizienten Datengräbern im GB- Bereich. Wenn dann auch noch ungewollte Abstürze oder Blocking-Calls dazu kommen (sehr gut im HA Log zu sehen).. zwingt das das komplette System in die knie!
Glanzes zeigt einen sehr wichtigen Wert " SWAP" das ist der beste Indikator ob mein System für das was ich damit mache ausreichend RAM hat. Reicht der RAM nicht, wird ein SWAP-File geschrieben - langsam und Bremse!
Hier muss man differenzieren: Die reine CPU-Auslastung in Prozent ist bei Storage-Operationen oft zweitrangig. Entscheidend ist nicht, wie sehr der Prozessor ‚schwitzt‘, sondern wie hoch der I/O-Durchsatz und die Latenz beim Wegschreiben der Daten sind.
Technisch gesehen ist die CPU-Last ein schlechter Indikator für die System-Performance, wenn der Flaschenhals bei den IOPS (Input/Output Operations Per Second) liegt. Am Beispiel eines NAS mit zwei Platten im RAID 1: Hier muss jeder Schreibvorgang auf zwei Spiegelplatten synchronisiert werden, was Overhead erzeugt. Wenn darauf zusätzlich zwei VMs laufen, teilen sich insgesamt drei Instanzen die begrenzte Bandbreite und die Schreib-Lese-Köpfe der Festplatten. Das führt zu sogenannten I/O-Waits, bei denen die CPU quasi untätig auf die Bestätigung vom Speicher wartet – die Auslastung bleibt niedrig, aber das System fühlt sich trotzdem quälend langsam an. Am besten auch noch “verschlüsseln” 
Ich persönlich würde NIEMALS auf die Idee kommen auf einem System mit Intel Celeron Jxxx eine VM zu werfen. Das war vor einigen Jahren überhaupt kein Problem, aber heute ist es einfach Unsinn. Es sei denn… mehr als 16GB RAM und SSD.. dann könnte man darüber reden
Gleiches gilt für Raspberry.. Super Teile.. aber heutzutage da noch ein heftiges VM draufzulegen… Nein-Danke! (aber das ist wie immer meine persönliche Erfahrung / Meinung)
Ein sehr nützliches Tool für die Planung eines RAID:
Meine Synology DS923+ mit AMD Ryzen R1600, 32 GByte Ram, SSD Cache 2 TByte und HA (2 CPU und 8 GByte) läuft eigentlich ganz gut.
2026-02-19 23:32:35 - custom_components.solar_forecast_ml.production.production_scheduled_tasks - INFO - End-of-day workflow completed (15/15 steps, 155.3s
Danke für die genaue Erklärung bzgl. Technischer Fakten.
