BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[betateilchen]

Moin,

,,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.

Das Problem hat sich über Nacht offenbar selbst geheilt. Inzwischen ist die Meldung nicht mehr vorhanden.
Snapshot von der Box mit dem Problem hatte ich gestern Abend schon geschickt.

Blinken: dass dein Repeater-Neustart der zweiten Box geholfen hat, zeigt, dass da ein Teil schlicht schwaches bzw. überlastetes Netz war.

Ok, mag sein. Aber wieso trat der Effekt auch bei LAN-Verbindung auf, wo der Repeater gar nicht im Spiel war? Wird von der Box grundsätzlich WLAN bevorzugt, wenn beide Verbindungen bestehen?

[betateilchen]

Der Blinker ist wieder da, hier im Arbeitszimmer bei az_ST20.
Der Repeater sollte nicht überlastet sein, da sind gerade mal 6 Clients angemeldet.

Es ist ja nur ein optisches "Problem", die Funktion der Box ist gegeben.
Trotzdem ein merkwürdiges Phänomen.


--

[tostmann]

Hi betateilchen,

danke für die Screenshots — die helfen sehr, da steckt die halbe Antwort schon drin.

Erstens ,,Sources Not Synced": in deinen Bildern stehen die Presets jetzt auf ,,synced", die Meldung ist weg. Das passt — die Box hatte ihre Account-Quellen anfangs nicht vollständig registriert, der periodische Abgleich holt das im Hintergrund nach. Hier hat er ohne dein Zutun gegriffen.

Zweitens das Blinken: deine beiden Aufnahmen 16 Sekunden auseinander zeigen genau das Kippen grau→grün, während die Box ungestört weiterspielt. Und dein Repeater-Bild ist der entscheidende Hinweis: az_ST20 hängt dort mit 5 GHz und 150 Mbit/s, also bestens angebunden. Damit ist klar, dass es NICHT am schwachen oder überlasteten Funk liegt, sondern an der Erreichbarkeits-Probe selbst. Genau da steckte ein Bug: fiel die Bose-Diagnose-Konsole kurz aus, wich die Probe auf die normale Geräte-API aus — dieser Fallback lief aber auf die falsche Portnummer und meldete deshalb nie ,,lebt noch". Folge: die Kachel sprang bei jedem kurzen Aussetzer direkt auf ,,offline" statt auf das weiche ,,settling", egal wie gut die Verbindung ist.

Das ist in v0.8.22 behoben (seit gestern Abend draußen): richtiger Port plus Entprellung, die Kachel kippt erst nach mehreren Fehl-Proben in Folge. Zieh das Update auf az_ST20, dann sollte das Flackern dort verschwinden. Hörbar war es ja ohnehin nie — die Box spielt unbeeindruckt weiter, die Kachel ist nur eine periodische Abfrage.

Zur LAN-Frage: dein Repeater-Bild beantwortet sie fast selbst. az_ST20 taucht dort weiterhin über WLAN auf (5 GHz, 150 Mbit/s), obwohl du das Kabel gesteckt hattest — die Box hat ihre WLAN-Verbindung also nicht aufgegeben. Heißt: dein ,,LAN-Test" hat den Repeater vermutlich gar nicht aus dem Spiel genommen, die Box lief die ganze Zeit über WLAN. Für SixBack ist es ohnehin einerlei, welchen Weg die Box nimmt — es spricht sie nur über die IP an, unter der sie im Netz auftaucht, und das Flackern kommt von der Probe, nicht vom Verbindungsweg.

Danke fürs gründliche Dokumentieren — sag gern, ob das Flackern nach dem v0.8.22-Update auf az_ST20 weg ist.

Dirk

[betateilchen]

Moin Dirk,

Erstens ,,Sources Not Synced": in deinen Bildern stehen die Presets jetzt auf ,,synced", die Meldung ist weg.

Die Presets standen auch vorher schon auf "synced" als die Meldung "Sources not synced" angezeigt wurde.

Genau da steckte ein Bug: fiel die Bose-Diagnose-Konsole kurz aus, wich die Probe auf die normale Geräte-API aus — dieser Fallback lief aber auf die falsche Portnummer und meldete deshalb nie ,,lebt noch". Folge: die Kachel sprang bei jedem kurzen Aussetzer direkt auf ,,offline" statt auf das weiche ,,settling", egal wie gut die Verbindung ist.

