BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[tostmann]

Elf Boxen synchron auf NDR1 — genau das Szenario, für das die Kompressions-Stufe gebaut wurde. Danke fürs Durchziehen, und die Auffälligkeiten sind mindestens so wertvoll wie der Erfolgsfall. Der Reihe nach:

Zur Klarstellung mit den 4 Boxen: das passt ins Bild, präzisiert es sogar. Die Kante des alten Speicherformats lag bei knapp 4 KB, und vier voll belegte Boxen liegen genau in dieser Gegend (~1 KB pro Box). Und dass es ,,von einem Moment auf den nächsten" passierte, hat eine konkrete Erklärung: den Preset-Speicher schreibt nicht nur ein Klick im WebUI, sondern auch der Auto-Migrate-Zyklus, der standardmäßig alle 30 Minuten läuft. Riss bei so einem Hintergrund-Schreibvorgang die 4-KB-Kante, hat die alte Aufräum-Logik den letzten guten Stand gleich mit entsorgt — ganz ohne Zutun. Seit v0.8.15/v0.8.17 ist dieser Mechanismus komplett raus.

9 von 11 nach Reboot + zurückspringende Schalter: die beiden gehören mit hoher Wahrscheinlichkeit zusammen — beides sieht nach fehlschlagenden Schreibzugriffen auf den NVS-Speicher aus (die Geräteliste der letzten zwei Boxen wurde nie persistiert, und die Schalter-Einstellung auch nicht; das WebUI liest dann beim nächsten Refresh den alten Stand zurück). Schöner Beleg dafür: Dein Diagnose-Schalter hat in Wirklichkeit funktioniert — die sieben pre-migrate-Snapshots Deiner Reserve-Boxen sind hier angekommen, danke! Nur gespeichert wurde die Einstellung nicht; nach dem nächsten ESP-Neustart ist sie wieder aus. Eine Bitte daher: Ruf einmal im Browser http://192.168.123.44/api/nvs/stats auf und poste die Ausgabe. Mein Verdacht: die Partition ist aus der Zeit vor der Kompression noch so voll, dass selbst das Umschreiben auf das kompakte Format keinen Platz mehr findet (das braucht kurzzeitig alt+neu gleichzeitig). Wenn die Stats das bestätigen, baue ich eine Aufräum-Aktion, die das auflöst — Deine Daten wären dann der Testfall, an dem sie sich beweisen muss.

Aus den Snapshots sehe ich übrigens, dass die sieben Reserve-Boxen bis vorhin noch auf Deiner soundcork-Instanz hingen und erst gegen 20:22 zu sixback migriert sind — der echte Vollausbau mit allen elf auf einem Stick läuft also erst seit dann. Umso gespannter bin ich, wie sich die Kiste über Nacht hält.

fl_ST20-Blinker: klingt nach grenzwertiger Antwortzeit dieser Box auf unsere Status-Abfragen (mal rechtzeitig, mal nicht — daher grün/weiß im Wechsel). Wenn Du magst: Diagnose-Sharing kurz anschalten und an der Box den Snapshot-Knopf drücken, dann sehe ich mir an, was sie antwortet. Falls es dieselbe Box ist, die schon immer ,,speziell" war, wäre auch Dein geplanter Factory-Reset ein sauberes Experiment.

Chrome auf macOS: notiert. Verdacht: Chromes neue Blockade für Zugriffe ins lokale Netz (Local Network Access) — Safari und Firefox haben die nicht, was zu Deinem Muster passen würde. Schau ich mir an; falls Chrome beim ersten Zugriff eine Berechtigung angefragt und sie verneint wurde, findet sie sich in den Website-Einstellungen wieder.

C5 auf 5 GHz: sehr guter Datenpunkt, danke! Das Thema steht auf der Liste; sobald der Arduino-Unterbau für den C5 stabil genug ist, bauen wir das Target — Hardware zum Gegentesten ist auch hierher unterwegs. Versprechen gibt es wie immer erst nach dem Gegentest.

Und ja: Diagnosedaten aus dem Gerätepark nehme ich gern — die Felddaten von heute Morgen haben am Ende drei Releases an einem Tag getrieben. Die nvs/stats-Ausgabe ist der wichtigste nächste Schritt.

Gruß, Dirk

[betateilchen]

Und ja: Diagnosedaten aus dem Gerätepark nehme ich gern — die Felddaten von heute Morgen haben am Ende drei Releases an einem Tag getrieben. Die nvs/stats-Ausgabe ist der wichtigste nächste Schritt.

Auf die Schnelle eben abgerufen:

Code Auswählen Erweitern

{"used_entries":370,"free_entries":260,"total_entries":630,"namespace_count":14,"percent_used":58.73016}
Bis Mittwoch bin ich auswärts auf einem Workshop, danach kann ich gerne weiter testen.


