Die Geschichte von SFML und STATS

Ich habe lange überlegt, wie wir uns gemeinsam an die Entwicklung und Geschichte hinter SFML erinnern können. - Es gab / gibt viele Vorschläge z.B. ein Treffen an einem Ort der für alle gut erreichbar ist.
Ich habe mir die “alten” Beitrage mal durchgelesen und musste Schmunzeln, wie aus einer Idee das heutige SFML wurde. - Ich hoffe Simon wird mir diesen Thread verzeihen und “gönnen” da ich gerne mal zusammenfassen möchte wie es dazu kam wo “wir” heute gemeinsam stehen. Da es so unglaublich viel ist.. habe ich mich für einen " Buch-Stil" entschieden..

Vorwort

Software verschwindet oft schneller, als sie entsteht. Neue Versionen ersetzen alte. Funktionen kommen hinzu, andere verschwinden wieder. Jahre später erinnert sich kaum noch jemand daran, warum eine bestimmte Entscheidung getroffen wurde oder welches Problem sie ursprünglich lösen sollte. Übrig bleiben Quellcode, Changelogs und Release Notes – aber selten die Geschichte dahinter.

Diese kleine Geschichte soll genau das bewahren und allen Danken im Forum die mitgewirkt haben oder noch mitwirken. Allen Voran natürlich auch Simon, der diesem Thema einen Platz gegeben hat.

Sie erzählt die Entstehung von Solar Forecast – einem Projekt, das mit einer einfachen Idee begann und sich Schritt für Schritt zu einem lokalen KI-Ökosystem entwickelte. Nicht geplant als großes Open-Source-Projekt. Nicht mit dem Ziel, eine möglichst komplexe Software zu entwickeln. Sondern mit dem Wunsch, ein Problem zu lösen, das im Alltag einer Photovoltaikanlage immer wieder auftauchte.

Was als persönliche Lösung begann, wurde im Laufe der Zeit zu weit mehr als einer Solarprognose. Es entstanden eine lokal arbeitende KI, eine Wetter-KI, eine eigene Datenbank, eine Analyseplattform, Transformer-Modelle, eine moderne Benutzeroberfläche und zahlreiche Systeme, die gemeinsam daran arbeiten, aus Daten belastbare Entscheidungen abzuleiten.

Doch diese Geschichte soll bewusst handelt nicht nur von Software, sondern auch von diesem Forum und den Nutzern!

Sie handelt von tausenden Stunden Entwicklung, von verworfenen Ideen, von Architekturentscheidungen, von Rückschlägen und von einer Community, die das Projekt von den ersten ZIP-Dateien bis zum heutigen Stand begleitet hat. Vor allem aber handelt sie von einer Überzeugung.
Der Überzeugung, dass moderne Technologie nicht bedeuten muss, Kontrolle abzugeben. Dass Daten dem Nutzer gehören. Dass künstliche Intelligenz nachvollziehbar sein darf.

Und dass gute Software nicht dadurch entsteht, möglichst viele Funktionen einzubauen, sondern dadurch, die richtigen Probleme zu lösen.

Sie ist die Erinnerung daran, wie aus einer Idee Schritt für Schritt ein Projekt wurde. Manche Entscheidungen entstanden aus Planung. Viele aus Problemen. Einige aus Zufällen. Fast alle jedoch entstanden im Austausch mit der Community.
Vielleicht werden in einigen Jahren andere Technologien an die Stelle von Solar Forecast treten. Vielleicht werden Prognosen dann selbstverständlich sein. Vielleicht werden lokale KI-Systeme alltäglich geworden sein.

Es soll zeigen, wie Ideen entstehen. Wie aus Beharrlichkeit Architektur wird. Und wie aus einer einfachen Frage ein Projekt wachsen kann, das weit über seinen ursprünglichen Zweck hinausgeht. Die Geschichte soll motivieren selber zu entwickeln, probieren und sich an anderen Projekten zu beteiligen.

**Wenn ihr möchtet das ich diese Geschichte hier nach Kapiteln erzähle.. bitte einfach einen Daumen hoch. ** ich würden dann ja nach Zeit immer wieder ein Kapitel hinzufügen
Wenn einer der Admins meint, das gehört hier nicht hin.. kein Problem bitte löschen!

