ESP-Claw aktuell halten – Update, Rebuild und Re-Flash auf das Guition JC1060P470

Nachdem ich euch in Teil 4 meiner ESP-Claw-Serie gezeigt habe, wie ich meinen ESP-Claw-Agenten zum ersten Mal mit meinem lokalen Ollama-Server zum Reden gebracht habe, ist erst einmal Ruhe eingekehrt. Mein Guition JC1060P470 läuft, redet mit Qwen 3.6 35B auf meinen RTX A6000-GPUs und tut, was es soll.

Aber ESP-Claw ist ein sehr aktives Open-Source-Projekt. Espressif committet quasi täglich neue Funktionen, Bugfixes und Capabilities ins Repository. Und damit stellt sich für mich als Maker eine ganz praktische Frage: Wie halte ich meine Installation aktuell, ohne dabei meine mühsam erarbeitete Board-Adaption für das JC1060P470 zu verlieren?

Genau dieser Update-, Rebuild- und Re-Flash-Workflow ist Inhalt dieses Beitrags. Klingt erst einmal trocken, ist aber für mich ein echter Maker-Skill geworden, denn ich möchte natürlich nicht gleich beim ersten Versuch ESP-Claw zu aktualisieren meine Konfigurationen verlieren.

Was bleibt vom Setup aus den Teilen 1 bis 4?

Bevor ich loslege, kurz die Ausgangslage bei mir am Rechner zum schnellen Wiedereinstieg:

• ESP-IDF v5.5.4 installiert unter D:\Programme\Espressif554\
• ESP-Claw-Repository geklont nach D:\esp32-claw\esp-claw\
• Eigene Board-Adaption unter application\edge_agent\boards\guition\jc1060p470_m3_dev\
• menuconfig-Anpassung für ESP32-P4-Chip-Revision <3.0
• Auf dem Board gespeichert: WiFi-Zugangsdaten, LLM-Konfiguration für Ollama, Memory-Dateien

Genau diese vier Punkte sind in den nächsten Phasen mein roter Faden, denn jeden davon kann ich beim Update entweder behalten oder versehentlich überschreiben.

Phase 1: Die eigene Board-Adaption zuerst sichern

Meine boards/guition/jc1060p470_m3_dev/-Dateien sind vermutlich das Wertvollste am ganzen Setup. Die YAML-Dateien, die JD9165-Init-Sequenz, die sdkconfig-Defaults das alles war mehrere Abende Arbeit. Wenn ich die verliere, fange ich nicht „ein bisschen“ von vorne an, sondern eigentlich komplett. Ich muss mir wieder alles erarbeiten wie die Konfiguration zustande gekommen ist.

Deshalb ist mein erster Gedanke vor jedem Update: Backup machen.

Für die meisten Maker ist der pragmatischste Ansatz genau der richtige. Die Board-Informationen als *.ZIP DAtei sichern.

Ich habe mir im Ordner D:\esp32-claw\ einen Ordner backups angelegt in dem ich die ZIP Datei speichern möchte. Dann bin ich wie folgt vorgegangen.

Befehl: cd D:\esp32-claw\esp-claw\application\edge_agent

Befehl: Compress-Archive -Path boards\guition -DestinationPath D:\esp32-claw\backups\boards_guition_$(Get-Date -Format yyyyMMdd).zip

Damit habe ich eine Zip-Datei mit Zeitstempel und kann jederzeit den Stand vor dem Update wiederherstellen.

Phase 2: ESP-IDF prüfen – aber nur updaten, wenn nötig

Mein zweiter Reflex früher war es, beim Update gleich auch ESP-IDF auf den neuesten Stand zu bringen. Davon rate ich mittlerweile ab. Eine neue ESP-IDF-Version kann ihre eigenen Inkompatibilitäten mitbringen, und ich will beim Update nicht zwei Variablen gleichzeitig verändern.

Mein Vorgehen heute:

1. Zuerst nur ESP-Claw updaten und sehen, ob die aktuelle ESP-IDF-Version (bei mir v5.5.4) noch reicht
2. Nur falls der Build mit einer klaren Fehlermeldung wie „requires ESP-IDF >= v5.x.x“ abbricht, eine neuere ESP-IDF-Version nachinstallieren
3. Die neue ESP-IDF-Version wird parallel installiert, nicht über die alte drüber

Genauso, wie ich es in Teil 2 der Serie für v5.5.4 beschrieben habe.

Phase 3: Das ESP-Claw-Repository aktualisieren

Jetzt geht es ans eigentliche Update. Wichtig: Immer in der „ESP-IDF 5.5 PowerShell“ arbeiten, nicht in einer normalen Windows-PowerShell.

Zuerst schaue ich, in welchem Zustand mein lokales Repo gerade ist:

Befehl: cd D:\esp32-claw\esp-claw

Befehl: git status

Wenn ihr so vorgeht wie ich hier beschireben habe, dann seht ihr wahrscheinlich die Änderungen unter „Untracked files“ oder „Modified files“. Genau diese will ich erst einmal rausnehmen, damit git pull sauber durchläuft:

Befehl: git stash --include-untracked

git stash legt meine lokalen Änderungen wie eine Schublade beiseite. Sie sind nicht weg, ich kann sie später mit git stash pop wieder hervorholen.

Jetzt schaue ich, was es überhaupt Neues beim ESP-claw gibt:

Befehl: git fetch

Befehl: git log HEAD..origin/master --oneline

So bekomme ich eine Liste aller Commits, die seit meinem letzten Stand auf dem master-Branch hinzugekommen sind. Bei mir waren das beim ersten Update 47 neue Commits in ein paar Tagen. Das ist eine ordentliche Menge. Falls ihr nach dem Aufruf in einem Pager mit [END] am unteren Bildschirmrand landet, einfach q drücken und ihr seid wieder zurück in der PowerShell.

Jetzt der eigentliche Pull:

Befehl: git pull --rebase

Den Schalter --rebase nutze ich, damit meine eigenen Commits sauber auf den neuen Stand draufgesetzt werden, statt einen unschönen Merge-Commit zu erzeugen.

Ganz wichtig danach: Die Submodule mitziehen, sonst hat man eine Mischung aus neuem Hauptcode und alten Submodulen.

Befehl: git submodule update --init --recursive

Bei mir hat dieser Schritt mehrere Sekunden gedauert, weil unter anderem ESP-Hosted und LVGL frische Versionen mitgebracht haben.

Phase 4: Stash zurückholen oder Backup einspielen

Je nach Variante aus Phase 1 sieht der nächste Schritt unterschiedlich aus:

Das ZIP-Backup:

Befehl: Expand-Archive -Path D:\esp32-claw\backups\boards_guition_<Datum>.zip -DestinationPath .\application\edge_agent\boards\ -Force

Damit kopiere ich meine gesicherte Board-Adaption wieder an die richtige Stelle im aktualisierten Repo.

Falls es jetzt Merge-Konflikte gibt – bei mir war das einmal der Fall – zeigt git status mir die betroffenen Dateien. Konflikte in YAML- oder Kconfig-Dateien sind meistens harmlos, weil meine Board-Adaption keine Datei verändert, die auch Espressif selbst pflegt. Bei Konflikten in setup_device.c würde ich aber genauer hinschauen und mir die History des Originals mit git log ansehen.

Mein Hinweis aus der Praxis: Achtet darauf, dass nach dem Wiederherstellen keine alten Backup-Dateien mit der Endung .c in eurem Board-Verzeichnis liegen (zum Beispiel setup_device_DISPLAY_BACKUP.c). ESP-IDF zieht beim Build automatisch alle .c-Dateien aus dem Boards-Ordner in die Kompilierung mit ein, und so eine Backup-Datei bringt den Build mit unbekannten Typen und ungenutzten Konstanten zum Absturz. Solche Dateien einfach auf .c.bak umbenennen oder ganz aus dem Boards-Verzeichnis nehmen.

Phase 5: Tooling-Updates nicht vergessen

