BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[fred_feuerstein]

Was bedeuten die markierten Einträge bei den beiden Presets? Das war jeweils mal eine Spotify Playlist, die über Sixback per drag/drop draufgezogen wurde. Aber aktuell sind andere Presets gespeichert, jeweils eine Zeile drüber sieht man es.
Beim Auslesen über das fhem BOSEST erscheinen als Presets nach wie vor nur die markierten Einträge bei den beiden Presets.

Also 1. Frage, was bedeutet es und 2. Frage wie bekomme ich die markierten Einträge wieder weg? (vorab: Reboot der Box hat nichts gebracht)

=> edit: ok, ein Reboot von Sixback hat geholfen. Nun passt es wieder. Nur die Frage 1 bleibt, was bedeuten die markierten Einträge bei über sixback hinterlegten Spotify Playlists.

[tostmann]

Hallo fred,

die markierte Zeile ist kein Preset, sondern die Spotify-Bindung des Slots — eine eigene Ebene neben dem Preset.

Wenn Du eine Playlist per Drag&Drop auf einen Slot ziehst, schreibt SixBack zwei Dinge: die Bindung (Slot → Playlist) und zusätzlich ein TuneIn-Preset namens "🎵 <Playlist>" auf den Speaker. Das zweite ist der Trick, mit dem die Hardware-Taste überhaupt Spotify starten kann: der Speaker spielt formal einen TuneIn-Sender, SixBack fängt den Aufruf ab und startet stattdessen Spotify. Deshalb steht im Speaker — und damit in dem, was BOSEST ausliest — der Playlist-Name und nicht der Sender.

Ziehst Du später einen normalen Sender auf den Slot, wird nur das Preset ersetzt. Die Bindung bleibt liegen und wird weiter angezeigt, obwohl sie nichts mehr tut: bei belegtem Slot spielt die Taste den Sender, die Bindung wird ignoriert. Harmlos also, aber die Anzeige führt in die Irre — das war eine Lücke unsererseits.

Im nächsten Release ist das behoben: beim Überschreiben eines Slots wird die alte Bindung jetzt automatisch mit entfernt, und an der Spotify-Zeile gibt es ein ✕, mit dem Du eine Bindung jederzeit manuell löschen kannst — das Preset bleibt dabei unangetastet.

Eine Rückfrage: was genau hat der SixBack-Reboot bei Dir gerichtet — die Spotify-Zeilen in der Oberfläche oder das, was BOSEST ausliest? Das hilft mir einzuordnen, ob da noch etwas anderes klemmt.

Gruß

[fred_feuerstein]

Ja, der SixBack Reboot hat, nachdem die Presets auf eine andere Quelle verwiesen haben, auch diese Bindung entfernt. Somit hat auch die Anzeige in fhem etc. wieder gepasst.
Aber schön, wenn künftig ein "X" hinter der Bindungszeile ist, um diese auch direkt löschen zu können.

Heute früh hatte ich mal wieder das Problem, dass 3 Lautsprecher keine Presets mehr hatten. Reboot von den Lautsprechern und Reboot von SixBack hat nichts gebracht. Habe dann die gespeicherten Presets per Import wieder eingespielt jeweils. Gibts da einen Trick? Denn nach dem Einspielen der Presets bei einem Lautsprecher muss man dann "manuell" alle 6 einzeln per "Push" auf dem Speaker speichern, bzw. teilweise hat er nach dem 3. Preset-Push komischerweise die anderen 3 auch "übernommen".

Das Problem mit 6 leeren Presets bei Lautsprechern habe ich sporadisch. Konnte noch keinen Grund feststellen. Netzwerk, WLAN, Sixback, etc. läuft bzw. lief alles ganz normal, nur eben die Presets von ein paar Lautsprechern sind manchmal weg. Häufigkeit ggfs. alle 10 Tage mal...

[betateilchen]

Im nächsten Release kommt unabhängig davon ein Fix, der den Speicher-Peak im WebUI-Pfad senkt. Gut möglich, dass dir das auf dem C5 schon reicht — das müsstest du dann bei dir gegentesten.

Bei mir funktioniert das Auslesen von /presets mit .32 nicht mehr.

Im WebUI werden keine presets angezeigt, wenn ich versuche, den Status zu aktualisieren, bricht der Vorgang beim Auslesen von /presets mit der Meldung "device busy (low heap)" oder so ähnlich ab. Die Meldung wird nur extrem kurz angezeigt, bevor sich das Fenster schließt.

Du darfst diesen Dateianhang nicht ansehen.

Laut /api/status sieht heap aber nicht so ganz schlecht aus.

Code Auswählen Erweitern

