Installation von Toorox ForeSight HA als Docker-Container für Home Assistant in der Docker Version

Solar Forecast ML
,
21

Ja genau. Der Unterschied Solarwetter und “sichtbares” Wetter ist mir klar, das habe ich hier im Forum schon deine Erklärung in diesem und jenem Thread gelesen :slight_smile: .

Worauf ich hinaus wollte ist der Widerspruch zwischem dem “Solarwetter”, dass meine PV-Anlage bis gerade gesehen hat (völlig ungetrübter, gleichmäßiger Verlauf der Leistung, siehe zweite Grafik vom Sunny Portal von heute Vormittag), und das was SFML gesehen haben will (48% Wolken). SFML meinte also heute früh, dass die Strahlung tatsächlich deutlich eingetrübt wurde, aber das war ja nicht so. Wie kann das sein? Von meiner Wetterstation kann sie das nicht abgeleitet haben. Da sieht der Strahlungsverlauf bisher so aus (passend zu PV-Leistung):

grafik
grafik899×183 8.52 KB

Da ist keine Senke bis 48% Wolken zu erkennen. Und das sind die Daten von in SFML eingetragenen Sensor. Wie könnte SFML dann auf die Idee mit den Wolken gekommen sein?

22

Bei den “Wolken” ist nur Himmelstrübung gemeint.

Wolken, Pollen, Staub, Sand, usw.

Man kann manchmal nicht erkennen zwischen 0% und 50%.

23

@Kaysen899 hat Recht, es kommt aber noch etwas anders hinzu.

Aktuell sind die europäischen, kanadischen und amerikanischen Wettermodelle für viele Region sehr unterschiedlicher Ansicht. Selbst das klassische und das “neue” KI-Wettermodell in Europa weichen dramatisch voneinander ab. → damit ist für SFML die Situation nicht eindeutig und es nutzt das gelernte Wissen und versucht zu treffen.

Das Europäische geht von einer Hitzewelle aus, die noch einige Tage anhält, das amerikanische von einem Kälteeinbruch ab mitte nächster Woche. Das hängt auch mit den Bodenstationen zusammen.
Es gab in Deutschland über 13000 Messtationen, die wurden eingekürzt und befinden sich zumeist in Metropolregionen - die bauartbedingt deutlich über den Temperaturen, Luftklarheit ect. liegen, als eine Ländliche- oder Bergstation.
So verschieben sich die Prognosen erheblich und gerade in DE sind die Temperaturen dadurch “angestiegen” obwohl sie im Mittel (aktuell) im Jahresmittel zu kalt und nass sind. - Ein Urteil hierüber oder eine ggf. Motivation steht mir nicht zu.

Um dem zu begegnen, nutzt SFML verschiedene Wetterdaten / Wettermodell (Rohdaten!!!) und erlent die Gewichtung welche lokal am besten zutrifft. Damit das funktioniert, sind externe Sensoren Pflicht. Das verkürzt die Lernzeit drastisch, da belastbare Werte vorliegen.
Sind keine externen Sensoren vorhanden (der wichitigste ist W/m) versucht SFML den Wert an der Produktion abzuleiten. Daher war es auch notwendig, dass ich das Mppt-Throtteling erkennen kann.

Kurzum es ist schon massiv und komplex wie SFML mit seinem AI-Stack versucht das Optimum zu erreichen. Daher sind Aussagewerte aus Wetter-Apps oder Sensoren nicht wirklich heranzuziehen, es ist viel komplexer und ein Lernen. → nicht umsonst ist der “Wetter-Code” mit über 60.000 Zeilen einer der komplexesten Teile der AI - wenn überhaupt dann muss man eine Mittelwert von 60 Tagen ziehen, da der AI-Stack so Jahreszeiten erkennt und immer wieder anderes an die Berechnungen herangeht.

@thomasz beantwortet das Deine Frage?

1 „Gefällt mir“
24

