Update- and configuration-strategy for Arduino-based devices

[Andreas]

@clemens

I hesitate a bit with this decision but for a really user friendly configuration without too much external help I see only the chance to do it via WiFi with a tool like WiFi Manager there is a nice description also. You have a graphical user interface without any IDE or cable and library stuff, perhaps you can upload also firmware packages (I have to figure this out).

I’ve recently also discovered GitHub - dreed47/WifiMQTTManager: ESP32/ESP8266 library for managing your IoT devices. and – drumroll(!) – GitHub - prampec/IotWebConf: ESP8266/ESP32 non-blocking WiFi/AP web configuration Arduino library. @Stefan might want to look into that for the Bienenwaage mit TTGO T-CALL und ESP32-Arduino-Software he contributed the other day.

[Stefan]

Hi @Andreas,

By now I’m working with the tzapu/WiFiManager lib with development branch which supports the ESP32.

But the GitHub - prampec/IotWebConf: ESP8266/ESP32 non-blocking WiFi/AP web configuration Arduino library) lib looks quite good at a first short view.

First I’ll go forward with the current solution, but why not have a deeper look at the proposed lib, as the possibility to store custom values looks interesting.

[clemens]

@Stefan

By now I’m working with the tzapu/WiFiManager lib with development branch which supports the ESP32.

I think tzapu’s WiFiManager is the WifiManger used most often in the past. But less activity development in the last month.

Btw. a nice overview and comparison between tzapu’s and prampec’s WifiManager aka IotWebConf now! ;-)

GitHub - prampec/IotWebConf: ESP8266/ESP32 non-blocking WiFi/AP web...

@clemens

perhaps you can upload also firmware packages (I have to figure this out).

Seems also possible GitHub - prampec/IotWebConf: ESP8266/ESP32 non-blocking WiFi/AP web configuration Arduino library

Highlights
[…]
Firmware OTA update support,

[edit] Auch heise.de hat den für eigene Projekte entdeckt: https://www.heise.de/hintergrund/ESP-Projekte-WLAN-mit-IotWebConf-5022556.html und benennt einen Nachteil des WifiManagers:

Kennt der WifiManager noch keine WLAN-Zugangsdaten, wartet die Bibliothek in setup() darauf. loop() führt der ESP dann erst aus, wenn das WLAN konfiguriert ist. Was für viele Smart-Home-Basteleien ein sinnvolles Vorgehen ist, blockiert allerdings Geräte, deren WLAN-Kommunikation nur ein Zusatzfeature ist.

D.h. es wird wohl GitHub - prampec/IotWebConf: ESP8266/ESP32 non-blocking WiFi/AP web configuration Arduino library

[clemens]

@clemens

[edit] Auch heise.de hat den für eigene Projekte entdeckt: Smart-Home-Projekte mit ESP: WLAN mit IotWebConf | heise online und benennt einen Nachteil des WifiManagers:

Kennt der WifiManager noch keine WLAN-Zugangsdaten, wartet die Bibliothek in setup() darauf. loop() führt der ESP dann erst aus, wenn das WLAN konfiguriert ist. Was für viele Smart-Home-Basteleien ein sinnvolles Vorgehen ist, blockiert allerdings Geräte, deren WLAN-Kommunikation nur ein Zusatzfeature ist.

Scheint nicht mehr so zu sein, siehe:

GitHub - tzapu/WiFiManager: ESP8266 WiFi Connection manager with web captive...

[clemens]

wifiManager.startConfigPortal("OnDemandAP"); tut beim WifiManager genau das was es soll, ich habe z.B. einen Testsketch hinbekommen, der nur nach der reset cause POWERON_RESET, d.h. power cycle oder reset button das captive portal lädt. Die custom variables sind beim WifiManager leider kein Spaß. die gibt es zwar konfigurierbar in der UI, um alles was mit denen gemacht werden soll muss man sich aber selbst kümmern, etwa im EEPROM speichern oder wieder auslesen … hatte ich mir anders vorgestellt. Und ein einfaches Beispiel dazu habe ich bisher auch noch nicht gefunden.

Bei IotWebConf ist der use case relativ eindeutig vorgegeben – ein device, das per WiFi mit dem Netz verbunden ist. Im example IotWebConf16OffLineMode.ino gibt es eine Funktion iotWebConf.goOffLine(); die das WLAN-Modul disconnected. Aber initial scheint es dennoch zu laufen, da suche ich noch eine Möglichkeit das on demand zu starten. forceApMode() habe ich mir noch nicht genauer angeschaut, ggf. macht das so was.

