Was passiert da in einem ESP8266 (12E)?

[Uwe B. (boerge)]

Moin,

ich bin gerade ein wenig am Experimentieren mit einem ESP8266 im 
DeepSleep-Mode, um den Stromverbrauch eines Sensormodules zu minimieren. 
Dabei kann ich mir zwei Zeiträume während der Verarbeitung im ESP8266 
nicht erkären.

Versuchaufbau:
* das Sensormodul, ein ESP8266-12E, welches nach der Verarbeitung in den 
DeepSleep-Mode geht und nach x Sekunden wieder aufwacht etc.. Zu 
bestimmten Zeitpunkten während der Verabeitung wird jeweils ein Impuls 
an ein GPIO-Pin ausgegeben
* der Stromverbrauch wird mit einer zweiten Schaltung, welches aus einen 
MC und einem INA219-Modul besteht, gemessen. Über oben erwähnte Impulse 
wird die Strommessung getriggert und die Anzahl der Impulse auch im 
Messergebnis mitgeloggt.

Es entsteht dabei angehangenes Diagramm (x-Achse: Zeit in ms, y-Links 
Strom in mA, y-rechts Anzahl der Impulse; blaue Kurve Stromverbrauch, 
grün x.Impuls)

Ich kann mir die langen Zeiten in Abschnitt 6 und 7 nicht erklären.

In Abschnitt 6 läuft dieser Code:

// **************************************************************
void wifi_connect()
{
  uint8_t count = 0;
  
  // Wifi anschalten
  WiFi.forceSleepWake();
  delay(1);
  // kein Laden/Sichern der Wifi-Konfiguration im Flash
  WiFi.persistent( false );
  // ins WIFI anmelden
  WiFi.mode(WIFI_STA);
  // feste IP-Konfiguration
  WiFi.config(ip, gateway, subnet); 
  // wenn Daten im RTC valid, dann mit diesen zuerst den Connect versuchen
  if (rtc_valid) {
  if (debug) Serial.println("Wifi.begin() mit RTC-Daten.");
  WiFi.begin(ssid, password, rtc.vars.wifi_channel, rtc.vars.wifi_ap_mac, true);  
  } else {
  if (debug) Serial.println("Wifi.begin() ohne RTC-Daten.");
    WiFi.begin(ssid, password);
  }
  WiFi.hostname(hostname);
  if (debug) Serial.print("Connect to WiFi: ") ;
  while (WiFi.status() != WL_CONNECTED) {
  count++;
    // nach 5s keine Verbindung mit RTC-Daten zustande gekommen, also doch scannen  
  if (count == 100) {
      if (debug) Serial.println("neuer Versuch ohne RTC-Daten!!!");
    WiFi.disconnect();
      delay(10);
      WiFi.forceSleepBegin();
      delay(10);
      WiFi.forceSleepWake();
      delay(10);
      WiFi.begin(ssid, password);  
    }
  // nach 15s keine Verbindug zustande gekommen
  if (count == 300) {
    if (debug) {
      Serial.println("...no connection (WLAN)!!!");
      Serial.flush();
    }
    write_rtc_memory((rtc.vars.awake_time+millis()-awake_time));
    WiFi.disconnect(true);
      delay(1);
      WiFi.mode( WIFI_OFF );
    ESP.deepSleep(deepsleep_time);
  }
    delay(50);
    if (debug) Serial.print(".");
  }
  if (debug) {
    Serial.println("");
    Serial.println("WiFi connected!");
    Serial.println(WiFi.localIP());
    Serial.println("");
  }
}

Wobei hier noch zu bemerken ist, dass das Wifi-Modul nach dem Aufwachen 
mittels:

WiFi.mode(WIFI_OFF);
WiFi.forceSleepBegin();
delay(1);

ausgeschaltet wird, da es während des Auslesens der Sensoren ja noch 
nicht benötigt wird.

Weiterhin wird MAC-Adresse und Kanal der vorherigen Verbindung im RTC 
gerettet und mit diesen Daten der erste Verbindungsversuch gestartet 
(möglichst kein Wifi-Scannen, was Zeit kostet). Das angehangene Diagramm 
ist ein solcher erfolgreicher Versuch mit den gesicherten Daten. Und es 
wird mit fester IP etc. gearbeitet, um die Latenzen für DHCP zu 
minimieren.


In Abschnitt 7 folgende Codezeilen:

