BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[fred_feuerstein]

Ich rufe die ohnehin nur über die IP auf.
und Auto-Migration habe ich gleich deaktiviert. Das sollte dann auch gemacht werden.
Und unabhängig davon, ein neuer scan an einem sixback findet dann trotzdem auch die Boxen des anderen sixback. Halt mit einem Status, dass sie zu einem anderen sixback gehören.
sind aber trotzdem in der Liste.
Deswegen der Vorschlag mit entweder White- oder Blacklist, in die man die jeweiligen IP Adressen der Boxen einträgt.

Aber am liebsten wäre es mir, wenn man alle meine Boxen mit einem sixback verwalten könnte. Vielleicht hat Dirk dazu noch eine Idee, evtl. längere abfragegzeiten oder timeouts oder so etwas.

[betateilchen]

Deswegen der Vorschlag mit entweder White- oder Blacklist, in die man die jeweiligen IP Adressen der Boxen einträgt.

Vermutlich würde sowas aber weit über das hinausgehen, was hinter dem eigentliche Konzept und der Zielsetzung von sixback steht. Installationen mit mehr als vier Soundtouch Boxen dürften eher nicht das typische Szenario sein.

[tostmann]

@betateilchen, @fred: Ja, zwei SixBack im selben WLAN gehen konfliktfrei — die Peer-Erkennung ist seit langem drin: ein SixBack fasst im Auto-Mode keine Boxen an, die ein anderer lebender SixBack verwaltet. Der Ablauf aus #164 (Gruppe 1 migrieren, Auto-Mode aus, dann Gruppe 2 am zweiten Stick) ist genau richtig, und fred macht mit IP-Zugriff plus deaktiviertem Auto-Mode schon das Richtige. Manuelles Migrieren übernimmt eine Box dagegen immer bewusst — das ist der gewollte Umzugsweg zwischen den Sticks.

mDNS stimmt: beide melden sich aktuell als sixback.local, da hilft nur der Zugriff per IP. Konfigurierbarer Hostname ist notiert. Die fremden Boxen tauchen beim Scan absichtlich mit ihrem Status auf — ein simples Ausblenden in der Ansicht (kein großes Verwaltungs-Feature, da bin ich bei betateilchen) ist ebenfalls notiert.

@fred zu "alle 9 an einem Stick": längere Abfragezeiten oder Timeouts helfen da leider nicht — die Grenze ist der Platz des Preset-Speichers im Flash, nicht das Timing. Das zu heben ist der schon erwähnte größere Umbau, für den ich kein Datum nenne; bis dahin ist die Aufteilung auf zwei Sticks der ehrliche Weg.

@betateilchen zum C5 nach "Update existing": kannst Du direkt nach so einem Update einmal kurz den Strom trennen (USB ab/an) und schauen, ob er dann kommt? Bei unseren C5-Boards im Labor bleibt das native USB nach dem Flash-Reset gelegentlich hängen, bis einmal Strom weg war — ein Fresh Install verdeckt das, weil man dabei ohnehin neu ansteckt und provisioniert. Wenn der Power-Cycle nichts ändert, ist es etwas anderes und ich schaue tiefer rein.

Noch ein Hinweis in eigener Sache: in den nächsten Wochen sind Schulferien — Antworten und Releases kommen daher etwas langsamer als zuletzt gewohnt.

[betateilchen]

die Peer-Erkennung ist seit langem drin: ein SixBack fasst im Auto-Mode keine Boxen an, die ein anderer lebender SixBack verwaltet.

Darauf würde ich aber (nach meinen Erfahrungen) nicht wetten...

@betateilchen zum C5 nach "Update existing": kannst Du direkt nach so einem Update einmal kurz den Strom trennen (USB ab/an) und schauen, ob er dann kommt?

Habe ich alles schon erfolglos getestet.
Können wir aber gerne nach den Schulferien nochmal genauer testen, es gibt ja einen Workaround.

[fred_feuerstein]

Also mit 8 Lautsprechern bei SixBack klappt es bisher ohne Probleme mit den Presets, also ohne "leere" Presets. Werde weiter beobachten und berichten
Version .34 ist installiert.

