TFS Docker Standalone Version mit ZARA Multihead Transformer (Proxmox, Linux, MacOsX)

TFS Docker Standalone Version mit ZARA Multihead Transformer (BETA) :rocket:

BITTE UNBEDINGT VOR DER INSTALLATION LESEN!

Dies ist keine einfache App oder leichtgewichtiges Add-on. Ihr installiert hier einen echten, lokal trainierenden Multi-Head Transformer mit kontinuierlicher Selbstoptimierung. Der mit der Hilfe von Home Assistant Solar-Prognosen erstellt.

(Tipp: Falls ihr nicht tief im Thema seid, kopiert den technischen Teil in eine KI und lasst ihn euch erklären: „Erkläre mir bitte, was ich hier vor mir habe, worauf muss ich achten, was ist ein Transformer und was macht dieses Modell besonders?“)

Technischer Hinweis: ZARA Architecture (BETA)

ZARA steht für Zero-latency Adaptive Runtime Architecture – ein vollwertiger 3-Stream Encoder-Decoder Transformer (verwandt mit modernen LLM-Architekturen wie LLaMA), der speziell für präzise 72-Stunden-Energieprognosen und kalibrierte Unsicherheitsbänder entwickelt wurde.

Es handelt sich nicht um ein klassisches ML-Modell oder eine einfache Vorhersage-App, sondern um eine rechenintensive, sich selbst optimierende Machine-Learning-Umgebung, die lokal auf eurer Hardware läuft.

Features:

-Multi-Core Support

  • CUDA, ROCm und MLX Support
  • MQTT Broker
  • ModBus Anbindung (im Test)
  • Eigenes Backend
  • Eigenes Frontent
  • Mächtige Transformer KI
  • 18 Jahre Wetterdaten aus einem engmaschigen Grid (ca. 50 Millionen Datenpunkte)
  • 13 Jahre Klimadaten, Jahreszeiten für 180 Standorte in DE
  • 18 Jahre Solardaten incl GHI und Clearsky für Europa
  • Eigene Wetter-Engine die aus ICON, ECWMF und DWD eigenen Solarwetter-prognosen erstellt
  • Selbstlernde auf den eigenen Standort
  • Anbindung an Wetterstationen (via HA Sensoren)
  • Mächtige Logik und Prognosekorrektur
  • Quantillenausgabe (P10, P50, P90)
  • Medianberechung
  • Drifterkennung und Emergency Training
  • SQL Datenbank
  • API zu Home Assistant via verschlüsseltem SSH
  • Rein Lokal keine Webservices, keine Telemetrie, kein Datenabfluß
  • Verschiedene Prognosemodi incl Blend-Logik
  • Wetter-Blend Automatik
  • Physic-Backbone
  • Anti “Ich rate mal” Logik
  • Insighs um die KI zu überwachen

Wichtige Systemvoraussetzungen

Diese Version benötigt dedizierte Ressourcen. Sie läuft nicht gut auf bereits ausgelasteten Systemen oder schwacher Hardware.

Empfohlen (für stabilen Betrieb):

  • Mindestens 4–6 GB RAM frei (besser 8 GB+)
  • Moderner x86_64-Prozessor mit AVX2-Unterstützung (Intel 6. Gen+ oder Ryzen)
  • SSD/NVMe Speicher
  • Dedizierte Docker-Umgebung (nicht auf einem überlasteten Mini-PC oder vollen Raspberry Pi)

Nicht empfohlen:

  • Stark ausgelastete NUCs oder Einplatinencomputer
  • Systeme ohne AVX2
  • Weniger als 4 GB freier RAM

Technische Spezifikationen – Was macht ZARA so besonders?

  • Struktur: 3-Stream Encoder-Decoder Transformer
    Encoder: 6 Layer | Decoder: 4 Layer
    Modell-Dimension: $d_{model}=256$, 8 Attention-Heads (4 KV-Heads mit GQA)

  • Kern-Technologien:

Komponente Technologie Funktion
Attention Flash Attention + GQA Reduziert KV-Cache um ~50 % bei voller Leistung
Positional Encoding RoPE Präzise relative Positionierung über lange Sequenzen
Activation SwiGLU Deutlich effizienter und stabiler als klassisches GELU
Routing MoE (Top-2 aus 4 Experten) Spezialisierte Experten für verschiedene Wetterregime
Normalization RevIN Entfernt saisonale Verschiebungen automatisch
Physics Layer Constraint Layer Verhindert physikalisch unmögliche Vorhersagen (z. B. Strom nachts)
Output Quantile Regression Liefert P10 / P50 / P90 Konfidenzintervalle statt einfacher Punktwerte

Adaptivität & Lernen:

  • Vollkommen lokal, keine Cloud, keine externen APIs
  • Täglich: Automatische Prognosegüte-Analyse
  • Wöchentlich: Micro-Finetuning
  • Monatlich: Full Retrain gegen Model Drift
  • Integrierte Drift Detection startet bei Bedarf automatisch Korrektur-Training

Fazit: ZARA ist ein hochmodernes, aufgabenspezifisches neuronales Netz, das echtes Kontext-Reasoning über Wetter- und Produktionsmuster betreibt – weit über das hinaus, was klassische Solarprognose-Modelle leisten können.

Installation – TFS Docker Standalone (BETA)

Linux (Bare Metal / VM)

  1. Docker installieren (falls noch nicht vorhanden):
curl -fsSL https://get.docker.com | sh
  1. Image entpacken und laden:
docker load < toorox-foresight-beta.tar.gz
  1. Container starten:
docker run -d \
  --name toorox-foresight \
  --restart unless-stopped \
  -p 8780:8780 \
  -v toorox_data:/data \
  -v ~/.ssh:/host_ssh:ro \
  toorox-foresight:latest
  1. Im Browser öffnen:

http://<DEINE-IP>:8780

Der Setup-Wizard führt euch durch alles Weitere.

Proxmox

Option A – LXC (empfohlen, leichtgewichtig):

  • Neuen LXC-Container erstellen (Debian 12 Template)
  • 4 GB RAM, 8 GB Disk, 2 Cores
  • Feature nesting=1 aktivieren
  • Dann im LXC die gleichen Docker-Befehle wie oben ausführen

Option B – VM:

  • Normale VM mit Debian 12 oder Ubuntu 24.04
  • Mind. 4 GB RAM, 16 GB Disk, 2 Cores
  • OS installieren → dann Docker-Befehle

Nach dem Start

  1. Browser: http://<IP>:8780
  2. Setup-Wizard starten
  3. SSH-Zugangsdaten zu eurem Home Assistant eingeben → Testverbindung
  4. „Import Configuration“ klicken → TFS liest automatisch alle Daten aus der SFML-Datenbank (Anlage, Panelgruppen, Sensoren, Standort etc.)
  5. „Start Fine-Tuning“ → ZARA lernt eure Anlage (ca. 1–2 Minuten pro Epoch)
  6. Fertig – die Forecasts laufen automatisch und werden kontinuierlich optimiert

Fragen, Probleme oder Erfahrungsberichte gerne hier im Thread!
Bitte keine Fragen nach " Wie installiere ich ein Docker-Image"

Viel Spaß mit ZARA!


RELEASE: 16.04.2026 (BETA 1)

Fuel my late-night ideas with a coffee? I’d really appreciate it — keep this project running!

Buy Me a Coffee

2 „Gefällt mir“

3 Stufiges einfaches Setup für Home Assistant Anbindung. incl Recorder Import der benöigten Daten UND überisicht des Fine-Tuning auf die Anlage

Dashboard mit den wichtigens Informatione sofern man TFS nicht headless betreiben möchte:

Einfache Konfiguration sofern man nicht die Daten aus HA importiert:

Einfache Überwachung des Modells und seiner verwendeten Parameter:

Kontrollzentrum

Was soll ich bloß sagen :+1:

1 „Gefällt mir“