10 „Gefällt mir“

Kapitel 1

Eine Prognose, der man nicht vertrauen konnte

Manchmal beginnen große Projekte nicht mit einer großen Idee. Sondern mit einem kleinen Ärgernis. Im Sommer 2025 stand ich – wie so viele andere Besitzer einer Photovoltaikanlage – jeden Morgen vor derselben Frage: Wie viel Energie wird meine Anlage heute erzeugen?

Eigentlich sollte diese Frage längst beantwortet sein. Es gab bereits verschiedene Solarprognosen für Home Assistant. Sie lieferten Werte, Diagramme und Sensoren. Auf den ersten Blick schien alles vorhanden zu sein.
Doch je intensiver ich sie im Alltag nutzte, desto deutlicher wurde ein grundlegendes Problem.
Die Prognosen waren rollierend. Sie passten sich im Laufe des Tages ständig an neue Wetterdaten an. Meteorologisch war das durchaus sinnvoll. Für die Planung des eigenen Energieverbrauchs war es jedoch ein erheblicher Nachteil.

Denn die wichtigste Entscheidung musste morgens getroffen werden. Sollte das Elektroauto heute geladen werden? Lohnt es sich, den Batteriespeicher bewusst leer laufen zu lassen? Wann sollte die Wärmepumpe arbeiten? Wie viel Energie würde tatsächlich zur Verfügung stehen?

Für all diese Entscheidungen brauchte ich keine Prognose, die sich mittags wieder änderte. Ich brauchte eine Prognose, der ich morgens vertrauen konnte. Aus genau diesem Gedanken entstand die erste Idee. Nicht für andere. Nicht als Open-Source-Projekt. Nicht einmal für Home Assistant. Sondern ausschließlich für meine eigene Anlage.

Damals begann ich auf einem Raspberry Pi mit der Entwicklung einer eigenen künstlichen Intelligenz. Sie sollte nicht irgendeine Solaranlage verstehen. Sie sollte meine Solaranlage verstehen.
Sie sollte aus ihren eigenen Erfahrungen lernen, Wetter und Ertrag miteinander in Beziehung setzen und mit jeder neuen Beobachtung besser werden.
Schon damals stand für mich fest, dass diese KI ausschließlich lokal arbeiten würde. Nicht, weil Cloud-Dienste grundsätzlich schlecht gewesen wären.- Sondern weil ich wollte, dass die Daten dort bleiben, wo sie entstehen.Beim Nutzer.

Ich wollte, dass jeder jederzeit nachvollziehen kann, welche Informationen gespeichert werden, wie sie verarbeitet werden und dass keine Daten an fremde Server übertragen werden. Datenschutz war für mich deshalb keine nachträgliche Funktion. Er war von Anfang an Teil der Architektur.
Der Raspberry Pi war der erste Beweis, dass diese Idee funktionieren konnte. Doch damit begann erst die eigentliche Herausforderung. Die KI lief. Aber sie lief nicht dort, wo sie später einmal eingesetzt werden sollte. Sie lief nicht in Home Assistant.

Damals wusste ich noch nicht, dass genau dieser Schritt die eigentliche Geschichte von Solar Forecast werden würde. Denn zwischen einer funktionierenden KI auf einem Raspberry Pi und einer stabilen Home-Assistant-Integration lagen Welten.
Nicht nur technisch. Sondern auch philosophisch. Ich hätte den einfachen Weg gehen können.

  • Eine Cloud.

  • Einen externen Server.

  • Eine API.

Alles Möglichkeiten, die viele andere Projekte bereits nutzten. Für mich kamen sie nie infrage.
Wenn Solar Forecast entstehen sollte, dann musste es vollständig lokal funktionieren. Nicht irgendwann, sondern von Anfang an.
Damals ahnte ich noch nicht, welche Konsequenzen diese Entscheidung haben würde. Sie würde praktisch jede Architekturentscheidung der kommenden Monate beeinflussen.
Und sie würde aus einem kleinen privaten Experiment Schritt für Schritt ein Projekt entstehen lassen, das sehr viel größer werden sollte, als ich es mir zu diesem Zeitpunkt vorstellen konnte.