// **************************************************************
void mqtt_reconnect ()
{
  uint8_t count = 0;
  // MQTT...
  // ...initialisieren
  mqtt_client.setServer(mqttServer, mqttPort);
  // ...verbinden
  while (!mqtt_client.connected()) {
    if (debug) Serial.println("Connecting to MQTT...");
    if (mqtt_client.connect(mqttClientId, mqttUser, mqttPassword )) {
       if (debug) Serial.println("Connected!");  
    } else {
      if (debug) {
        Serial.print("failed with state ");
        Serial.print(mqtt_client.state());
      }
      count++;
      delay(100);
    }
  if (count == 100) {
    // keine Verbindung zum Broker, dann wieder schlafen legen
      if (debug) {
        Serial.println("...no connection (MQTT-Broker)!!!");
      Serial.flush();
      }
      write_rtc_memory((rtc.vars.awake_time+millis()-awake_time));
    ESP.deepSleep(deepsleep_time);
  }
  }
}

Ich kann mir konkret folgende Verarbeitungszeiten nicht erklären:
* Abschnitt 6: eigentlich insgesamt, warum dauert das eine ganze 
Sekunde?
* Abschitt 7: 1450ms - ca. 2340ms, welcher in allen Messungen konstant 
ist

Wer kann mir ein paar Tipps geben, was da passiert und wie man das 
abstellen könnte? Hat jemand noch weiter Tipps, um die Verarbeitung 
weiter optimieren zu können?

Grüße & Danke Uwe

[Uwe B. (boerge)]

Uwe B. schrieb:
> welches nach der Verarbeitung in den
> DeepSleep-Mode geht

...vielleicht noch eine Ergänzung, falls die Frage kommen sollte, in 
DeepSleep gehe ich mit:

ESP.deepSleep(deepsleep_time, WAKE_RF_DISABLED);

Grüße Uwe

[Michael U. (amiga)]

Hallo,

am Anfang habe ich solche Experimente auch gemacht.
Ende vom Lied: DeepSleep für 300s, aufwachen, normaler WLAN-Connect mit 
fester IP, connect zum MQTT Broker. BME280 im forced-Mode lesen, BH1750 
lesen, Daten per MQTT rausschicken, DeepSleep.
Dauer ca. 2-3s komplett.
Ein ESP32 mit BME280 und MAX44009 verhält sich nahezu identisch, 
sporadisch brauchen beide mal rund 4s bis der WLAN-Connect steht, im 
identischen Umfeld.
Habe ich nicht weiterverfolgt. Eine 18650 LiFePO4 mit 1500mA hält stabil 
2 Monate durch, dann ist laden fällig, reicht mir so.

Gruß aus Berlin
Michael

[Stefan S. (st_schulte)]

Moin!

Also ich weiß nicht wie vergleichbar der ESP8266 mit dem ESP32 ist,
aber Andreas Spiess ist der Sache beim ESP32 auf den Grund gegangen:
https://youtu.be/CJhWlfkf-5M?t=933
(Link zur Stelle mit dem Graphen des ESP32)
Andreas ist ja Schweitzer, vielleicht fragst Du mal :-)

Gruß,
Stefan

[Stefan F. (Gast)]

Finde heraus, an welchen Stelle sich deine Code-Ausführung in den beiden 
fraglichen Zeitabschnitten befindet. Ich würde dazu ggf. weitere 
debug-Meldungen hinzufügen. Zeiche das dann im Diagramm ein.

Da du den Wert von deepsleep_time nicht gezeigt hast, kann ich gar nicht 
einmal prüfen, ob diese Zeit mit dem Diagramm überein stimmt.

[Uwe B. (boerge)]

Moin,

Stefan ⛄ F. schrieb:
> Da du den Wert von deepsleep_time nicht gezeigt hast, kann ich gar nicht
> einmal prüfen, ob diese Zeit mit dem Diagramm überein stimmt.

...ich denke mal der Wert für deepsleep_time (derzeit bei 2min) ist für 
meine Frage nicht relevant. Das Diagramm zeigt den Stromverbrauch 
während der ESP wach ist... Die Schlafzeiten passen auch zu dieser 
deepsleep_time. Der Stromverbrauch während der Schlafphase entspricht 
auch halbwegs meinen Erwartungen (0.1 - 0.2 mA, wobei aber auch die 
Genauigkeit/Auflösung des INA219 bei diesen geringen Strömen schon eine 
Rolle spielt, sollte man also nicht so ernst nehmen ;-)).

Hier mal der Code meiner setup()-Routine, der loop() ist leer. D.h. also 
die ca. 2.4s in dem Diagramm ist die Laufzeit von setup():

