Espeasy: MQTT funktioniert seit 20181008 nicht mehr

Im Jahr 20181004 hat sich Folgendes geändert:

• [sendHttp] # 1830 Zeitüberschreitung einstellen und vorzeitig beenden, wenn die Zeitüberschreitung erreicht ist
• [WiFiClient] Legen Sie das Zeitlimit fest und konfigurieren Sie es für Controller
• [Core 2.4.1] Gehen Sie von 2.4.2 zurück zu Core 2.4.1

Und im Jahr 20181006:

• [WiFi] Fügen Sie Verzögerungen zu Verbindungsversuchen in ControllerSettings hinzu

Könnten Sie vielleicht den Build 20181003 und vielleicht auch diese anderen 2 testen, um das Problem einzugrenzen?

Ich werde es versuchen, aber ich fürchte, ich werde es erst am Samstag tun können. ;-);

Haben Sie eine Vorstellung davon, wie lange es dauert, bis die MQTT-Verbindung unterbrochen wird?
Und fällt es irgendwie mit einer WLAN-Wiederverbindung zusammen?

Soweit ich sehen konnte, gab es keinen Wifi-Verlust.
Dass die MQTT-Verbindung unterbrochen wurde, war heute Morgen ziemlich schnell (10 Minuten), aber ich hatte auch Stunden nach dem letzten Eintrag vom IOBroker ...
Ich werde versuchen, heute Abend mindestens einen der drei Builds zu starten.

Nur als Scheck; Bauen Sie es selbst oder verwenden Sie nächtliche Builds?

eine andere Sache zu überprüfen:

Sind Sie sicher, dass MQTT nicht mehr funktioniert?
Mein hier zeigt nach einer Weile "Connection LOST", aber alles funktioniert immer noch mit MQTT.

Der einzige Fehler, den ich sehe, ist die Meldung "Verbindung unterbrochen", während alles noch funktioniert.
Zum Beispiel bekomme ich Betriebsminuten vom MQTT-Controller.
Nach einer Weile (zwischen 10 Minuten und 10 Stunden) sehe ich "Verbindung verloren", aber die Minuten zählen immer noch bis zum Senden über MQTT.

Greetz
Sascha

MQTT sollte eine erneute Verbindung herstellen, sobald festgestellt wurde, dass keine Verbindung mehr besteht.
Siehe auch @ Sasch600xt anderes verwandtes Problem:
https://github.com/letscontrolit/ESPEasy/issues/1873#issuecomment -431170001

Einige Builds vor 20180927, von denen Sie berichten, dass sie einwandfrei funktionieren, habe ich einen Fix für MQTT-Controller hinzugefügt, bei dem sich der MQTT-Client auf dem ESP eine neue Client-ID gibt, um zu verhindern, dass der Broker eine neue Verbindung ablehnt, wenn Der Broker geht weiterhin von einer bestehenden Verbindung von diesem Client aus und der Client glaubt, dass die Verbindung getrennt ist.

Können Sie die Timeout-Einstellung des Controllers erhöhen? Der Standardwert war 1000 ms, bevor ich diese Einstellung einführte und der erste Build standardmäßig 100 ms hatte. Später habe ich die Standardeinstellung (für neue Einstellungen) auf 300 ms geändert.
Vielleicht können Sie versuchen, es nur als Test auf 300 oder höher (nicht höher als 1000 ms) einzustellen. (egal welche Version, mindestens eine, die früher fehlgeschlagen ist)

Ich habe das gleiche Problem mit 1 (von 5) Einheiten erlebt. Ich habe ein bisschen mit den Einstellungen des MQTT-Controllers gespielt (minimales Sendeintervall, maximale Warteschlangentiefe, maximale Wiederholungsversuche und vollständige Warteschlangenaktion). Einstellungen, die jetzt für mich mit diesem Gerät funktionieren: 1000ms, 5/5 und "Älteste löschen".