10 „Gefällt mir“

Kapitel 2

Als “Das geht nicht” keine Antwort war und wie der Name entstand

Es gibt Sätze, die Hobby - Entwickler häufiger hören als andere.

“Das funktioniert nicht.”

“Das unterstützt Home Assistant nicht.”

“Dafür gibt es keine Bibliothek.”

“Das geht so nicht.”

Im Herbst 2025 hörte ich diese Sätze sehr oft.

Die erste Version meiner künstlichen Intelligenz lief bereits auf einem Raspberry Pi. Dort hatte ich alle Freiheiten. Ich konnte Bibliotheken installieren, Modelle testen und experimentieren.Home Assistant war eine völlig andere Welt.Die Plattform ist bewusst so aufgebaut, dass Integrationen stabil und ressourcenschonend arbeiten. Genau das macht Home Assistant so zuverlässig. Gleichzeitig bedeutete das aber auch, dass viele Bibliotheken, die für moderne Machine-Learning-Anwendungen selbstverständlich sind, dort schlicht nicht zur Verfügung standen.An diesem Punkt hätte ich den einfachen Weg gehen können.
Viele Projekte lösen dieses Problem, indem sie die eigentliche Intelligenz auf einen externen Server verlagern. Home Assistant liefert die Daten, die Berechnung erfolgt irgendwo in der Cloud und das Ergebnis kommt zurück.
Technisch wäre das deutlich einfacher gewesen. Für mich war diese Lösung jedoch nie eine Option. Nicht aus technischen Gründen. Sondern aus Überzeugung.

Wenn ich eine künstliche Intelligenz entwickle, dann sollte sie dort laufen, wo auch die Daten entstehen: Beim Nutzer.
Ich wollte nicht, dass jemand seine Anlagendaten erst an einen fremden Server schicken muss, um anschließend seine eigene Prognose zurückzubekommen.

Die Daten sollten den Rechner niemals verlassen. Damit war klar:
Wenn die benötigten Bibliotheken nicht existierten, musste ich einen anderen Weg finden. Mein erster Ansatz war deshalb kein Transformer und auch keine Attention-KI. Ich entschied mich bewusst für klassisches Machine Learning. So entstand auch der Name Solar Forecast Machine Learning > Solar Forecast ML oder kurz SFML.
Nicht, weil ich überzeugt war, dass dies die beste Lösung wäre. Sondern weil sie unter den technischen Rahmenbedingungen überhaupt umsetzbar war. Rückblickend war das eine Zwischenstation. Eigentlich wollte ich von Anfang an eine echte künstliche Intelligenz entwickeln. Scheiterte jedoch an Home Assistant und ich konnte kein Beispiel finden, von jemanden der es geschafft hat. Im Gegenteil, niemand hatte es bisher geschafft.
Doch manchmal muss man einen Umweg gehen, um sein eigentliches Ziel überhaupt erreichen zu können.
Viele Wochen arbeitete ich an unterschiedlichen Ansätzen. Immer wieder stieß ich auf dieselben Grenzen.
Immer wieder stellte sich die gleiche Frage:

Wie bringt man moderne KI auf eine Plattform, die dafür eigentlich nicht vorgesehen ist?

Im Home-Assistant-Developer-Forum bekam ich häufig dieselbe Antwort.
“Das geht nicht.” Für mich war das nie das Ende der Diskussion. Es bedeutete lediglich, dass dieser Weg nicht funktionieren würde. Also musste es einen anderen geben. Ich habe nie versucht, Home Assistant auszutricksen. Ich wollte die Regeln der Plattform verstehen und innerhalb dieser Regeln eine Lösung entwickeln. Das wurde zu einer Grundhaltung, die das gesamte Projekt prägen sollte. Nicht gegen Home Assistant. Sondern mit Home Assistant. Nicht möglichst spektakulär. Sondern möglichst sauber.

Diese Denkweise führte schließlich zu einer Erkenntnis, die später das gesamte Projekt verändern sollte. Vielleicht musste ich gar nicht versuchen, vorhandene Bibliotheken in Home Assistant zum Laufen zu bringen.