Den 9. Lautsprecher in meinem Netzwerk habe ich nun mit einem anderen Projekt laufen: Soundtouch Reborn (STR) https://st-reborn.de/de/
Hier wird ohne externen Server alles "auf" dem Lautsprecher abgelegt, incl. WebServer zur Steuerung etc., und einige weitere Möglichkeiten.

Somit kann ich das andere Projekt auch mit testen

[tostmann]

Danke fürs Gegentesten — das ist eine wichtige Rückmeldung. Schön, dass .34 bei Dir mit 8 Boxen bisher sauber durchläuft und die leeren Presets weg sind.

Kurz zum Hintergrund, warum das jetzt hält: Der Verlust kam nicht vom WLAN oder von der Anzahl der Boxen, sondern von einem abgebrochenen Schreibvorgang in den Preset-Speicher. Blieb ein Eintrag dabei halb geschrieben zurück, hat der Speicher ihn beim nächsten Neustart als ungültig verworfen — deshalb sah danach alles aus wie frisch und leer. Seit .34 wird jeder Preset-Stand in zwei getrennte Slots geschrieben, nach dem Schreiben zurückgelesen und verglichen, und erst dann auf den neuen Stand umgeschaltet. Ein abgebrochener Schreibvorgang kann den zuletzt gültigen Stand damit nicht mehr überschreiben.

Dein "weiter beobachten" ist trotzdem genau richtig — der Fehler kam ja nur alle paar Tage, sicher ist erst eine längere ruhige Phase. Falls doch nochmal etwas auffällt, wäre ein /api/status-Dump im Moment des Problems (also vor dem Reboot/Recovery) sehr hilfreich.

Und dass Du parallel STR laufen lässt und mittestest: super. SixBack zielt bewusst auf den einfachen Fall — bis rund fünf Boxen und die sechs Tasten zurück, ohne Cloud. Für größere oder speziellere Aufbauten ist es gut, dass es daneben noch andere Wege gibt.

[tostmann]

v0.8.35 ist raus. Zwei Sachen aus diesem Thread sind drin:

Hostname konfigurierbar. Zwei Sticks im selben Netz haben sich bisher beide als sixback.local gemeldet — mDNS-Kollision, und in der DHCP-Liste sieht man auch nicht, welcher welcher ist. Jetzt einstellbar über die Web-UI oder PUT /api/hostname; wirkt auf mDNS und den DHCP-Client-Namen. Validierung serverseitig (a-z, 0-9, Bindestrich — nicht am Anfang oder Ende; Großbuchstaben werden kleingeschrieben, max. 24 Zeichen, leer = zurück auf Default). Braucht einen Reboot, und die UI zeigt bis dahin an, dass noch einer aussteht — sie behauptet also nicht, der neue Name sei schon aktiv.

Einzelne Boxen ausblenden. Lässt sich je Box einzeln setzen. Die Box verschwindet dann aus der Liste und aus allen Auswahl-Dialogen (Zone, Stereo-Paar, DLNA-Browser, Group-Sync), und ihr Status-Polling entfällt damit auch — spart also nebenbei Netzwerk-Fan-out. Überlebt Re-Discovery und Reboot. Bewusst reine Anzeige-Sache: im Hintergrund bedient der Stick die Box weiter genau wie vorher.

Dazu noch drei Dinge:

Improv läuft jetzt auf beiden USB-Buchsen (16-MB-S3). Bisher legte ein Compile-Flag fest, ob der Provisionierungs-Handshake auf UART0 (Bridge-Chip) oder auf dem nativen USB-Serial-JTAG liegt — Boards mit nur einer Buchse und ohne Bridge brauchten deshalb ein eigenes Build-Target. Jetzt laufen zwei Improv-Instanzen parallel, und die Buchse, auf der zuerst ein vollständiges IMPROV-Magic ankommt, bekommt die Session. Gematcht wird bewusst auf das Magic und nicht aufs erste Byte: sonst sperrt ein offenes Terminal auf der einen Buchse den echten Host auf der anderen aus.

