BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[betateilchen]

Heute habe ich das auch endlich ausprobiert, ich habe ja genug "Reserve-Boxen" hier stehen.
Das hat alles auf Anhieb funktioniert - RESPEKT für diese tolle Lösung!

Könnte man das Ganze auch auf einem ESP32 C5 betreiben, der auch 5GHz WLAN beherrscht?

Hintergrund meiner Frage: meine Bose Boxen laufen alle auf 5 GHz.

Alles was hier nur 2,4GHz "kann", ist in ein eigenes WLAN ausgelagert (Shelly etc). Ungern möchte ich aber meine Bose Boxen auf 2,4GHz umstellen.

[betateilchen]

Nun habe ich versucht, die vorhandenen Boxen von soundcork auf sixback zu migrieren.
Das hat scheinbar auch ein bisschen funktioniert, aber ich kann die Presets nicht belegen.

Was will mir diese Meldung sagen?

Du darfst diesen Dateianhang nicht ansehen.

Aktuell funktioniert hier nur noch einer meiner vorhandenen Lautsprecher.

Insgesamt habe ich 11, aber im Moment nur 4 in Benutzung.
Wenn es also irgendwann um Lasttest geht, einfach melden

[tostmann]

Danke fürs Ausprobieren — und die gute Nachricht zuerst: dass bei Dir schon ein Speaker läuft, heißt, an Netz und Migration liegt es nicht. Die Meldung auf Deinem Screenshot ist etwas ganz anderes.

"NVS save failed (partition full/fragmented)" kommt vom Speicher auf dem ESP, in dem SixBack seine Einstellungen ablegt — das NVS ist ein kleiner Schlüssel-Wert-Bereich im Flash (~20 KB). Pro migriertem Speaker landen dort Inventar- und Preset-Daten, und bei 11 Speakern ist der Platz schlicht aufgebraucht. Genau deshalb läuft bei Dir nur ein Teil: die ersten Belegungen passten noch rein, dann war voll. Mit soundcork oder der Migration hat das nichts zu tun.

Den in der Meldung vorgeschlagenen Aufräum-Aufruf (/api/nvs/cleanup) kannst Du Dir sparen — die Firmware räumt vor dem Speichern bereits automatisch auf, und in Deinem Fall ist es kein wegräumbarer Cache, sondern echte Speaker-Daten. Der manuelle Aufruf macht also nichts, was nicht ohnehin schon versucht wurde.

Was jetzt hilft: Du hast 11 Geräte migriert, nutzt aber nur 4. Entferne die nicht genutzten in der Geräteliste der WebUI (oder per API):

Code Auswählen Erweitern

curl -X DELETE http://<sixback-ip>/api/speakers/<deviceId>
Damit wird Platz frei und die Presets der aktiven Geräte lassen sich wieder belegen.

Wenn Du magst, schick mir kurz die Ausgabe von:

Code Auswählen Erweitern

curl http://<sixback-ip>/api/nvs/stats
Der Wert "percent_used" bestätigt die Diagnose.

Der eigentliche Fix ist schon auf meiner Liste: Ich hebe das Limit an — die großen Speaker-Daten wandern in den deutlich größeren Dateispeicher (LittleFS), damit auch viele Geräte ohne dieses Problem laufen. Ich melde mich, sobald das draußen ist; das Lasttest-Angebot mit Deinen 11 Boxen nehme ich dann sehr gern an.

[betateilchen]

Moin,
danke für Deine Antwort. Das Problem war ein ganz anderes. Die verschiedenen Fehlermeldungen, die ich gestern Abend zu sehen bekam, waren offenbar alle irreführend. Seit gestern Abend funktionieren die Boxen auch wie gewünscht. Allerdings war ich dann zu müde, um das Ergebnis noch zu beschreiben.

Aber der Reihe nach...

Zuerst: ich habe noch nicht elf Geräte migriert, sondern nur vier.

Erst habe ich einen Lautsprecher testweise migriert, das hat anstandslos funktioniert.
Das fand in einem abgeschotteten WLAN statt, in dem nur der Lautsprecher und sixback liefen.

Danach habe einen AP gestartet, der 2,4GHz in meinem "Haupt-WLAN" bereitgestellt hat. Damit wollte ich die vier in regulärer Nutzung befindliche Bose Boxen migrieren.
Die Boxen wurden anstandslos gefunden und offenbar auch migriert. Beim Anlegen von Presets gingen dann die Fehlermeldungen los und es hat eine Weile gedauert, bis ich hinter die Ursache gekommen bin.