Vielleicht musste ich sie einfach selbst schreiben und die Funktion von Home Assistant besser verstehen, den Core verstehen…
Damals ahnte ich noch nicht, dass genau dieser Gedanke Wochen später dazu führen würde, dass aus einem klassischen Machine-Learning-Projekt Schritt für Schritt eine vollständig lokal arbeitende Transformer- und Attention-KI entstehen würde – geschrieben in reinem Python und ohne die üblichen ML-Frameworks. Doch bis dahin war es noch ein weiter Weg und zunächst wartete eine ganz andere Herausforderung. Wie schreibt man eine HA-Integration, wie verteilt man sie, wie testet man im Vorfeld, was ist der Unterschied zwischen App und Integration, was sind die Regeln seitens Home Assistant, wie mache ich sie auf Bare Metal, schwachen Systemen, Proxmox, ARM,.. lauffähig.

Ich musste also viel lesen und lernen meine erste Home-Assistant-Integration zu schreiben das Problem dabei war: Ich hatte so etwas noch nie gemacht.

Die erste wichtige Entscheidung war " Integration" oder " App (add-on)".. doch diese Frage klärte sich sehr schnell: Es muß eine Integration sein, wenn ich die Home Assistant eigenen Schutzmechanismen, maximale Transparenz, 100% Kompatibilität möchte. Eine App ist zwar deutlich einfacher und schnell gemacht, aber sie umgeht alle Sicherheitsfeatures von Home Assistant und der Nutzer kann den eigentlichen Code nicht sehen und hat keine Ahnung was er sich da auf das System holt.

Daher war die Entscheidung gefallen: Die Königsklasse und maximale Sicherheit für Nutzer : Integration

Diese Entscheidung sollte noch ungeahnte Schwierigkeiten erzeugen. Aus dem Gedanken einen Fork zu machen - einfach das funktionierende System vom PI auf HA zu bringen - wurde eine komplette Neuentwicklung.

Tipp: Wenn Du mal selber entwickeln möchtest, baue lieber eine Integration keine App - ja es ist schwerer, ja es restriktiver, ja man muss tiefer einsteigen,.. aber es ist sicherer und 100% Supervisor-Überwacht. Selbst wenn Du einen Fehler machst, riskierst Du nicht die Systeme / Persönilchkeitsrechte / kannst Datenschutz einhalten und belegen / .. der Nutzer.

10 „Gefällt mir“

Kapitel 3

Die KI, die es eigentlich nicht geben durfte

Es gibt Entscheidungen, die ein Projekt verändern und es gibt Entscheidungen, die seine gesamte Zukunft bestimmen.
Eine davon traf ich bereits ganz am Anfang, als ich eine KI für den Raspberry PI baute.
Sie sollte zwingend lokal auf einem Raspberry Pi laufen, lokal (automatisch) lernen und keine Daten versenden. - Das hat sehr gut funktioniert…Eigentlich hätte ich zufrieden sein können.

Doch ich hatte ein anderes Ziel. Ich wollte diese KI nach Home Assistant bringen, als echte Home-Assistant-Integration.

Erst in diesem Moment wurde mir klar, wie schwierig es werden wird…Home Assistant ist keine Plattform für Machine Learning. Es ist eine Plattform für Hausautomatisierung.
Das ist ein entscheidender Unterschied, den ich als alter Linux-Coder (Fedora) fundamental unterschätzte.
Viele Bibliotheken, die außerhalb von Home Assistant selbstverständlich sind, existieren dort nicht oder können nicht einfach eingebunden werden.
Je intensiver ich mich mit der Plattform beschäftigte, desto häufiger dachte " ohje" und mit jeden den ich um Rat fragte, jedes Forum das ich durchsuchte, jeder DEV sagte immer das selbe:

“Das geht nicht.”

Besonders im internationalen Home-Assistant-Developer-Forum. Aus technischer Sicht war diese Einschätzung nachvollziehbar. Mit den bekannten Werkzeugen ließ sich das tatsächlich nicht umsetzen.
Ich wollte jedoch niemals eine Integration entwickeln, bei dem eine Solaranlage erst ihre Daten an einen fremden Server schicken muss, um anschließend ihre eigene Prognose zurückzubekommen, oder wo große LLM ( ChatGpt, Claude, Grok,..) eingebunden werden müssen. Mir war klar "Keine Daten verlassen das Systems des Nutzer, keine Daten werden dezentral abgelegt, keine Zusatzkosten,..)

