1. Der Moment

Es gibt diesen einen Gedanken, der mich seit Wochen nicht loslässt: Ein Smart Home, das nicht mit einem KI-Agenten reden kann, ist nicht mehr zeitgemäß.

Nicht in zwei Jahren. JETZT! Spätestens wenn das den Massenmarkt erreicht, will niemand mehr in einer Konfigurationssoftware herumklicken, um eine Logik zu ändern. Man sagt dem System einfach, was man will — Status abfragen, schalten, und vor allem: die Konfiguration direkt ändern. Bei einem halben Dutzend anderer Dienste mache ich genau das längst, und es funktioniert perfekt.

Und dann schaue ich auf meine Loxone-Installation. Über die Jahre gewachsen, ~100 Seiten Config, Abertausende ineinandergreifende Bausteine. Und mir wird klar: So geht es nicht weiter. Also fange ich an, das Ding umzubauen — von Grund auf neu zu denken.

Das hier ist Folge 1 einer Reihe, in der ich euch bei diesem Umbau mitnehme. Ehrlich, mit allen Zweifeln, allem Respekt vor dem, was funktioniert — und allem, was mich an die Wand treibt.

Und ja, mir ist völlig klar, dass das ein radikaler Schritt ist. Aber ich sehe für die Zukunft schlicht keine andere Möglichkeit, als einen LLM-Agenten ins Zentrum zu stellen, wenn ich endlich das Smart Home haben will, das mir seit Jahren vorschwebt.

Ich habe über die Jahre unzählige Sensoren und Aktoren verbaut, die ein wahnsinniges Potenzial haben — aber genau dieses Potenzial lässt sich nicht heben, weil die Software es nicht hergibt. Und ich als Anwender kann nicht rund um die Uhr in der Konfiguration sitzen und alles permanent nachjustieren und perfektionieren. Das geht einfach nicht.

Ich habe in den letzten Jahren hunderte, wenn nicht tausende Stunden in eigene Regeln gesteckt — Regeln, die ich heute mit einem aktuellen Sprachmodell in wenigen Minuten produktiv bekomme. Genau das ist der Knackpunkt.

Denn die Modelle sind in den letzten Monaten exponentiell besser geworden. Plötzlich sind Dinge möglich, die vor einem Jahr noch undenkbar waren. Und das ist der eigentliche Grund, warum ich genau jetzt loslege — und nicht in zwei Jahren.

Das Lustige daran: Ein bisschen geahnt habe ich das schon. Vor gut einem Jahr saß ich bei Loxone im „Let’s Automate“-Podcast und wurde gefragt, wie ein Smart Home der Zukunft aussehen wird. Meine Antwort damals, sinngemäß:

„KI-basierte Entscheidungen stecken heute noch in den Kinderschuhen. Wenn man das wirklich vernünftig aufzieht, muss man größer und gewerkeübergreifend denken — am Ende läuft es auf eine Art Agentic AI hinaus, die die Sensorwerte des Hauses verarbeitet und im besten Fall selbstständig entscheidet, was zu tun ist. Man sagt einfach: ‚Hey, kümmer dich drum‘ — und wenn etwas nicht passt, sagt man der KI, dass es Mist war, und sie lernt dazu.“

↳ Gesagt habe ich das vor gut einem Jahr im „Let’s Automate“-Podcast von Loxone — direkt zur Stelle ab Minute 10:28.

Sie sehen gerade einen Platzhalterinhalt von Standard. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf den Button unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Inhalt entsperren Erforderlichen Service akzeptieren und Inhalte entsperren

Weitere Informationen

Was mir damals fehlte, war das Wie. Und ich hätte niemals damit gerechnet, dass es so schnell geht — ich dachte, bis dahin vergehen noch Jahre. Stattdessen, um es mit meinen eigenen Worten aus demselben Podcast zu sagen: ein exponentielles Wachstum, bei dem man vor zwei, drei Jahren noch gedacht hätte, das dauert ein Jahrzehnt — und jetzt sind wir schon da.

Heute weiß ich langsam, aber stetig, wie dieses Wie aussieht. Und genau deshalb baue ich es jetzt.

2. Worum es in dieser Reihe geht