Im Vorfeld der Bose Abschaltung hatte ich die Presets der Boxen auf die Fritzbox als Mediaserver umgestellt. Danach hatte ich den Boxen den Internetzugang gesperrt und diese auf soundcork umgestellt.

Durch den gestern nach wie vor gesperrten Internetzugang konnte sixback natürlich keine TuneIn presets auf die Boxen legen, weil diese einfach nicht abgespielt werden konnten. (Das meinte ich mit irreführende Fehlermeldungen, mit NVS hatte das gar nix zu tun, auch die zeitweise HTTP 502 Meldung offenbar nicht)

Als mir das mit der Internetsperre dann einfiel und ich diese entfernt habe, konnten alle vier Boxen problemlos eingerichtet werden.

Fazit: im Rahmen der Migration könnte im Status eines Bose Gerätes vielleicht ein Hinweis stehen, falls dabei festgestellt wird, dass keine Verbindung ins Internet besteht. Das hätte mir bestimmt zwei Stunden experimentieren bis hin zum Flashen der Box per USB erspart

Der erste getestete Lautsprecher hatte die Internetsperre nie, deshalb trat das Problem dort nicht auf.

Der Vollständigkeit halber noch die gewünschte Ausgabe:

Code Auswählen Erweitern

{"used_entries":390,"free_entries":240,"total_entries":630,"namespace_count":13,"percent_used":61.90476}
Kannst Du bitte zu meiner Frage bezüglich ESP32 C5 mit 5GHz WLAN noch was sagen?

[tostmann]

Danke fürs gründliche Nachfassen — und vor allem dafür, dass Du der Sache so sauber auf den Grund gegangen bist. Dass die angezeigten Meldungen (NVS, zeitweise 502) in die Irre geführt haben, geht auf unsere Kappe: sie haben das eigentliche Problem verdeckt statt es zu benennen.

Dein Befund ist goldwert: ohne Internetzugang kann die Box den TuneIn-Stream gar nicht erst abspielen, und dann scheitert folgerichtig auch das Ablegen des Presets — nur sagt das die Fehlermeldung eben nicht. Genau Deinen Vorschlag greifen wir auf: im Geräte- bzw. Migrationsstatus soll künftig ein klarer Hinweis erscheinen, wenn eine Box (oder SixBack selbst) keine Internet-Verbindung hat. Das hätte Dir die zwei Stunden erspart.

Zu Deiner ESP32-C5-Frage (5-GHz-WLAN): Der C5 ist tatsächlich der naheliegende Kandidat — er ist der erste ESP32 mit Dualband, also 2,4 und 5 GHz. Aktuell laufen alle vier SixBack-Targets ausschließlich auf 2,4 GHz. Ein 5-GHz-Build steht damit auf dem Schirm, ist aber noch nicht spruchreif: der IDF-/Framework-Support für den C5 ist derzeit noch dünn, und ich habe selbst noch keinen C5 hier im Lab. Ich besorge mir die Tage einen — aber ohne Hardware zum Gegentesten will ich nichts versprechen, was ich nicht verifiziert habe. Sobald ich einen C5 sauber zum Laufen bekomme, melde ich mich dazu.

Schön, dass jetzt alle vier Boxen laufen — und danke fürs Mittesten.

[betateilchen]

Hallo Dirk,

Ein 5-GHz-Build steht damit auf dem Schirm, ist aber noch nicht spruchreif: der IDF-/Framework-Support für den C5 ist derzeit noch dünn, und ich habe selbst noch keinen C5 hier im Lab. Ich besorge mir die Tage einen — aber ohne Hardware zum Gegentesten will ich nichts versprechen, was ich nicht verifiziert habe. Sobald ich einen C5 sauber zum Laufen bekomme, melde ich mich dazu.

Wenn alles klappt, sollte ich ab morgen das oben verlinkte C5-DevKit von Amazon hier haben.
Falls es was zum Testen gibt, was per WebFlash getestet werden kann, sag Bescheid.

[betateilchen]

Unter welchen Umständen verlieren die Boxen eigentlich die Presets?

