Wichtige Info: Zukunft von SFML // Docker - Version

[Tom-HA]

Update zur Zukunft von SFML: Neue Wege und KI-Power

Aufgrund aktueller Differenzen mit der US-amerikanischen Firma Nabu Casa (Home Assistant und weitere iOt Produkte) und den daraus resultierenden Folgen für die Entwickler habe ich die strategische Ausrichtung von SFML überdacht. Besonders das Feedback aus der Proxmox- und VM-Community nach einer Docker-Lösung hat bei der Entscheidung eine zentrale Rolle gespielt.
Eine Komerzialisierung ist und bleibt weiterhin ausgeschlossen! - Klares NEIN!

Die Entscheidung

• SFML bleibt als HA-Integration bestehen! (Keine Diskussion) und wird NICHT eingestellt und ganz normal weiterentwickelt! Ebenso Stats und alles andere!
• SFML erhält parallel eine eigenständige Docker-Version “toorox foreSight”.

Die Docker-Version läuft unabhängig von Home Assistant als Host in einem eigenen Container (vergleichbar mit AdGuard oder Paperless).
Home Assistant wird dabei zum reinen „Datensammler“, während toorox foreSight autark agiert. Das macht das System unabhängig von Kern-Problemen des HA-Core und hebt gleichzigt die aktuell sehr zähe bereitstellung von pinned Dependencies durch HA Dev auf und bietet somit deutlich kräftigere Modelle.

---

Der „Große Bruder“: Die Docker-Version

Diese Version wird eine deutlich massivere KI-Unterstützung bieten und in drei Stufen entwickelt:

1. Wetter- & Solarprognose (Test-Release Mitte / Ende April)
2. Energieverbrauchsprognose
3. LLM-Integration (KI-Sprachmodell)

Wichtige Features:

• Kommunikation via MQTT: Die Docker-Version stellt die bekannten Sensoren via MQTT für Dashboards, Automationen und eigene Entwicklungen bereit.
• Lokal & Sicher: Läuft rein lokal, ohne Internetanbindung und ohne Datenversand. Bestehende SFML-Integrationen werden gemergt.
• API-Anbindung: Die notwendigen Daten werden via API aus HA ausgelesen.
• Eigenes Webinterfache: einbindbar in Ha wie Stats (dieses Mal in React!)
• extrem einfacher Workflow

Hardware-Anforderungen

Die KI-Power benötigt Ressourcen. Plant für die Docker-Version kalkulatorisch mit:

• Mindestens 8 GB RAM
• CPU: Intel i5 (Baujahr 2016 oder jünger)

Ich freue mich darauf, das Projekt mit euch gemeinsam auf das nächste Level zu heben! - Bedanken möchte ich mich in diesem Kontext bei den Enthusiasten die gemeinsam mit mir eine Docker / Container Version Diskutiert haben!

Zara
( Zero-latency Adaptive Runtime Architecture)

Ich werde euch in diesem Thread auf dem Laufenden halten!

[Linos]

Als bisher stiller Beobachters deines Projektes SFML würde ich toorox foreSight absolut feiern und mit aufspringen.

@Tom-HA

Energieverbrauchsprognose

Meine Aufmerksamkeit liegt besonders hierauf. In meinen Augen der größte Mehrwert mit Großverbrauchern wie Wärmepumpe oder E-Auto… denn ohne Prognose-> kein Energiemanagement.

@Tom-HA

API-Anbindung: Die notwendigen Daten werden via API aus HA ausgelesen.

Vielleicht wäre auch eine zusätzlich Input-Anbindung per Mqtt möglich. Das würde das speisen direkt von zB Energiesytemen ermöglichen und so dezentralisierend wirken.

Ein weiteres Gedankenspiel bezieht sich auf Backups, um Reinforcement Learning wieder herzustellen zu können.

Hochachtungsvoll und mit größter Wertschätzung deiner Arbeit

[Tom-HA]

@Linos

@Linos

Als bisher stiller Beobachters deines Projektes SFML würde ich toorox foreSight absolut feiern und mit aufspringen.