Edit:

Der output vorhin war mit 4 aktiven Boxen.
Inzwischen habe ich wieder alle 11 Boxen in Betrieb, da verändert sich dann das Ergebnis der Abfrage.

Code Auswählen Erweitern

{"used_entries":395,"free_entries":235,"total_entries":630,"namespace_count":14,"percent_used":62.69841}

Edit 2: aktuell sind wieder alle 11 Boxen in sixback zu sehen. Auch nach einem eben durchgeführten ESP-reboot sind noch alle 11 Boxen sichtbar.

[betateilchen]

Chrome auf macOS: notiert. Verdacht: Chromes neue Blockade für Zugriffe ins lokale Netz (Local Network Access) — Safari und Firefox haben die nicht, was zu Deinem Muster passen würde. Schau ich mir an; falls Chrome beim ersten Zugriff eine Berechtigung angefragt und sie verneint wurde, findet sie sich in den Website-

Man muss Google Chrome explizit erlauben, Geräte im lokalen Netzwerk suchen zu dürfen.
Dann klappt es auch mit sixback.

[tostmann]

Hallo betateilchen,

kurz, nur das was für deinen Aufbau neu und relevant ist (die vollständigen Release-Notes zu v0.8.18 bis v0.8.21 stehen auf GitHub):

In v0.8.21 ist die Migration robuster gegen schwaches WLAN geworden: der Telnet-Schritt retried jetzt (3x), ein einzeln verlorenes Paket bricht die Migration nicht mehr ab, und schlägt sie doch fehl, steht der RSSI des ESP in der Meldung statt eines nichtssagenden "Kommando fehlgeschlagen". Hintergrund war ein Fall mit RSSI -86, bei dem die Migration reproduzierbar an einem einzelnen Kommando hängen blieb.

Aus demselben Fall eine Erkenntnis, die vielleicht dein fl_ST20-"Blinken" erklärt: entscheidend für die Zuverlässigkeit ist der Link zwischen ESP und AP, nicht die Nähe des Sticks zum Speaker (die beiden reden nur über das LAN). Ein schwaches ESP-Signal führt zu grenzwertigen Antwortzeiten — also genau deinem Status-Dot-Flapping-Verdacht. Wirf mal einen Blick auf den RSSI in /api/status; wenn der grottig ist, Stick näher an den Router/AP. Und falls beim nächsten 11er-Lauf wieder etwas zurückspringt oder verloren geht: Snapshot-Button bei der betroffenen Box (Diagnose-Sharing an), dann sehe ich Modell, Firmware und Live-Status direkt.

Viele Grüße, Dirk

[fred_feuerstein]

wegen dem Status-Blinken. Das Problem habe ich auch. Also der Status wird nicht immer korrekt dargestellt und verändert sich von online/play zu offline usw. obwohl der Lautsprecher aktiv ist und Musik abspielt.

Und mein ESP32 S3 liegt direkt neben einer Fritzbox.

Werde es weiter beobachten, wenn ich aus dem Urlaub zurück bin

[tostmann]

Hi fred,

danke für die Rückmeldung — und gerade weil der S3 bei dir direkt neben der Fritzbox sitzt, ist das ein wichtiger Datenpunkt: dann ist es eben NICHT der Funk-Link zwischen ESP und AP, sondern etwas anderes. Mein RSSI-Hinweis weiter oben deckt deinen Fall also nicht ab.

Was die Statusanzeige eigentlich ist
Das online/play- bzw. offline-Label im WebUI ist kein Zustand, den der Speaker meldet, sondern eine periodische Erreichbarkeits-Probe, die SixBack selbst fährt: erst ein Connect auf die Bose-Diagnose-Konsole, und wenn die nicht kommt, ein Fallback auf die normale Geräte-API. Das läuft im Hintergrund für jeden Speaker nacheinander durch. Mit der Wiedergabe hat das nichts zu tun — die Audio-Dekodierung läuft komplett auf dem Speaker, unabhängig davon, ob SixBack ihn in genau dieser Sekunde erreicht.

Was das bedeutet
Wenn die Kachel auf offline springt während der Speaker weiterspielt, hat SixBack nur eine Probe-Runde verfehlt — nicht der Speaker aufgehört. Die Bose-Diagnose-Konsole ist eine schlanke geräteinterne Schnittstelle, die unter Last (mehrere Speaker kurz hintereinander geprobt, oder der periodische Hintergrund-Zyklus der einmal alle anfasst) auch mal kurz nicht antwortet. Dann kippt die Kachel für genau diesen Durchlauf. Das ist ein Anzeige-Problem, kein Wiedergabe-Problem — vorausgesetzt, der Ton läuft tatsächlich weiter.