{
  "name": "SixBack",
  "version": "0.8.32",
  "build": "2026-07-15 23:25:40",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 857,
  "wifi": {
    "connected": true,
    "ssid": "mowg",
    "ip": "192.168.123.46",
    "rssi": -75,
    "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": 70436,
    "min_free": 14996,
    "total": 257776
  },
  "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.46:8000"
  },
  "speakers_count": 4,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "health": {
    "boot_count": 1,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 0,
    "last_wifi_down_s": 0,
    "last_reset": "POWERON",
    "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": 257
  }
}


[tostmann]

v0.8.33 ist raus (sixback.io, OTA + Web-Flasher; GitHub-Release-Notes haben die Details).

@betateilchen: das "device busy (low heap)" war ein Fehler von mir in .32 — die neue Heap-Prüfung hatte eine viel zu hohe Schwelle, auf dem C5 wurde damit praktisch jede Preset-Abfrage abgewiesen. In .33 behoben und auf einem C5 verifiziert. Auf dem C5 bitte per Web-Flasher aktualisieren, Knopf "Update existing" (behält WLAN/Presets/Spotify — Online-OTA ist auf dem C5 ja bewusst aus). /api/status zeigt jetzt zusätzlich largest_block und outbound_rejects. Und: die beiden C5 sind angekommen — vielen Dank! Der erste läuft schon im Testaufbau.

@fred: Deinen sporadischen Preset-Verlust nehme ich ernst. .33 baut dafür Diagnose ein: /api/status zeigt jetzt preset_store.load_ok und save_fails — und solange der gespeicherte Preset-Bestand unlesbar sein sollte, bekommen die Boxen beim Sync ein 404 statt einer leeren Liste und behalten ihre Presets. Zum Eingrenzen der Ursache:

• Welchen Import hast Du zur Wiederherstellung benutzt — Datei-Import (⬆) oder "Import from device"?
• Hattest Du zwischen Entdecken und Import den Refresh-Knopf gedrückt?
• Welche 3 Boxen waren betroffen — sind das die mit Fritzbox-/DLNA-Presets?
• Welche SixBack-Version lief am 16.07. früh?
• Beim nächsten Vorfall bitte VOR der Wiederherstellung einmal /api/status sichern (Text kopieren reicht).

[betateilchen]

die neue Heap-Prüfung hatte eine viel zu hohe Schwelle, auf dem C5 wurde damit praktisch jede Preset-Abfrage abgewiesen.

Danke für die Korrektur, sowas ähnliches hatte ich schon vermutet.
 
Bei drei von vier Boxen werden die Presets jetzt auch wieder angezeigt, bei der vierten Box tritt wieder die "low heap" Meldung (bei freiem Speicher zwischen 45 und 62kB) auf. Das Ganze lasse ich jetzt mal ohne geöffnetes WebUI eine Weile laufen und werde beobachten, ob sich das irgendwann von selbst erledigt.

[fred_feuerstein]

@fred: Deinen sporadischen Preset-Verlust nehme ich ernst. .33 baut dafür Diagnose ein: /api/status zeigt jetzt preset_store.load_ok und save_fails — und solange der gespeicherte Preset-Bestand unlesbar sein sollte, bekommen die Boxen beim Sync ein 404 statt einer leeren Liste und behalten ihre Presets. Zum Eingrenzen der Ursache:

• Welchen Import hast Du zur Wiederherstellung benutzt — Datei-Import (⬆) oder "Import from device"?
• Hattest Du zwischen Entdecken und Import den Refresh-Knopf gedrückt?
• Welche 3 Boxen waren betroffen — sind das die mit Fritzbox-/DLNA-Presets?
• Welche SixBack-Version lief am 16.07. früh?
• Beim nächsten Vorfall bitte VOR der Wiederherstellung einmal /api/status sichern (Text kopieren reicht).

zu deinen Fragen:

• ich hatte Datei Import gemacht (habe von allen Boxen den entsprechenden Export nach Einrichtung erstellt), wo wäre denn der Punkt "Import from device" zu finden?
• ich hatte Browser-Reload, Status beim Speaker und Gesamt-Refresh getestet. Hatte alles nicht geholfen, die Presets waren leer.
• bei mir hat jede Box 1 Preset auf eine Playlist von der Fritzbox. Die anderen Presets sind Radio-Kanäle von tunein über SixBack. Bei 1 Box habe ich 2 Playlists von Spotify drauf.
• es lief die .29 - werde jetzt mal auf die .33 gehen.
• /api/status werde ich wenn es mal wieder vorkommt sichern

edit:
bin nun auf der .33 und nach dem Update kam bei einer Box gleich das Problem mit leeren Presets. Refresh zeigt bei dieser Box kurz Fehler 502, nicht erreichbar. Danach Status beim Speaker selbst läuft durch, aber presets sind leer. Im Anschluss Gesamt Refresh läuft durch und zeigt bei dem Speaker 0/6. Also leere Presets.