Ok Nachrichten ...
Sieht so aus, als wäre es das gleiche Problem, über das blb4github vor 12 Stunden gesprochen hat. Nahm eine NEUE Einheit und es funktioniert bis jetzt ohne Probleme !!!! Sieht so aus, als hätte der "alte" Speicher- oder Zeitprobleme. Ich werde versuchen, das Timout in diesem Fall zu erhöhen ... halte dich auf dem Laufenden ;-)
Übrigens .. (Sorry .. Selfbuild mit Atom .. weil ich nicht alle Plugins will ... Aber bis jetzt ist es immer gut gelaufen ..) Ihr alle macht großartige Arbeit daran ... und soweit ich herausgefunden habe Nur dies (und daher das mit der neuesten Software) hat dieses Problem. Ich werde die Einstellungen erhöhen und Sie wissen lassen.

Grüße Peter

@fraeggle ist es möglich, hier Screenshot von guten und schlechten Modulen Systeminfo-Seiten

Und eine Beschreibung der Hardware.
Ich habe zum Beispiel das Gefühl, dass sich in letzter Zeit einige Änderungen an den Sonoff-Modulen ergeben haben.
Sonoff Basic und der S20

@fraeggle Könnten Sie vielleicht auch den problematischen Knoten vollständig
Leere Bin-Dateien sind in den Release-ZIP-Dateien enthalten.

Hallo TD-er
Ich hatte den fehlerhaften Knoten zuvor gelöscht ... Da ich die Timeout-Einstellungen auf 800 ms geändert habe
es ist stabil. Die Spannung wird alle 120 Sekunden aktualisiert.

Hardware nichts Besonderes .... weil ich immer noch auf das Eintreffen von INA219 warte .. ;-)

Grüße Peter

ups ich habe es leider geschlossen ..

Aber ich denke mit diesem "Workaroud" kann es geschlossen werden ... Ich denke wirklich, dass es jetzt ein Einheitenproblem ist.
Was denkst du darüber TD-er?

Trotzdem ist es seltsam, dass sich die Einheiten in diesem Aspekt unterscheiden.
Dies würde darauf hinweisen, dass die WLAN-Stabilität in einer Einheit schlechter ist

Ich stimme zu, aber ich denke, dass dieses Gerät einfach einen zu großen Toleranzbereich hat. Wie ich dir sagte, seit ich auf 800 ms umgestellt habe, funktioniert es gut ...
Wenn Sie damit einverstanden sind, werde ich dieses schließen, da es die Möglichkeit gibt, das Zeitlimit zu ändern.

Danke für Ihre Hilfe..

Grüße Peter

Ich fand "seit 20181007 MQTT Open Hab zeigt" Connection Lost "# 1873.
Vielleicht das gleiche Problem?
TD-er sag mir, ob ich helfen kann, indem ich Protokolle oder ähnliches erstelle ...
Verwenden von Openhab (mit IOBroker). aber bis jetzt kein Fehler nach dem Einstellen von Timeout auf 800ms

Ist der MQTT-Broker für OpenHAB, den Sie ausführen, auf einem Computer in Ihrem eigenen Netzwerk installiert oder extern?
Und wenn lokal, ist es vielleicht auf einem Computer installiert, dem Ressourcen fehlen?

Ich habe auch einen Test seit 394 Minuten bei 20181020.
Zeitüberschreitung bei 800 ms.
Manchmal wird es nach 24 Stunden oder sogar länger als getrennt angezeigt. Aber ich habe nie 2 Tage erreicht.
Und wieder funktioniert für mich alles noch, nachdem "Connection Lost" angezeigt wird. Es ist also nur die Botschaft, die mich verwirrt. ich werde dich auf dem Laufenden halten