Die Anwendungs-Logs (Arduino-Serial) bleiben dabei auf UART0, da ändert sich nichts. Auf dem nativen Port läuft allerdings die IDF-Konsole mit, der Improv-Stream teilt sich die Buchse dort also mit Log-Ausgaben. Deshalb nachgemessen: 894 Improv-Frames unter Dauerlast, ~11 KB Konsolen-Ausgabe im selben Stream, kein einziger kaputter Frame. Geprüft per Checksumme und nicht per Frame-Suche — ein toleranter Parser meldet sonst fröhlich Erfolg auf einem Stream, an dem ein strikter Client erstickt.

Zwei bekannte Fälle stehen auch auf der Flasher-Seite: bei ~88 % kann der Browser in der Konsole ,,Error fetching current state: TIMEOUT" loggen — der Flash läuft normal weiter und wird fertig. Und selten kommen sich Konsole und Handshake auf dem nativen Port doch in die Quere, dann meldet der Browser ,,Improv Wi-Fi Serial not detected". In beiden Fällen: nochmal versuchen, oder die UART-Buchse nehmen.

Store-Schreibfehler sind jetzt sichtbar — Warn-Anzeige im Header, statt dass es erst nach dem nächsten Reboot auffällt. Gilt auch für die Speaker-Liste.

gabbo-Watcher (das HW-Tasten-Re-Arm für Spotify) prüft PSRAM zur Laufzeit statt zur Compile-Zeit: auf S3-Modulen ohne bestücktes PSRAM startet er gar nicht erst — dort gibt es dann folglich auch kein HW-Tasten-Re-Arm. Boards mit PSRAM sind unverändert.

Partitionen sind unverändert, also ganz normal per OTA installierbar.

Release-Notes · sixback.io

[fred_feuerstein]

Hab heute die .35 installiert.

Vorher: mit der .34 lief das System schon tagelang mit 8 Lautsprechern vollkommen problemlos.

Heute nach dem Update auf .35 nach Reboot waren wieder 9 Lautsprecher da. Gleich den einen wieder entfernt. Somit 8 aktiv.
Aber: es kam heute (warum auch immer) schon ein paar Mal zu Aussetzern beim WebRadio, bis hin dass auf einmal wieder Presets bei ein paar Lautsprechern fehlten.
Musste bei 4 Lautsprechern (nach erfolglosem Status Refresh Gesamt und Status Refresh beim Lautsprecher) wieder die gespeicherten Presets einspielen und danach jeweils mindestens zwei Presets pro Lautsprecher mit "push" aktivieren. Dann übernimmt er komischerweise auch die anderen, für die ich noch keinen "push" gemacht habe.

Momentan steht im Header von SixBack: ⚠ store: 8 preset save fails · 19 inventory save fails
(btw: wie bekommt man den Status im Header wieder entfernt?)

Bin gespannt wie die .35 sich weiter verhält. Wie gesagt, die .34 lief mit den 8 Lautsprechern bisher am stabilsten über Tage hinweg.

edit:
jetzt nach ein paar Stunden war gerade wieder ein Lautsprecher ohne Presets, bzw. alle 6 Presets standen mit der Push-Meldung da. Konnte dann einen Sender per Push wieder speichern. Dann waren alle wieder gesetzt.
Status lief ohne Probleme durch...
Kann es sein, dass es nun auch bereits mit 8 Lautsprechern Speicher-Probleme gibt mit der .35 ?
Bei der .34 gab es die mit 8 Lautsprechern "scheinbar" nicht, dort erst ab 9 Lautsprechern.

für den Notfall, kommt man eigentlich auch wieder auf eine ältere Version (bspw. .34) zurück? Falls ja, wie?

[tostmann]

Danke für den ausführlichen Bericht — vor allem für den Vergleich mit .34, das ist die eigentlich wertvolle Information.

Zuerst zu Deiner direkten Frage: Die Anzeige im Header ist ein Zähler seit dem letzten Neustart. Es gibt keinen Knopf zum Zurücksetzen, ein Neustart des Sticks löscht sie. Ich will Dir den Neustart aber nicht als Lösung verkaufen, denn die Anzeige ist hier nicht das Problem, sondern der Hinweis darauf.