Hier der Api-Status:

Code Auswählen Erweitern

{"name":"SixBack","version":"0.8.33","build":"2026-07-17 02:16:41","license":"PolyForm-Noncommercial-1.0.0","copyright":"Copyright (c) 2026 Dirk Tostmann","uptime_s":334,"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":112580,"min_free":55064,"total":340176,"largest_block":41972,"outbound_rejects":0},"psram":{"free":8361488,"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":9,"scan_in_progress":false,"groups_persist_ok":true,"preset_store":{"load_ok":true,"save_fails":6,"speakers":8},"health":{"boot_count":1,"crash_count":0,"wifi_reboots":0,"heap_reboots":0,"wifi_disconnects":0,"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":34}}
Werde jetzt wieder den Import-Button nutzen.
Komischerweise hatte ich auch bei dem ganzen Status Refresh usw. bei anderen Boxen auch unter jedem Preset den Push-Button als wenn etwas geändert worden wäre. Ein Status-Button bei dem jeweiligen Speaker hat es gerichtet. Ist irgendwie komisches Verhalten.
Aber der eine Speaker bleibt bei 6 leeren Presets. Wie gesagt Import-Button genutzt (dabei kam rechts unten wieder kurz eine 502 Meldung, aber der Speaker ist erreichbar), dann nochmal Status und Browser-Reload und die 6 Presets sind wieder da...

[fred_feuerstein]

Zwischendurch mal den aktuellen Stand bei meiner einzelnen Box im Büro (anderes WLAN, Netzwerk etc.) mit separatem SixBack:

[erwin23]

Das Gehäuse für den S3 sieht ja super aus!! Magst du die Stl posten?
Beste Grüße

[tostmann]

@betateilchen: Danke für den Test. Die verbleibende "low heap"-Meldung bei 45–62 kB haben wir im Labor nachgestellt: neben der in v0.8.33 korrigierten Block-Schwelle gibt es eine zweite Schwelle auf den freien Gesamt-Heap (45 kB auf Sticks ohne PSRAM), und die ist für den normalen C5-Betrieb ebenfalls zu hoch — bei Deiner Baseline lehnt sie Abfragen ab, obwohl der Stick gesund ist. In v0.8.34 (gerade veröffentlicht) ist sie gesenkt (im Labor validiert, unter Dauerlast kein einziger Abweiser mehr), und die Diagnose schlüsselt jetzt auf, welche Bedingung abgelehnt hat — es gibt nämlich noch eine dritte (max. 2 gleichzeitige Box-Abfragen), die bei mehreren Boxen plus einer langsam antwortenden Box genau das Muster "immer dieselbe Box betroffen" erzeugen kann. Dein Status-Output nach dem Update sagt uns dann sofort, welcher Fall es bei Deiner vierten Box ist.

Dein Ansatz, ohne offenes WebUI zu beobachten, ist übrigens goldrichtig: wir konnten im Labor zeigen, dass zwei gleichzeitig geladene WebUI-Seiten (zwei Tabs oder zwei Geräte) den C5 binnen Sekunden vom Netz werfen können — ein einzelner Tab ist dagegen auch unter Dauerlast stabil. v0.8.34 fängt genau das ab: die Seite wird auf Chips ohne PSRAM nur noch einmal gleichzeitig ausgeliefert, ein zweiter paralleler Abruf bekommt eine Mini-Warteseite mit Auto-Retry statt eines konkurrierenden 75-KB-Transfers — im Labor mit dem identischen Doppel-Lade-Test verifiziert (0 % Ping-Verlust statt Totalausfall). Achtung C5: kein Selbst-OTA — Update über den Webflasher ("Update existing").

@fred: Die neuen Diagnose-Felder haben ihren Job gemacht — save_fails:6 war der Treffer. Wir haben Deine Konstellation im Labor exakt reproduziert: mit 9 Boxen läuft der Preset-Speicher des Sticks über (NVS-Partition, 20 kB). Bis 8 Boxen speichert alles sauber, ab der 9. schlägt jeder Schreibvorgang fehl ("partition out of space") — deshalb steht bei Dir speakers:8 und die neunte Box verliert ihre Presets bei jedem Neustart wieder. Auch das komische "Push-Knopf unter jedem Preset"-Verhalten passt dazu: wenn das Speichern fehlschlägt, laufen Anzeige und gespeicherter Stand auseinander. Die 502 beim Refresh ist ein Folgesymptom (Box antwortete kurz nicht), nicht die Ursache.

Workaround ab sofort: die Flotte auf zwei Sticks aufteilen — mit dem separaten Büro-Stick machst Du schon genau das Richtige, z.B. 5+4 verteilt ist die Kante weg. Alternativ nicht genutzte Boxen aus dem Store entfernen. Der Datei-Import war der richtige Recovery-Weg; "Import from device" liest umgekehrt die aktuell auf der Box gespeicherten Tasten ein und hätte bei leeren Tasten nichts gerettet.

