Skip to content
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

  1. ioBroker Community Home
  2. Deutsch
  3. Hardware
  4. Verbindungsabbruch mit ESP32 an MQTT

NEWS

  • UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?
    apollon77A
    apollon77
    48
    3
    8.3k

  • Monatsrückblick – September 2025
    BluefoxB
    Bluefox
    13
    1
    1.9k

  • Neues Video "KI im Smart Home" - ioBroker plus n8n
    BluefoxB
    Bluefox
    15
    1
    2.3k

Verbindungsabbruch mit ESP32 an MQTT

Geplant Angeheftet Gesperrt Verschoben Hardware
16 Beiträge 4 Kommentatoren 4.4k Aufrufe
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • F Offline
    F Offline
    Flossdorfer
    schrieb am zuletzt editiert von
    #7

    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.

    1 Antwort Letzte Antwort
    0
    • ThisoftT Offline
      ThisoftT Offline
      Thisoft
      schrieb am zuletzt editiert von
      #8

      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!

      22 HM-Geräte; PivCCU2 auf RasPi

      ioBroker-Multihost; Ubuntu-Master auf Intel-Atom und 3 RasPi-Clients

      1 Antwort Letzte Antwort
      0
      • a200A Offline
        a200A Offline
        a200
        schrieb am zuletzt editiert von
        #9

        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.

        IoBroker auf QNAP TS-451, Raspi und NUC

        1 Antwort Letzte Antwort
        0
        • ThisoftT Offline
          ThisoftT Offline
          Thisoft
          schrieb am zuletzt editiert von
          #10

          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?

          22 HM-Geräte; PivCCU2 auf RasPi

          ioBroker-Multihost; Ubuntu-Master auf Intel-Atom und 3 RasPi-Clients

          1 Antwort Letzte Antwort
          0
          • M Offline
            M Offline
            mrmomba
            schrieb am zuletzt editiert von
            #11

            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();
            }
            
            
            1 Antwort Letzte Antwort
            0
            • ThisoftT Offline
              ThisoftT Offline
              Thisoft
              schrieb am zuletzt editiert von
              #12

              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.

              22 HM-Geräte; PivCCU2 auf RasPi

              ioBroker-Multihost; Ubuntu-Master auf Intel-Atom und 3 RasPi-Clients

              1 Antwort Letzte Antwort
              0
              • a200A Offline
                a200A Offline
                a200
                schrieb am zuletzt editiert von
                #13

                @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.

                IoBroker auf QNAP TS-451, Raspi und NUC

                1 Antwort Letzte Antwort
                0
                • M Offline
                  M Offline
                  mrmomba
                  schrieb am zuletzt editiert von
                  #14

                  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...

                  1 Antwort Letzte Antwort
                  0
                  • ThisoftT Offline
                    ThisoftT Offline
                    Thisoft
                    schrieb am zuletzt editiert von
                    #15

                    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…

                    22 HM-Geräte; PivCCU2 auf RasPi

                    ioBroker-Multihost; Ubuntu-Master auf Intel-Atom und 3 RasPi-Clients

                    1 Antwort Letzte Antwort
                    0
                    • M Offline
                      M Offline
                      mrmomba
                      schrieb am zuletzt editiert von
                      #16

                      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.

                      1 Antwort Letzte Antwort
                      0
                      Antworten
                      • In einem neuen Thema antworten
                      Anmelden zum Antworten
                      • Älteste zuerst
                      • Neuste zuerst
                      • Meiste Stimmen


                      Support us

                      ioBroker
                      Community Adapters
                      Donate

                      758

                      Online

                      32.4k

                      Benutzer

                      81.4k

                      Themen

                      1.3m

                      Beiträge
                      Community
                      Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
                      ioBroker Community 2014-2025
                      logo
                      • Anmelden

                      • Du hast noch kein Konto? Registrieren

                      • Anmelden oder registrieren, um zu suchen
                      • Erster Beitrag
                        Letzter Beitrag
                      0
                      • Home
                      • Aktuell
                      • Tags
                      • Ungelesen 0
                      • Kategorien
                      • Unreplied
                      • Beliebt
                      • GitHub
                      • Docu
                      • Hilfe