IPS MQTT Fehlermeldung

Ich habe vor einiger Zeit meinen MQTT-Broker auf dem Raspberry gelöscht und auf IPS umgestellt.
Leider habe ich das Problem, dass die Schaltvorgänge teilweise extrem verzögert ausgeführt werden.
Die Verzögerung spielt sich im Bereich von 5 Sekunden und mehr ab.
Konkret bedeutet das beim schalten von Licht, dass man dann schon mal längere Zeit im Dunkeln steht.
Das Problem hatte ich vorher nie.
Da ich aber auch Geräte erweitert habe, kann ich nicht beurteilen, ob dies mit dem IPS-MQTT-Server zusammenhängt oder nicht.
Die Anzahl der Geräte ist mit 9 Stück relativ gering, von daher kann es nicht kommen.

Auffallend ist eine Fehlermeldung, die ich ab und zu erhalte:
MQTT Fehler.JPG

Hat jemand das gleiche Problem, bzw. eine Idee, woran es liegen kann?

Danke!
Peter

Keiner eine Idee bzw. schon mal das gleiche Problem gehabt?

Magst du mal im Debug vom MQTT Server schauen wann die Pakete kommen? Evtl. findest du dadurch die Ursache.

paresy

Hallo paresy!

Ich habe ein kleines Skript geschrieben, welches den Kanal 1 meines Sonoff 4CH einschaltet und mittels IPS_Sleep nach 2 Sekunden wieder ausschaltet.

Wenn ich im Debug mitlese, passiert folgendes:

Teilweise schaltet das Gerät sofort und auch nach den 2 Sekunden wieder aus (so wie es soll), führe ich die Aktion gleich wieder durch, kommt im Debug der Schaltvorgang verzögert und auch Sonoff schaltet verzögert. Die Ausschaltzeit ist dann deutlich über den 2 Sekunden wie du im Screenshot sehen kannst. Das geht soweit, dass es zum Teil 5 Sekunden und länger dauert, bis der Befehl ausgeführt wird.
Diese Situation hatte ich bei Verwendung des Raspberry MQTT Servers nie.

MQTT Verzögerung1.JPG

Woran kann das liegen?

@paresy

Habe leider noch keine Antwort erhalten und mein Problem besteht nach wie vor.
Ich musste gerade den Dienst komplett neu starten, um MQTT überhaupt wieder zum laufen zu bekommen.
Debug von allen relevanten Objekten (MQTT Server, Server Socket und Shelly-Aktor) habe ich protokolliert.
Wenn ich über ein Skript den Shelly-Aktor schalten, kommen bei allen drei Daten rein, aber der Aktor schaltet nicht.
Gleiches wenn ich es mit „Befehl testen“ versuche.
Lediglich über die Shelly-App und über den Browser lassen sich alle meine MQTT-Geräte wie Shelly und Sonoff problemlos schalten.
Teilweise funktioniert es, aber mit extremer zeitverzögerung.

Diese Probleme hatte ich mit Mosquitto am Raspberry nie, jedoch weiß ich nicht, ob dies durch eventuelles hinzufügen von Geräten entstanden ist.

Bitte um Hilfe, denn so wie es jetzt läuft, kann es definitiv nicht bleiben!

LG Peter

Hallo Peter,

wir haben über 25 MQTT Module(Shelly und Tasmota) und das klappt mit KaiS Modulen an dem MQTT Server gut.
Ab und an habe ich auch mal eine Zeitverzögerung, aber die bewegt sich im Bereich 1-2 Sekunden, und da suche ich auch noch.
Das passiert hier aber auch nur sporadisch.
Das hatte ich so mit dem Mosquitto und KaiS’s seinen Modulen früher nicht bemerkt.
Blinklicht mit IPS(als Zeitgeber) und einem Tasmota Modul habe ich auf dem Dachboden am laufen (3 Sekundentakt), wenn ich mal Abends nachschaue, scheint es zu laufen. Ja, hatten Besuch auf dem Dachboden, Waschbären hatte sich dort niedergelassen,
Mal sehen, ob es etwas hilft.

Ich habe gerade mal aus dem Webfront meine 3 Fachsteckdose hier im Büro durchgeschaltet, wenn ich draufklicke kommt der Schaltbefehl sofort an und die Anzeige passt. Ab und an dauert es dann mal 1-2 Sekunden, aber wie gesagt, nicht immer.

Ok IPS läuft hier auf einem Tinkerboard (hat etwas mehr Dampf als der Pi2 oder 3) und ich habe auch die IPS Spezialschalter mal geändert, und die Thread Count, Thread Queue Limit erhöht, OPcache Support aktiv gesetzt.

