ESP32 HTTP Client: Fehlercode -1 nach einiger Zeit?

[Thorsten M. (cortex_user)]

Hallo,

mit dem Seeeduino XIAO ESP32 fiel es mir das este Mal auf, dass die GET 
Abfrage von openwaether.org nur die erste kurze Zeit funktioniert und 
danach nur noch der Fehlercode -1 zurückliefert, was einfach heisst dass 
die Seite nicht gefunden wurde. Ich zieh mir da einen JSON String 
runter.

url = openwaether.api./data/....
HTTPClient http;

int result = http.get(url)

ergibt result = -1

Häh? Normalerweise funktioniert etwas nicht einmal und dann nie wieder 
zudem es auf einem normalen ESP32 WROOM einwandfrei spielt. Ich verwende 
aber String in der Funktion als Container für die Payload der Seite. 
Openweather erlaubt 1000 Aufrufe pro Monat und 60/Minute. Danach 
ersheint ein leerer Datensatz.

Testweise habe ich mal google.de aufgerufen, was Fehler 301 
zurückliefert, weil google kein http unterstützt.

Ich benutze wificlient.h und HTTPClient als Libs für die Arduino IDE.

Gruss, Thorsten

[Helmut -. (dc3yc)]

Thorsten M. schrieb:
> url = openwaether.api./data/....

Und mit dieser URL soll das funktionieren? Glaub ich nicht...

[Obelix X. (obelix)]

Am PC mit dem Browser wird "openwaether.org" auch nicht gefunden.

[Εrnst B. (ernst)]

Zeig mal mehr code. Dein Schnipsel ist nicht korrekt, und passt nicht 
zur aktuellen Version vom ESP32-HTTP-Client:

https://github.com/espressif/arduino-esp32/blob/master/libraries/HTTPClient/src/HTTPClient.h#L211

Auch das aussenherum ist wichtig:
Z.B. erzeugst du jedesmal einen neuen HTTP-Client, mit Keep-Alive oder 
ohne, räumst du nach dem Request auch wieder auf? Wie stellst du das 
Timing mit "60 Requests pro Minute" sicher? Wie schnell ändert sich das 
Wetter bei dir, dass du eine so hohe Polling-Frequenz brauchst?

[Thorsten M. (cortex_user)]

Εrnst B. schrieb:
> Z.B. erzeugst du jedesmal einen neuen HTTP-Client, mit Keep-Alive oder
> ohne, räumst du nach dem Request auch wieder auf? Wie stellst du das
> Timing mit "60 Requests pro Minute" sicher? Wie schnell ändert sich das
> Wetter bei dir, dass du eine so hohe Polling-Frequenz brauchst?

Dass ich die richtige url benutzte sollte klar sein. Code heute abend, 
bin auf Arbeit in der Pause. Nur was ich im Kopf hatte. Und es geht nur 
um den Fehlercode, die URL ist wumpe dabei.

[Εrnst B. (ernst)]

Thorsten M. schrieb:
> Und es geht nur
> um den Fehlercode,

der ist "Connection Refused". z.B. Wlan offline, Firewall sperrt den 
Zugriff, aber auch: Keine freien TCP-Sockets am ESP mehr verfügbar, weil 
alle in irgendwelchen verlorenen Keep-Alive HTTP-Clients hängen.

Bei zuvielen Zugriffen auf den Service würde der eher mit HTTP Error 
"509 Bandwidth exceeded" oder so antworten.

[Thorsten M. (cortex_user)]

Hier ist mal ein Teil des Codes. Lief den ganzen Tag 1x die Stunde, nach 
3-4 Aufrufen Fehlercode -1 . Aktuell läuft er an einer http Testseite, 
die für ssolche Zwecke besteht wo nur Text drauf ist einwandfrei 
durch... komisch. -1 heisst dass die url nicht erreicht wurde aber im 
Browser kriege ich einwandfrei den json container angezeigt, egal wie 
oft ich F5 drücke.