[Andreas]

Hi Clemens,

benutzt Du denn nun WiFiManager oder IotWebConf bzw. wäre nicht letzteres Dein Favorit? Wir können ja gerne ein paar Änderungen machen, wenn Dich der aktuelle Umgang mit WiFi dabei irgendwie stört, sofern Du, wie geschrieben, mit dem TTGO T-Call-SIM800L ausschließlich GSM nutzen willst.

Viele Grüße,
Andreas.

[clemens]

Ich habe mich noch nicht entschieden bzw. weiß nicht, ob man mit der einen oder der anderen Bibliothek unser Szenario abdecken kann.

Nach dem heise-Artikel war ja der Stand der Dinge, dass so was mit dem WifiManager nicht möglich ist. Nach meiner Recherche scheint die dort beschriebene zwingende WiFi-Konfiguration kein Blocker zu sein. Doku beim WifiManager ist ganz schön messi und auch in den Beispielen sind kleine Schnitzer drin, die wenig Pflege vermuten lassen.

Mein Favorit wäre momentan IotWebConf, wenn der ganze WLAN-Kram nicht zu sehr “im System” integriert ist. Vielleicht sollte ich mal das heise-Beispiel anschauen … ggf. bin ich dann schlauer.

[Andreas]

@clemens

Ich habe mich noch nicht entschieden bzw. weiß nicht, ob man mit der einen oder der anderen Bibliothek unser Szenario abdecken kann.

@clemens

Mein Favorit wäre momentan IotWebConf.

Ja, ich dachte auch, dass das unser aktueller Favorit wäre. Also schauen wir doch dort, was wir tun können, um es auf Deinen Anwendungsfall anzupassen bzw. zu erweitern?

[clemens]

Das hört sich jetzt nicht so gut an

IotWebConf vermeidet, dass ein ESP beim Abfragen der WLAN-Daten blockiert. Für Geräte, die sowohl für sich als auch eingebunden in ein WLAN funktionieren sollen, ist das eine gute Lösung. Der Preis dafür ist, dass die loop()-Funktion regelmäßig in die Bibliothek springen muss. delay() ist in loop() daher fast verboten und der Code muss stattdessen mit millis() prüfen, ob genug Zeit für den nächsten Schritt vergangen ist. Ein Beispiel, wie so etwas aussieht:

aus: ct 03/2021

Die TinyGSM blockiert definitiv, die Frage ist ob das dann egal ist und dennoch funktioniert.

[Andreas]

@clemens

Ein Beispiel, wie so etwas aussieht:

void loop() {
    iotWebConf.doLoop(); 
    
    // DHT sensor read loop
    unsigned long currentMillis = millis();
    if (currentMillis - previousMillis > SHT20_INTERVAL) {
        previousMillis = currentMillis;
        float humd = sht20.readHumidity();                  // Read Humidity
        float temp = sht20.readTemperature();               // Read Temperature
        <print statements>
    }
    
}

– Execute normal code after configuration. · Issue #123 · prampec/IotWebConf · GitHub

See also Execute normal code after configuration. · Issue #123 · prampec/IotWebConf · GitHub

IotWebConf provides a delay() method, but I also recommend to compare millis instead: (current - start) > diff

[Andreas]

@clemens

Das hört sich jetzt nicht gut an: Die TinyGSM blockiert definitiv, die Frage ist ob das dann egal ist und dennoch funktioniert.

Vielleicht hilft hier auch schon die Begutachtung von @Stefan bei Inbetriebnahme und Weiterentwicklung der Firmware für Arduino (Bienenwaage 2.0 und 5.0) - #40 by Stefan etwas weiter?

[Andreas]

@clemens

Im example IotWebConf16OffLineMode.ino gibt es eine Funktion iotWebConf.goOffLine(); die das WLAN-Modul disconnected. Aber initial scheint es dennoch zu laufen, da suche ich noch eine Möglichkeit das on demand zu starten.

Vielleicht ist die richtige Methode, die direkt aus setup() aufgerufen werden sollte, startupOffLine()?

– IotWebConf on demand as configuration tool · Issue #223 · prampec/IotWebConf · GitHub

[clemens]

@Andreas

Vielleicht hilft hier auch schon die Begutachtung von @Stefan

Er nimmt ja den WifiManager und nicht IotWebConf, kann man machen, muss sich dann aber um das handling der custom Variablen selbst kümmern.

[Andreas]

Hi again,

I also just discovered this library. It doesn’t look bad.