@Kaysen899 Da hätte ich mich wohl anders ausdrücken sollen. Ich habe des Wort “Wolken” nur verwendet, weil es auch im GUI (s. snapshot) verwendet wird und so von Lesern, die gerade erst beginnen, sich in SFML einzuarbeiten, besser zugeordnet werden kann, IMO. Die Begriffe Strahlungsdämpfung oder Strahlungsminderung wären vielleicht passender.

@Tom-HA Danke für Deine Erläuterungen. Das Prinzip ist mir schon klar, aber sie haben mich dazu gebracht, noch einmal meinen Gripskasten etwas genauer und ausfühlicher zu bemühen :slight_smile:.

Dabei ist mir klar geworden, dass ich nur auf “meinen” Sensor geschaut habe und automatisch angenommen hatte, dass die obere Reihe in der Darstellung mit den Sonnen immer “ungedämpfte” Einstrahlung meint, was natürlich quatsch ist. Die Sonne repräsentiert halt irgendetwas von 0-X% Dämpfung. Wird die Dämpfung > X%, kommt das nächst ungünstigere Symbol dran …

Aber so ganz passt das für trotzdem noch nicht so ganz zusammen. Wenn ich auf die 14. Stunde schaue, sehe ich das hier:

grafik
grafik494×143 8.32 KB

Nach meinem Verständnis bedeuten die Zahlen, dass die 798 W/m² 86 % der rechnerisch maximalen Einstrahlungsleistung bei völlig sauberer Atmosphäre bedeutet, und dass das verwendete Wettermodell eben die 14 % Dämpfung aus den Wettervorhersagen errechnet hat.

Für meinen Sensor wird nun für diese 14. Stunde folgendes berichtet:

grafik
grafik494×143 8.37 KB

Rechnerisch müsste die maximale mögliche Strahlung in dieser Stunde (798 / 0.86) = 928 W/m² betragen (ich nehme mal an, dass mit Mittelwerten OSLT gerechnet wird). Mein Sensor meldet nun 731 W/m², das wäre nur 79 % der maximalen Strahlung, also 21 % Dämpfung (731 / 928). Ich lese da aber 4 %.

4 % von was? Gibt es “im Hintergrund” einen “erlernten” Kalibrierfaktor” oder gar eine Kalibrierfunktion, mit dem/der die von meinem Sensor gelieferten Werte umgerechnet werden? Schließlich ist der ja nicht wirklich ab Werk kalibriert :). Bei 0 % Dämpfung würde mein Sensor dann zu den Einstrahlungsbedingungen in der 14 Stunde 761 W/m² melden, und der interne Korrekturfaktor zu der Zeit wäre k = 761 / 928 = 0.28.

Falls dem so ist, verstehe ich das und meine Frage ist beantwortet. Falls nein - bliebe die Frage “4 % Dämpfung von was?”.

25

Hallo @thomasz

Zunächst einmal vorne Weg: Ich finde es super, wenn sich jemand die Mühe macht und sich mit dem was ich hier gebaut habe so im Detail auseinandersetzt und logisch, strukturiert und klar analysiert. Gleichwohl muss ich einen kleinen Dämpfer einschieben, dass ich hier nicht öffentlich den AI-Stack und wie er im Detail funktioinert offenlege → man weiß nie wer mitliest :slight_smile: und es gab schon üble Kopierversuche.

Trotzdem will ich Rede und Antwort stehen und Dir deine Frage beantworten.. werde es aber allgemein halten - Dafür bitte ich um Verständnis.

Also:
Das was Du als “Dämpfung” erkannt hast / es so nennst, ist keine klassicher Dämpfung sondern eine durch Blending und Wissen ausgeführte "Wahrheitskorrektur. Du bist nicht falsch und Du hast es im Kern auch 100% korrekt erfasst! - sehr cool!

Stell es Dir bildlich so vor:

Jeden Tag 45Min vor Sonnenaufgang treffen sich der Leiter der Physik-Abteilung, der Leiter vom vergangenen EOD, der Leiter der Wetter-AI, der Datenbank-Beauftragte, der Solarpeezialist, der Leiter des Archives, der Leiter “Mptt” und Anlagenalterung, der Local Guide, der Creative und der Außenminister für Wetterrohdatenabruf zum Meeting
Sie haben das gemeinsame Ziel den bestmöglichen Treffer der Prognose ohne zu rollieren zu finden.
Also Therorie, Praxis, Anlagenwissen und Kreativirät müssen einfach gesagt in Einklang gebracht werden.
Hubbel hört sich alles an und trifft dann eine Entscheidung und übergibt seine Entscheidung an Marketing (Stats) und Stats publiziert es dann basierend of SOT mit den Hinweis aus Backbone (Korrektur) .
Parallel dazu betrachtet Hubble aber auch noch die Quantillen und bildet einen P10 Wert und blendet den mit seinen eigenen Aufzeichnungen.

Am Ende des Tages treffen sich dann alle wieder (EOD) und derjenige der am schlechtesten lag wird bestraft und sein Stimmrecht am folgenden morgen wird nicht eingeschränkt aber gemerkt. bei mehreren Fehlern - darf er nicht mehr mitreden.

So funktioinert es im “Groben”, so kommt es zu der von Dir “Dämpfung” genannten 4%.

1 „Gefällt mir“
26

:joy: Sehr schöne Beschreibung! Ähnelt sehr dem Vorgehen der Management-Ebenen meiner letzten Arbeitsstätte (war wirklich die Letzte …). Nur dass die Meetings dort oft nicht mit Messwerten, sondern mit Wunschdenken befasst waren (leichte Ketzerei …).

Aber jetzt habe ich ein Gefühl, auf welche Grundgesamtheit sich die 4 % beziehen. Vielen Dank!

Zur Erläuterung meines Ansatzes - ich schreibe hier nur, wenn mein Verständnis von dem, was ich sehe, irgendwie aus meiner Sicht zu Widersprüchen führt. Das könnte ja tatsächlich statt auf mangelnden Verständnises :slight_smile: auf einen Fehler hindeuten. Ich will keinesfalls dein private properties einem “reverse engineering” unterziehen. Versprochen!

2 „Gefällt mir“
27

Moin Ihr Beiden und erst mal vielen Dank für die geniale Software, ich habe TFS erst kurz im Einsatz aber es ist schon jetzt extrem genau. Auch würde ich gerne ForeSight nutzen, habe HA aber auf einem RasPi 4 laufen, entsprechend wäre eine Auslagerung auf meinen Docker-Host ideal, das final release lässt aber scheinbar leider noch auf sich warten und die Beta scheint nicht öffentlich zu sein (oder ich habe es einfach nicht finden können bisher), die Integration hier scheint ja ausschließlich darauf abzuzielen, dass ich das HA ebenfalls auf dem gleichen Docker laufen lasse? Jetzt könnte ich zwar das Verzeichnis auf diverse Arten auf dem Docker mounten, aber ich sehe das irgendwie kritisch auf diese Weise in HA einzugreifen?!

Das letzte Update für die Beta war eine kurze Notiz, dass die Veröffentlichung Mitte Juni hätte passieren können, scheinbar hat sich das verzögert?! Oder ist mir die Nachricht entgangen, dass das Thema eingestampft wurde ggf. Zugunsten dieser Lösung hier? Oder sollte ich das eher in dem Beta-Thread fragen?

Und generell mal die Frage: Bringt es Vorteile für den Docker Container (egal ob diese Version oder die Beta), wenn man eine Nvidia-Grafikkarte verbaut hat, wenn es um die Berechnung geht? Frage für einen Freund :wink:

Danke für eure großartige Arbeit!

28

Der Container läuft bei mir, wenn ich docker exec -it toorox-foresight date eingebe, wird jedoch die falsche Uhrzeit ausgegeben. Ist das problematisch bzw. kann das korrigiert werden?