ESP-Claw bringt das Python-Tool esp-bmgr-assist mit, das aus meinen YAML-Dateien C-Code generiert. Dieses Tool wird parallel zum Repo weiterentwickelt und wenn ich es nicht mit-aktualisiere, läuft mein idf.py gen-bmgr-config mit einer veralteten Version, die das neue Schema vielleicht gar nicht versteht.

Befehl: pip install --upgrade esp-bmgr-assist

Bei mir kam dabei ein Sprung von v0.8.1 auf eine neuere Version zustande, und das hat tatsächlich einen Fehler beim späteren Build behoben, den ich sonst lange nicht verstanden hätte.

Phase 6: Komponenten neu auflösen und gen-bmgr-config erneut laufen lassen

Jetzt wechsle ich in das Edge-Agent-Verzeichnis:

Befehl: cd application\edge_agent

Mit den neuen Submodulen und einem aktualisierten Code-Stand kann es sein, dass ESP-IDF einige seiner managed components neu auflösen will. Ein Reconfigure stößt das sauber an:

Befehl: idf.py reconfigure

Danach lasse ich den ESP Board Manager erneut über meine YAML-Dateien laufen. Das ist wichtig, weil neue Schemaversionen ab und zu zusätzliche Pflichtfelder einführen, die der Build sonst monieren würde:

Befehl: idf.py gen-bmgr-config -c ./boards -b jc1060p470_m3_dev

Wenn ich am Ende wieder etwas wie Successfully validated 7 peripherals und Successfully validated 6 devices sehe, ist die Adaption mit dem aktuellen Schema kompatibel. Wenn nicht, bekomme ich an dieser Stelle eine klare Fehlermeldung mit Zeilennummer in der jeweiligen YAML und kann gezielt nachbessern. Lieber jetzt als später mitten im Build.

Phase 7: Die Chip-Revision dauerhaft festschreiben

Hier ist meine wichtigste Lektion aus dem ersten Update: Die in Teil 2 per menuconfig gesetzte Chip-Revision-Anpassung für meinen alten ESP32-P4 v1.3 ist nach einem idf.py fullclean weg. Die Datei sdkconfig wird dabei neu erzeugt, und damit verliere ich die manuelle Anpassung.

Die saubere Lösung: Die Einstellung in meine sdkconfig.defaults.board aufnehmen. Damit wandert sie ins Versionskontrollsystem und überlebt jeden Clean-Build:

# Chip revision range for older ESP32-P4 silicon (Guition JC1060P470 hat v1.3)
CONFIG_ESP32P4_REV_MIN_FULL=0
CONFIG_ESP32P4_REV_MAX_FULL_NUM=199

Ich hatte diese zwei Zeilen schon vor dem Update hier D:\esp32-claw\esp-claw\application\edge_agent\boards\guition\jc1060p470_m3_dev\sdkconfig.defaults.board ganz am Ende ergänzt und kann das nur jedem empfehlen, der auch ein älteres P4-Board einsetzt. Spart bei jedem Rebuild einen Schritt und vermeidet Fehlersuche, wenn die Firmware plötzlich nicht mehr bootet.

Wer ein neueres Board mit P4 v3.0+ hat (ESP32-P4 Function EV Board, M5Stack Tab5), kann diesen Schritt natürlich weglassen.

Phase 8: Der neue Build

Jetzt kommt die Stunde der Wahrheit:

Befehl: idf.py build

Bei mir lief das Update an dieser Stelle in zwei Modi durch:

Wenn ich ehrlich bin, ist nach einem größeren ESP-Claw-Update fast immer ein Full Rebuild angesagt, weil Espressif Header-Dateien tief unten anfasst und dann alle abhängigen Module neu kompiliert werden müssen.

Am Ende sehe ich wieder eine Ausgabe wie diese:

edge_agent.bin binary size 0x2b0760 bytes. Smallest app partition is 0x400000 bytes. 0x14f8a0 bytes (33%) free.

Bei mir ist die Firmware nach dem Update leicht gewachsen auf etwa 2,82 MB mit 33 % freiem Platz in der App-Partition. Das ist normal, weil neue Capabilities zusätzlichen Code mitbringen. Solange noch genug Platz auf der App-Partition ist, ist alles in Ordnung.