Verbindung verloren ist nur eine Informationsmeldung, die angibt, dass die Verbindung unterbrochen wurde.
Es sollte jedoch eine neue Verbindung neu gestartet werden.
Auf der Seite sysinfo können Sie sehen, wie oft die WLAN-Verbindung unterbrochen und wiederhergestellt wurde und wie lange sie seit der letzten (erneuten) Verbindung zum Accesspoint mit WLAN verbunden ist.

Sobald die WiFi-Verbindung unterbrochen wird, wird auch davon ausgegangen, dass die MQTT-Verbindung wiederhergestellt werden muss, sodass die Verbindung zum MQTT-Broker als unterbrochen betrachtet wird.
Bis vor 4 Wochen war es möglich, dass der MQTT-Broker den neuen Verbindungsversuch nicht akzeptierte, da der Broker den Client weiterhin als verbunden ansah.
Dies kann zu unbestimmten Wiederverbindungsversuchen führen, wenn der Client weiterhin versucht, eine Verbindung herzustellen, und der Broker die Verbindung nicht akzeptiert.
Ich habe die MQTT-Client-ID bei jeder erneuten Verbindung geändert (indem ich die Anzahl der erneuten Verbindungen zur Client-ID hinzufügte), damit der Broker sie als neuen Client betrachtet.
Dies führt zu einer schnellen Wiederverbindung, wobei der Broker als einzigen Nachteil das LWT (letzter Wille und Testament) senden würde, da er davon ausgeht, dass der Client getrennt wird.

Wenn dies zu unerwünschtem Verhalten führt, kann ich es in eine neue Strategie umwandeln.
Zum Beispiel kann ich bei einem fehlgeschlagenen Wiederverbindungsversuch zuerst versuchen, eine ordnungsgemäße Trennungsnachricht zu senden.

Kurz gesagt, es gibt zahlreiche Optionen, bei denen die Verbindung zum Broker unterbrochen werden kann, und ich bin mir nicht sicher, warum sie in Ihrem Fall unterbrochen wird.
Könnte eine Zeitüberschreitung, eine WLAN-Trennung, eine unbekannte Antwort des Brokers oder ein anderer Grund sein.

OK habe es.
Sehr gute Aussage, danke.
Ich bin gerade in Minute 507 / Open HAB Controller / 800ms Timeout.
Bisher ist alles gut :)

Sollte ich das Standardzeitlimit für neue Instanzen eines Controllers auf 1000 ms zurücksetzen?

naja ...... gib mir noch 36 stunden ..... dann weiß ich besser über den fehler kommt auch mit 800ms oder nicht.

Minute 629 jetzt ohne Probleme ...

seltsam ... entdeckt nach Änderung auf 800ms folgen.
Letzter Trennungsgrund | (200) Zeitüberschreitung für Leuchtfeuer
Nummer verbindet sich wieder | 3
Was bedeutet das Beacon Timeout?
MQTT läuft noch, ist aber momentan genauso wie Sasch600txt. Aber anders als zuvor ... MQTT funktioniert immer noch
Nur der Broker sagt, dass dieser nicht verbunden ist.

Weitere Informationen zum Beacon-Frame finden Sie in Wikipedia
Kurz gesagt, der Zugangspunkt sendet regelmäßig ein Paket, das Informationen über das Netzwerk enthält.
Dieses Intervall beträgt typischerweise 100 TU (102,4 ms).
Das ESP-Modul versucht jedes Mal, dieses Beacon zu hören, aber aus einer Reihe von Gründen fehlt möglicherweise ein Beacon-Frame. Das Timeout ist länger als 100 TU, daher müssen einige dieser Beacon-Frames fehlen, um ein Beacon-Timeout zu melden.
Gründe, einen solchen Leuchtfeuerrahmen zu verpassen, sind:

• zu beschäftigt mit der Verarbeitung anderer Blockierungsaufgaben (sehr wahrscheinlich)
• Access Point sendet kein Beacon aufgrund hoher Verkehrsanforderungen anderer (abhängig von Marke / Modell / Einstellungen)
• HF-Störungen (nicht wahrscheinlich, wenn man bedenkt, wie oft dies auftritt)
• Uhrendrift (nicht wirklich wahrscheinlich)