Die eine Frage, die alles entscheidet
Bricht bei so einem Wechsel der Ton wirklich ab, oder springt nur die Kachel auf offline und die Musik läuft unbeirrt weiter? Das ist der Knackpunkt: nur-Kachel = kosmetisch, da gehört die Probe entprellt. Wenn der Ton dabei wirklich abreißt, ist das ein anderer, echter Fehler, dem ich völlig anders nachgehen muss.

Was mir hilft
Wenn es das nächste Mal passiert: schick mir einen Diagnostic-Snapshot — der fängt zwar nicht den Moment des Umspringens ein, sagt mir aber, mit welchen Modellen und Firmware-Ständen ich es zu tun habe. Dazu zwei Dinge: wie viele Speaker hast du im Setup, und steht in der Kachel offline oder settling? settling (Diagnose-Konsole weg, Geräte-API noch da) ist bewusst weicher gefärbt und genau für diesen transienten Fall gedacht — wenn du voll offline siehst, sind in dem Durchlauf beide Wege weggekippt.

Stand
Die Kachel erst nach mehreren aufeinanderfolgenden Fehl-Proben auf offline kippen lassen statt nach einer einzigen, und die Proben bei vielen Speakern zeitlich entzerren — das steht auf meiner Liste. Kein festes Datum, aber das ist der richtige Hebel, sobald sich bestätigt, dass nur die Anzeige zappelt und der Ton durchläuft. Schönen Urlaub erstmal.

Dirk

[betateilchen]

entscheidend für die Zuverlässigkeit ist der Link zwischen ESP und AP, nicht die Nähe des Sticks zum Speaker (die beiden reden nur über das LAN).

Von etwas anderem war ich nie ausgegangen.

Inzwischen bin ich wieder zuhause und ich werde mir das Thema mit fl_ST20 nochmal in Ruhe vornehmen, ggf. auch mal den angedachten Factory Reset machen und dann schauen. An ein WLAN Problem denke ich erstmal nicht:

Signalstärke: -72dBm

[betateilchen]

Die Installation von 0.8.21 ist irgendwo hängengeblieben.
Der angezeigte Stand ist seit 10 Minuten so.

Du darfst diesen Dateianhang nicht ansehen.


Edit: ich war mal mutig und habe den RST Button gedrückt, scheint offenbar alles in Ordnung zu sein:

Du darfst diesen Dateianhang nicht ansehen.

[fred_feuerstein]

@dirk

zu deinen Fragen:

Also bei mir sind es 9 bis 10 Lautsprecher. Alle auf letzter bose Firmware.
kann durchaus sein, dass wenn nur 2 Lautsprecher im setup/Betrieb sind das Problem dann nicht auftritt oder nicht auffällt.

Ansonsten. Also die Box spielt weiterhin, aber der Status ändert sich dann nur in sixback und wechselt hin und wieder.

Wegen Farbe der Kacheln etc. Das teste ich dann in 2 Wochen zuhause weiter.

[betateilchen]

Aus demselben Fall eine Erkenntnis, die vielleicht dein fl_ST20-"Blinken" erklärt:

Die fl_ST20 ist inzwischen per LAN Kabel angeschlossen. Auch da macht sie den Blinker.
Jetzt werde ich tatsächlich mal das Factory Reset machen.

Was mir noch aufgefallen ist: Das Umbenennen eines (anderen) Speakers, was seit 0.8.18 funktionieren soll, klappt hier nicht. Das mit dem Reboot habe ich natürlich schon mehrfach probiert.


--

[tostmann]

@fred

danke — das beantwortet die entscheidende Frage: der Ton läuft durch, nur die Kachel zappelt, also rein kosmetisch. Und dein Hinweis mit den 9–10 Boxen hat mich direkt auf die Ursache gebracht.

Der Fehler war konkret: fällt die Bose-Diagnose-Konsole unter Last kurz aus, weicht die Erreichbarkeits-Probe auf die normale Geräte-API aus — dieser Fallback lief aber auf die falsche Portnummer und lieferte nie ein "lebt noch". Dadurch konnte der weiche "settling"-Zustand nie greifen, und die Kachel sprang bei jedem kurzen Aussetzer direkt auf "offline". Bei zehn nacheinander geprobten Boxen passiert das ständig — genau dein Muster.

Beides ist hier behoben: der Fallback trifft jetzt den richtigen Port, und die Anzeige ist entprellt (kippt erst nach mehreren Fehl-Proben). Ich teste den Fix gerade. Danke fürs Melden — der Fall hat einen echten Bug aufgedeckt.

Dirk

[betateilchen]

Die fl_ST20 habe ich nun ins Arbeitszimmer geholt, da steht sie ca. 1 Meter neben einem WLAN Repeater.

