hab einmal rot und einmal schwarz neu gestartet. STRG+F5 mehrmals. Hab allerdings keinen PIN Code, falls das daran hängt.
genau so ist es, wenn der PIN fehlt. gibt es das nicht. (so wie vor dem Update)
also alle 30 Epochen durchgelassen
x64 3700U
2026-04-15T20:50:54.717665Z [info ] training_complete baseline_val_loss=0.070353 best_val_loss=0.012888 duration_s=6003 epochs=30 improvement_percent=81.68 samples_train=1540 status=complete test_loss=0.005133
2 Threads immer voll ausgelastet →ca. 30% CPU Last
Pi5 8GB RAM
hat bei epoch 26 aufgehört.
2026-04-15T20:55:12.312908Z [info ] training_complete baseline_val_loss=0.070754 best_val_loss=0.019476 duration_s=5924 epochs=21 improvement_percent=72.47 samples_train=1142 status=complete test_loss=0.012194
wieder 2 Threads → ergo ca. 50% CPU Last
[Bugfix] TFS v1.2.0 — Kritischer Azimut-Fehler: Falsche Himmelsrichtungen wurden an Open-Meteo übergeben
Was war das Problem?
Toorox ForeSight bezieht seine Wetterdaten von als Servide u.A. von Open-Meteo. Damit Open-Meteo die auf geneigten Modulen tatsächlich auftreffende Solarstrahlung korrekt berechnen kann, benötigt es zwei Angaben zur Dachfläche: Neigungswinkel und Himmelsrichtung (Azimut). Genau hier lag der Fehler — beide Systeme verwenden unterschiedliche Konventionen:
- Solar Forecast ML verwendet den klassischen Kompass: 0° = Nord, 90° = Ost, 180° = Süd, 270° = West — so wie jede Windrose, jedes GPS und jede Karte seit Jahrhunderten und / oder auch die wissenschaftichen Konventionen.
- Open-Meteo Ser verwendet eine wissenschaftliche Konvention: 0° = Süd, positive Werte gehen nach West, negative nach Ost — gültiger Bereich: −180° bis +180°.
TFS v1.2.x hat den Kompasswert unverändert an Open-Meteo übergeben. Bei Südausrichtung (180°) stimmten beide Konventionen zufällig näherungsweise überein — alles schien zu funktionieren. Bei jeder anderen Ausrichtung lehnte Open-Meteo die Anfrage mit HTTP 400 Bad Request ab, und alle drei Wettermodelle (ICON, GFS, ECMWF) lieferten keinerlei Daten zurück.
| Compass | → OM | Himmelsrichtung |
|---|---|---|
| 0 (N) | −180 | Nord ✓ |
| 90 (E) | −90 | Ost ✓ |
| 180 (S) | 0 | Süd ✓ |
| 225 (SW) | 45 | SW ✓ |
| 270 (W) | 90 | West ✓ |
| 315 (NW) | 135 | NW ✓ |
2026-04-15T19:34:03.671224Z [info ] finetune_epoch best_epoch=15 best_val=0.040837 duration_s=116 epoch=20 improved=False lr=1.00e-05 max_epochs=30 patience=5 train_loss=0.018634 val_loss=0.041032
2026-04-15T19:34:03.671341Z [info ] finetune_early_stop best_epoch=15 best_val=0.040837 epoch=20
2026-04-15T19:34:04.831077Z [info ] finetune_test_eval test_loss=0.020661
2026-04-15T19:34:04.844013Z [info ] training_complete baseline_val_loss=0.45659 best_val_loss=0.040837 duration_s=2336 epochs=15 improvement_percent=91.06 samples_train=1740 status=complete test_loss=0.020661
Wenn ich das richtig interpretiere, dann hat das Finetuning knapp 39 Minuten gedauert. Nicht erschrecken @Tom-HA , bin vom NUC (bare metal) nun auf einen Geekom A5 Pro Mini-PC mit AMD 7-5825U Ryzen-Prozessor, 16GB DDR4 (Proxmox / HA-VM) gewechselt. 
CPU-Auslastung bis 51%.
1 „Gefällt mir“
SFML Version 20.0.0 / Toorox ForeSight Version: 1.2.0
Ich habe extrem hohe Prognosewerte, die nun ca. 70% höher ausfallen, aber aufgrund der PV-Anlage nicht stimmen können.
Hallo @ottokar
Das schaut nach fehlerhaftern Daten in der DB aus → das führt zu falschem Training. Ich würde mir gern mal deine DB ansehen um zu schauen woran es liegt und sie ggf reparieren. Wenn das für Dich in Ordnung ist, dann schicke sie mir bitte per PN.. auf keinen Fall hier im Chat “anhängen” .
Nachtrag:
Ich habe gerade die Datenbank eines anderen Nutzers analysiert. Ähnliches Sympthom.
TFS erkennt alle Gruppen im System, d.H. wenn es mal Änderungen durch Sensor-Trouble, oder ändern der Panelgruppen-Konfiguration gab, werden diese mit aufgenommen. So können zum Beispiel aus 2 Gruppen 4 werden.
Das ist supoptimal, auch wenn SFML es rausrechnet, erzeugt es trotzdem Rauschen und ggf. unsinnige Prognosen.
Der Fix ist einfach, ich baue schnell eine Datum-Prüfung ein, so wie SFML es auch hat. So wird automatisch nur die letzen bekannte Konfiguration genommen. Das ist auch sinnvoll, sollte ein Nutzer mal ein Pannel dazustellen oder eines wegnehmen. Sorry das ich nicht daran gedacht habe, es von SFML zu übernehmen.
Wichtig nach dem Fix (V1.2.2) wird das TFS sich selbst überprüfen und ggf neu Trainieren..
Fix ist raus:
Who is affected:
Every user who has ever changed their panel configuration in SFML — e.g. corrected a tilt or azimuth value, renamed a group, or experienced temporary sensor trouble during SFML’s astronomy caching.
What was wrong
TFS automatically discovers your panel groups from SFML. SFML stores one entry per group per day and keeps historical configuration instead of overwriting it.
If your setup ever changed — say you had two groups at one azimuth for a few days, then corrected them — SFML’s history contains both versions side by side.
TFS v1.2.1 and earlier treated every unique tilt/azimuth combination as a separate group. The result: two real groups could turn into four (or more) ghost groups in TFS’s internal model.
Impact on the Transformer
This was more than cosmetic. The consequences were:
Model architecture was built with the inflated group count — for example, four output heads instead of two
Training was noisy: duplicate groups shared the same name but had different orientations; the model received the same actual yields for both, learning an inconsistent mapping
Weather data was fetched using only the first group’s orientation — whichever version happened to be enumerated first
Forecast responses to SFML contained duplicate group names; SFML’s blend logic kept only one of each by name, effectively discarding half of TFS’s per-group predictions
SFML’s ensemble blend masked the problem well enough that it wasn’t immediately visible — but forecast quality was quietly degraded, and anyone who had ever reconfigured their panels was running a model that didn’t match their actual setup.
What v1.2.3 does
The group discovery now reads only the most recent snapshot of each panel group. Historical rows from past configurations are ignored.
Result:
two physical groups produce exactly two TFS groups, with the current orientation and capacity — no matter how many times the configuration has changed.
Important: First-Start Fine-Tune After Update
Because the Transformer’s architecture depends on the group count, installations that were running with inflated groups need to re-initialize the model once after updating. TFS handles this automatically:
Update via the HA Add-on Store (v1.2.1 → v1.2.3)
Restart the add-on
TFS detects the changed group count and triggers a new fine-tuning run
First-run fine-tune duration: 10–45 minutes depending on CPU
Do not interrupt the fine-tune — aborting corrupts the checkpoint
After fine-tuning completes, SFML automatically picks up the improved per-group predictions on the next forecast cycle. No manual action required.
Thanks
Big thanks to the customer who flagged the duplicate-group issue in the forum (simon42) and provided a database dump for diagnosis. This fix would have taken much longer to find without that concrete evidence.
BiG Thx to:
- Kaysen889
- Ottokar
- Joachim
es gab keinen neuen fine tune! und es werden weiter 4 Gruppen erkannt.
2026-04-16T03:28:50.831806Z [info ] server_starting host=0.0.0.0 port=8780
INFO: Started server process [80]
INFO: Waiting for application startup.
2026-04-16T03:28:50.917071Z [info ] config_loading path=/data/config.yaml
2026-04-16T03:28:51.019982Z [info ] sfml_auto_import_startup
<frozen serve_forecast>:1040: DeprecationWarning: 'asyncio.iscoroutinefunction' is deprecated and slated for removal in Python 3.16; use inspect.iscoroutinefunction() instead
2026-04-16T03:28:52.633224Z [info ] sfml_auto_import_startup_complete imported=0 skipped=2218 total=2208
2026-04-16T03:28:52.636966Z [info ] enrichment_gate missing_daytime_rows=1019
2026-04-16T03:28:52.637835Z [info ] enrichment_start total_records=2208
2026-04-16T03:28:52.640446Z [info ] enrichment_step1_sensors updated=0
2026-04-16T03:28:54.690695Z [info ] archive_fetched end=2026-03-08 hours=720 start=2026-02-07
2026-04-16T03:28:56.849397Z [info ] archive_fetched end=2026-04-07 hours=720 start=2026-03-09
2026-04-16T03:28:57.736870Z [info ] archive_fetched end=2026-04-11 hours=96 start=2026-04-08
2026-04-16T03:28:57.803136Z [info ] enrichment_step2_open_meteo updated=1536
2026-04-16T03:28:57.803606Z [info ] physics_init capacity_kwp=1.76 groups=4 lat=x lon=x
2026-04-16T03:28:57.804571Z [info ] enrichment_step3_pvlib updated=0
2026-04-16T03:28:57.805676Z [info ] enrichment_complete astronomy_computed=0 missing_daytime_after=1380 open_meteo_filled=1536 sensor_mapped=0 status=complete total_records=2208
2026-04-16T03:28:57.805826Z [info ] enrichment_done astronomy_computed=0 missing_daytime_after=1380 open_meteo_filled=1536 sensor_mapped=0 status=complete total_records=2208
2026-04-16T03:28:57.805889Z [info ] engine_init
2026-04-16T03:28:57.807715Z [info ] physics_init capacity_kwp=1.76 groups=4 lat=x lon=x
2026-04-16T03:28:57.931718Z [info ] era5_climatology_loaded slots=8784
2026-04-16T03:28:58.336835Z [info ] model_loaded g5=True n_temporal=47 params=20481387
2026-04-16T03:28:58.342847Z [info ] last_forecast_restored at=2026-04-16T05:16:21.649133
2026-04-16T03:28:58.346036Z [info ] performance_ratio_updated confidence=1.00 mean=0.773 median=0.845 pr=0.845 samples=310
2026-04-16T03:28:58.346231Z [info ] performance_ratio_init confidence=1.0 mean=0.7731206240695428 median=0.844642107896449 performance_ratio=0.844642107896449 samples=310
2026-04-16T03:28:58.358758Z [info ] forecast_accuracy_computed bias_kwh=0.4685 coverage_p10_p90=0.75 mae_kwh=0.4743 rmse_kwh=0.5653 samples=156
2026-04-16T03:28:58.359778Z [info ] engine_accuracy_updated bias=0.4685 mae=0.4743 model_age_days=60
2026-04-16T03:28:58.360061Z [info ] scheduler_started jobs=3
2026-04-16T03:28:58.360158Z [info ] sfml_periodic_sync_started interval_seconds=3600
2026-04-16T03:28:58.360251Z [info ] feedback_task_started interval_seconds=21600
2026-04-16T03:28:58.361709Z [info ] fallback_forecast_scheduled at=2026-04-17T00:30:00+02:00
2026-04-16T03:28:58.388072Z [info ] primary_forecast_scheduled at=2026-04-16T05:50:16+02:00
2026-04-16T03:28:58.388295Z [info ] nightly_training_scheduled at=2026-04-17T02:00:00+02:00
2026-04-16T03:28:58.390312Z [info ] weather_pipeline_scheduled refresh_hours=[6, 12, 18] startup_delay_s=60
2026-04-16T03:28:58.390533Z [info ] weather_pipeline_started refresh_hours=[6, 12, 18]
2026-04-16T03:28:58.390902Z [debug ] weather_pipeline_next_refresh hour=6 wait_s=2161
2026-04-16T03:28:58.391125Z [debug ] weather_pipeline_next_refresh hour=12 wait_s=23761
2026-04-16T03:28:58.391329Z [debug ] weather_pipeline_next_refresh hour=18 wait_s=45361
Dann muss ich noch einen GiGo Check einbauen… Gefunden.. . es gibt noch eine zweite Stelle vor die Panelgruppen “Altlasten” liegen.. im Astro-Cache also muss ich den auch noch mit bereinigen..
FIx ist raus.. sollte das Problem von Test-Resten, Fehlkonfigurationen lösen Ich muss es aber ncoh erst testen!
kannst Du bitte mal fix testen bitte
wenn mit GIT das Update ausrollt und mein HA merkt, das eins da ist, dann ja.
1 „Gefällt mir“
ja blind am morgen…. 
Es passiert was. Im Sinne dieses Memes! 
config_sfml_mismatch_reseeded cached_groups=4 cached_hash=e1b2bf972089 fresh_groups=2 fresh_hash=2e74fdfd4e37
finetune läuft
Edit: auf dem Pi aber auch, obwohl dort nix neu sein sollte.
Edit2: pro Epoch werden jetzt auch nur noch 120s gebraucht und nicht 200s. mann merkt den unterschied an Gruppen. x64
Ahh ich sehr er hat es korrigert von 4 auf 2 und trainiert neu.. Gott sei es Gedankt…
Nebeneffekt er kickt nun auch falsche Sensor-Werte raus…
Dann kann ich ja nun ins Büro fahren 
Danke @Kaysen899 und @ottokar .. nach dem retrain sollte alles passen..
HINWEIS:
Das Update kontrolliert nicht nur die Gruppen, sondern auch GiGo (Fehlerhafte Sensorwerte) es kann also durchaus passieren das nach dem Update bei dem eine oder anderen ein retraing stattfindet.. auch wenn die Panelgruppen korrekt sind..
1 „Gefällt mir“
Wir müssen halt heute mit der “Falschen” Prognose leben und morgen gehts wieder den gewohnten Gang.
Edit :Ich glaube ich habe noch vom forecast, vor dem Sonnenaufgang, profitiert.
Er hat runter korrigiert.
Entweder das Training hat schon etwas gebracht oder das Wetter wird doch schlechter als gestern Abend gedacht.
1 „Gefällt mir“
Na siehst du… alles wird gut
und sorry das ich nicht daran gedacht habe einen Filter direkt von Anfang an einzubauen..
1 „Gefällt mir“
Guten Morgen,
hier hat auch alles geklappt auf Bare Metal Core i7 2,8GHz, 16GB, NVME-SSD, erster Addon-Lauf 30 min.
training_complete baseline_val_loss=1.097697 best_val_loss=0.224976 duration_s=1815 epochs=21 improvement_percent=79.5 samples_train=1174 status=complete test_loss=0.217813
CPU-Auslastung lag so bei 25%, RAM 6,2 %
Das ist ein ordentlicher Wert!!! 79,5% Verbesserung gegenüber dem vortrainierten Modell … guter Wert und 30Min für rund 1200 Samples inklusive Normalisierung ist auch sehr gut! - Viel Spaß!
(Bitte daran denken, auch er muss sich erst einschwingen bis er die volle Leistung erreicht, aber bei rund 80% sollte das schnell gehen)
Hört sich doch gut an.
By the way: Könnte ich eine Developer-PIN kommen? Die Kurven fehlen mir doch ein wenig…
Beste Grüße
Paul