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.