Kurz gesagt: Ich baue mein Smart Home von einem geschlossenen System auf ein offenes, KI-getriebenes Brain um. Loxone bleibt — aber nicht mehr als Chef, sondern als ausführende I/O-Schicht.

Diese erste Folge ist das Manifest: das Warum, die Grundhaltung, die Leitplanken. Damit ihr wisst, worauf ihr euch einlasst, hier schon mal die grobe Landkarte der nächsten Folgen — jede knöpft sich ein Unterthema im Detail vor, immer mit dem geplanten Ansatz und dem ehrlichen aktuellen Umsetzungsstand:

• Loxone als reine I/O-Hülle — was bleibt am Bus, was rauswandert, und wie das Brain die Hardware überhaupt anspricht.
• Das Integrations-Nadelöhr — wie jedes Gerät (vom Tesla bis zum Saugroboter) künftig nativ andockt, statt durch Loxone gequetscht zu werden.
• Ausfallsicherheit — was passiert, wenn das Brain abstürzt, der Strom weg ist oder das Sprachmodell gerade trödelt.
• Der Tech-Stack — die deterministische Steuer-Engine, die LLM-Schicht obendrauf, und warum diese Trennung das ganze Fundament ist.
• Konfiguration per Sprache — der eigentliche Endgegner: dem Haus sagen, was es tun soll, statt es zu klicken.
• Eigene App mit Kachel-UI — weil die schönste Logik nichts bringt, wenn die Bedienung kacke ist.

Es wird also kein Hochglanz-„Schaut mal, was ich Tolles gebaut habe“. Es wird ein Logbuch — inklusive der Sackgassen.

3. Wie es mit Loxone ist — das Gute und der Schmerz

Erstmal das Gute, weil ich Loxone wirklich viel verdanke: In den Modulen steckt enorm viel Wissen und Alltagstauglichkeit. Die Lichtsteuerung mit den Lichtstimmungen finde ich nach wie vor richtig geil gelöst — da steckt jahrelange Erfahrung drin, die man als Selbstbauer erstmal nachbauen können muss. Die Live-View — ich starte die Ansicht und sehe die komplette Signalkette, wie ein Sensorwert durch die Bausteine läuft und was hinten rauskommt — diese optische Transparenz habe ich jahrelang geliebt.

Und es gibt noch eine Loxone-Eigenschaft, die ich erst richtig zu schätzen gelernt habe, als ich angefangen habe, über Alternativen nachzudenken: Es läuft lokal und es läuft deterministisch. Der Miniserver rechnet seine Logik im Haus, in einem festen Takt, ohne Cloud, ohne „warte mal kurz, der Server denkt nach“. Ein Schalter drückt, das Licht geht an. Punkt. Diese Verlässlichkeit ist kein Detail — sie ist genau das, was ich beim Umbau auf keinen Fall verlieren darf. Merkt euch den Gedanken, der kommt in Teil 4 mit voller Wucht zurück.

Aber. Der Schmerz ist über die Jahre größer geworden als der Komfort — und er ist erstaunlich konkret:

• Jede Mini-Änderung kostet einen Reboot. Loxone Config ist keine Live-Umgebung, in der man mal eben einen Wert ändert. Man baut sein Programm im Editor zusammen, lädt es in den Miniserver — und der startet sein Steuerprogramm dafür neu. Bei meiner überladenen Config sind das bis zu 30 Sekunden, in denen schlicht nichts geht. Für jeden kleinen Tweak. Wer schon mal „nur kurz“ einen Schwellenwert anpassen wollte und dann eine halbe Minute im dunklen Flur stand, weiß, was ich meine.
• Die Config kennt keine Wiederverwendung. Es gibt keine sauberen Funktionen, keine Namensräume, kein „dieses Muster einmal definieren und zehnmal benutzen“. Man verdrahtet Bausteine visuell — und bei jeder neuen Stelle verdrahtet man sie wieder. Bei mir stehen Regeln doppelt und dreifach drin, weil Gruppieren und Kapseln einfach nicht vorgesehen ist. Genau die optische Transparenz, die ich mal geliebt habe, ist dadurch zum Stolperstein geworden: Bei Abertausenden Bausteinen habe ich selbst keinen Überblick mehr, was wo passiert.
• Loxone ist das Integrations-Nadelöhr. Das ist der Punkt, der mich am meisten nervt. Jedes moderne Gerät — die Teslas, die Dreame-Saugroboter, zig WLED-Controller, der Mähroboter — spricht eine eigene, oft richtig fähige Schnittstelle. Aber um es in Loxone zu holen, muss ich es durch Virtuelle Ein- und Ausgänge quetschen: HTTP-Requests zusammenbasteln, UDP-Strings parsen, irgendwas pollen, Werte von Hand auseinandernehmen. Und am Ende sehe ich dann genau die zwei, drei Basis-Werte, für die ich eine Stunde gebastelt habe — während die Geräte nativ ein Vielfaches könnten. Ein geschlossenes System gibt eben das Tempo vor, und das Tempo ist nicht das des Marktes.
• Single Point of Failure. Fällt der Miniserver aus, geht gar nichts mehr — kein Licht, keine Beschattung, keine Heizungslogik. Bei einem zentralen Gehirn ist das systembedingt. Bei einem selbstgebauten muss ich mir genau darüber von Tag eins an Gedanken machen (dazu die eigene Folge zur Ausfallsicherheit).

