Schlechterer Solar-Forecast nach Update & Zeitumstellung – DB bereinigen oder neu trainieren?

Solar Forecast ML
1

Nach einem SFML-Update vor etwa einem Monat (bei dem der Forecast ungefähr um die Hälfte unterschätzt wurde) und gleichzeitig der Umstellung auf die Sommerzeit ist die Vorhersagegenauigkeit deutlich gesunken. Zuvor lag sie bei etwa 85 % (30 Tage), inzwischen hat sie sich – nach fast einem Monat – auf etwa 70 % stabilisiert, also ungefähr auf dem Niveau von vor über zwei Monaten.

Es sieht so aus, als müsste ich die Datenbank anpassen, da ich aktuell einen sehr merkwürdigen Forecast beobachte. Während der gestrige Forecast noch sinnvoll war und recht nah an der Realität lag, habe ich heute erneut folgende Auffälligkeiten:

  • Der Forecast überschreitet die physikalisch mögliche Energiemenge meiner Anlage (>50 kWh), obwohl bei 6 kWp selbst unter optimalen Bedingungen maximal etwa 40+ kWh möglich sind.

  • Zwischen 13:00 und 16:00 wird eine konstante Leistung von 6 kW prognostiziert.

  • Um 20:00 steigt die Produktion wieder an und liegt über dem Wert von 19:00 – vermutlich ein Artefakt der Zeitumstellung.

Gibt es ein Tutorial oder eine Anleitung, wie ich die Datenbank bearbeiten kann? Es handelt sich um die Datei solar_forecast.db, die allerdings sehr viele Tabellen enthält.

  • Muss ich nach dem Löschen von Daten ein Retraining durchführen?

  • Ist es überhaupt möglich, gezielt bestimmte Zeiträume zu entfernen?

  • Ich erinnere mich, dass frühere Änderungen an der Datenbank zu deutlich längeren Verarbeitungszeiten geführt haben – ist das weiterhin der Fall?

BTW: Falls du TFS veröffentlichst und SFML diese fehlkalibrierten Daten verwendet – sollte ich mit einer schnellen Korrektur rechnen, oder verstärkt das nur die Abweichungen und es ist besser, zuerst SFML zu korrigieren?

After an SFML update about a month ago (where the forecast was underestimated by roughly half), combined with the switch to daylight saving time, the prediction accuracy dropped significantly. Previously, I had around 85% accuracy (30 days), but now – after almost a month – it has stabilized at around 70%, which is roughly the level from over two months ago.

It looks like I may need to modify the database, as I’m currently seeing a very strange forecast. While yesterday’s forecast was still reasonable and quite close to reality, today I again observe the following:

  • The forecast exceeds the physically possible energy production for my installation (>50 kWh), whereas with 6 kWp even under perfect conditions the maximum should be around 40+ kWh.

  • From 13:00 to 16:00, a constant power output of 6 kW is predicted.

  • At 20:00, the production increases again and is higher than at 19:00 – likely an artifact from the daylight saving time change.

Is there any tutorial or guide on how to edit the database? It’s the solar_forecast.db file, but it contains many tables.

  • Do I need to retrain after removing data?

  • Is it even possible to selectively remove specific time ranges?

  • I remember that previous database modifications resulted in significantly longer processing times – is that still the case?

BTW: If you release TFS and SFML uses this miscalibrated data, should I expect a quick correction, or will it amplify the discrepancies, meaning it’s better to fix SFML first?

image
image568×463 12.3 KB

image
image672×418 17.4 KB

1 „Gefällt mir“
INFO: Wie wird die Prognose-KI (ZARA) trainiert -> Wie funktioineren SFML und TFS
SFML: Bug? Samples erhöhen sich nicht mehr wie gewohnt
2

(Beitrag vom Verfasser gelöscht)

3

(Beitrag vom Verfasser gelöscht)

4

