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

Begonnen von Pati_Alpha, 28 Januar 2026, 17:23:23

Vorheriges Thema - Nächstes Thema

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