Phase 9: Was bleibt beim Flash erhalten und was nicht?

Vor dem Re-Flash will ich genau wissen, was auf dem Board mein Update überlebt und was nicht. Und an dieser Stelle muss ich euch eine ehrliche Maker-Anekdote erzählen, denn genau hier bin ich beim ersten Update mit Karacho in die Falle gelaufen.

Mein erster Reflex war: „Ich nutze einfach idf.py flash, das wird schon das richtige machen.“ Falsch gedacht. Nach dem Flash war mein Provisioning-AP esp-claw-000000 wieder aktiv, das WLAN-Passwort weg, die Ollama-Konfiguration leer und meine Memory-Dateien auf den Default-Stand zurückgesetzt. Ich durfte das komplette Provisioning aus Teil 4 noch einmal durchspielen und habe meine gelernten Skills verloren.

Der Grund liegt im Flash-Kommando, das ESP-IDF intern aufruft. Schaut euch mal die Zeile an, die idf.py flash tatsächlich ausführt:

esptool.py ... write_flash ...
  0x2000   bootloader/bootloader.bin
  0x8000   partition_table/partition-table.bin
  0x10000  ota_data_initial.bin
  0x20000  edge_agent.bin
  0xb20000 storage.bin     ← ← ← ← ← 

Die letzte Zeile ist der entscheidende Punkt: Bei einem normalen idf.py flash schreibt ESP-Claw eine frische storage.bin auf die FATFS-Partition bei 0xb20000 und damit sind alle dort liegenden Inhalte überschrieben. Bei ESP-Claw landen WiFi-Credentials, LLM-Konfiguration und Memory-Dateien nämlich genau in dieser Storage-Partition, nicht im NVS, wie ich ursprünglich vermutet hatte.

So sehen die Partitionen auf meinem 16-MB-Flash aus:

Das heißt im Klartext: Ein normales idf.py flash setzt mein Board faktisch in den Werkszustand zurück, weil die storage.bin mitgeflasht wird. Das ist sinnvoll beim allerersten Flash, ein riesiger Stolperstein aber bei jedem späteren Update.

Die saubere Lösung kommt aus ESP-IDF selbst und heißt app-flash. Dieser Befehl schreibt nur die App-Partition mit der neuen edge_agent.bin und lässt alle anderen Partitionen, vor allem die storage.bin, unangetastet:

Für jedes folgende Update nutze ich nur noch die sanfte App-Flash-Variante. Den vollen Flash hebe ich mir für den allerersten Setup-Lauf auf, den harten Reset für Fälle, in denen sich das Board partout nicht mehr fängt.

Phase 10: Re-Flash und Monitor

Jetzt das Board anschließen, den richtigen COM-Port heraussuchen (bei mir COM7) und losflashen.

Um den richtigen Port zu finden kannst Du den folgenden Befehl ausführen.

Befehl: Get-PnpDevice -Class Ports -PresentOnly | Format-Table FriendlyName, Status

Ich nutze gleich den Modus, der nach dem Flash sofort den seriellen Monitor öffnet, und natürlich app-flash statt flash:

Befehl: idf.py -p COM7 app-flash monitor

Was ich im Boot-Log sehen will, ist im Wesentlichen dasselbe wie in Teil 4:

• PSRAM mit 32 MB bei 200 MHz Octal-Mode erkannt
• Alle Peripherie-Blöcke aus meiner YAML initialisiert
• Beide ES8311-Codec-Instanzen gestartet
• ESP-Hosted Host-Seite beginnt SDIO-Probe
• ESP32-C6 als Slave erkannt

Der entscheidende Unterschied zum allerersten Flash: Mein Board verbindet sich diesmal direkt mit meinem Heim-WLAN, weil die WiFi-Credentials in der Storage-Partition unangetastet geblieben sind. Im Log erscheint nicht mehr Provisioning AP active, sondern direkt:

wifi station: connected to <meine_SSID>, IP: 192.168.178.161