// **************************************************************
void setup() 
{

  awake_time = millis();
  
  pinMode(TRIGGER_PIN, OUTPUT);
  digitalWrite(TRIGGER_PIN, HIGH);
  
  pulse_pin(TRIGGER_PIN);      // ==> 1

  // Wifi ausschalten, da zuerst nur die Sensoren etc. ausgelesen werden sollen
  WiFi.mode(WIFI_OFF);
  WiFi.forceSleepBegin();
  delay(1);

  pulse_pin(TRIGGER_PIN);  // ==> 2

  // RTC-Memory auslesen und validieren
  ESP.rtcUserMemoryRead(0, (uint32_t *) &rtc.data, sizeof(rtc.data));
  if (calculateCRC32((uint8_t*) &rtc.data.data[0], sizeof(rtc.data.data)) == rtc.vars.crc32) {
    old_awake_time = rtc.vars.awake_time;
    rtc_valid = true;
  } else {
    old_awake_time = 0;
  }

  pulse_pin(TRIGGER_PIN);  // ==> 3

  // Konfiguration aus Datei im SPIFFS auslesen
  config_read();

  pulse_pin(TRIGGER_PIN);  // ==> 4

  // serielle Schnittstelle initialisieren
  if (debug) {
    Serial.begin(115200);
    Serial.println("");
    Serial.println("...setup");
  }
  
  Wire.setClock(3400000);
  
  // BME280
  bool status = bme.begin(0x76);  
  if (!status) {
    if (debug) Serial.println("Could not find a valid BME280 sensor, check wiring!");
    while (1);
  }
  
  // BH1750
  myLux.powerOn();
  myLux.setContHighRes();
  
  // ADS1115
  ads.begin();

  pulse_pin(TRIGGER_PIN);  // ==> 5

  // Sensoren auslesen und in Stromsparmode schicken (wenn erforderlich)
  sensors_read();
  if (debug) {
    Serial.println("sensor_read ended.");
    Serial.flush();
  }

  pulse_pin(TRIGGER_PIN);  // ==> 6

  // WiFi initialisieren (incl. Aktivierung Wifi)
  wifi_connect();

  pulse_pin(TRIGGER_PIN);  // ==> 7

  // MQTT initialisieren
  mqtt_reconnect();
  
  pulse_pin(TRIGGER_PIN);  // ==> 8

  // MQTT
  mqtt_publish_values();
  // MQTT-Loop aufrufen, um Telegramm sicher zu versenden
  //mqtt_client.loop();
  delay(1);

  pulse_pin(TRIGGER_PIN);  // ==> 9

  // ESP schlafen legen
  if (debug) {
    Serial.println("...deepSleep");
    Serial.flush();
  }
  
  // aktuelle Wachzeit sowie CRC32 berechnen und in RTC-Memory schreiben
  write_rtc_memory((millis()-awake_time));
  
  pulse_pin(TRIGGER_PIN);  // ==> 10

  // schlafen gehen
  //WiFi.disconnect(true);
  //delay(1);
  
  pulse_pin(TRIGGER_PIN);  // ==> 11
  digitalWrite(START_STOP_PIN, LOW);

  ESP.deepSleep(deepsleep_time, WAKE_RF_DISABLED);
  
}

Die Routine pulse_pin() erzeugt oben angesprochene Impulse für die 
Auswertung, die Zahlen in den Kommentaren korrespondieren mit den 
Abschnitten (grüne Kurve) im Diagramm. Die Routinen in den Abschnitten 6 
und 7, die mich am meisten interessieren und aus welchen Gründen auch 
immer, sehr lang sind, hatte ich ja oben schon aufgelistet... Dort 
passiert halt nicht sehr viel, aber trotzdem wird jeweils fast eine 
Sekunde "verbraten". Deshalb meine Frage....

Stefan ⛄ F. schrieb:
> Finde heraus, an welchen Stelle sich deine Code-Ausführung in den beiden
> fraglichen Zeitabschnitten befindet. Ich würde dazu ggf. weitere
> debug-Meldungen hinzufügen. Zeiche das dann im Diagramm ein.

Für Abschnitt 6 (wifi_connect) könnte ich noch weiter unterteilen, 
stimmt und werde ich nochmal machen. Abschitt 7 (mqtt_reconnect()) 
besteht eigentlich nur aus mqtt_client.connected() und da finde ich die 
(konstante!) Sekunde "Bedenkzeit" schon recht happig.

Irgendwie werde ich das Gefühl nicht los, dass da Dinge sind, die ich 
mit meinem Code nicht beeinflussen kann und unterlagert noch laufen?

Grüße & Danke Uwe

[Stefan F. (Gast)]