Das ist ausdrücklich kein „Loxone ist schlecht“. Loxone macht das, wofür es gebaut wurde, verdammt solide. Das hier ist: Ich bin aus diesem System herausgewachsen — und das, was ich jetzt will, war in seinem Bauplan nie vorgesehen.

4. Der neue Ansatz — Loxone wird zur Hülle, das Hirn wird meins

Hier ist die Richtung, und sie ist bewusst ambitioniert: Loxone wird steuerungslogisch zur reinen I/O-Hülle. Die Sensoren, Aktoren und Extensions bleiben am Bus — die ganze physische Ebene, in die viel Geld und Verkabelung geflossen ist, fasse ich nicht an. Was rauswandert, ist die Logik: Szenen, Lichtstimmungen, Verknüpfungen, Automatiken. Die ziehen um in ein eigenes, deterministisches Brain, das ich selbst kontrolliere.

Die zentrale Architektur-Entscheidung: zwei Schichten, klar getrennt

Wenn ihr aus diesem ganzen Artikel nur eine Sache mitnehmt, dann diese. Das Brain besteht aus zwei strikt getrennten Schichten:

1. Eine deterministische Steuer-Engine. Sie führt die Logik aus — schnell, lokal, in einem festen Takt, ohne nachzudenken. Das ist der Teil, der einen Lichtschalter in Millisekunden bedient. Diese Schicht ist langweilig, und das ist ein Kompliment: Sie tut jeden Tag exakt dasselbe, vorhersehbar, auch wenn das halbe Internet brennt.

2. Eine LLM-/Agenten-Schicht obendrauf. Sie ist der schlaue Teil: Sie versteht, was ich will, schreibt und ändert Regeln, baut Automatiken um, beantwortet Fragen über den Zustand des Hauses. Sie redet mit der Engine über MCP (das Model Context Protocol — quasi die standardisierte Steckdose, über die Sprachmodelle Werkzeuge und Systeme ansprechen).

Und jetzt die Leitplanke, die diese beiden Schichten für immer auseinanderhält — die Kern-These der ganzen Reihe:

Das LLM denkt, schreibt und ändert Regeln. Es sitzt NIE in der Echtzeit-Steuerschleife. Eine schnelle, lokale, deterministische Engine führt aus.

Warum so streng? Weil ein Sprachmodell für eine Steuerschleife die drei falschen Eigenschaften hat: Es ist langsam (Antwortzeiten im Bereich von hunderten Millisekunden bis Sekunden, wo eine Steuerung Millisekunden braucht), es ist nicht-deterministisch (dieselbe Frage kann zweimal leicht anders beantwortet werden — Gift für eine Logik, die jedes Mal identisch reagieren muss), und es ist abhängig (von Rechenlast, im Zweifel von einem Netz). Ein Lichtschalter, der erst angeht, wenn ein Modell fertig gegrübelt hat, ist kaputt — so einfach ist das.