Cheers,
Andreas.

GitHub - khoih-prog/ESP_WiFiManager: This is an ESP32 / ESP8266 WiFi...

This library is based on, modified, bug-fixed and improved from:

1. Tzapu WiFiManager
2. Ken Taylor WiFiManager

to add support to ESP32 besides ESP8266.

[clemens]

Khoi Hoang empfiehlt selbst die oben nicht mehr, sondern die neuere

GitHub - khoih-prog/ESPAsync_WiFiManager: This is an ESP32 (including...

Von ihm gibt es gefühlt 100 Wifi-Manger libs im Arduino-Lib-Manager, ich weiß nicht woher die Inflation kommt. Das wirkt auch alles sehr werbelastig (“Speed is OMG”) und in den Beispielen sind teilweise pin-Definitionen drinnen und anderes für spezifische boards.

Weiter braucht es z.B. für die double reset-button-Funktion eine weitere Bibliothek. Mir ist der Mehrwert dieser lib bisher noch nicht klar.

[clemens]

Michael / @MKO hat unter 8266 - homie battery powered OR Bienenwaage 2.0 NodeMCU? - #8 by MKO darauf hingewiesen, dass einige boards bzw. libs statt eines EEPROMs einen Teil des Flashs (RAM kanns ja nicht sein, oder?) zur permanenten Speicherung von Variablen über einen deep sleep hinaus nutzen:

@MKO

You can get the AB01 very cheaply, directly from Heltec.
[…]
One problem with these is, for example, that they do not have an EEprom on board to save the settings of the scale. Instead, there is a user space in the flash memory that can be used for this.

Bei Michael ging es zwar nicht um einen ESP, mir ist bei einigen captive portal-libs, die wir hier diskutieren auch aufgefallen, dass die mehrere Möglichkeiten anbiten, z.B. https://github.com/khoih-prog/ESPAsync_WiFiManager

ESP8266 and ESP32-based boards using EEPROM, SPIFFS or LittleFS.

LittleFS kenne ich bisher nur vom filesystem der PyCom boards und habe es im Arduino-Umfeld bisher noch nicht gelesen. Scheint aber so was wie eine Flash- oder RAM-Disk zu sein.

Hat das gegenüber dem EEPROM irgendwelche Vorteile, ausser größer? Für so Konfig-Sachen sehe ich gerade keinen Anwendungsfall für uns, aaaber wäre das nicht genau das, was wir schon ewig für den ESP suchen zur temporären Speicherung mehrere Messzyklen, die wir dann – statt bisher alle 5 Minuten – als bulk nur 1x oder 2x am Tag schicken könnten?

[Andreas]

@clemens

Sondern den neueren ESPAsync_WiFiManager.

Oha, die Bibliothek ist aber ordentlich!

This library is based on, modified, bug-fixed and improved from:

1. Tzapu's WiFiManager
2. Ken Taylor's WiFiManager
3. Alan Steremberg's ESPAsyncWiFiManager
4. Khoi Hoang's ESP_WiFiManager

Currently supported Boards

This ESPAsync_WiFiManager library currently supports these following boards:

1. ESP8266 and ESP32-based boards using EEPROM, SPIFFS or LittleFS.
2. ESP32-S2 (ESP32-S2 Saola, AI-Thinker ESP-12K, etc.) using EEPROM, SPIFFS or LittleFS.
3. ESP32-C3 (ARDUINO_ESP32C3_DEV) using EEPROM or SPIFFS.

Und dann auch noch aktiv in der Entwicklung. Das hat für mich definitiv sogar mehrere Bienchen verdient.

[Andreas]

Gerade eben wurde mir noch AutoConnect for ESP8266/ESP32 vorgeschlagen. Bewertung: Sieht ebenfalls ordentlich gemacht aus.

GitHub - Hieromon/AutoConnect: An Arduino library for ESP8266/ESP32 WLAN...

[Andreas]

@Stefan

I’m working with the tzapu/WiFiManager lib with development branch which supports the ESP32.

FWIW, I just also discovered GitHub - alanswx/ESPAsyncWiFiManager: Port WiFiManager to ESP Async Server.

[Stefan]

Thanks @Andreas for the hint,

I managed to build a custom config portal based on the tzapu/WiFiManager - the tricky part for me was the use of checkboxes (not shown here.

The ESP32 checks the presence of an bluetooth token after the sleep period, if the token is present the config portal is started for 15 min. If the token is not present (off) the ESP starts up normal.

Example:

More to come (hope to find the time & muse)