Ansonsten kann ich dir nur anbieten, mal gemeinsam auf dein System per Anydesk und Telefon zu schauen, wird aber erst ab Freitag gehen.
Und nein, ich mache das nicht mehr beruflich, ist ein rein, User helfen Usern.
Noch ein Tipp, wenn du noch einen Pi2(lieber 3) zum testen über hast, einfach mal da IPS als Testsystem drauf werfen, und nur den MQTT Server mit einigen Tasmota oder Shelly Modulen probieren.

Hallo Thomas,

danke für dein Angebot der Unterstützung, welche ich gerne annehme.
Freitag bin ich zuhause und geht bei mir. Schicke mir per PN deine Nummer, dann rufen wir uns zusammen.

Zum Problem:
Ich habe jetzt intensiv versucht, dem Problem auf die Spur zu kommen.
Im Augenblick funktioniert gar keine Kommunikation per MQTT. Ich habe den Debug des MQTT Server Sockets mitschreiben lassen und bin auf eine merkwürdige Situation gestoßen. Wenn ich irgend ein Geräte schalte, also Shelly oder Sonoff, wird ein Transmit-Befehl mit der jeweiligen IP des Geräts ausgegeben, aber zugleich der gleiche Befehl mit einer IP die ich weder wo hinterlegt habe noch in der Liste der aktiven Geräte in meinem Modem finde.
Wie dies zustande kommt, ist mir unerklärlich.
Nach Prüfung des Log-Files habe ich festgestellt, dass heute um 12:22 Uhr die gesamte Kommunikation des MQTT-Servers gestoppt wurde. Dies zeigen auch die Shelly-Geräte, da um 12:22 Uhr die letzte Aktualisierung war.
Im Status-Dialog fand ich folgende Meldung:

06.10.2019, 12:22:32 | Server Socket | remote_endpoint: Der Socket ist nicht verbunden

Woher kann das kommen?

LG Peter

Hallo Peter,

ich werde das Problem erst mal mit Kai nach unserem telefonat besprechen.
Denn es scheint so, wir haben die gleichen Beobachtungen gemacht, nur bei mir sind die weniger kritisch.

Hallo Thomas,

war ein informatives Gespräch!

In der Zwischenzeit konnte ich noch folgendes testen/feststellen:
Wenn ich bei meinem Sonoff-Gerät über den Web-Browser die 4 Kanäle ein- und wieder ausschalte, funktioniert alles.
Wenn ich dies öfters hintereinander durchführe, werden die Schaltvorgänge extrem träge und es taucht das gleiche Problem auf, wie bei meinen anderen MQTT-Geräten (Shelly).
Schalte ich die MQTT-Funktion aus (löschen der hinterlegten IP-Adresse des IP-Symcon-Servers), kann ich so schnell schalten wie ich will, die Schaltvorgänge werden im Bruchteil einer Sekunde durchgeführt und es wird auch nie träge.

Weiters ist mir aufgefallen, dass mit eingeschaltetem MQTT-Dienst ab irgendeinem Zeitpunkt, im Meldungsfenster die Server-Verbindung geschlossen wird und danach die Meldung einer eingehenden Verbindung kommt.
Dies wiederholt sich dann regelmäßig.

MQTT Fehler2.JPG

Um auszuschließen, dass es am WLAN liegt, habe ich für den Versuch ein eigenes Netz mit einem einzigen Gerät aufgebaut.

Ich spreche morgen mal mit meinem Dad.
Vielleicht können wir dann ja etwas rausfinden. Evtl. kann ich dann ja auch @paresy ein paar Infos zukommen lassen.

Grüße,
Kai

Gesendet von iPhone mit Tapatalk

Danke Kai, das wäre sehr nett.
Im Augenblick hab ich keinen Rat mehr, an was es liegen kann.

LG Peter

Wenn ich bei meinem Sonoff-Gerät über den Web-Browser die 4 Kanäle ein- und wieder ausschalte, funktioniert alles.
Wenn ich dies öfters hintereinander durchführe, werden die Schaltvorgänge extrem träge und es taucht das gleiche Problem auf, wie bei meinen anderen MQTT-Geräten (Shelly).
Schalte ich die MQTT-Funktion aus (löschen der hinterlegten IP-Adresse des IP-Symcon-Servers), kann ich so schnell schalten wie ich will, die Schaltvorgänge werden im Bruchteil einer Sekunde durchgeführt und es wird auch nie träge.

Moin Peter,

habe das gerade mal an einer Sonoff 4 fach Steckdosenleiste probiert, aber MQTT Server eingetragen gelassen.
Wenn ich über den Web-Browser einen Kanal im Sekundentakt ein/aus schalte, werden die Schaltvorgänge nicht träge.
Die letzten Daten von der Sonoff Konsole :