Das ist in v0.8.22 behoben (seit gestern Abend draußen): richtiger Port plus Entprellung, die Kachel kippt erst nach mehreren Fehl-Proben in Folge. Zieh das Update auf az_ST20, dann sollte das Flackern dort verschwinden. Hörbar war es ja ohnehin nie — die Box spielt unbeeindruckt weiter, die Kachel ist nur eine periodische Abfrage.

Das Update auf .22 hatte ich heute morgen schon eine Stunde vor dem Entstehen der beiden Screenshots durchgeführt.

Aktuell ist das Blinken wieder ohne jegliches Zutun meinerseits verschwunden, es sind jetzt aber auch nur 4 der 11 Boxen im Netzwerk angemeldet. Heute morgen waren noch alle 11 in Betrieb.

Zur LAN-Frage: dein Repeater-Bild beantwortet sie fast selbst. az_ST20 taucht dort weiterhin über WLAN auf (5 GHz, 150 Mbit/s), obwohl du das Kabel gesteckt hattest
...
es spricht sie nur über die IP an, unter der sie im Netz auftaucht,

Der Test mit dem LAN Kabel war gestern Abend, heute morgen waren alle Boxen nur per WLAN angebunden.
Bezüglich der IP: Als die Box mit LAN Kabel angeschlossen war, hatte sie ja für den LAN port eine andere IP Adresse, das wurde von sixback auch korrekt erkannt. Hat jetzt vermutlich auch nichts mit dem Flackern zu tun, aber ich wollte das zumindest noch als "Positivmeldung" erwähnt haben.

Was wollen mir die Meldungen im Anhang eigentlich sagen?
Was ich gemacht habe: die 7 zusätzlichen Boxen wieder mit Strom versorgt, weil ich testen wollte, ob das Blinken bei 11 aktiven Boxen wieder auftritt.


--

[tostmann]

Hi betateilchen,

die Meldung ,,ours, but URL stale — will be repaired on reboot" ist genau das, was sie sagt, und kein Defekt: die Box ist zu deinem SixBack-Stick migriert (deshalb ,,ours"), hat aber noch die ALTE IP-Adresse deines Sticks als Cloud-Adresse gespeichert. Das passiert, wenn der Stick selbst per DHCP eine neue IP bekommen hat — dann zeigen die Boxen noch auf die alte Stick-IP, die es so nicht mehr gibt. Genau deshalb sehen auch nur 4 von 11 ,,aktiv" aus: die mit der alten Adresse erreichen ihre Cloud (= deinen Stick) unter dem gespeicherten Pfad nicht mehr, bis sie umgebogen sind.

SixBack repariert das von selbst. Das IP-Failsafe biegt jede ,,eigene" Box beim nächsten Stick-Start auf die aktuelle Stick-IP um, und der periodische Re-Claim macht dasselbe im Hintergrund — das kann ein paar Minuten dauern. Wenn du nicht warten willst: den SixBack-Stick einmal kurz stromlos machen; beim Hochfahren re-migriert er alle eigenen Boxen in einem Rutsch, danach stehen sie wieder auf ,,migrated". Die eine Box, die als OFFLINE markiert ist, muss dafür erreichbar sein — sobald sie wieder online ist, wird sie genauso umgebogen wie die anderen.

Damit das gar nicht erst auftritt: eine DHCP-Reservierung für die MAC-Adresse des SixBack-Sticks in der Fritzbox bzw. im Router. Dann ändert sich die Stick-IP nie, und die Boxen können nicht mehr ,,stale" werden — das ist auch im README als empfohlenes Setup vermerkt. Bei einem 11-Boxen-Dauertest ist ein Stick-Reboot (und damit ein IP-Wechsel) schnell mal passiert, die Reservierung nimmt das Thema komplett raus.

Zwei kleinere Punkte aus deinem Post: dass ,,Sources not synced" noch stand, obwohl die Presets schon gefüllt waren, ist kosmetisch — das Sync-Flag wird bei jedem Status-Refresh neu ermittelt und hinkt der tatsächlichen Preset-Liste manchmal kurz hinterher. Und die andere IP von az_ST20 im LAN-Test ist die IP der BOX selbst (am LAN-Port), nicht die deines Sticks; die ,,stale"-Meldung dreht sich allein um die Stick-IP.

