BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[betateilchen]

Ich bin ja gerne bereit, bezüglich WLAN weiter zu testen und meine Erkenntnisse zu teilen.

Aber kannst Du mir bitte dabei helfen, eine platformio.ini zu finden, mit der ich die Software so kompilieren kann, dass sie zumindest läuft und nicht in einer Boot-Schleife endet? Da scheint es offenbar noch Probleme zu geben, die nichts mit WLAN zu tun haben dürften.

Mit dem Eintrag, der aktuell für C5 auf github steht, scheint das nicht zu klappen. Auch die Änderungen nach Deinen Hinweisen im vorletzten Beitrag haben keinen Erfolg gebracht.

[tostmann]

Moin,

deine Trennung stimmt: die Boot-Schleife ist ein Config-/Board-Mismatch, nicht WLAN. Unser env:c5 ist bewusst auf ein nacktes 4-MB-Board OHNE PSRAM zugeschnitten (board esp32-c5-devkitc1-n4, partitions-4mb.csv, flash_size 4MB) — kein BOARD_HAS_PSRAM, kein psram_type, kein flash_mode. Dein DevKit ist ein N16R8, also 16 MB Flash + 8 MB PSRAM; genau diese Config auf einem PSRAM-Board crasht deshalb beim Boot.

Zwei Wege:

1. Am direktesten: ein nacktes esp32-c5-devkitc1 mit 4 MB / ohne PSRAM (die N4-Variante, ~5-8 EUR). Darauf läuft der github-env:c5 unverändert, die Boot-Schleife ist weg — und dein WLAN-Ergebnis wird 1:1 mit unserem vergleichbar, was uns fürs 5-GHz-Thema am meisten hilft.

2. Auf deinem N16R8 bleiben: dafür braucht es ein eigenes Env mit 16-MB-Layout + aktiviertem PSRAM. Wichtig: der C5 hat QUAD-SPI-PSRAM (nicht Octal wie der S3), die opi-/qio_opi-Werte aus unserem s3-8mb wären also falsch — es muss qspi. Hier ein Versuch zum Draufsetzen, aber ehrlich UNGETESTET (wir haben kein N16R8, und ob der aktuelle C5-Core die 8 MB Quad-PSRAM sauber hochzieht, ist selbst offen):

Code Auswählen Erweitern

[env:c5-16mb]           ; UNGETESTET — guess fuer C5 N16R8 (16 MB Flash + 8 MB PSRAM)
extends = common
board = esp32-c5-devkitc1-n4
board_upload.flash_size = 16MB
board_build.partitions = partitions.csv          ; 16-MB-Layout, wie env:s3
board_build.filesystem = littlefs
; C5-PSRAM = QUAD-SPI (NICHT Octal wie S3!) -> qspi, nicht opi:
board_build.arduino.memory_type = qio_qspi
board_build.psram_type = qspi
build_flags =
    ${common.build_flags}
    -D ARDUINO_USB_MODE=1
    -D ARDUINO_USB_CDC_ON_BOOT=1
    -D BOARD_HAS_PSRAM
    -D SIXBACK_SPOTIFY_ENABLED=1
    -D SIXBACK_OTA_ENABLED=1
    -D SIXBACK_OTA_PREFIX='"sixback-c5-"'

Wenn der Boot damit durchläuft: der serielle Backtrace direkt nach einem Reboot sagt sofort, ob es noch am PSRAM/Heap hängt. Und falls es weiter zickt, ist Weg 1 der verlässliche.

Ehrliche Erwartung in beiden Fällen: selbst ohne Boot-Schleife kann der 5-GHz-Connect noch an dieselbe Wand laufen wie bei uns (ein C5 verbindet sauber, ein anderer bekommt trotz gutem Empfang reproduzierbar keinen AP). Aber du kommst damit erstmal sauber bis zum eigentlichen WLAN-Test.

Gruß

[betateilchen]

Ein Stück weiter bin ich inzwischen.
Ich habe den Abschnitt vom simplen ESP32 kopiert und angepasst.

Code Auswählen Erweitern

