fhem-mcp - FHEM-Steuerungs-Spielerei mit lokalem LLM

[Pati_Alpha]

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.

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

[kgie]

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 

[Prof. Dr. Peter Henning]

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:

Code Auswählen Erweitern

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"

Code Auswählen Erweitern

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

[kgie]

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.

[RalfRog]

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.

[Prof. Dr. Peter Henning]

@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

[KölnSolar]

mein Senf dazu:

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?

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
....