Uwe B. schrieb:
> Die Routinen in den Abschnitten 6
> und 7, die mich am meisten interessieren und aus welchen Gründen auch
> immer, sehr lang sind, hatte ich ja oben schon aufgelistet..

Der Wifi Verbindungsaufbau dauert typischerweise 1 bis 5 Sekunden.

Den Verbindungsaufbau zum MQTT Server kannst du auf dem Server mal mit 
Wireshark (oder tcpdump) aufzeichnen, dass siehst du welcher der 
Verbindungsteilnehmer langsam ist.

[Timmo H. (masterfx)]

Stefan ⛄ F. schrieb:
> Der Wifi Verbindungsaufbau dauert typischerweise 1 bis 5 Sekunden.
Also bei mir dauert das im Schnitt immer 200ms (connect_time) (Auflösung 
ist aber wegen delay(100) auch nur 100ms ;-), und das ohne statische IP. 
Alle paar Stunden oder Tage verschluckt sicher Router mal, dann dauerts 
auch mal 2 oder 3 Sekunden.
MQTT Connect (mqtttime) dauert meist 20ms bei mir.

Arduino Core 2.6.3
ESP8266 2.4.0

void setup() {
    int tries = 0;
    // put your setup code here, to run once:
    Serial.begin(115200);
    

    bool status;
    
    // default settings
    // (you can also pass in a Wire library object like &Wire2)
    status = bme.begin(BME280_ADDRESS_ALTERNATE);  
    if (!status) {
        Serial.println("Could not find a valid BME280 sensor, check wiring!");
        //while (1);
    }
    
    //Serial.println("-- Default Test --");
    delayTime = 3000;
    bme.setSampling(Adafruit_BME280::MODE_FORCED,
                    Adafruit_BME280::SAMPLING_X1, // temperature
                    Adafruit_BME280::SAMPLING_X1, // pressure
                    Adafruit_BME280::SAMPLING_X1, // humidity
                    Adafruit_BME280::FILTER_OFF );

    connect_time = millis();

    WiFi.mode(WIFI_STA);
    WiFi.begin(ssid, password);

    while (WiFi.status() != WL_CONNECTED) {
        delay(100);
        Serial.print(".");
        if(tries++ > 40){
          Serial.println("Conn Timeout");
              ESP.deepSleep(60e6);
              delay(100);
        }

    }
    connect_time = millis()-connect_time;

    pinMode(15,OUTPUT);
    digitalWrite(15, HIGH);

    Serial.println("");
    Serial.println("WiFi connected");
    Serial.println("IP address: ");
    Serial.println(WiFi.localIP());

    Serial.println();
    client.setServer(mqtt_server, 1883);

}

void loop() {
    mqtttime = millis();
    if (!client.connected()) {
        reconnect();
    }
    mqtttime = millis()-mqtttime;

    client.loop();
    get_BME_Values();
    get_Batt_voltage();
    publishMQTTdata();
    delay(100);
    ESP.deepSleep(5*60e6);
    delay(100);
}

void reconnect() {
  // Loop until we're reconnected

  while (!client.connected()) {
    Serial.print("Attempting MQTT connection...");
    // Attempt to connect
    if (client.connect("BME280_Client")) {
      Serial.println("MQTT connected");
    } else {
      Serial.print("failed, rc=");
      Serial.print(client.state());
      Serial.println(" try again in 5 seconds");
   
      // Wait 5 seconds before retrying
      delay(200);
    }
  }
}

[Uwe B. (boerge)]