Das "Beacon Timeout" tritt also ab und zu auf den ESP-Knoten auf.
Ich arbeite hart daran, dass jedes Plugin / Controller kurze Zeitscheiben verwendet, um Aufgaben so wenig wie möglich zu blockieren.

Ich kann alle Fraeggle sagte bestätigen.
Irgendwann heute Abend bekam ich "Connection Lost"

Ein schönes Wochenende wünsche ich ihnen :)
Sascha

@fraeggle :
Wenn es als "Verbindung unterbrochen" angezeigt wird, versuchen Sie, in die Controller-Einstellungen von ESPEasy zu wechseln. Deaktivieren Sie einfach den Controller -> Speichern, aktivieren Sie ihn erneut -> Speichern. Dann zeigt es sich zumindest für mich wieder als verbunden. Keine Lösung, aber zumindest interessant :) Verwenden Sie dieses IPSymcon?

@ TD-er:
zu beschäftigte Aufgaben? na ja ...... an der "TEST UNIT", die ich hier laufen lasse, sende ich nur alle 60 Sekunden eine Betriebsminute ...... an diesem Gerät läuft nichts mehr ..... also wahrscheinlich das kleinstmögliche System

@ Sasch600xt die Begriffe "zu beschäftigt" sind vielleicht nicht die besten, die das eigentliche Problem beschreiben.
Die Arduino-Methode ist:

• Rufen Sie setup()
• Rufen Sie loop() immer und immer wieder an.

Darüber hinaus führt die Arduino-Version für ESP8266 (und ESP32 Arduino) einige Aufgaben außerhalb der loop() für den Arduino-Teil aus.
Bei diesen Aufgaben geht es um Hintergrundprozesse wie die Verarbeitung der Netzwerkverbindung und des eingehenden Datenverkehrs usw.
Die Hintergrundaufgaben werden nur ausgeführt bei:

• Ende eines loop()
• beim Aufrufen von delay() oder yield() aus dem Arduino-Raum.

Wenn ein Schleifenlauf länger als 102,4 ms dauert und keine Aufrufe vonield () oder delay () erfolgen, hat der ESP-Knoten ein Beacon-Intervall verpasst.
Auch wenn mehrere Blockierungsaufgaben ausgeführt werden, die immer gerade ausgeführt werden, wenn der WiFi-Zugangspunkt das Beacon sendet, werden einige Beacons übersehen.

Wenn Sie sich das serielle Protokoll ansehen (mit aktivierter Debug-Ebene), sehen Sie die Timing-Statistiken.
Einige von ihnen können mehrere zehn ms machen und sind daher Kandidaten für die Ursache dieser "Trennungs" -Gründe.

Ich könnte dem Scheduler eine Aufgabe hinzufügen, um zu versuchen, alle 102,4 ms auf das Beacon zu hören. Das einzige ist, ich bin mir nicht sicher, wie ich sehen soll, wann ein solches Leuchtfeuer gesehen wurde.

Zu diesem Problem könnte ich das Trennen / Wiederverbinden von MQTT untersuchen, wenn eine Verbindung unterbrochen wurde.
Welchen Broker verwenden Sie? Ich benutze Mosquito hier und es funktioniert gut mit dem aktuellen Verhalten.

ok, "zu beschäftigt" war ein bisschen einfach von mir zu sagen :)

Ich verwende ein Skript, das in meiner ipsymcon-Haussteuerungsumgebung für MQTT-Broker ausgeführt wird

Greetz
Sascha

Hallo Sascha .. Mit IOBroker.
@ TD-er ging zurück zu Build 27092018. Broker sagt mir immer noch verbunden ...
Wirklich verwirrend. KEINE Fehler innerhalb von 14 Stunden (Anzahl stellt die Verbindung wieder her | 0)

