Verbindungsabbruch mit ESP32 an MQTT

Thisoft

USB-Booster bzw. Powerbank sollte eigentlich i.O. sein - natürlich nur wenn die Kapazität der Ladezustand dementsprechend angepasst ist. Wieviel Ah hat denn der USB-Booster?

Was den RST-Eingang betrifft weiß ich zwar jetzt nicht ob der im Wemos-Clone irgendwie beschaltet ist, aber schaden kann es nicht wenn du den mal (sicherheitshalber über einen Widerstand in der Größenordnung von 5k) auf +3,3V legst.

a200

Der Booster hat 600mA (https://www.amazon.de/SODIAL-0-9-5V-Vol … B00YO8NG1E). Das sollte für den Wemos clone reichen. der RST-Eingang ist bei mir mit dem D0 verbunden, damit der Wakeup funktioniert.

Das ist meine Lösung.

Flossdorfer

Ich habe RST nicht definiert, werde ich mal machen. Was passiert denn, wenn Störungen an RST auftreten? Wird dann neu gebootet? Das macht der ESP32 nämlich nicht.

Ich benutze nicht explizit einen Sleep-Modus und denke, dass er nicht automatisch da rein geht.

Thisoft

OK. Was den RST betrifft das geht damit in Ordnung wenn der mit GPIO0 verbunden ist.

Wo ich aber ein ungutes Gefühl habe ist deine Stromversorgung. Ich dachte du meinst mit USB-Booster eine Powerbank, aber das ist ja ein Stepup-Konverter der aus 1,5V Zellen- bzw. Akkuspannung die 5V für den Wemos generiert. Da würde ich für nichts garantieren…! Hänge mal testweise eine kräftige Powerbank direkt dran und schaue ob die Abbrüche dann immer noch auftreten!

a200

Halb so wild, ich nutze 3,7V LiIon Akku mit 2200 mAh. Allerdings habe ich nichts vergleichbares in Fritzing gefunden. Und der Booster steppt mir die Spannung von 3,7v auf 5V. Das läuft über (sonnige) Stunden stabil. Durch den DeepSleep kann ich den Verbrauch so minimieren, dass das Ding seit Wochen läuft. Hier spielt die Dimensionierung des Solarpanels eine wichtige Rolle. Bei Gelegenheit will ich von groß (165x165mm) auf 2 x klein (100x60mm) umsteigen.

Die Abbrüche hatte ich auch bei meiner Powerbank, die ich test-weise am laufen hatte.

Die Meldung in IoBroker bekomme ich alle 5 Minuten. Also jedes mal wenn der ESP aufwacht und sich dann neu verbinden will.

Thisoft

So, ich hab mir mittlerweile zum Vergleichen mal einen Temperatursensor mit 'nem ESP8266-12 und 2 Stück DS18B20 und 2 AA-Batterien aufgebaut (hatte ich schon länger vor…). Meine Erfahrungen der ersten paar Tage: Verbindungsabbrüche habe ich bisher keine gehabt, aber dafür ein anderes Phänomen. Wenn ich die Schlafphase zu lang wähle wacht er nicht mehr auf, ich bin noch ein wenig am rantasten - bis 5 Minuten Schlafrhythmus ist er bisher stabil durchgelaufen, bei 30 Minuten jedoch ist er nur so 5-6 mal aufgewacht und dann hat er sich nicht mehr gemeldet. Kann ich mir gerade noch nicht so ganz erklären...

@a200: Die Meldung im Log ist eigentlich ganz logisch. Da meckert ioBroker dass die Verbindung plötzlich abbricht. Tut sie ja auch... wenn du das vermeiden willst musst du die Verbindung vor dem Schlafenlegen des ESP explizit disconnecten - falls du ein selbstgeschriebenes Programm verwendest...

@Flossdorfer: Was der Grund für die von dir beschriebene Art von Abbrüchen sein könnte weiß ich jetzt auch nicht wirklich. Ist evtl. die WLAN-Verbindung schwach? Oder eben doch die Stromversorgung... Warum wollt ihr unbedingt diesen Booster verbauen? Geht das nicht auch mit 2 Solarzellen und 2 Batterien in Reihe?

mrmomba

Hallo,

ich hatte das Problem bei mir auch gehabt, (falls du dich daran erinnerst, Thisoft) bei meinem OpenMQTT Sensor Projekt.

Meine ERKLÄRUNG zu meinem Problem damals:

delay(xyz)

Nach dem ich in meinen Script KONSEQUENT alle delays entfernt habe, läuft er nun ohne Probleme.

Aber ich sehe das delay nicht als Kern des Problems, sondern eher etwas anders. Im LOG stand aber dennoch der gleiche Fehler, den du da hast.

VERMUTUNG:

MQTT: Client -> Server -> Client, KOmmunizieren miteinander. Wenn der ESPxxx jetzt aber nicht Antwortet (warum auch immer) geht der Server vom Problem aus, möglicherweise gibts es da auch eine Fehlertoleranz, und ist der Counter voll, sagt er sich halt: LMAA. Reset.

Ich weiß es leider nicht, ob es sowas wie: mqttClient.disconnect(clientID) gibt, um vor dem DeepSleep sich vom Server abzumelden.

Darum habe ich meine Loop jetzt ganze ohne Verzögerung

void loop() {
  // put your main code here, to run repeatedly:
  int int_var_TMP_LaufZeitInSekunden = int_fkt_LaufZeitSekunden();

  if ( int_var_TMP_LaufZeitInSekunden - int_var_TMP_Loop_Time_DHT >= ((DHTSensorReadInt+BME280i2cReadInt)/2)){
    Serial.println("Lese TEMPERATUR");
    int_var_TMP_Loop_Time_DHT = int_var_TMP_LaufZeitInSekunden;

    Value101Temperatur = float_fkt_getTemp();
    Value102Luftfeuchtigkeit = float_fkt_getHum();
    Value107Barrometer = float_fkt_getLuftDruckBME();
  }

  ArduinoOTA.handle();
[color]  fkt_MqttClientLoop();[/color] // DIESE SELBSTGEBAUTE FUNKTION IST WICHTIG!

}

und zwar steht das hier drin!

(Macht wenig Sinn - ich weiß, aber ich will eigene Funktionen nutzen :-) )