Diese Überzeugung machte den Weg erheblich schwieriger. Denn plötzlich gab es keine fertigen Lösungen mehr. Ich musste anfangen, selbst nach Alternativen zu suchen. Es gab niemanden, zu dem Zeitpunkt, der eine lokale KI auf einem Home Assistant zum Laufen bekommen. Ebenfalls gab es keine einzige statische Solarprognose oder Prognose die wirkliche lokale Wetterdaten einbezieht und sie in einen Kontext mit der Anlage selbst setzt und daraus lernt.

Manchmal (sehr oft) führte eine Idee in eine Sackgasse. Dann begann die Suche von vorn. Nicht mit der Frage:

“Warum funktioniert das nicht?”

Sondern mit einer anderen.

“Wie könnte es trotzdem funktionieren?”

Immer wenn Home Assistant eine Grenze setzte, stellte sich dieselbe Frage:
Muss ich diese Grenze akzeptieren?

Oder muss ich nur einen besseren Weg finden?

Damals wusste ich noch nicht, dass genau diese Suche Monate später dazu führen würde, eine vollständige Transformer- und Attention-KI in reinem Python zu entwickeln – ohne TensorFlow, ohne PyTorch und ohne die Frameworks, die normalerweise als Voraussetzung gelten.
Rückblickend glaube ich, dass genau hier die eigentliche Identität von Solar Forecast entstanden ist.

Und genau deshalb entstand Schritt für Schritt eine Architektur, die am Ende sehr viel eigenständiger wurde, als ich sie mir am Anfang jemals vorgestellt hatte. Dazu später mehr..

6 „Gefällt mir“

Kapitel 4

Aus einem Nutzer wurden viele - Simons Beitrag

Rückblickend ist es fast schwer vorstellbar, wie klein alles begann.

  • Es gab kein GitHub.

  • Kein HACS.

  • Keine Releases.

  • Keine Installationsanleitung.

  • Keine Roadmap.

Viel wichtiger war aber " Gibt es überhaupt Leute, die sowas gebrauchen können - die bereit sind neues auszuprobieren / testen - oder lass ich es einfach und nutze es für mich allein mit meinem PI"

Also durchsuchte ich Foren zum Thema Home Assistant und fand schnell heraus, dass das Thema größer ist als ich anfangs dachte. Für mich war klar, wenn ein Forum dann Simon42 (ich kannte ihn bis dato nicht). Der Grund war einfach, der Umgangston im Forum war freundlich und fast schon freundschaftlich. Das hat mir extrem gut gefallen!
Also eröffnete ich nach der Anmeldung direkt einen Thread, in dem ich fragte ob jemand Interesse hat, das ich erkläre wir man eine lokale KI auf einem PI einrichtet die eine Solarprognose erstellt. - Das Feedback hat mich schlicht überrannt.. damit war klar " Hier bin ich richtig, hier sind Leute die Lust haben zu basteln und Neues auszuprobieren" - Also der Startschuss war gefallen " Das Teil muss auf Home Assistant" - Ich eröffnete einen Beta-Thread… Die ersten Versionen verschickte ich als ZIP-Dateien. Das war es alles andere als komfortabel.

Jede neue Version bedeutete, Dateien von Hand zu kopieren, Home Assistant neu zu starten, Konfigurationen anzupassen und im Zweifel wieder alles rückgängig zu machen. Manchmal mehrfach am selben Tag. Heute noch bin ich den Menschen dafür unglaublich dankbar - dass sie an meine Vision glaubten und mir ihr Feedback gaben. DANKE!!!

Sie testeten keine fertige Software, -sie vertrauten einer Idee.Damals wusste niemand, wohin sich das Projekt entwickeln würde. Am wenigsten ich selbst.

Ich hatte bis zu diesem Zeitpunkt weder einen GitHub-Account noch jemals zuvor eine Home-Assistant-Integration veröffentlicht. Eigentlich war ich nur jemand, der für seine eigene Solaranlage eine bessere Lösung bauen wollte.