Inzwischen hatte ich drei Mal den Fall, dass keine Presets mehr vorhanden waren und ich diese manuell wieder über die WebUI setzen musste.
Eine Box (die ST20 im Flur) hatte dieses Problem bisher offenbar noch nicht, die Presets ließen sich dann aber auch nicht von dieser Box auf die anderen drei kopieren.

[tostmann]

Hallo betateilchen,

der Frage bin ich nachgegangen — und Du hast damit einen echten Bug aufgedeckt. Kurzfassung: die Presets gehen nicht auf den Boxen verloren, sondern im SixBack-ESP, und zwar reproduzierbar ab einer bestimmten Anzahl verwalteter Speaker. Ich habe das gestern im Labor nachgestellt und die Ursache gefunden.

Zum Hintergrund: SixBack legt die Preset-Belegung aller Speaker als ein einzelnes JSON-Objekt im NVS des ESP ab. Der dafür verwendete NVS-String-Datentyp hat in ESP-IDF ein hartes Limit von 4000 Bytes — das war mir in dieser Konsequenz nicht bewusst. Ab etwa fünf Speakern mit voller Preset-Belegung ist das JSON größer, und ab da schlägt ausnahmslos jeder Speichervorgang fehl, völlig egal wie leer die NVS-Partition tatsächlich ist. Die Fehlermeldung "partition full" in der WebUI war daher irreführend, und genau deshalb ließ sich auch nichts mehr von einer Box auf andere kopieren: der Kopiervorgang ist am Ende derselbe Schreibpfad.

Der eigentlich fatale Teil: die eingebaute Aufräum-Routine, die bei einem fehlgeschlagenen Speichervorgang Platz schaffen soll, löscht in ihrer letzten Eskalationsstufe den alten Eintrag, um ihn neu zu schreiben. Da der Neuschreib bei Überschreiten des Limits aber prinzipbedingt wieder scheitert, vernichtet ein einziger zu großer Speichervorgang den letzten intakten Stand. Im laufenden Betrieb merkt man davon nichts, weil die Belegung im RAM weiterlebt und die WebUI alles korrekt anzeigt — erst beim nächsten Neustart des ESP (zum Beispiel durch ein OTA-Update, davon gab es zuletzt mehrere in kurzer Folge) lädt er den leeren Stand. Boxen, die danach ihre Preset-Liste vom ESP synchronisieren, übernehmen das Ergebnis. Dass Deine ST20 im Flur verschont blieb, passt ins Bild: deren Eintrag steckte vermutlich noch im letzten erfolgreich gespeicherten Stand, beziehungsweise die Box hat seither schlicht nicht neu gesynct.

Der Fix ist fertig und auf Test-Hardware verifiziert: die Ablage erfolgt jetzt als NVS-Blob (das Limit liegt damit bei der Partitionsgröße statt bei 4000 Bytes), und die Aufräum-Routine sichert den alten Stand und stellt ihn wieder her, falls der Neuschreib scheitert — ein Datenverlust durch diesen Mechanismus ist damit ausgeschlossen. Kommt mit dem nächsten Release.

Bis dahin zwei praktische Hinweise. Erstens: Presets, die Du jetzt setzt, leben bei Deiner Speaker-Anzahl nur im RAM und sind nach dem nächsten ESP-Neustart wieder weg — das Neu-Belegen lohnt sich also erst nach dem Update. Zweitens: wenn Du die Zahl der in SixBack verwalteten Speaker vorerst auf vier oder fünf reduzierst, bleibt das JSON unter dem Limit und alles verhält sich normal.

Eine ehrliche Ansage noch zur Kapazität: auch mit dem Fix ist die NVS-Partition (24 KB, aus Kompatibilitätsgründen zum Bestand nicht änderbar) bei voller Preset-Belegung nach meiner Messung bei etwa sieben Speakern am Ende — dann allerdings mit korrekter Fehlermeldung und ohne Datenverlust. Für den vollen Ausbau auf elf Boxen braucht es noch eine weitere Ausbaustufe der Ablage, die ist auf der Liste. Wenn Du nach dem Update mit Deinem Bestand testen magst, wäre mir das sehr willkommen — Deine Flotte ist dafür das beste Testfeld, das ich kenne.

Gruß, Dirk

[JoWiemann]

Hallo Dirk,

schreibst Du das JSON 1:1 weg. Dann wäre mein Vorschlag, ohne tiefer eingestiegen zu sein, es zu komprimieren.

Grüße Jörg