Hi,
ich habe seit einigen Tagen das Problem, dass sich die Konsole “aufhängt”.
Als Meldung kommt: “Konnte Skript nicht ausführen JSON parsing failed: “ dahinter steht noch “Verbindungsfehler
JSON parsing failed:
Die Verwaltungskonsole wird sich neu verbinden sobald der Symcon Server wieder verfügbar ist.”
Ich finde einfach keinen Fehler. In diesem Fall wollte ich ein Matter Gerät anlernen. Im vorigen einer manuell angelegten Variable ein Profil zuordnen. Davor ein PHP Script speichern. usw…
Also immer andere Aktionen, alles aber strukturverändernde Operationen.
Solange ich nicht mit den Variablen bzw Skripten oder dergleichen mache, funktioniert das System einwandfrei.
Symcon läuft als Docker auf einem Raspberry Pi 5.
Symcon 9.0, Raspberry Pi (Docker) (arm64), 15.06.2026, f2880badc0d6
Nachdem ich zwei Tage mit Claude Fehler gesucht habe, hier auch seine (ihre?) Zusammenfassung dazu:
(Profile/Skripte/Events/Verschieben/Instanz-Erstellung) hängen den Kernel-Prozess auf (Deadlock, kein Crash)
Umgebung
- IP-Symcon 9.0 (Rev. f2880badc0), Docker-Image symcon/symcon:stable
- Host: Raspberry Pi (Debian), Docker-Compose-Stack „symcon“
- Zugriff: Web-Konsole (Port 3777) sowie PHP-API (IPS_* Funktionen) über MCP-Automatisierungs-Tools
Symptom
Bestimmte strukturverändernde Operationen am Objektbaum lassen Symcon für mehrere Minuten komplett unerreichbar werden (Web-Konsole UND API), bevor es sich selbst erholt oder ein manueller Neustart nötig wird.
Reproduzierte betroffene Operationen
IPS_CreateVariableProfile()(neues Variablenprofil anlegen)IPS_CreateScript()(neues Skript anlegen) — reproduziert sowohl per API als auch manuell in der GUI- Bearbeiten/Speichern eines bestehenden Skripts in der GUI
IPS_SetName()auf ein Event-ObjektIPS_GetVariableProfileList()bzw. Öffnen der Profilauswahl-Dropdown in der GUI (Standardprofile wie~UnixTimestampbetroffen, nicht nur neue Profile)- Verschieben/Reparenten einer Variable in der GUI
- Klick auf „Instanz erstellen“ im Hardware-Konfigurator
Nicht betroffene Operationen
GetValue()/SetValue()IPS_CreateVariable()IPS_CreateCategory()IPS_VariableProfileExists()(gezielte Abfrage nach Namen)IPS_ObjectExists(),IPS_GetObject(), allgemeine Lesezugriffe
Wichtiger Befund: kein Crash, sondern Hänger
- Kein Fataler Fehler/Exception im Symcon-Anwendungslog (
docker logs) zum Zeitpunkt des Ausfalls - Kein Segfault in
dmesg - Kein OOM-Kill (
docker inspect→OOMKilled=false) - Docker-Container-
StartedAtbleibt bei manchen Vorfällen unverändert — der Container selbst restartet nicht, nur der interne IPS-Kernel-Prozess wird unresponsive - Bei mindestens einem Vorfall lieferte die API die Fehlermeldung
IPS Fehler [-43002]: Server is shutting down, danach war die Symcon-eigene „Laufzeit“ (system_info) auf 0 zurückgesetzt — deutet auf einen internen Selbst-Neustart-Mechanismus hin, unabhängig vom Docker-Container - Erholung erfolgt nach 1–10+ Minuten von selbst, oder erfordert manuellen Container-Neustart
Arbeitshypothese
Deadlock im IPS-Kernel bei Operationen, die einen umfassenderen Objektbaum-Rebuild/Recompile auslösen (z. B. IPS_ApplyChanges-artige Neukonfiguration aller abhängigen Instanzen). Möglicher Zusammenhang mit einem hängenden/fehlerhaften Modul: im Kernel-dmesg finden sich unabhängig davon zahlreiche wiederkehrende Verbindungsfehler eines HomeMatic-RF-LAN-Gateway-Moduls (hb-rf-eth, IP 192.168.200.224, „Error sending packet, not connected“ / „Error -101 while connecting“). Nicht verifiziert, ob dieses Modul ursächlich am Deadlock beteiligt ist — aber die zeitliche Häufung strukturverändernder Trigger deutet auf ein synchron blockierendes Modul beim Objektbaum-Update hin.
Workarounds
- Variablenprofile: einfache Integer-Variable ohne Profil verwenden
- Skripte/Events: können erstellt werden, aber jeder Versuch birgt Risiko eines mehrminütigen Hängers; nach Anlage per GUI hat Lesen/Ausführen normal funktioniert
- Keine Möglichkeit gefunden, die betroffenen Operationen zuverlässig ohne Risiko durchzuführen