So sieht die compose.yml aus:

  toorox-foresight:
    image: toorox_foresight_ha:latest
    container_name: toorox-foresight
    restart: unless-stopped
    ports:
      - "8780:8780"
    volumes:
      - /storage/.kodi/userdata/homeassistant:/config
    environment:
      - TFS_TIMEZONE_STR=Europe/Vienna
      - TFS_LATITUDE=xx
      - TFS_LONGITUDE=xx
      - TFS_STATE_DIR=/config/toorox_foresight_ha

Im Journal steht:

Aug 20 17:26:02 LibreELEC 78b980aa567f[755]: INFO:     Started server process [7]
Aug 20 17:26:02 LibreELEC 78b980aa567f[755]: INFO:     Waiting for application startup.
Aug 20 17:26:02 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:02.237748Z [info     ] tfs_bootstrap                  codename=Phoenix state_dir=/config/toorox_foresight_ha version=28.0.0
Aug 20 17:26:02 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:02.239523Z [info     ] state_db_schema_ready          version=1
Aug 20 17:26:02 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:02.239836Z [info     ] state_db_connected             path=/config/toorox_foresight_ha/tfs.db
Aug 20 17:26:02 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:02.254242Z [info     ] runtime_context_resolved       latitude=xx location_source=settings longitude=xx panel_group_source=sfml panel_groups=2
Aug 20 17:26:02 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:02.255455Z [info     ] weather_blender_initialized    rows=46
Aug 20 17:26:02 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:02.814150Z [info     ] base_model_loaded              path=/app/models/base/TFS-V2_pretrain_best.safetensors.enc
Aug 20 17:26:02 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:02.994995Z [info     ] lora_applied                   instance=default val_loss=0.03782
Aug 20 17:26:03 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:03.019789Z [info     ] startup_notification           adapter_path=/config/toorox_foresight_ha/lora/lora_default.safetensors adapter_status=active base_model_hash=9f032a4b93da1794 base_model_path=/app/models/base/TFS-V2_pretrain_best.safetensors.enc codename=Phoenix panel_groups=2 version=28.0.0
Aug 20 17:26:03 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:03.022053Z [info     ] forecast_job_registered        kind=fixed spec=00:30
Aug 20 17:26:03 LibreELEC 78b980aa567f[755]: /usr/local/lib/python3.12/site-packages/tzlocal/unix.py:208: UserWarning: Can not find any timezone configuration, defaulting to UTC.
Aug 20 17:26:03 LibreELEC 78b980aa567f[755]:   warnings.warn("Can not find any timezone configuration, defaulting to UTC.")
Aug 20 17:26:03 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:03.101316Z [info     ] forecast_job_registered        kind=solar_dynamic next_run_local=2026-08-21T05:17:21.426479+02:00 next_run_utc=2026-08-21T03:17:21.426479+00:00 spec=sunrise-45
Aug 20 17:26:03 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:03.102209Z [info     ] finetune_job_registered        at=00:00 timezone=Europe/Vienna
Aug 20 17:26:03 LibreELEC 78b980aa567f[755]: 2026-08-20T15:26:03.104028Z [info     ] scheduler_started              timezone=Europe/Vienna
Aug 20 17:26:03 LibreELEC 78b980aa567f[755]: INFO:     Application startup complete.
Aug 20 17:26:03 LibreELEC 78b980aa567f[755]: INFO:     Uvicorn running on http://0.0.0.0:8780 (Press CTRL+C to quit)
29

Das Problem hatte ich auch. Im allwissenden Netz habe ich dann diesen Vorschlag gefunden:

- /etc/localtime:/etc/localtime:ro

Die lokale Datei /etc/localtime (ein Symlink) wird unter volumes auf das Verzeichnis /etc des Containers gemapped.

lrwxrwxrwx 1 root root 33 Nov 24  2024 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin

Im container stand da schlicht nix, deshalb hat er sicherheitshalber mit UTC gearbeitet. Der container ist ja eigentlich auch für das HA-OS als addon gedacht. Vielleicht tritt das Problem in dieser Zielumgebung nicht auf.