In v0.8.34 ist außerdem die Preset-Ablage auf ein doppelt gepuffertes Schema umgestellt: jeder Speichervorgang schreibt in einen Ersatz-Slot, wird zurückgelesen und erst nach Verifikation aktiv geschaltet — ein fehlschlagender Schreibvorgang kann den letzten guten Stand damit konstruktionsbedingt nicht mehr beschädigen. Wir haben Deine Verlust-Sequenz im Labor exakt nachgestellt: vor dem Fix war der komplette Store nach dem Neustart zweimal weg, mit dem Fix überleben alle nicht betroffenen Boxen. Über der Kapazitätsgrenze schlagen Speichervorgänge jetzt sauber und sichtbar fehl statt still Daten zu riskieren. Die Grenze selbst (~9 Boxen pro Stick) bleibt — dafür braucht es einen größeren Umbau, ohne Datum; das Aufteilen auf zwei Sticks bleibt der empfohlene Weg. Eine deutliche Fehleranzeige in der WebUI folgt.

[fred_feuerstein]

Ok, danke für die schnelle Rückmeldung. Da muss ich mal schauen was ich mache. Der 2.Stick ist ja in meinem Büro an einem anderen Ort. Dort steht die 10. BOX. Bringt mir also zuhause nix.

9 Boxen sind bei mir zuhause, bisher an einem Stick.
erstmal werde ich ein device aus dem Stick entfernen und weiter probieren.
Ob ich dann noch einen weiteren esp32 hole um die Boxen aufzuteilen muss ich überlegen.

[betateilchen]

Danke, ich werde die .34 testen.

Workaround ab sofort: die Flotte auf zwei Sticks aufteilen — mit dem separaten Büro-Stick machst Du schon genau das Richtige, z.B. 5+4 verteilt ist die Kante weg.

Nur interessehalber: gibt es generell eine Möglichkeit, zwei sixback ESP32 im gleichen WLAN zu betreiben, ohne dass sie sich in Quere kommen?

[fred_feuerstein]

Nur interessehalber: gibt es generell eine Möglichkeit, zwei sixback ESP32 im gleichen WLAN zu betreiben, ohne dass sie sich in Quere kommen?

Das würde mich auch interessieren. Dann müsste es ja mindestens eine Whitelist oder Blacklist geben, sonst findet jeder scan die zuvor entfernten Boxen wieder.
Status der Boxen ist dann: wird von anderem sixback verwaltet (oder so ähnlich). Aber die Boxen sind trotzdem in der Liste.

[betateilchen]

Achtung C5: kein Selbst-OTA — Update über den Webflasher ("Update existing").

Schon vor einiger Zeit bin ich dazu übergegangen, Updates nur noch über "Fresh install" zu machen.

Bei "Update existing" läuft zwar das Update problemlos durch, aber danach wird der Stick nie wieder erreichbar. Verwirrend ist dabei auch diese Meldung:

Du darfst diesen Dateianhang nicht ansehen.

Obwohl ich "update" gewählt habe, werde ich gewarnt, dass alle Daten gelöscht werden. Und offenbar passiert das auch tatsächlich.

Ob das ein C5-spezifisches Verhalten ist, habe ich jetzt noch nicht getestet. Mit "Fresh install" funktioniert jedenfalls alles wie gewünscht und letztlich geht es ja danach nur noch darum, das WLAN neu einzutragen.

Übrigens sehe ich nach wie vor nur das verkürzte Menü mit "Installation" und "Log/Console".



--

[betateilchen]

Das würde mich auch interessieren. Dann müsste es ja mindestens eine Whitelist oder Blacklist geben, sonst findet jeder scan die zuvor entfernten Boxen wieder.

Ich könnte mir vorstellen, dass man zuerst den ersten ESP32 in Betrieb nimmt und dazu die dafür vorgesehenen Boxen ins Netz bringt. Wenn die Boxen migriert sind, schaltet man die "Auto-Migration" ab.
Danach trennt man den ESP32 und den ersten Satz Boxen vom Netzwerk.

Nun nimmt man den zweiten ESP32 in Betrieb und verfährt mit der zweiten Gruppe Boxen genauso.

Wenn in beiden ESP32 die Auto-Migration ausgeschaltet ist, sollte nach meiner Vorstellung eigentlich kein "in-die-Quere-kommen" passieren. Allerdings habe ich das noch nicht getestet.

Problem dabei ist nur, dass es dann zwei Geräte im Netzwerk gibt, die behaupten, sie seien "sixback.local". Da sollte man wohl die Sticks nur noch über ihre IP aufrufen und nicht über ihren Namen.