mqtt verliert verbindung #533
Replies: 7 comments 3 replies
-
|
Hallo, das ist sehr komisch. Das "offline" auf dem Statustopic ist eigentlich eine LWT Message. Das bedeutet, dass diese bei einem Disconnect des Clients (auch wenn dieser hart ausgeschaltet wird) vom Broker (Server) gesetzt wird. Der Client schickt nie ein "offline". Was passiert wenn du im Fehlerfall (also wenn OpenDTU die Verbindung verliert) du den ESP aussteckst? Setzt wir dann das Topic auf "offline" gesetzt? Falls nein liegt der Fehler am Broker (Server). |
Beta Was this translation helpful? Give feedback.
-
|
Das probiere ich beim nächsten Fehlerall. |
Beta Was this translation helpful? Give feedback.
-
|
Guten Tag, was war die Lösung. Habe das auch gerade. Danke |
Beta Was this translation helpful? Give feedback.
-
|
Hi, ich habe das leider noch nicht lösen können das passiert nur nach dem man iobroker neugestartet hat. Danach muss man OpenDTU neustarten danach steht die verbiendung wieder. |
Beta Was this translation helpful? Give feedback.
-
|
Habe es gerade versucht nochmal nachzustellen.
Ich weiß nicht was ich hier noch testen soll. Könnte mir auch vorstellen das der in ioBroker integrierte MQTT Broker seltsame dinge tut. @Ivangrosnij würdest du das ggf. mal auf den Output der Seriellen Konsole achten während du den ioBroker neustartest? |
Beta Was this translation helpful? Give feedback.
-
|
ich habe momentan OpenDTU-OnBattery drauf laufen da ist was MQTT angeht gleich wenn man ioBroker neustartet geht die Verbiendung verloren. |
Beta Was this translation helpful? Give feedback.
-
wenn du den in ioBroker integrierten MQTT Broker verwendest bleiben die Verbindungen auch dort nicht bestehen. Sie werden nur wieder aufgebaut. Leider bringt ein Auszug aus der Console im Webinterface nichts da tiefgreifende Logs aus dem TCP Stack nur auf der richtigen Seriellen Konsole ausgegeben werden. Und genau das wäre wichtig. Weil wie man im oberen Log sieht, wird 1x versucht eine Verbindung aufzubauen: |
Beta Was this translation helpful? Give feedback.
-
|
Hier mein Fehlerbeschreibung und Korrekturmöglichkeit in englisch. Ever since I started using OpenDTU, I have been troubled by this annoying problem, which I have already found described as a openDTU problem on several places. I've analyzed and corrected it in temp branch of async-mqtt-client. Regarding the cause: The problem now, however, is that the MQTT client code has a bug in the connection setup. Under certain circumstances, the method MqttClient::loop() may stuck in the second phase of the connection setup if the MQTT server e.g. ioBroker allows a socket connect but unfortunately does not send back a connect-acknowledge packet in situation like server shutdown or restart. The faulty code in MqttClient.cpp: void MqttClient::loop() {
switch (_state) {
case State::connectingTcp1:
...
...
if (_useIp ? _transport->connect(_ip, _port) : _transport->connect(_host, _port)) {
_setState(State::connectingTcp2); <---- connection successful; set _state to connectingTcp2
} else {
_setState(State::disconnectingTcp1);
_disconnectReason = DisconnectReason::TCP_DISCONNECTED;
break;
}
// Falling through to speed up connecting on blocking transport 'connect' implementations
[[fallthrough]];
case State::connectingTcp2:
if (_transport->connected()) { <---- connected is false until the ioBroker sends a connect-acknowledge-packet
_parser.reset();
_setState(State::connectingMqtt); <---- ioBroker does not send an acknowledge, the _state will never set to next step connectingMqtt
}
break;
Here are my modifications:
void MqttClient::loop() {
switch (_state) {
case State::disconnected:
#if defined(ARDUINO_ARCH_ESP32)
if (_useInternalTask == espMqttClientTypes::UseInternalTask::YES) {
vTaskSuspend(_taskHandle);
}
#endif
break;
case State::connectingTcp1:
if (_useIp ? _transport->connect(_ip, _port) : _transport->connect(_host, _port)) {
_setState(State::connectingTcp2);
_lastClientActivity = millis(); // <---- set connect time
} else {
_setState(State::disconnectingTcp1);
_disconnectReason = DisconnectReason::TCP_DISCONNECTED;
break;
}
// Falling through to speed up connecting on blocking transport 'connect' implementations
[[fallthrough]];
case State::connectingTcp2:
if (_transport->connected()) {
_parser.reset();
_lastClientActivity = _lastServerActivity = millis();
_setState(State::connectingMqtt);
} else if (millis() - _lastClientActivity > _keepAlive) { // <---- new else block; use _keepAlive 15 seconds as timeout here
_setState(State::disconnectingTcp1); // <---- force an disconnect sequence that calls onMqttDisconnect which starts a new connect request
_disconnectReason = DisconnectReason::TCP_DISCONNECTED;
}
break;https://github.com/marvinroger/async-mqtt-client seems to be dead so I do not expect any fixes from this site. Regards! |
Beta Was this translation helpful? Give feedback.
-
Thats not true. OpenDTU does not use this library. It uses: https://github.com/bertmelis/espMqttClient Please report your issue here to get it fixed in the upstream repository. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, I opened a case at https://github.com/bertmelis/espMqttClient
Yes, but the library(https://github.com/marvinroger/async-mqtt-client) seems to be more or less the master of https://github.com/bertmelis/espMqttClient. In my opinion, reporting bugs in masters first is always the best strategy to propagate fixes to more than one fork/copy". |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hallo,
ich betreibe HM-1500 mit OpenDTU auf ESP32 mit ioBroker
Letzte zeit verliert OpenDTU mqtt verbindung zum ioBroker.
Nach eine neustart von OpenDTU verbindet er sich wieder.
Interesant ist auch das über Weboberläche Info/MQTT/Verbindungsstatus auf getrennt ist.
und in ioBroker /DTU/Status/ online zeigt.
Beta Was this translation helpful? Give feedback.
All reactions