Und ich glaube, sie erklärt genau das, was Du beschreibst. "8 preset save fails · 19 inventory save fails" heißt: Der Stick konnte 27 Mal etwas nicht in seinen Speicher schreiben. Alles, was in diesen Momenten geändert wurde, existierte danach nur noch im Arbeitsspeicher — und war beim nächsten Neustart weg. Das passt auf beide Symptome: Der neunte Lautsprecher, den Du entfernt hattest, war nach dem Neustart wieder da, weil das Entfernen nie gespeichert werden konnte. Und die Presets fehlten bei mehreren Boxen, weil die Preset-Liste denselben Weg nimmt.

Wichtig für den Vergleich mit .34: Diese Zähler gibt es erst seit .35, ich habe sie in dieser Version überhaupt erst eingebaut. Das heißt nicht automatisch, dass .34 fehlerfrei war — dieselben Schreibfehler wären dort passiert, nur ohne jede Anzeige. Ob .35 sich wirklich schlechter verhält oder ob Du jetzt zum ersten Mal siehst, was vorher unsichtbar war, kann ich von hier aus nicht entscheiden.

Was ich brauche, um weiterzukommen: einen Statusabzug, solange die Warnung im Header steht und bevor Du neu startest:

Code Auswählen Erweitern

http://<IP-des-Sticks>/api/status
Darin stehen der freie Speicher und die Zähler. Ein fehlgeschlagener Schreibvorgang hat im Code genau zwei mögliche Ursachen — zu wenig freier Arbeitsspeicher im Moment des Schreibens, oder der Speicherbereich im Chip ist voll. Welche von beiden es bei Dir ist, sieht man nur an diesen Werten, und die Gegenmaßnahmen sind völlig verschieden. Ohne den Abzug kann ich nur raten, und damit ist Dir nicht geholfen.

Zwei weitere Dinge:

Der neunte Lautsprecher: Seit .35 kannst Du einzelne Boxen ausblenden, statt sie zu entfernen. Ausgeblendete Boxen verschwinden aus der Liste und aus allen Auswahldialogen und kommen bei einer erneuten Suche nicht wieder — im Gegensatz zum Entfernen. Solange die Schreibfehler aber anhalten, überlebt auch das Ausblenden den Neustart nicht; das ist eher die Lösung für danach.

Die Aussetzer beim Webradio kann ich Dir nicht erklären. Ob sie mit den Schreibfehlern zusammenhängen oder unabhängig davon sind, ist offen. Falls das wieder auftritt, wäre die ungefähre Uhrzeit hilfreich, damit ich es mit dem Statusabzug in Beziehung setzen kann.

Noch ein Hinweis, der Dich zwar nicht betrifft, aber wichtig ist: Ich habe heute einen Fehler im Web-Flasher gefunden — der Button "Update existing" konnte den Stick unter bestimmten Umständen vor der Installation komplett löschen. Betroffene Sticks starten danach gar nicht mehr und brauchen eine vollständige Neuinstallation. Dass Dein Stick nach dem Update normal weiterlief, zeigt, dass Du diesen Fall nicht erwischt hast. Behoben und bereits live — die Flasher-Seite ist korrigiert, dafür ist kein neues Release nötig. Wer über den Web-Flasher aktualisiert und dabei doch einmal gefragt wird, ob gelöscht werden soll: das Häkchen nicht setzen.

Dass .34 bei Dir über Tage mit acht Boxen ruhig lief, nehme ich ernst. Wenn .35 sich schlechter verhält, will ich wissen warum — dafür brauche ich aber den Statusabzug aus dem Fehlermoment.

[tostmann]

Nachtrag — Deine Ergänzung habe ich erst gesehen, nachdem ich oben geantwortet hatte. Zwei Punkte daraus.

Zurück auf .34: ja, das geht jetzt. Bisher ging es nicht, weil die alten Dateien nirgends mehr lagen — sixback.io hält immer nur die aktuelle Version. Ich habe die .34-Dateien deshalb gerade an die Release-Seite gehängt:

Code Auswählen Erweitern

https://github.com/tostmann/SixBack/releases/tag/v0.8.34
Dort brauchst Du zwei Dateien für Deinen Chip — welcher es ist, steht in der Statuszeile oben in der Weboberfläche (z. B. "ESP32-S3 16MB"):

Code Auswählen Erweitern