Plötzlich installierten fremde Menschen meinen Code, das war ein merkwürdiges Gefühl. Nicht, weil ich Angst hatte, die Prognose könnte ungenau sein, dafür war es schließlich eine Beta.

Meine größte Sorge war eine ganz andere.

Was passiert, wenn ich das Home-Assistant-System eines Nutzers beschädige? Dieser Gedanke begleitete mich von Anfang an. Deshalb testete ich jede Version zunächst auf meinen eigenen Systemen.
Nicht oberflächlich, sondern so gründlich, wie ich es irgendwie konnte.

  • Ich arbeitete mit Mock-Daten.

  • Ich ließ statische Codeanalysen laufen.

  • Ich prüfte Interpreter.

  • Ich führte Penetrationstests durch.

  • Ich simulierte ungewöhnliche Situationen.

Und trotzdem wusste ich: Mein eigenes Zuhause ist niemals die Realität.

Erst wenn andere Menschen die Software benutzen, beginnt das eigentliche Lernen. Soviel verschiedene Systeme ( Proxmox, VM, BareMetal, ARM,..) und noch viel mehr verschiedene Wechselrichter und Akkusysteme. Dabei lernte nicht nur die künstliche Intelligenz. Ich lernte ebenfalls.
Plötzlich tauchten Wechselrichter auf, die ich nie gesehen hatte. Anlagenkonfigurationen, auf die ich niemals gekommen wäre. Sensoren mit völlig anderen Eigenschaften. Hardware, die sich ganz anders verhielt als meine eigene.
Jeder Fehlerbericht war deshalb viel mehr als eine Fehlermeldung.
Er war eine neue Perspektive.
Viele Funktionen, die heute selbstverständlich (in SFML) erscheinen, entstanden genau in dieser Zeit. Nicht, weil ich sie geplant hatte.
Jeder einzelne " alter Hase" wertvolles Feedback gab.
Je mehr Nutzer hinzukamen, desto häufiger stellte ich fest, dass meine eigene Anlage nur eine von unzähligen Möglichkeiten war. Eine Lösung, die bei mir perfekt funktionierte, konnte bei jemand anderem völlig ungeeignet sein.

Das zwang mich dazu, Software anders zu denken, nicht mehr für einen einzelnen Anwendungsfall, sondern für eine Gemeinschaft unterschiedlichster Anlagen.

Ich begann deshalb, regelmäßig Microsoft-Teams-Sitzungen anzubieten. Eigentlich waren sie als einfache Fragerunden gedacht. Rückblickend wurden sie zu etwas viel Wichtigerem. Sie wurden zum Ort, an dem Solar Forecast gemeinsam weiterentwickelt wurde. Dort ging es selten nur um Fehler.
Viel häufiger ging es um Ideen.

  • Warum verhält sich die KI so?

  • Könnte man Wetter anders bewerten?

  • Warum lernt das System an dieser Stelle nicht?

  • Braucht man diesen Sensor wirklich?

Oft entstanden aus solchen Gesprächen neue Funktionen. Manchmal verschwand eine Idee auch wieder, weil sie nicht zum Gesamtkonzept passte.
Ich habe sehr früh gelernt, dass gute Software nicht dadurch entsteht, jeden Wunsch sofort umzusetzen, man muss zuhören -sehr genau sogar.
Danach beginnt die eigentliche Arbeit. Jede neue Idee stellte dieselbe Frage:

Passt sie wirklich zu Solar Forecast?
Oder löst sie nur das Problem eines einzelnen Nutzers? Nicht jede gute Idee gehört automatisch in ein Projekt.

Diese Erkenntnis hat Solar Forecast wahrscheinlich genauso geprägt wie jede technische Innovation. Bis heute versuche ich deshalb, jede neue Funktion gegen dieselbe Frage zu prüfen.

Macht sie das Gesamtsystem besser?

Oder macht sie es lediglich größer? Diese Unterscheidung ist schwieriger, als sie zunächst klingt. Denn mit jeder neuen Funktion wächst auch die Verantwortung. Gerade weil immer mehr Menschen die Software produktiv einsetzen.
Vielleicht war genau das der Moment, in dem aus meinem Projekt langsam ein gemeinsames Projekt wurde.

