Update:
Der vorherige Ansatz bereitet Probleme (Leistungsgreze) daher sind die Panelgruppen bei Verwendung von TFS wie folgt begrenzt:
1 PG = ARM, alte CPU`s ab 2026 wie beschrieben 4GB RAM
2PG = Alte CPU´s wie beschrieben kein ARM 6GB RAM
3PG = nur moderne CPU nicht älter als 2022 mind. i5 oder AMD Ryzen mind 6GB RAM
4 PG = nur moderne CPU 4 Core und mind 8GB RAM
Hallo, toll das Du das auch als Docker einzeln bereit stellst. Damit kann ich es vielleicht auch in meinen IOB integrieren und muss nicht mehr auf unzulängliche Cloudlösungen zurück greifen.
Ich habe gerade erst angefangen mich nun mit toorox foreSight auseinander zu setzen.
Ich hoffe ich kann es nutzen wie ich denke.
Ein paar Sachen sind mir eingefallen aber vermutlich ist das alles schon bedacht und diskutiert worden. Verzeiht mir da ich noch nicht besonders weit gekommen bin.
Es muss nicht kommentiert werden aber ich wollte es wenigstens mal los werden.
Vielleicht ist es ja hilfreich. Hier meine ersten Gedanken:
PS: Wenn ich es nutzen kann spende ich ein paar kg Kaffee 
Das kann ich mir vorstellen, uns beeindruckender wie viel du invertierst.
Ich werde erstmal beim HA-Addon bleiben, weil mein Proxmox Node mit Ressourcen am Anschlag ist. Sobald ich aber Upgrade werde ich umsteigen. Zusätzliche Unabhängigkeit von HA ist in meinen Augen was Gutes.
Ist sicherlich bekannt, aber falls nicht auf dem Schirm: wenn alles steht kann ja drüber nachgedacht werden es über https://community-scripts.org/ verfügbar zu machen.
Zu deinen drei Punkten — die sind tatsächlich alle bereits Teil meiner Architektur oder aktiv in Arbeit:
1. Vorjahresdaten zum Anlernen
Genau so funktioniert es. ForeSight wird mit einem vortrainierten Modell ausgeliefert, das auf synthetischen Solardaten von über 500 europäischen Standorten (18 Jahre pro Standort) gelernt hat. Beim ersten Start auf deiner Hardware macht es automatisch ein Fine-Tuning auf deine echten Produktionsdaten — je mehr Historie vorhanden ist, desto besser. 10+ Tage reichen für den Start, aber mehrere Monate machen das Modell natürlich deutlich robuster. Wenn du also Daten hast die du einspeisen kannst: perfekt, genau dafür ist der automatische Import-Mechanismus gedacht → SFML DATENBANK MUSS 100% sauber sein, sonst zerschießt es die Trainingsdaten, kein Sensor-Trouble, keine Fehlkonfiguration,..
2. Einzelne Panelgruppen separat lernen
Aktuell unterstützt das Modell bis zu 4 Panelgruppen mit individueller Ausrichtung, Neigung und Leistung. Das Pre-Training deckt bewusst verschiedene Konfigurationen ab (Süd, Ost, West, Flachdach), und das Fine-Tuning auf deiner Anlage lernt dann die spezifischen Unterschiede pro Gruppe — unterschiedliche Module, Verschattung, Inverter-Verhalten etc. Das Modell gibt pro Gruppe eine eigene Prognose aus, nicht nur einen skalierten Gesamtwert.-> exact so wie SFML
3. Leistungsstarkes Subsystem fürs Training
Sehr guter Gedanke, und genau das habe ich umgesetzt. Das Pre-Training (das rechenintensive Grundlernen auf den 500+ Standorte) läuft auf einer dedizierten AMD-Workstation mit 2 GPU. Ihr bekommt das fertig trainierte Modell und müsst nur noch das leichte Fine-Tuning auf seiner eigenen Hardware machen — das dauert auf einem normalen x86-System etwa 10 Minuten, kein GPU nötig. Ein Raspberry Pi 5 schafft das ebenfalls, dauert dann etwas länger. Die schwere Arbeit passiert also bereits bei mir (das Training).
Dein Szenario “RPI als Hauptsystem + AMD im Haus fürs Anlernen” ist ein interessanter Ansatz. Aktuell ist das nicht nötig weil das Fine-Tuning bewusst so leicht gehalten ist dass es auf dem Hauptsystem mitläuft — aber wenn jemand sehr viele Daten oder sehr häufiges Re-Training will, ist die Architektur dafür offen (HTTP-API, Checkpoint-Dateien sind portabel).
Kurz zusammengefasst: du denkst genau in die richtige Richtung. Das System ist darauf ausgelegt, lokal und privat zu laufen, aus echten Daten zu lernen, und auch auf moderater Hardware performant zu sein.
Bei Fragen zur ioBroker-Integration oder zum Docker-Setup: gerne melden.
Zara
Das ist genau der Grund warum ich es mache.. niemand weiß was die Amerikaner als nächstes mit HA vorhaben und echtes Open Source ist es schon lange nicht mehr. → das ist aber ein anderes Thema
Mein Plan ist eher, da es eine spezielle und mächtige AI ist, sie auf huggingface zu veröffentlichen und für HA als import via HACS (nur die Traiingsdaten, dass sollte nicht zu schwer werden - > aktuell beläuft sich die Größe auf ca. 100MB extahiert aus 500Mio + Datensätzen.. + die Bibliotheken und Skripte all in rund 200 MB Headless
Wobei das Plataue ist noch nicht erreicht..
Epoch train val Δ val * = new best
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1 0.1381 0.1423 — *
2 0.1270 0.1352 − 5.0% *
3 0.1218 0.1307 − 3.3% *
4 0.1189 0.1285 − 1.7% *
5 0.1172 0.1271 − 1.1% *
6 0.1160 0.1262 − 0.7% *
7 0.1152 0.1256 − 0.5% *
8 0.1147 0.1249 − 0.5% *
9 0.1142 0.1248 − 0.1% *
10 0.1139 0.1244 − 0.3% *
11 0.1137 0.1242 − 0.2% *
12 0.1135 0.1241 − 0.02% *
13 0.1134 0.1240 − 0.1% *
14 läuft —
konvergiert aber sehr gut.. für alle die wissen wollen was es bedeutet:
Was sagt das über die Güte (Qualität) des Modells aus? Sehr positiv!
Hier eine einfache Zusammenfassung:
Für die Solar-Prognose bedeutet das:
Die Vorhersage, wie viel Strom morgen oder übermorgen aus den Solaranlagen kommt, wird immer genauer.
Weniger Fehler = weniger Über- oder Unterproduktion
Fazit in einem Satz:
Die KI ist auf einem sehr guten Weg und wird mit jeder Runde ein bisschen schlauer. Sie hat noch nicht aufgehört, sich zu verbessern – das Training läuft weiter und das Modell wird wahrscheinlich noch etwas genauer werden. Für eine lokale Solar-Prognose mit 500 Millionen Datensätzen ist das ein richtig starkes Zwischenergebnis.
Hi,
ich habe hier eine Frage zu meinem Verständnis:
Ich habe einen älteren Intel Pentium G4400T, auf dem mein HA werkelt. Dieser wird nun nicht vom Update auf 20.0.0 unterstützt (leider).
D.h. meine Reise mit SFML endet ab dieser Version hier - neue Updates sind ab Version 20.0.0 für mich tabu?
Grüße
Thomas
Nein, du siehst das falsch. SFML läuft ganz normal weiter und macht seine SFML sachen.
Du kannst lediglich das Zusatzmodul TFS nicht nutzen. Stelle es dir so vor wie STATS für ARM, geht ja auch nicht, aber SFML an sich läuft ja trotzdem.
Ich frage mich generell, wie genau aktuell die täglichen für die Prognose benötigten Wettervorhersage Daten sind, die an Dritter Stelle und hinter dem Horizont der KI, abgerufen werden? Hängt nicht auch insbesondere von diesen täglich variablen Wetterdaten die Prognosegenauigkeit einer jeden KI ab? Gerade bei nicht stabilen und wechselhaften Wetterlagen sicherlich ein Thema?
ok - danke für die Info 
dann ändert sich für mich erst mal nichts.
Da bin ich beruhigt!
Grüße
Das ist genau der kritische Punkt. Hier hilft schiere Masse ( Schwarmwissen). Da ich aber bei meiner Ethik der vollen lokalen Kontrolle und niemals eine KI auf meinen HA oder in mein Netzwerk lassen werden (man hat ja die Vorfälle gerade bei Claude in den letzen Wochen gesehen) - mache ich mir die Mühe und trainiere die KI selbst. Insgesamt sind es 18 Jahre Solar, Wetter, Strahlungs, Leistungsdaten im 1 Minuten-Cluster. Hinzu trainiere ich direkt auf Nord, Ost, Süd, West und die gängisten Ausrichtungswinkel und das mit einm Netz von 500 Messpunkten über ganz Deutschland hinweg ( nur die Ostfriesieschen Inslen und östliches MeckPom sind eher dünn)
Das bedeutet im Klartext: Die KI hat jeweils 18x
09-04-2026 15:20 Uhr am Standort XY und selben Zeitunkt 18 Jahre (!!)
das wird alles in eine Beziehung gestzt und daraus eine Prognose erstelllt.. mal ganz einfach gesprochen.. und bei der schieren Masse an Daten entsteht eine hohe Wahrscheinlichkeit, die dann auch noch Mathematisch verfeiernt wird.
Somit fällt es nicht so sehr ins Gewicht da die aktuelle Wetterprognose nur 1/18 ausmacht. → sehr sehr stark vereinfacht!
Die HA TFS wird nach dem Training bei ca. 25Millionen trainierten Paramatern für max 4 Gruppern also 100 Millionen theoretischen Möglichkeiten für die Gesamtprognose zu einem bestimmten Zeitpunkt X liegen… auch wieder sehr sehr stark vereinfacht gesprochen.
Auch arbeitet TFS mit Quadrillen und bildet so einen Median .. das sieht man auch gut in der Developer-Test Ansicht.. die NICHT teil der HA TSF ist, sondern nur für mich zur Kontrolle.. hier siest du sie.. die schraffierten Felder und den Median (die Linie)
Der Median selbst (P50) wird dabei direkt von der Wetterprognose mit beeinflusst.. so ist er nicht einfach ein Mittelwert.. sondern eine Wahrscheinlickeit zu einem spezifischen Zeitpunkt.. abhängig von Wetter, Anlage, Erfahrung.
Um das Lernen zu ermöglichen ohne das Ha mehrere Tage / Wochen neu trainiert, habe ich mir einen Kniff einfllallen lassen, der das Lernen auf 10 -20 Min in bestimmten Intervallen möglich macht. Das ist aber Betriebsgeheimins. → Hier liegt auch der große Unterschied zu anderen LLM wie zum Beispiel DeepSeek, Qween, phi4, Gemma,.. die sind Dumm und lernen nicht dazu.
Wichtiges Update zum TFS HA-Version
Das Preetraining ist erfolgreich durchgelaufen und das Modul wurde so eben zum erstem Mal in HA unter realen Bedingungen geladen und das Fine-Tuning mit den vorhandenen Daten aus SFML wurde automatisch gestartet und läuft wie geplant sehr resourchenschonend durch.
Hier ein paar Eckdaten zum Modell und der Effekt vom Fine-Tuning Script (sofern SAUBERE SFML Daten vorhanden sind)
Model:
Pre-Trained → Finde-Tunend
| Run | Baseline | Best | Improvement | Modell |
|---|---|---|---|---|
| g1 (broken train_zara) | 0.135 | 0.066 | −51% | from-scratch, nicht pretrained |
| g1 (korrekter _run_finetune) | 0.153 | 0.082 | −46% | echtes Transfer Learning |
| g4 (jetzt) | 0.112 | 0.022 | −80% | g4 Transfer Learning + group_mask |
−80% Verbesserung gegenüber der Pre-Training-Baseline! Das ist ein sehr großer Erfolg.
LAST auf dem HA Host während Fine-Tuning:
Lets get ready to rumble.. nun beginnt das echte Testen…
HA APP Protokoll:
HA IDLE und tatsächliche RAM-Nutzung auf dem HOST
Erster Forecat (heute) OHNE die Feinabstimmung sondern out of the box.. ERSTAUNLICH!!!
| g1 (03:09 Nacht) | g4 (20:18 Abend) | IST | |
|---|---|---|---|
| Total p50 | 15.94 kWh | 11.70 kWh | 11.02 kWh |
| Fehler | +4.92 (+44.6%) | +0.68 (+6.2%) | — |
| Per-group | keine | ✓ Gruppe 1 + 2 | — |
| Validation | 0.0 (broken) | 0.82 | — |
Versioinierung
G1 = Erste Version (BETA 1)
G2 = Broken (abgestürzt)
G3 = Broken (abgestürzt)
G4 = läuft! mit +6,2% aus dem Stand!
Es bleibt spannend.. morgen z.B. ist schweres Wetter (Wechslhaft mit Sonne und Regen)
Update zum Stand (TFS HA)
Der Forcast ist nun korrekt in das SFML Ökosystem eingebunden..
Besondere Herausforderung(en) waren u.A. die sehr komplexen Logiken in SFML ( Mppt Throtteling, Wetter-Ereigisse, Anlagen-Defekte, Frost, Schnee,..) so einzubauen das sie nicht zerstört werden.
Eine ganz besondere Thematik war den Output von TFS für SFML lesbar zu machen, da TFS in P10, P50, P90 (Quadrillen) eine völlig andere Sprache Spricht die für HA so nicht einfach umzusetzen ist.
Nächster Schritt:
Die Trainierten Wetterdaten für den Weather-Blend nutzen und aktivieren. Dazu läuft gerade das Traning und die Feature-Erweiterung. Das geht aber recht schnell wird ca. 28 Std in anspruch nehmen..
Prinzip:
Aktuelles Wetter holen + KI erstellt zusätzliche Wetter Prognose bestehend aus 18x vorhandene historische Wetterdaten + Tendenz (18Jahre +/- 3 Tage um das aktuelle Datum herum) → Blend und Einschätzung als Single Source of Truth für den eigentlichen Forecast.
So ähnlich macht es SFML auch bereits..
Erwünschtes Ergebniss:
Prognose SFML gegen Prognose TFS (beide erstellen eine unabhängige Prognose) und SFML lernt wer bessere ist.. Das Ego-Problem.. SFML hat einen starken Charakter und ist etwas Nazistisch und will immer Recht haben.. das muss ich ihr noch abgewöhnen (dynamich)
Los geht´s.. es bleibt spannend!
| # | System | Prognose | IST | Fehler absolut | Fehler % |
|---|---|---|---|---|---|
| 1 | TFS HA (g5 + Wetter KI) | 3.84 kWh | 4.44 kWh | −0.60 kWh | −14% |
| 2 | Trixi Container (g1) | 5.80 kWh | 4.44 kWh | +1.36 kWh | +31% |
| 3 | Meteo Forecast | 2.84 kWh | 4.44 kWh | −1.60 kWh | −36% |
| 4 | SFML | 6.78 kWh | 4.44 kWh | +2.34 kWh | +53% |
| 5 | Eigene Schätzung | ~7.00 kWh | 4.44 kWh | +2.56 kWh | +58% |
| 6 | Solar Forecast | 7.84 kWh | 4.44 kWh | +3.40 kWh | +77% |
| 7 | TFS HA (g4 ohne Wetter) | 8.17 kWh | 4.44 kWh | +3.73 kWh | +84% |
Es bestättigt sich das die SFML mit diesen Wetterbedingen immer wieder Probleme hat. TFS HA g5 kann hier wirklich der Game-Changer sein.
Mein NAS hat die 8GB nVidia vorhin eingebaut bekommen 
Bin schon ein wenig neidisch! CUDA, ROCm sind im Container eingebaut.. wird die Grafikarte also problemlos erkennen und das Training dahin auslagern.. sollte dann bei Dir in unter 5 Minuten erledigt sein Bei mit mit einem i7 rein CPU dauert es ca. 15 Min.. da es aber nur nach Bedarf und in den Nachtstunden getriggert wird, ist das kein Problem.. TFS ist das zurückhaltend und stellt sich hinten an
Ist auch mein alter Ryzen 7 1700x reingekommen. 20W mehr Verbrauch, solange die GPU idlet.
Bin gespannt
Frage von einem User:
Kann man nicht die Historischen Daten in SFML direkt einbauen, dass würde das Lernen doch deutlich verkürzen.
Erste Tests haben gezeigt, dass sich mittels TFS KI auch die Cloud-Buckets smart befüllen lassen → D.h in einer Zukünftigen Version wäre prinzipiell möglich SFML mit Pre-Fill Wetter-KI auszustatten, was die Lernzeit deutlich verkürzen würde. → es wäre nur noch eine Korrektur und kein “neues Lernen”
ABER:
Das würde lokales Pre-Training auf die örtlichen Gegebenheiten erfordern. Auf performanen Systemen ca.2 Std (um die Daten für dein eigenen Standort zu extrahieren / lernen für alle Jahrezeiten und Monate am eigenen Standort.
Aus zwei Gründen ist das nicht praktikabel:
Daher:
Ja würde gehen.. sinnvoll → NEIN
Warum machst du die Grenze der CPU bei 2016?
Hat das nur einen leistungstechnischen Hintergrund, oder hat es auch etwas mit der Funktionalität zu tun?
Hallo @Flori
Hardware-Anforderungen (Fine-Tuning ähnlich wie der EOD unter SFML)
Das Fine-Tuning läuft ausschließlich auf der CPU und ist auf max. 30 Epochs begrenzt — das Plateau wurde bei allen Testsystemen reproduzierbar bei Epoch 18 erreicht. Als Mindestanforderung gilt Intel i5 der 6. Generation (Skylake).
Warum Skylake als Grenze?
Home Assistant führt den Event-Loop single-threaded aus und unterstützt kein natives Multi-Core. Skylake war der erste Sprung mit deutlich höherem Single-Thread-Takt gegenüber Broadwell — schnellere Vorgänger-CPUs würden nur mit allen Cores theoretisch mehr Leistung bringen, was HA nicht erlaubt.
Die Docker/Linux-Standalone-Variante kennt diese Einschränkung nicht und nutzt alles was vorhanden ist. CUDA und ROCm sind intergriert und ein komplett anderer Prognose-Zyklus. Quasi - Vollgas (wer später bremst kommt eher an)
Gemessene Fine-Tuning-Zeiten auf verschiedenen Systemen uneingeschräkte Docker Stand Alone varriante:
| Hardware | Zeit |
|---|---|
| AMD Ryzen AI 7 450G | < 1 Min |
| AMD Ryzen 7 5800X3D | 2 Min |
| AMD Ryzen 5 5600 | 4 Min |
| Intel i7 12. Gen | 8 Min |
| Intel i5 10. Gen | 10 Min |
| Intel i5 6. Gen (Minimum) | 16 Min |
Pre-Training (das müsst ihr nich machen, das habe ich bereits erledigt)
| Phase | Dauer |
|---|---|
| KI Solar (18 Jahre) | 6 Tage 14 Std |
| KI Wetter (18 Jahre) | 3 Tage 2 Std |
| Feature Engineering | ~6 Std |
Hardware dafür: AMD Ryzen 7 5800X3D + 2× RX 6600 8GB VRAM.
Modellgröße g5
| Variante | Parameter |
|---|---|
| TFS g5 (Full) | 500 Millionen |
| TFS g5 HA (Add-on) | 40 Millionen |
Die HA-Variante ist auf die Hardware-Realität von Home Assistant-Systemen zugeschnitten → 500M Parameter auf einem HA wären nicht praxistauglich.
Aber beide Modelle haben die gleichen Features: Max 4 Gruppen,… Unterschied ist, dass die HA Version in das Öko-System von SFML integriert ist und SFML einen Teil der Arbeit übernimmt.
Der Blend / die Zusammenarbeit von SFML und TFS funktioinert und zeigt Effekt:
2026-04-11 01:24:38.166 INFO (MainThread) [custom_components.solar_forecast_ml.coordinator] Solar Forecast Coordinator fully initialized (AI-Ready, 2.29 kWp)
2026-04-11 01:24:38.805 INFO (MainThread) [custom_components.solar_forecast_ml.forecast.forecast_orchestrator] TFS forecast: 20.81 kWh (score 0.88)
2026-04-11 01:24:38.805 DEBUG (MainThread) [custom_components.solar_forecast_ml.forecast.forecast_rule_based_strategy] Physics+LSTM blend active
2026-04-11 01:24:38.805 DEBUG (MainThread) [custom_components.solar_forecast_ml.forecast.forecast_rule_based_strategy] Physics engine initialized
HINWEIS:
TFS überigbt an SFML die Gesamtsumme der einzelnen Stunden für 72 Std und SFML verteilt die Stunden und wendet die umfangreichen Logiken (Schatten, Mppt-Throttelling, .. ) an.
SFML: 10,2
TFS HA: 8,79 (RAW ohne Wetter)
Finaler Forecast : 9,51
Heute Abend werden wir wissen wie genau es ist (noch ohne Wetter-Einfluss da der Feature-Build (g5) noch nicht fertig ist