Ich installiere IObroker jetzt auf meinem Computer, nur um zu sehen, was los ist.

Bearbeiten:
45 Minuten später kann ich IObroker immer noch nicht auf meinen Computern zum Laufen bringen.
Ich bin mir nicht sicher, was hier los ist, aber das Windows-Installationsprogramm funktioniert einfach nicht (die Service-Bat-Datei ist nirgends zu finden) und die Installation unter Linux ist einfach nicht abgeschlossen. Es wird immer wieder versucht, dieselbe npm-Installation durchzuführen.
Getestet unter Ubuntu 18.04 auf einem Intel CPU-Host und Bash unter Windows (Ubuntu 18.04)

Ich bin mir nicht sicher mit Windows. Ich denke, es gibt einige Software-Abhängigkeiten. Laufen es auf Himbeere.
für Windows ioBroker verwendet Node.js als Plattform und stellt diese voraus. (Download: http://nodejs.org/download/) Zuerst muss node.js installiert werden.

Ich habe auch ein Problem mit einem Modul mit 4 angeschlossenen DS18B20-Sensoren.
Ich dachte, es sei mein RasPi, nahm aber ein sauberes Raspbian Streth-Bild und installierte Mücken- und Knotenrot darauf. Gleiches Problem, Verbindungsunterbrechung nach 6-12 Stunden.

Dashboard: https://emoncms.org/Edegem/scrtmp2e
Die 4 Kurven aus dem ESP sind CV_aanvoer, CV_retour und Sanitair_warm, Sanitair_koud

@fluppie wenn du offizielle Builds verwendest?

Nein, ich baue mich mit PlatformIO / Atom
EDIT: Ha, ich habe nicht gut gelesen, ich werde einen offiziellen Build versuchen.

Lass uns das sehen!

Hallo

Ich habe / hatte das gleiche Problem, ich benutze HomeAssistant, aber nach ESPEasy_mega-20181111 fw ist das Problem für mich behoben.

Danke
T.

Meins verlor nach 2-3 Tagen immer noch die Verbindung. Ich werde auf Folgendes aktualisieren: ESP_Easy_mega-20181112_normal_ESP8266_4096.bin

Wir werden sehen!

Meins war der Conn zu verlieren. nach 1-10 Stunden. Ich habe ~ 10h30min Betriebszeit und alle (5pcs) die zugehörigen Module angeschlossen. :-)

Anscheinend lohnt es sich zu versuchen ... immer noch auf 2709, da eine stabile Verbindung benötigt wird. Bitte halten Sie mich auf dem Laufenden. :-))

Sie können auch folgen über: https://emoncms.org/Edegem/scrtmp2e und überprüfen, ob die Diagramme CV_ und Sanitair_ vorhanden sind :).

1 Tag Betriebszeit und immer noch in Ordnung. :-)

Sie können auch folgen über: https://emoncms.org/Edegem/scrtmp2e und überprüfen, ob die Diagramme CV_ und Sanitair_ vorhanden sind :).

:-D Sanitair_warm fast 60 C? kleines Lagerfeuer? ;-);
Ich werde die Firma versuchen .. Danke ...

Ich war duschen ;-)

1 Tag ... noch verbunden :-D
unter Verwendung von 12112018