Danke! Das war auch eine MENGE Arbeit.. aber wir beide haben ja eh noch ein Date :slight_smile:
Das hier ist die erste Beta das Design und Funktioinen kommen dann später.
Kannst Du mit mal bitte einen Gefallen tun und den Prompt mit dem kompletten Text ausprobieren ob das so funktioinert das es in eine leicht verständliche Erklärung umgewandelt wird.. sonst änder ich den Prompt noch ein wenig ab

1 „Gefällt mir“

Der finale Live-Test direkt nach der Installation ist durch. Die Bedingungen waren denkbar schlecht (Wechsel zwischen Sonne und Regen, dazu Saharastaub), aber das Modell hält stand. Daten wurde vom HA-Recorder gepollt. Prognose wurde um 3:25 Uhr erstellt und fixiert (kein Nachregeln)

IST:

Nur 5 % Abweichung am zweiten Tag nach der Installation! Besonders die integrierten Satellitendaten machen bei der Wolkenbestimmung den entscheidenden Unterschied!

1 „Gefällt mir“

Wie kann ich mir das praktisch vorstellen? Da steht also ein externer, performanter Rechenknecht, der Daten aus dem HA holt, den Forecast berechnet und dann an HA zurückgibt um Automatisierungen zu steuern? Der Rechenknecht muss ständig verfügbar sein oder reicht das eine begrenzte Zeit am Tag? So ala UUCP-Mailtransport aus den Anfangszeiten des Internets?

Das sieht doch sehr gut aus.

Was mich mal interessiert, wie zuverlässig sind die Werte von Tomorrow also morgen?

Bei SFML hab ich halt leider oft gemerkt das sie nicht sehr aussagekräftig sind, klar können sie nicht 98% genau sein.

Mal als Beispiel, gesagt wird morgen soll ich 6 kWh produzieren, wenn dann aber der Tag morgen kommt und der Tomorrow Wert quasi heute ist, dann wurde er bei der Berechnung/Forecast morgens Früh auf 4 kWh korrigiert.

Also quasi nicht nutzbar um zb. zusagen, ach heute ist nicht viel Solar, morgen soll aber viel sein, also Wasch ich morgen erst

So ungefähr.. lass es mich so erklären:

TSF (Toroox ForeSight): Deep Tech & Wissenschaftliche Präzision

Kurz und knackig: TSF spielt technisch in derselben Liga wie GPT-4 – nur dass es nicht Gedichte schreibt, sondern Energieprognosen macht.

Die Architektur: ZARA & das Ensemble

Im Herzen schlägt ZARA (Zero-latency Adaptive Runtime Architecture). Ein Multi-Head-Transformer, der exakt die gleichen Mathematik benutzt wie die großen LLMs da draußen.

  • 800 Millionen Datenpunkte – das ist, als hätte SFML 20 Jahre nonstop Kaffee getrunken und nur über Wetter und Sonne nachgedacht.
  • Multimodale Integration: Ein extra (seperater) 4-Head-Transformer mixt EUMETSAT-Satellitenbilder, frische Wetterdaten und 13 Jahre Klimageschichte zu einem Daten-Cocktail.
  • Wissenschaftliche Validierung: Kein „vielleicht wird die Sonne scheinen“. Stattdessen saubere Quantile (P10 bis P90). Das ist stochastische Gewissheit – Enterprise-Level. Kombiniert mit spezifischen Anlagenwissen.

Hardware-Anforderungen: Real Talk

Wer denkt, er kann so ein Modell auf einem 200-€ Mini-PC oder einem alten Celeron zum Laufen bringen… nun ja… viel Spaß dabei. :grinning_face_with_smiling_eyes:

Das hier sind keine simplen Text-Spaghetti, das sind fette Matrix-Multiplikationen. Die Power benötigen..

AMD-CPU vs. GPU Benchmark (beim Initial-Training):

  • High-End CPU (Ryzen 12 Kerne, 64 GB RAM): ~40 Minuten
  • Mittelklasse GPU (8 GB VRAM): ~6 Minuten

