Symcon reagiert nicht mehr auf alles / Rückkanal?

Hallo zusammen,

seit Mittwoch bereitet mit Symcon einiges an Kopfzerbrechen.
Das letzte was noch klappte war eine Postmeldung um 2.37 Uhr nachts.
Danach kamen keinerlei Meldungen mehr an

Am Nachmittag lies sich keine Änderung mehr speichern oder löschen.
Im Endeffekt wurde es schon ausgeführt, aber erst nach dem Symcon Neustart.

Es folgte eine Odyssey mit mehrmaligem Raspberry neu installieren und Backup einspielen. Auch der Raspberry 4 wurde duch einen anderen Raspberry 4 getauscht.
Im Anschluss habe ich alles aus dem Store gelöscht was nicht aktiv war. Donnerstag gegen 10 Uhr ging es dann wieder flüssig.
Was mir persönlich geholfen hat war die Fehlermeldung aus dem Bild. Diese kam aber nur, da ich aus lauter Verzweiflung die Beta 5.6 installiert habe.

Und seit gestern Abend tritt der Fehler wieder auf.
Konkret heißt das:

  • Webconsole lädt „unendlich“ noch „Änderungen“ oder „Löschen“, beim Tab schließen, kann man aber speichern und das wird dann auch übernommen, aber erst später verwendet z.B. nach Symcon Dienst Neustart
  • Webfront reagiert nur auf manches, z.B. Lampen aus LCN oder Shelly gehen nur AN oder AUS, je nachdem welcher Zustand angezeigt wird. Beispiel Büro Lampe ist an. Ich kann sie ausschalten aber nicht mehr ein. Am physischen Schalter EIN und man kann wieder ausschalten.
  • Diverse Variablen werden nicht aktualisiert ( LCN, TheThingsNetwork, CMI von Technische Alternative)
  • RTSP Stream geht weiterhin
  • Alexa Skriptaufrufe funktionieren problemlos, dadurch lässt sich auch LCN wieder schalten oder Sonos wird eingeschaltet
  • Auf LCN Relais die Symcon auswertet wird nicht reagiert. Also Wert an LCN senden geht, aber von LCN dauert wohl zu lange um zu reagieren

Message Queue hab ich bereits aktiviert, werde aber nicht schlau daraus. Die Skripte laufen alle recht normal. Manche brauchen bis zu ca. 450ms. Wenn das normal ist?

Das lief jetzt die letzten Wochen alles wirklich problemlos. Auch durchtesten einiger Reolink OnVif Kameras störten Symcon nicht.
Die einzige Änderung war der Tausch eines Raspbee Moduls durch einen Conbee 2 Stick. Am Ende wurde es auch eine Neuinstallation. Das lief aber dann am Wochenende vorher gut.

Mir ist aber gleich am Mittwoch aufgefallen, dass gefühlt bei den PHP Informationen weniger Threads laufen.
Hatte die maximal Werte schon mal verdoppelt und das hat Raspberry vor über einem Jahr gut geschluckt.
Alle Raspberries im Netzverbund (3x Deconz, 1x Enocean + 1x LinHK (seit 2019 aktuell)) wurden auch erst letztes Wochenende auf den aktuellen Stand gebracht.
Ich weiß jetzt nicht mehr weiter…
Was kann ich noch tun?
Verwenden vielleicht mehrere Dienste den selben Rückkanal?

Das Debugging für Experten hab ich jetzt auch noch getestet.
„Leider“ stürzt das System nicht ab
Nach dem harten Stopp mit killal Symcon lief das System wieder 6-7 Minuten stabil und dann ist es wieder wie eingefroren. Start 15.40 Uhr und Einfrieren 15.47 Uhr
Heute früh war es ähnlich. 5.37 Uhr Start und um 6.00 Uhr etwa letzte Aktualsierungen der Variablen

Welche und wieviele Shelly Geräte hast du?
Schalte mal den MQTT Server ab und schau dann, ob das Problem weg ist.

Grüße,
Kai

Guten Morgen Kai,

ja, das war des Rätsels Lösung. Dafür schon mal vielen Dank!
Der MQTT Server scheint die Verzögerung auszulösen.
Schaltet man ihn aus läuft alles wieder flüssig.
Was kann man da machen? Infos die drüber fließen reduzieren?
Das einzige was die letzten Wochen „neu“ dazu kam, lief aber auch schon ca. zwei Wochen,
waren die Werte vom Fully Kiosk über ein Fire Tablet.

Schaltet man den Server wieder ein wird sofort verzögert. Beispiel LCN Lampe wird nicht nach Webfront schalten nicht angezeigt, schaltet man den Server wieder aus, wird es korrekt dargestellt.

Shellies:
1x Shelly 1
2x Shelly 1PM
2x Shelly Plug S
2x Shelly 2.5

So jetzt läuft es wieder.
Die Shellys waren scheinbar nicht die Übertäter.
Es war das MQTT das aus dem Fully Kiosk Tablet kam.
Das lief aber auch wie vorher beschrieben rund zwei Wochen ohne Probleme.
Danke für deine Hilfe! :slight_smile:

Mich würde interessieren, warum dies passiert.
Denn dieses Problem scheinen ja mehrere zu haben.

@paresy, können wir da irgendwie zur Fehlersuche / Ursachenforschung beisteuern?

Grüße,
Kai

Hi,

ich wollte kurz nachfragen, ob das Problem bei dir immer noch aktuell ist?

paresy

Nein, hat sich seither erledigt.
Es war das Fire Tablet / Fully Kiosk, das über das Fully Kiosk Modul UND MQTT gesendet hat.
Seit MQTT aus ist, läuft es wieder rund. Und mittlerweile laufen mehrere Geräte auf diese Art und keinerlei Probleme mehr.
Danke für die Nachfrage :slight_smile:

Danke für den Tipp.
@paresy, auch das ist wieder so ähnlich wie mit dem Shelly. Das selbe Verhalten.

Ich werde bei Gelegenheit mal MQTT bei einem Tablet einschalten.

Grüße,
Kai