Dirk

[fred_feuerstein]

gerade wollte ich das Update von 0.8.21 auf 0.8.23 machen. Lief alles durch, dann Meldung ESP Reboot...
Und sixback ist nicht mehr erreichbar. Hat scheinbar den Reboot nicht geschafft.

Jetzt ist wohl tatsächlicher erstmal Test-Pause bis ich wieder zuhause bin

[betateilchen]

die ,,stale"-Meldung dreht sich allein um die Stick-IP.

Vielleicht könnte man in der Meldung etwas klarer machen, dass es um den reboot von sixback geht und nicht um den reboot des Lautsprechers.

Zum Thema IP-Vergabe: sixback hat hier seit Anbeginn der Nutzung durchgehend immer die gleiche IP.

[betateilchen]

gerade wollte ich das Update von 0.8.21 auf 0.8.23 machen. Lief alles durch, dann Meldung ESP Reboot...
Und sixback ist nicht mehr erreichbar. Hat scheinbar den Reboot nicht geschafft.

Bei mir hat das Update von .22 auf .23 auf einem ESP32-S3 16MB problemlos funktioniert.

Nach dem Reboot des ESP haben die 7 "zusätzlichen" Boxen fast alle wieder die stale-Meldung. Nur die eine Box, die offline meldet, tanzt aus der Reihe. Keine Ahnung, warum die offline sein soll.

[tostmann]

Danke für die Meldung — und Entwarnung vorweg: gebrickt ist da nichts. Ein OTA-Update kann den Stick nicht hardware-seitig zerstören; im schlimmsten Fall holt man ihn per USB über den Webflasher in zwei Minuten zurück. Wichtiger: ich glaube, ich habe die Ursache, und sie passt genau zu deiner Installation.

Du fährst mit Abstand die größte Installation hier (um die zehn Boxen). Die neue Hardware-Tasten-Funktion aus 0.8.23 hält pro Box eine kleine Dauerverbindung offen. Bei sehr vielen Boxen laufen damit zehn solcher Dauerverbindungen gleichzeitig — zusammen mit der normalen Geräte-Suche, der Cloud-Anbindung und dem OTA-Download kann das das interne Verbindungs-Budget des ESP überlaufen. Ergebnis: der Stick läuft eigentlich weiter, aber die Weboberfläche nimmt keine Verbindung mehr an, also wirkt er ,,nicht erreichbar". Auf kleineren Installationen tritt das nicht auf, deshalb ist es bisher niemandem untergekommen.

Ich habe gerade 0.8.24 veröffentlicht, die genau das abfängt: es bleiben maximal vier dieser Dauerverbindungen gleichzeitig offen, bei mehr Boxen rotieren sie fair durch. Damit bleibt der Stick auch bei zehn Boxen jederzeit erreichbar. Auf einem Test-S3 hier ist 0.8.24 sauber per OTA durchgelaufen.

So bekommst du deinen Stick wieder und auf 0.8.24:

• Zuerst den Stick einmal stromlos machen (10 Sekunden Netzteil ziehen). Nach dem Neustart sollte er wieder antworten.
• Falls er unter der alten Adresse nicht auftaucht, im Router die Geräteliste prüfen — nach dem Reboot kann er eine neue IP bekommen haben (Hostname beginnt mit ,,sixback"). Eine feste DHCP-Reservierung verhindert das künftig.
• Wenn er wieder da ist: das Update auf 0.8.24 anstoßen, das sollte dir jetzt angeboten werden.
• Nur falls gar nichts hilft: einmal per USB über den Webflasher neu aufspielen — danach normal weiter.

Und falls es dir nichts ausmacht: wenn der Stick wieder läuft, würde mich nach dem Update ein kurzer Blick interessieren, ob mit 0.8.24 jetzt alles stabil bleibt. Sag Bescheid, wenn was klemmt.

[betateilchen]

Und falls es dir nichts ausmacht: wenn der Stick wieder läuft, würde mich nach dem Update ein kurzer Blick interessieren, ob mit 0.8.24 jetzt alles stabil bleibt. Sag Bescheid, wenn was klemmt.

Vermutlich kann es ein bisschen dauern, bis Fred das testen kann

Gestern hatte er geschrieben:

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