Ich hab’s zwar ordentlich optimiert, sodass es auch auf der CPU läuft – aber ehrlich? Die GPU ist einfach das natürliche Habitat für eine KI. Das weiß jeder, der mal lokale KI`s wie Qwenn, LLAMA und Co ausprobiert hat.

Grid-Search & Hyperparameter-Optimierung

Das, was TSF von den meisten unterscheidet, ist der Grid-Search. Die KI probiert millionen Parameter-Kombinationen durch, bis sie das perfekte mathematische Setup für genau deinen Standort gefunden hat.

Billig-Prozessoren und alte Celerons geben da meist nach kurzer Zeit den Geist auf und flüstern leise: „Bro… das war’s für mich.“ - sie verfügen schlicht nicht über die korrekten Befehlssätze.

Warum TSF nicht direkt in Home Assistant läuft

HA ist genial für Automatisierung – aber für schwere KI-Berechnungen eher suboptimal. Der Event-Loop frisst alles über einen einzigen Kern, egal wie viele Kerne dein Server hat. → Ein Umstand der seit Jahren heftig kritisiert wird, da es HA völlig egal ist wie neu oder performat deine CPU ist.. es zählt nur die Single-Core Leistung.

Deshalb läuft TSF als eigener Docker-Container auf einem getrennten System oder in einer VM ausserhalb von HA: Holt sich die Daten sicher per SSH, rechnet 45 Minuten vor Sonnenaufgang die Prognose durch und schiebt das Ergebnis sauber per REST oder MQTT zurück. Clean. Elegant.

Fazit

Die Hardware-Empfehlungen sind keine böse Absicht – das ist einfach nur Physik und Mathe. !Wenn du wissenschaftlich fundierte Solar- und Energieprognosen auf LLM-Niveau willst, dann ist TSF genau das richtige Spielzeug für dich.
Einmal fine-getuned, einmal Grid-Search durchgezogen, einmal Training abgeschlossen – und danach chillt der Container die meiste Zeit entspannt im Hintergrund.

Er ist extra auf Stromsparen und Effizienz getrimmt. Die richtig fette Rechenpower braucht er eigentlich nur bei der Erstinstallation, beim Grid-Search und beim Training.
Die laufenden Prognosen sind dagegen eher kleine, schnelle Prozesse. Genau das macht ihn so attraktiv für Proxmox, VMs oder reines Linux: Er ist genau dann da, wenn du ihn brauchst – und ansonsten idlet er brav vor sich hin, ohne dein System unnötig zu belasten.

Zu deiner zweiten Frage.. Temporär dazuschalten.. JaEin.. Grundsätzlich würde es gehen, da er ein Back-Fill Mechanismus hat, aber die Drift-Detection und die damit verbundenen Trigger würden brechen.

Das ist aktuell nicht der Fokus.. die meiste Rechenleistung geht in dern 24 Stunden Forecast und die Genauigkeit der Folgetage liegt zwischen 89,2 und 93%. aber an dieser Stelle wird gelernt, da u.A. mittels Luftdruck die Wetterstabilität bestimmt wird.
Grundsätzlich ist der Prognose-Prozess ein völlig anderer als der von SFML.

1 „Gefällt mir“

Gibt es ein Problem, wenn ich erst die App installiere und danach dann die Standalone Version?

Nein, die beiden sind völlig unabhängig funktioineren unabhängig nutzen unabhängige Daten, haben unterschiedliche Metriken..

Die App ist der “kleine Bruder” und erstellt auch keine Prognose, die man nutzen könnte, sondern liefert nur RAW-Daten an SFML.. anders wäre es überhaupt nicht möglich sie überhaupt auf HA zu bekommen.

TFS HA: Produziert valide Layer für SFML.. kann selbst keine Prognose → Braucht HA als Host und SFML

TFS DO: Unabhänig von HA erstellt Prognosen und vieles mehr. → hat nichts mit SFML oder HA zu tun

Komplett unterschiedliche Designs und Konzepte. TFS Docker Standalson hat ungefähr die doppelte Power und Resouchenbedarf wie TFS Home Assistant App und nutz komplett andere Skripte und Biblotheken die unter HA nicht lauffähig sind. Er würde Home Assistant zum Frühstück fressen und die CPU im HA würde abschalten wegen Thermischer Überlastung.. wenn nicht würde er den HA vermutlich für 2 - 4 Tage komplett blockieren..

Eiin PI 4 ohne Lüfter ist schlicht den Hitzetod gestorben, da er völlig überhitzt.. und dann abgeschaltet hat. → mit Lüfter ging es dann hat aber knapp 20 Std gedauert bis das FineTuning mit 100 Epochs durch gewesen ist… Pi 4 8GB RAM 1 Container Ha und ein 1 Container TSF DO → daher der Hinweis PI 5 mit SSD und 8GB ist das absolut untere Ende der Leistungskette bei ARM und es darf nichts anderes darauf Laufen.. dann schafft er es in 2 - 4 Std je nach Backfill aus dem Recorder. danach idelt der PI bei 3 Watt vor sich hin…

Mit Abstand am Besten sind AMD-Prozessoren.. mir scheint das die es überhaupt nicht interessiert.. hat schon einen Grund warum Intel seit Jahren abrutscht.. irgendwas mach AMD besser und efizienter bei den Befehlen.. aber da kenne ich mich nicht aus.

1 „Gefällt mir“

Also werden dann neue Forecast Sensoren in HA Erstellt oder sind es weiter die SFML Sensoren, die dann die „Unterstützung“ von TFS haben?

TFS Docker hat überhaupt nichts mit SFML zu tun!!

Also nein.. hat nichts mit SFML zu tun sind eigene Sensoren .. Bitte nicht verwechseln!

ich hatte fürs ausprobieren meinen Desktop nehmen wollen. Der ist aber nicht als 24/7 immer-an-Server gedacht. Sollte aber von der Performance her gehen:

Ryzen 7 7800x3d

32 Gbyte DDR5

2 TByte NVMe M.2 SSD

Radeon RX7700XT mit 12 GB DDR6

Aber die Ergebnisse kann ich dann in HA weiterverarbeiten? Um z.B. die Wärmepumpe zu steuern?

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

WOW! - Perfektes Setup! Das ist genau die HW für die es gebaut wurde.. darauf wird es “fliegen” !

Ja natürlich.. sind ja ganz normale MQTT Sensoren.. HA Standard .. aber haben eben NICHTS mir SFML zu tun

Mein Plex Server langweilt sich mit einer NVIDIA T600 mit 4GB RAM von PNY. Reicht die graka aus um die docker Version sinnvoll zu betreiben?

Ja, aber in Abhängigkeit mit dem Prozessor.. grundsätzlich hat sie CUDA sowie
PyTorch/TensorFlow mit CUDA-Unterstützung.
Da ZARA nicht quantisiert ist, sollte sie 5–15 Tokens/sek schaffen → aber die Frage bleibt.. welche CPU?

Ich könnte das anbieten

CPU Intel Core i5-6400
Mainboard MSI Z170-A PRO
RAM 32 GB DDR4-3200 (G.Skill)
GPU RTX 3060 12 GB (Palit)
Netzteil Seasonic SSR-550FX 550W Gold
SSD 500 GB
OS Ubuntu Server 24.04 LTS

Oder einen PI 5 mit 16 GB

Input nur noch per API / MQTT wie hier beschrieben und das Tool ist komplett gekapselt / isoliert: Wichtige Info: Zukunft von SFML // Docker - Version - #3 von Tom-HA

Nur die MQTT / API-Ports für dieses Docker-Image freigeben und lokaler sicherer geht es dann (fast) nicht mehr.

Richtig cool, dann kann auch ich es mit meiner Sicherheitsparanoia endlich einsetzen :smiley:

da reihe ich mich gern ein… auch wenn ich einiges “umständlich” mache (aus der Sicht anderere) so ist genau das die erste Überlegung die ich anstelle " Wie ist es sicher, wie verhindere ich Datenabfluss, was ist das aboslute minimum an das Daten das ich brauche.. ich bin da ganz bei dir!

1 „Gefällt mir“