Genau das ist das Ergebnis, das ich wollte. Kein erneutes Provisioning, keine Captive-Portal-Akrobatik, kein Kampf mit Android. Das Board taucht direkt wieder mit der bekannten IP-Adresse im LAN auf. Mit Strg + ] komme ich später aus dem Monitor wieder zurück in die PowerShell.

Phase 11: Funktions-Check und neue Capabilities entdecken

Über die alte LAN-IP rufe ich die ESP-Claw-Web-UI auf und prüfe drei Dinge:

1. System Settings → LLM: Sind meine Ollama-Einstellungen noch da? (Base URL, Modellname, Timeout)
2. Memory: Sind Soul, Identity und User Info noch unverändert?
3. Capabilities: Sind eventuell neue Capabilities dazugekommen, die ich aktivieren möchte?

Der dritte Punkt ist für mich der eigentliche Reiz an Updates. Bei meinem letzten Update kamen tatsächlich zwei neue Capabilities dazu, die ich später noch tiefer ansehen will. Das sind genau die Bausteine, mit denen ich meine Roboter-Auto-Steuerung anbinden kann.

Zum Abschluss noch ein kurzer Test im Web Chat:

Are you still there?

Wenn die Antwort flüssig zurückkommt, läuft die komplette Kette nach dem Update unverändert: Browser → ESP-Claw → Ollama → A6000 → Qwen 3.6 → Antwort.

Mein persönliches Fazit zu Teil 5

Ein Update-Workflow klingt nach Buchhalterei, ist aber für mich zu einer wichtigen Maker-Disziplin geworden. Drei Lernpunkte nehme ich aus den ersten Updates mit:

1. Die eigene Board-Adaption sichern. Ein einfaches ZIP-Backup vor jedem git pull ist das einfachste und sicherste Vorgehen um nichts zu verlieren.
2. sdkconfig.defaults.board. Alles, was per menuconfig gesetzt werden müsste, gehört in diese Datei, sonst überlebt es keinen Clean-Build und ich darf jedes Mal von vorne anfangen.
3. idf.py app-flash statt idf.py flash beim Update. Das ist der entscheidende Unterschied zwischen einem sanften Firmware-Update und einem versehentlichen Werksreset, bei dem WiFi, LLM-Konfiguration und Memory-Dateien verloren gehen.

Souveräne KI bedeutet für mich am Ende auch: Den eigenen Stack selbst pflegen zu können, ohne auf eine fremde Cloud, ein fremdes Update-System oder einen fremden App-Store angewiesen zu sein.

Im nächsten Teil kehre ich zurück zum eigentlichen KI-Thema. Ich tauche tiefer in die Architektur ein und schaue mir an, was Capabilities und Skills im Detail sind, wie sie sich unterscheiden und wie das Zusammenspiel zwischen LLM, Lua-Runtime und Hardware funktioniert. Genau dieses Verständnis brauche ich, bevor ich meine eigenen Skills schreibe um mein Roboter-Auto zu steuern.

Wir lesen uns im nächsten Teil!

Was kommt in den nächsten Beiträgen?

• Teil 1: Auftakt und Vorstellung der Vision
• Teil 2: ESP-IDF v5.5.4 einrichten und ESP-Claw bauen – Schritt für Schritt
• Teil 3: Ein neues Board zu ESP-Claw hinzufügen – meine Board-Adaption für das Guition JC1060P470
• Teil 4: ESP-Claw mit dem eigenen Ollama-Server verbinden – Konfiguration und erste Chats
• Teil 5 (dieser Beitrag): ESP-Claw aktuell halten – Update, Rebuild und Re-Flash auf das Guition JC1060P470
• Teil 6: Capabilities und Skills verstehen – die Architektur eines ESP-Claw-Agenten
• Teil 7: Eine eigene Skill schreiben – das Roboter-Auto fernsteuern oder den Geschirrspühler erklären
• Teil 8: Sprache rein, Sprache raus – das HMI-Board als echter Voice-Assistant zur Unterstützung an der Waschmaschine
• Teil 9: Lua-Skripte für Verhaltensmuster – wenn der Agent eigenständig handelt