Neues Feature: OTA-Update via WebGUI

@tuniii @biologist
Ich hab jetzt hier im Thread nichts dazu gefunden, vielleicht gehts ja gar nicht, aber könnte man vielleicht auch WROOMs „einfach“ OTA-fähig machen, indem man die Firmware zweistufig aktualisiert?
Bei vielen meiner ESP8266-Geräten mit Tasmota muss ich das auch machen.

Da gibts eine kleine „minimal“-Firmware, die nichts kann außer einer rudimentären WebGUI und der Möglichkeit die „richtige“ Firmware hochzuladen, diese Firmware ist bei Tasmota um die 400kb groß.

Man updated dann von einer „richtigen“ Firmware immer erstmal in die „minimal“ Firmware und dann auf die nächste Version der „richtigen“ Firmware. Durch die deutlich geringere Größe der Minimal-Firmware brauchts dann nicht die doppelte Flash-Größe, sondern eben nur „ein bisschen“ freien Platz :slight_smile:
Ich stell mir das gerade so vor, als würde man über ein paar „ifdef“ z.B. Bluetooth, RFID, Sound-Decoder etc. etc. einfach nicht in die minimal-FW eincompilen und hätte damit ohne viel Aufwand eine minimal-FW.

Wahrscheinlich ist es in Wirklichkeit deutlich aufwendiger, aber vielleicht als Gedankenanstoß für die nächste Rennrad-Tour oder Joggen :smiley:

Puh, also ich kenne Tasmota, nutze es auch (auf Sonoff S20) und kenne auch den Mechanismus. Aber ehrlich gesagt habe ich mich noch gar nicht darum gekümmert, wie das umgesetzt ist. Also auf jeden Fall ist es erheblich viel Aufwand. Möchte ich erstmal nicht in Aussicht stellen, aber wer weiß…

Da ich meinem Espuino in letzter Zeit nicht allzu viel Liebe geschenkt habe, hab ich heute mal das OTA Feature getestet.
Von 202111x auf 20220601-1 war straight-forward und lief ohne Probleme, da ich gleich noch ein paar Settings getestet habe, hab ich gleich noch paar mal drüber geflashed (ebenfalls via OTA)
Dabei ist mir aufgefallen, wenn man während aktivem Playback ein update einspielt, erhält man starkes ruckeln.

Aber das ist schon jammern auf ganz hohem Niveau. Würde das playback hier stoppen/pausieren.

patch.diff.txt (456 Bytes)

2 „Gefällt mir“

Hab’s hinzugefügt:

Lange nicht mehr genutzt , aber immer noch Probleme nach OTA-Update.
Gestern OTA-Update mit MacOS gemacht , bootet falsch. Nochmal , immer noch falsch. Gleiches Image vom iPhone geflasht , ok .
Heute nochmals das gleiche Verhalten.
Wieso mag der ESP mein iPhone und meinen iMac nicht ? Ich hatte das schonmal mit OTA von Windows aus , ging absolut nicht. Damals aber mit iMac ok.
Gibt es dazu neue Erkenntnisse? Habe mal gegoogelt aber nichts gefunden was mir weiterhilft .

Hast das mal mit Arduino2 getestet? Vielleicht ändert das ja was.
Ich finde das OTA-Update über die WebGUI eigentlich auch gar nicht so praktisch. Man kann das auch direkt in platformio.ini integrieren, aber das skaliert halt nicht so, wenn man mehr als einen ESPuino hat. Also zumindest mal nicht automatisch. Damit hatte ich jedenfalls mit meinem ESP32 im Gartenhaus mit Updates noch keine Probleme. Die mache ich allerdings auch nicht so oft :slight_smile:

nee , noch nicht, wollte ich am WE angehen.
Funktionierendes OTA wäre schon cool. Dann könnte ich meinem Sohn in Kanada die Firmware schicken und er flasht es mit seinem Handy. Jetzt haben die Kleinen immer noch den Code von Dez. 2021 drauf.