sixback-<chip>-littlefs.bin
sixback-<chip>-firmware.bin
Beide lädst Du in der Weboberfläche des Sticks hoch, unter dem aufgeklappten Bereich ⚙ SYSTEM beim Firmware-Update. Wichtig ist die Reihenfolge: zuerst littlefs, dann firmware. Der Stick startet nach dem zweiten Upload von allein neu. Die Partitionen sind zwischen .34 und .35 gleich geblieben, deshalb funktioniert das in beide Richtungen; WLAN-Zugang, Presets und Spotify-Anmeldung bleiben dabei erhalten.

Ein Hinweis dazu: Nach dem Zurückgehen meldet der Stick beim nächsten "Check for update" natürlich wieder, dass .35 verfügbar ist. Nicht versehentlich draufklicken, sonst bist Du wieder da, wo Du gestartet bist.

Zu Deiner Frage, ob .35 schon bei 8 Boxen an die Grenze kommt und .34 erst bei 9: Das kann ich Dir ehrlich nicht beantworten, und ich möchte es auch nicht raten. .35 legt gegenüber .34 zwei Kleinigkeiten zusätzlich in den Speicher (den einstellbaren Gerätenamen und das Kennzeichen für ausgeblendete Boxen). Ob das den Ausschlag gibt, habe ich nicht gemessen — es klingt nach wenig, aber "klingt nach wenig" ist keine Aussage, auf die Du Dich verlassen solltest.

Genau das würde der Statusabzug zeigen, um den ich oben gebeten hatte: darin steht sowohl der freie Arbeitsspeicher als auch, wie voll der Speicherbereich ist. Damit ließe sich die Frage beantworten statt vermuten. Wenn Du also das nächste Mal die Warnung im Header siehst — einmal die Adresse aufrufen und den Text hier reinkopieren, das reicht mir.

Und danke fürs Dranbleiben und Mitschreiben, das ist genau die Art Rückmeldung, mit der sich so etwas eingrenzen lässt.

[fred_feuerstein]

Aktuell habe ich ja noch die Status Meldung im Header.

Also hier die Ausgabe vom /api/status

Code Auswählen Erweitern

{
  "name": "SixBack",
  "version": "0.8.35",
  "build": "2026-07-26 21:42:27",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 26984,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -69,
    "channel": 11,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 105588,
    "min_free": 59548,
    "total": 339184,
    "largest_block": 39924,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8358844,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 8,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 15,
    "speakers": 9
  },
  "inventory": {
    "save_fails": 45
  },
  "health": {
    "boot_count": 2,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 2,
    "last_wifi_down_s": 0,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 282
  }
}
Ansonsten wegen manuellem Downgrade: Bei meinem ESP32-S3 16MB wäre es die Version:
sixback-s3-littlefs.bin
sixback-s3-firmware.bin
oder?

[fred_feuerstein]

So, bin erstmal auf der .34 zurück. Aber das Problem ist geblieben. Scheinbar hatte ich die ganzen Tage vorher mit der .34 keine Reboots am ESP. Deshalb lief es zuverlässig...

Also nach Flash und Reboot haben wieder bei 4 Lautsprechern die Presets gefehlt. Alle wieder eingerichtet einzeln über Import, die Anzeige unten rechts war dann ein 500er Fehler, Reload der Webseite zeigte dann die 6 neuen Presets aus dem Import beim Lautsprecher an, aber alle wieder mit PUSH Meldung. Dann wieder bei 2 bis 3 Presets nacheinander PUSH ausgewählt. Dann sind die restlichen Presets beim Speaker auch wieder gesetzt.
Das Ganze dann bei den 3 weiteren Lautsprechern auch so ähnlich weiter.

Als alles wieder eingerichtet war habe ich einfach mal einen Reboot vom ESP gemacht. Und siehe da, es fehlen wieder die entsprechenden Presets bei 4 Lautsprechern.

So wie es aussieht ist die Grenze mit dem Speicher wohl nicht bei 8, sondern scheinbar wesentlich darunter.
Wie sind Deine Erfahrungen bei anderen Usern? Laufen 4 Lautsprecher noch gut oder 5?
Könnte also sein, dass man wirklich einen 2. ESP32 braucht, um 8 und mehr Lautsprecher zu verwalten.

Ansonsten, am besten nie Rebooten

[kaputt]

Bei mir sind es 4 ST10 ohne Probleme.

Gruß aus L.E.
Uwe