Nach ~ 3 Tagen 3 Stunden verlor einer meiner Geräte die MQTT-Verbindung. :-( (Mega-20181112 4096 VCC fw)

@redskinhu :
Nur um sicherzugehen, funktioniert es immer noch gut, nachdem das Gerät die MQTT-Verbindung verloren hat?
weil es auf meiner Seite nur als "Verbindungsverlust" angezeigt wird, aber immer noch mit allen MQTT-Aktionen einwandfrei funktioniert.

Greetz
Sascha

In der Tat ist eine verlorene Verbindung nicht ab und zu ungewöhnlich.
Solange die Verbindung ohne menschliches Eingreifen wiederhergestellt wird, gibt es kein Problem.
WiFi-Verbindungen werden von Zeit zu Zeit zurückgesetzt, und Sie können nichts tun, um dies zu verhindern.
Sobald eine solche Verbindung unterbrochen wird, werden MQTT-Clients auf demselben Knoten benachrichtigt, um die Verbindung wiederherzustellen.

Es sieht aus wie ein LWT-Problem. MQTT ist nicht vollständig getrennt, ESPEasy sendet / empfängt MQTT-Nachrichten, aber das LWT wird nicht erneuert, sodass der HomeAssistant die LWT-Verbindungsnachricht nicht erhalten hat, sodass angezeigt wird, dass der entsprechende Sensor / Schalter nicht verfügbar ist. Das ist meine Theorie ...

Meins Immer noch verbunden und im Gegensatz zu meinem ersten Beitrag sagt mir sogar MQTT LWT, dass ich verbunden bin. Sieht gut aus.

In der Tat ist eine verlorene Verbindung nicht ab und zu ungewöhnlich.
Solange die Verbindung ohne menschliches Eingreifen wiederhergestellt wird, gibt es kein Problem.
WiFi-Verbindungen werden von Zeit zu Zeit zurückgesetzt, und Sie können nichts tun, um dies zu verhindern.
Sobald eine solche Verbindung unterbrochen wird, werden MQTT-Clients auf demselben Knoten benachrichtigt, um die Verbindung wiederherzustellen.

OK gibt es in diesem Fall die Möglichkeit, das angeschlossene LWT zu erneuern?

Es soll das LWT in dem Moment senden, in dem es die Verbindung erneuert.

Ich habe gerade einen Knoten, der im LWT als nicht verbunden angezeigt wird und der Messungen einwandfrei sendet. Ein bisschen älter gebaut ... vielleicht sagt dir das etwas

GIT-Version: | Mega-20181008
Betriebszeit: | 3 Tage 17 Stunden 36 Minuten

Ich habe seltsame Dinge gesehen, als der ESP-Knoten glaubt, er sei getrennt worden und müsse erneut eine Verbindung herstellen, aber der Broker ist anderer Meinung.

Hallo

Ich habe eine kleine Untersuchung durchgeführt. Es sieht so aus, als ob nur das LWT das Problem ist. Einer meiner ESP hat dieses MQTT-Ding "getrennt" wieder hergestellt.

Alles funktioniert gut, Sensoren / Schalter. Der Home Assistant konnte sie jedoch nicht sehen, da ich in der Konfiguration die LWT-Details angegeben habe.

- platform: mqtt
  name: "Socket 02"
  command_topic: "home/Socket02_ESP12F/GPIO/13"
  state_topic: "home/Socket02_ESP12F/Relay/State"
  availability_topic: "home/Socket02_ESP12F/status/LWT"
  payload_available: "Connected"
  payload_not_available: "Connection Lost"
  payload_on: "1"
  payload_off: "0"
  qos: 1

Ich habe den MQTT-Verkehr überprüft: Ich habe die Sensordaten erhalten und konnte den GPIO ein- und ausschalten. Alles ist in Ordnung, ex. das LWT.

Und nachdem ich eine LWT "Connected" Nachricht veröffentlicht hatte und alles wieder normal war.

Ich hoffe, es hilft.

T.

PS:
Ich denke an eine Regel, die LWT Connected-Nachricht veröffentlichen kann, wenn die LWT-Nachricht Disconnected ist, aber leider kann ich keine MQTT-Zeichenfolgen importieren ;-)

Jedenfalls habe ich mich sehr auf die neue fw-Veröffentlichung gefreut. 4 lange Tage ....

Ich war am Montag / Dienstag weg und die Tage danach waren sehr beschäftigt;)

Ich werde mir das LWT ansehen, um zu sehen, ob ich herausfinden kann, warum es nicht bei erneuter Verbindung veröffentlicht wird.