Danke! Ich bin überzeugt davon, dass es der nächste logische Schritt sein muss.

@Linos

Meine Aufmerksamkeit liegt besonders hierauf. In meinen Augen der größte Mehrwert mit Großverbrauchern wie Wärmepumpe oder E-Auto… denn ohne Prognose-> kein Energiemanagement.

Ja, das ist mein erklärtes Ziel. Hierbei geht es aber auch um dedezierte Wärmepumpensteuerung auf dem durch die KI gelernten Dämmwerte des Hauses und persönlichen Heizbedarfes in Abhängikeit der Parameter. E-Auto ist einfach, dass kann SFML bereits sehr gut → wird übernommen

@Linos

Vielleicht wäre auch eine zusätzlich Input-Anbindung per Mqtt möglich. Das würde das speisen direkt von zB Energiesytemen ermöglichen und so dezentralisierend wirken.

Ja, da gerade Unsicherheit herrscht ob die Amerikaner das bestehende System so beibehelten ist es zwingens notwendig sich als Entwickler breiter aufzustellen. Auch bietet eine Docker-Lösung deutlich einfachere Konfigurationsflüsse zum Beispiel in Ha oder später via MQTT, API, … hier mal ein Beispiel wie simpel es ist:

Aktuell ist die Anbinung an HA implementiert.. ABER es wird in späteren Versionen möglich sein, REST API, MQTT ähnich einfach einzubinden (ein Mqtt-Broker ist bereits eingebaut):

ABER DAS IST ALLES NOCH EARLY BETA!

[Mercator]

Zwar OT, aber was gibts da?

Unsicher nacht mich grad eher deine Ausführung “Ja, da gerade Unsicherheit herrscht ob die Amerikaner das bestehende System so beibehelten i”

VG

[Linos]

@Tom-HA

Ja, da gerade Unsicherheit herrscht ob die Amerikaner das bestehende System so beibehelten

Für mich wäre es fraglich wie zuverlässig das läuft. Im Zuge eines Wanddisplays-Projektes empfand ich die API nicht sonderlich stabil und es kam häufig zu Problemen beim aktualisieren… aber Fehler meinerseits möchte ich auch nicht ausschließen

@Tom-HA

Ja, das ist mein erklärtes Ziel. Hierbei geht es aber auch um dedezierte Wärmepumpensteuerung auf dem durch die KI gelernten Dämmwerte des Hauses und persönlichen Heizbedarfes in Abhängikeit der Parameter. E-Auto ist einfach

Akku so schonend wie möglich Laden um das Ziel zum pv_ende erst zu erreichen → muss das Auto heute voll werden wenn ich den Arbeitsweg morgen noch schaffe → stattdessen lieber vorheizen weil die Nacht kalt wird.

Die thermische Kapazität eines Gebäudes ist spezifisch und statisch. Die Trägheit (warm → kalt, kalt ->warm) bei schnelle Wetterwechsel bricht jeder Interpolation das Genick

@Tom-HA

Ja, das ist mein erklärtes Ziel

Das ultimative lokale Energiemanagement
(Verbrauch, Wetter, Speicher, Erzeugung)

[lemuba]

Bei Docker bin ich zumindest raus.

Dank SFML habe ich den Schritt weg von Proxmox HA sowie den diversen zusätzlichen Proxmox-VMs und -Containern hin zu einer reinen HA-Bare-Metal-Installation geschafft. Genau so wurde es ja auch beworben. Unterm Strich bedeutet das für mich deutlich weniger Ballast und administrativen Aufwand — und genau das bevorzuge ich absolut. Paperless, evcc, aber auch SFML inklusive Stats laufen bei mir hervorragend als HA-Integration bzw. Add-on. Ich möchte keine zusätzlichen Maschinen, keine weitere Hardware und keine separaten Systeme mehr administrieren müssen. Deshalb werde ich bei meinem jetzigen Setup mit einem einzigen System in Form von HA Bare Metal bleiben — und das gefällt mir richtig gut. Einen konkreten Nutzen oder eine praktische Verwendung für eine Solarprognose hatte ich bisher zwar noch nicht, aber ich fand und finde das Thema trotzdem sehr spannend und verfolge es deshalb gerne mit. Ein zusätzliches Docker-System werde ich dafür jedoch nicht extra aufsetzen. Rein informativ bleibe ich aber gerne stiller Mitleser.

