[Modul] Symcon-MCP-Server

Erweiterungen Externe Zusatzsoftware
1

Hi zusammen,

ich habe heute nach mal einen Prototyp eines Symcon-MCP-Servers als Modul entwickelt. Es ist wirklich verblüffend wie gut es auf anhieb funktionierte.

Das Modul kann über den Link installiert werden. Es Modul befindet sich aber noch in Entwicklung und dient nur zum Testen und Sammeln von Erfahrungen im Zusammenhang mit MCP.

Man stellt einfach die Verbindung mit dem Symcon-System her und eine beliebige KI versucht sich selbst zurechtzufinden und erlernt selbst, was, wie und wo gesteuert werden kann oder soll. Dabei versucht sie sich erst mal einen Überblick zu schaffen und baut sich nach und nach eine eigene Wissensdatenbank auf. Dabei müssen Aktoren nicht so genannt werden wie der Befehl.

Desto besser die Struktur in der Symcon-Console ist, desto schneller findet sich die KI zurecht. Aber selbst wenn etwas mal gar nicht nachvollziehbar ist, kann die KI Rückfragen stellen.

Beispel:
Aktor heißt “LI-01”
„Schalte das Licht im Badezimmer ein.“
Darauf kann die KI nachfragen, z.B. “Ich kann es nicht finden. Kannst du es mal einschalten?”
Dabei schneidet das MCP die Variablenänderung mit und die KI lernt, welches Licht hier im Badezimmer gemeint war.

Es hilft wenn man in Symcon eine Struktur nach Räumen aufgeteilt hat. Ich habe bisher nur 4-5 Stunden getüftelt, aber das hat schon ziemlich spaß gemacht.

Ich hab der KI gesagt, Schalte bitte meine Treppenbeleuchtung ein und habe mich dann vor meiner Treppe voller Erwartungen gestellt. Siehe da, es hat geklappt! Der Homematic-Wired-Aktor hieß EG-TH-LI-01 und war im Ordner “Treppenhaus”.

”Mach mal bitte rotes Licht in der Küche.”. ArtNet-Controller, hat funktioniert.

”Dimme wir mal ein Licht im Flur.” Hue-LED-Strip, hat funktioniert.

”Mach mal meine Rollade im Büro auf.” Daraufhin hat die KI die Rollade geschlossen.
”Du hast die Rollade da nicht auf, sondern zugemacht.” Die KI antwortete mit “Bitte entschuldige.” und hat die Rollade geöffnet.

”Schalte das Licht im Schlafzimmer in 10 Minuten an und in 15 Minuten die Rollade etwas auf” Funktioniert! Dafür wird dann ein entsprechendes Skript angelegt.

Aktuell habe ich den MCP-Server lokal auf meinem Mac ausgeführt, weil es auf meiner SymBox nicht auf Anhieb lief, mit eigenem Port (habe ich mir noch nicht näher angeschaut). Ich habe es mal hochgeladen, und ihr könnt auch gerne damit rumspielen.

Über das Skript mit dem Aufruf “MCP_HTTP=1 ./start-mcp-local.sh” könnt ihr den Server erstellen und starten. Vorher eine local-config.env erstellen. Eine Vorlage liegt im Ordner genauso wie eine detaillierte Anleitung.

Beste Grüße
iMaxxx

5 „Gefällt mir“
ChatGPT vs. Gemini
2

Spannend und Danke für den Anstoß! Ich habe mir mal einen schnellen Fork gebaut und den Node MCP Server Teil in einen Docker verschoben https://github.com/Seb0815/symcon-mcp-server so muss man nicht in der Dockerinstallation von Symcon rumdoktern. Schon cool wie schnell man brauchbare Dinge auch in einem komplexen Symconumgebung bekommen kann.

Ich werde deine Implementierung auf jeden Fall noch weiter testen.

Danke und Grüße

Seb.

3

Hi, cooles Projekt, hab mir die Docker Installation von Seb. mal installiert und versucht mit meiner lokalen OpenWebUI Installation zu verbinden.
Also:

Symcon (mit MCP Modul) ←→ Docker (MCP-Server) ←→ OpenWebUI (MCP Tool)

alles scheint auch zu funktionieren, zumindest sehe ich die Anfragen im MCP-Server und keine Fehler, aber die KI scheint keine Liste von Geräten zu bekommen und halluziniert über Geräte und Räume die es nicht gibt :frowning:

Irgendeine Idee wie ich testen kann ob der MCP Server daten vom Symcon bekommt ?

4

@SebiMann : Habe das mal ebenfalls mit docker nachgebaut und nach ein paar hürden läuft es auch. Was mir in der Doku aufgefallen ist:

  • Man muss Dein Repo clonen, nicht das original
  • es gibt keine .env.example für das setup script im Repo, muss man sich selber anlegen
  • im docker-compose.yml wird ein volume ./libs/mcp-server/data gemountet, was es per default nicht gibt. Das muss man sich selber anlegen, besser wäre es wahrscheinlich ein docker volume stattdessen zu nutzen
  • der Befehl zum ansehen der logs sollte docker compose logs -fheissen

Im Augenblick habe ich jedoch probleme, den MCP mit dem http type in claude_desktop sichtbar zu machen. Spricht der nicht das mcp Protokoll direkt?

{
  "mcpServers": {
    "symcon": {
      "type": "http",
      "url": "http://docker:4096",
      "headers": {
        "x-mcp-api-key": "Bearer xxxyyyy"
      }
    }
  }
}
5

Hey, danke fürs Ausprobieren und das Feedback! Das Halluzinationsproblem kenne ich — der MCP-Server liefert nur dann echte Daten, wenn der KI-Agent die Tools aktiv aufruft. OpenWebUI macht das nicht automatisch.

