Hey! :)
Ich wollte mal ein kleines Experiment teilen, das ich kürzlich umgesetzt habe – vielleicht gibt es ja abseits von vermutlich üblichen ,,braucht doch keiner"-Reflexen trotzdem etwas Interesse oder eine Diskussion.
Kurzfassung:
Ich habe einen MCP-Server als Brücke zu FHEM gebaut, der es einem lokal laufenden LLM erlaubt, FHEM-Devices strukturiert abzufragen und zu steuern. Das Ganze läuft ohne Cloud, komplett lokal, und greift letztlich nur über die bekannten FHEM-Mechanismen (in meinem Fall via verschlüsseltem Telnet) zu.
Etwas ausführlicher:
- MCP-Server stellt u. a. Funktionen wie list_devices, get_device_commands, execute_command bereit (mehr ERSTMAL für den ersten Durchstich nicht)
- LLM läuft lokal (LM Studio, GPU-beschleunigt, in diesem Fall einfach gpt-oss 20B auf meinem M2 Max MacBook Pro)
- Das Modell bekommt keine Sonderrechte, sondern nutzt exakt die definierten Schnittstellen via Telnet
- FHEM selbst bleibt unverändert, es kommt nur eine zusätzliche, klar abgegrenzte Steuerschicht dazu
Der praktische Test war dann banal:
Ein natürlicher Sprachbefehl (,,na dann schalte doch mal meine Schreibtischlampe ein") => Tool-Intents liefen los => Modell ermittelt passendes Device => prüft verfügbare Commands => führt den Befehl aus => Lampe geht an, sauber nachvollziehbar im FHEM-Log.
Mir ist völlig klar, dass jetzt direkt Fragen kommen wie
,,Warum nicht einfach Alexa/Google/HomeKit?" oder
,,Was bringt mir das gegenüber einem normalen Sprachassistenten?"
Fairer Punkt – für viele vermutlich gar keinen Mehrwert. Habe ich natürlich auch alles mit AlexaFhem und Homebridge laufen.
Für mich ist der interessante Teil aber:
- freie, lokale Interpretation natürlicher Sprache
- kein festes Skill-/Intent-Modell
- keine Cloud, kein Vendor-Lock-in
- nachvollziehbares Reasoning (welches Device warum angesprochen wurde)
Ob das am Ende Spielerei bleibt oder ob sich daraus sinnvolle Anwendungsfälle ergeben (z. B. komplexere Zustandslogik, Kontext, Kombination mehrerer Geräte), wird sich zeigen.
... aber ziemlich sicher kann ich jetzt sagen ,,Ich hab grade beim Kacken kalte Füße" und das Reasoning würde das Device ,,FussbodenheizungBad" finden und anschalten. :D :D :D
Ich wollte es hier einfach mal teilen – vielleicht hat ja jemand Lust, das technisch einzuordnen oder weiterzudenken, statt nur zu erklären, warum man das nicht braucht. :)
Vielleicht erweitere ich es auch mal und packe es in ein GitHub Repo oder so. :)
Viele Grüße
Patrick
Ich finde das interessant. Da war ja neulich ein c't Artikel zu MCP, da kam mir auch FHEM in den Sinn. Aber über ein paar Experimente im Prompt bin ich nicht hinausgekommen.
Das LLM hat sicher auch kein Problem den Quellcode und die Doku zu verarbeiten (ich sage mal nicht verstehen). Ich glaube, dass man da auch komplexere Aufgaben delegieren kann wie "Lege eine Regel an die das Flurlicht einschaltet wenn die Haustür geöffnet wird". Möglicherweise ist FHEM da auch ganz gut geeignet wegen der umfassenden Doku, dem frei zugänglichen Code und der programmiersprachen-ähnlichen Syntax. Also Code gerne teilen, einen Blick werde ich mal reinwerfen :)
Dann versuche ich doch mal vor dem Hintergrund meiner Erfahrung in mehreren wissenschaftlichen KI-Projekten, das "einzuordnen".
1. Die Steuerung einer Hausautomatisierung ist eine einfache Aufgabe mit sehr begrenztem Wortschatz und sehr begerenzter Semantik. Es ist eine irrsinnige Energie-(und sonstige Ressourcen-)Verschwendung, für dafür ständig eine Maschine vom Kaliber MacBook Pro laufen zu lassen. Tatsächlich hat sich das ein wenig eingeschlichen, manche KI-Projekte setzen wirklich für jeden Mist ein neuronales Netz ein.
2. Das Wesentliche bei der Hausautomatisierung ist die Erkennung eines "Intents", also einer Absicht. Diese lässt sich in den meisten Fällen aus einer einigermaßen normierten Sprache herausholen, genau dafür gibt es seit etlichen Jahren das FHEM-Modul Babble. Auch wenn ich die im Ausgangspost verwendete Sprache nicht verwenden will: Ein Satz, in dem die Begriffe "Toilette", "kalt" und "Füße" vorkommen, kann damit problemlos in eine FHEM-Anweisung umgesetzt werden. Da Babble auch die Ankopplung eines einfachen Chatbots erlaubt, können damit auch Dialoge geführt werden. Beispiel: Ich:"Spiele Musik" -> FHEM:"Wo soll ich Musik spielen" -> Ich:"Im Wohnzimmer" -> FHEM:"Von wem soll ich im Wohnzimmer Musik spielen" -> Ich:"Von Alison Balsom" -> FHEM:"OK, ich werde im Wohnzimmer Musik von Alison Balsom spielen"
3. Der Einsatz eines LLM ist nur sinnvoll, wenn eine solche Erkennung fehlschlägt. Dafür braucht man aber keinen MCP-Server, sondern kann das LLM dafür benutzen, die verwendete Sprache zu normieren. Beispiel, hier aus ChatGPT:
Ich gebe Dir nachfolgend mehrere Sätze zum analysieren. Extrahiere mir daraus jeweils erstens: Einen Handlungsort, zweitens: Ein zu bedienendes Gerät aus der Liste: Beleuchtung, Heizung,Klimaanlage, drittens: Eine am Gerät durchzuführende Aktion. Wenn sich aus einem Satz mehrere Aktionen ergeben würden, führe diese Tripel jeweils separat auf.
Satz 1: "Beim Sitzen auf der Toilette habe ich kalte Füße".
Satz 2: "Im Flur ist es zu dunkel"
Satz 3: "Im Schlafzimmer ist es zu warm und zu feucht"
Satz 1: ,,Beim Sitzen auf der Toilette habe ich kalte Füße."
Handlungsort: Toilette
Gerät: Heizung
Aktion: Heizung einschalten bzw. Heizleistung erhöhen
Satz 2: ,,Im Flur ist es zu dunkel."
Handlungsort: Flur
Gerät: Beleuchtung
Aktion: Beleuchtung einschalten bzw. Helligkeit erhöhen
Satz 3: ,,Im Schlafzimmer ist es zu warm und zu feucht."
Handlungsort: Schlafzimmer
Gerät: Klimaanlage
Aktion: Raum kühlen (Temperatur senken)
Handlungsort: Schlafzimmer
Gerät: Klimaanlage
Aktion: Luft entfeuchten
Solche Anfragen kommen vielleicht 1x pro Tag vor, alles Andere kann von einem semantischen System abgefangen werden.
4. Damit ist eigentlich klar, dass ein eigenes LLM für den begrenzten Zweck der Hausautomatisierung nicht sehr sinnvoll ist.
LG
pah
Aber nehmen wir jetzt mal eher die Konfiguration von FHEM selbst in den Blick, also das Anlegen von Devices, die ein bestimmtes gewünschtes Szenario abbilden, das man mit natürlicher Sprache beschreibt. Wäre das nicht eine sinnvolle Nutzung?
LLMs können da vermutlich nicht nur die korrekten Devices anlegen sondern auch noch den PERL Code erzeugen, den man ggf. in 99_myUtils.pm braucht. Dafür müsste das LLM auch nicht permanent laufen, sondern nur wenn man gerade was ändern will.
Geht die Diskussion hier:
https://forum.fhem.de/index.php?topic=143598.0
nicht in eine ähnliche Richtung?
Dort dann allerdings nicht mit lokalen Ressourcen sondern Gemini.
@RalfRog: Natürlich. Dort habe ich ja auch für das Modell aus mehreren Schichten geworben. Und das ist, pardon, nicht Werbung weil das Babble-Modul von mir stammt. Es steht jedem frei, etwas Anderes zu verwenden, ich denke, dass man auch mit Rhasspy so etwas aufsetzen kann.
@kgie: LLM sind sehr gut brauchbar als Sparringspartner beim Programmieren. Aber, sorry, nicht für Anfänger. Und man darf dabei auch nicht Code erwarten, der hohe Qualität hat.
LG
pah
mein Senf dazu:
ZitatAber nehmen wir jetzt mal eher die Konfiguration von FHEM selbst in den Blick, also das Anlegen von Devices, die ein bestimmtes gewünschtes Szenario abbilden, das man mit natürlicher Sprache beschreibt. Wäre das nicht eine sinnvolle Nutzung?
Klingt immer gut, wenn es etwas vereinfacht. ABER: wir kennen das doch zur Genüge:
Was man nicht selber entwickelt hat, fällt einem irgendwann auf die Füße.
- Fehleranalyse
- Verständnis des erst einmal unverständlichen (und in dem Augenblick unerwünschten)Verhaltens einer komplexen Steuerung
- Erweiterungen von vorhandenen Steuerungen
....
Hey zusammen,
erstmal danke für das viele und teils sehr unterschiedliche Feedback - finde ich sehr spannend und freue mich, dass überhaupt etwas zurückkam! :)
Ein paar Punkte zur Einordnung, weil hier teilweise aneinander vorbeigeredet wird und zum generellen Kontext:
Der Ansatz war und ist von Anfang an als Experiment (bzw. sogar Spielerei) genannt, nicht als Vorschlag für eine produktive, dauerhafte Sprachsteuerung von FHEM. Mich interessiert daher weniger ,,wie schalte ich am effizientesten ein Licht", sondern ,,wie verhält sich ein LLM, wenn es strukturiert und kontrolliert auf ein bestehendes System zugreifen darf" bis eben hin zu "Wohin können wir das entwickeln, um z.B. für die geschickte Konfiguration ein stabiles, schnelles und genaues Tool zu bekommen".
Dass HomeAssistant in diese Richtung bereits deutlich weiter ist (MCP ist dort inzwischen etabliert) war dann noch zusätzliches Salz in der Wunde - der Softwarearchitekt und HA-Nutzer aus meinem (beruflichen) Projekt war z.B. sogar erstaunt, dass "wir" (FHEM) so etwas noch nicht haben! (Jaa, der Spott in der Kantine war groß... :-X :D )
Ich bin mir aber auch nicht 100% sicher, was in HomeAssistant schon möglich ist. In meinem Falle habe ich ja zunächst
sehr bewusst auf MCP-Tools, welche Geräte anlegen etc. verzichtet. Das wäre sicher aber einer der nächsten Schritte. :) Dachte da im nächsten Schritt des Experiments grob an ein Sandbox-FHEM in einer VM mit einigen Device-Dummys zu denen man dann mal Automatismen schreiben lässt oder so.
@kgie
Ja, genau das ist für mich einer der spannendsten nächsten Schritte! :)
Nicht Live-Steuerung, sondern Konfigurationserzeugung (Devices, DOIFs etc.).
Wichtig dabei: sicher grade am Anfang bzw. für Profi-Nutzer (unter welche ich die meisten Leute, die alleine im Forum schon nur nicht in ihre eigenen Threads schauen mal packen würde :D) nicht
,,Prompt => ungeprüfter Code => live", sondern eher
Prompt => Vorschlag => Review => Anpassung/Refactoring => AktivierungGerade bei FHEM mit seiner offenen Doku, dem zugänglichen Code und der klaren Syntax sehe ich da Potenzial!
Zusätzlich würde ich mit RAG (Retrieval Augmented Generation) arbeiten, also Einbeziehen von Doku, Beispielen und ggf. Forenlösungen.
Dazu vielleicht noch ein Mini-Exkurs:
Viele schlechte Erfahrungen, welche Leute mit ,,Coding per KI" haben, kommen m.E. daher, dass ohne Spezifikation und Kontext gepromptet wird – dann sind inkonsistente Ergebnisse wenig überraschend und es wird abgeschmiert als "KI coded nicht in guter Qualität". Dass das an der Realität mittlerweile vorbei ist, sieht man aber natürlich an den Schlagzeilen wie z.B., dass Microsoft jetzt großflächig Claude Code für seine Entwickler ausrollt etc., wie man es also dreht, wendet oder ob man es selbst mag: Profis nutzen es, das ist klar! Man muss das "Werkzeug" aber natürlich gut verstehen und geschickt nutzen, da es ja nun doch etwas komplexer ist als z.B. ein Linter, der mich nur im JavaScript auf eine fehlende Klammer hinweist.
Anderes, realitätsnäheres Mini-Beispiel: Wenn ich 10-mal hintereinander selbst in ein gutes Tool wie Claude Code schlicht ,,Bau mir einen Taschenrechner" prompte, bekomme ich zwangsläufig 10 unterschiedliche Ergebnisse mit stark schwankender Qualität. Das ist kein Bug, sondern falsche Nutzung: fehlende Spezifikationen!
Hier hilft z.B. Spec-driven Development - also mit klaren Anforderungen reingehen:
- UI soll so aussehen
- Features müssen z.B. Wurzel und e-Funktion beinhalten
- Randbedingungen sind diese und jene
- Zielumgebung ist z.B. eine native Mac App in Swift
- etc.
und idealerweise ist das ganze RAG-unterstützt. So wird relevante Doku, bestehende Beispiele etc. vorab einbezogen und die Ergebnisse werden DEUTLICH konsistenter und nachvollziehbarer.
Genau diese Kombination halte ich für spannend, auch im FHEM-Kontext! :)
@pah
Ich glaube, hier sind wir fachlich näher beieinander, als es auf den ersten Blick bei der Antwort wirkt. Deine Punkte sind schlüssig - für eine produktive Sprachsteuerung, darum geht es hier aber nicht. :)
Ich denke, hier wurde "Experiment" und "Spielerei" völlig übergangen, aber das ist schon ok. Mit 1-2 Antworten in diese Richtung habe ich ja, wie anfangs erwähnt, auch gerechnet, daher ganz kurz zu den Punkten:
- Energieeffizienz ist bei einem Experiment und bei Entwicklung kein Bewertungskriterium. Das lokale System lief ohnehin, FHEM war nur ein angebundener Aktor etc.
- Intent-Erkennung per Babble / Regex etc. ist natürlich für strukturierte Sprache völlig ausreichend – das wird hier auch nicht ersetzt. Aber auch hier mal über "andere Nutzer" im Haus nachdenken, die vielleicht nicht wissen, wie ein Device genau heißt etc. - absoluter game changer, natürlich Sprache nutzen zu können, die nicht strukturiert ist und quasi keine Kenntnis über das System voraussetzt.
- Das gezeigte Normierungs-Beispiel ist korrekt, aber der experimentelle Unterschied ist: Das Modell entscheidet selbstständig über Devices, Fähigkeiten und Befehle. Um diese Entscheidungen kontrolliert ausführen zu können, braucht es dann genau so eine Schnittstelle wie MCP.
- Ein eigenes LLM nur für Hausautomatisierung ergibt keinen Sinn – das war auch nie die These. Davon ab geht das mMn generell in Richtung "KI Nutzen vs. Ressourcenverbrauch" und da könnten wir jetzt 700 Beispiele ausdiskutieren a la "Wenn du ChatGPT fragst, statt zu googeln verbrauchst du 10x mehr Energie für dasselbe Ergebnis", trotzdem tun Leute genau das nunmal, weil es natürlicher zu bedienen ist! Aber darum geht es hier wie gesagt nicht und das Thema möchte ich bitte entsprechend beenden.
@KölnSolar
Völlig berechtigter Hinweis! Das Thema hatte ich noch gar nicht erwähnt!
Bendenke aber hier auch mal den Unterschied bezüglich der Zugänglichkeit zwischen z.B.:
- komplexen, gewachsenen Profi-Setups mit hunderten Regeln
- Einsteiger- oder Hobby-Szenarien, wo jemand schlicht möchte, dass abends bei Bewegung drei Lampen angehen – und dafür erstmal eine Stunde braucht, nicht mit der Doku klar kommt, im Forum aber gesagt bekommt "Na lies doch die Doku" :D (scnr)
Grade letzterem Fall kann ,,KI als Vorschlagsgenerator" mMn helfen, solange klar ist, dass man Verantwortung und Verständnis nicht vollständig delegiert.
@RalfRog
Genau - wenn es einen MCP-Server für FHEM gibt, ist der Client im Prinzip austauschbar!
Lokales LLM, Cloud-LLM, Coding-Agent – alles denkbar, je nach Zielsetzung und Kostenmodell.
Hier fand ich eben lokale Modelle aus mehreren Gründen spannend, da man keine teuren Token bezahlt und ich sonst bei 8/10 Usern bereits das große "Jaja klar, dann weiß OpenAI demnächst auch noch, wo meine Lampe steht - NEIN, DANKE!" am Horizont gesehen habe. :D ... primär aber der experimentelle und spaßige Aspekt, sowas komplett selbst zu betreiben :P
Letztlich sind dann ja auch Lösungen denkbar wie ein LLM, was auf dem Haussteuerungsserver läuft und per Routing z.B. nur in komplexen Fällen bedient wird oder z.B. in einer VM für unterschiedliche Anwendungen im Haus zur Verfügung steht... die Möglichkeiten sind da unzählig - aber alle auch noch etwas weiter am Horizont.
Ich werde den Code aufräumen und dann gern teilen - Feedback aus unterschiedlichen Richtungen find ich aber weiterhin super spannend, gerade auch kritisch-konstruktives!
Hach, mir macht das Thema einfach Spaß. :D
Viele Grüße :)
Patrick