Heute Abend hatte plötzlich eine zweite Box - interessanterweise auch eine ST20 - hier im Arbeitszimmer den Blinker gespielt. Das Blinken bezieht sich übrigens nur auf die Anzeige im WebUI von sixback. Auf die Funktion der Box hat das keinen erkennbaren Einfluß, sie spielt munter vor sich hin.

Dann habe ich den besagten Repeater einmal stromlos gemacht und neu gestartet, jetzt scheint das Blinken an der zweiten Box erstmal verschwunden zu sein.

Die fl_ST20 habe ich inzwischen zurückgesetzt und nun kämpfe ich seit einer ganzen Weile damit, die Box wieder für sixback nutzbar zu machen. Sie ist im WLAN, wird von sixback gefunden und angeblich auch migriert. Danach kann ich die Box auch über sixback ein- und ausschalten, der Status des "Power" Buttons wird aber nicht aktualisiert. Auch sind auf der Box nur 4 von 6 presets angekommen und die Box meldet den Status "Sources not synced". Den Button "Re-Sync Sources" habe ich schon zweimal ausprobiert.

Was bei der Box aber funktioniert hat: Ich konnte sie über sixback umbenennen. Den Namen, den ich in der Bose App bei der Einbindung ins WLAN vergeben hatte, hat die Box nicht übernommen.

Mal schauen, wie weit ich heute noch mit dieser seltsamen Box komme...

[betateilchen]

Mal schauen, wie weit ich heute noch mit dieser seltsamen Box komme...

Neuer Status

• der Blinker ist verschwunden
• der neue Name ist stabil
• alle 6 presets sind vorhanden
• Die Meldung "Sources Not Synced" bekomme ich nicht weg
  
  
• die in einem vorherigen Beitrag benannte andere Box läßt sich nach wie vor nicht umbenennen

Für heute ist es genug, ich gehe jetzt schlafen.

[fred_feuerstein]

Mit dem Umbenennen, das könnte auch was anderes sein. Ich habe von meinen 10 Devices auch 3, die ich nichtmal in der bose app umbenennen kann.
Der vorige Name bleibt einfach bestehen.

[tostmann]

Hi,

danke fürs gründliche Durchtesten — betateilchen und fred, dein Punkt von gerade eben gehört direkt dazu. Der Reihe nach:

Umbenennen (das betrifft euch beide): das ist ein echter Bug, kein Bedienfehler — und fred hat den Finger genau draufgelegt, es scheitert ja sogar in der Bose-App. Der Grund: eine an die Cloud gebundene (migrierte) Box wendet einen Rename nicht lokal an, sondern delegiert ihn an ihre Cloud — die Box feuert dabei selbst einen Account-Aufruf ab. Genau diesen Endpoint hat SixBack bisher nicht bedient, also lief der Rename ins Leere (die Box meldet ,,ok", ändert aber nichts). Dass sich deine fl_ST20 nach dem Reset umbenennen ließ, betateilchen, passt ins Bild: frisch zurückgesetzt war sie kurz nicht gebunden, da greift der lokale Rename direkt — die noch gebundenen Boxen (und freds 3 von 10) scheitern. Ich hab den fehlenden Handler ergänzt und auf echter Hardware geprüft: Umbenennen greift dann wieder, in SixBack wie in der Bose-App. Kommt mit einem der nächsten Updates.

,,Sources Not Synced" + dass erst 4 von 6 Presets ankamen: das ist ein anderer Punkt — die Box hat ihre Account-Quellen nicht vollständig registriert. Der Re-Sync soll genau das nachholen; bleibt er bei dir nach zwei Versuchen hängen, schick mir bitte einen Diagnostic-Snapshot der fl_ST20 (Diagnose-Sharing an, dann Snapshot-Knopf). Dann sehe ich an ihrem /sources, woran die Registrierung klemmt, statt zu raten.

Power-Button-Status aktualisiert nicht: die Status-Anzeige ist eine periodische Abfrage, kein Push vom Speaker. Einen physischen Tastendruck am Gerät meldet die Bose-Firmware gar nicht nach außen — deshalb kann die Kachel den Power-Zustand nicht in Echtzeit spiegeln. Das ist eine Grenze der Geräte-Firmware, kein Wackler in SixBack.

Blinken: dass dein Repeater-Neustart der zweiten Box geholfen hat, zeigt, dass da ein Teil schlicht schwaches bzw. überlastetes Netz war. Daneben gab es aber auch einen echten Bug bei uns — die Erreichbarkeits-Probe lief im Fallback auf eine falsche Portnummer und sprang deshalb bei jedem kurzen Aussetzer direkt auf ,,offline" statt auf das weiche ,,settling". Der ist gefixt, und die Anzeige ist zusätzlich entprellt. Kommt im selben Update.

Danke euch beiden — Rename und Probe-Port hätte ich ohne eure Meldungen nicht so schnell gefunden.

Dirk