void fkt_MqttClientLoop() {
  var_MqttClient.loop();
}

Thisoft

Ja, es gibt den Befehl

mqttClient.disconnect()

Dass der Code völlig ohne delays fehlerfrei funktioniert kann ich mir erstens schwer vorstellen, z.B. wird vor dem DeepSleep ein delay wärmstens empfohlen weil die MCU sonst u.U. noch zu tun hat und das Schlafengehen ignoriert. Und andererseits kann ich jetzt auch keinen Zusammenhang herstellen wieso ein Delay die MQTT-Verbindung unterbrechen sollte… Aber wenn's bei dir hilft um so besser.

a200

~~@Thisoft:~~

Ja, es gibt den Befehl
mqttClient.disconnect()
Dass der Code völlig ohne delays fehlerfrei funktioniert kann ich mir erstens schwer vorstellen, z.B. wird vor dem DeepSleep ein delay wärmstens empfohlen weil die MCU sonst u.U. noch zu tun hat und das Schlafengehen ignoriert. Und andererseits kann ich jetzt auch keinen Zusammenhang herstellen wieso ein Delay die MQTT-Verbindung unterbrechen sollte… Aber wenn's bei dir hilft um so besser. `
sehe ich auch so. ein delay(100); direkt nach DeepSleep sollte schon ausgeführt werden.

mrmomba

Hallo,

da im delay() meines Hörensagens-Wissens her der ESP aber nichts Abarbeitet, kann es vermutlich dazu kommen, dass vom MQTT keine Anfragen bearbeitet werden.

Es soll ja auch nicht heißen, dass delay generell Teufelszeug ist,

mein Hinweis sollte eher dahin gehen wie der folgende Psydocode.

Wenn Zeit Reif für DeepSleep

Trenne Verbindung von MQTT

Mache zusätzlich etwas mehr

Setze ReifezeitfürDeepSleep Counter zurück

Delay

Beginne DeeoSleep

Delay

Und überhaupt bin ich kein Profi und auch nur wenig versiert im Scripten… (mehr mache ich nicht und kann ich nicht)

aber ich habe in diesem Fall wohl als blindes Huhn mein Korn getroffen.

Ich bin noch gaaaanz Weit weg davon, deepsleep zu nutzen und ein Webfrontend zu bauen, mit der Chance Konfigs abzuspeichern. das sindfür mich 200 Level über mir...

Thisoft

Hallo mrmomba,

prinzipiell gebe ich dir da zu nahezu 100% Recht - auch wenn du dein Licht ein wenig unter den Scheffel stellst ;-)

Es wäre jetzt höchstens noch interessant wie lange deine delays im Code waren und wie lange das MQTT-Protokoll wartet bevor es einen Verbindungsabbruch wirft. Falls du im Code delays genutzt hattest um den ESP mehrere Sekunden oder gar Minuten warten zu lassen dann wäre das durchaus eine Erklärung für Verbindungsabbrüche…

mrmomba

Ich habe den alten Code noch (gibt es ja auch hier zum Download)

Da sind die delays alle drin.

Was dann noch interessant ist, unter welchen Bedingungen wie lange die Addition aller delays sein kann.

=> Ich habe jetzt aber auch den neuen Code hochgeladen im Topic und Beitrag:

viewtopic.php?f=34&t=12419&p=158484#p158484

Nene, ich betrachte mein Scripting glaube ich sehr realistisch :-D

Es gibt nun mal Ende vom Verstehen - wie zum Beispiel das speichern und lesen aus dem EEProm, aber aktuell kann ich mir mit einer config.h helfen :-)

Interessant wäre. wie sich der Code nach dem Umbau mit dem Pseudocode verhält.

Community Forum

NEWS

Verbindungsabbruch mit ESP32 an MQTT

Support us

350

32.5k

81.8k

1.3m