Was Claude selbst zu meiner Aufgabestellung sagt:
Kurz gesagt: Ja, das geht
Dein Vorgehen funktioniert, wenn man es in Schritte aufteilt. Den Teil, der Zeit frisst, kann Claude gut übernehmen: Doku und Forum zusammentragen und bewerten, Varianten bauen, Skripte schreiben und Fehler korrigieren. An zwei Stellen muss man aber mit Absicht vorgehen: wie die Daten zu Claude kommen (wegen der Zugangsdaten), und wo die Test-Visus wirklich angezeigt werden.
1. Das Zugangsdaten-Problem lösen: Export mit Whitelist statt Komplettdump
Du gibst Claude nicht die ganze Symcon-Datenstruktur. Stattdessen schreibt Claude ein PHP-Exportskript, das du in Symcon ausführst. Das Skript holt nur, was für die Visu gebraucht wird:
-
Objektbaum: IDs, Namen, Typen, Parent, Position, Icons, Links und Ziele
-
Variablen: Typ, Profil bzw. Darstellung, aktueller Wert (wenn gewünscht), Aktionsskript ja/nein
-
WebFront-Konfiguration: Items, Splitpanes, Kategorien, also die Struktur deiner Raum- und Gewerke-Sicht
-
Instanzen: nur Modulname und Modul-ID, keine Instanzkonfiguration (dort liegen API-Keys, Passwörter und Tokens)
-
Skripte: nur der Name, kein Inhalt
Zusätzlich gibt es einen Filter, der alles mit pass|token|secret|key|user|mail maskiert. Heraus kommt eine JSON-Datei, die du vor dem Weitergeben selbst durchsiehst. Damit hast du die Kontrolle, und Claude bekommt trotzdem alles, was es für die Visu braucht.
Direkten Zugriff per JSON-RPC würde ich zunächst nicht geben. Wer dort PHP ausführen kann, hat volle Kontrolle über die Anlage. Später ginge das mit einem Testsystem, dazu unten mehr.
2. Ablauf in Phasen
Phase A: Bestandsaufnahme und Recherche
-
Claude liest den Export und baut daraus ein Modell: Räume × Gewerke, welche Geräte, welche Variablentypen.
-
Dann recherchiert es gezielt für deine Geräte: Was bringen die Viessmann- und Miele-Module schon an Kacheln mit? Welche Community-Kacheln (HTML-SDK) gibt es im Module Store und im Forum? Welche Features der Kachelvisu kamen in den letzten Versionen dazu?
-
Ergebnis ist ein kompakter Katalog mit Bewertung („passt zu deinem Bedarf“, „aktiv gepflegt?“, „Aufwand“), statt 200 Forenseiten.
-
Wichtig: Dieser Schritt muss mit Webrecherche laufen. Die Kachelvisu entwickelt sich schnell, und Wissen aus dem Training reicht dafür nicht.
Phase B: Strukturvorschlag
-
Abbildung deiner Zweiteilung auf die Kachelvisu, zum Beispiel: Startseite mit Raumkacheln (kompakt) und daneben Gewerke-Kacheln (Heizung, Media, Webdienste) mit Unterseiten für die Details.
-
Als Diagramm bzw. Tabelle zum Abnicken, bevor irgendetwas gebaut wird.
Phase C: Designvarianten
Hier liegt der Knackpunkt: Die Kachelvisu wird von Symcon gerendert. Es gibt drei Wege, abhängig vom Ziel:
| Weg |
Wie |
Vorteil |
Nachteil |
| HTML-Mockups |
Claude baut klickbare Nachbauten deiner Bildvorlagen im Browser |
sehr schnell, viele Varianten |
nicht originalgetreu, die echten Kacheln sehen anders aus |
| Echte Test-Visu |
Skript legt eine separate Test-Kategorie und eine eigene Visualisierungsinstanz mit Dummy-Variablen an |
echtes Rendering, eindeutig |
braucht Symcon, langsamere Iteration |
| HTML-SDK-Kacheln |
eigene Kacheln als HTML/JS, standalone im Browser mit Mock-Daten entwickelt, danach als Modul verpackt |
volle Gestaltungsfreiheit, z. B. für Viessmann/Miele |
Wartungsaufwand, eigenes Modul |
Meine Empfehlung: Mockups nur zur groben Richtungswahl. Danach echte Test-Visus. HTML-SDK nur dort, wo die Standardkacheln deine Vorstellung nicht treffen.
Phase D: Umsetzung
-
Ein idempotentes Aufbauskript: Es legt die neue Kachelvisu-Struktur in einer eigenen Kategorie an, mit Links auf deine bestehenden Variablen.
-
Das alte WebFront bleibt unangetastet und läuft parallel weiter. Rückgängig machen heißt: Kategorie löschen.
-
Bei Änderungen wird das Skript angepasst und neu ausgeführt, statt die Visu von Hand zu bearbeiten. So bleibt die Konfiguration nachvollziehbar.
3. Wie die automatische Test- und Korrekturschleife hier aussieht
Am besten funktioniert das, wenn Claude das Ergebnis selbst sehen kann:
-
Claude erzeugt das Skript, du führst es aus (oder Claude per JSON-RPC auf einem Testsystem).
-
Claude öffnet die Test-Visu im eingebauten Browser (lokale IP, nur Lesezugriff), macht einen Screenshot und vergleicht mit der Vorlage.
-
Claude korrigiert, und es geht in die nächste Runde.
Für ein wirklich autonomes Arbeiten gibt es eine saubere Variante: ein zweites Symcon als Testsystem (z. B. Docker oder Raspberry Pi), das nur die per Skript erzeugte Dummy-Struktur enthält und keine echten Geräte und Zugangsdaten. Dort kann Claude frei arbeiten. Erst das fertige Aufbauskript läuft dann auf deinem Produktivsystem. Ob und wie deine Lizenz ein Testsystem abdeckt, müsstest du prüfen.
4. Realistische Grenzen
-
Symcon-API-Details: Claude kennt die API grundsätzlich, wird sich bei einzelnen Funktionsnamen oder Parametern (vor allem neu bei Darstellungen bzw. Kachelvisu) aber manchmal irren. Die Testschleife fängt das ab. Ohne Testschleife wird es mühsam.
-
Von der Bildvorlage zur Kachel: Standardkacheln haben ein festes Aussehen. Einen „Look“ wie auf einem Pinterest-Bild bekommt man nur mit HTML-SDK, und das ist dann eigener Code, den du pflegen musst.
-
Community-Code bewerten: Claude kann einschätzen, ob ein Modul gepflegt wird und zu deinem Bedarf passt. Ob ein Modul auf deinem System sauber läuft, zeigt aber nur der Test.
-
Fuzzy ist okay: Dein Ansatz („grobe Richtung, dann Alternativen zur Auswahl“) passt gut zu dieser Arbeitsweise. Wichtig ist nur, dass es nach Phase B eine verbindliche Struktur gibt, sonst dreht man sich bei den Designs im Kreis.
5. Vorschlag zum Einstieg: kleiner Pilot
Nicht gleich alles umbauen, sondern ein Raum plus die Heizungsseite (Viessmann). Daran testest du den gesamten Ablauf: Export → Recherche → 2–3 Varianten → Aufbauskript. Danach weißt du, ob die Qualität passt, bevor der Rest dran ist.
Konkret wäre der erste Schritt: Claude schreibt das bereinigte Exportskript. Dafür bräuchte ich deine Symcon-Version (7.x oder 8.x, wegen Profilen bzw. Darstellungen) und die Info, ob das Skript Variablenwerte mit exportieren soll oder nur die Struktur.
~~~~
Nachtrag: Da ich keine Lust auf manuelles Copy & Paste habe und Claude Code vieles autonom erledigen soll scheint der Weg über einen hierfür von Claude erstellten MCP-Server zu sein, der die Sicherheitsaspekte implementiert: ipsymcon-mcp-server von Schimmilab forken und absichern (Whitelist, Secret-Filter, Schreiben nur in der Zielkategorie).
Ich bin von meiner Formulierung etwas einseitig 