07:47:52 SRC: WebGui from 10.10.0.20
07:47:52 MQT: stat/sonoff091/RESULT = {"POWER3":"ON"}
07:47:52 MQT: stat/sonoff091/POWER3 = ON
07:47:52 SRC: WebGui from 10.10.0.20
07:47:52 MQT: stat/sonoff091/RESULT = {"POWER3":"OFF"}
07:47:52 MQT: stat/sonoff091/POWER3 = OFF
07:47:53 SRC: WebGui from 10.10.0.20
07:47:53 MQT: stat/sonoff091/RESULT = {"POWER3":"ON"}
07:47:53 MQT: stat/sonoff091/POWER3 = ON
07:47:53 SRC: WebGui from 10.10.0.20
07:47:53 MQT: stat/sonoff091/RESULT = {"POWER3":"OFF"}
07:47:53 MQT: stat/sonoff091/POWER3 = OFF
07:47:54 SRC: WebGui from 10.10.0.20
07:47:54 MQT: stat/sonoff091/RESULT = {"POWER3":"ON"}
07:47:54 MQT: stat/sonoff091/POWER3 = ON
07:47:54 CFG: in Flash gespeichert am F7, zählen 1353, Bytes 4096
07:47:55 SRC: WebGui from 10.10.0.20
07:47:55 MQT: stat/sonoff091/RESULT = {"POWER3":"OFF"}
07:47:55 MQT: stat/sonoff091/POWER3 = OFF
07:47:56 CFG: in Flash gespeichert am F6, zählen 1354, Bytes 4096
07:47:56 HTP: Konsole

Aber wenn ich so schnell hintereinader vom Web-Browser schalte, kommen die Daten auch mal bis zu 5 Sekunden später in IPS an.

Kurzes Feedback: Ich habe das Thema auf dem Schirm :slight_smile:

Nur noch keine Zeit gehabt genauer reinzusehen, da ich noch nicht weiß, wie ich das gut nachstellen kann.

paresy

Moin paresy,

ich kann dir ne Testumgebung bereitstellen.

Grüße,
Kai

Gesendet von iPhone mit Tapatalk

Moin paresy, moin Kai!

@Kai
Das Problem besteht tatsächlich nicht erst, wenn ich schnell hintereinander schalte, sondern bereits bei einfachen, einmaligen Schaltvorgängen. Zum Beispiel habe ich eine ShellyS zum ein- und aussschalten des Fernsehers und des Receivers. Im Hintergrund steht ein Skript, welches den Stromverbrauch prüft und aufgrund dessen dann per AIOGateway nur den Fernseher oder nur den Receiver oder beides aktiviert bzw deaktiviert.
Wenn es jetzt zu Verzögerungen im MQTT Protokoll kommt, stimmen die zeitlichen Abläufe zum AIOGateway nicht mehr zusammen.
Teilweise kommt es vor, dass Befehle mit extrem langer Verzögerung ankommen.
Dies ist speziell beim Schalten von Licht sehr ärgerlich.

@paresy
Wie kann ich euch bei der Fehlersuche unterstützen? Benötigt ihr einen Debug-Auszug?

LG Peter

EDIT: Im Moment kann ich per MQTT gar nichts schalten. Die Debug des Aktors und des MQTT Servers geben die Meldung sofort aus. Debug des MQTT Server Socket gibt keine Meldungen aus und ist tot.

@Loewenkoenig: Magst du in den PHP Informationen einmal schauen, ob dort ggf. etwas „fest“ hängt und die Verzögerung auslöst wenn du schaltest?

paresy

Nein, hängt nichts. Hab grad nachgesehen.
Im Moment geht bei mir gar kein MQTT. Wenn ich den Dienst neu starte, dann funktioniert es sicher wieder.
Hab dies bewusst jetzt nicht durchgeführt, damit du eventuell etwas prüfen/testen kannst.
Auffallend ist, dass die Verbindung immer wieder mal geschlossen wird und auch Fehlermeldungen des Server Sockets zu finden sind.
Diese variieren aber in der Meldungsart.

11.10.2019, 17:50:44 | Server Socket | remote_endpoint: Der Socket ist nicht verbunden

Habe ich eine Möglichkeit bei dir (wenn der Fehlerzustand da ist) einmal rauf zu schauen? Magst du mir eine PM schicken wann du Zeit hättest?

paresy

Sicher, kein Problem.
Du hast in kürze meine Kontaktdaten per PM.

LG Peter

Kurzes Feedback: Es lag einfach an der Menge der MQTT Geräte/Nachrichten pro Sekunde die der Pi (mit den PHP Modulen hinten dran) einfach nicht mehr sauber verarbeiten konnte. Ich habe dann den OpCache Spezialschalter aktiviert (wodurch die Skripte gecached werden und somit wesentlich schneller ausgeführt werden können) und das Problem ist verschwunden :slight_smile:

Für alle die Latenzen auf einem „Pi“ System haben -> Schaut mal bitte ob es hilft, wenn ihr den OpCache Spezialschalter aktiviert.

paresy