Hallo zusammen, ich habe seit Update auf Config/App 17.1 versucht, den neuen nativen MCP-Server meines Miniserver Compact mit Claude (Anthropic) zu verbinden, um KI-gestützte Auswertungen meines Smarthomes (v.a. PV/Speicher-Daten) zu machen. Dabei bin ich auf mehrere Probleme gestoßen und wollte fragen, ob jemand ähnliche Erfahrungen hat oder weiß, wie der offizielle Weg korrekt funktioniert.
Setup:
Miniserver Compact, Firmware + Config/App auf 17.1
MCP-Server-Objekt in Config angelegt, eigener Loxone-Benutzer mit eingeschränkten Rechten für die KI erstellt
Ziel: Anbindung an Claude Desktop (Windows)
Problem 1 – MCP-Verbindung:
Beim Aufruf der über die App kopierten connect.loxonecloud.com/.../mcp-URL im Browser bzw. beim Eintragen in Claude Desktop bekomme ich durchgehend error: unauthorized.
Die interne/externe URL in den Eigenschaften des MCP-Server-Objekts bleibt leer, auch nach mehrfachem Programmieren.
Laut Doku soll die Verbindung über einen Login mit einem dedizierten Loxone-Benutzer laufen (least privilege) – aber es öffnet sich kein Anmeldefenster, weder in Claude Desktop noch im Browser.
Frage: Muss ich zwingend Claude Desktop verwenden, oder funktioniert das auch mit der Web-Version (claude.ai)? Und wie sieht der korrekte OAuth-Flow konkret aus – wo genau meldet man sich mit dem Loxone-User an?
Problem 2 – CPU-Auslastung von 7-8% auf 25% gestiegen:
Zeitlich ungefähr im selben Zeitraum wie meine MCP-Versuche ist die Dauerauslastung meines Miniservers von üblichen 7-8% auf 25% gesprungen und bleibt dort dauerhaft.
Ich habe das MCP-Server-Objekt zwischenzeitlich wieder komplett entfernt – Auslastung blieb unverändert bei 25%.
Parallel bekomme ich seit ca. 2 Wochen wiederkehrende, sporadische Modbus-Fehlermeldungen von meinem MTEC-Energiespeicher (Battery Management System Warning Code, Fault Flag 1/2, Running State – "seit einiger Zeit keine Daten empfangen"), obwohl die Werte selbst beim Reinschauen unauffällig sind (SoC, Spannung, Temperatur alles im Normalbereich).
Im Debug-Log fand ich wiederholt den Eintrag: "PRG Remotebusserver MTEC unexpected transaction ID"
Ich habe daraufhin die Abfragezyklen der MTEC-Sensoren entzerrt (nicht mehr alle im 60s-Takt) und das Timeout von 2000ms auf 5000ms erhöht – bisher ohne sichtbare Besserung bei der Auslastung.
Testweise die MTEC-IP-Adresse auf ungültig gesetzt (Verbindung praktisch gekappt) – Auslastung blieb bei 25%, obwohl MTEC dadurch nicht mehr erreichbar war.
Meine Fragen an die Community:
Hat schon jemand den nativen MCP-Server erfolgreich mit Claude verbunden? Wie genau lief der Auth-Flow ab?
Kennt jemand das "unexpected transaction ID"-Problem bei MTEC-Wechselrichtern über Modbus TCP, und was war die Lösung?
Gibt es eine Möglichkeit, in der Miniserver-Weboberfläche oder Config genauer zu sehen, WAS konkret die CPU-Last verursacht (Prozess-Aufschlüsselung), statt nur die nackte Prozentzahl zu sehen?
Danke schon mal für jeden Hinweis!
Setup:
Miniserver Compact, Firmware + Config/App auf 17.1
MCP-Server-Objekt in Config angelegt, eigener Loxone-Benutzer mit eingeschränkten Rechten für die KI erstellt
Ziel: Anbindung an Claude Desktop (Windows)
Problem 1 – MCP-Verbindung:
Beim Aufruf der über die App kopierten connect.loxonecloud.com/.../mcp-URL im Browser bzw. beim Eintragen in Claude Desktop bekomme ich durchgehend error: unauthorized.
Die interne/externe URL in den Eigenschaften des MCP-Server-Objekts bleibt leer, auch nach mehrfachem Programmieren.
Laut Doku soll die Verbindung über einen Login mit einem dedizierten Loxone-Benutzer laufen (least privilege) – aber es öffnet sich kein Anmeldefenster, weder in Claude Desktop noch im Browser.
Frage: Muss ich zwingend Claude Desktop verwenden, oder funktioniert das auch mit der Web-Version (claude.ai)? Und wie sieht der korrekte OAuth-Flow konkret aus – wo genau meldet man sich mit dem Loxone-User an?
Problem 2 – CPU-Auslastung von 7-8% auf 25% gestiegen:
Zeitlich ungefähr im selben Zeitraum wie meine MCP-Versuche ist die Dauerauslastung meines Miniservers von üblichen 7-8% auf 25% gesprungen und bleibt dort dauerhaft.
Ich habe das MCP-Server-Objekt zwischenzeitlich wieder komplett entfernt – Auslastung blieb unverändert bei 25%.
Parallel bekomme ich seit ca. 2 Wochen wiederkehrende, sporadische Modbus-Fehlermeldungen von meinem MTEC-Energiespeicher (Battery Management System Warning Code, Fault Flag 1/2, Running State – "seit einiger Zeit keine Daten empfangen"), obwohl die Werte selbst beim Reinschauen unauffällig sind (SoC, Spannung, Temperatur alles im Normalbereich).
Im Debug-Log fand ich wiederholt den Eintrag: "PRG Remotebusserver MTEC unexpected transaction ID"
Ich habe daraufhin die Abfragezyklen der MTEC-Sensoren entzerrt (nicht mehr alle im 60s-Takt) und das Timeout von 2000ms auf 5000ms erhöht – bisher ohne sichtbare Besserung bei der Auslastung.
Testweise die MTEC-IP-Adresse auf ungültig gesetzt (Verbindung praktisch gekappt) – Auslastung blieb bei 25%, obwohl MTEC dadurch nicht mehr erreichbar war.
Meine Fragen an die Community:
Hat schon jemand den nativen MCP-Server erfolgreich mit Claude verbunden? Wie genau lief der Auth-Flow ab?
Kennt jemand das "unexpected transaction ID"-Problem bei MTEC-Wechselrichtern über Modbus TCP, und was war die Lösung?
Gibt es eine Möglichkeit, in der Miniserver-Weboberfläche oder Config genauer zu sehen, WAS konkret die CPU-Last verursacht (Prozess-Aufschlüsselung), statt nur die nackte Prozentzahl zu sehen?
Danke schon mal für jeden Hinweis!
Kommentar