Was du jetzt machen kannst ist alles zu löschen inklusiver deiner Datenbank und neu anfangen.

Die ganzen Service Calls sollen nicht ausgeführt werden und sind nur für Entwickler. Mit sehr hoher wahrscheinlichkeit hast du deine ganzeb Daten geschrottet.

Das hatten wir zumindest so in der Vergangenheit.

Niemals ohne Aufforderung des Entwicklers einfach die Service Calls ausführen.

5

Das war die Geschichte mit dem Knopf - wenn er da ist, wird er auch gedrückt​:wink:

1 „Gefällt mir“
6

Noch einmal – wie ich bereits zuvor geschrieben habe – wurden solche Forecast-Werte schon vor dem Start dieser Maßnahmen geschätzt. Das gilt sowohl für die Erhöhung auf 6 kW für einen halben Tag als auch für den höheren Wert um 20 Uhr im Vergleich zu 19 Uhr.
Woher kommt also die Annahme einer „corrupted database“, außer der Tatsache, dass sie als Development beschrieben ist?

BTW: Ich habe eine Sicherung der Datenbank, also alles entspannt.

Once again – as I mentioned earlier – these forecast values had already been estimated before these actions were implemented. This applies both to the increase to 6 kW for half of the day and to the higher value at 20:00 compared to 19:00.
So where does the conclusion about a “corrupted database” come from, apart from the fact that it’s described as being for development?

BTW: I have a backup of the database, so no worries.

7

@anon90989627
sorry to say.. Du hast deine Datenbank und KI-Modell zerstört! Die Services, sind nur für Entwickler und / oder auf Anweisung das steht auch extra in der Beschreibung!!!

Es gibt KEINE Chance das nun noch irgendwie zu retten! - Du hast sowohl die KI-Lerndaten, die Wetter-Gewichte, Actuals, alte sowie neue Daten unwiederruflich, dauerhaft und nachhaltig zerstört. (nicht mal ein Backup hilft hier noch, da Teile des Codes umgeschrieben wurden und in einem MOCK-Modus versetzt sind… ) → Ausführen der Service = komplette alles Löschen und komplett von vorn beginnen. Es ist wirklich NUR für Test-Systeme und Entwickler die am Code arbeiten möchten und ihn in einen " DEV-Modus" versetzen möchten. Es werden an vielen Stellen “Schalter” gesetzt die einen “normalen” Betrieb unmöglich machen.

Du wirst komplett von vorn beginnen müssen!!!

Schritt eins: HA Stoppen und via SSH / SMB mit dem HA vebrinden
Schritt zwei: Löschen des Ordners " config/solar_forecast_ml
Schritt drei: Versteckte Ordner anzeigen lassen und in .storage die SFML Einträge löschen (hier liegen nun durch das Ausführen der Services Debug und Mock Daten)
Schritt vier: HA komplett über SSH neustarten (nicht reload)
Schritt fünf: Warten bis HA wieder da ist und SFML neu einrichten

Zu Deiner Frage " Bootstrap" der wird automatisch beim EOD ausgelöst und macht einen Backfill. Der ist nicht dazu gedacht manuell die DB zu beeinflussen

ICH WARNE NOCH EINMAL AUSDRÜCKLICH (WIE SCHON SO OFT) DIE HINWEISE BEI DEN SERVICE ABSOLUT ERNST ZU NEHMEN UND NIEMALS AUSZUFÜHREN ES SIND REINE ENTWICKLER SEREVICE DIE MIT DEM REGULÄREN BETRIEB NICHTS ZU TUN HABEN

1 „Gefällt mir“
8

(Beitrag vom Verfasser gelöscht)

9