VG

[Tom-HA]

Kein Sorge! Wie ich eingangs sagte! SFML bleibt und wird weiter entwickelt! - Daran wird sich nichts ändern!
Es ist nur eine zusästzliche Option - für den der es möchte!

[seebaer1976]

freue mich wenns ans testen geht, egal ob die linux oder docker version oder auch beides

[Tom-HA]

Zwischenstand:

Die KI wird die kommenden Tag damit zubringen zu trainieren.. da ich nicht X oder NVIDA bin… kaum mit den großen Server-Farmen mithalten kann und keine Standleitung vom Kraftwerk habe.. wird das einige Tage in Anspruch nehmen. Geplant ist für den Anfang eine Transfprmer KI mit 20M Parametern..

Ich habe eine Datenbank bekommen die folgenden Daten für Deutschland enthält auf die ich die KI trainiere:

• Lat/Lon Grid über Deutschland (3.000 Punkte)
• 18 Jahre pro Punkt (2005-2023)
• 157.000 Stunden pro Punkt
• ~500 Millionen Stunden Solar-Daten
• Mit: GHI, DNI, DHI, Temperatur, Wind, PV-Produktion

es bleibt spannend!

SFML wird von dieser DB ebenfalls in zukünftigen Updates proftieren!

[ottokar]

@Tom-HA

Besonders das Feedback aus der Proxmox- und VM-Community nach einer Docker-Lösung hat bei der Entscheidung eine zentrale Rolle gespielt.

Ich habe ja aufgrund von SFML meine Home Assistant-Installation von Proxmox auf einen NUC (Bare Metal) migriert. Anschließend habe ich zusätzlich OpenCCU (Homematic) in eine Proxmox-VM ausgelagert.

Proxmox selbst läuft auf einem Lenovo M720Q mit i5-8400T und 16 GB RAM.

Eine VM-Version von „toorox foreSight“ für Proxmox würde ich sehr begrüßen und wäre auch gerne bereit, diese zu testen.

[Tom-HA]

Noch mal zur Erklärung…