:-(

Timmo H. schrieb:
> Also bei mir dauert das im Schnitt immer 200ms (connect_time) (Auflösung
> ist aber wegen delay(100) auch nur 100ms ;-), und das ohne statische IP.

...da steht nichts anderes im Code, als bei mir. So ganz glaube ich dir 
die 200ms nicht...

Timmo H. schrieb:
> MQTT Connect (mqtttime) dauert meist 20ms bei mir.

....dito

Grüße Uwe

[Timmo H. (masterfx)]

Uwe B. schrieb:
> ...da steht nichts anderes im Code, als bei mir. So ganz glaube ich dir
> die 200ms nicht...
Siehe Bild oben. Die connect_time wird auch per MQTT an den Server 
gesendet und erzeugt den Plot im Bild. Warum sollte ich lügen?!
Der größte unterschied zu dir ist das ich halt keine statische 
IP-Verwende. Eine statische IP verhindert ja nicht, dass du dich nicht 
trotzdem beim Router anmelden müsstst. Vielleicht ist das sogar 
kontraproduktiv?!
Meine Fritzbox ist übrigens nur die fürs WLAN zuständig, der DHCP läuft 
auf dem ein Vodafone Modem der via LAN an der FB hängt.

uint8_t publishMQTTdata(){
    char msg[128];
    snprintf(msg,128,"{ \"name\": \"BME280\", \"Temp\" : %.2f, \"Pressure\" : %.4f, \"Humidity\": %.2f, \"vBat\" : %.3f }",BME_Data.temp,BME_Data.pressure, BME_Data.humidity, BME_Data.vbat);
    client.publish("/balkon/weather", msg);
    snprintf(msg,128,"{\"t1\":%ld, \"t2\": %ld }",connect_time, mqtttime);
    client.publish("/balkon/stat", msg);

}

[Uwe B. (boerge)]

Uwe B. schrieb:
>> MQTT Connect (mqtttime) dauert meist 20ms bei mir.
>
> ....dito

...hmmm, ausser vielleicht --> macht es einen Unterschied, ob man 
bestimmte Dinge in loop() statt in setup() macht (z.B. das MQTT-Gedöns)?

Grüße Uwe

[Timmo H. (masterfx)]

Kein Plan, kann auch am Router, DHCP oder statischer IP liegen. Einfach 
ausprobieren.
Auf jeden Fall hält mein 750mAh Akku 3-4 Monate (siehe Bild unten recht, 
heute gerade wieder gewechselt nach 104 Tagen)

[Uwe B. (boerge)]

Moin,

Timmo H. schrieb:
> Der größte unterschied zu dir ist das ich halt keine statische
> IP-Verwende. Eine statische IP verhindert ja nicht, dass du dich nicht
> trotzdem beim Router anmelden müsstst. Vielleicht ist das sogar
> kontraproduktiv?!

...nach der Theorie eigentlich nicht, da der DHCP-Server keine Lease 
verteilen muss. (In einem meiner (frühen) Experimente könnte man es, 
glaube ich, auch sehen...).

Timmo H. schrieb:
> Warum sollte ich lügen?!

...ist vielleicht falsch rüber gekommen, war nicht so gemeint ;-). Macht 
mich halt nur nachdenklich, da ich keine entscheidenden Unterschiede 
zwischen deinem und meinem Code sehe bzw. keine schlüssige Erklärung 
dafür habe...

Grüße Uwe

[Michael U. (amiga)]

Hallo,

Timmo H. schrieb:
> Also bei mir dauert das im Schnitt immer 200ms (connect_time) (Auflösung
> ist aber wegen delay(100) auch nur 100ms ;-), und das ohne statische IP.
> Alle paar Stunden oder Tage verschluckt sicher Router mal, dann dauerts
> auch mal 2 oder 3 Sekunden.
> MQTT Connect (mqtttime) dauert meist 20ms bei mir.

grundsätzlich bestätige ich Deine Zeiten, habe aber zuletzt nur mit dem 
ESP32 getestet, da hatte ich um 300ms incl. MQTT-connect in Erinnerung.
Beim ESP32 habe ich eben auch den Effekt, daß er manchmal, heschätzt 
1-2x am Tag bei 5min Raster, lange braucht, dabei dann aber immer stabil 
4-4,2s..
Sollte ich mal meine Stromaufnahme nachmessen? ESP8266/BME280/BH1750 mit 
400mAh haben bei mir nur ca. 3 Wochen durchgehalten.
Ist mir aber eigentlich egal, der Sensor steht auf dem Balkon und der 
Akku ist zum Laden in gut 30s ausgetauscht.

Gruß aus Berlin
Michael

[Uwe B. (boerge)]

Moin,

Uwe B. schrieb:
> Timmo H. schrieb:
>> Der größte unterschied zu dir ist das ich halt keine statische
>> IP-Verwende. Eine statische IP verhindert ja nicht, dass du dich nicht
>> trotzdem beim Router anmelden müsstst. Vielleicht ist das sogar
>> kontraproduktiv?!
>
> ...nach der Theorie eigentlich nicht, da der DHCP-Server keine Lease
> verteilen muss. (In einem meiner (frühen) Experimente könnte man es,
> glaube ich, auch sehen...).

...ich habe das "DHCP-Experiment" (ohne feste IP; also kein 
wifi.config(...)) mit der jetzigen Konstellation nochmal gefahren. Im 
angehangenen Diagramm sieht man deutlich die Zeit, die der ESP auf die 
IP-Konfiguration wartet...

Man sieht aber auch, dass der Zeitraum davor immer noch unverändert da 
ist, also muss es etwas anderes sein...

Grüße Uwe