Hey
nein, das reicht leider nicht! bei einem Neustart / Reload werden die Daten-Flags direkt wieder gesetzt.
Hintergrund: Dev´s brauchen Neustartfeste / peristente Entwicklerumgebungen, da einige Änderungen am Code / Tests erst nach dem Löschen des pycache aktiv werden.
aus diesem Grund erzeugen einige der Service im Standartverzeichnis von Home Assistant, in dem jede App / Integration ihre Konfiguration ablegt, Dateien die den Code immer wieder in den Entwicklermodus versetzen. → was logisch auch korrekt ist!

Aber es ist gut das Du eine Sicherung von der DB und Costum-Components hast. Nur ein einfaches zurückspielen reicht nicht aus! Du musst wirklich im versteckten Konfigurationsordner von HA die Konfigurationseinträge von SFML entfernen.. anders wird es nicht gehen. Der Code würde immer wieder bei einem Neustart zurückgesetzt und in einem “neutralen Dev-Modus” laufen.
Also bitte unbedingt die Einträge für SFML in .storage suchen und löschen. Alternativ ein HA Backup lokal auf dem Rechner öffnen, versteckte Dateien anzeigen lassen und den ordner .storage komplett austauschen (eine Version bevor die Services benutzt hast) → bitte vorsicht, dort liegen ALLE Konfigurationen von Home Assistant! Mach bitte auf jeden Falle eine lokale Kopie bevor du etwas änderst!

Auf jeden Fall die Datei: core.config_entries löschen!
und wenn vorhanden:

Bildschirmfoto 2026-04-26 um 15.37.30
Bildschirmfoto 2026-04-26 um 15.37.30862×440 56.5 KB

Viel Erfolg!!! und bitte niewieder irgendwo draufklicken wo eine Warnung steht oder nicht klar ist was passiert

10

Die Dateien im .storage-Verzeichnis habe ich zwar nicht gesichert, daher konnte ich sie nicht wiederherstellen, aber das war auch nicht nötig, da sie zuletzt nicht geändert wurden (seltsam?).

Alle Dateien .storage/solar_forecast_ml_json*, solar_forecast_ml_v10 und v16 sind auf den Zeitraum 31. Januar bis 10. Februar datiert – mehr sehe ich nicht.

Home Assistant in Docker, aber das sollte doch keinen Einfluss auf irgendetwas haben, oder?

11

core.config_entries ist die wichtigste.. bitte unbedingt löschen! doch HA sichert den Ordner immer mit beim Backup… Backup auf PC laden.. lokal entschlüsseln > öffnenen > versteckte Dateien anzeigen lassen > Ordner storage suchen > inhalt zurück auf den HA kopieren..

12

maybe I can switch to english.
I checked core.config_entries file and it has text entries related to all integrations (so I belive I can not remove it directly) and the only related to solar_forecast_ml is as follows

{“created_at”:“2026-01-31T10:19:08.541361+00:00”,“data”:{“inverter_max_power”:15.0,“panel_groups”:\[{“azimuth”:201.0,“energy_sensor”:“sensor.goodwe_today_s_pv_generation”,“name”:“Gruppe 1”,“power_wp”:6000.0,“tilt”:40.0}\],“power_entity”:“sensor.goodwe_pv_power”,“solar_capacity”:6.0,“solar_yield_today”:“sensor.goodwe_today_s_pv_generation”},“disabled_by”:null,“discovery_keys”:{},“domain”:“solar_forecast_ml”,“entry_id”:“\*\*\*\*\*\*\*\*\*”,“minor_version”:1,“modified_at”:“2026-04-26T06:31:39.443327+00:00”,“options”:{“adaptive_forecast_mode”:true,“diagnostic”:true,“enable_tiny_lstm”:true,“evcc_forecast”:false,“has_battery”:false,“hourly”:false,“learning_backup_protection”:true,“ml_algorithm”:“tiny_lstm”,“notify_fog”:true,“notify_forecast”:false,“notify_frost”:true,“notify_learning”:false,“notify_snow_covered_panels”:true,“notify_startup”:false,“notify_successful_learning”:true,“notify_weather_alert”:true,“pirate_weather_api_key”:“\*\*\*\*\*\*\*\*\*\*\*”,“solar_to_battery_sensor”:“sensor.goodwe_battery_power”,“update_interval”:1800,“winter_mode”:true,“zero_export_mode”:false},“pref_disable_new_entities”:false,“pref_disable_polling”:false,“source”:“user”,“subentries”:[ ],“title”:“Solar Forecast ML”,“unique_id”:“solar_forecast_ml_sensor.goodwe_pv_power”,“version”:1},