31

Die KI hat mir folgende Ergänzung für das Dockerfile vorgeschlagen:

# Zeitzonen-Paket installieren und konfigurieren
RUN apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get install -y tzdata && \
    ln -fs /usr/share/zoneinfo/Europe/Berlin /etc/localtime && \
    echo "Europe/Berlin" > /etc/timezone && \
    rm -rf /var/lib/apt/lists/*

Die Fehlermeldung ist im Journal damit weg. Jedoch haben die Logeinträge im Journal immer noch 2 Stunden Versatz.

Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.064250Z [info     ] tfs_bootstrap                  codename=Phoenix state_dir=/config/toorox_foresight_ha version=28.0.0
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.067478Z [info     ] state_db_schema_ready          version=1
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.067804Z [info     ] state_db_connected             path=/config/toorox_foresight_ha/tfs.db
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.087850Z [info     ] runtime_context_resolved       latitude=xx location_source=settings longitude=xx panel_group_source=sfml panel_groups=2
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.088729Z [info     ] weather_blender_initialized    rows=46
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.509571Z [info     ] base_model_loaded              path=/app/models/base/TFS-V2_pretrain_best.safetensors.enc
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.616992Z [info     ] lora_applied                   instance=default val_loss=0.03782
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.631167Z [info     ] startup_notification           adapter_path=/config/toorox_foresight_ha/lora/lora_default.safetensors adapter_status=active base_model_hash=9f032a4b93da1794 base_model_path=/app/models/base/TFS-V2_pretrain_best.safetensors.enc codename=Phoenix panel_groups=2 version=28.0.0
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.632013Z [info     ] forecast_job_registered        kind=fixed spec=00:30
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.702919Z [info     ] forecast_job_registered        kind=solar_dynamic next_run_local=2026-08-21T05:17:21.426479+02:00 next_run_utc=2026-08-21T03:17:21.426479+00:00 spec=sunrise-45
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.703530Z [info     ] finetune_job_registered        at=00:00 timezone=Europe/Vienna
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: 2026-08-20T16:44:39.704535Z [info     ] scheduler_started              timezone=Europe/Vienna
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: INFO:     Application startup complete.
Aug 20 18:44:39 LibreELEC eb6397519dde[755]: INFO:     Uvicorn running on http://0.0.0.0:8780 (Press CTRL+C to quit)

/etc/localtime

gibt es auf Libreelec leider nicht.

docker exec -it toorox-foresight date

gibt jetzt die korrekte Zeit aus

:crayon:by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)

32

Ich muss mich nochmal melden, lt. Github erfolgt täglich um 02:00 Uhr das Finetuning.

Lt. meinem Journal startet es jedoch bereits um 0 Uhr:

Aug 23 00:00:40 LibreELEC 12d733e36474[755]: 2026-08-22T22:00:40.414623Z [info     ] finetune_dataset_progress      offset=10/200 samples=10
Aug 23 00:01:20 LibreELEC 12d733e36474[755]: 2026-08-22T22:01:20.660337Z [info     ] finetune_dataset_progress      offset=20/200 samples=20

Liegt hier immer noch ein Uhrzeitproblem vor?

Wie bereits geschrieben

docker exec -it toorox-foresight date

gibt jetzt die korrekte Uhrzeit aus.

EDIT:

- TFS_FINETUNE_TIME=02:00

soll lt. KI funktionieren, ich werde es testen.

33

Ich weiß nicht wie es im Container ist, aber in der TFS App kann man den Trainingszeitraum festlegen.

34

wird leider ignoriert, hat sonst jemand eine Idee, wie man das Finetuning um 02:00 Uhr startet?

@Tom-HA wäre es möglich, die Finetuning-Startzeit auch im separaten Container konfigurierbar zu machen?

35

Ich habe im Dockerfile nur die erste Zeile auf diesen Wert

ARG BUILD_FROM=ubuntu

geändert, und konnte den container dann bauen. Und ich nutze docker-compose, weil ich das bequemer finde.

  toorox-foresight:
    #build: /home/tz/tsf/TFS-HA-SFML-Transformer-AI-28.0.0/toorox_foresight_ha
    image: toorox_foresight_ha:latest
    container_name: toorox-foresight
    restart: unless-stopped
    ports:
      - "8780:8780"
    volumes:
      - /opt/homeassistant/config:/config
      - /etc/localtime:/etc/localtime:ro
      # Benötigt für den SSH-Tunnel und automatischen Datenimport aus HA
      - ~/.ssh:/host_ssh:ro
    environment:
      - TFS_TIMEZONE_STR=Europe/Berlin
      - TFS_LATITUDE=52.xxx
      - TFS_LONGITUDE=9.xxx
      - TFS_STATE_DIR=/config/toorox_foresight_ha

Vielleicht würde es ja funktionieren, die Umgbungsvariable unter “environment:” zu definieren. “Versuch macht kluch …”

36

Ich habe den Container nach deiner Anleitung gebaut und verwende auch docker-compose. Die Umgebungsvariable

- TFS_FINETUNE_TIME=02:00

habe ich versucht, hat jedoch keine Auswirkung auf den Startzeitpunkt des Finetunings.

Könnte die Zeit vor dem Bau des Containers hier festgelegt werden?

37

Ich habe bei mir ins Log geschaut. Bei mir ist die fintune-Zeit 22:00 Uhr. Und ich meine, das war schon immer so:

2026-08-23T22:00:00.127675Z [info     ] finetune_dataset_building      actuals_count=1099 degradation_count=1464 end_date=2026-08-23 groups=3 max_samples=200 start_date=2026-06-24 step_hours=6 weather_count=1368

Und ich kann mich nicht erinnern, dass ich eine config.yaml mit ähnlichem Inhalt angelegt hatte bzw. habe. Der container startete, machte seinen Port auf 8780 auf, und wurde danach vom SFML gefunden. Die ursprünglich Fehlermeldung “could not connect to …” OSLT verschwand und wurde durch das Protokoll der Leseergebnisse ersetzt.

Im “Inspect” zum Portainer finde ich bei mir das hier:

Env:[
"TFS_LONGITUDE=9.xxx",
"TFS_STATE_DIR=/config/toorox_foresight_ha",
"TFS_TIMEZONE_STR=Europe/Berlin",
"TFS_LATITUDE=52.xxx",
"PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"LANG=C.UTF-8",
"PYTHONUNBUFFERED=1",
"PYTHONDONTWRITEBYTECODE=1",
"PIP_NO_CACHE_DIR=1",
"PIP_DISABLE_PIP_VERSION_CHECK=1",
"PYTHONPATH=/app",
"TFS_MODEL_DIR=/app/models",
"OMP_NUM_THREADS=4",
"MKL_NUM_THREADS=4"
],
ExposedPorts:{
8780/tcp:{
}
},

Wenn bei Dir dann noch die envvar TFS_FINETUNE_TIME auftauchen sollte, denke ich, dass es ein bug in TFS sein müsste, weil die Variable nicht berücksichtigt wird.

Wie sieht denn denn dein docker-compose.yaml aus? ansonsten genauso, wie meines?

38

Meine docker-compose.yml sieht so aus

  toorox-foresight:
    image: toorox_foresight_ha:latest
    container_name: toorox-foresight
    restart: unless-stopped
    ports:
      - "8780:8780"
    volumes:
      - /storage/.kodi/userdata/homeassistant:/config
    environment:
      - TFS_TIMEZONE_STR=Europe/Vienna
      - TFS_LATITUDE=4.x
      - TFS_LONGITUDE=1.x
      - TFS_FINETUNE_TIME=02:00
      - TFS_STATE_DIR=/config/toorox_foresight_ha

TS-FINETUNE_TIME habe ich gem. KI-Vorschlag hinzugefügt, funktioniert jedoch nicht. Gem. Github erfolgt das Finetuning täglich um 02:00 Uhr.
Diese Uhrzeit kann selbst festlegen, wenn die App in homeassistant installiert wird.
Es müsste daher eine Variable geben, die beim Start des Containers übergeben werden kann oder vielleicht beim Bau des Containers festgelegt wird.

39

Im code wird in der Tat auch diese envvar eingelesen:

    options_path = os.environ.get("TFS_OPTIONS_JSON")
    if options_path and Path(options_path).exists():
        with open(options_path) as f:
            options: dict[str, Any] = json.load(f)
        for key in ("latitude", "longitude", "log_level"):
            if key in options and options[key] is not None:
                setattr(settings, key, options[key])
        if "forecast_times" in options and options["forecast_times"]:
            settings.timing.forecast_times = list(options["forecast_times"])
        if "finetune_time" in options:
            settings.timing.finetune_time = options["finetune_time"]
        if "auto_finetune" in options:
            settings.timing.auto_finetune = bool(options["auto_finetune"])

(aus config.py). Ob sie allerdings berücksichtigt wird, habe ich noch nicht gefunden. Vielleicht mache ich mal einen fork oder pull, dann geht’s schneller.

Bei deinem Volume-MApping ist mir allerdings noch aufgefallen, dass das /config Dir von TFS auf dem Host in “/storage/.kodi/userdata/homeassistant” zeigt. Ist das das config Dir von homeassistant?

Hast du portainer installiert? Falls nicht, das ist sehr empfehlenswert. Erleichtert die Überwachung von Containern ungemein. Mein compose-Eintrag:

  portainer:
    container_name: portainer
    image: portainer/portainer-ce
    restart: always
    ports:
      - "9000:9000/tcp"
    environment:
      - TZ=Europe/London
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/portainer:/data

Und da sehe ich doch gleich, dass ich noch die falsche TZ konfiguriert habe :slight_smile:.

40

Ja, das confdir für homeassistant passt. Portainer hab ich noch nicht installiert, hab mich bisher mit den docker-compose Befehlen über SSH vorangekämpft.

KI hat mir die config.py ergänzt, damit ich FINETUNE-TIME als Variable übergeben kann.
Log schaut jetzt gut aus:

Aug 24 17:03:14 LibreELEC 409c640c0c93[730]: INFO:     Started server process [7]
Aug 24 17:03:14 LibreELEC 409c640c0c93[730]: INFO:     Waiting for application startup.
Aug 24 17:03:14 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:14.533672Z [info     ] tfs_bootstrap                  codename=Phoenix state_dir=/config/toorox_foresight_ha version=28.0.0
Aug 24 17:03:14 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:14.535323Z [info     ] state_db_schema_ready          version=1
Aug 24 17:03:14 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:14.535567Z [info     ] state_db_connected             path=/config/toorox_foresight_ha/tfs.db
Aug 24 17:03:14 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:14.549841Z [info     ] runtime_context_resolved       latitude=xx location_source=settings longitude=xx panel_group_source=sfml panel_groups=2
Aug 24 17:03:14 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:14.550638Z [info     ] weather_blender_initialized    rows=46
Aug 24 17:03:14 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:14.982889Z [info     ] base_model_loaded              path=/app/models/base/TFS-V2_pretrain_best.safetensors.enc
Aug 24 17:03:15 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:15.102347Z [info     ] lora_applied                   instance=default val_loss=0.037209
Aug 24 17:03:15 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:15.116298Z [info     ] startup_notification           adapter_path=/config/toorox_foresight_ha/lora/lora_default.safetensors adapter_status=active base_model_hash=9f032a4b93da1794 base_model_path=/app/models/base/TFS-V2_pretrain_best.safetensors.enc codename=Phoenix panel_groups=2 version=28.0.0
Aug 24 17:03:15 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:15.117166Z [info     ] forecast_job_registered        kind=fixed spec=00:30
Aug 24 17:03:15 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:15.180599Z [info     ] forecast_job_registered        kind=solar_dynamic next_run_local=2026-08-25T05:22:37.932372+02:00 next_run_utc=2026-08-25T03:22:37.932372+00:00 spec=sunrise-45
Aug 24 17:03:15 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:15.181027Z [info     ] finetune_job_registered        at=02:00 timezone=Europe/Vienna
Aug 24 17:03:15 LibreELEC 409c640c0c93[730]: 2026-08-24T15:03:15.181925Z [info     ] scheduler_started              timezone=Europe/Vienna
Aug 24 17:03:15 LibreELEC 409c640c0c93[730]: INFO:     Application startup complete.
Aug 24 17:03:15 LibreELEC 409c640c0c93[730]: INFO:     Uvicorn running on http://0.0.0.0:8780 (Press CTRL+C to quit)

  toorox-foresight:
    image: toorox_foresight_ha:latest
    container_name: toorox-foresight
    restart: unless-stopped
    ports:
      - "8780:8780"
    volumes:
      - /storage/.kodi/userdata/homeassistant:/config
    environment:
      - TFS_TIMEZONE_STR=Europe/Vienna
      - TFS_LATITUDE=xx
      - TFS_LONGITUDE=xx
      - TFS_FINETUNE_TIME=02:00
      - TFS_AUTO_FINETUNE=true
      - TFS_STATE_DIR=/config/toorox_foresight_ha

config.txt (10,3 KB)

41

Das sollte alles funktionieren. Ich habe bei mal die finetune Zeit auf 21:00 Uhr gestellt. Mal schauen, was geschieht …

Das Start-Log sieht sehr ähnlich aus. Nur die TT wicht deutlich ab :slight_smile:.

INFO:     Started server process [7]
INFO:     Waiting for application startup.
2026-08-24T15:20:12.103377Z [info     ] tfs_bootstrap                  codename=Phoenix state_dir=/config/toorox_foresight_ha version=28.0.0
2026-08-24T15:20:12.105639Z [info     ] state_db_schema_ready          version=1
2026-08-24T15:20:12.105838Z [info     ] state_db_connected             path=/config/toorox_foresight_ha/tfs.db
2026-08-24T15:20:12.117107Z [info     ] runtime_context_resolved       latitude=52.xxx location_source=settings longitude=9.xxx panel_group_source=sfml panel_groups=3
2026-08-24T15:20:12.117865Z [info     ] weather_blender_initialized    rows=46
2026-08-24T15:20:12.715774Z [info     ] base_model_loaded              path=/app/models/base/TFS-V2_pretrain_best.safetensors.enc
2026-08-24T15:20:12.809052Z [info     ] lora_applied                   instance=default val_loss=0.037551
2026-08-24T15:20:12.818967Z [info     ] startup_notification           adapter_path=/config/toorox_foresight_ha/lora/lora_default.safetensors adapter_status=active base_model_hash=9f032a4b93da1794 base_model_path=/app/models/base/TFS-V2_pretrain_best.safetensors.enc codename=Phoenix panel_groups=3 version=28.0.0
2026-08-24T15:20:12.822064Z [info     ] forecast_job_registered        kind=fixed spec=00:30
2026-08-24T15:20:12.877510Z [info     ] forecast_job_registered        kind=solar_dynamic next_run_local=2026-08-25T05:37:24.755875+02:00 next_run_utc=2026-08-25T03:37:24.755875+00:00 spec=sunrise-45
2026-08-24T15:20:12.877867Z [info     ] finetune_job_registered        at=00:00 timezone=Europe/Berlin
2026-08-24T15:20:12.878767Z [info     ] scheduler_started              timezone=Europe/Berlin
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8780 (Press CTRL+C to quit)

Und wie man sieht, wird auch bei mir mit UTC gelogged. Warum das so ist, ist mir nicht klar. Die Dateien im container haben den owner root:root, und die Zeit für root zeigt

root@8192bf43d25b:/app# date
Mon Aug 24 17:28:50 CEST 2026