Hallo,
bei mir hängt sich der MQTT Server alle paar Tage auf. Auch ein Socket Neustart funktioniert dann nicht (wenn ich auf Änderungen übernehmen gehe, läuft das „IPS-Wartehäuschen“ endlos), vielmehr muss ich den Dienst (Docker-Container) neu starten. Das Debug ist leider leer, so dass ich damit nicht dienen kann.
Hat jemand eine Idee, wo der Fehler liegt und wie er zu beheben ist?
Viele Grüße…
Ein bisschen mehr Anhaben wären allenfalls hilfreich zum eingrenzen des Problemes…
Was macht dich sicher, dass sich der MQTT Server aufhängt?
Kommen nur da keine Daten und alles andere läuft fehlerfrei?
Hast du eine Kamera-Stream?
Läuft dieser wenn das Problem auftritt?
Ich kenne aktuell nur die Thematik mit dem Stream, und auch da lässt sich der Dienst nur noch killen, normal beenden geht nicht.
Welche symcon Version? Mit SSL?
paresy
Danke Ihr beiden.
Es ist Symcon 8.0 und ohne SSL.
Nach dem Aufhängen kommen/gehen von allen/zu allen Clients (u.a. zB FullyKiosk, Linktap) keine Daten mehr (auch vom MQTT Explorer kann ich keine Verbindung mehr herstellen). Wenn ich dann für einen Socket-Neustart in der Instanzenkonfiguration „Aktiv“ ausschalten möchte, läuft das „IPS-Wartehäuschen“ endlos - weder so manuell noch per Skript lässt sich der Server Socket neu starten.
Einen Kamera-Stream habe ich nicht.
VG!
wie viel MQTT-Devices hast du am Start ? kannst du die evtl auf 2 oder mehr Ports aufsplitten ?
Bei mir laufen zB Shellies auf 1883, NSPanel 1885, ESPs auf 1886 usw. (natürlich musst du die Devices auch ändern)
Wenn du einen (mehrere) Port(s) deaktivierst, kannst du schonmal eingrenzen, wo der Fehler herkommt
Danke, das ist ein guter Hinweis. Wenn ich es richtig verstehe, brauche ich dann JEWEILS auch einen eigenen Konfigurator. Wie bekomme ich denn die bestehenden Variablen von dem einen in den anderen Server?
nö, nur mehrerere Splitter und Server (I/O), ich mache alles manuell ohne Konfigus
aber immer korrekt das Gateway verbinden, sonst hast du einen Knoten drin.
Zugangsdaten kannst du identisch lassen, also nicht ändern
Ich versuche es gerade mal mit dem Fully. In den Settings habe ich den neuen Port… angepasst, im Server Gerät das Gateway entsprechend geändert. Nun bekomme ich in dem neuen Konfigurator zwar die ID des bestehenden Servergeräts angezeigt, es kommen aber keine Daten an?!? Wenn ich auf „prüfen“ gehe, kommt bei aktueller Wert 4 und bei empfohlener Wert 1 - ich habe allerdings keine Ahnung, was das für ein Wert ist. Ich habe dennoch einmal „übernommen“, es kommen aber weiter keine Daten an…
ich habe zwar auch einen FKiosk laufen ! doch ! an MQTT angebunden
hast du nicht ein einfaches Gerät ?
Leider nicht. Ich schaffe es jetzt auch erst mal nicht weiter zu testen (insgesamt zersplittert das Vorgehen auch ganz schön). Vielen Dank aber schon einmal.
dann würde ich erstmal alles rauswerfen und eins nach dem anderen ausprobieren.
Bei mir läuft das Zeuchs stabil und schalte jeweils den Debug ein
Mit dem MQTT habe ich schon seit 2 Jahren das Problem, dass er sich aufhängt. Mal nach 2 Tagen, mal nach 2 Wochen. Der Ganze Server (Ubuntu) lässt sich dann auch nicht mehr neu starten und ich muss ihn vom Strom nehmen.
Ich habe mittlerweile neue MQTT Server angelegt mit unterschiedlichen Ports aber habe immer noch nicht herausgefunden warum der originale Server immer die Probleme macht. Mit den neu angelegten Servern habe ich noch keine Probleme gehabt, wenn ich das richtig beobachtet habe.
ich würde einfach ALLES killen und komplett neu aufbauen, da hängt bestimmt irgendwo ein Bit 
quer
Das könnte sich als recht umfangreich erweisen:
Bevor ich das neu aufbaue lebe ich lieber mit ein paar Neustarts. Außer dem einen MQTT Server funktioniert das ganze System ja weiterhin normal. Nur wenn es hängt, lässt sich der Dienst nicht mehr abschalten/neustarten und deshalb wahrscheinlich auch das Betriebssystem nicht neu booten.
Und, wie gesagt, seit ich alle Geräte auf die beiden anderen Server mit anderen Ports umgestellt habe, habe ich kaum mehr Probleme.
Wenn es mal wieder passiert ist, kannst du ja mal versuchen mit dem Debugger einen Snapshot der ganzen Threads zu machen: Debugging für Experten (Raspberry Pi, Linux, SymBox) Evtl. gibt es irgendwo einen Deadlock, den ich dann finden könnte.
paresy
Das betrifft aber das ganze System (1692), ich meinte nur, alles was mit MQTT zutun hat
Naja, was gibt´s na neu einzurichten? Ich kann ja nur die Server und die dazugehörenden Sockets neu anlegen. Anschließend die Geräte an die neuen Ports senden lassen. Das habe ich ja schon gemacht.
Hättest du noch andere Ideen, was man neu machen könnte?
Hi,
Ich sehe durch zufall das du ovms nutzt. Auch mit ssl zertifikat? In irgend einer 7er versuon gab es probleme, die aber gefixt wurden.
Lässt du dir alle daten schicken vom ovms?
Falls ja, lese dir mal hier den punkt wissenswertes durch.
Ich müsste mal selber nachsehen was ich weglasse (auf jedenfall die events mit den uhrzeiten und nich ein paar speziellere).
Ich habe zwei ovms und die senden sonst locker 250-300 datenpunkte pro! Gerät.
Ich muss aber sagen, dass das super stabil läuft mit dem symcon mqtt.
Viele grüsse
Insgesamt bleibt festzuhalten, dass die Probleme mit dem MQTT-Server keine Einzelfälle sind. Irgendwo muss das Problem also in der IPS-Umgebung liegen.
Ich habe zuletzt Shellies mit dazu genommen über das IPS-Shelly-Modul - vielleicht liegt das Problem hier irgendwie (?!?). Kai arbeitet ohnehin an einer neuen Version des Moduls, ich warte hier mal ab…
Vielleicht hilft diese Info, falls nicht, bitte einfach ignorieren!
Ich habe den internen Symcon MQTT Server ohne SSL laufen und zusätzlich noch zwei Mosquittos.
Bei mir läuft auch ein NSPanel mit dem NSPanel Lovelace UI Modul von Kai Schnittcher - Danke für das Modul an dieser Stelle!
Das NSPanel nutzt den MQTT-Broker von Symcon. Ich wollte das auch den Mosquitto umstellen, das NSPanel hat damit kein Problem - aber sobald ich im Symcon beim NSpanel das Gateway - also den MQTT-Broker - ändere, steht mein Symcon, braucht dann einen Neustart und ich muss dann möglichst schnell das NSPanel wieder auf den Symcon-internen Broker umstellen, sonst steht der Symcon innerhalb kürzester Zeit erneut.
Weiter getestet habe ich dann nicht, sorry. War halt schon recht nervig, wenn man nicht mal mehr Licht ausschalten kann. Einschalten is ja net so schlimm - gehöre als IT’ler ja zum lichtscheuen Gesindel ^^
Könnte also auch die Gateway-Implementierung betreffen, evtl. hat der interne MQTT-Broker ja gar kein Problem.
Wie geschrieben - nur als Zusatzinfo, fundierte Belege habe ich leider nicht. Falls unbrauchbar, bitte ignorieren! 