Spielt einwandfrei:
http://www.testingmcafeesites.com/index.html

Spielt nicht oder nur wenige Male
http://api.openweathermap.org/data/2.5/forecast?q=Kassel,DE&APPID=<XXXXXXXXXXXXXXXXX>&mode=json&units=metric&cnt=1

static JsonDocument doc;
static HTTPClient http;
static String payload;

/* Anfragen an Server richten */
int RequestWeather() {

  String url = openweather;

  /* Starte die Anfrage und hole die payload ab */
  http.begin(url);
  debugln("GET Anfrage ...");
  int httpCode = http.GET();
  debug("HTTP Fehlercode:");
  debugln(httpCode);

  if (httpCode > 0) {
    if (httpCode == HTTP_CODE_OK) {
      payload = http.getString();
      debugln(F("HTTP Weather Request successful."));

      // Versuche das JSON-Dokument zu analysieren
      DeserializationError jsonError = deserializeJson(doc, payload);
      if (jsonError) {
        debug(F("JSON Weather parsing error!"));

[Εrnst B. (ernst)]

Bei dir im Screenshot schaut's doch auch so aus, als würden alle 
Requests beantwortet ("HTTP 200 OK"), nur das Json-Parsing schlägt fehl.

Bau mal im
if (jsonError) {
eine Ausgabe von "payload" mit ein, damit du schauen kannst ob das 
gültiges Json ist.

Falls ja: Hat dein JsonDocument genug Speicher?

Hat dein ESP genug freien Speicher für String und JsonDocument 
gleichzeitig?

[Thorsten M. (cortex_user)]

Εrnst B. schrieb:
> f (jsonError) {
> eine Ausgabe von "payload" mit ein, damit du schauen kannst ob das
> gültiges Json ist.

Auf der Testseite steht nur Testzeugs, da parsed json natürlich nicht. 
Hauptsache die Seite lädt. Lese aber grad auf openwaethermap, dass sie 
die api 2.5 diesen Monat abschalten und ein neues Bezahlmodell 
einführen. Kann sein, dass die die Anfragen einfach begrenzen. Jetzt 
gibt es Wetter nur noch gegen Geld.

[Rolf (rolf22)]

Wenn man immer wieder 'http.begin' aufruft, ohne vorher mit 'http.end()' 
aufzuräumen, dann sind vermutlich irgendwann irgendwelche Ressourcen 
erschöpft.

[Thorsten M. (cortex_user)]

Rolf schrieb:
> Wenn man immer wieder 'http.begin' aufruft, ohne vorher mit 'http.end()'
> aufzuräumen, dann sind vermutlich irgendwann irgendwelche Ressourcen
> erschöpft.

Das ist schon alles ok so. Es tritt nach endlosem Testen nur aufd wenn 
ich langsamer als 1 Mal die Minute abtaste. So verrückt das klingt. Alle 
5 Minuten und dann ist die zweite Abtastung nach Reset schon ein Fehler. 
Auch die NTP Zeit Abfrage schlägt dann fehl um die interne Uhr zu 
synchronisieren weil Ticker.h Timer nicht sonderlich genau sind. Reichen 
würde 1x die Stunde. Und ich vermute fast dass dieser Seeeduino Xiao ne 
Macke hat in seinen Eingeweidden, denn das ist noch nie passiert vorher. 
Ich teste das mal mit nem normalen Esp32 Board am WE. Gibt aber auch 
noch andere Libraries und Möglichkeiten als die verwendete.

/* Anfragen an Server richten */
int RequestWeather() {

  JsonDocument doc;
  HTTPClient http;
  String payload;

  String url = openweather;

  debugln("GET Anfrage Openweathermap...");
  http.begin(url);
  int httpCode = http.GET();
  debug("HTTP Fehlercode:");
  debugln(httpCode);

  if (httpCode > 0) {
    if (httpCode == HTTP_CODE_OK) {
      payload = http.getString();
      debugln(F("HTTP Weather Request successful."));

      // Versuche das JSON-Dokument zu analysieren
      DeserializationError jsonError = deserializeJson(doc, payload);
      if (jsonError) {
        debug(F("JSON Weather parsing error!"));
        http.end();
        return 0;
      } else {
        // Drucke den analysierten JSON-Inhalt in Buffer
        //serializeJsonPretty(doc, Serial);
      }

      /* Daten auslesen in Variablen */
      JsonObject item = doc.as<JsonObject>(); /* Erzeuge ein Json Wurzel Object */
      item = doc["list"][0];                  /* zeige auf Array der Liste Index = 0 */
      Temperatur = (float)item["main"]["temp"];
      Windspeed = 3.6 * (float)item["wind"]["speed"];
      WetterID = (int)item["weather"][0]["id"];
      Wettertext = String(item["weather"][0]["description"]);
      Druck = (int)item["main"]["pressure"];
      Wolkendichte = (int)item["clouds"]["all"];
      Feuchte = (int)item["main"]["humidity"];
      Windstaerke = GetWindstaerke(Windspeed);
    }
  } else {
    debugln(F("HTTP Weather Request failed!"));
    http.end();
    return 0;
  }

  http.end();
  return 1;
}

[Monk (Gast)]

Zeige mal detailliert, wie du die Stromversorgung gemacht hast. 
Schaltplan, Fotos samt Netzteil und Leitungen. Ich will auch die 
Platzierung der Pufferkondensatoren sehen.

Weil: Dort liegt fast immer die Problemursache bei "seltsamen" 
Instabilitäten nach längerer zeit.

[Thorsten M. (cortex_user)]

Aehm... Usb Stecker rein und fertig. Seeeduino Ciao eben. 20ma Display 
dran und 3 Leds Schaltplan im Kopf, verdraten und fertig am I2C Bus

[Εrnst B. (ernst)]

Thorsten M. schrieb:
> Auch die NTP Zeit Abfrage schlägt dann fehl um die interne Uhr zu
> synchronisieren weil Ticker.h Timer nicht sonderlich genau sind.

Solche Details wären halt am Anfang hilfreich.
d.H. es liegt nicht am HTTPClient, es liegt nicht am Json-Parser. 
Vermutlich ist der ESP aus dem WLan geflogen...

Verwendest du Sleep-Modi? Lange Schleifen ohne delay() und yield()?

Ansonsten: Zielgerichtet den Fehler suchen. z.B. Ausgabe von 
"WiFi.isConnected()", "WiFi.localIP()" usw. im Fehlerfall.
Vom PC einen Ping auf den ESP durchlaufenlassen. Bricht der ab, wenn die 
Fehler auftreten?

Thorsten M. schrieb:
> Ich teste das mal mit nem normalen Esp32 Board am WE

Gerade beim Problem mit langen Schleifen kann das helfen das Problem zu 
verschleiern, Single-Core vs. Dual-Core.

[Thorsten M. (cortex_user)]

Dafuer hab3 ich wifi Events, die allerdings nicht getriggert haben. Ich 
reduziere alles die Tage auf diese eine Routin3 und schaue weiter

Via Handy
Thorsten

[Monk (Gast)]

Thorsten M. schrieb:
> Aehm... Usb Stecker rein und fertig

Das USB Kabel kann schon der Knackpunkt sein. Oder das Netzteil regelt 
schwankende Stromaufnahme nicht schnell genug aus.

Thorsten M. schrieb:
> Seeeduino Ciao eben

Das scheint es nicht zu geben. Wo sind die technischen Unterlagen zu dem 
Modul, insbesondere der Schaltplan? Es gab schon öfter mangelhafte 
gestaltete Module.

Wenn es dieses ist:
https://files.seeedstudio.com/wiki/XIAO_WiFi/Resources/Seeeduino-XIAO-ESP32C3-SCH.pdf

Dann hat es zu wenig Pufferkapazität. Hänge an 3,3V und GND einen 100µF 
Elko. Das hat schon vielen geholfen.

[Thorsten M. (cortex_user)]

Monk schrieb:
> Dann hat es zu wenig Pufferkapazität. Hänge an 3,3V und GND einen 100µF
> Elko. Das hat schon vielen geholfen.

Das werde ich am WE machen in meiner Werkstatt. Übrigens läuft alles 
auch, wenn man den Code komplett zusammen streicht und nur die Client 
Routine stehen lässt. Alle Timer raus usw. Da scheint irgendwas 
strubblig zu werden. Also ertst puffern, dann Code Stück für Stück 
wieder dazu geben und schauen ob es nach jedem Schritt noch läuft. 
Mancher Code ist ja auch fehlerhaft aus den Libraries.

Tja, die Wunder der Technik... immer wieder ein Vergnügen :-)

[Thorsten M. (cortex_user)]

Kurze Info: Der 100uF Elko an 3.3V out vom Modul hat das Problem 
vollständig behoben!

[Monk (Gast)]

Thorsten M. schrieb:
> Der 100uF Elko an 3.3V out vom Modul hat das Problem
> vollständig behoben!

Siehst du, man kann den Tipp gar nicht oft genug wiederholen.

[Jens K. (jensky)]

Thorsten M. schrieb:
> url = openwaether.api./data/....

Thorsten M. schrieb:
> 
http://api.openweathermap.org/data/2.5/forecast?q=Kassel,DE&APPID=<XXXXXXXXXXXXXXXXX>&mode=json&units=metric&cnt=1

--->
openwaether
openweather

?

[Thorsten M. (cortex_user)]

:-))))

[Monk (Gast)]

Mache das Display mal dunkler, wenn es länger als 1 Jahr halten soll. 
Oder ergänze den Aufbau mit einem PIR Sensor, womit das Display nur bei 
Bedarf eingeschaltet wird.

[Thorsten M. (cortex_user)]

Monk schrieb:
> Mache das Display mal dunkler, wenn es länger als 1 Jahr halten soll.
> Oder ergänze den Aufbau mit einem PIR Sensor, womit das Display nur bei
> Bedarf eingeschaltet wird.

Das geht nicht, 0 oder 1. Es brennt schnell ein, daher ständig wechselt 
und nachts geht es aus. Zeit kommt vom NTP Server. 4 Pins ablöten, neues 
Display rein und fertig. 4 Euro das Stück bei Aliexpress. Das EEPROM 
oben wird schon so rolierend beschrieben, dass die Datensätze der 
Grafiken immer neue Plätze buchen.

/* Datensicherung im EEPROM rolierend */
void SafeToEE(tables_t* data) {

  const int len = sizeof(*data);

  /* Erzeuge eine zufällige Blockadresse */
  const int max_blocks = EESIZE / len;
  int newBlock = random(0, max_blocks);

  EE_WritePtr = newBlock * len;  // Zieladresse im EEPROM
  data->valid = DVALID;          // Block gültig markieren
  data->blknr++;                 // Laufende Nummer

  sprintf(buf, "EE Block Nr.%u Data Set = %d Adr = %04X", newBlock, data->blknr, EE_WritePtr);
  debugln(buf);

  /* Funktion erwartet den Typ als Parameter ohne Angabe der Länge */
  myMem.put(EE_WritePtr, *data);
}


/* Daten lesen aus aktuellem Datensatz */
int ReadFromEE(tables_t* data) {

  uint16_t EE_AdrPtr = 0;
  uint16_t maxn = 0;
  uint16_t adr_found = 0;
  bool found = false;

  /* Position von valid ermitteln */
  const uint32_t validOffs = (uintptr_t) & (data->valid) - (uintptr_t) & (*data);
  const uint32_t blknrOffs = (uintptr_t) & (data->blknr) - (uintptr_t) & (*data);
  const int len = sizeof(*data);

  /* EE durcchsuchen nach gültigem valid */
  int16_t marke, id;
  while (EE_AdrPtr < (EESIZE - len)) {
    myMem.get(EE_AdrPtr + validOffs, marke);  // Valid Marke auslesen als int16_t
    if (marke == DVALID) {
      myMem.get(EE_AdrPtr + blknrOffs, id);  // Block Nummer auslesen als int16_t
      sprintf(buf, "Adresse: %04X = %u ID = %u", EE_AdrPtr, marke, id);
      debug(buf);
      /* Werte müsen gecasted werden! */
      if ((uint16_t)id >= maxn) {
        adr_found = EE_AdrPtr;
        maxn = (uint16_t)id;
        debug("*");
      }
      debugln();
      found = true;
    }
    EE_AdrPtr += len;  // Nächster Datensatz
  }

[Monk (Gast)]

Thorsten M. schrieb:
> Das geht nicht, 0 oder 1

Aber selbstverständlich kann man den Kontrast per Software einstellen!

Auszug aus meinem Treiber:

    i2c.beginTransmission(display_address);
    i2c.write(0x00);
    i2c.write(0x81);
    i2c.write(contrast); 
    i2c.endTransmission();

Mir reicht in Innenräumen ein kleiner "contrast" Wert um 50.

> Es brennt schnell ein,

Eben deswegen der Vorschlag mit dem PIR Sensor. Du kannst es im 
Ruhezustand auf einen ganz niedrigen Kontrast (z.B. 8) stellen und wenn 
der Sensor auslöst für eine Minute auf 128 erhöhen.

[Thorsten M. (cortex_user)]

Monk schrieb:
> Aber selbstverständlich kann man den Kontrast per Software einstellen!

Ich baue es mal eben ein.... ist aber nur fürs Büro mit dem Handy als 
Hotspot für Wifi da Firmen Wlan leider an MAC Adresse gekoppelt ist aus 
Sicherheitsgründen. Könnte ich zwar ändern im XIAO auf die meines 
Laptops aber lieber nicht.

PS: Klappt! :-) Danke! 50 reicht vollkommen aus.

[Monk (Gast)]

Thorsten M. schrieb:
> 50 reicht vollkommen aus.

Probiere noch weniger. Das Auge reagiert logarithmisch. Vielleicht 
reicht dir sogar 20.

[Thorsten M. (cortex_user)]

Das passt schon mit 60 jetzt, der Kontrast ist sogar noch besser 
geworden. Vielleicht spendiere ich noch einen LDR für den A0 Pin für die 
Licht Sensierung mit einer Look Up Table für die Helligkeit. Gibt es ja 
diese Logarithmus Tabellen für LEDs.

Ups... Sturmwarnung für heute abend. Windstärke 5-6 ... woher das?

[Thorsten M. (cortex_user)]

Ich popp den Threasd nochmal hoch. Nachdem ich mich intensiv mit dem 
Xiao, Firebeetle und Wrover befasst habe und deren Connektivität zum 
Wlan fallen natürlich auch viele Berichte im Netz auf. Kurz und knapp: 
Seit dem Zurücksetzen des Core von 3.03 auf 2.11 sind die Probleme weg! 
Der Core nervt schon desswegen weil vieles nicht mehr funktioniert bzw 
anders .Der Watchdog verhält sich nicht mehr wie beschrieben, braucht 
jetzt einen Struct und egal was man da einträgt, die Zeiten stimmen 
nicht. LED Pwm anders, Timer anders usw usw.  Zudem scheinen etliche 
Wrapper Funktionen von Libraries nicht angepasst zu sein, da die ja die 
Espressiv API nur kapseln. Zurück auf 2.11 und alles wurde gut, auch 
keine Vebindungsabrüche mehr. Habe auch den Eindruck, dass der Esp32 
gerne mal den wifi Core abschmieren lässt ohne dass das bemerkbar wird. 
Er bleibt weiter angemeldet im Netz also sichtbar aber reagiert auf 
nichts mehr. Abhilfe ist zyklisches Resetten des ESP32, stört mich nicht 
in der Anwendung und die Daten sind im spiffs ja speicherbar.