Wie ist die Timeout-Einstellung des MQTT-Brokers?
Ich denke über die Möglichkeit nach, dass der Broker eine verlorene Verbindung annimmt, aber der ESP-Knoten verhält sich immer noch so, als wäre er aktiv und immer noch verbunden.

Ich habe 100-1000 ms versucht. Jetzt 300. Egal.

Nicht im Controller, im Broker.
Diese Zeiten liegen in der Größenordnung von 10 bis 15 Sekunden.
Überprüfen Sie daher in der Konfiguration des Brokers, welches Timeout verwendet wird.

Ich habe nichts am LWT-Timeout geändert und konnte in meiner Mosquitto-Konfiguration keine relevanten Einstellungen finden. Es muss Standard sein. Ich konnte auch in den Dokumenten keine LWT-Zeitüberschreitungseinstellung finden.

Nein, nicht das LWT-Timeout, das Timeout des Brokers.
Wenn ein Client innerhalb des Zeitlimits keine Nachricht sendet, betrachtet der Broker diese als getrennt.
Wenn der Client eine andere Timeout-Einstellung verwendet, kann es sein, dass der Broker den Client als getrennt betrachtet und der Client nicht versucht, die Verbindung wiederherzustellen.

Was ich aus der mqtt-Spezifikation verstehe, sendet der Broker LWT, wenn er innerhalb des vom Client festgelegten Keep Alive-Zeitraums keine Nachricht vom Client erhält. Auf der Brokerseite gibt es nichts zu konfigurieren.

Siehe https://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over

Und

https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament

Das stimmt, aber ich möchte wissen, was diese "Keep Alive Period" auf der Brokerseite ist.
Ich weiß, dass es auf der ESPeasy-Seite behoben ist.
Aber wenn diese nicht miteinander synchron sind, werden Sie seltsame Dinge sehen.

hm ich habe keine möglichkeiten so etwas einzustellen

Sagt aber immer noch "Verbunden". 4 Tage :-D

Hatte gerade einen Mega-20181006 das Gleiche tun lassen. LWT nicht auf Online aktualisiert, aber normal funktionierendes MQTT

@ jimmys01 Können Sie in Ihrem Broker sehen, ob die Entscheidung auf der Kunden-ID basiert? (Dies ändert sich, wenn die Verbindung unterbrochen wird.)
Diese Änderung der Client-ID habe ich Ende September hinzugefügt.

@ TD-er, ich habe einen Weg gefunden, dies zu reproduzieren! Ich deaktiviere das wemos vom mikrotik-Router und es stellt eine Verbindung wieder her, aber das LWT bleibt offline, während das mqtt noch funktioniert. Schicken Sie mir Builds, um sie nach Belieben zu testen

Können Sie auch die Client-ID im MQTT-Broker sehen?
Wenn hinter der Client-ID ein "-1" oder etwas anderes steht, bedeutet dies, dass die neue Client-ID akzeptiert wird.
Wenn nicht, hat dies möglicherweise etwas mit der Änderung der Client-IDs zu tun, die ich vor einiger Zeit vorgenommen habe.

Ich habe nicht herausgefunden, wo sich die Client-ID in Mosquitto befindet, aber Protokolle zeigen an, dass kein Client getrennt und ein neuer verbunden wurde, wahrscheinlich weil der WLAN-De-Auth- und Auth-Prozess schneller ist als der Herzschlag des MQTT-Protokolls.

Neue Verbindung, nachdem ich sowohl den esp als auch den Broker neu gestartet habe

 New connection from 10.10.1.53 on port 1883.
1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').

Deaktivieren Sie den Client und der Client stellt die Verbindung wieder her. Der Broker hat diesmal den Kunden LWT aus irgendeinem Grund als online verlassen ...

1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965308: New connection from 10.10.1.53 on port 1883.

Zweite Entauthentifizierung