Wenn das komplett reproduzierbar ist, könntest Du mal versuchen mit dem Python-Tool : Over The Air Updates (OTA) - ESP32 - — ESP-IDF Programming Guide latest documentation
Die OTA-Data-Partion auszulesen um den Status zu erfahren.
Wenn ich das richtig verstanden habe, wird beim OTA-Update ja immer die gerade nicht aktive Partition beschrieben.
Dann wird die aktive (zu bootende) Partition gewechselt und es kommt zum reset.

Entweder ist der Upload nicht erfolgreich bei Dir und die neue Partition damit nicht „valid“ und / oder der Wechsel auf die neue Partition klappt nicht.

Benutzt Du Safari? Hast Du es mal mit Chrome probiert?

Ich hatte irgendwann auch aufgehört aber finde es ebenfalls super praktisch.
Wir hatten hier doch auch mal das Thema, dass nach einem Update per USB trotzdem noch die alte Firmware geladen wird. Das hängt glaube ich auch damit zusammen, dass dann die aktive Partition nicht geändert wird. USB schreibt dann eine Partiion neu (und ich glaube USB schreibt immer auf „0“) und gebootet wird halt trotzdem „1“. Löscht man dann „alles“ wird die OTA-Data-Parttion gelöscht und er bootet wieder von 0. Man kann beim flashen irgendwie die Option nachschieben, dass die aktive Partition geändert wird bzw. die OTA-Data-Partition gelöscht wird.
Aber wie das so ist, wenn man dann die Zeit dazu verliert :frowning:

Hi
Alles was du schreibst kann ich so bestätigen . Ich benutze meist Safari , es passiert aber auch mit Edge oder Chrome unter Windows. Und natürlich auch mit USB. Manchmal habe ich schon gedacht es läge an einem Wechsel zwischen den Browsern oder Betriebssystemen , so als würde in Vscode irgendwo was abgelegt werden. In aller Regel benutze ich MacOS per USB oder OTA und dann passiert der Fehler gefühlt nie . Nur wenn ich was anderes zwischendurch nehme habe ich es bisher gehabt.
Ich habe auch schonmal irgendwo gelesen dass man gezielt eine Partition flashen kann um, wie in dem Beitrag beschrieben Remote ,auf den ESP zu kommen um eine defekte Installation zu reparieren.
Ich bin aber nicht fit genug das zu erforschen .
VG

In deinem Projektverzeichnis gibt es einen Unterordner .pio. Dort ist build drin und da findest du die firmware.

Ich hab mich jetzt noch einmal mit OTA beschäftigt und würde hier gerne noch einmal die Dinge zusammenfassen und um Unterstützung bitten:

OTA

  • Wenn OTA zur Verfügung steht (8 MB Flash), existieren zwei App-Partitionen im Flash-Speicher (OTA0 und OTA1).
  • Zusätzlich existiert eine OTA-Data-Partition, in welcher (u.a.) gespeichert wird, welche App-Partition gerade aktiv ist.
  • Bei einem OTA-Update wird die jeweils nicht verwendete OTA-Partition mit der neuen Software beschrieben und anschliessend wird diese als „aktiv“ markiert.
  • Nach eine Reboot wird die neue Software gestartet.
  • Das funktioniert immer im Wechsel und somit kann entweder OTA0 oder OTA1 die gerade aktive App-Partition sein,

OTA-Bug

  • Bei einem Update über USB/Seriell wird IMMER die App-Partition OTA0 beschrieben.
  • Wenn nun - durch vorherige OTA-Updates - OTA1 gerade die aktive App-Partition ist, wird weiterhin OTA1 gestartet.
  • Die per USB/Seriell aktualisierte Software wird nicht gestartet.

Lösungen

  • „Erase Flash“. Damit wird alles gelöscht (auch die OTA-Data-Partition) und somit auch wieder von OTA0 gestartet. Nachteil: Es wird alles gelöscht…
  • esptool.py erase_region 0x9000 0x2000 Löscht nur die OTA-Data-Partition. Wobei „0x9000“ evtl.angepasst werden muss. Das ist die Startadresse der OTA-Data-Partition.