[env:c5]
extends = common
board = esp32-c5-devkitc1-n4
board_build.partitions = partitions-4mb.csv
board_build.filesystem = littlefs
board_upload.flash_size = 4MB
; FS-Image filtern: silence.mp3 (Spotify-only, ~120KB) raus, sonst sprengt das
; data/-Payload (244KB) das 256KB-spiffs der 4mb-OTA-Tabelle -> LFS_ERR_NOSPC.
; Classic hat kein Spotify, braucht silence.mp3 nicht. version_bump.py bleibt.
extra_scripts =
    ${common.extra_scripts}
    pre:scripts/fs_exclude_esp32.py
build_flags =
    ${common.build_flags}
    ; ESP32-classic behaelt A/B-OTA (1.81MB Slots reichen)
    -D SIXBACK_OTA_ENABLED=1

Damit komme ich bis hierhin:

Code Auswählen Erweitern

14:27:32.527 >
14:27:32.527 > =========================================
14:27:32.527 >   SixBack 0.8.27+1700
14:27:32.527 >   Build: 2026-07-01 14:23:31
14:27:32.527 >   Copyright (c) 2026 Dirk Tostmann
14:27:32.539 >   License: PolyForm Noncommercial 1.0.0
14:27:32.539 >   Commercial use prohibited — see LICENSE
14:27:32.539 > =========================================
14:27:32.550 > [mbedtls] PSRAM not available — keeping default internal allocator
14:27:32.550 > [fs]   LittleFS mounted, 8192/262144 bytes used
14:27:32.550 > [   549][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.580 > [   584][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.590 > [uiauth] web-UI password protection disabled
14:27:32.590 > [   590][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.601 > [   600][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.601 > [improv] starting (idle-window 120s, no NVS-creds present)
14:27:33.255 > [  1259][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:33.261 > [provision] improv-exclusive window 10s (no captive yet)
14:27:43.266 > [captive] starting open AP 'SixBack-007F94' + DNS + HTTP on 192.168.4.1
14:27:43.266 > [provision] no NVS connect — waiting on improv OR captive

Das sixback-WLAN ist da, das Portal kommt, aber das war es dann auch.
Der Scan liefert kein Ergebnis, ein manuelles Eintragen der Daten auf der Portalseite funktioniert auch nicht.
Es kommt immer noch die vom watchdog ausgelöste Reboot-Schleife.

Code Auswählen Erweitern

14:27:10.658 > [captive] starting open AP 'SixBack-007F94' + DNS + HTTP on 192.168.4.1
14:27:10.670 > [provision] no NVS connect — waiting on improv OR captive
14:27:31.101 > E (32670) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
14:27:31.101 > E (32670) task_wdt:  - async_tcp (CPU 0)
14:27:31.112 > E (32670) task_wdt: Tasks currently running:
14:27:31.112 > E (32670) task_wdt: CPU 0: IDLE
14:27:31.112 > E (32670) task_wdt: Aborting.
14:27:31.120 > E (32670) task_wdt: Print CPU 0 (current core) registers

Wie bekommt man das NVS Problem in den Griff?
Müsste das nicht automatisch beim Start formatiert werden, wenn es noch nicht existiert?

[betateilchen]

Wir haben wohl gerade beide eine Antwort geschrieben...

1. Am direktesten: ein nacktes esp32-c5-devkitc1 mit 4 MB / ohne PSRAM (die N4-Variante, ~5-8 EUR). Darauf läuft der github-env:c5 unverändert, die Boot-Schleife ist weg — und dein WLAN-Ergebnis wird 1:1 mit unserem vergleichbar, was uns fürs 5-GHz-Thema am meisten hilft.

Die Idee hatte ich auch schon, aber ich habe noch keine Quelle dafür gefunden. Hast Du eine Quelle für mich, möglichst in Deutschland? (Bei Amazon nicht verfügbar)

2. Auf deinem N16R8 bleiben: dafür braucht es ein eigenes Env mit 16-MB-Layout + aktiviertem PSRAM. Wichtig: der C5 hat QUAD-SPI-PSRAM (nicht Octal wie der S3), die opi-/qio_opi-Werte aus unserem s3-8mb wären also falsch — es muss qspi. Hier ein Versuch zum Draufsetzen, aber ehrlich UNGETESTET (wir haben kein N16R8, und ob der aktuelle C5-Core die 8 MB Quad-PSRAM sauber hochzieht, ist selbst offen):

Das werde ich testen, danke.

Ehrliche Erwartung in beiden Fällen: selbst ohne Boot-Schleife kann der 5-GHz-Connect noch an dieselbe Wand laufen wie bei uns (ein C5 verbindet sauber, ein anderer bekommt trotz gutem Empfang reproduzierbar keinen AP). Aber du kommst damit erstmal sauber bis zum eigentlichen WLAN-Test.

Genau darum geht es mir, ich möchte zumindest mal bis zur Möglichkeit kommen, das WLAN überhaupt zu testen. Und dann kann ich weiter forschen.

[betateilchen]

Die Idee hatte ich auch schon, aber ich habe noch keine Quelle dafür gefunden. Hast Du eine Quelle für mich, möglichst in Deutschland? (Bei Amazon nicht verfügbar)

Ok, ich habe jetzt bei Aliexpress bestellt.
Versand + Zölle sind seit heute höher als der Artikelpreis...

[tostmann]

ich hatte seinerzeit den bestellt:

https://de.aliexpress.com/item/1005010442802432.html

Krass, jetzt 4 Euro teuer ...

[betateilchen]

ich habe den hier bestellt: https://de.aliexpress.com/item/1005012416463528.html

[tostmann]

SixBack v0.8.28 ist raus — ESP32-C5-Support (Dual-Band/5 GHz) + Fixes am WLAN-Setup

Der ESP32-C5 ist ab dieser Version ein offizielles Target: Der Web-Flasher auf https://sixback.io/ erkennt den Chip automatisch, OTA-Kanal inklusive. Verifiziert haben wir auf zwei C5-Boards (die verbreiteten 4-MB/N4-DevKitC-Klone): beide Provisioning-Wege — Captive-Portal und Improv über den Web-Flasher — enden dort in einer 5-GHz-Verbindung, die Zugangsdaten überleben den Reboot.

Beim C5-Testen haben wir auch die Ursache für die hier gemeldete Reboot-Schleife während des Portal-Setups gefunden: Der WLAN-Scan lief bisher blockierend im Webserver-Task. Auf Dual-Band-Chips dauert der Scan über beide Bänder rund 9 Sekunden — das reißt den 5-Sekunden-Task-Watchdog, und der Stick macht einen Panic-Reboot genau in dem Moment, in dem die Setup-Seite lädt (die Seite stößt den Scan automatisch an). Bei jedem neuen Versuch dasselbe. Auf reinen 2,4-GHz-Chips blieb derselbe Code mit ~4 Sekunden knapp unter der Grenze, deshalb ist das erst mit dem C5 aufgefallen. Der Scan läuft jetzt asynchron; auf unseren C5s war der Crash vorher zuverlässig reproduzierbar und tritt seit dem Fix nicht mehr auf.

Weitere Fixes am Setup-Fluss in v0.8.28: Das Portal-Fenster ist jetzt idle-basiert (5 Minuten seit der letzten Interaktion, 30 Minuten Obergrenze) statt eines harten 5-Minuten-Abbruchs, der auch mitten in der Passwort-Eingabe zuschlagen konnte. Ein laufender Verbindungsversuch wird am Fensterende nicht mehr abgebrochen (vorher konnten korrekt eingegebene Zugangsdaten dabei verloren gehen). Nach erfolgreichem Setup startet der Stick einmal neu — vorher konnte die Web-UI auf Port 80 bis zum nächsten Reboot unerreichbar bleiben, was wie ein fehlgeschlagenes Setup aussah, obwohl der Stick längst im WLAN war. Und auf der Improv-Seite: serielle Daten nach Ablauf des Improv-Fensters können ein unprovisioniertes Gerät nicht mehr dauerhaft lahmlegen; es kehrt immer in seinen Setup-Zyklus zurück.

Für alle, die aus den Quellen bauen: Der Verweis auf die Improv-Bibliothek zeigte auf einen Commit, den es im öffentlichen Repo nicht mehr gab — frische Checkouts schlugen deshalb beim Bauen fehl. Ist ebenfalls behoben, ein frisches Clone+Build geht wieder durch.

@betateilchen: Dein N16R8 müsste vom Scan-Fix direkt profitieren — der Crash-Mechanismus ist board-unabhängig, und Dein Fehlerbild (Reboot-Schleife, sobald das Portal bedient wird) passt exakt darauf. Getestet haben wir allerdings nur die 4-MB/N4-Variante; das c5-Build ist auf 4 MB Flash ohne PSRAM ausgelegt und läuft auf größeren Boards im 4-MB-Layout (ein eigenes 16-MB/PSRAM-Target steht noch aus). Wenn Du v0.8.28 auf Deinem Board probierst, wären Deine Ergebnisse sehr willkommen.

Update wie gewohnt: OTA über die Web-UI oder komplett frisch über https://sixback.io/. Die Partitionslayouts sind unverändert, OTA ist also für alle Targets unkritisch. Changelog: https://github.com/tostmann/SixBack/releases/tag/v0.8.28

[betateilchen]

Super, danke vielmals!

Das ging ja dann doch schneller als erwartet.

Du darfst diesen Dateianhang nicht ansehen.

Auf den ersten Blick scheint alles zu funktionieren, mal schauen, ob noch irgendwelche Nebeneffekte auftauchen.

Die WLAN-Verbindungsqualität des C5 scheint nicht die allerbeste zu sein, aber dafür kann ja sixback nichts. Bei einem Abstand von unter einem Meter zum Repeater ist ein RSSI von -78dBm eigentlich zu schlecht.

Für mich ist am Wichtigsten, dass ich den 2,4GHz AccessPoint, den ich ausschließlich wegen sixback in Betrieb genommen hatte, nun wieder abbauen kann.


--

[tostmann]

Klasse, danke fürs schnelle Testen und die Rückmeldung — freut mich, dass der Extra-AP jetzt wieder wegfallen kann!

Zum RSSI: den liest SixBack nur aus, beeinflussen kann die Firmware ihn nicht. −78 dBm bei unter einem Meter sind allerdings ungewöhnlich niedrig — für die kurze Distanz würde man deutlich mehr erwarten. Da würde ich eher beim Link selbst schauen als beim Board: misst Du zum Repeater (dann ist dessen Uplink/Platzierung der Flaschenhals) oder zur Basis? Unsere beiden baugleichen C5-Testboards liegen im Scan bei ~−55 dBm, insofern ist ein grundsätzlich schwaches C5-5-GHz-Frontend zumindest nicht unser Befund.

[betateilchen]

Zum RSSI: den liest SixBack nur aus, beeinflussen kann die Firmware ihn nicht.

Das ist mir schon klar.

Inzwischen weiß ich, dass der C5 sich gar nicht zum nahegelegenen Mesh-Repeater im gleichen Raum verbindet, sondern direkt zur Fritzbox. Und da liegen zwei Wände dazwischen, was natürlich bei 5GHz nicht so richtig toll ist. Inzwischen ist der sixback in den Raum zur Fritzbox umgezogen.

Du darfst diesen Dateianhang nicht ansehen.

Insgesamt erscheint die gesamte Kommunikation zwischen Browser und sixback aktuell sehr hakelig mit sehr langen Aufbauzeiten der Seite im Frontend, zeitweise endet das Laden der Seite überhaupt nicht.



--

[betateilchen]

Kann es sein, dass es da noch ein Problem beim Persistieren von Einstellungen gibt?
Der Schalter "Auto-Migrate at Boot" wird offenbar nicht gespeichert.
Und beim Button "WiFi factory reset" habe ich den Eindruck, dass der im Moment nicht wie bisher funktioniert.
Zur Neukonfiguration des WiFi musste ich sixback neu flashen, da ich keine andere Möglichkeit gefunden habe, das zurückzusetzen.

[tostmann]

Danke für die detaillierten Rückmeldungen — ich habe die drei Punkte (Auto-Migrate speichert nicht, WiFi factory reset, hakelige WebUI) hier auf zwei C5-Boards nachgestellt.

Ergebnis vorweg: Auf einem frisch geflashten v0.8.28 kann ich keinen der drei Punkte reproduzieren. Der Auto-Migrate-Schalter übersteht den Reboot, der WiFi-Factory-Reset löscht die Zugangsdaten sauber und das Gerät kommt danach zuverlässig mit dem Setup-AP hoch (Portal lädt, neu einrichten klappt), und die WebUI bleibt flüssig. Der freie Heap war über eine Viertelstunde unter Last stabil bei rund 60 KB, kein Leck.

Was ich anfangs für einen Bug hielt, trat nur auf einem Board auf, das ich zuvor durch sehr viele Provisioning-Zyklen in einen instabilen Zustand gefahren hatte (mehrere Abstürze, Heap fast leer). Nach einem sauberen Neu-Flash war genau dieses Board wieder völlig unauffällig und macht alles korrekt.

Deshalb der Verdacht: Dein Gerät ist in einen ähnlichen degradierten Zustand geraten. Zwei Dinge würden helfen, das einzugrenzen:

- Ruf einmal http://<IP-des-Sticks>/api/status auf und poste den "health"-Block daraus (crash_count, boot_count, uptime_s und die heap-Werte free/min_free). Daran sieht man sofort, ob das Gerät im Hintergrund abstürzt.
- Ein sauberer Neu-Flash über den Web-Flasher (mit "erase") sollte den Zustand zurücksetzen. Danach würde mich interessieren, ob die Punkte weg sind.

Noch ein separater Punkt, unabhängig von deinen drei Beobachtungen: Auf dem C5 funktioniert das Selbst-Update per OTA nicht. Der Chip hat für den verschlüsselten Download schlicht zu wenig RAM — er hat kein PSRAM, und der Dual-Band-WLAN-Stack belegt spürbar mehr Speicher als bei den 2,4-GHz-Chips. Der TLS-Handshake scheitert dann an der Speicherreservierung. Auf dem C5 bitte Updates daher ausschließlich über den Web-Flasher (sixback.io) einspielen; die anderen Chips (C3/C6/S3/ESP32) sind davon nicht betroffen. Das nächste Update zeigt auf dem C5 auch einen klaren Hinweis darauf an, statt einer kryptischen Fehlermeldung.

[betateilchen]

- Ruf einmal http://<IP-des-Sticks>/api/status auf und poste den "health"-Block daraus (crash_count, boot_count, uptime_s und die heap-Werte free/min_free). Daran sieht man sofort, ob das Gerät im Hintergrund abstürzt.

Code Auswählen Erweitern

{"name":"SixBack","version":"0.8.28","build":"2026-07-03 02:09:53","license":"PolyForm-Noncommercial-1.0.0","copyright":"Copyright (c) 2026 Dirk Tostmann","uptime_s":13811,
"wifi":{"connected":true,"ssid":"mowg","ip":"192.168.123.44","rssi":-39,"channel":40,"band":"5GHz","mac":"38:44:BE:00:7F:94","hostname":"sixback.local","improv_active":false,"improv_window_s":0,"captive_active":false,"captive_window_s":0},
"heap":{"free":49480,"min_free":2320,"total":258240},"psram":{"free":0,"total":0},
"chip":{"model":"ESP32-C5","cores":1,"revision":100,"flash_size":16777216},
"cloud_replacement":{"port":8000,"base_url":"http://192.168.123.44:8000"},"speakers_count":4,"scan_in_progress":false,
"health":{"boot_count":3,"crash_count":0,"wifi_reboots":0,"heap_reboots":0,"last_reset":"POWERON","wdt_subscribed":true,"wifi_down_for_s":0,"heap_low_for_s":0,"last_ping_age_s":10}}


- Ein sauberer Neu-Flash über den Web-Flasher (mit "erase") sollte den Zustand zurücksetzen. Danach würde mich interessieren, ob die Punkte weg sind.

Das habe ich schon zweimal gemacht, auch das erste Flashen des C5 wurde ja über den Web-Flasher durchgeführt.

Nach dem Aufruf von sixback.local sieht das bei mir erstmal so aus:

Du darfst diesen Dateianhang nicht ansehen.

Das Laden der Seite wird nicht abgeschlossen, deshalb werden die Lautsprecher nicht angezeigt.
Manchmal passiert aber auch gar nix und die Seite bleibt einfach leer, weil das Laden der Seite zu keinem Ende kommt.


Die Boxen selbst scheinen aber bisher problemlos zu laufen.



--