1542965308: New client connected from 10.10.1.53 as aquariums_1_1 (c1, k10, u'openhabian').
1542965308: Socket error on client aquariums_1, disconnecting.
1542965385: New connection from 10.10.1.53 on port 1883.

Nach dieser erneuten Verbindung und wenn das LWT offline bleibt, funktionieren MQTT-Nachrichten einwandfrei. Beachten Sie das zusätzliche _1_1 auf dem Client-Namen.

1542965385: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965385: Socket error on client aquariums_1_1, disconnecting.
1542965448: Socket error on client aquariums_1, disconnecting.

OK, dann werde ich die Änderung der Client-ID zurücksetzen.
Vielleicht ist es auch möglich, remote zu überprüfen, ob der Client als verbunden gilt?
Ich habe Verbindungsverweigerungen gesehen, wenn der Broker der Ansicht ist, dass der Client noch verbunden ist und der Client versucht, die Verbindung wiederherzustellen.
Wenn Sie es in kurzen Intervallen wiederholen, bleibt dieser Status erhalten, und ein Client kann die Verbindung nie wieder herstellen.

Gibt es eine Statusaktualisierung dazu?

Nein noch nicht.
Aber da wir (endlich) einige Fortschritte in anderen Stabilitätsfragen machen, wird es wohl als nächstes auf meiner Liste stehen.
Danke für den Ping;)

Ich habe es optional gemacht, die Client-ID bei erneuter Verbindung zu ändern. (Extras => Erweitert neben den anderen MQTT-Einstellungen)

Bitte schließen Sie das Problem, wenn es jetzt funktioniert.
Ich werde es auf fest setzen.

Warum sollte man die Client ID trotzdem ändern?

Es gab Berichte darüber, dass der Broker Verbindungsversuche ablehnte, solange der Broker davon ausgeht, dass der Client noch verbunden war.
Also wurde der Kunde abgelehnt und erneut versucht.
Aber irgendwie lösten diese erneuten Verbindungen auf der Brokerseite etwas aus, um Verbindungsversuche als jüngste Aktivität dieses Clients zu betrachten, und daher würde der Client niemals als getrennt betrachtet.

Ok, das hat es gelöst, aber die Lösung ist für die anderen, die dieses Kontrollkästchen sehen, nicht selbsterklärend.
Fügen Sie möglicherweise ein Popup hinzu, das erklärt, wie Sie es ankreuzen können, wenn nach einem WLAN-Verlust Probleme mit der erneuten Verbindung auftreten
Eine Suche bei tasmota-Problemen zeigt Ihnen, dass sie ähnlich aussehende Probleme hatten, die mit der Beibehaltung des MQTT zusammenhängen und so aussahen, als wäre dies ein Maklerproblem.
Ich hatte auch einen Client, der sich überhaupt nicht wieder mit WLAN verband, nachdem ich es deaktiviert hatte ... ich muss das untersuchen.

Wir werden dies der Dokumentation hinzufügen.
Wir arbeiten sehr hart daran, die Dokumentation auf den neuesten Stand zu bringen und viele Dokumentationen aus dem Wiki in die ReadTheDocs zu verschieben. Dies ermöglicht eine Dokumentation pro Version.
Die Dokumentdateien sind auch im GitHub-Repository enthalten.

Im Idealfall enthält ein Commit für eine Korrektur im Code auch ein Update in der Dokumentation.
Ich werde dieses Problem jetzt schließen.
Wenn Sie weitere Informationen zu dem anderen von Ihnen erwähnten Problem haben, öffnen Sie bitte ein neues Problem.

Hallo

Ich habe kürzlich die Version 20190110 installiert. Es sieht vielversprechend aus. Keine LWT-Probleme nach 5 Testtagen. :-)
Ich habe einige Knoten mit aktivierter Option "MQTT change ClientId at reconnect" und einige mit deaktivierter Option.

Gute Nachrichten!

T.