Schnelltest ob der Server überhaupt mit Symcon kommuniziert:

curl -X POST http://<SERVER-IP>:4096 \
  -H "Content-Type: application/json" \
  -H "X-MCP-API-Key: DEIN_KEY" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"symcon_ping","arguments":{}}}'

Wenn da kernelVersion zurückkommt, läuft alles korrekt. Das Problem liegt dann am System-Prompt — OpenWebUI muss angewiesen werden, zuerst symcon_get_object_tree aufzurufen bevor es über Geräte redet. Ich hab das in die Anleitung aufgenommen.

6

Danke für die detaillierte Analyse, das war sehr hilfreich! Hab alle Punkte in v2.1.0 behoben:

  • .env.example liegt jetzt im Repo

  • data/-Verzeichnis wird von start-docker.sh automatisch angelegt — kein manuelles mkdir mehr nötig

  • Header-Format ist jetzt in der Anleitung als Tabelle dokumentiert: Bei X-MCP-API-Key direkt den Key eintragen, kein Bearer-Präfix. Das war wahrscheinlich auch dein Problem mit Claude Desktop:

    „headers“: {

    „x-mcp-api-key“: „xxxyyyy“

    }

  • statt "Bearer xxxyyyy" — Bearer gehört nur zum Authorization-Header.

  • Log-Befehl: Beide Varianten (docker logs -f symcon-mcp-server und docker compose logs -f) stehen jetzt in der Anleitung.

Zu Claude Desktop und "type": "http" — das ist der Streamable-HTTP-Transport, den Claude Desktop ab Version 0.9+ unterstützt. Falls du eine ältere Version hast, musst du den mcpb-Adapter im mcpb/-Ordner nutzen (stdio → HTTP-Bridge). Steht in mcpb/README.md.> curl -X POST http://:4096
-H „Content-Type: application/json“
-H „X-MCP-API-Key: DEIN_KEY“
-d ‚{„jsonrpc“:„2.0“,„id“:1,„method“:„tools/call“,„params“:{„name“:„symcon_ping“,„arguments“:{}}}‘

Wenn da kernelVersion zurückkommt, läuft alles korrekt. Das Problem liegt dann am System-Prompt — OpenWebUI muss angewiesen werden, zuerst symcon_get_object_tree aufzurufen bevor es über Geräte redet. Ich hab das in die Anleitung aufgenommen.

7

vielen Dank. Mittlerweile hatte ich mir meine eigene http fähige Version gebastelt ( KI Integration in IPSYMCON - #2 von tommi )

Das headquarter war ebenfalls schon in der Richtung aktiv (GitHub - symcon/SymconMCP · GitHub) und hat auch Videos dazu gemacht

8

Hier meine Erfahrungen mit IP-Symcon und MCP – das primäre Ziel war die Sprachsteuerung meines Hauses, ähnlich wie Alexa.

Lokale Modelle (Ollama / OpenWebUI)

  • Die Modelle, die in meine 22 GB VRAM passen, sind für sinnvolle MCP-Anfragen leider zu dumm. Einzig qwen3.5:9b ließ sich manchmal dazu bringen etwas zu tun – vor allem, wenn die Geräte in der Knowledge Base hinterlegt waren.

  • Neben der Modellgröße ist das benötigte Context Window das Hauptproblem. Mit über 2.000 Variablen in meiner Symcon-Instanz schaffen es die kleinen Modelle nicht, den Root-Kontext sauber zu setzen und versuchen den gesamten Baum zu laden.

  • Eine Filteroption im MCP-Server wäre sehr hilfreich, damit das LLM nur eine definierte Teilmenge an Geräten sieht – ähnlich wie in Home Assistant, wo man die steuerbaren Geräte gezielt freigeben kann.

  • qwen3.5:32b lief schon deutlich besser, musste aber mangels VRAM im RAM ausgeführt werden. Die Latenz war entsprechend: ca. 5 Minuten, bis das Wohnzimmerlicht gefunden und eingeschaltet war. Für praxistaugliche Geschwindigkeit bräuchte ich mindestens 2× RTX 3090.

Cloud-Modelle

  • Claude Sonnet 4.6 lieferte mit Abstand die besten Ergebnisse. Die Integration in die Desktop App ist beeindruckend. Auch die direkte API-Anbindung ins lokale System lief hervorragend – allerdings waren nach wenigen Befehlen (Licht an/aus, Rollladen hoch/runter) bereits ~3 € verbraucht. Auch hier würde auch eine Filterfunktion die Kosten deutlich senken.

  • Gemini lag irgendwo zwischen Claude und dem lokalen qwen3.5:32b, konnte mich aber nicht überzeugen – es gab vereinzelte Fehler und Probleme beim Tool Calling.

Mit etwas Glück komme ich in nächster Zeit an 2× RTX 3090 heran, um lokale Modelle weiter zu testen. Für Modell-Empfehlungen bin ich jederzeit dankbar!

9

Das ist super spannend! Vielen Dank für diese Beiträge. Ich bin sehr daran interessiert!

Mein Ziel wäre allerdings weniger, die KI als Sprachassistenten zu verwenden, sondern vielmehr zur Entwicklung von Abläufen, Skripten, grafischen Oberflächen sowie allgemein zur Pflege und Weiterentwicklung der Funktionen der Haustechnik.

Meine Frage ist daher, ob sich der von dir entwickelte MCP-Server für solche Aufgaben eignet oder ob dafür ein anderer Ansatz notwendig wäre.

Im Übrigen verwende ich Codex-5.5 von OpenAI, da ich über meinen Arbeitgeber Zugang zu einem API-Schlüssel habe.

Vielen Dank im Voraus für jeglichen Input.