tooroxForesight ist eine zusätzliche Option — SFML wird weiterhin vollständig entwickelt und unterstützt. Beide Systeme existieren parallel und bedienen unterschiedliche Bedürfnisse. Wer mit SFML zufrieden ist, muss nichts ändern → im Gegenteil SFML wird von den mehrern Millionen Parametern profitieren (in späteren Updates werden die Trainingsdaten in SFML einfließen.

tooroxForesight ist eine dedizierte, eigenständige Prognose-Engine, die als autarke Intelligenzschicht vollständig lokal innerhalb eurer Infrastruktur operiert. Während SFML als bewährte Basis erhalten bleibt, geht tooroxForesight einen anderen Weg — spezialisierter, containerisiert und tiefer in die Transformer-Technologie eingebettet und kann so auf die neusten Entwicklungen in der KI zurückgreifen. HA → restriktiv und in modernen technologien outdated mehrer Entwicklungsschritte im Hintertreffen (aus diesem Grund bekommt das HA DEV Team auch die Sprach-Tools von Ha nicht in den Griff… torrox ForeSight → neueste lokale Technologien.

1. Systemarchitektur & Deployment

Die Software ist als containerisierte Anwendung konzipiert. Datenaustausch erfolgt bidirektional über Home Assistant — tooroxForesight extrahiert Rohdaten, prozessiert sie und spielt die Ergebnisse als Sensorentitäten zurück → bietet auch eine eigene Website

Installationswege:

• Standalone Docker — macOS, Linux, Proxmox, VM
• Home Assistant Add-on — Nahtlose Integration direkt im HA-Ökosystem

2. Die KI-Engine: Transformer ohne GPU-Zwang

Im Kern arbeitet ein hochoptimierter 0.5B Parameter Transformer, der gezielt für Zeitreihenanalysen im Energiebereich entwickelt wurde — kein generatives LLM, keine GPU-Abhängigkeit. → Aber daraus ergeben sich auch HW-Anforderungen.

• CPU-Optimierung: Läuft auf Standard-Server-Hardware oder performanten NAS-Systemen
• On-Device Learning: Kontinuierliches, lokales Lernen — angepasst an Verschattung, PV-Ausrichtung, individuelles Verhalten. Keine Cloud, keine Datenweitergabe.

3. Training & Datengrundlage

tooroxForesight ist eine vollständige Eigenentwicklung „from scratch". Training auf einem massiv kuratierten Datensatz mit mehreren Millionen Sonnenstunden und historischen Wetterdaten — manuell aufbereitet, um Rauschen zu eliminieren und die Relevanz für Energieprognosen zu maximieren.

4. Vergleich: Generische lokale KI vs. tooroxForesight

Merkmal	Generische lokale KI (Ollama etc.)	tooroxForesight
Fokus	Text- & Sprachverarbeitung	Energie- & Wetterprognosen
Hardware	Hoher VRAM / GPU-Bedarf	CPU-optimiert
Lernkurve	Aufwendiges Prompt-Engineering	Out-of-the-box einsatzbereit
Datenschutz	Lokal	Lokal (vollständige Souveränität)

5. Typische Einsatzszenarien

tooroxForesight fügt sich in nahezu jede bestehende Infrastruktur ein — egal ob HA zentral oder peripher ist:

1

HA auf minimalistischer Hardware → Rechenarbeit ausgelagert

Pi, Green, Yellow o.ä. als HA-Host — tooroxForesight läuft daneben auf NAS, Linux-Server oder macOS. HA bleibt schlank, die KI-Last liegt auf der Hardware, die dafür gebaut ist.

2

Proxmox mit HA im Container → tooroxForesight als eigener Container

Saubere Trennung auf Containerebene — beide laufen auf derselben Hardware, aber vollständig isoliert. Ideal für bestehende Proxmox-Setups.

3

HA auf potenter Hardware → tooroxForesight als Add-on direkt in HA

Wer genug Rechenleistung auf dem HA-Host hat, bekommt die nahtloseste Integration — als App direkt im HA-Ökosystem, ohne zusätzliche Infrastruktur.

4

Vollständig ohne Home Assistant

tooroxForesight als Container auf beliebiger Hardware, direkte Anbindung der Solaranlage — kein HA notwendig. Für alle, die eine rein eigenständige Lösung ohne Smart-Home-Plattform wollen.

Fazit

tooroxForesight und SFML verfolgen zwei grundlegend unterschiedliche Ansätze. SFML ist tief in Home Assistant verwurzelt — es arbeitet innerhalb der HA-Umgebung, akzeptiert deren Restriktionen und holt das Maximum aus dem heraus, was HA ermöglicht. tooroxForesight geht einen anderen Weg: State-of-the-Art lokale KI-Entwicklung, verbunden mit Home Assistant — aber ohne HA als Host. Keine Kompromisse durch Plattformgrenzen, keine Abhängigkeit vom HA-Ökosystem.

In die Entwicklung sind direkt Eure Erfahrungen, gemeldeten Probleme und Wünsche eingeflossen. Das Ergebnis ist kein Ersatz und kein Richtungswechsel — sondern eine vollständig eigenständige, parallele Weiterentwicklung für alle, die mehr Power, echte Standalone-Fähigkeit und die neueste Transformer-Technologie wollen.

Vorteil dieser Architektur:

• Eine Codebasis, zwei Installations-Wege
• HA-User → den Comfort der HA-UI
• Linux-User → standalone arbeiten ohne HA
• Updates funktionieren in beiden Richtungen gleich

So ergeben sich 3 Möglichkeiten:

• SFML → reines HA
• toroox ForeSight HA App
• toorox ForeSight Standalone

[Kaysen899]

Wenn es als App kommt, kann man dann die DB nahtlos von der Integration übernehmen?

[Tom-HA]

Ein Add-On ist ein Container (!!) es ist eine eigene Docker-Schicht in HA das ist der Unteschied zwischen Integration und App (früher Add on) → ganz einfach gesprochen.
Ja natürlich bleibe ich meinem Motto treu:

1. Pricacy First keine Daten nach außen
2. Keine Tracker, keine verdeckten Telemetrie-Daten
3. Kompatibilität nach HA Richtlinien
4. Kompatibilität zwischen meinen Apps / Integrationen also auch Datenbanken
5. Strikter HA Workflow → soweit wie möglich vereinfacht

Also klares JA! .. dieses vorgehen schließt die Lücke aus von Useren bereits gesammelten Daten und / oder Import.. etwas das bei SFML zu Problemen geführt hat.. Du erinnerst Dich bestimmt lebhaft an Probleme

ABER es gibt einen sehr sehr wichtigen Unterschied: Hardware… Restrictionen!

[Kaysen899]

Natürlich war App gemeint und nicht Addon.

Zur HA App würde ich mitmachen und auch testen, musst halt mal die Spezifikationen erläutern.

Da ja bei mir kein Intel sondern ein Zen2 Ryzen 3700U vorhanden ist. (also auch etwas älter.)

[Tom-HA]

@Kaysen899

Ryzen 3700U

Überhaupt kein Problem! Mehr als ausreichend! Schwierig wird es nach aktuellem Stand nur bei ARM und den Ur-Alt Intel (JXXX, Celeron,…) und weniger als 4GB RAM.. es hat sich bei den Tests wieder gezeigt, dass selbst die kleinen AMD`s die Intels in der “i-Serie” locker in die Tasche stecken → wie ja auch schon bei SFML festgestellt…

Hinweis:
Ich habe CUDA und ROC direkt mit eingebaut.. wer also eine Grafikkarte in seinem Host hat profitiert direkt davon!

[Joachim-xo]

Und wer hatte die Idee?

@Joachim-xo

SFML als App (Add on)

[Tom-HA]

SFML wird keine App! Es bleibt eine Integrattion!
Toorox ForeSight ist archtektonisch etwas ganz anderes und im Gegenssatz zu SFML auch nicht überall Lauffähig. Es ist im Kern ein klasssischer Docker Container (lokale KI mit 0,5B Pram) für HA mit einem speziellen Wrapper!

Im Kern ist ForeSight ein klassischer Docker-Container, kompatibel mit allen Container-Systemen (Linux, Proxmox, Synology, Qnap, MacOsX,…)
Darin läuft eine eigene, trainierte künstliche Intelligenz mit 0,5 Milliarden Parametern. Diese KI kann paralllel durch einen speziellen (eingebauten) Wrapper in Home Assistant eingebunden werden als App.

Man kann sie von der Bauweise her mit Modellen wie Qwen, DeepSeek oder Phi vergleichen – nur dass sie komplett selbst entwickelt und trainiert wurde (noch wird) und sich ausschließlich auf Solar- und Energieprognosen spezialisiert hat.

Die KI läuft sowohl auf der CPU als auch auf der GPU (mit CUDA und ROCm-Unterstützung).

Der Geschwindigkeitsunterschied zwischen GPU und CPU ist dabei sehr deutlich (aktueller Entwicklungsstand):

• Auf einer GPU mit 8 GB VRAM dauert eine Trainingsrunde (Epoche) nur ca. 10 Sekunden.
• Auf einem Ryzen mit 12 Kernen + 32 GB RAM dauert dieselbe Runde ca. 144 Sekunden.

Dieser Wert wird sich aber noch stark verbessern. Durch „Early Stopping“ und gezielte Anpassung der Parameter wird die KI später auch auf älteren oder schwächeren Intel-Prozessoren mit nur 5–15 Sekunden pro Epoche laufen können. So wird das tägiche Training sich auf ca. 1 Minute reduzieren lassen. → das ist die größte Herausfordung. Ziel sind zwischen 20 Token auf kleinen Systemen und bis zu 400 Token auf großen Systemen.

Es lässt sich auf Grund der verschiedenen Archtiekturen nicht wirköoch vergleichen, aber ungefähr*:

SFML: etwa 1000 Parameter
Toroox ForeSight: 0,5 Milliarden Parameter (Wetter + Solardaten über einen Zeitraum von etwa 10 Jahren an 180 Standorten in DE als Basis)

Das sind völlig andere Leistungsklassen und Architekturen,..

*Nerds nun bitte nicht Erschlagen!

[Tom-HA]

NERD STUFF → Training Status // Erste Pre-Tests live Modell

Update zum Solar-Prognose-Modell (ZARA Pre-Training)
Epoch 4 von 15 läuft gerade – und es sieht richtig gut aus!

Aktueller Stand:

• Epoch 1: Val-Loss 0.150 !
• Epoch 2: Val-Loss 0.144 (-4%)
• Epoch 3: Val-Loss 0.141 (-2%)
• Epoch 4: neuer Tiefpunkt bei 0.117! (besser als das bisherige Best)

Der Loss schwankt aktuell zwischen 0.117 und 0.133, was bei Quantile/Pinball Loss und laufender Cosine Scheduler völlig normal ist. Der gleitende Durchschnitt zeigt weiter nach unten – das Modell lernt also noch.

Technisch läuft alles stabil:

• GPU-Auslastung ~73%
• 580 - 610 Watt Verbrauch (seit 3 / 6 Tagen) → Etwa 80 kWh das Training
• Batch 12.000 von 78.000 in Epoch 4
• Keine Abstürze

Ziel: Im Pre-Training stabil unter 0.12 zu kommen, bevor ich mit dem Fine-Tuning auf die DB von SFML starte.

Das fühlt sich nach einem soliden Schritt in Richtung brauchbarer lokaler Solar-Prognose an.

Pre-Test nach Epoch 3 d=256 aus dem Stand:

Ertrag: 10,48 kWh
Prognose SFML: 9,28
Prognose TFS: 11,17

Pre-Test nach Epoch 3 Wärmepumpe Verbrauch / Tag

IST: 6,8 kWh
Prognose Solar Forecast Energy AI V1 = 5 kWh
Prognose TFS: 7,2 kWh

Pre-Test Akkuladung nach Epoch 3 (10% - 100% um 20 Uhr)

IST 82%
Prognose SFML + STATS : 72%
Prognose TFS: 90%

Pre-Test Zeitpunkt MPPT Throttel erreicht

Ist: 14:32
Prognose SFML + Stats = 15:00 Uhr
Prognose TFS = 13:00 Uhr
Wichtig SFML und TSF geben die Stunde an nicht Uhrzeit!

Es zeichnet sich bereits jetzt ab, dass TFS aus der “Kalten” nur mit Recorder-Daten aus HA eine beeindruckende Treffergnauigkeit erreicht. Abschließende Test nach kompletten Training stehen noch aus.

Größe Modell + Container + Website + Konfigurtaionsmodule + Installer + Voll Trainiert … etwa 500MB (all in) Zuwachs nach einem Jahr ca + 80MB

[nobbilie]

Mit meinem Unraid und dem Ryzen 5 7430U 32GB RAM sollte das also auch laufen?

[Tom-HA]

@nobbilie

Ja, locker! - aber es wird noch etwas dauern bis zum ersten Release, das Training dauert ca. 6 Tage 24/7 und dann muss es verifiziert werden, und quantisiert… bei Problemen muss ich noch einmal Trainieren.. nichts davon ist aus dem " Regal" alles selbst gebaut / trainiert…

Status:

Verbesserungen pro Epoch:
Epoch 2: -4%
Epoch 3: -2%
Epoch 4: -1.5%
Epoch 5: -0.6%
Epoch 6: -0.4%
Epoch 7: 0% (war schlechter)
Epoch 8: -0.7%
Epoch 9: -0.08%

sieht so aus das das erste Plataue (wo sie nicht mehr “schlauer wird” ) erreicht ist - um es mal sehr einfach zu sagen