Deshalb: Das KI-Hirn ist der Architekt, nicht der Bauleiter, der bei jedem Handgriff danebensteht. Es entwirft und ändert den Plan; ausgeführt wird der Plan von einer dummen, schnellen, grundsoliden Maschine. Genau dieses Prinzip macht Loxone heute lokal schon richtig — und genau dieses Prinzip rette ich in die neue Welt hinüber, statt es gegen Cloud-Bling-Bling einzutauschen.

(Konkret geplant ist die Engine als schneller, lokaler Kern mit festem 50-Hz-Takt — also alle 20 Millisekunden ein kompletter Durchlauf. Bewusst soft-realtime und mitlaufend im vorhandenen Proxmox-Cluster, statt teurer dedizierter Echtzeit-Hardware; 50 Hz reichen für Haustechnik mit Komfort. Die wirklich zeitkritischen Reflexe — Schalter drücken, Licht an — sollen zusätzlich ganz unten an der I/O-Kante lokal abgesichert sein, damit selbst ein Neustart der virtuellen Maschine sie nicht ausknockt. Aber Vorsicht, ganz ehrlich: Das ist die aktuelle Architektur-Entscheidung, kein laufender Code. Sprache — geplant Rust für die Engine, Node für das Brain —, Taktrate und das ehrliche „läuft / läuft noch nicht“ bekommen eine eigene Folge zum Tech-Stack. Ich will hier nichts behaupten, was noch nicht steht.)

Wie das Brain die Loxone-Hardware überhaupt anspricht

„Loxone zur Hülle degradieren“ klingt erstmal nach einem Schlagwort. Technisch steckt dahinter ein konkreter Zugang, und der läuft bei mir in einem Schwester-Projekt schon gegen einen echten Miniserver:

• Das Brain verbindet sich per WebSocket mit dem Miniserver und liest die Strukturdatei LoxAPP3.json — das ist die komplette Landkarte der Installation: alle Räume, Kategorien und Steuerobjekte mit ihren eindeutigen IDs (UUIDs). Genau diesen Weg nutzen auch Home Assistant und Node-RED.
• Statusänderungen kommen als Live-Event-Stream, nicht per ständigem Pollen: einmal enablestatusupdate angefordert, pusht der Miniserver jede Wertänderung von selbst über die offene Verbindung. Sparsam und in Echtzeit.
• Geschrieben wird über das jeweilige benannte Steuerobjekt (/dev/sps/io//On|Off|Pulse bzw. ein Analogwert) — man adressiert also den Baustein, nicht direkt die Hardware-Klemme; der direkte Schreibzugriff per Control-UUID über die WebSocket-Verbindung geht ebenfalls. So kann das Brain einen Ausgang genauso schalten, wie es seinen Zustand liest. Kein Hack, sondern der vorgesehene Weg — und er authentifiziert sich über ein Token, nicht über ein Klartext-Passwort.
• Merker bzw. virtuelle Eingänge nehme ich nur als Fallback — für reine Logik-Punkte, die kein eigenes Command-Interface haben. Das ist die Ausnahme, nicht der Normalweg.
• Was ich mir gespart habe: der naheliegende MQTT-Weg ist auf meiner Miniserver-Generation eine Sackgasse — die Anzahl der Topics ist mit 15 rein und 15 raus viel zu knapp gedeckelt, um eine ganze Installation abzubilden. Schön, das früh zu wissen, bevor man es aufwendig falsch baut.
• Wichtig zur Einordnung: Diese WebSocket-Schnittstelle selbst ist erprobt und produktiv — in einem Schwester-Projekt läuft sie stabil gegen einen echten Miniserver. Was noch aussteht, ist die saubere Einbindung genau dieses Zugangs in das neue Brain.

Das ist der Hebel, der den ganzen Umbau erst realistisch macht: Ich muss die teure, funktionierende Hardware-Ebene nicht anfassen. Ich übernehme nur den Part, der ihr sagt, was sie tun soll.

Und was, wenn das selbstgebaute Hirn abstürzt?

Berechtigte Frage — schließlich habe ich den Single Point of Failure oben selbst als Loxone-Schwäche angeprangert. Die Antwort steckt schon im Aufbau: Die zeitkritischen Reflexe leben unten an der I/O-Kante und laufen lokal weiter, auch wenn das Brain im Proxmox-Cluster gerade neu startet — so ein Failover dauert grob ein bis zwei Minuten, in denen das Licht trotzdem auf den Schalter reagiert. Das schlaue Hirn darf ausfallen; das dumme, schnelle Rückgrat darf es nicht. Wie robust das am Ende wirklich ist, nimmt eine eigene Folge ehrlich auseinander — Ausfallsicherheit ist bei einem Eigenbau kein Häkchen, das man einmal setzt, sondern eine Daueraufgabe.

Warum überhaupt der große Schritt — und nicht der bequeme?

Zwei Gründe, und beide habe ich oben schon angerissen:

• Das Integrations-Nadelöhr auflösen. Im eigenen Brain soll jedes Gerät seine native Schnittstelle sprechen — über einen eigenen Adapter, der alle in einer zentralen Entitäten-Registry zusammenführt, statt jedes Gerät einzeln durch Loxone zu prügeln. Das ist der eigentliche Befreiungsschlag — und gleichzeitig der Teil, der am meisten Bauarbeit vor sich hat (eine eigene Folge wert).
• Die Agenten-/MCP-Zukunft. Ich will mit dem Haus reden — Zustände abfragen, schalten und die Konfiguration per Sprache ändern. Ein offenes, eigenes Hirn ist der einzige Weg dahin, der mir nicht von einem Hersteller-Fahrplan diktiert wird.

Der eigentliche Hammer: Das Haus lernt aus meinen eigenen Daten

Und jetzt kommt der Punkt, der mich am meisten kribbeln lässt — für mich einer der größten Hebel überhaupt. Über die Jahre sammelt mein Haus eine gigantische Menge an Daten: Präsenzmelder, die sehen, wann ich in welchem Raum bin. Reed-Kontakte, die wissen, wann welche Tür auf- und zuging. Und jede Menge Logs, wann ich welches Licht ein- und ausgeschaltet habe. Bisher war das zum großen Teil schlicht Datenmüll — schön geloggt, aber nie wirklich genutzt.

Genau hier wird der KI-Agent zum echten Sparringpartner. Er kann sich diese Logs anschauen und Muster erkennen, auf die ich von Hand nie systematisch gekommen wäre: zu welchen Zeiten und unter welchen Bedingungen ich das Licht schalte, wie sich Anwesenheit, Tür-Status und Tageszeit überlagern. Daraus macht er von selbst konkrete Regelvorschläge — zum Beispiel das Licht so zu automatisieren, dass ich im besten Fall gar keinen Schalter mehr anfassen muss. Und je länger das läuft, desto besser wird es: Die KI lernt aus meinem tatsächlichen Verhalten mit und schärft den Automatikmodus immer weiter nach.

Für mich ist das nur ein Beispiel von vielen — und ehrlich gesagt einer der Gründe, warum ich glaube, dass KI-Agenten gerade alles verändern. Nicht nur im Smart Home: Überall, wo Sensoren und Logs bisher bloß „Big Data“ produziert haben, mit dem am Ende niemand etwas anfing, wird genau dieser Datenberg plötzlich nutzbar. Aus Datenmüll wird ein System, das mitdenkt.

Wir bauen kein zweites Loxone — und „Warum nicht Home Assistant?“

Damit kein falscher Eindruck entsteht: Es geht ausdrücklich nicht darum, Loxone nachzubauen oder zu klonen. Das wäre sinnlos. Das Herzstück ist nämlich gar keine weitere Steuerungs-Software, sondern die Wissensdatenbank, auf der das Brain aufsetzt. Heute stecken da schon über 200 Loxone-Bausteine drin, durchsuchbar. Aber dabei bleibt es nicht: Ich nehme nach und nach auch andere Systeme mit hinein — allen voran Home Assistant, gefühlt das weltweit führende DIY-Smart-Home-System, und später weitere wie Node-RED (stark in der Flow-Logik) und ioBroker (groß in der deutschen Community).

Und dabei spielt jedes System seine eigene Stärke ins Wissen ein — genau diese Unterscheidung ist mir wichtig:

• Loxone glänzt mit seinen Funktionsbausteinen — kuratierte, über Jahre erprobte, fertige Logik. Das ist das eigentliche Tafelsilber des Systems: Da steckt Erfahrung drin, die man als Selbstbauer nicht mal eben nachbaut.
• Home Assistant glänzt umgekehrt mit Integrationen — tausende Plugins und Erweiterungen, mit denen sich praktisch jedes Gerät anbinden lässt. Die Breite, die einem ein geschlossenes System nie geben kann.

Genau diese zwei Welten führe ich in der Wissensdatenbank zusammen: das Logik-Wissen von Loxone und das Integrations-Wissen von Home Assistant (und weiteren Systemen). Wenn ich dann in meiner eigenen App eine Funktion nachbaue, erfinde ich das Rad nicht neu, sondern greife auf die Best Practices aus beiden Lagern zurück. So weiß das Brain, wie ein bestimmtes Problem in jeder Welt gelöst wird — und wird damit nicht zum Klon eines einzelnen Systems, sondern zu etwas, das die guten Ideen aus allen Ökosystemen kennt und kombiniert.

Womit auch die Frage beantwortet ist, die garantiert kommt: „Warum dann nicht einfach Home Assistant?“ Home Assistant — oder ioBroker, openHAB — ist großartig, aber für mich kein Konkurrent, den ich ersetze, sondern eine von mehreren Wissensquellen, aus denen mein System lernt. Mein eigenes Brain baue ich trotzdem, aus zwei Gründen. Erstens ist auch eine fertige Plattform am Ende ihr Event- und Automations-Modell, in das ich mich reinbiegen muss — genau die strikte Trennung, die mir wichtig ist (knochentrockene deterministische Echtzeit-Engine unten, LLM-Autoren-Schicht sauber darüber), müsste ich auch dort erst obendraufsetzen. Zweitens will ich die Agenten-/MCP-Anbindung nicht als Plugin nachrüsten, sondern als Kern-Designprinzip ab Tag eins. Und ja: Das kann sich als der härtere Weg herausstellen. Auch das gehört zur Ehrlichkeit dieser Reihe.

Und das Beste: die Wissensbasis baut sich gerade selbst

Jetzt kommt der Teil, der das alles für mich überhaupt erst realistisch macht — und ehrlich gesagt der spannendste. Ich fülle diese Wissensdatenbank nämlich nicht mühsam von Hand. Dahinter steht ein Team aus spezialisierten KI-Agenten, die zusammenarbeiten: Einer kuratiert den Blog (ja, auch diesen Beitrag hier), einer ist auf Loxone spezialisiert und pflegt Baustein für Baustein in die Wissensbasis ein, weitere kümmern sich um andere Systeme und Domänen. Jeder ist Experte für sein Gebiet — und gemeinsam treiben sie das Wissen voran.

Das ist keine graue Theorie für „irgendwann“. Es passiert genau jetzt, während dieser Beitrag online geht: Parallel sind gerade Home Assistant mit elf Loxone-Vergleichsartikeln in die Datenbank gewandert, kurz darauf Node-RED — und ioBroker steht als Nächstes an. Die Wissensbasis wächst also nicht in Schüben, wenn ich mal Zeit finde, sondern kontinuierlich, durch dieses Zusammenspiel der Agenten. Und genau dieses Zusammenspiel ist für mich der eigentliche Hebel — der Unterschied zwischen „nettes Konzept“ und „das wird wirklich was“.

Die Hardware-Weichen: konsequent Richtung KNX

Beim Umbau räume ich auch den langen Schwanz an Spezial-Anbindungen auf, der sich über die Jahre angesammelt hat. Denn mein Haus ist gewachsen, und entsprechend gemischt ist die Landschaft: Über die Jahre sind hier KNX, DMX für die Lichtsteuerung, 1-Wire für Temperatursensoren, Modbus für Energiewerte und einiges mehr zusammengekommen. Wie viel Verkabelung da insgesamt drinsteckt, habe ich vor Jahren schon mal dokumentiert — Stichwort drei Leitungskilometer.

Die Grundsatzentscheidung für alles Neue: so viel wie möglich über KNX — ein offener Industriestandard, robust, herstellerübergreifend. KNX bleibt das Rückgrat. Der Rest wandert auf saubere, netzwerkfähige Wege, und vieles davon läuft bei mir ohnehin schon so. Konkret heißt das:

• RS485 läuft bereits über Ethernet — sauber im Netz statt als serielle Strippe.
• DMX (Lichtsteuerung) wandert über ein Ethernet-Gateway ins Netzwerk.
• 1-Wire (Temperatursensoren) hängt künftig an kleinen ESP-Boards mit PoE, die die Werte ins Netz stellen.
• Modbus (Energiewerte, u. a. vom Wechselrichter) wird bei mir sogar weitgehend hinfällig, weil diese Daten ohnehin schon über ein anderes System (Victron Venus OS) zusammenlaufen.
• KNX bleibt — wo nötig mit einer KNX-IP-Schnittstelle pro Linie, damit das Brain sauber drankommt.

Ein Brocken bleibt aber, und der ist hartnäckig: die 0-10-Volt-Geschichten. Da geht es um ein, zwei sehr reale Stellen im Haus, an denen die simple Bastel-Lösung nicht sauber funktioniert — die Lösung dafür hebe ich mir bewusst für später in der Reihe auf, weil sie ein schönes Beispiel dafür ist, dass „selber machen“ eben auch heißt, solche Detailprobleme wirklich zu lösen statt zu überspielen.

Kein Big Bang — das ist mir wichtig

Und weil ich kein Hasardeur bin: Ich reiße nichts an einem Wochenende raus. Ich migriere Gerät für Gerät, Funktion für Funktion. Jedes Stück muss erst seine Zuverlässigkeit beweisen, bevor ich bei Loxone den Stecker ziehe. Ein sauberer, schrittweiser Umzug, bei dem das Haus jederzeit voll funktioniert — und bei dem ich an jeder Stelle zurückkann, wenn das Neue sich noch nicht verdient hat. Den Komplett-Ausstieg entscheide ich am Ende, nicht am Anfang. Vielleicht bleibt Loxone als I/O-Hülle sogar dauerhaft — genau das ist ja der Witz an der Sache.

5. Aktueller Umsetzungsstand (ehrlich, work in progress)

Damit ihr einschätzen könnt, wo ich wirklich stehe — transparent, mit klaren Markern, ohne Schaumschlägerei:

• ✅ Live: Eine Wissensdatenbank mit über 200 Loxone-Bausteinen, durchsuchbar per Hybrid-Suche (semantisch + Volltext). Läuft produktiv und ist die Grundlage, damit das Brain später überhaupt „weiß“, wie Loxone tickt.
• ✅ Real: Strukturierte Konzept-Notizen und erste eigene Technik-Artikel (u. a. zum Loxone-API-Zugriff) liegen in der KB und sind per Schnittstelle abrufbar — die Wissensbasis fürs Brain wächst kontinuierlich.
• 🔄 Erprobt, wird extrahiert: Der oben beschriebene Loxone-Zugang über WebSocket + LoxAPP3.json + Control-UUID-Schreibzugriff läuft bereits produktiv gegen einen echten Miniserver — bisher in einem Schwester-Projekt. Als wiederverwendbarer Baustein fürs Brain muss er noch sauber herausgelöst werden.
• 📋 Konzept (frisch entworfen): Das eigentliche Brain — die deterministische Steuer-Engine plus LLM-Autoren-Schicht über MCP. Die Architektur und die Aufteilung stehen (genau die aus Teil 4), die Implementierung der Engine hat aber noch nicht begonnen. Hier ist ehrlich am meisten Luft.
• 📋 Geplant: Das Reverse-Engineering der bestehenden Config und der Echtzeit-Betrieb am Test-Miniserver — das hängt noch an ein paar Zugängen.
• ✅ Angelaufen: Die Hardware-Weichen sind gestellt — konsequent über KNX, inklusive des kniffligen 0-10-Volt-Themas (Lösung steht, Beschaffung läuft, Details folgen in der Reihe).

Ehrlich zusammengefasst: Das Fundament — Wissen und ein erprobter Zugang zur Hardware — steht. Das eigentliche Hirn ist durchdacht, aber frisch in der Mache. Ihr lest hier also live mit, wie es entsteht — inklusive der Stellen, an denen ich mich verrenne. Genau so soll diese Reihe funktionieren.

6. Aus meinem täglichen Leben

Ganz ehrlich: Im Alltag hat sich bisher — nichts geändert. Und das ist volle Absicht. Während ich im Hintergrund am neuen Hirn schraube, läuft das Haus weiter wie immer, die Lichtschalter tun, was sie sollen, und meine Familie merkt von dem ganzen Umbau genau null. Genau so muss es sein: Der Umbau ist für mich, nicht gegen den Alltag.

Was sich dafür umso mehr verändert hat, ist mein Kopf. Seit Wochen lässt mich dieser eine Gedanke nicht los, und ich ertappe mich dauernd dabei, wie ich abends statt „nur mal kurz“ wieder zwei Stunden in Konzept-Notizen versinke. Viele kleine Details, die man der fertigen Lösung später gar nicht ansieht — welcher Wert wo herkommt, was passiert, wenn genau dieser eine Sensor mal nicht antwortet — fressen jetzt schon richtig Zeit. Wer selbst mal an so einem Umbau gesessen hat, kennt das.

Der Moment, auf den ich mich am meisten freue, ist eigentlich ein ziemlich unspektakulärer: das erste Mal, dass ich nicht die Config öffne, sondern einfach sage „mach das Wohnzimmer abends 20 Prozent wärmer“ — und es passiert. Kein Baustein, kein Reboot, kein 30-Sekunden-Warten. Bis dahin teste ich brav am Test-Miniserver weiter, damit zu Hause keiner was davon mitbekommt.

Die größten Vorteile — und was man ehrlich mitdenken muss

Worauf das Ganze hinausläuft — die stärksten Argumente dafür, und das, was man bei so einem Schritt fairerweise dazusagen muss:

✅ Dafür spricht	⚠️ Das muss man mitdenken
Konfiguration per Sprache. Die KI richtet ein — ich sage nur, was ich will.	Selbstgebaut = selbst verantwortlich für Stabilität und Ausfallsicherheit (eigene Folge).
Das Haus lernt aus den eigenen Daten (Anwesenheit, Türen, Schaltzeiten) und schlägt Automatiken vor.	Datenschutz: Bei Cloud-KI fließen Nutzungsdaten in die Cloud.
Proaktive Verbesserungen. Der Agent prüft die Logs von selbst und liefert laufend Vorschläge.	Gegenmittel lokale LLMs: potenziell 100 % lokal — künftig sogar auf Smartphone oder Mini-Rechner mit wenigen Watt.
Wissen aus allen Welten (Loxone, Home Assistant, Node-RED, ioBroker) statt einem Hersteller.	Lokale Modelle noch schwächer — holen aber rasant auf.
Zuverlässig und schlau: deterministische Engine unten, KI-Schicht oben.	Stand heute ein Plan / Work in Progress, kein fertiges Produkt.

Hilfe! Ich brauche eure Ideen 🙏

Und jetzt seid ihr dran — genau die Sache, bei der ich oben im Audio eure Hilfe brauche: Mein neues, KI-gesteuertes Hirn fürs Haus hat noch keinen Namen. Und so ein Ding sollte einen richtig guten tragen. Wie würdet ihr es taufen? Schreibt euren Vorschlag in die Kommentare — ein einziges Wort genügt, ob nüchtern-technisch, frech oder völlig abgedreht. Ich lese jeden Vorschlag und antworte auf jeden. Und wer weiß: Vielleicht heißt mein Haus-Hirn am Ende genau so, wie ihr es getauft habt.

Und dann geht es in dieser Reihe Schritt für Schritt weiter — als Nächstes vermutlich mit der ersten Beta meiner neuen, selbstgebauten Smart-Home-Software. Bleibt dran, es wird spannend.

📝 Transkript der Sprachnachricht oben (zum Aufklappen)

„Servus, Jörg hier. Ganz ehrlich: Mein Smart Home dreht sich gerade um 180 Grad – und ich werfe Loxone teilweise raus. Acht Jahre lang war der Miniserver das Gehirn meines Hauses, und ich hab ihn geliebt. Aber ich bin rausgewachsen. Jetzt baue ich mir mein eigenes, KI-gesteuertes Hirn, mit dem ich einfach reden kann. Radikal? Absolut. Ich nehme dich in diesem Artikel mit – ehrlich, mit allen Zweifeln und allem, was mich an die Wand treibt. Und ganz am Ende brauche ich sogar deine Hilfe bei einer Sache – aber was genau, das verrate ich dir erst im Artikel. Bleib dran, es lohnt sich.“