Nicht, weil plötzlich viele Menschen den Code kannten. Sondern weil immer mehr Menschen ihre Erfahrungen, ihre Ideen und ihre Zeit einbrachten. Daher spreche ich auch von einem Community-Projekt - nicht meinem eigenen!

Der Thread platze aus allen Nähten und wurde so unübersichtlich, dass wir (keine feste Gruppe, sondern wer Lust und Zeit hatte an den “Teams-Meetings” teilzunehmen) gemeinsam überlegten ob man das irgendwie besser strukturieren könnten. Da neue User schier erschlagen wurden durch die Fülle an Informationen.
Das führte dazu, dass ich mit Simon in Kontakt kam und wir uns via Teams trafen und er völlig selbstlos, als wäre es das normalste der Welt, anbot eine eigene Spalte in seinem Forum zu machen. Harry unterstütze von der ersten Sekunde ebenfalls und so entstand die Unterkategorien - so wie sie heute im Forum zu finden sind.

Ich wiederhole mich, aber ich möchte mich ausdrücklich bei Simon, Harry und all den Usern der ersten Stunde bedanken und ich glaube das nicht jedem klar ist, wieviel Zeit und Liebe ihr / wir in diese Projekt gesteckt haben.

7 „Gefällt mir“

Kapitel 5

Der Traum von der echten KI - Manchmal braucht eine Idee Zeit und Geduld-

Als Solar Forecast entstand, arbeitete die erste Version bereits mit Machine Learning. Für viele Nutzer war das bereits beeindruckend. Die Prognosen wurden besser, das System lernte. Es passte sich an.
Von außen betrachtet hätte man sagen können:

“Die KI funktioniert.”

Ich selbst sah das anders. Eigentlich war das nie die KI, die ich bauen wollte.
Das klassische Machine Learning war ein Kompromiss -ein notwendiger Kompromiss. Nicht mehr und nicht weniger.
Die eigentliche Vision war von Anfang an eine andere gewesen. Ich wollte eine moderne künstliche Intelligenz.
Ein System, das Zusammenhänge erkennt, Muster versteht und nicht nur Gewichte optimiert. Ein System, das mit den Möglichkeiten aktueller KI arbeitet.
Damals erschien das nahezu unmöglich. Nicht weil die Mathematik fehlte, nicht weil die Hardware fehlte.
Sondern weil Home Assistant schlicht nicht für solche Anwendungen entwickelt worden war.
Viele Entwickler akzeptierten diese Grenze. Ich konnte sie akzeptieren.
Aber ich wollte sie verstehen!
Je tiefer ich mich mit modernen KI-Architekturen beschäftigte, desto klarer wurde mir, dass das eigentliche Problem gar nicht die Mathematik war.
Das Problem waren die Werkzeuge.
Fast jeder moderne KI-Stack setzt auf große Frameworks.

  • TensorFlow.

  • PyTorch.

  • JAX.

Alle bringen Millionen Zeilen Code, riesige Abhängigkeiten und hohe Anforderungen an Speicher und Laufzeit mit. Für Home Assistant war das keine realistische Grundlage. Insbesondere dann nicht, wenn man sich fest vorgenommen hat, nur Dinge zu benutzen, die Home Assistant nativ bereitstellt und auch intern selber pflegt. - Keine Experimente, keine Hudelei, keine Dinge die die Architektur von Home Assistant gefährden können.
Also stellte sich wieder dieselbe Frage wie so oft zuvor.

Was passiert, wenn ich die Werkzeuge nicht benutzen kann?

Die Antwort war zunächst ernüchternd: Dann schreibe ich sie eben selbst.
Rückblickend klingt dieser Satz fast naiv, damals war er einfach logisch.
Wenn die Architektur eines Projektes einen bestimmten Weg ausschließt, bleibt immer noch die Möglichkeit, einen neuen Weg zu entwickeln.

Also begann ich, Transformer zu verstehen / lernen, nicht als Anwender sondern als Entwickler. Ich wollte nicht einfach Bibliotheken benutzen.
Ich wollte verstehen, warum sie funktionieren.

  • Was passiert in einer Attention?
  • Warum lernt ein Transformer?
  • Wie sind sie gecoded
  • Welche mathematischen Schritte laufen tatsächlich ab?

