Würde mein i5 9500t/32GB Ram, HA Bare Metal, 25GB RAM frei, bei der HA-App-Variante und 3 Panelflächen noch mitspielen?
Hi,
ich schließe mich der Frage an und gehe noch etwas “tiefer” - Wenn ein HA auf dem min. Hardware Niveau ausgestattet ist (Intel i5 6. Gen z.B. i5 6500T) mit 8 GB Ram - ist das System dann für die KI Berechnung ausreichend nur entsprechend langsam oder ist die Kombination HA mit TFS KI kritisch bzw nicht lauffähig?
Grüße Thomas
Ja, aber mit Einschränkungen. Der Intel Core i5-9500T ist ein solider kleiner Arbeiter für kompakte Systeme - Vorteil ist er hat 6 Threads und zum Glück kein Hyper-Gedöns.. d.h er kann nicht so schnell überhitzen! TSF ist so gebaut das es via executer im Gegensatz zu HA selbst (HA kann nur einen Kern benutzen) alle Kerne nutzen kann.. Einschränkung: die Zeit für das FT (Fine-Traning) könnte etwas länger Dauern, vermutlich 15 Minuten + .. aber ich überlege gerade es fest auf 2 Uhr Nachts zu pinnen da sollte es nicht stören. Fatal wäre es nur zu dem Zeitpunkt einen HA-Backup Job zu starten
LG Zara
1 „Gefällt mir“
Ganz genau.. es läuft, aber wird Zeit brauchen.. abstürzen wird es nicht!
1 „Gefällt mir“
Das Backup-Thema sollte gut bedacht werden. Natürlich kann man die Zeiten schieben aber was ist wenn ich in einem halben Jahr wieder die Zeiten verschiebe aufgrund anderer Befindlichkeiten und habe FT-Zeit vergessen.
Vielleicht wäre eine individuelle einstellbare Zeit mit einem entsprechenden Backup-Hinweis ein guter Weg? Ich persönlich würde wahrscheinlich gegen 23uhr oder 04uhr FT starten, da bei mir 00uhr - 01uhr einige Automationen „zurücksetzen“ und 02uhr - 03uhr mein Backup-Zeitraum ist
1 „Gefällt mir“
Guter Punkt! Ich muss da drüber nachdenken, aber prinzipiell reden wir hier von 2 Verschiedenen Sachen.. bin noch in der Designentscheidung / Überlegung und für jedes Argument offen..
0:30 Triggert SFML nicht nur den Early Forecast sondern würde dann auch TFS triggern
45 Min vor Sonnenaufgang Triggert SFML die Morning Routine und den Finalen FC für den Tag.. TFS würde dort eingehängt werden.
23:30 SFML macht seinen EOD - Bleibt so
Nach Bedarf würde TFS (aktuell) um 2 Uhr das eigene Lernen (NICHT TRAINING!!) triggern - > wie oft das wäre kann ich aktuell nicht einschätzen. Vermutlich 1 -2 mal im Monat.
Spontan, warum das TFS Lernen nicht hier hinten ran hängen…
… ich schätze mal, in der Früh sind die meisten Systeme ruhig und es werden keine Updates / Wartungen / Arbeiten (alias reboot) durchgeführt. Anders als „typische Backup-Zeiten 22-04Uhr“ und Typische-Freizeit >16uhr.
Natürlich kann ich nur von meinem System sprechen aber ich denke Mal mit „arbeiten gehen“ oder „ausschlafen“ sollte das schon allgemein gut passen
Weil das Lernen nur SInn macht wenn keine Aktuellen Daten " reinkommen" .. daher muss es in einer “non-production” Zeitfenster sein
So wie ich es verstehe bezieht sich „TFS-Lernen“ nicht nur auf PV sondern auch auf Verbrauchsprognose? Folglich auch in „non-verbrauch“ Zeitfenster nur lernen, dass wäre bei Wärmepumpe in Winter-Nacht nicht ohne weiteres pauschal möglich.
Was passiert beim lernen wenn gleichzeitig aktuelle Daten rein kommen → verfälscht um ein paar Promille bis zum nächsten lernen?
PS: Ich möchte nichts in Frage stellen. Ich bin nur interessiert und versuche Beweggründe zu verstehen 
Wie ich eingangs erklärt habe, folgt das in mehreren Schritten.
- Solar Prognose a) leichte HA Version b) Docker Vollversion
- Energie + Solarprognose → Stand heute nur Docker (Single-Core Problematik)
- Full Stack = Docker
- Full Stack mit erweiterten Funkionen (Ende 2026)
Zu den Daten, wie groß die “Lücke ist” hängt maßgeblich von der HW-Leistung ab.Das sind wenige Millisekunden bis Sekunden. TFS hat eine eigene DB greift also nicht in die laufende HA DB ein, so entsteht kein Await und vor dem FT wird die DB via API abgefragt und es findet ein Backfill statt - Übrigend in jeder TFS Version!
UPDATE: Nachdem die TFS HA Version ja läuft und es nun um Feldversuche geht, gibt es Neugikeiten von der Docker-Version.. der Config-Flow ist fertig (zunächst nur für den Import der benötigen Daten aus HA)
Mir sind noch sehr gut die Worte von @dietmar1968 und @Joachim-xo aus den Entstehungstagen von SFML im Ohr
Das ist irgendwie eine BLACK-BOX.. daher habe ich von Anfang an darauf geachtet, dass man “mitgenommen” wird, was da pasiert..
3 Einfache Schritte:
- Zugangsdaten HA eingeben
- Anlagen Konfiguration und vorhandene Daten aus der SFML DB holen
- Training durchführen ( hier wird die KI auf die Anlage angepasst, dass muss nur bei der Ersteinrichtung gemacht werden und dauer je nach Hardware bis zu einer Stunde)
Man sieht auch direkt das die komplette Last vom Home Assistant weg ist und die Rechenleistung “ausgelagert” ist.. das beide Systeme unabhängig sind.
Zara
PS: Da es ein externer Docker-Container ist, muss ich nicht den Zirkus mit den vorgegeben Schritten in HA machen, sondern kann das alles im Background durch Skripte erledigen lassen.. deutlich komfortabler und nix mit Sensoren bauen, wilde Templates…
1 „Gefällt mir“
Soll ich Super-DAU das mal probieren? Mein kleiner Delli
(Intel i7 8750H - 16 GB RAM 6 Kerne 12 Threads 2,2 GHZ)
sollte das ja wohl locker wegrechnen.
Und meine Zugangsdaten finde ich wohl auch irgendwo 
Mein NAS steht auch schon bereit 
Super gern, aber gebt mir noch ein paar Tage um den Code zu testen, dass er sauber und ohne Fehler läuft.. ich melde mich sofort perönlich bei euch.. aktuell habe ich noch struggle mit der korrekten Wetterberechnungen die besteht im Gegensatz zu SFML zusätzlich aus Klima-Modellen der letzten 40 Jahre..
2 „Gefällt mir“
Ich könnte auch noch nen PI 5 anzubieten 
INFO: Proof of Concept und finale Architektur steht
Die “alten” Hasen die mich schon seit dem 1 und 2 Beta-Thread von SFML begleiten wissen, dass ich gern mal einen Zwischstand und Gründe für Designentscheidungen treffe und das der Thread auch eine Art Road-Map ist…
Hier müssen wir aber klar Unterscheiden in TFS HA und TFS DO
TFS HA = App für Home Assisistant die SFML voraussetz und sich via HACS installieren lässt out of the box → kein Setup notwendig install and forget
TFS DO = Standalone Docker Image Full Stack ohne Kompromisse und unabhägig von Home Assistant → Setup notwendig und HW-Leistung vorausgesetzt Multi-Core und Support für GPU.
Host kann Proxmox, Linux, MacOsX, NAS,.. sein
Nun zu Designentscheidungen und ihre Begründung(en)
TFS HA:
Setzt ein korrekt konfigurietes SFML voraus. Liest die Sensor Konfiguartion aus SFML und die in der Daten aus der SFML DB
Weitere Features:
- Multi Core via async_executer
- Support für Intel und AMD (AMD bevorzugt) ab 2016 und I-Serie
- Support für ARM 64Bit min 8GB RAM (Achtung dauert länger!)
- Dedezierte DB (SQL)
- Klima + Strahlung + Wetter für 18 Jahre
- Watchdog nativ
- Lokal und isolierter Container
- Max 30 Epochs mit 3 Early Stopping (Plateau Erkennung) im Fine Tuning
- Durchschnittliche Verbessunerung bei 500 Samples (SFML) 86%
- SMFL ist Master und blendet (lernt) startet bei 15% nach 2 Wochen ca. 65%
- Alle Sensoren und SFML DB bleiben funktioinal
- Eigene Dashboards, Automationen brechen nicht
- Bei deinstalltion oder Fehler von TFS HA Fallback zur normalen Logik
- Kernfunktionen von SFML, STATS, GPM, Weather bestehen und sind integriert keine breaking Chances
- Klein und kompakt Grundinstallation ca. 200MB (App)
TFS DO:
Braucht KEINE SFML installation, aber potente Hardware oder viel Zeit..
SFML vorhanden:
Wenn eine SFML Iinstallation vorhanden ist, wird die Sensor Konfiguration aus SFML ausgelesen und via Pull zu jedem in SFML hinterlegten Sensor die Historie geholt. Das Produziert riesige Datenmengen / Datenpunkte. Beim Fine-Tuning wird dann die Pre-trained KI gegen die lokalen Daten Trainiert. Je nach Leistung der HW und Historischen Daten kann das zwischen 30 Min und mehrern Stunden dauern. Der Fortschritt wird im Backend angezeigt. → Dieser Vorgnag muss nur einmal durchgeführt werden!
Ebenfalls werden die Klimadaten gegen den Standort trainiert (Klima ist nicht Wetter!!)
Kein SFML vorhanden:
Im Konfigurationsmenüe müssen von Hand die entsprechenden Sensoren eingetragen werden, sofern HA vorhanden! Prozess ist dann der Selbe
Keine Historischen Daten + keine SFML
Führt kein Fine-Tuning durch und samelt selbsständig Daten für 10 Tage und startet dann.
Weitere Features:
- MQTT Broker
- Multi Core
- CUDA / ROCm / MLX Support für Apple M2 +
- Backup
- Eigene DB
- Watchdog
- Lokal und isolierter Container
- Max 100 Epochs mit 5 Early Stopping (Plateau Erkennung) im Fine Tuning
- Durchschnittliche Verbessunerung bei 3 Monaten Historische Daten 83%
- Später komplettes Energie-Management
- Bilanzierung
- Klima + Wetter + Solar + Strahlung + Historische Daten für 40 Jahre
- Platformunabhängig
- Eigenes Backend Standart p10 p50 p90 Graph
- API für WR und Systeme kommt im Sommer - Vorerst Sensoren von HA
- Aktuelle Größe 1,5 GB (All in)
5 „Gefällt mir“
Ich habe eine kurze Frage dazu…..ich habe 5 Panelgruppen - das konnte man ja zu Beginn einstellen, jetzt erlaubst du das ja nicht mehr.
Ist das ein Problem, weil aktuell läuft bei mir alles wunderbar mit den 5 Gruppen - checkt TFS HA das oder bricht mir dann alles ein?
Mein Docker steht jetzt. Ich habe ihn auf meinem Proxmox Host als VM installiert. Ich bin also bereit zum testen 
Hast Du für die Installation ein Helper Script genommen?