something here is damaged?

:crayon:by HarryP: Code/log lines formatted (please always enclose them in </>)
see also: (Neues Update & Features - Hier in der Community 🫶)

13

Im actually not at home… will answer you asap

14

sure, no problem.
I just checked this entry with respect to entire from backup that I made ~6 days ago and it is basically identical

15

Than pls copy it back to HA and you good to go
Afterwards restart and pls sent me via pn your SFML Log file config/solar_forecast_ml and I will investigate your problem

16

the only difference in core.config_entries is that I corrected slightly azimuth and PV angle in panel configuration but it was through GUI and I can change it back - this is very minor change I believe.
I compared both files by characters and this is the only change, checked all other files in .storage folder modified today and I also see no issue there.

Let me collect the logs

17

Hast du schon die Logs an @Tom-HA geschickt ?
Hat sich etwas in den letzten Tagen an der Genauigkeit geändert?
Wie ist denn deine Genauigkeit über die letzten Tage?

Have you sent the logs to @Tom-HA ?
Has the accuracy changed at all in the last few days?
How has the accuracy been over the last few days?

18

Hi,

Yes, Tom checked the logs with no issue.

Currently forecast accuracy is more stable. Still some overshoot is visible but it’s not that dramatic as few days back when for ~5h you could see limitation on kWp clipping

19

Ok, to summarize what we have already.

  1. Although after requesting some developer services looked beneficial to forecast accuracy it most likely destroyed database
  2. My play with developer services was restored from the backup
  3. It did not impact any files from other then two solar_forecast_ml folders
  4. In theory there is possible to remove problematic period but no manual
  5. Lack of accuracy appeared after SFML update where database recalculation was done “The first End of Day (EOD) cycle after this update will take longer than usual. The model will automatically perform a fresh training run to incorporate the new parameters and optimizations.” and forecast dropped from already achieved 85% 30days accuracy and having ~600 samples collected. Issue on GitHub was created Recent discrepancies between forecast and actual PV production · Issue #105 · Zara-Toorox/Solar-Forecast-ML · GitHub and several people experienced similar issue
  6. It was noticed that forecast was reduced by half to expected one
  7. Additional shift was noticed probably due to winter to summer time transition
  8. Next update most likely (and based on release description) corrected that issue
  9. Despite point 7, inaccuracy significantly gained and still some overshoots are noticed including unrealistic forecast for yesterday exceeding possible production by my PV system
  10. Today I see first time from the month gain for 30 days accuracy sensor
  11. Inaccuracy of the forecast during dynamically changing weather could be from destabilized model
  12. I still don’t understand how SMFL is using newest weather data while display from the morning :wink:
20

A factual response here is the following:

So the fair conclusion is:

  • yes, running destructive developer services can damage or destabilize the database/model state
  • yes, that alone is already a technically plausible explanation for at least part of the later instability
  • yes, a temporary drop after recalculation or retraining is also technically plausible
  • yes, timing shifts around seasonal transitions are plausible
  • yes, remaining forecast-quality concerns may still be valid
  • but no, the currently presented screenshots are not sufficient proof
  • proper assessment requires original SFML Stats data, not custom-built cards

If there is a real forecast-quality problem, it should be demonstrated with the original Stats views so that clipping, throttling, technical limits and system-side anomalies can be evaluated correctly. Without that, there is simply not enough reliable evidence to judge the claim with confidence.