To do:

  • Bei einem einfachen OTA Sketch (OTA Demo) tritt das Problem nicht auf. Dann wird (vom esptool) die aktive Partition wieder zurück auf OTA0 gesetzt.

    • esptool and OTA conflict - ESP32 Forum > As you’ve noticed, the default flasher commands in master branch now erase the ota_data partition and flash the default partition (factory or OTA slot 0 if no factory partition is present) each time. This will be in the V3.2 release.
    • Vermutung: Bei Verwendung einer angepassten Partitionskonfiguration (z.B. custom_8mb_ota.csv) wird die OTA-Data-Partition nicht angefasst.
  • PlatformIO „PreAction Script“ schreiben, um „erase_region“ automatisch ausführen zu lassen. OTADATA not reset on code upload for ESP32 - PlatformIO Community

    • Hier müsste man am besten prüfen, ob OTA verwendet wird und wenn ja, welche Adresse die OTA-Data-Partition hat.
  • Ich hab’ zum debuggen die Funktionen esp_ota_get_boot_partition() und esp_ota_get_running_partition() eingebunden. So kann man sehen, welche App-Partition gerade aktiv ist. → Könnte man auch im Web-UI anzeigen.

    • Man könnte im der Web-UI sogar die aktive Partition wechseln :face_with_raised_eyebrow:
  • Ergänzungen / Korrekturen / Vorschläge ? :smiley:

  • Python - Spezis hier um das PlatformIO Script zu erstellen?

1 „Gefällt mir“

Da rufe ich mal @fetzerch :slight_smile:

Sowas in etwa?

Ich nutze im Moment kein OTA. Gerne testen und feedback geben. Habe auch nichts dagegen, wenn jemand anders den PR übernimmt und fertig macht.

4 „Gefällt mir“

Danke @fetzerch - ich teste das gerne in dieser Woche.

1 „Gefällt mir“

Ich bin jetzt endlich dazu gekommen das zu testen.

Sieht in meiner Umgebung sehr gut aus! Die OTA Partition wird gelöscht und immer von der app0 gestartet.
Bei den beiden Todo’s im PR kann ich leider nicht helfen. Ich habe versucht den code in otatool.py zu verstehen. Ich würde meinen, dass vorab eine Prüfung stattfindet. Kann man das nicht so lassen?

Ich habe in diesem Zusammenhang noch ein paar Anpassungen für OTA gemacht:

Evtl. bekommt man damit auch die weiter oben beschriebenen Probleme in den Griff.
Es wird damit im Log (und in der WebUI unter Info) angezeigt, von welcher OTA-Partition gestartet wurde:

[ 586 ]  Software-revision: 20230108-1
[ 586 ]  Git-revision: 411d98a-dirty
[ 596 ]  ESP-IDF version: v4.4.3
[ 603 ]  OTA-Info: Running: app1 | Boot: app1 | Next-OTA: app0
1 „Gefällt mir“

Ich benutze meinen Espuino hauptsächlich als „Frühstücksradio“ . Dazu habe ich eine .m3u mit 10 Streams.
@biologist Ist es machbar beim Abspielen von m3u-Listen mittels der Tasten vor und zurück über die Endpunkte in beide Richtungen hinauszurollen ?
Ich meine von 1 ans Ende und vom Ende wieder zu 1. Das würde den Weg von z. Bsp. Antenne Bayern bis WDR2 deutlich verkürzen.
Ich weiß , langer Tastendruck geht auch…aber Faulheit und WAF.

Das müsste gehen, indem du in nachfolgendem Case noch die Zeile
gPlayProperties.repeatPlaylist = true; einfügst:

In diesem Fall sollte dann das hier greifen:

Prinzipiell geht es , aber manchmal ein Reboot

Rebooting…
ets Jul 29 2019 12:21:46

Inzwischen funktioniert das aber fehlerfrei, oder?
Ich gehe davon aus, dass der Reboot durch den Fehler mit der falschen LED-Adressierung (mitunter 255) passiert ist.

Ist ok, ich hatte nichts mehr