Erst als ich diese Fragen beantworten konnte, begann ich damit, eigene Implementierungen zu schreiben.
Nicht tausende Funktionen, oder ein komplettes Framework, sondern genau die Bausteine, die Solar Forecast wirklich benötigte. - Mehr nicht!

Das war gleichzeitig die größte Freiheit und die größte Herausforderung, da ich keine KI zur Programmierung einsetzen wollte, alles von Hand und zu Fuß entstehen sollte. Die einzige Programiersprache die ich beherrsche ist Python, also hieß es lernen, lernen, lernen, und noch mal lernen wir eine KI im Kern funktioniert um es in Pure-Phyton selber zu bauen.

Wochenlang entstand Stück für Stück eine eigene Transformer-Architektur, leicht genug, um auf einem Raspberry Pi zu laufen, effizient genug, um Home Assistant nicht auszubremsen, flexibel genug, um später auch unter Proxmox, auf virtuellen Maschinen oder Bare Metal eingesetzt werden zu können.

Irgendwann kam der Moment, an dem ich den ersten vollständigen Trainingslauf startete. SFML trägt noch heute den Grundgedanken “ML = Machine Learning” im Namen, aber dem ist sie entwachsen. Es ist ein eigener KI-Stack speziell für Home Assistant und Docker, leichtgewichtig und unglaublich effizient. - Aber es ist ein Attention-Model wie die frühen ChatGpt und Claude Architekturen. - Wieder ein Kompromiss der Home Assistant geschuldet ist.
Damit war ich nicht zufrieden also zerlegte ich die “einzelne KI” in hochspezialisierte einzelne KI`s. Jede einzelne hat eine spezielle Aufgabe und faste sie zusammen zum Hubble KI-Stack.

Dann aber passiert etwas, dass ich nicht kommen gesehen hatte: Home Assistant wechselte die Python-Version. Ich war frustriert und ziemlich am Ende um ehrlich zu sein. - Die Community hat mich aufgefangen und motiviert weiter zu machen. Also schrieb ich alles passend um und sagte mir " Jetzt erst Recht" die Grenze ist noch nicht erreicht. So entstand Toorox Foresight für Home Assistant - der erste echte und vollständige 4 Head Transformer für Home Assistant. ich Trainierte mein eigenes Modell mit 18 Jahren Wetterdaten in 5 Minuten Schritten für 189 Standorte in DE und AT. dazu noch 14 Jahre Klimadaten für DE, AT, CH.. insgesamt 7 Tage hat das Training auf einem Hochleistungsrechner gedauert - die Stromrechnung war astronomisch!
Ich schaffte es einen echten Transformer in Python zu schreiben, mit insgesamt 22,6 Mio Parametern und nannte ihn TFS-HA. Der eigentlich geniale Clou ist: Nach der Installation trainiert er selbstständig - d.h. anhand der Geolocation bereinigt er sein wissen und wird immer schlauer.. das ist etwas das nicht einmal ChatGpt und Co können (!!!).

Für viele Nutzer war TFS einfach eine neue Komponente. Für mich bedeutete es etwas anderes -Es war die Rückkehr zur ursprünglichen Idee.Die Idee, mit der alles begonnen hatte - damals auf einem Raspberry Pi im Oktober 2025.
Als eine Vision, die zunächst unmöglich schien.
Heute arbeitet TFS HA mit über 22 Millionen Parametern vollständig lokal.

  • Ohne Cloud.
  • Ohne externe Dienste.
  • Ohne die Frameworks, die dafür ursprünglich vorgesehen waren.
  • Trainiert sich selber
  • Wird immer besser
  • Ist kaltstartfähig
  • das Modell ist super schlank und nur 88MB groß (quantifiziert)

Rückblickend werde ich manchmal gefragt, ob ich “damals” wusste, dass das funktionieren würde. Die ehrliche Antwort lautet:

Nein.

Man kann also mit stolzer Brust sagen: Hier im Forum wurde etwas geschaffen, das einzigartig und wegweisend in der Home Assistant Welt ist und so nirgends gibt. Das ist der Verdienst aller die ihre Zeit investiert haben um zu Testen, nicht aufgaben und an mich und meine Vision glauben.

10 „Gefällt mir“