FHEM Forum

Bose hat am 6. Mai 2026 die SoundTouch-Cloud abgeschaltet. Damit gehen auf den Speakern Presets, NowPlaying, Stereo-Pairing, Updates etc. ins Leere. Die Firmware kann nicht gepatcht werden — die Boxen sprechen weiter ihr BMX-Cloud-Protokoll, nur niemand antwortet mehr.

BoseFix32 ist eine Firmware für einen handelsüblichen ESP32. Wer hier mitliest hat vermutlich eh schon einen ESP32 für andere FHEM-Sachen rumliegen — das reicht. Für die nicht-Bastler in der Familie (Mutti, Oma, der Nachbar mit der SoundTouch im Wohnzimmer): jeder 5-€-ESP32 vom Distributor tut's, geflasht wird per Chrome-Browser auf install.busware.de/bosefix/ (https://install.busware.de/bosefix/) — einmal "Connect" klicken, dauert ~30 Sekunden, fertig. Wer auch das nicht selbst machen will: ein technik-affiner Bekannter flasht den Stick einmalig, dann läuft er autonom im LAN. Keine Cloud, kein Account, kein Abo. Eine USB-Stromversorgung und WLAN reichen.

Was es kann:

• SoundTouch 10 / 20 / 30 entdeckt sich via SSDP + Auto-Discovery
• Migration in einem Klick: rewrite der Cloud-URLs am Speaker via Telnet :17000, Presets bleiben erhalten
• TuneIn-Stations spielen direkt (Live-Resolver gegen radiotime.com)
• Custom Stream-URLs als Preset (z.B. Fritzbox-Radio, RadioBrowser-Stationen)
• DLNA / UPnP / Bluetooth-Presets als Passthrough — Speaker spricht den DLNA-Server eh direkt an, BoseFix32 reicht das ContentItem nur durch
• Stereo-Pair / Multi-Room-Gruppen, NowPlaying-Telemetrie, Preset-Long-Press-Push
• Web-UI auf http://bosefix.local/ für alles — discovery, migration, presets, gruppen
• Diagnostic-Snapshot per Knopfdruck wenn was nicht klappt — JSON-Dump kann direkt an den Maintainer hochgeladen werden

Was es nicht kann:

• Spotify (technisch möglich über Connect+OAuth, aber eigenes Projekt)
• Amazon Prime Music (war nie eine eigene BMX-Source, lief nur über die App)
• Andere Bose-Speaker als SoundTouch 10/20/30 — andere Modelle ungetestet

Installation: https://install.busware.de/bosefix/ (https://install.busware.de/bosefix/) — der Webflasher erkennt den ESP automatisch, Chrome / Edge öffnen, "Connect" klicken, fertig. Es geht jeder ESP32 den ihr rumliegen habt: classic, S3, C3, C6 — alle vier Targets werden gebaut und im Webflasher angeboten. Empfehlung wenn ihr neu kauft: ein ESP32-S3-DevKitC-1-N16R8 (~10 €) wegen 16 MB Flash und 8 MB PSRAM, mehr Headroom für künftige Features. Funktioniert aber auch auf einem 4-MB-ESP32 classic aus der Schublade.

Quellen:

• Repo + Issues: github.com/tostmann/BoseFix32 (https://github.com/tostmann/BoseFix32)
• Spec-Grundlage: julius-d/ueberboese-api (https://github.com/julius-d/ueberboese-api) — open OpenAPI-Spec der Bose-Streaming-Cloud

Stand: v0.6.0 ist gerade frisch released (DLNA-Passthrough + Diagnostic-Snapshot). OTA-Update von älteren Versionen läuft.

Feedback, Bug-Reports und vor allem Snapshots von Geräten die exotische Source-Types nutzen sind willkommen — der Diagnostic-Snapshot-Knopf im WebUI lädt das direkt an mich hoch (ohne WLAN-Passwort, ohne Tokens — nur Speaker-MAC, FW-Version, Source-XMLs).

So long,
Dirk

P.S.: Ich war doch verwundert wie viele Bose-Nutzer es außer mir gibt und wie eine solche Firma einfach den Schalter umlegen kann — lasst es uns eine Warnung sein ...

Antwort auf: https://forum.fhem.de/index.php?topic=144574.msg1363970#msg1363970

Schön, dass das Update durchgelaufen ist und DLNA jetzt wieder funktioniert. Zu deinen Punkten der Reihe nach:

DLNA-Preset NEU anlegen
Aktuell nein. BoseFix32 reicht ein DLNA-ContentItem, das der Speaker schon hatte, 1:1 wieder zurueck — er bringt also seine alten Presets ueber die Migration. Aber: einen DLNA-Server zu browsen (Ordner aufklappen, Track waehlen, als Preset speichern) heisst, einen UPnP/ContentDirectory-Client im ESP32 zu haben. Das ist substantieller Aufwand und steht aktuell nicht auf der Liste — ehrlicher Stand. Was als Workaround geht: wenn du die Stream-URL deines Fritzbox-Webradios oder einer DLNA-Quelle direkt kennst (z.B. aus der Fritzbox-UI rauskopiert), kannst du sie als "Direct stream (URL)" in BoseFix32 als Preset speichern. Das ist dann technisch INTERNET_RADIO, nicht STORED_MUSIC, aber fuer Webradio-Streams ist das identisch von der Funktion.

Spotify
Ehrlich nein. Spotify Connect vom Handy laeuft ja schon — der Speaker spricht da direkt mit dem Spotify-Dienst, BoseFix32 ist gar nicht im Pfad. Damit Playlists als Preset gehen wuerde, brauchen wir Spotify-OAuth + die Spotify-Web-API fuer Playlist-Browsing + die ContentItem-Struktur source="SPOTIFY". Das ist ein eigenes Projekt — kein "kommt naechste Woche". Vorlaeufiger Tipp: in der BoseConnect-/SoundTouch-Hardware-Buttons-1-6 ueber Spotify Connect zu mappen geht ja eh nicht, das funktioniert nur ueber dieses Long-Press am Speaker — und genau das macht BoseFix32 fuer alle anderen Quellen. Spotify ist die Luecke, ja.

bosest 7-20
Bose-Speaker haben hardware-seitig Buttons 1-6. Die Slots 7-20 die das FHEM-Modul "bosest" anbietet sind eine FHEM-Erweiterung — das Modul merkt sich die ContentItems lokal und sendet sie per /select an den Speaker, ohne dass es einen physischen Button-Press dafuer gaebe. Technisch interessant, BoseFix32 macht das aktuell nicht — denkbar als WebUI-Feature ("zusaetzliche Quick-Picks ohne Long-Press"), aber kein konkretes Date.

Amazon Prime Music in Bosman
Danke fuer den Hinweis. Wenn Bosman das hinkriegt waere das eine extra Source. Bei BoseFix32 nicht geplant — Amazon-API ist hostile, OAuth, Geo-Locked, das wird nur zum Frust.

Snapshot — welcher Speaker?
Der beste Snapshot fuer mich ist: ein bereits migrierter Speaker, der ein funktionierendes DLNA-Preset enthaelt. Also genau der, an dem du jetzt nach dem v0.6.0-Update das DLNA-Preset wieder siehst. Da lese ich das echte ContentItem im rohen XML-Format heraus und sehe, wie dein DLNA-Server (Fritzbox?) die UPnP-URL formatiert. Mit diesem Format kann ich beurteilen, ob man eine "DLNA-URL hinterlegen"-UI bauen koennte, ohne einen vollen UPnP-Browser zu implementieren. Snapshot frisch nach Reset oder vor Migration brauchst du nicht zu uebernehmen — frisch zurueckgesetzt hat eh nichts drin und unmigriert hat keine relevanten Daten mehr (Cloud ist aus). Klick einfach im WebUI auf den Speaker, dann auf "Diagnostic snapshot" → "Send to maintainer". Kein Account, kein Token, kein WLAN-Passwort enthalten.

6 von 8 Geraeten — der wichtigste Punkt
Das ist ein echter Bug oder Setup-Problem, dem will ich nachgehen. Was BoseFix32 macht:

• SSDP-Multicast M-SEARCH auf 239.255.255.250:1900, ST=urn:schemas-upnp-org:device:MediaRenderer:1, 4 Sekunden lauschen
• Bekannte IPs aus dem NVS (alle frueher gesehenen Speaker) abklopfen
• Active-Scan ueber /24 wenn entsprechend konfiguriert
• Manuelle IP: HTTP-GET http://IP:8090/info, erwartet wird ein XML mit "<info deviceID=...>"

Damit ein Speaker NICHT entdeckt wird, muss mindestens einer dieser Punkte fehlschlagen. Diagnose-Schritte die mir helfen wuerden:

• Welche Bose-Modelle sind die 2 fehlenden? (SoundTouch 10/20/30, Wave SoundTouch, SoundTouch 130/300/520, Wireless Link Adapter, Soundbar, ...)
• IP-Adressen der 2 fehlenden Speaker — bekommst du die aus deinem Router oder aus FHEM/bosest? Bitte gegen die manuell adden im BoseFix32-WebUI testen.
• Wenn manuell-add fehlschlaegt: auf einer Shell folgendes absetzen:
  Code Auswählen Erweitern
  curl -v http://<fehlende-ip>:8090/infoBekommst du da ein XML zurueck das mit "<info deviceID=..." beginnt? Oder gibt es Connection-Refused / Timeout / anderen Inhalt?
• Sind alle 8 Geraete im selben Subnetz (gleiches /24)? Multicast/SSDP geht nur innerhalb des Broadcast-Domain.
• Hast du IGMP-Snooping auf deinem Switch oder Multicast-Filtering auf dem AP? Auf Aruba- oder Unifi-Setups verschluckt das gerne SSDP-Antworten — fuer 6 von 8 Geraeten klappt es dann zufallsverteilt.

Wenn du mir die Modelle der 2 fehlenden Speaker und das curl-Ergebnis vom /info-Endpoint nennst, finden wir die Ursache schnell. Bei einem v.a. Multicast-Problem koennte ich auch nochmal mehr Spam-Logging in den Discovery-Code einbauen — dann sieht man im seriellen Output von BoseFix32 welche IPs auf M-SEARCH antworten und welche nicht.

So long,
Dirk

ZitatDLNA-Preset NEU anlegen
Aktuell nein. BoseFix32 reicht ein DLNA-ContentItem, das der Speaker schon hatte, 1:1 wieder zurueck — er bringt also seine alten Presets ueber die Migration. Aber: einen DLNA-Server zu browsen (Ordner aufklappen, Track waehlen, als Preset speichern) heisst, einen UPnP/ContentDirectory-Client im ESP32 zu haben. Das ist substantieller Aufwand und steht aktuell nicht auf der Liste — ehrlicher Stand. Was als Workaround geht: wenn du die Stream-URL deines Fritzbox-Webradios oder einer DLNA-Quelle direkt kennst (z.B. aus der Fritzbox-UI rauskopiert), kannst du sie als "Direct stream (URL)" in BoseFix32 als Preset speichern. Das ist dann technisch INTERNET_RADIO, nicht STORED_MUSIC, aber fuer Webradio-Streams ist das identisch von der Funktion.

also ich habe hier einen Lautsprecher, der noch nicht migriert ist und die QUelle STORED_MUSIC noch kennt. Er hat 6 Presets, die alle auf den DLNA von der Fritzbox zeigen. Einmal einen MP3 Ordner auf der 1 und dann 2 bis 6 Radiosender von der Fritzbox.
So sieht es aus vor Migration: Bild1
Nach der Migration sieht es so aus: Bild2

im Webif von bosefix32 stehen alle presets drin. Aber wenn ich einen Preset an der Box einschalte, kommt auf dem Display: Preset noch nicht gewählt (oder so ähnlich). Und in der original Bose-App sehe ich auch, dass kein Medienserver zu sehen ist.
Wenn ich auf einen der Presets im Webif von bosefix klicke, um den auf der Box zu speichern kommt der Hinweis: Quelle nicht vorhanden. Also das geht so nicht.
Wüsste auch nicht, welchen Pfad als Direktstream ich eingeben sollte. Per XML curl kann man ja die Presets auch setzen von der Fritzbox als Quelle, aber auch nur wenn bereits der STORED_MUSIC hinterlegt ist. Denke, das ist eines der Hauptprobleme aktuell.
Von dieser Box sende ich Dir jetzt mal den Snapshot. (13:53 Uhr)

Hier muss ich also vorerst entweder Radiosender als direktstream einbinden oder über tunein. tunein lasse ich erstmal aussen vor.
Oder ich muss die Einrichtung der Box über die bosman-App machen und zu deren Server migrieren. In der App kann ich dann auf meine medienserver zugreifen und Quellen von dort setzen. Ziel wäre natürlich die Bosman-App nicht mehr zu benötigen.

ZitatSpotify

soweit verstanden. Ist also evtl. irgendwann mal ein separates Projekt :)

Zitatbosest 7-20

Das war gar nicht meine Erwartung, die SPeicherung von 7- 20 Presets. Hier reicht ja die Möglichkeit in BOSEST-FHEM. Denke in bosefix sollte erstmal der Standard laufen. :)

ZitatAmazon Prime Music in Bosman

Wie gesagt, war nur als Hinweis gedacht. kein momentanes todo etc. :)

ZitatSnapshot — welcher Speaker?
Der beste Snapshot fuer mich ist: ein bereits migrierter Speaker, der ein funktionierendes DLNA-Preset enthaelt. Also genau der, an dem du jetzt nach dem v0.6.0-Update das DLNA-Preset wieder siehst.

Genau so einen Lautsprecher habe ich nicht. Siehe oben. Nach der Migration sind die Presets nicht mehr an der Box verfügbar und der STORED_MUSIC ist weg.

Zitat6 von 8 Geraeten — der wichtigste Punkt
Das ist ein echter Bug oder Setup-Problem, dem will ich nachgehen. ...

• 1. Welche Bose-Modelle sind die 2 fehlenden? (SoundTouch 10/20/30, Wave SoundTouch, SoundTouch 130/300/520, Wireless Link Adapter, Soundbar, ...)
• 2. IP-Adressen der 2 fehlenden Speaker — bekommst du die aus deinem Router oder aus FHEM/bosest? Bitte gegen die manuell adden im BoseFix32-WebUI testen.
• 3. Wenn manuell-add fehlschlaegt: auf einer Shell folgendes absetzen:
  
  Code Auswählen Erweitern
  curl -v http://<fehlende-ip>:8090/infoBekommst du da ein XML zurueck das mit "<info deviceID=..." beginnt? Oder gibt es Connection-Refused / Timeout / anderen Inhalt?
• 4. Sind alle 8 Geraete im selben Subnetz (gleiches /24)? Multicast/SSDP geht nur innerhalb des Broadcast-Domain.
• 5. Hast du IGMP-Snooping auf deinem Switch oder Multicast-Filtering auf dem AP? Auf Aruba- oder Unifi-Setups verschluckt das gerne SSDP-Antworten — fuer 6 von 8 Geraeten klappt es dann zufallsverteilt.

Wenn du mir die Modelle der 2 fehlenden Speaker und das curl-Ergebnis vom /info-Endpoint nennst, finden wir die Ursache schnell. Bei einem v.a. Multicast-Problem koennte ich auch nochmal mehr Spam-Logging in den Discovery-Code einbauen — dann sieht man im seriellen Output von BoseFix32 welche IPs auf M-SEARCH antworten und welche nicht.

zu 1: also es sind eine Soundtouch Portable und eine Soundtouch 30, die nicht gefunden werden und auch manuell nicht hinzugefügt werden können.
zu 2: die IP Adressen habe ich aus dem Router. Sind aber auch im FHEM BOSEST enthalten und die gleichen.

Der Scan findet sie nicht und manuell über IP geht auch nicht.

zu 3: im Browser oder in einer Shell kommt bei curl -v http://<fehlende-ip>:8090/info ein passendes xml:
<info deviceID="F4844C2FFCAB">
<name>EG_Kueche_ST30</name>
<type>SoundTouch 30</type>
<margeAccountUUID>cmp5q12324523452356325345235oaunh</margeAccountUUID>
<components>
<component>
<componentCategory>SCM</componentCategory>
<softwareVersion>
27.0.6.46330.5043500 epdbuild.trunk.hepdswbld04.2022-08-04T11:20:29
</softwareVersion>
<serialNumber>F81239457239457239457239057235940</serialNumber>
</component>
<component>
<componentCategory>PackagedProduct</componentCategory>
<serialNumber>069447981830183AE</serialNumber>
</component>
</components>
<margeURL>https://server.bosman.app</margeURL>
<networkInfo type="SCM">
<macAddress>F4844C2FFCAB</macAddress>
<ipAddress>192.168.123.191</ipAddress>
</networkInfo>
<networkInfo type="SMSC">
<macAddress>F4844C475155</macAddress>
<ipAddress>192.168.123.191</ipAddress>
</networkInfo>
<moduleType>sm2</moduleType>
<variant>mojo</variant>
<variantMode>normal</variantMode>
<countryCode>GB</countryCode>
<regionCode>GB</regionCode>
</info>bei der portable kommt auch ein xml Ergebnis.
Und vor allem. In der orig. Bose-App sind alle Boxen zu finden, in fhem sind alle Boxen und in Boseman auch.

zu4: ja sind alle im gleichen Netz. Habe nur ein Subnetz zuhause. Ist zwar recht groß, aber nur ein subnetz.
zu5: das kann ich Dir nicht sagen. Ich habe nur Fritz-Geräte im Einsatz. Da ist zumindest nichts speziell konfiguriert oder speziell abgeschaltet was das betrifft.

Puh. Doch eine längere Nachtricht :)

Danke fuer die zwei Snapshots — sind beide angekommen und ausgewertet. Damit habe ich genau was ich brauchte.

Was im Snapshot vom unmigrierten SoundTouch 10 drin stand
Alle 6 Slots sind STORED_MUSIC mit Pfaden in deine FRITZ!Box als DLNA-Server. Beispiel-ContentItem fuer "Bayern 3":

<ContentItem source="STORED_MUSIC"
             location="4:cont2:615:part22:32"
             sourceAccount="<fritzbox-media-server-uuid>/0"
             isPresetable="true">
  <itemName>Bayern 3</itemName>
</ContentItem>
Wichtigste Erkenntnisse:

• Das location-Attribut ist eine hierarchische UPnP-ObjectID, Fritzbox-spezifisches Format ("4:cont2:615:part22:32"). Die ist nicht raten, nur der DLNA-Server kennt sie.
• Das sourceAccount besteht aus der UUID des DLNA-Servers + Slot-Index. Die UUID liefert der Speaker selbst via seinem "/listMediaServers"-Endpoint — bei dir stehen dort 4 Server drin (2× FRITZ!Box, 2× xupnpd).
• Der Speaker kann ueber seine eigenen BMX-Endpoints ("getMediaServerNavigation", "playMediaServerNavigation") durch den DLNA-Server browsen. Heisst: ein "DLNA-Preset anlegen"-UI in BoseFix32 muss nicht selbst UPnP sprechen — wir lassen den Speaker das machen und reichen das ContentItem nur an /select weiter.

Damit ist STORED_MUSIC-Preset-Anlegen technisch realistisch konzipiert. Ich nehme das auf die Liste fuer eine v0.7 — keine Wochen-Versprechung, aber jetzt mit klarem Plan statt Spekulation.

Wichtige Beobachtung zum migrierten Speaker
Bei dem 2. Snapshot (OG_Bad_ST10weiss) zeigt die "margeServerUrl" auf "https://server.bosman.app". Du hast also einen Teil deiner Speaker schon auf das bosman.app-Projekt migriert, nicht zu BoseFix32. Das ist kein Problem, sehr interessant sogar: bei diesem Speaker sind Slots 2-6 LOCAL_INTERNET_RADIO (json-URLs auf "192.168.123.238"), Slot 1 ist STORED_MUSIC geblieben. Heisst: irgendeine Stelle (bosman.app oder du manuell?) hat die DLNA-Presets durch direkte Stream-URLs ersetzt. Wenn das automatisch passiert ist, ist das schlau — Webradio funktioniert dann ohne DLNA-Abhaengigkeit.

Discovery-Bug: 6 von 8 Geraeten
Diese Diagnose-Frage ist noch offen — im Snapshot stehen nur 2 Speaker drin. Wenn du Lust hast den Forensik-Pfad weiterzugehen:

• Welche Modelle und IPs haben die restlichen 6 Geraete? Aus dem FHEM-bosest-Modul oder Router-DHCP-Tabelle lesbar.
• Stehen alle 8 Geraete im gleichen 192.168.123.0/24? Multicast/SSDP geht nur innerhalb /24.
• Versuche mal von der Pi-Konsole "curl -v http://<fehlende-ip>:8090/info" gegen eine der nicht-gefundenen IPs. Wenn die ein XML mit "<info deviceID=..." zurueckliefert, ist es ein Discovery-Problem; wenn nicht, ist es kein klassischer SoundTouch oder Port 8090 ist gefiltert.

Frage am Rande
Du hattest in deinem Post geschrieben "So sieht es aus:" und vermutlich einen Screenshot angehaengt. Der ist in deinem Posting leer geblieben — kein Anhang sichtbar. Wenn du den nochmal hochlaedst, kann ich gegenpruefen ob bei euch in der WebUI die Presets gleich angezeigt werden wie der Snapshot vermuten laesst.

So long,
Dirk

ah mist Du warst zu schnell oder ich zu langsam mit der Bearbeitung meines Beitrages, ich habe oben im Beitrag noch auf alle Fragen von Dir geantwortet. Schau es Dir oben nochmal an. Auch die Bilder sind jetzt dran.


... und ja, wegen dem Bosman... das ist für mich momentan die einzige Möglichkeit auf meine Medienserver (Fritzbox etc.) zuzugreifen. Deswegen muss ich bis es eine andere Lösung gibt, die Boxen nach den Tests wieder zu Bosman um-migrieren.

... und die Presets auf die json Files sind eine andere Variante, ohne jeglichen Server (bosman, bosefix, soundcork etc.). Hatte ich im anderen Thread bei meinen Tests erwähnt.

Kurzes Status-Update, damit du nicht im Dunkeln sitzt:

Ich habe heute Nachmittag im Lab mit deiner Konstellation nachgespielt — Bosman-App auf dem iPhone, ein lokaler minidlna als DLNA-Server, einer meiner SoundTouch 10 als Versuchsspeaker. Damit konnte ich das Verhalten reproduzieren:

• Bosman setzt vor dem Speichern eines STORED_MUSIC-Presets ganz spezifisch einen sourceItem-Eintrag beim Speaker an, der die DLNA-Server-UUID als sourceAccount fuehrt und auf "READY" gesetzt ist. Erst dann funktioniert /select.
• Nach Migration zu BoseFix32 ist genau dieser sourceItem-Eintrag weg — der Speaker faellt zurueck auf seinen Default "StoredMusicUserName", der UNAVAILABLE ist. Folge: dein gemerktes DLNA-ContentItem kommt mit "Quelle nicht vorhanden" beim /select-Versuch.
• Mein erster Reparatur-Versuch (STORED_MUSIC + STORED_MUSIC_MEDIA_RENDERER in meinem account/full deklarieren, pro DLNA-Server eine eigene Source) wirkt nicht — der Speaker uebernimmt diese Eintraege aus dem account/full einfach nicht. Bosman scheint also nicht ueber account/full den sourceItem zu setzen, sondern ueber einen aktiven Push direkt zur Speaker-API. Genau diesen Push-Mechanismus muss ich noch finden.

Danke fuer deine Geduld und die Snapshots, das war Gold wert. Melde mich ...

So long,
Dirk

@fred_feuerstein

Erst mal: sorry doppelt.

Erstens: du hast in den letzten Wochen viel Zeit in Tests, Bug-Reports und Logs auf dem BoseFix32-Namen investiert — und jetzt benenne ich das Ding mitten in deinem Testlauf in SixBack um. Hintergrund kein Gimmick: "BoseFix" enthielt die Marke "Bose" wörtlich, und je mehr Sichtbarkeit das Projekt bekommt, desto eher kommt da eine Anwaltspost. Lieber jetzt umbenennen als spaeter unter Druck. SixBack spielt auf die sechs Preset-Tasten an, die wir aus dem Bose-Cloud-Tod zurueckholen — der Fokus bleibt.

Zweitens: aus demselben Umbenennen folgt: dein OTA-Update wird NICHT funktionieren. Deine alte BoseFix32-Firmware fragt beim Online-Update intern noch die alten Dateinamen bosefix32-<chip>-firmware.bin an. Die habe ich heute auf dem Hosting umbenannt zu sixback-<chip>-firmware.bin. Der Online-Update-Klick endet daher in einem 404 und du stehst ohne Update da. Sorry — das ist ein Side-Effect der Rename-Operation, den ich erst zu spaet gesehen habe.

Was du machen musst

Frische USB-Installation via Webflasher. Ist 2 Minuten:

• Browser (Chrome / Edge / Brave — kein Firefox/Safari) auf https://install.busware.de/sixback/
• ESP-Stick per USB an deinen Rechner.
• Knopf "CONNECT" → seriellen Port auswaehlen → "INSTALL".
• Das Tool erase'd den Stick vollstaendig + schreibt die Factory-Image inkl. WebUI + Bootloader.
• Direkt danach kommt der Improv-Wi-Fi-Prompt im selben Browser-Fenster: SSID + Passwort eingeben, der Stick verbindet sich.
• Auto-Mode laeuft 10 s nach Boot los, findet deine Speaker via SSDP, importiert ihre Presets und schreibt die SixBack-Cloud-URL via Telnet rueber. Pro Speaker ~90 s. Bei 8 Speakern also gut Kaffee holen.

Was verloren geht (durch das erase_flash):

• WiFi-Credentials → musst du im Improv-Setup neu eingeben (= einmal pro Stick).
• Auto-Mode-Settings → fallen auf Image-Default zurueck (enabled=true, default-Cron 30 min). Falls du das gezielt aus hattest: WebUI Top-Toggle direkt nach Boot umstellen, bevor die Discovery durchlaeuft.
• Speaker-Inventory + Preset-Store auf dem Stick → wird vom Auto-Mode-Pass aus den Speakern selbst neu importiert. Deine Speaker selbst behalten ihre Presets. Die werden vom Auto-Mode-pre-import-Schritt ausgelesen und in den Stick-Store geschrieben, also kein User-Verlust.

Was BLEIBT: deine Speaker selbst. Die behalten alles. Auch wenn deine alten 8 Speaker derzeit auf einer BoseFix32-Cloud-URL (= alter Stick-IP) standen, kannst du den frisch geflashten Stick einfach am gleichen WLAN am gleichen IP-Bereich laufen lassen — Auto-Mode rewrite'd die Cloud-URLs sauber auf den neuen Stick.

Dein Bug-Report war Gold wert. Das 2-von-8-Speakern-Problem hat den ARP-Race-Pfad sichtbar gemacht und ist im release: v0.7.0-Tag explizit als Dank aufgefuehrt. Bei deinen 8 Speakern hast du eh die brutalste Test-Umgebung von uns allen.

Wenn dir nach dem Reflash was komisch vorkommt — hau direkt rein, hier im Thread oder via Snapshot-Upload aus der WebUI (System → Snapshot an Maintainer schickt mir die Diagnose-Daten verschluesselt rueber).

Nochmal danke fuer die Geduld — und sorry fuer die Namens-Hin-und-Her-Phase plus den OTA-Bruch.

Frohe Pfingsten!

Du, das ist doch alles gar kein Problem. Danke für die sehr ausführliche Beschreibung.

Das auto migrieren schalte ich gleich nach dem booten ab.

Btw.Hab jetzt neun Geräte am Start. 2 davon sind noch komplett original auf bose eingestellt, und haben Presets auf lokalen mediaserver und dessen radiostreams (fritzbox)
Die anderen habe ich schon mehrfach von Bosman auf sixback und wieder auf original gesetzt.

Habe übrigens den Tipp bekommen, eine neu resettete Box ohne vorhandene Quellen per USB/telnet die sources.xml und Presets.xml von einer anderen Box zu geben. Das klappt.
man muss halt einweder temporär über USB oder dauerhaft root aktivieren an der Box.
geht aber alles mit einem USB Stick.

Leider auch noch keine Idee eine sources Quelle per api etc. zu setzen. Keine Ahnung wie das bei Bosman funktioniert.

Sagen wir mal so. Das wichtigste ist ja, dass die Boxen weiter genutzt werden können, vor allem erstmal als Radio. Bei mir über 80 Prozent der Nutzung.

Der Rest wird sich zeigen.

Melde mich, wenn ich den esp32 S3 neu bespielt habe.

Also ESP32 S3 läuft nun mit "sixback" v0.7.619

Auto-Scan hat nur 5 Lautsprecher gefunden, aber manuell konnte ich alle weiteren adden.
Es sind nun alle 9 Bose-Geräte in der Liste.
Teils noch auf Bosman migriert, teils original Bose und teils sixback Migration.

Prima soweit !!
Nun mal sehen wie es weitergeht nach und nach :).
Wenn es noch eine Lösung für die lokalen Medienserver gibt, also das Hinzufügen einer Source und das "halbwegs" komfortable setzen einer Playlist, Webradio etc. von der Fritzbox wäre super, aber kein Muss.
Habe ja eine lokale Lösung mit dem Kopieren der Sources.xml und Presets.xml von einer auf die andere Box per USB.
Ansonsten halt über Bosman.

Top!

Zitat von: fred_feuersteinHabe ja eine lokale Lösung mit dem Kopieren der Sources.xml und Presets.xml von einer auf die andere Box per USB.

Genau dafuer ist seit gestern Abend v0.7.3 live (install.busware.de/sixback/ (https://install.busware.de/sixback/)) — pro Speaker-Kachel gibt's jetzt ein ⬇ Export und ⬆ Import, das alle 6 Preset-Slots als JSON ablaedt bzw. zurueckspielt (DLNA-/STORED_MUSIC-Slots inklusive, der rawContentItem fliegt mit). Damit faellt der USB-XML-Umweg weg.

Was sonst neu ist: pro Slot ein ✕ zum Wegwerfen einer noch nicht gepushten Aenderung, 🔄 Refresh status raeumt jetzt auch alte un-gepushte Drag-Drops auf, und Cross-Speaker-Drop kopiert (statt swap) — Greta verliert ihren Preset nicht mehr wenn du ihn auf Emma ziehst. Screenshot des neuen UI anbei.

Zu deinen 9 Geraeten: dass der LAN-Scan nur 5 sieht und du manuell ergaenzen musstest ist ein bekannter ARP-Race direkt nach ESP-Boot — der Speaker antwortet auf den ersten Probe-Sweep zu langsam. Workaround ist genau was du gemacht hast (manuell adden), Fix dafuer steht noch aus.

DLNA-Browse direkt aus dem Web-UI (Fritzbox-Sources auflisten + Track in einen Slot ziehen) ist die naechste Baustelle. Bose-Speaker selbst kennen dafuer nur /listMediaServers, der eigentliche Container-Browse muesste vom ESP per UPnP-CDS laufen — also Arbeit, kein quick fix. Kein ETA.

Gruss, Dirk

Das sieht doch schonmal ganz gut aus :)

Was mir so noch auffällt. Die Anzeige und Links zu GitHub von der WebUI zeigen alle noch auf ...bosefix32... und das gibt es nicht mehr, bzw. landen die Links auf 404.
(bzw. war es bis gestern so. Habe die neue Version noch nicht drauf ... )

Zitat von: fred_feuerstein am 23 Mai 2026, 16:43:16Was mir so noch auffällt. Die Anzeige und Links zu GitHub von der WebUI zeigen alle noch auf ...bosefix32... und das gibt es nicht mehr, bzw. landen die Links auf 404.
(bzw. war es bis gestern so. Habe die neue Version noch nicht drauf ... )

ich muss noch die Umbenennung auch im Code konsequent zu ende führen ... dann schalte ich es wieder "public"

Update: v0.7.924 ist live

Rename ist durch. Neuer Heimathafen: sixback.io (https://sixback.io/) — Web-Flasher, Doku, Snapshot-Upload, alles dort. GitHub-Repo ist tostmann/SixBack (https://github.com/tostmann/SixBack), die alten bosefix32-Links sind tot.

Was seit v0.7.619 dazukam (nur die User-sichtbaren Sachen):

• Spotify-Library als Sidebar-Tab — wer Premium hat, kann Tracks/Alben/Playlists per Drag&Drop auf einen Preset-Slot ziehen. Hardware-Knopf am Speaker triggert dann den Spotify-Player. Shuffle/Repeat pro Slot. Pairing einmal pro Speaker-Reboot.
• Stream-Tab mit D&D — eigene Radio-URLs als Kacheln, draggen auf Slots. Geht via TUNEIN-Tunnel (Bose-LIR-Pfad ist defekt). Hinweis im UI: HTTP-Streams laufen besser als HTTPS (Bose-Cert-Pinning auf alter FW).
• Push-Reliability — Verify-Retry mit Polling, slotsMatch ignoriert Name bei Tunnel-IDs. "Push Slot" failed nicht mehr sporadisch.
• NVS-Schutz — 3-pass Cleanup bei voller Partition. Der "Preset-revert nach Reboot"-Bug ist endgueltig weg.
• Auto-Migrate per default an — fresh-flashed Stick + Provision = uebernimmt alle erreichbaren Speaker zero-touch.
• Zwei Sticks im selben LAN — peer-aware Auto-Mode. Keiner klaut dem anderen Speaker. Macht's einfacher wenn man S3 und C6 parallel laufen hat.
• C3/C6-Builds — funktionieren jetzt (APP_CPU_NUM-Single-Core-Fix). Mehr ESP-Varianten verwendbar.
• S3-TLS-Stabilitaet — PSRAM-mbedtls-Hook. HTTPS-Calls (Spotify, OTA-Check) brechen nicht mehr nach Stunden ein.

Was nicht neu ist: DLNA-Browse im WebUI steht weiter auf der Liste, kein ETA. Amazon ebenfalls nein. Spotify-Premium-only — Free-Accounts koennen Bose nicht remote-steuern (Spotify-API-Limit, nicht unser Problem).

Update-Pfad:

• S3 mit OTA-Partition: "Install Update" im WebUI klicken, zieht direkt von sixback.io.
• C3/C6 ohne OTA: Web-Serial-Updater auf sixback.io (https://sixback.io/) — Chrome/Edge + USB, NVS bleibt erhalten (Update-Manifest, nicht Fresh-Install).

Snapshot-Button bleibt der einfachste Weg fuer "X funktioniert nicht" — kein Account, kein Mail, ein Klick.

So long,
Dirk

Hallo Dirk,

Update erfolgreich :)

Habe gerade mal mit einem Lautsprecher Spotify getestet. Das klappt soweit. Konnte eine Playlist testweise erfolgreich in die Library einfügen und dann sowohl per Drag/Drop oder Long-Press auf eine Preset-Taste entsprechend auf der Box speichern.
Hier ist auch interessant, dass man diese "laufende" Spotify Playlist/Song/Album dann in fhem wieder auf die Speicher 7 - 20 speichern kann. Auch das funktioniert prima.
Dann diese Box mal rebootet. In SixBack musste ich nichts machen. Nur in der Spotify App kam eine Meldung, ob der Lautsprecher wieder verbunden werden soll (oder so ähnlich). Die Speicher waren noch belegt und auch der test-Channel Nr. 7 in fhem konnte einfach wieder abgespielt werden.
Das genaue Handling etc. muss ich mir nochmal genauer anschauen. Aber es funktioniert erstmal ! Super.

Ansonsten das generelle Handling im WebIf von SixBack. Hier und da kommen als Einblendung rechts unten in rot Fehlermeldungen (diverse, bsp beim Setzen eines Presets: "Set failed: NVS save failed (partition full/fragmented) — try POST /api/nvs/cleanup"). Meist muss man mal entweder die komplette Seite aktualisieren oder oben auf Refresh Status gehen. Teilweise kommt es vor, dass man nach Drag/Drop bspw. eines Radiosenders das Ergebnis nicht direkt auf der Speichertaste sieht (also diese Ansicht: alt / neu, wo man dann pushen kann). Auch hier muss man manchmal einfach mal einen Reload der Seite oder Refresh-Status machen.

Andere Dingen funktionieren denke ich soweit.

Hier noch ein paar Fragen:
Nochmal wegen DLNA. Klar, über die Leiste Links kann man noch nicht Browsen. Soweit verstanden, auch dass das ein separates Projekt wird. Aber Du meintest, man könnte das manuell irgendwie machen:
- wie kann ich bei einer "neuen" Box, wo die STORAGE_MUSIC noch fehlt, die Quelle setzen? (ich mache das aktuell über das Einspielen der Sources.xml einer eingerichtete Box über USB)
- Wie kann ich über SixBack aktuell eine Audioquelle (mp3 oder Internetradio etc.) vom Medienserver als Preset setzen? Oder geht das noch gar nicht (also er zeigt gespeicherte Presets von einer Box an, kann aber noch gar keine selbst setzen).


Aktuell teste ich von meinen 9 Geräten mit 2 Boxen das SixBack Handling (migriert). Wenn ich das mit dem Setzen von DLNA Inhalten noch irgendwie hinbekomme, dann kann ich eigentlich komplett alle Lautsprecher auf SixBack migrieren.
Aber kann es sein, dass man anfangs die Lautsprecher wieder auf "original" zurücksetzen konnte und das aktuell in SixBack nicht mehr per "Knopf" geht?

Hallo Fred,

danke fürs ausführliche Testen — dass auf deiner Hardware Spotify-Library inkl. Drag&Drop + Long-Press + fhem-Speicher 7-20 + Reboot-Persistenz funktioniert, ist die Cross-Validation der v0.7.7→v0.7.924-Kette, die mir gefehlt hat. Ich hatte nur auf meinem S3 verifiziert.

Zu deinen Bug-Berichten habe ich Issues angelegt, beide mit vorgezogener Code-Analyse:

• Rote Toasts unten rechts → #1 (https://github.com/tostmann/SixBack/issues/1): der Toast-Helper im WebUI hat keinen Dedup, jeder neue Fehler überschreibt den vorherigen ohne Filter. 5 Quellen identifiziert (Status-Polling, NowPlaying, Spotify-Trigger, Verify-Retries, D&D-kickPoll). Fix: Dedup-Window + die "manchmal-erwartete"-Pfade als 'warn' statt 'error' klassifizieren.
• D&D "alt/neu"-View fehlt sporadisch → #2 (https://github.com/tostmann/SixBack/issues/2): silent-catch der bei kurzfristigem 502 (Speaker gerade busy) die Slots als "alle leer" rendert statt den alten Zustand zu behalten. Fix: 502 erkennen + Drop-Inhalt lokal optimistisch rendern, ohne auf den Server-GET zu warten.

"Auf Original zurücksetzen"-Knopf ist bewusst entfernt. Die alte Bedeutung war "envswitch boseurls zurück zur Bose-Cloud setzen" — da die Cloud seit 2026-05-06 tot ist, würde der Knopf den Speaker nur gegen tote Endpoints schicken. Sinnvolle Variante: #3 (https://github.com/tostmann/SixBack/issues/3) Restore aus Pre-Migration-Snapshot. SixBack speichert pro Speaker beim allerersten Migrate ohnehin ein vollständiges Abbild (Presets + Sources + Cloud-Config) lokal im ESP. Damit lässt sich per Knopf der Stand vor dem ersten SixBack-Eingriff wiederherstellen, falls man sich Slots versehentlich überschrieben hat.

DLNA schauen wir uns an. Das sind zwei separate Probleme — (a) STORED_MUSIC-Quelle auf einer neuen Box ohne USB-sources.xml registrieren, und (b) UPnP-Server in der SixBack-UI browsen + Track als Preset hinterlegen. Ich kläre die technischen Risiken und melde mich mit einer realistischen Aufwands-Schätzung. Für ein Versprechen ist es momentan zu früh.

Wo Diskussion weiterläuft: SixBack ist seit kurzem public auf github.com/tostmann/SixBack (https://github.com/tostmann/SixBack) — Issues für strukturierte Bug-Reports + Feature-Wünsche, Discussions als Q&A. FHEM-Forum bleibt aktiv für Release-Ankündigungen und allgemeine Diskussion (wer keinen GitHub-Account hat).

Gruß, Dirk

SixBack v0.8.0 — DLNA-Browse landet

Hi Fred,

gerade rausgegangen: in der WebUI gibt es jetzt einen eigenen DLNA-Tab. Speaker auswählen, dann den DLNA-Server (alles was der Bose über /listMediaServers meldet — MiniDLNA, Twonky, Fritz!Mediaserver...), durch die Ordner klicken und Track oder Container per Drag&Drop auf einen Preset-Slot ziehen. Der ESP schaltet im Hintergrund die Quelle um, hält den Slot-Knopf "gedrückt" und liest das OPAQUE-ContentItem zurück in den Store.

Webflasher wie immer:  https://sixback.io/  (manifest.json v0.8.0, gebaut für S3 + C3 + C6 // ESP32-classic ist leider zu klein)

Bonus oben drauf: Migrate und Reboot haben jetzt einen Schritt-für-Schritt-Fortschrittsdialog statt nur einem Toast, mit Status-Polling und sauberem Timeout-Hinweis falls der Bose mal nicht zurückkommt.

Wichtige Einschränkung: das hilft Speakern die den DLNA-Server bereits kennen. Für Boxen die "STORED_MUSIC" noch nie registriert hatten, ist das Bootstrap-Problem noch nicht gelöst — das ist Phase (a) und steht für eine der nächsten Versionen an. Wenn du eine Box hast wo DLNA grundsätzlich schon spielt, probier es bitte aus und schreib was rauskommt — besonders ob das Drag-on-Slot bei deinem Setup (Twonky, Synology, NAS, was-auch-immer) durchgeht.

Issues + Code: https://github.com/tostmann/SixBack/releases/tag/v0.8.0

Danke für die Version. Hatte OTA Update gestartet, aber es lief nur bis zu ca. 30 Prozent. Dann brach es ab. Ein Seitenreload hat den ESP32 S3 dann nicht mehr erreicht. Reboot etc. hat nichts geändert.
Flash über sixback.io => hier erst das "Update" probiert. Das lief durch, aber der ESP32 war danach immer noch nicht erreichbar. Manuelles Update einzelner Bereiche habe ich nicht versucht. Dann also die Fresh-Installation incl. Erase. Das hat funktioniert. Musste nur Spotify neu connecten. Der Rest, also meine 9 Bose Devices waren beim ersten Start direkt da und ich habe nur die Auto Migration gleich abgebrochen. Das möchte ich aktuell ja noch nicht ;)

Was das für ein Problem war kann ich nicht sagen. Hatte bei den vorherigen OTA Updates problemlos funktioniert.

Wegen DLNA Problem habe ich im Github ein ISSUE angelegt.

Und jetzt hab ich noch ein passendes Gehäuse für den sixback esp32 s3:

Kurzes Update: SixBack v0.8.1 ist raus.

Zwei gemeldete Punkte sind behoben:

• Bootloop auf dem ESP32-C3 — läuft jetzt sauber.
• DLNA-Browser zeigt jetzt direkt eure Mediaserver an, ohne Umweg über eine externe Adresse.

Außerdem lassen sich C3 und C6 wieder per OTA aktualisieren. Einmalig müssen die beiden über https://sixback.io/ (https://sixback.io/) neu geflasht werden (Partitions-Umstellung), danach kommen Updates wieder over-the-air.

Die "kleinen Dinger" sind hart an ihrem Limit ...

Rückmeldungen wie immer gern!

Update von 0.8.0 auf 0.8.1 auf dem ESP32 S3 schlägt bei mir fehl.

- Check for Update
- es wird Update available 0.8.1 angezeigt
- Install Update => mit Bestätigungsfenster
- dann kommt rote Meldung rechts unten, siehe Screenshot:

Ursache gefunden, @fred_feuerstein. Der S3 hat eine große LittleFS-Partition, daher lädt das Online-Update beim S3 ein rund 10 MB großes Web-UI-Image über HTTPS — bei C3/C6 sind es nur ~256 KB, deshalb tritt das dort nicht auf.

Der OTA-Client in 0.8.0 bricht ab, wenn beim Download länger als 5 Sekunden keine Daten ankommen. Stockt dein WLAN während des großen S3-Downloads also kurz, hält der Client das fälschlich für das Stream-Ende und bricht zur Sicherheit ab (kein Brick — das Gerät bleibt heil auf 0.8.0), und genau das erzeugt die rote Fehlermeldung. Auf einer stabilen Verbindung läuft derselbe Download komplett durch (hier reproduziert: volle ~10 MB plus Firmware in ca. 60 Sekunden).

In 0.8.1 ist das behoben (Idle-Timeout von 5 auf 30 Sekunden erhöht plus zusätzliche Content-Length-Prüfung) — nur kommt dein 0.8.0-Client per Online-Update evtl. nicht zuverlässig dorthin (Henne-Ei-Problem).

Verlässlicher Weg auf die aktuelle Version 0.8.2 — ohne USB, ohne Verlust deiner Einstellungen:

Lade die beiden Dateien herunter (jetzt auch direkt in den ,,Supported targets"-Kacheln auf sixback.io (https://sixback.io/) verlinkt):

• sixback-s3-firmware.bin (https://sixback.io/sixback-s3-firmware.bin)
• sixback-s3-littlefs.bin (https://sixback.io/sixback-s3-littlefs.bin)

Dann in der Geräte-WebUI unter Firmware update → Manual upload: das App-Image (firmware.bin) über Flash app, das Web-UI-Image (littlefs.bin) über Flash web UI. Das schiebt die Images direkt aus deinem Browser über das lokale Netz ins Gerät — kein stockanfälliger HTTPS-Pull — und NVS/Presets bleiben unangetastet.

Alternativ kannst du das Online-Update einfach nochmal probieren; auf einer ruhigen Leitung läuft es meist sofort durch. Mit 0.8.2 ist das Online-Update dann dauerhaft robust.

Ich werde die manuellen Updates wie von dir beschrieben probieren.

Aber das Problem vom Update war in dem Fall nicht eine schlechte wifi oder Internet Verbindung, denn die rote Fehlermeldung kommt sofort nach Klick auf Update.
er versucht es aktuell gar nicht erst.

(Mein esp32 S3 steht neben der fritzbox, hat also ausreichend wifi, würde ich vermuten)

Gebe dann Rückmeldung.

=> habe es nochmal OTA versucht => gleicher Fehler beim Versuch auf 0.8.3 => Der Fehler kommt direkt nach Klick auf Update.
=> dann Versuch manuell mit den von Dir verlinkten Dateien => App Firmware konnte aktualisiert werden. => Web UI (...littlefs.bin) kommt direkt nach Klick auf Flash web UI wieder ein roter Fehler rechts unten. Siehe angehängter Screen.
kann es sein, dass bei der 0.8.0 die Partition zu klein erstellt wurde, statt 10MB nur 1MB? So würde ich die Fehlermeldung interpretieren.

Denke, ich werde wohl nochmal von vorne über USB anfangen müssen mit Erase...

Edit: bin nun auf 0.8.3, nach USB Update mit Erase.

- DLNA Browser funktioniert :)
- Übersicht der Lautsprecher super mit den ausklappbaren Presets :)


und wie immer noch eine Frage: Auf der WebUI aber auch unter sixback.io gibt es keinen Link zur sixback github Seite, oder? Fände ich ganz gut, dann könnte man gerade aktuell direkt mal zu Github wechseln und nachschauen was es Neues gibt. Vielleicht auch als Link unten in der Fusszeile?! (nur als Anregung ;) )

Hi Fred,

danke für den Screenshot — der zeigt's exakt, und dein Verdacht war fast richtig, nur an der falschen Stelle:

Die Meldung ,,file is too big (9.88 MB, max 1.00 MB)" kam von einem Größen-Limit in der WebUI selbst, nicht von der Flash-Partition. Der manuelle ,,Flash web UI"-Upload hatte noch ein altes 1-MB-Limit drin (Relikt aus der Zeit, als das Web-UI-Image winzig war). Das S3-Web-UI-Image ist inzwischen ~9,9 MB groß — und genau das hat der Check sofort abgelehnt, bevor überhaupt etwas geschrieben wurde. Die LittleFS-Partition auf dem S3 ist ~10 MB, also völlig ausreichend; die ,,1 MB" aus der Meldung war nur das (falsch gesetzte) Upload-Limit.

In v0.8.4 ist das Limit angehoben — der manuelle ,,Flash web UI" funktioniert dann mit dem großen S3-Image. Ich hab das auf einem S3-Testgerät einmal komplett durchgespielt: ~9,9-MB-Image manuell hochgeladen → sauber geschrieben (~80 s) → Reboot → UI intakt.

Zum Online-Update, das ,,gar nicht erst losläuft": das war der Updater-Stand der 0.8.0 selbst (der Install-Button hing am gecachten Prüf-Status). Ab 0.8.3 behoben — aber ein 0.8.0-Gerät kann sich diesen Fix nicht selbst per OTA holen, daher war dein einmaliger USB-Weg mit Erase genau richtig. Jetzt, wo du auf 0.8.3 bist, läuft das Online-Update künftig normal durch.

Deine Anregung mit dem GitHub-Link: ist drin — Footer-Link zur Projektseite in der WebUI und auf sixback.io, ebenfalls ab v0.8.4.

Schön, dass DLNA-Browser und die ausklappbare Übersicht bei dir laufen!

Gruß

Was mir so generell aufgefallen ist:

Handling klappt insgesamt recht gut. Nur nach einem Fresh-Install bei der vielzahl an Bose Devices bei mir, da hakt es recht schnell an verschiedenen Stellen. Auch wurden nicht alle Presets, vor allem die auf DLNA Quelle (obwohl verfügbar) korrekt angezeigt und waren auch nicht mehr abspielbar.
Ein DLNA Drag/Drop auf einen Preset hat vermeintlich funktioniert, aber am Lautsprecher ging es dann trotzdem nicht.
Habe in diesen Fällen dann über die Bose-App die Playlist vom DLNA gestartet und dann manuell am Bose Gerät die Speichertaste gedrückt. Dann ging es wieder.

Nun ändert man ja nicht laufend alles neu. Von daher ist das Handling auch wieder ok.

Also soweit alles prima. Momentan.

- DLNA funktioniert
- Spotify funktioniert
- Webradio ohnehin...

Jetzt erstmal wieder ein bisschen Musik hören :D


Ach so: Update auf 0.8.4 hat wieder OTA funktioniert.
Aber danach waren meine 9 Lautsprecher nicht mehr da. Der Scan, der vorher seit Tagen immer alle 9 gefunden hat, findet aktuell keinen einzigen Lautsprecher mehr.
OK. Ich lass den sixback nun mal ein bisschen laufen. Vielleicht findet er später wieder was. (wollte jetzt nicht 9 mal manuell hinzufügen...)

Zitat von: fred_feuersteinUpdate auf 0.8.4 hat wieder OTA funktioniert. Aber danach waren meine 9 Lautsprecher nicht mehr da. Der Scan, der vorher seit Tagen immer alle 9 gefunden hat, findet aktuell keinen einzigen Lautsprecher mehr.

Danke für die ausführliche Rückmeldung — und schön zu lesen, dass DLNA, Spotify und Webradio bei dir soweit laufen. Den Workaround (in der Bose-App vom DLNA starten und dann am Gerät die Speichertaste drücken) kenne ich; den DLNA-Push direkt aus SixBack sauber hinzubekommen ist noch eine eigene Baustelle, da bleibe ich dran.

Zur verschwundenen Erkennung nach dem Update: ich habe den kompletten Diff von 0.8.0 auf 0.8.4 durchgesehen, gezielt auf den Discovery-Pfad. Am Scan selbst (SSDP/M-SEARCH und der Scan-Handler) wurde nichts geändert — der Umbau in diesem Sprung betraf nur das HTTP-Routing (ich habe die Regex-Engine rausgeworfen, weil sie auf den kleinen C3/C6 den Speicher sprengt und Bootloops auslöst) sowie die Partitionierung. Es gibt also keine bewusste Änderung, die die Lautsprecher-Suche lahmlegen würde.

Mein Verdacht ist deshalb ein vorübergehender Zustand direkt nach dem OTA-Neustart: dass der Multicast-/IGMP-Beitritt nach dem Reboot nicht sauber zustande kommt und die M-SEARCH-Antworten der Boxen schlicht nicht ankommen. Das würde dazu passen, dass vorher tagelang alle 9 zuverlässig gefunden wurden und sich an der Suche im Code nichts geändert hat.

Damit ich das messen statt raten kann, zwei kurze Sachen:

• Mach den Stick einmal richtig stromlos (Netzteil ziehen, ~10 s warten, wieder einstecken — nicht nur den Reset-Knopf) und starte danach den Scan neu. Kommen die 9 dann wieder? Falls ja, war es genau dieser Zustand nach dem OTA-Reboot.
• Falls du ohnehin seriell drankommst (115200 Baud): schick mir beim Scan die Zeilen ab [inv][ssdp] M-SEARCH burst sent, listening 4s .... Wenn diese Zeile erscheint, aber danach keine Treffer-Zeilen folgen, ist eindeutig die Multicast-Antwort das Problem und nicht der Code.

Wenn sich das bestätigt, ist die naheliegende Gegenmaßnahme ein erneuter Multicast-Join bzw. ein automatischer Scan-Retry kurz nach dem WiFi-Connect — das baue ich aber erst ein, wenn die Logs es zeigen, nicht auf Verdacht. Die 9 Boxen manuell neu anzulegen ersparst du dir damit hoffentlich.

Gruß, Dirk

Also auch nach längerem Strom abziehen und wieder einstecken hat es nicht funktioniert.
Teilweise nach dem Scan Versuch war der ESP gar nicht mehr erreichbar per Web.

Dann hier also mal ein Log nach dem Klick auf Scan:
[15:42:08][inv] discovery starting (sync phase)
[15:42:08][inv][ssdp] M-SEARCH burst sent, listening 4s ...
[15:42:08]Guru Meditation Error: Core  0 panic'ed (Unhandled debug exception).
[15:42:08]Debug exception reason: Stack canary watchpoint triggered (bg-discover)
[15:42:08]Core  0 register dump:
[15:42:08]PC      : 0x4037ea3a  PS      : 0x00060236  A0      : 0x80383324  A1      : 0x3fcca2e0 
[15:42:08]A2      : 0x3fcea3c4  A3      : 0xffffffff  A4      : 0xb33fffff  A5      : 0x403775ec 
[15:42:08]A6      : 0x00000001  A7      : 0x00000024  A8      : 0x00060223  A9      : 0x3fcca2e0 
[15:42:08]A10     : 0x00060223  A11     : 0x00000003  A12     : 0x00060223  A13     : 0x00060423 
[15:42:08]A14     : 0x0000003c  A15     : 0x0000cdcd  SAR     : 0x00000018  EXCCAUSE: 0x00000001 
[15:42:08]EXCVADDR: 0x00000000  LBEG    : 0x40056f5c  LEND    : 0x40056f72  LCOUNT  : 0xffffffff 
[15:42:08]
[15:42:08]
[15:42:08]Backtrace: 0x4037ea37:0x3fcca2e0 0x40383321:0x3fcca310 0x40383356:0x3fcca330 0x403834c0:0x3fcca350 0x403765b3:0x3fcca370 0x403765cd:0x3fcca3a0 0x40376749:0x3fcca3c0 0x403775f8:0x3fcca3e0 0x421147c2:0x3fcca400 0x421176c5:0x3fcca430 0x400398b5:0x3fcca460 0x42113d91:0x3fcca480 0x42113ef5:0x3fcca4b0 0x420cb1a9:0x3fcca4f0 0x4209bf3e:0x3fcca510 0x4208d752:0x3fcca530 0x420ade32:0x3fcca560 0x42085d15:0x3fcca580 0x4207dcca:0x3fcca5a0 0x4207e0b5:0x3fcca5d0 0x4207e20f:0x3fcca600 0x4207e426:0x3fcca630 0x4207f31d:0x3fcca660 0x4207f359:0x3fcca6a0 0x4207f37f:0x3fcca6d0 0x4207b52d:0x3fcca700 0x42077a19:0x3fcca740 0x42088b7f:0x3fcca770 0x420741b8:0x3fcca790 0x4208774f:0x3fcca7b0 0x42087903:0x3fcca7d0 0x42072de9:0x3fcca820 0x4200723b:0x3fcca860 0x4200674a:0x3fcca8d0 0x4200c1b9:0x3fcca930 0x4200dfca:0x3fcca960 0x4200e2a7:0x3fcca9c0 0x4204f4a6:0x3fcca9e0 0x42052006:0x3fccab70 0x420529f8:0x3fccb100 0x4201b37e:0x3fccb140 0x4037e935:0x3fccb160
[15:42:08]
[15:42:08]
[15:42:08]
[15:42:08]
[15:42:08]ELF file SHA256: 7327ee12e
[15:42:08]
[15:42:09]Rebooting...
[15:42:09]ESP-ROM:esp32s3-20210327
[15:42:09]Build:Mar 27 2021
[15:42:09]rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
[15:42:09]Saved PC:0x4037dc61
[15:42:09]SPIWP:0xee
[15:42:09]mode:DIO, clock div:1
[15:42:09]load:0x3fce2820,len:0x10cc
[15:42:09]load:0x403c8700,len:0xc2c
[15:42:09]load:0x403cb700,len:0x30c0
[15:42:09]entry 0x403c88b8
[15:42:09]
[15:42:09]=========================================
[15:42:09]  SixBack 0.8.4
[15:42:09]  Build: 2026-05-29 11:19:39
[15:42:09]  Copyright (c) 2026 Dirk Tostmann
[15:42:09]  License: PolyForm Noncommercial 1.0.0
[15:42:09]  Commercial use prohibited — see LICENSE
[15:42:09]=========================================
[15:42:09][mbedtls] PSRAM allocator installed (threshold=512, psram_free=8188 KB)
[15:42:09][fs]   LittleFS mounted, 176128/10354688 bytes used
[15:42:09][   590][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
[15:42:09][improv] starting (idle-window 30s, NVS-creds present)
[15:42:10][wifi] NVS credentials present, trying ssid=hannebambel HOME
[15:42:11][wifi] connected, IP=192.168.123.173
[15:42:11][wifi] PS=NONE TX=max CPU=240 MHz — optimized for reliability
[15:42:11][improv] reset window after AP connect — improvLastActivityMs=2385 improvActive=1
[15:42:11][wifi] up, IP=192.168.123.173 MAC=1C:DB:D4:74:9F:44 RSSI=-73
[15:42:11][mdns] sixback.local advertised
[15:42:11][  2398][E][Preferences.cpp:506] getString(): nvs_get_str len fail: speakers NOT_FOUND
[15:42:11][inv] no NVS-state, starting fresh
[15:42:11][  2417][E][Preferences.cpp:506] getString(): nvs_get_str len fail: presets NOT_FOUND
[15:42:11][inv]  0 known speakers, presets loaded
[15:42:11][failsafe] IP unchanged (192.168.123.173) — nothing to do
[15:42:11][  2428][E][Preferences.cpp:506] getString(): nvs_get_str len fail: slots NOT_FOUND
[15:42:11][spot] no NVS slot-map, start empty
[15:42:11][  2444][E][Preferences.cpp:506] getString(): nvs_get_str len fail: library NOT_FOUND
[15:42:11][spot] no NVS library, start empty
[15:42:11][spot/worker] running
[15:42:11][spot] init done — preset-pressed callback registered, TLS-clients ready, worker spawned
[15:42:11][bose] cloud-replacement listening on :8000
[15:42:11][bose] tell speakers to use: http://192.168.123.173:8000
[15:42:11][ui]   web/api listening on http://192.168.123.173:80/
[15:42:11][ui]   mDNS: http://sixback.local/
[15:42:11][health] boot #12  last-reset=PANIC  crashes-lifetime=7  wifi-reboots=0  heap-reboots=0
[15:42:11][health] task-wdt subscribed=1 (timeout=30s)
[15:42:11][auto] startup  enabled=0  bootDelayMs=10000  dryRun=0  maxPerBoot=4  cronIntervalS=1800
[15:42:11][auto] disabled at boot — task stays alive but idle (re-enable + reboot or wait for cron tick reload)
[15:42:11]
[15:42:11][setup] SixBack ready - UI: http://sixback.local/
[15:42:11][setup] Trigger speaker discovery: curl -X POST http://sixback.local/api/speakers/discover
[15:42:16][  7390][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
Habe jetzt die 9 Boxen manuell hinzugefügt. Das hat fehlerfrei funktioniert. Keine Ahnung warum der Scan gar nichts gefunden hat.

Als Idee: Bei Bosman und opensoundcloud kann man IP-Adressen von lautsprechern speichern, die bei Bedarf (wenn nicht automatisch per scan gefunden) dann "automatisch" manuell vom System hinzugefügt werden.
Vielleicht könnte man hier auch so eine IP-Liste pflegen.

Denn ich musste eben nochmal den Stecker ziehen und nach Start sind erneut keinerlei Lautsprecher zu sehen....

Danke fürs serielle Log — das war genau der fehlende Baustein, und es war kein Multicast-Problem, wie ich zuerst vermutet hatte. Der entscheidende Hinweis steht ganz oben in Deinem Dump:

Debug exception reason: Stack canary watchpoint triggered (bg-discover)
Der Name in der Klammer ist der Task, der den Scan im Hintergrund fährt. Heißt: der Discovery-Task ist seinen Stack übergelaufen und das Gerät hat sich mitten im Scan neu gestartet. Danach ist das Speaker-Inventar leer — daher ,,findet 0 von 9", während das manuelle Hinzufügen (ein komplett anderer Code-Pfad) weiterhin geklappt hat. Das passt exakt zu dem, was Du beschrieben hast.

Was das Log sonst noch zeigt, die Zeilen mit
Preferences.cpp ... nvs_open failed: NOT_FOUND, ist übrigens harmlos — das ist nur der normale ,,diesen NVS-Namespace gibt es noch nicht"-Hinweis direkt nach einem frischen Flash, kein Defekt.

Warum es Dich trifft und die kleinen Testaufbauten nicht: je mehr Speaker auf den SSDP-Burst antworten, desto tiefer wird der Aufrufstapel im Scan — bei 9 Geräten reicht das, um den Stack zu sprengen, bei 2-3 nicht.

Gefixt in v0.8.5: der Discovery-Task sammelt die SSDP-Antworten jetzt erst ein und probt die Speaker danach (vorher mitten in der Empfangsschleife, mit dem 1-KB-Empfangspuffer noch auf dem Stack), und der Task-Stack wurde verdoppelt. Auf S3, C6 und C3 läuft der Scan damit sauber durch und findet alle Speaker.

v0.8.5 ist bereits online. Du kannst direkt per OTA aktualisieren — kein USB nötig, keine Partitions-Änderung. Nach dem Update sollte der Scan Deine 9 wieder von allein finden, ohne manuelles Nachtragen. Falls bei Dir mit 9 Geräten wider Erwarten doch noch etwas hakt, schick nochmal ein kurzes serielles Log oder klick den Snapshot-Button, dann schaue ich weiter — ich konnte den Fix hier nur bis 3 Speaker gegentesten, das Überlauf-Verhalten selbst ist aber raus.

Noch mit drin in v0.8.5 (das war GitHub #8): Deine selbst angelegten Stream-Kacheln liegen jetzt im Gerät (NVS) statt nur im Browser — sie überstehen also einen USB-Erase und einen Browserwechsel, inklusive Export/Import.

Grüße!

Nach Update auf die 0.8.5 waren alle Lautsprecher sofort da! Scheint also funktioniert zu haben :)
Und die Import/Export Funktion bei dem Direkt-Streams und der erstmalige Import der Browser-Streams hat funktioniert.

Hatte im Issue zu den "Verbessungen bei vielen Lautsprechern" noch ergänzt als Comment, ob es möglich wäre, die Sortierung der Speaker zu ändern. Beispielsweise man pickt einen Speaker und schiebt ihn hoch oder runter.

Solange das mit dem Finden der Lautsprecher wieder gut funktioniert, braucht man denke ich auch keine anzulegende IP-Listen-Möglichkeit, die dann vom sixback nach und nach geadded wird. Schauen wir also mal wie es sich weiter verhält.


Ich muss das mit DLNA die Tage noch mal genauer testen. Hatte jetzt schon Fälle, da konnten Kacheln von meinem Standard-DLNA (Fritzbox), obwohl es eine alte Box war mit eingerichtetem STORAGE_MUSIC für die Fritzbox, dann nicht richtig gespeichert und abgespielt werden.

Habe meine Backup Box, die noch keinen festen Platz hat, mal neben meinen Arbeitsplatz geholt, da kann ich nebenbei immer mal was probieren.

Wenn mir was auffällt, notiere ich es mal auf meinem virtuellen Zettel.


Weisst Du eigentlich wieviele User sixback nutzen? Würde mich mal interessieren, weil ja sonst kaum Rückmeldungen kommen. Weder hier noch bei Github, oder? :)

Habe gerade noch die Version 0.8.6 installiert.

Neu: die bose Devices können sortiert werden (per drag/drop in der Übersicht)

Klasse!

Vielen Dank.

Kleiner Dank an dieser Stelle an fred_feuerstein: Dein ausführliches Testen und die seriellen Logs — gerade der Discovery-Crash-Dump — haben in den letzten Tagen gleich mehrere Macken aufgedeckt, die dadurch schnell gefixt werden konnten (Discovery-Stack, device-seitige Streams, Speaker-Sortierung). Sehr wertvolles Feedback!

Und weil's gerade passt (kleiner Cross-Post, hihi): SixBack hat's auf Hackaday geschafft — Bring Back Your Bose With An ESP32 (https://hackaday.com/2026/05/28/bring-back-your-bose-with-an-esp32/).

SixBack v0.8.8 ist raus — drei Fixes, alle per OTA aus jeder 0.8.x-Version einspielbar.

Quellen-Selbstheilung (der wichtigste): Manche Speaker waren zwar ,,migriert", hatten aber nie eine Account-Bindung bekommen (leere margeAccountUUID). Dadurch waren am Speaker gar keine SixBack-Quellen registriert, und jeder Preset-Push scheiterte mit /select=500 — TuneIn / Spotify / Stream meldeten alle ,,unknown source". v0.8.8 erkennt das beim periodischen Status-Check und bindet den Speaker automatisch neu, die Quellen registrieren sich wieder — ohne dass man etwas tun muss. Zusätzlich gibt es in der WebUI einen ,,Re-Sync Sources"-Button und einen Warnhinweis, falls ein Speaker in diesem Zustand steckt.

Captive-Portal: Der WLAN-Einrichtungs-Hotspot lief in einen Redirect-Loop (ERR_TOO_MANY_REDIRECTS) — behoben, die Setup-Seite lädt wieder sauber.

Push-Zuverlässigkeit: Der Preset-Push wartet jetzt, bis der Sender am Speaker tatsächlich spielt, bevor er den Long-Press auslöst (statt fester 8 s). Auf langsameren Verbindungen ging vorher gelegentlich der Preset verloren.

Einspielen: in der WebUI unter Firmware update → Install (notfalls Force re-install), oder frisch flashen über sixback.io (https://sixback.io/).
Release-Notes: github.com/tostmann/SixBack/releases/tag/v0.8.8 (https://github.com/tostmann/SixBack/releases/tag/v0.8.8)

Heute habe ich das auch endlich ausprobiert, ich habe ja genug "Reserve-Boxen" hier stehen.
Das hat alles auf Anhieb funktioniert - RESPEKT für diese tolle Lösung!

Könnte man das Ganze auch auf einem ESP32 C5 (https://amzn.eu/d/02uvZ4su) betreiben, der auch 5GHz WLAN beherrscht?

Hintergrund meiner Frage: meine Bose Boxen laufen alle auf 5 GHz.

Alles was hier nur 2,4GHz "kann", ist in ein eigenes WLAN ausgelagert (Shelly etc). Ungern möchte ich aber meine Bose Boxen auf 2,4GHz umstellen.

Nun habe ich versucht, die vorhandenen Boxen von soundcork auf sixback zu migrieren.
Das hat scheinbar auch ein bisschen funktioniert, aber ich kann die Presets nicht belegen.

Was will mir diese Meldung sagen?

Bildschirmfoto 2026-06-04 um 21.27.14.png

Aktuell funktioniert hier nur noch einer meiner vorhandenen Lautsprecher.

Insgesamt habe ich 11, aber im Moment nur 4 in Benutzung.
Wenn es also irgendwann um Lasttest geht, einfach melden :)

Danke fürs Ausprobieren — und die gute Nachricht zuerst: dass bei Dir schon ein Speaker läuft, heißt, an Netz und Migration liegt es nicht. Die Meldung auf Deinem Screenshot ist etwas ganz anderes.

"NVS save failed (partition full/fragmented)" kommt vom Speicher auf dem ESP, in dem SixBack seine Einstellungen ablegt — das NVS ist ein kleiner Schlüssel-Wert-Bereich im Flash (~20 KB). Pro migriertem Speaker landen dort Inventar- und Preset-Daten, und bei 11 Speakern ist der Platz schlicht aufgebraucht. Genau deshalb läuft bei Dir nur ein Teil: die ersten Belegungen passten noch rein, dann war voll. Mit soundcork oder der Migration hat das nichts zu tun.

Den in der Meldung vorgeschlagenen Aufräum-Aufruf (/api/nvs/cleanup) kannst Du Dir sparen — die Firmware räumt vor dem Speichern bereits automatisch auf, und in Deinem Fall ist es kein wegräumbarer Cache, sondern echte Speaker-Daten. Der manuelle Aufruf macht also nichts, was nicht ohnehin schon versucht wurde.

Was jetzt hilft: Du hast 11 Geräte migriert, nutzt aber nur 4. Entferne die nicht genutzten in der Geräteliste der WebUI (oder per API):

curl -X DELETE http://<sixback-ip>/api/speakers/<deviceId>
Damit wird Platz frei und die Presets der aktiven Geräte lassen sich wieder belegen.

Wenn Du magst, schick mir kurz die Ausgabe von:

curl http://<sixback-ip>/api/nvs/stats
Der Wert "percent_used" bestätigt die Diagnose.

Der eigentliche Fix ist schon auf meiner Liste: Ich hebe das Limit an — die großen Speaker-Daten wandern in den deutlich größeren Dateispeicher (LittleFS), damit auch viele Geräte ohne dieses Problem laufen. Ich melde mich, sobald das draußen ist; das Lasttest-Angebot mit Deinen 11 Boxen nehme ich dann sehr gern an.

Moin,
danke für Deine Antwort. Das Problem war ein ganz anderes. Die verschiedenen Fehlermeldungen, die ich gestern Abend zu sehen bekam, waren offenbar alle irreführend. Seit gestern Abend funktionieren die Boxen auch wie gewünscht. Allerdings war ich dann zu müde, um das Ergebnis noch zu beschreiben.

Aber der Reihe nach...

Zuerst: ich habe noch nicht elf Geräte migriert, sondern nur vier.

Erst habe ich einen Lautsprecher testweise migriert, das hat anstandslos funktioniert.
Das fand in einem abgeschotteten WLAN statt, in dem nur der Lautsprecher und sixback liefen.

Danach habe einen AP gestartet, der 2,4GHz in meinem "Haupt-WLAN" bereitgestellt hat. Damit wollte ich die vier in regulärer Nutzung befindliche Bose Boxen migrieren.
Die Boxen wurden anstandslos gefunden und offenbar auch migriert. Beim Anlegen von Presets gingen dann die Fehlermeldungen los und es hat eine Weile gedauert, bis ich hinter die Ursache gekommen bin.

Im Vorfeld der Bose Abschaltung hatte ich die Presets der Boxen auf die Fritzbox als Mediaserver umgestellt. Danach hatte ich den Boxen den Internetzugang gesperrt und diese auf soundcork umgestellt.

Durch den gestern nach wie vor gesperrten Internetzugang konnte sixback natürlich keine TuneIn presets auf die Boxen legen, weil diese einfach nicht abgespielt werden konnten. (Das meinte ich mit irreführende Fehlermeldungen, mit NVS hatte das gar nix zu tun, auch die zeitweise HTTP 502 Meldung offenbar nicht)

Als mir das mit der Internetsperre dann einfiel und ich diese entfernt habe, konnten alle vier Boxen problemlos eingerichtet werden.

Fazit: im Rahmen der Migration könnte im Status eines Bose Gerätes vielleicht ein Hinweis stehen, falls dabei festgestellt wird, dass keine Verbindung ins Internet besteht. Das hätte mir bestimmt zwei Stunden experimentieren bis hin zum Flashen der Box per USB erspart :)

Der erste getestete Lautsprecher hatte die Internetsperre nie, deshalb trat das Problem dort nicht auf.

Der Vollständigkeit halber noch die gewünschte Ausgabe:
{"used_entries":390,"free_entries":240,"total_entries":630,"namespace_count":13,"percent_used":61.90476}
Kannst Du bitte zu meiner Frage bezüglich ESP32 C5 mit 5GHz WLAN noch was sagen?

Danke fürs gründliche Nachfassen — und vor allem dafür, dass Du der Sache so sauber auf den Grund gegangen bist. Dass die angezeigten Meldungen (NVS, zeitweise 502) in die Irre geführt haben, geht auf unsere Kappe: sie haben das eigentliche Problem verdeckt statt es zu benennen.

Dein Befund ist goldwert: ohne Internetzugang kann die Box den TuneIn-Stream gar nicht erst abspielen, und dann scheitert folgerichtig auch das Ablegen des Presets — nur sagt das die Fehlermeldung eben nicht. Genau Deinen Vorschlag greifen wir auf: im Geräte- bzw. Migrationsstatus soll künftig ein klarer Hinweis erscheinen, wenn eine Box (oder SixBack selbst) keine Internet-Verbindung hat. Das hätte Dir die zwei Stunden erspart.

Zu Deiner ESP32-C5-Frage (5-GHz-WLAN): Der C5 ist tatsächlich der naheliegende Kandidat — er ist der erste ESP32 mit Dualband, also 2,4 und 5 GHz. Aktuell laufen alle vier SixBack-Targets ausschließlich auf 2,4 GHz. Ein 5-GHz-Build steht damit auf dem Schirm, ist aber noch nicht spruchreif: der IDF-/Framework-Support für den C5 ist derzeit noch dünn, und ich habe selbst noch keinen C5 hier im Lab. Ich besorge mir die Tage einen — aber ohne Hardware zum Gegentesten will ich nichts versprechen, was ich nicht verifiziert habe. Sobald ich einen C5 sauber zum Laufen bekomme, melde ich mich dazu.

Schön, dass jetzt alle vier Boxen laufen — und danke fürs Mittesten.

Hallo Dirk,

Zitat von: tostmann am 05 Juni 2026, 10:07:48Ein 5-GHz-Build steht damit auf dem Schirm, ist aber noch nicht spruchreif: der IDF-/Framework-Support für den C5 ist derzeit noch dünn, und ich habe selbst noch keinen C5 hier im Lab. Ich besorge mir die Tage einen — aber ohne Hardware zum Gegentesten will ich nichts versprechen, was ich nicht verifiziert habe. Sobald ich einen C5 sauber zum Laufen bekomme, melde ich mich dazu.

Wenn alles klappt, sollte ich ab morgen das oben verlinkte C5-DevKit von Amazon hier haben.
Falls es was zum Testen gibt, was per WebFlash getestet werden kann, sag Bescheid.

Unter welchen Umständen verlieren die Boxen eigentlich die Presets?

Inzwischen hatte ich drei Mal den Fall, dass keine Presets mehr vorhanden waren und ich diese manuell wieder über die WebUI setzen musste.
Eine Box (die ST20 im Flur) hatte dieses Problem bisher offenbar noch nicht, die Presets ließen sich dann aber auch nicht von dieser Box auf die anderen drei kopieren.

Hallo betateilchen,

der Frage bin ich nachgegangen — und Du hast damit einen echten Bug aufgedeckt. Kurzfassung: die Presets gehen nicht auf den Boxen verloren, sondern im SixBack-ESP, und zwar reproduzierbar ab einer bestimmten Anzahl verwalteter Speaker. Ich habe das gestern im Labor nachgestellt und die Ursache gefunden.

Zum Hintergrund: SixBack legt die Preset-Belegung aller Speaker als ein einzelnes JSON-Objekt im NVS des ESP ab. Der dafür verwendete NVS-String-Datentyp hat in ESP-IDF ein hartes Limit von 4000 Bytes — das war mir in dieser Konsequenz nicht bewusst. Ab etwa fünf Speakern mit voller Preset-Belegung ist das JSON größer, und ab da schlägt ausnahmslos jeder Speichervorgang fehl, völlig egal wie leer die NVS-Partition tatsächlich ist. Die Fehlermeldung "partition full" in der WebUI war daher irreführend, und genau deshalb ließ sich auch nichts mehr von einer Box auf andere kopieren: der Kopiervorgang ist am Ende derselbe Schreibpfad.

Der eigentlich fatale Teil: die eingebaute Aufräum-Routine, die bei einem fehlgeschlagenen Speichervorgang Platz schaffen soll, löscht in ihrer letzten Eskalationsstufe den alten Eintrag, um ihn neu zu schreiben. Da der Neuschreib bei Überschreiten des Limits aber prinzipbedingt wieder scheitert, vernichtet ein einziger zu großer Speichervorgang den letzten intakten Stand. Im laufenden Betrieb merkt man davon nichts, weil die Belegung im RAM weiterlebt und die WebUI alles korrekt anzeigt — erst beim nächsten Neustart des ESP (zum Beispiel durch ein OTA-Update, davon gab es zuletzt mehrere in kurzer Folge) lädt er den leeren Stand. Boxen, die danach ihre Preset-Liste vom ESP synchronisieren, übernehmen das Ergebnis. Dass Deine ST20 im Flur verschont blieb, passt ins Bild: deren Eintrag steckte vermutlich noch im letzten erfolgreich gespeicherten Stand, beziehungsweise die Box hat seither schlicht nicht neu gesynct.

Der Fix ist fertig und auf Test-Hardware verifiziert: die Ablage erfolgt jetzt als NVS-Blob (das Limit liegt damit bei der Partitionsgröße statt bei 4000 Bytes), und die Aufräum-Routine sichert den alten Stand und stellt ihn wieder her, falls der Neuschreib scheitert — ein Datenverlust durch diesen Mechanismus ist damit ausgeschlossen. Kommt mit dem nächsten Release.

Bis dahin zwei praktische Hinweise. Erstens: Presets, die Du jetzt setzt, leben bei Deiner Speaker-Anzahl nur im RAM und sind nach dem nächsten ESP-Neustart wieder weg — das Neu-Belegen lohnt sich also erst nach dem Update. Zweitens: wenn Du die Zahl der in SixBack verwalteten Speaker vorerst auf vier oder fünf reduzierst, bleibt das JSON unter dem Limit und alles verhält sich normal.

Eine ehrliche Ansage noch zur Kapazität: auch mit dem Fix ist die NVS-Partition (24 KB, aus Kompatibilitätsgründen zum Bestand nicht änderbar) bei voller Preset-Belegung nach meiner Messung bei etwa sieben Speakern am Ende — dann allerdings mit korrekter Fehlermeldung und ohne Datenverlust. Für den vollen Ausbau auf elf Boxen braucht es noch eine weitere Ausbaustufe der Ablage, die ist auf der Liste. Wenn Du nach dem Update mit Deinem Bestand testen magst, wäre mir das sehr willkommen — Deine Flotte ist dafür das beste Testfeld, das ich kenne.

Gruß, Dirk

Hallo Dirk,

schreibst Du das JSON 1:1 weg. Dann wäre mein Vorschlag, ohne tiefer eingestiegen zu sein, es zu komprimieren.

Grüße Jörg

Hallo Jörg,

ja, das JSON geht 1:1 ins NVS — seit gestern als Blob statt als String (das war der eigentliche Bugfix, der String-Typ hat ein hartes 4000-Byte-Limit), aber unkomprimiert.

Dein Vorschlag ist gut, und ich habe ihn gleich vermessen statt nur geschätzt. Erstens die Rate: der Preset-Store meines Test-Bestands (3 Speaker, voll belegt) geht mit deflate von 2311 auf 592 Bytes, Faktor ~3,9 — JSON mit den immer gleichen Keys und URL-Präfixen ist dankbares Material. Rechnerisch hebt das die Decke von derzeit ~7 voll belegten Speakern pro Stick auf grob 20+, auch mit dem Faktor 2 eingerechnet, den ein NVS-Blob-Update kurzzeitig braucht (alter und neuer Wert koexistieren).

Zweitens die Implementierungsseite, und da wird es interessant: miniz (deflate) liegt auf allen vier Ziel-Chips komplett im Mask-ROM — Kompressor (tdefl) und Dekompressor (tinfl), in den ROM-Linker-Scripts nachgesehen und auf einem S3 real ausgeführt (12 KB Test-JSON in 5 ms komprimiert, Roundtrip sauber). Kostet also null Flash. ABER: der tdefl-Arbeitsspeicher-State der ROM-Variante ist gemessene 167.744 Bytes — die ROM-Builds sind die speicherhungrige Voll-Konfiguration, identisch auf allen vier Chips. Auf dem S3 mit PSRAM ist das egal; auf C3/C6 passt das zwar in den nackten Chip (512 KB SRAM), aber nicht mehr in das, was unter laufendem SixBack mit WiFi und TLS an Heap übrig ist (~50-80 KB). Der Dekompressor ist mit ~11 KB überall unkritisch.

Deshalb habe ich als Gegenkandidat heatshrink (LZSS, zwei kleine C-Files) auf einem C6 vermessen: mit window=8 braucht der Encoder-State ganze 1,6 KB, schafft auf demselben Test-JSON Faktor ~3,6 in 13 ms, Decoder-State 548 Bytes. Mit window=11 sind es Faktor ~5 bei 12 KB State. Auf echten Daten (weniger repetitiv als mein Test-JSON) ist eher Faktor 2-2,5 realistisch — aber selbst das verdreifacht die Decke praktisch. Damit kann ein und derselbe leichtgewichtige Kompressor einheitlich auf allen Chips laufen, für ~3-5 KB Flash; das ROM-deflate bliebe als Option für den S3. Ein Format-Byte vor dem Blob hält beide Wege offen; Export/Import bleibt ohnehin Klartext-JSON.

Steht damit konkret auf der Liste für die Ausbaustufe für größere Flotten. Danke für den Anstoß — der hat sich gelohnt.

Gruß, Dirk

Kurzer Nachtrag: die im letzten Post angekündigte Ausbaustufe ist fertig und seit heute als v0.8.17 (https://github.com/tostmann/SixBack/releases/tag/v0.8.17) released (Update über System -> Check for update, oder es kommt mit dem periodischen Check von selbst).

Bei der Umsetzung gab es noch eine Wendung, die Jörgs Nachfrage im Rückblick doppelt berechtigt: das ROM-deflate ist an seinem Arbeitsspeicher-Hunger gescheitert. Der Kompressor-State der ROM-Variante misst 167.744 Bytes — das passt auf C3/C6 zwar in den nackten Chip, aber nicht in das, was unter laufendem SixBack mit WLAN und TLS an Heap übrig bleibt. Geworden ist es deshalb heatshrink (https://github.com/atomicobject/heatshrink) (LZSS, zwei kleine C-Files, ISC-Lizenz): 1,6 KB Encoder-State, läuft einheitlich auf allen vier Chips, gemessener Faktor 2-4 auf echten Store-Daten.

Das Ergebnis in Zahlen: die Decke pro Stick steigt von ~7 voll belegten Speakern auf 15-20+. Verifiziert auf Test-Hardware: ein Store mit 11 Speakern x 6 Presets (~11 KB Klartext — früher Hard-Fail ab ~5,5 KB) schreibt sauber durch, überlebt Reboots und belegt die NVS-Partition zu gerade 49 %.

Weil diese Schicht Nutzerdaten hütet, war der Paranoia-Anteil diesmal bewusst hoch: alle Lese-Pfade sind gegen korrupte Daten abgesichert (ein defekter Eintrag kann den Boot nicht mehr aufhängen), bei Speicherknappheit fällt das Schreiben sauber auf unkomprimiert zurück, und host-seitig liefen 2.700 Fuzz-Fälle mit absichtlich kaputten Daten ohne Hänger oder Absturz durch. Bestehende Daten migrieren beim ersten Schreiben von selbst — da muss niemand etwas tun. Einziger Hinweis: ein manuelles Downgrade auf eine Version vor v0.8.17 kann die komprimierten Stores nicht mehr lesen.

@betateilchen: damit ist Dein Vollausbau mit allen elf Boxen an einem Stick keine theoretische Frage mehr — falls Dein Lasttest-Angebot noch steht, wäre genau das jetzt der richtige Test. Die Presets nach dem Update einmal neu setzen (die vor v0.8.15 gesetzten lagen bei Deiner Speaker-Zahl ja nur im RAM), danach bleiben sie.

Danke nochmal an Jörg für den Anstoß — von der Forums-Frage bis zum Release vergingen am Ende keine drei Stunden.

Gruß, Dirk

Moin Dirk,

danke für die schnelle Reaktion, ich werde .17 testen und berichten.
Auch den Lasttest werde ich gerne durchführen, ob ich das heute noch schaffe, weiß ich aber nicht.

Zur Klarstellung:

• bis jetzt hatte ich noch nie mehr als 4 Speaker mit sixback in Betrieb
• der Verlust der presets erfolgte von einem Moment auf den nächsten, ohne irgendeine Aktion meinerseits

Ich gehe dann mal eine Steckdosenleiste mit 7 Slots suchen  8)

Die Vielfalt der Zustandsmeldungen scheint grenzenlos zu sein.



----

Übrigens: mein ESP32 C5 kam gestern an und bisher verhält er sich mit einem WLAN Test-Sketch der Arduino IDE völlig unauffällig auf 5GHz.

So, der Lasttest läuft. Die Gruppe mit 11 Boxen spielt einheitlich NDR1 Niedersachsen.

Das Einzige was auffällt: der Status von fl_ST20 hat ein Blinker-Syndrom. Mal grün (on), mal weiß (off) obwohl der Lautsprecher durchgehend läuft.
Aber diese Box ist ohnehin irgendwie speziell, es ist die Box, die auch die presets nie verloren hatte.
Vielleicht mache ich da irgendwann nochmal einen Factory-Reset und konfiguriere sie neu.

Alle Boxen, die mit ST... in der Liste beginnen, sind die Reserve-Boxen. Die ersten vier sind hier in der Wohnung verteilt und regulär in Benutzung.

@Dirk: Brauchst Du irgendwelche Diagnosedaten aus dem Gerätepark?


---

Ein paar Auffälligkeiten nach einiger Zeit...

Nach einem ESP-Reboot sind nur noch 9 der 11 Geräte in sixback vorhanden. Die zuletzt hinzugefügten zwei Geräte fehlen.

Was noch auffällt: Die Schiebeschalter im WebUI funktionieren nicht mehr. Egal ob in Safari oder in Firefox. Es kommt zwar die Meldung "Auto-Migrate disabled" aber der Schalter springt sofort wieder auf "on" und grün. Ähnlich bei "Share diagnostic..." nur dass hier alles auf "off" bleibt.

Und dann sind da noch ein paar Merkwürdigkeiten beim Browser-Einsatz:

• Chrome auf macOS: sixback ist weder unter 192.168.123.44 noch sixback.local erreichbar
• Safari auf macOS: 192.168.123.44 und sixback.local erreichbar
• Firefox auf macOS: 192.168.123.44 und sixback.local erreichbar

Wobei diese Browser-Phänomene auch noch auf mac mini und macbook neo unterschiedlich auftreten.

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

Zitat von: tostmann am 07 Juni 2026, 23:26:03Und 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:

{"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.

{"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.

Zitat von: tostmann am 07 Juni 2026, 23:26:03Chrome 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.

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

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 :)

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

Zitat von: tostmann am 10 Juni 2026, 01:36:43entscheidend 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:

ZitatSignalstärke: -72dBm

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

Bildschirmfoto 2026-06-10 um 17.42.52.png

---

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

Bildschirmfoto 2026-06-10 um 17.45.18.png

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

Zitat von: tostmann am 10 Juni 2026, 01:36:43Aus 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.


--

@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

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

Zitat von: betateilchen am 10 Juni 2026, 20:23:02Mal 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.

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.

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

Moin,

Zitat von: tostmann am 10 Juni 2026, 23:47:18,,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.

Zitat von: tostmann am 10 Juni 2026, 23:47:18Blinken: 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?

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.


--

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

Moin Dirk,

Zitat von: tostmann am 11 Juni 2026, 11:21:02Erstens ,,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.

Zitat von: tostmann am 11 Juni 2026, 11:21:02Genau 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.

Zitat von: tostmann am 11 Juni 2026, 11:21:02Zur 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.


--

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

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 :)

Zitat von: tostmann am 11 Juni 2026, 15:24:42die ,,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.

Zitat von: fred_feuerstein am 11 Juni 2026, 15:38:21gerade 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.

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.

Zitat von: tostmann am 11 Juni 2026, 17:21:58Und 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:

Zitat von: fred_feuerstein am 10 Juni 2026, 12:36:43Werde es weiter beobachten, wenn ich aus dem Urlaub zurück bin :)

Im Moment läuft hier alles unauffällig.

Auf meiner Wunschliste steht aktuell: Ein-/Ausschalten der Uhrzeitanzeige (z.B. bei ST20) über die WebUI

Und ich überlege seit ein paar Tagen, ob nicht früher (zu Bose Cloud Zeiten) auf der ST20 auch das von TuneIn gelieferte Sender-Logo angezeigt wurde oder ob ich mir das nur einbilde.

Hallo betateilchen,

beides ist jetzt geklärt — der Uhrzeit-Wunsch ist umgesetzt, bei den Logos habe ich leider eine Absage.

Uhrzeit-Anzeige: in v0.8.25 (gerade veröffentlicht) gibt es pro Box mit Display (ST20/ST30) einen An/Aus-Schalter für die Uhr direkt in der Web-UI — Box-Karte aufklappen, dann erscheint eine Zeile "Clock display" mit einem Schalter. SixBack schaltet das geräteseitig, der Speaker behält die Einstellung. Bestandssticks ziehen v0.8.25 automatisch per OTA.

TuneIn-Sender-Logos am Display: das geht leider nicht — und zwar nicht an SixBack, sondern am Display selbst. Ich habe es an einem echten ST30 nachgemessen: beim Abspielen liefert der Speaker intern durchaus ein gültiges Sender-Logo (die now_playing-Antwort enthält eine funktionierende Logo-URL), aber das Geräte-Display zeigt bei Radio trotzdem nur Text — Sendername und Slogan im Wechsel, kein Logo-Bild. Das war auch zu Bose-Cloud-Zeiten so; die Logos sieht man nur in der SoundTouch-App, nicht auf dem Gerät. Über die API ist daran nichts zu ändern.

Helligkeit: dazu passend — das Display kann auch nicht dimmen, es kennt nur an und aus. Jeder Helligkeitswert über null leuchtet gleich hell. Deshalb ist es bewusst ein reiner An/Aus-Schalter geworden und kein Helligkeitsregler.

Viele Grüße

Danke für Deine Antwort.

Zitat von: tostmann am 14 Juni 2026, 16:22:43kein Logo-Bild. Das war auch zu Bose-Cloud-Zeiten so; die Logos sieht man nur in der SoundTouch-App, nicht auf dem Gerät.

Da würde ich tatsächlich dagegen wetten. Wenn ich das Logo noch nie auf der Box gesehen hätte, würde ich es ja gar nicht vermissen.

Aber egal, wenn die API das nicht hergibt, dann ist das eben so. Vermutlich kam das dann einfach woanders her.
Oder ich verwexle das tatsächlich total. Aber das Airplay Logo gab/gibt es ja auch auf der ST20, zumindest hatte ich das zu soundcork-Zeiten noch gesehen. Jetzt mit sixback scheint das aber auch nicht mehr zu kommen, fällt mir gerade auf.

Vielleicht muss ich nochmal eine Box auf soundcork bringen, um das zu verifizieren.

Zitat von: betateilchen am 14 Juni 2026, 17:59:11Vielleicht muss ich nochmal eine Box auf soundcork bringen, um das zu verifizieren.

Zumindest das bei sixback nicht vorhandene TuneIn-Logo habe ich bei einer Box auf soundcork schonmal.
Wenn ich mal viel Zeit habe, werde ich weiterforschen.


--

Ja, es gab kein Sender-Logo, nur ein Quellen Logo für Tunein. Oder auch andere Quellen. Bspw. Spotify Logo, Airplay Logo, Amazon Music Logo usw.

Wegen dem OTA Update Problem, was ich schon 2 m hatte, zuletzt wie oben berichtet.
es kann durchaus sein, dass es an der Anzahl der Lautsprecher liegt. Wobei betateilchen ja auch die grosse Anzahl hat.

Aber das Update lief korrekt durch, nur der Neustart vom esp32 S3 hatte nicht funktioniert. Esp war nicht mehr erreichbar.
Was ich aus der Ferne machen konnte: der Esp hängt an einem USB Anschluss der fritzbox. Habe die fritzbox mal neugestartet. Dabei wird auch der USB Anschluss mal stromlos. Somit neuer reboot vom Esp32.
danach war er wieder erreichbar.

Und das Update von 0.8.23 auf die 0.8.25 hat wieder fehlerfrei funktioniert.

Zitat von: fred_feuerstein am 14 Juni 2026, 20:32:28Wegen dem OTA Update Problem, was ich schon 2 m hatte, zuletzt wie oben berichtet.
es kann durchaus sein, dass es an der Anzahl der Lautsprecher liegt. Wobei betateilchen ja auch die grosse Anzahl hat.

Das Problem hatte ich auch schon zwei Mal: beim Update auf .21 und heute beim Update auf .25
Die Aktualisierung der Anzeige blieb einfach irgendwo stehen und es schien sich nichts mehr zu tun.
In Wirklichkeit lief das Update aber durch und ein Drücken des RST-Buttons am ESP32 hat in beiden Fällen den Spuk beseitigt.

Ein Problem mit der Anzahl der Boxen sollte aber eher nicht die Ursache sein.
Beim heutigen "Problem" waren nur 4 von 11 Boxen in Betrieb (aka: mit Strom versorgt)

@fred: Danke, du triffst es genau — es sind zwei verschiedene Dinge, die man leicht in einen Topf wirft:

Sender-Logo (das eigene Logo eines einzelnen Senders, z.B. das bunte SWR3-Bild): Das gab es noch nie auf dem Gerätedisplay, auch nicht zu Bose-Cloud-Zeiten — es erscheint nur in der SoundTouch-App. Am Display steht immer nur der Sendername als Text.

Quellen-Logo (die Marke der Quelle: TuneIn, Spotify, AirPlay, Amazon Music ...): Das zeigt das Display sehr wohl. Es ist fest in der Geräte-Firmware hinterlegt und hängt an der gerade aktiven Quelle.

Damit muss ich meine eigene Aussage von vorhin korrigieren: die war zu pauschal. Das Quellen-Logo (also das TuneIn-Logo selbst) geht — nur die senderindividuellen Logos nicht.

Und SixBack zeigt das TuneIn-Quellen-Logo auch: Sobald ein Sender als echte TuneIn-Quelle läuft, steht das TuneIn-Logo über dem Sendernamen, genau wie früher.

@betateilchen: Wenn bei dir das TuneIn-Logo fehlt, läuft der betreffende Sender bei dir vermutlich gar nicht als TuneIn-Quelle, sondern als selbst hinzugefügter Stream (Stream-Tab bzw. "trotzdem hinzufügen", oder aus der RadioBrowser-Suche). Solche Sender laufen technisch als Quelle "Internet Radio" und tragen deshalb kein TuneIn-Branding — das ist so korrekt, kein Fehler. Dass du es auf soundcork siehst, liegt vermutlich daran, dass dort derselbe Sender über die echte TuneIn-Quelle aufgelöst wird.

Magst du in der WebUI mal nachschauen, wie der betroffene Sender hinterlegt ist — kommt er aus der TuneIn-Suche (dann sollte das Logo da sein) oder ist es ein eigener Stream? Dann haben wir Gewissheit.

Ich bin durchaus in der Lage, zwischen "Quellen Logo" und "Sender Logo" zu unterscheiden.

<presets>
<preset id="1">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s50412" sourceAccount="" isPresetable="true">
<itemName>Bremen Zwei</itemName>
<containerArt>https://sixback.io/stations/tunein-logo/s50412</containerArt>
</ContentItem>
</preset>
<preset id="2" createdOn="1781335119" updatedOn="1781335119">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s56857" sourceAccount="" isPresetable="true">
<itemName>NDR 2 Niedersachsen</itemName>
<containerArt>https://sixback.io/stations/tunein-logo/s56857</containerArt>
</ContentItem>
</preset>
<preset id="3">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s24896" sourceAccount="" isPresetable="true">
<itemName>SWR3</itemName>
<containerArt>https://sixback.io/stations/tunein-logo/s24896</containerArt>
</ContentItem>
</preset>
<preset id="4">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s25529" sourceAccount="" isPresetable="true">
<itemName>NDR 1 Niedersachsen</itemName>
<containerArt>https://sixback.io/stations/tunein-logo/s25529</containerArt>
</ContentItem>
</preset>
<preset id="5">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s8007" sourceAccount="" isPresetable="true">
<itemName>ORF Hitradio OE3</itemName>
<containerArt>https://sixback.io/stations/tunein-logo/s8007</containerArt>
</ContentItem>
</preset>
<preset id="6">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s6814" sourceAccount="" isPresetable="true">
<itemName>Radio Swiss Jazz</itemName>
<containerArt>https://sixback.io/stations/tunein-logo/s6814</containerArt>
</ContentItem>
</preset>
</presets>


@betateilchen: Du hattest recht — deine Presets sind sauber als source="TUNEIN" hinterlegt, meine Custom-Stream-Vermutung war daneben. Ich bin dem im Code nachgegangen (auch bei soundcork) und habe die echte Ursache gefunden und am ST30 verifiziert.

Jede Quelle registriert beim Speaker ein kleines Quellen-Icon. soundcork liefert dort ein echtes Logo aus; SixBack lieferte an genau dieser Stelle bislang bewusst ein 1x1-transparentes Platzhalterbild (um keine fremden Logos mitzuliefern) — deshalb erscheint das Logo bei soundcork und bei SixBack nicht. Am ST30-Display bestätigt: sobald SixBack dort ein echtes Bild ausliefert, zeigt das Panel es an.

Den Fix baue ich ein — aber bewusst nicht mit dem TuneIn-Logo, sondern mit einem eigenen SixBack-Badge ("SIX/BACK"). Zwei Gründe: ein fremdes Markenlogo mitzuliefern ist markenrechtlich heikel, und "TuneIn" als Anzeige ist ohnehin wenig hilfreich — das Badge brandet jetzt den lokalen Cloud-Ersatz direkt am Gerät. Am ST20/ST30-Display erscheint künftig also "SIX BACK" an der Stelle, wo vorher nichts war (einheitlich für alle Quellen, auch eigene/LAN-Streams).

Kommt mit dem nächsten Release per OTA. Danke fürs hartnäckige Gegenhalten — ohne deinen XML-Beleg hätte ich an der falschen Stelle weitergesucht.

Ok. Und ich beharre auch auf meiner Meinung, dass ich auf der ST20 irgendwann schon das NDR2 Logo und bei SWR3 auch schon Album-Art vom laufenden Titel gesehen habe.  Mit der App habe ich die Box nie benutzt, außer für die Ersteinrichtung.

Nochmal zum Thema Dimmen: Nicht dass ich das wirklich bräuchte oder danach gefragt hätte. Aber die ST20 ist ja durchaus in der Lage, unterschiedliche Helligkeiten bei dargestellten Objekten zu verwenden.
Im Standby Modus wird das WLAN Symbol abgedunkelt, die Uhrzeit aber in voller Helligkeit angezeigt.
Mit dem Thema habe ich mich noch nicht weiter beschäftigt, aber vielleicht ist die Helligkeit eine Eigenschaft der einzelnen angezeigten Objekte und nicht des gesamten Displays?

@betateilchen: Klingt alles gut möglich — und ist eine gute Idee. Wenn die Zeit es hergibt, schaue ich mir das Display-Rendering an der ST20 (Sender-Logo, Album-Art, Objekt-Helligkeit) gern nochmal genauer an; im Moment sprengt es aber ehrlich gesagt meinen Rahmen. Der Code ist offen — falls jemand früher Lust hat, da reinzuschauen: PR sehr willkommen.

Das eigentliche Ziel war, die Preset-Tasten ohne Bose-Cloud zurückzubringen, "Back" eben — und das steht. Das SIX/BACK-Badge an der Quellen-Stelle kommt wie angekündigt per OTA.

Mach Dir keinen Stress.
Was jetzt schon alles geht, ist echt super. Danke dafür!

Ehrlich gesagt wäre mir eine 5GHz-Lösung persönlich wichtiger als die Display-Themen 🙃

Und ich hätte auch schon lange etwas gespendet, aber Paypal kommt mir nicht ins Haus.

Nach dem gestrigen Update auf .26 hat mein sixback über Nacht einen totalen Gedächtnisverlust erlitten. Die aktuelle Uptime von 10 Stunden deutet darauf hin, dass gestern Abend irgendwas passiert ist, als ich längst geschlafen habe.

Heute morgen kennt sixback nur noch (vermutlich: wieder) die 5 Boxen, die aktuell in Betrieb sind. Diese werden im WebUI auch nicht mehr in der von mir sortierten Reihenfolge angezeigt.

Von einem sixback Logo ist bisher nichts zu sehen. Muss ich dazu die Box einmal neu starten oder sollte das von alleine auftauchen?

Kurz:

.26 als Ursache praktisch ausgeschlossen — der Release war nur der Quellen-Badge fürs Display (der eine Icon-Stub-Handler), kein Owner-/Discovery-/Persistenz-Code. ,,Erkennt nur eingeschaltete Boxen" ist erwartet: ausgeschaltete Speaker sind nicht im LAN, per SSDP/UPnP also nicht auffindbar. Der owned/migrierte Zustand liegt pro Speaker im NVS und geht nicht verloren — die Box kommt beim Einschalten mit ihrem Zustand zurück. Diagnose-Frage: taucht sie nach Power-on (kurz warten) von selbst wieder auf? Falls eine eingeschaltete, pingbare Box dauerhaft fehlt, ist das was anderes — dann bitte Modell + FW-Stand.

SIX/BACK-Badge: das ist das Quellen-Icon im per-Quelle-Slot und kommt nur bei den Quellen, die über die BMX-Services laufen — also Internet-Radio (TuneIn / Custom Stations / RadioBrowser), und auch nur solange diese Quelle die aktive now-playing-Quelle ist. Bei DLNA/gespeicherter Musik und Spotify liefert die Quelle ihre eigene Cover-/Track-Art, da kommt kein Badge. Es ist per Quelle, nicht per Sender — ein Per-Sender-Logo geht am Panel nicht.

Nochmal: der Unterschied zwischen Quellen-Logo und Sender-Logo ist mir völlig klar. Bei mir laufen nur TuneIn Sender über presets, wie gestern im XML zu sehen.

Nicht auffindbare Speaker wurden im Frontend in den letzten Tagen immer als "offline" angezeigt.
Dass sie nun nicht mehr angezeigt werden, ist das Eine. Das andere ist die verlorengegangene Reihenfolge im Frontend. Das brachte mich zu der Vermutung, dass alle Informationen vorloren gingen und dann einfach die gefundenen Boxen als neu migriert wurden.

Das Inventar scheint auch tatsächlich nur noch 5 Boxen anstatt 11 zu kennen, siehe Anhang.


--

Zitat von: tostmann am 16 Juni 2026, 11:41:47die Box kommt beim Einschalten mit ihrem Zustand zurück. Diagnose-Frage: taucht sie nach Power-on (kurz warten) von selbst wieder auf? Falls eine eingeschaltete, pingbare Box dauerhaft fehlt, ist das was anderes — dann bitte Modell + FW-Stand.

Die Box taucht beim Anlegen der Spannungsversorgung wieder auf und wird nach einiger Zeit als "migrated (ours)" angezeigt.

Ein "Refresh Status" wie im vorletzten Beitrag zu sehen hängt sich aktuell reproduzierbar beim "Inventory probe" auf.

Der hängende ,,Refresh Status" war ein echter Bug — und ist behoben. Der manuelle Refresh hat die komplette Geräte-Abfrage (Telnet/BMX pro Box, eine eingebaute Warteschleife von bis zu 30 Sekunden für Boxen in einem Zwischenzustand, plus pro Box die Spotify-Verknüpfung) in einem einzigen Web-Request erledigt, auf den die Oberfläche ohne Timeout gewartet hat. Bei einer kleinen Anlage fällt das kaum auf, bei einer großen Zone friert dabei die ganze Oberfläche ein. Ich habe die Abfrage jetzt — wie schon den ,,Discover"-Scan — in den Hintergrund verlagert: der Browser bekommt sofort eine Antwort und pollt dann, bis die Probe durch ist. Die UI bleibt durchgehend bedienbar. Ist ab sofort in v0.8.27 verfügbar — per OTA-Update oder über den Webflasher.

Zum ,,nur noch 5 statt 11 Boxen": Da hattest Du recht und meine erste Antwort war zu schnell. Migrierte Boxen sollen NICHT aus der Liste verschwinden, nur weil sie aus sind — SixBack merkt sie sich dauerhaft und zeigt sie auch ausgeschaltet als OFFLINE-Kachel. Die Discovery fügt nur hinzu, sie entfernt nie von selbst. Dass bei Dir 6 fehlen heißt: der gespeicherte Stand hält gerade wirklich nur noch die 5 erreichbaren. Der wahrscheinlichste Moment, in dem die anderen herausgefallen sind, ist genau das holprige Update mit der RST-Knopf-Rettung (.21/.25) — ein abgebrochenes Update kann den gespeicherten Stand beschädigen, und danach werden nur noch die Boxen wieder gelernt, die gerade eingeschaltet sind. Dass eine Box beim Einschalten sofort wieder als ,,migrated (ours)" auftaucht, passt genau dazu.

So bekommst Du die 11 zurück (am einfachsten nach dem v0.8.27-Update, dann hängt auch das nicht mehr): alle Boxen einschalten und einmal ,,Discover" laufen lassen; was der Auto-Scan nicht findet, lässt sich manuell per IP nachtragen. Einmal wieder erfasst, bleiben sie gespeichert und erscheinen künftig auch ausgeschaltet wieder.

Falls Du es trotzdem genauer einkreisen willst: häng den ESP an die serielle Konsole und lös den Refresh aus — Zeilen wie ,,[inv] keep ... cloudUrl=..." zeigen, ob eine der Boxen noch eine alte/tote Cloud-Adresse trägt. Nötig ist das aber nicht mehr, das blockiert die UI ja jetzt nicht mehr.

Zum SIX/BACK-Badge unverändert: das erscheint nur bei Internet-Radio-Quellen (TuneIn / Custom Stations / RadioBrowser), nicht bei DLNA oder Spotify. Und .26 selbst war wirklich nur die Badge-Änderung und nicht die Ursache des Verlusts.

Zitat von: tostmann am 16 Juni 2026, 14:34:28Zum SIX/BACK-Badge unverändert: das erscheint nur bei Internet-Radio-Quellen (TuneIn / Custom Stations / RadioBrowser), nicht bei DLNA oder Spotify.

Das habe ich auch aus Deiner letzten Antwort schon verstanden.
Nichts destotrotz:

Zitat von: betateilchen am 16 Juni 2026, 12:50:57Bei mir laufen nur TuneIn Sender über presets, wie gestern im XML zu sehen.

Und trotzdem sehe ich nix.
Egal, so wichtig ist mir das alles nicht.

"Now playing" auf einem Display, das sowieso schon auf meinem Schreibtisch steht 8)

signal-2026-06-17-152126.jpeg

Ein FHEM-notify schickt eine SIP Nachricht mit artist & track an das Telefon.
An einer Lösung mit Sender-Logo arbeite ich noch...


--

Zitat von: betateilchen am 17 Juni 2026, 15:23:11An einer Lösung mit Sender-Logo arbeite ich noch...

works as designed...

signal-2026-06-17-200251.jpeg

Senderlogos lasse ich mir auch von meinen Favoritensendern über ein DOIF in ein Reading schreiben, welche dann über die TabletUI auf meinen Wandtablets auf den entsprechenden Stellen angezeigt werden.

Zitat von: fred_feuersteinSenderlogos lasse ich mir auch von meinen Favoritensendern über ein DOIF in ein Reading schreiben

Wo Du gerade da bist, eine Rückfrage zu Deinem Setup mit den 9-10 Boxen: in v0.8.27 steckt eine nicht-blockierende Status-Aktualisierung, die genau das Zappeln der Status-Anzeige adressiert, das Du beschrieben hattest (Anzeige wechselt, obwohl der Lautsprecher aktiv ist und Musik durchläuft — bei Dir mit vielen Boxen deutlich häufiger als mit zweien). Bist Du schon auf 0.8.27, und falls ja: läuft die Status-Anzeige bei Deinen 9-10 Boxen jetzt ruhig, oder zappelt sie noch?

Heute habe ich unachtsamerweise einen zweiten ESP32 mit sixback geflasht, der hat dann direkt angefangen, die vorhandenen Boxen auf sich selbst zu migrieren. Das hat einiges an Verwirrung gestiftet.

Inzwischen habe ich alle vier betroffenen Boxen wieder eingefangen und siehe da - nach dem Ausflug und der Rückkehr zum "Heimat sixback" ist jetzt plötzlich auch das viel diskutierte sixback Logo sichtbar.



--

Zitat von: tostmann am 18 Juni 2026, 21:28:02Wo Du gerade da bist, eine Rückfrage zu Deinem Setup mit den 9-10 Boxen: in v0.8.27 steckt eine nicht-blockierende Status-Aktualisierung, die genau das Zappeln der Status-Anzeige adressiert, das Du beschrieben hattest (Anzeige wechselt, obwohl der Lautsprecher aktiv ist und Musik durchläuft — bei Dir mit vielen Boxen deutlich häufiger als mit zweien). Bist Du schon auf 0.8.27, und falls ja: läuft die Status-Anzeige bei Deinen 9-10 Boxen jetzt ruhig, oder zappelt sie noch?

Es wechselt auch in der 0.8.27 noch von "grün" auf "weiss" und wieder mal auf "grün", obwohl die Box die ganze Zeit einen Stream abspielt. Wechselt irgendwie zyklisch hin und her.

danke fürs Nachtesten auf 0.8.27 und für die Rückmeldung — gut zu wissen, dass das zyklische grün↔weiß bei Deinen 9-10 Boxen noch da ist.

Einordnung dazu: das ist ein reines Anzeige-Artefakt im Webfrontend. Der Status-Poll fragt periodisch jede Box ab; bei vielen Boxen überlappen sich der Poll und die Eigen-Statusmeldung der Box, und die Anzeige kippt für einen Moment auf weiß, bevor sie wieder auf grün einrastet. Dahinter steckt nichts Funktionales — die Box streamt durch, die Presets bleiben belegt, die Tasten lösen aus. Der non-blocking-Refresh in 0.8.27 hat das Zappeln seltener gemacht, aber bei Deiner Boxen-Zahl offensichtlich nicht ganz weg.

Ehrlich zur Priorität: das eigentliche Ziel war, die sechs Hardware-Tasten ohne die Bose-Cloud zurückzuholen — und das läuft. Den Status-Punkt im Webfrontend hübscher zu polieren steht bei mir bewusst weit hinten; ich nehme ihn auf die Liste, aber das Frontend zu perfektionieren ist nicht, wo gerade die Energie reingeht.

Wo ich aber sofort hellhörig werde: wenn bei den vielen Boxen etwas Funktionales hakt — Aussetzer im Audio, eine Taste die nicht greift, eine Box die nicht migriert. Das wäre dann kein Kosmetik-Thema und würde ich mir gleich ansehen. Sag bei sowas gern Bescheid.

Zu dem grün/weiß Thema auch noch eine Anmerkung von mir: das tritt sehr sporadisch auch bei meinen vier Boxen auf. Aber da das Frontend bei mir nicht zur "täglichen Nutzung" der Boxen verwendet wird, habe ich das inzwischen einfach als kosmetische Unzulänglichkeit eingestuft, die auf die Funktion keinerlei Einfluss hat.

In meinem Urlaub diese Woche habe ich versucht, aus dem Quellcode die Dateien für meinen ESP32-S3 zu erzeugen. Aber trotz vieler Versuche ist mir das nicht gelungen. Irgendwelche Abhängigkeiten können nicht aufgelöst werden. Allerdings muss ich auch dazusagen, dass ich mich mit PlatformIO noch nie anfreunden konnte. Mein Ziel im Erfolgsfall wäre gewesen, mich am Thema "5GHz" zu versuchen. Aber solange mir nichtmal das Kompilieren für eine bereits unterstützte Plattform gelingt, macht dieses Vorhaben für mich keinen Sinn.

Heute hatte ich endlich mal Zeit und Lust, meine neue "Bose Cloud" ordentlich zu verpacken :)

signal-2026-06-28-183839.jpeg

signal-2026-06-28-183925.jpeg

Angebracht ist das Ganze inzwischen per Klettband an der Rückseite einer ST20,
der vorhandene USB port reicht für die Versorgung aus und
liefert auch im Standby Modus der Box die benötigte Versorgungsspannung.

signal-2026-06-30-131125.jpeg

Nun hoffe ich nur, dass das sixback-Logo nicht markenrechtlich geschützt ist 8)



---

Zitat von: betateilchen am 28 Juni 2026, 00:15:38In meinem Urlaub diese Woche habe ich versucht, aus dem Quellcode die Dateien für meinen ESP32-S3 zu erzeugen. Aber trotz vieler Versuche ist mir das nicht gelungen. Irgendwelche Abhängigkeiten können nicht aufgelöst werden.

Inzwischen habe ich eine VM mit Debian aufgesetzt, weil ich vermutete, es könnte was mit der Installation auf macOS zu tun haben.
Aber dem war wohl nicht so, denn genau an der gleichen Stelle wie auf dem mac bricht auch die Projektkonfiguration unter Trixie ab:

Bildschirmfoto 2026-06-30 um 18.53.24.png

Wenn ich das "Anhängsel" hinter der url entferne, läuft die Konfiguration durch.
Aber irgendwas muss das ja bedeuten.
Was geht da schief und wie bekomme ich diese library vielleicht doch installiert?



---

Hallo betateilchen,

das liegt nicht an deinem Setup, sondern an einem kaputten Pin im Repo. In der platformio.ini ist die Improv-Lib auf einen festen Commit festgenagelt, den es auf GitHub nicht (mehr) gibt — der wurde durch einen Rebase ersetzt. PlatformIO klont das Lib-Repo deshalb erfolgreich, kann dann aber den angegebenen Commit nicht auschecken (git reset --hard ... schlägt fehl → "Konnte Objekt nicht parsen" / VCSBaseException). Bei mir baut es nur durch, weil der alte Commit noch in meinem lokalen PlatformIO-Cache liegt; bei einem frischen Build fehlt er.

Sofort-Workaround bei dir: In der platformio.ini die improv-wifi-busware-Zeile (im Block [common], lib_deps) auf den aktuellen Stand zeigen lassen. Entweder den Commit-Suffix komplett weglassen:

    https://github.com/tostmann/improv-wifi-busware.git

oder gezielt auf den aktuellen Commit pinnen:

    https://github.com/tostmann/improv-wifi-busware.git#768256c01e5ba42acd3d638fee39959bb9f8853c

Danach einmal den Lib-Cache des Projekts leeren, damit PlatformIO neu zieht (pio pkg uninstall / .pio-Ordner im Projekt löschen) und neu bauen.

Ich korrigiere den Pin im Repo und ziehe das in den nächsten Release; dann ist der Schritt nicht mehr nötig. Danke fürs Melden.

Hallo Dirk,

das mit dem Weglassen hatte ich schon erfolgreich probiert.

Inzwischen habe ich auch gesehen, dass es für den C5 schon Ansätze in der platform.ini gibt.
Mein C5 DevKit ist übrigens speichermäßig als N16R8 gekennzeichnet.

Das Kompilieren für C5 hat auch funktioniert, das sixback WLAN wird auch gefunden und das Portal ist erreichbar, aber ich kann dort noch keine Verbindung zu meinem Netzwerk herstellen. Na, mal schauen...
Ein kleines Erfolgserlebnis hatte ich dann ja doch noch.

Looking for upload port...
Uploading /home/udo/pio-build/bosefix32/c5/firmware.bin
esptool v5.1.2
Connected to ESP32-C5 on /dev/ttyACM0:
Chip type:          ESP32-C5 (revision v1.0)
Features:           Wi-Fi 6 (dual-band), BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 240MHz
Crystal frequency:  48MHz
MAC:                38:44:be:ff:fe:00:7f:94
BASE MAC:           38:44:be:00:7f:94
MAC_EXT:            ff:fe


allo betateilchen,

freut mich, dass der Workaround gegriffen hat und der C5 schon so weit kommt — Kompilieren, eigenes "sixback"-WLAN und erreichbares Portal sind genau die Schritte, die laufen sollen. Das ist schon das halbe Spiel.

Genau an der Stelle, an der du jetzt hängst — Portal da, aber die Box verbindet sich nicht mit deinem WLAN — steckt auch der Grund, warum der C5 bei uns derzeit NICHT als offizielles Release dabei ist. Auf einem C5-Board hier hat sich der Stick sauber verbunden (auch auf 5 GHz), auf anderer C5-Hardware bekommen wir aber trotz gutem Empfang reproduzierbar keine Verbindung zum Access Point zustande — und zwar auf beiden Bändern. Das sieht nach einem HF-/Hardware-Varianten-Thema aus, das wir noch nicht dingfest gemacht haben. Solange das nicht über die verschiedenen C5-Boards hinweg zuverlässig läuft, wollen wir den C5 nicht ausliefern: ein Target, das auf dem eigenen Tisch funktioniert, beim Anwender aber genau so stehenbleibt wie bei dir gerade, ist kein gutes Release. Lieber ehrlich "noch nicht" als ein C5-Image, das die Hälfte der Leute nicht ins Netz bekommt.

Wichtig ist mir der Punkt: am C5 als Chip liegt es nicht, und am Build und Flashen offensichtlich auch nicht — bei dir kompiliert es ja, läuft, und das Portal steht. Der eine offene Punkt ist eng umrissen: das zuverlässige Einbuchen ins heimische WLAN über die verschiedenen C5-Boards hinweg — und genau da stehst du gerade auch.

Was du gern versuchen kannst (und woran wir wirklich interessiert sind):

- Der env:c5 ist aktuell auf ein 4-MB-DevKit ohne PSRAM zugeschnitten (board esp32-c5-devkitc1-n4, partitions-4mb.csv). Auf deinem N16R8 läuft das auf dem 4-MB-Layout einfach mit, der Rest von Flash und PSRAM liegt brach — das ist NICHT die Ursache des Verbindungsproblems, nur zur Einordnung.
- Zum Eingrenzen: häng ihn testweise an ein reines 2,4-GHz-Netz. Wenn schon 2,4 GHz nicht joint, ist es genau die Wand, die wir auch sehen; wenn 2,4 geht und nur 5 GHz nicht, wäre das ein sehr nützliches Signal.
- Falls es bei dir doch verbindet: gib hier unbedingt Bescheid — du wärst ein zusätzlicher Datenpunkt auf echter Hardware, und du hast ja genau die 5-GHz-Motivation. Der Code liegt offen, Beobachtungen und PRs sind willkommen.

Viel Erfolg, und danke fürs Dranbleiben — gerade die C5-Rückmeldungen bringen uns hier weiter.

Moin,

was ich zu meinem DevKit definitiv sagen kann:

• Verbindung zu 5GHz WLAN funktioniert grundsätzlich problemlos und ist stabil
• Verbindung zu 2.4GHz WLAN funktioniert grundsätzlich problemlos und ist stabil

Dabei spreche ich jetzt aber nicht von sixback, sondern von einer anderen getesteten Applikation, die ich über die Arduino IDE auf das DevKit gebracht habe.

---

Was fällt mir sonst noch auf?

• Beim Kompilieren von sixback gibt es ein paar Warnungen, aber es läuft trotzdem bis zum Upload durch.
• Aktuell taucht das sixback-WLAN nicht mehr auf.
• Die Flash Größe wird wohl automatisch erkannt.

Configuring flash size...
Auto-detected flash size: 16MB
Flash will be erased from 0x00002000 to 0x00007fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x001d2fff...
Flash parameters set to 0x024f.


Environment    Status    Duration
-------------  --------  ------------
c5             SUCCESS   00:01:07.373

Und wenn ich mir aktuell den device monitor anschaue, sehe ich, dass das devkit sich in einer Dauer-Bootschleife befindet. Sehr merkwürdig.

06:26:24.917 > Rebooting...
06:26:24.917 > ESP-ROM:esp32c5-eco2-20250121
06:26:24.936 > Build:Jan 21 2025
06:26:24.936 > rst:0xc (SW_CPU),boot:0x18 (SPI_FAST_FLASH_BOOT)
06:26:24.936 > Core0 Saved PC:0x4080aca4
06:26:24.936 > SPI mode:DIO, clock div:1
06:26:24.948 > load:0x408556b0,len:0x1258
06:26:24.948 > load:0x4084bba0,len:0xca4
06:26:24.948 > load:0x4084e5a0,len:0x315c
06:26:24.948 > entry 0x4084bba0
06:26:26.294 > E (1366) MSPI Timing: Failed to allocate dummy cacheline for PSRAM memory barrier!
06:26:26.295 > [     6][I][esp32-hal-psram.c:106] psramAddToHeap(): PSRAM added to the heap.
06:26:26.816 >
06:26:26.876 > assert failed: lfs_fs_grow_ lfs.c:5263 (block_count >= lfs->block_count)


Zitat von: tostmann am 30 Juni 2026, 22:05:41Der env:c5 ist aktuell auf ein 4-MB-DevKit ohne PSRAM zugeschnitten (board esp32-c5-devkitc1-n4, partitions-4mb.csv).

Da steht bei mir zwar was anderes in der platformio.ini, aber ich habe das jetzt mal so eingetragen, wie von Dir angegben. Jetzt startet der C5 zumindest mal wieder so weit, dass das sixback-WLAN auftaucht. Aber noch während der Eingabe im Portal schlägt dann wieder die Reboot-Schleife zu. Deshalb kann ich da überhaupt nichts dauerhaft eingeben.

06:33:22.471 > ESP-ROM:esp32c5-eco2-20250121
06:33:22.471 > Build:Jan 21 2025
06:33:22.486 > rst:0x1 (POWERON),boot:0x59 (SPI_FAST_FLASH_BOOT)
06:33:22.486 > SPI mode:DIO, clock div:1
06:33:22.486 > load:0x408556b0,len:0x1258
06:33:22.486 > load:0x4084bba0,len:0xca4
06:33:22.491 > load:0x4084e5a0,len:0x315c
06:33:22.491 > entry 0x4084bba0
06:33:23.782 > E (1303) MSPI Timing: Failed to allocate dummy cacheline for PSRAM memory barrier!
06:33:23.782 > [     2][I][esp32-hal-psram.c:106] psramAddToHeap(): PSRAM added to the heap.
06:33:24.310 > [   532][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
06:33:24.339 > [   561][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
06:33:24.345 > [   567][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
06:33:24.351 > [   573][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
06:33:24.993 > [  1216][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND


Moin,

danke, das grenzt es sauber ein. Dein DevKit verbindet mit einer anderen App auf 2,4 UND 5 GHz stabil → die Funk-HW deines Boards ist ok; die sixback-Nicht-Verbindung liegt bei dir damit FW/Config-seitig bei uns, nicht am RF. Guter Datenpunkt.

Ehrlich zur Prio: C5 steht bei uns zeitlich gerade nicht auf der Agenda — wir bekommen das 5-GHz-Verhalten über die verschiedenen C5-Boards hinweg nicht zuverlässig dicht und treiben es aktuell nicht aktiv weiter. Aber: einen konkreten PR dazu nehmen wir hier gern an und testen ihn.

Gruß

Ich bin ja gerne bereit, bezüglich WLAN weiter zu testen und meine Erkenntnisse zu teilen.

Aber kannst Du mir bitte dabei helfen, eine platformio.ini zu finden, mit der ich die Software so kompilieren kann, dass sie zumindest läuft und nicht in einer Boot-Schleife endet? Da scheint es offenbar noch Probleme zu geben, die nichts mit WLAN zu tun haben dürften.

Mit dem Eintrag, der aktuell für C5 auf github steht, scheint das nicht zu klappen. Auch die Änderungen nach Deinen Hinweisen im vorletzten Beitrag haben keinen Erfolg gebracht.

Moin,

deine Trennung stimmt: die Boot-Schleife ist ein Config-/Board-Mismatch, nicht WLAN. Unser env:c5 ist bewusst auf ein nacktes 4-MB-Board OHNE PSRAM zugeschnitten (board esp32-c5-devkitc1-n4, partitions-4mb.csv, flash_size 4MB) — kein BOARD_HAS_PSRAM, kein psram_type, kein flash_mode. Dein DevKit ist ein N16R8, also 16 MB Flash + 8 MB PSRAM; genau diese Config auf einem PSRAM-Board crasht deshalb beim Boot.

Zwei Wege:

1. Am direktesten: ein nacktes esp32-c5-devkitc1 mit 4 MB / ohne PSRAM (die N4-Variante, ~5-8 EUR). Darauf läuft der github-env:c5 unverändert, die Boot-Schleife ist weg — und dein WLAN-Ergebnis wird 1:1 mit unserem vergleichbar, was uns fürs 5-GHz-Thema am meisten hilft.

2. Auf deinem N16R8 bleiben: dafür braucht es ein eigenes Env mit 16-MB-Layout + aktiviertem PSRAM. Wichtig: der C5 hat QUAD-SPI-PSRAM (nicht Octal wie der S3), die opi-/qio_opi-Werte aus unserem s3-8mb wären also falsch — es muss qspi. Hier ein Versuch zum Draufsetzen, aber ehrlich UNGETESTET (wir haben kein N16R8, und ob der aktuelle C5-Core die 8 MB Quad-PSRAM sauber hochzieht, ist selbst offen):

[env:c5-16mb]           ; UNGETESTET — guess fuer C5 N16R8 (16 MB Flash + 8 MB PSRAM)
extends = common
board = esp32-c5-devkitc1-n4
board_upload.flash_size = 16MB
board_build.partitions = partitions.csv          ; 16-MB-Layout, wie env:s3
board_build.filesystem = littlefs
; C5-PSRAM = QUAD-SPI (NICHT Octal wie S3!) -> qspi, nicht opi:
board_build.arduino.memory_type = qio_qspi
board_build.psram_type = qspi
build_flags =
    ${common.build_flags}
    -D ARDUINO_USB_MODE=1
    -D ARDUINO_USB_CDC_ON_BOOT=1
    -D BOARD_HAS_PSRAM
    -D SIXBACK_SPOTIFY_ENABLED=1
    -D SIXBACK_OTA_ENABLED=1
    -D SIXBACK_OTA_PREFIX='"sixback-c5-"'

Wenn der Boot damit durchläuft: der serielle Backtrace direkt nach einem Reboot sagt sofort, ob es noch am PSRAM/Heap hängt. Und falls es weiter zickt, ist Weg 1 der verlässliche.

Ehrliche Erwartung in beiden Fällen: selbst ohne Boot-Schleife kann der 5-GHz-Connect noch an dieselbe Wand laufen wie bei uns (ein C5 verbindet sauber, ein anderer bekommt trotz gutem Empfang reproduzierbar keinen AP). Aber du kommst damit erstmal sauber bis zum eigentlichen WLAN-Test.

Gruß

Ein Stück weiter bin ich inzwischen.
Ich habe den Abschnitt vom simplen ESP32 kopiert und angepasst.

[env:c5]
extends = common
board = esp32-c5-devkitc1-n4
board_build.partitions = partitions-4mb.csv
board_build.filesystem = littlefs
board_upload.flash_size = 4MB
; FS-Image filtern: silence.mp3 (Spotify-only, ~120KB) raus, sonst sprengt das
; data/-Payload (244KB) das 256KB-spiffs der 4mb-OTA-Tabelle -> LFS_ERR_NOSPC.
; Classic hat kein Spotify, braucht silence.mp3 nicht. version_bump.py bleibt.
extra_scripts =
    ${common.extra_scripts}
    pre:scripts/fs_exclude_esp32.py
build_flags =
    ${common.build_flags}
    ; ESP32-classic behaelt A/B-OTA (1.81MB Slots reichen)
    -D SIXBACK_OTA_ENABLED=1

Damit komme ich bis hierhin:

14:27:32.527 >
14:27:32.527 > =========================================
14:27:32.527 >   SixBack 0.8.27+1700
14:27:32.527 >   Build: 2026-07-01 14:23:31
14:27:32.527 >   Copyright (c) 2026 Dirk Tostmann
14:27:32.539 >   License: PolyForm Noncommercial 1.0.0
14:27:32.539 >   Commercial use prohibited — see LICENSE
14:27:32.539 > =========================================
14:27:32.550 > [mbedtls] PSRAM not available — keeping default internal allocator
14:27:32.550 > [fs]   LittleFS mounted, 8192/262144 bytes used
14:27:32.550 > [   549][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.580 > [   584][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.590 > [uiauth] web-UI password protection disabled
14:27:32.590 > [   590][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.601 > [   600][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:32.601 > [improv] starting (idle-window 120s, no NVS-creds present)
14:27:33.255 > [  1259][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
14:27:33.261 > [provision] improv-exclusive window 10s (no captive yet)
14:27:43.266 > [captive] starting open AP 'SixBack-007F94' + DNS + HTTP on 192.168.4.1
14:27:43.266 > [provision] no NVS connect — waiting on improv OR captive

Das sixback-WLAN ist da, das Portal kommt, aber das war es dann auch.
Der Scan liefert kein Ergebnis, ein manuelles Eintragen der Daten auf der Portalseite funktioniert auch nicht.
Es kommt immer noch die vom watchdog ausgelöste Reboot-Schleife.

14:27:10.658 > [captive] starting open AP 'SixBack-007F94' + DNS + HTTP on 192.168.4.1
14:27:10.670 > [provision] no NVS connect — waiting on improv OR captive
14:27:31.101 > E (32670) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
14:27:31.101 > E (32670) task_wdt:  - async_tcp (CPU 0)
14:27:31.112 > E (32670) task_wdt: Tasks currently running:
14:27:31.112 > E (32670) task_wdt: CPU 0: IDLE
14:27:31.112 > E (32670) task_wdt: Aborting.
14:27:31.120 > E (32670) task_wdt: Print CPU 0 (current core) registers

Wie bekommt man das NVS Problem in den Griff?
Müsste das nicht automatisch beim Start formatiert werden, wenn es noch nicht existiert?

Wir haben wohl gerade beide eine Antwort geschrieben...

Zitat von: tostmann am 01 Juli 2026, 14:35:481. Am direktesten: ein nacktes esp32-c5-devkitc1 mit 4 MB / ohne PSRAM (die N4-Variante, ~5-8 EUR). Darauf läuft der github-env:c5 unverändert, die Boot-Schleife ist weg — und dein WLAN-Ergebnis wird 1:1 mit unserem vergleichbar, was uns fürs 5-GHz-Thema am meisten hilft.

Die Idee hatte ich auch schon, aber ich habe noch keine Quelle dafür gefunden. Hast Du eine Quelle für mich, möglichst in Deutschland? (Bei Amazon nicht verfügbar)

Zitat von: tostmann am 01 Juli 2026, 14:35:482. Auf deinem N16R8 bleiben: dafür braucht es ein eigenes Env mit 16-MB-Layout + aktiviertem PSRAM. Wichtig: der C5 hat QUAD-SPI-PSRAM (nicht Octal wie der S3), die opi-/qio_opi-Werte aus unserem s3-8mb wären also falsch — es muss qspi. Hier ein Versuch zum Draufsetzen, aber ehrlich UNGETESTET (wir haben kein N16R8, und ob der aktuelle C5-Core die 8 MB Quad-PSRAM sauber hochzieht, ist selbst offen):

Das werde ich testen, danke.

Zitat von: tostmann am 01 Juli 2026, 14:35:48Ehrliche Erwartung in beiden Fällen: selbst ohne Boot-Schleife kann der 5-GHz-Connect noch an dieselbe Wand laufen wie bei uns (ein C5 verbindet sauber, ein anderer bekommt trotz gutem Empfang reproduzierbar keinen AP). Aber du kommst damit erstmal sauber bis zum eigentlichen WLAN-Test.

Genau darum geht es mir, ich möchte zumindest mal bis zur Möglichkeit kommen, das WLAN überhaupt zu testen. Und dann kann ich weiter forschen.

Zitat von: betateilchen am 01 Juli 2026, 14:41:27Die Idee hatte ich auch schon, aber ich habe noch keine Quelle dafür gefunden. Hast Du eine Quelle für mich, möglichst in Deutschland? (Bei Amazon nicht verfügbar)

Ok, ich habe jetzt bei Aliexpress bestellt.
Versand + Zölle sind seit heute höher als der Artikelpreis...

ich hatte seinerzeit den bestellt:

https://de.aliexpress.com/item/1005010442802432.html

Krass, jetzt 4 Euro teuer ...

ich habe den hier bestellt: https://de.aliexpress.com/item/1005012416463528.html

SixBack v0.8.28 ist raus — ESP32-C5-Support (Dual-Band/5 GHz) + Fixes am WLAN-Setup

Der ESP32-C5 ist ab dieser Version ein offizielles Target: Der Web-Flasher auf https://sixback.io/ erkennt den Chip automatisch, OTA-Kanal inklusive. Verifiziert haben wir auf zwei C5-Boards (die verbreiteten 4-MB/N4-DevKitC-Klone): beide Provisioning-Wege — Captive-Portal und Improv über den Web-Flasher — enden dort in einer 5-GHz-Verbindung, die Zugangsdaten überleben den Reboot.

Beim C5-Testen haben wir auch die Ursache für die hier gemeldete Reboot-Schleife während des Portal-Setups gefunden: Der WLAN-Scan lief bisher blockierend im Webserver-Task. Auf Dual-Band-Chips dauert der Scan über beide Bänder rund 9 Sekunden — das reißt den 5-Sekunden-Task-Watchdog, und der Stick macht einen Panic-Reboot genau in dem Moment, in dem die Setup-Seite lädt (die Seite stößt den Scan automatisch an). Bei jedem neuen Versuch dasselbe. Auf reinen 2,4-GHz-Chips blieb derselbe Code mit ~4 Sekunden knapp unter der Grenze, deshalb ist das erst mit dem C5 aufgefallen. Der Scan läuft jetzt asynchron; auf unseren C5s war der Crash vorher zuverlässig reproduzierbar und tritt seit dem Fix nicht mehr auf.

Weitere Fixes am Setup-Fluss in v0.8.28: Das Portal-Fenster ist jetzt idle-basiert (5 Minuten seit der letzten Interaktion, 30 Minuten Obergrenze) statt eines harten 5-Minuten-Abbruchs, der auch mitten in der Passwort-Eingabe zuschlagen konnte. Ein laufender Verbindungsversuch wird am Fensterende nicht mehr abgebrochen (vorher konnten korrekt eingegebene Zugangsdaten dabei verloren gehen). Nach erfolgreichem Setup startet der Stick einmal neu — vorher konnte die Web-UI auf Port 80 bis zum nächsten Reboot unerreichbar bleiben, was wie ein fehlgeschlagenes Setup aussah, obwohl der Stick längst im WLAN war. Und auf der Improv-Seite: serielle Daten nach Ablauf des Improv-Fensters können ein unprovisioniertes Gerät nicht mehr dauerhaft lahmlegen; es kehrt immer in seinen Setup-Zyklus zurück.

Für alle, die aus den Quellen bauen: Der Verweis auf die Improv-Bibliothek zeigte auf einen Commit, den es im öffentlichen Repo nicht mehr gab — frische Checkouts schlugen deshalb beim Bauen fehl. Ist ebenfalls behoben, ein frisches Clone+Build geht wieder durch.

@betateilchen: Dein N16R8 müsste vom Scan-Fix direkt profitieren — der Crash-Mechanismus ist board-unabhängig, und Dein Fehlerbild (Reboot-Schleife, sobald das Portal bedient wird) passt exakt darauf. Getestet haben wir allerdings nur die 4-MB/N4-Variante; das c5-Build ist auf 4 MB Flash ohne PSRAM ausgelegt und läuft auf größeren Boards im 4-MB-Layout (ein eigenes 16-MB/PSRAM-Target steht noch aus). Wenn Du v0.8.28 auf Deinem Board probierst, wären Deine Ergebnisse sehr willkommen.

Update wie gewohnt: OTA über die Web-UI oder komplett frisch über https://sixback.io/. Die Partitionslayouts sind unverändert, OTA ist also für alle Targets unkritisch. Changelog: https://github.com/tostmann/SixBack/releases/tag/v0.8.28

Super, danke vielmals!

Das ging ja dann doch schneller als erwartet.

Bildschirmfoto 2026-07-03 um 10.13.51.png

Auf den ersten Blick scheint alles zu funktionieren, mal schauen, ob noch irgendwelche Nebeneffekte auftauchen.

Die WLAN-Verbindungsqualität des C5 scheint nicht die allerbeste zu sein, aber dafür kann ja sixback nichts. Bei einem Abstand von unter einem Meter zum Repeater ist ein RSSI von -78dBm eigentlich zu schlecht.

Für mich ist am Wichtigsten, dass ich den 2,4GHz AccessPoint, den ich ausschließlich wegen sixback in Betrieb genommen hatte, nun wieder abbauen kann.


--

Klasse, danke fürs schnelle Testen und die Rückmeldung — freut mich, dass der Extra-AP jetzt wieder wegfallen kann!

Zum RSSI: den liest SixBack nur aus, beeinflussen kann die Firmware ihn nicht. −78 dBm bei unter einem Meter sind allerdings ungewöhnlich niedrig — für die kurze Distanz würde man deutlich mehr erwarten. Da würde ich eher beim Link selbst schauen als beim Board: misst Du zum Repeater (dann ist dessen Uplink/Platzierung der Flaschenhals) oder zur Basis? Unsere beiden baugleichen C5-Testboards liegen im Scan bei ~−55 dBm, insofern ist ein grundsätzlich schwaches C5-5-GHz-Frontend zumindest nicht unser Befund.

Zitat von: tostmann am 03 Juli 2026, 14:24:49Zum RSSI: den liest SixBack nur aus, beeinflussen kann die Firmware ihn nicht.

Das ist mir schon klar.

Inzwischen weiß ich, dass der C5 sich gar nicht zum nahegelegenen Mesh-Repeater im gleichen Raum verbindet, sondern direkt zur Fritzbox. Und da liegen zwei Wände dazwischen, was natürlich bei 5GHz nicht so richtig toll ist. Inzwischen ist der sixback in den Raum zur Fritzbox umgezogen.

Bildschirmfoto 2026-07-03 um 15.27.39.png

Insgesamt erscheint die gesamte Kommunikation zwischen Browser und sixback aktuell sehr hakelig mit sehr langen Aufbauzeiten der Seite im Frontend, zeitweise endet das Laden der Seite überhaupt nicht.



--

Kann es sein, dass es da noch ein Problem beim Persistieren von Einstellungen gibt?
Der Schalter "Auto-Migrate at Boot" wird offenbar nicht gespeichert.
Und beim Button "WiFi factory reset" habe ich den Eindruck, dass der im Moment nicht wie bisher funktioniert.
Zur Neukonfiguration des WiFi musste ich sixback neu flashen, da ich keine andere Möglichkeit gefunden habe, das zurückzusetzen.

Danke für die detaillierten Rückmeldungen — ich habe die drei Punkte (Auto-Migrate speichert nicht, WiFi factory reset, hakelige WebUI) hier auf zwei C5-Boards nachgestellt.

Ergebnis vorweg: Auf einem frisch geflashten v0.8.28 kann ich keinen der drei Punkte reproduzieren. Der Auto-Migrate-Schalter übersteht den Reboot, der WiFi-Factory-Reset löscht die Zugangsdaten sauber und das Gerät kommt danach zuverlässig mit dem Setup-AP hoch (Portal lädt, neu einrichten klappt), und die WebUI bleibt flüssig. Der freie Heap war über eine Viertelstunde unter Last stabil bei rund 60 KB, kein Leck.

Was ich anfangs für einen Bug hielt, trat nur auf einem Board auf, das ich zuvor durch sehr viele Provisioning-Zyklen in einen instabilen Zustand gefahren hatte (mehrere Abstürze, Heap fast leer). Nach einem sauberen Neu-Flash war genau dieses Board wieder völlig unauffällig und macht alles korrekt.

Deshalb der Verdacht: Dein Gerät ist in einen ähnlichen degradierten Zustand geraten. Zwei Dinge würden helfen, das einzugrenzen:

- Ruf einmal http://<IP-des-Sticks>/api/status auf und poste den "health"-Block daraus (crash_count, boot_count, uptime_s und die heap-Werte free/min_free). Daran sieht man sofort, ob das Gerät im Hintergrund abstürzt.
- Ein sauberer Neu-Flash über den Web-Flasher (mit "erase") sollte den Zustand zurücksetzen. Danach würde mich interessieren, ob die Punkte weg sind.

Noch ein separater Punkt, unabhängig von deinen drei Beobachtungen: Auf dem C5 funktioniert das Selbst-Update per OTA nicht. Der Chip hat für den verschlüsselten Download schlicht zu wenig RAM — er hat kein PSRAM, und der Dual-Band-WLAN-Stack belegt spürbar mehr Speicher als bei den 2,4-GHz-Chips. Der TLS-Handshake scheitert dann an der Speicherreservierung. Auf dem C5 bitte Updates daher ausschließlich über den Web-Flasher (sixback.io) einspielen; die anderen Chips (C3/C6/S3/ESP32) sind davon nicht betroffen. Das nächste Update zeigt auf dem C5 auch einen klaren Hinweis darauf an, statt einer kryptischen Fehlermeldung.

Zitat von: tostmann am 03 Juli 2026, 19:00:12- Ruf einmal http://<IP-des-Sticks>/api/status auf und poste den "health"-Block daraus (crash_count, boot_count, uptime_s und die heap-Werte free/min_free). Daran sieht man sofort, ob das Gerät im Hintergrund abstürzt.

{"name":"SixBack","version":"0.8.28","build":"2026-07-03 02:09:53","license":"PolyForm-Noncommercial-1.0.0","copyright":"Copyright (c) 2026 Dirk Tostmann","uptime_s":13811,
"wifi":{"connected":true,"ssid":"mowg","ip":"192.168.123.44","rssi":-39,"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":49480,"min_free":2320,"total":258240},"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.44:8000"},"speakers_count":4,"scan_in_progress":false,
"health":{"boot_count":3,"crash_count":0,"wifi_reboots":0,"heap_reboots":0,"last_reset":"POWERON","wdt_subscribed":true,"wifi_down_for_s":0,"heap_low_for_s":0,"last_ping_age_s":10}}


Zitat von: tostmann am 03 Juli 2026, 19:00:12- Ein sauberer Neu-Flash über den Web-Flasher (mit "erase") sollte den Zustand zurücksetzen. Danach würde mich interessieren, ob die Punkte weg sind.

Das habe ich schon zweimal gemacht, auch das erste Flashen des C5 wurde ja über den Web-Flasher durchgeführt.

Nach dem Aufruf von sixback.local sieht das bei mir erstmal so aus:

Bildschirmfoto 2026-07-03 um 17.51.09.png

Das Laden der Seite wird nicht abgeschlossen, deshalb werden die Lautsprecher nicht angezeigt.
Manchmal passiert aber auch gar nix und die Seite bleibt einfach leer, weil das Laden der Seite zu keinem Ende kommt.


Die Boxen selbst scheinen aber bisher problemlos zu laufen.



--

Hallo betateilchen,

kurzes Update: den nicht speichernden Schalter "Auto-Migrate at Boot" habe ich gefunden und gefixt. Ursache war ein Bug im Endpoint /api/auto-mode — er hat der Weboberfläche "gespeichert" gemeldet, auch wenn das Schreiben in den internen Speicher (NVS) fehlschlug. Die Oberfläche zeigte den neuen Zustand, gespeichert war aber nichts, und weil sie direkt danach den echten Stand neu einliest, ist der Schalter wieder zurückgesprungen — genau dein Symptom.

Gefixt in v0.8.29: der Endpoint schreibt jetzt robuster (räumt bei vollem NVS erst regenerierbare Caches frei und schreibt erneut) und meldet einen Fehlschlag ehrlich, statt falschen Erfolg zu melden. Ich habe es auf einem frisch gelöschten C5 nachgestellt und verifiziert — der Schalter überlebt jetzt einen Reboot.

Dein WLAN war übrigens nicht die Ursache: der 5-GHz-Empfang in deinem Status-Dump war einwandfrei.

Sobald v0.8.29 auf sixback.io liegt, einmal updaten und gegentesten wäre super. Falls es dann wider Erwarten immer noch nicht hält, bekommst du jetzt eine sichtbare Fehlermeldung statt eines stillen Fehlschlags — dann poste bitte einmal die Ausgabe von /api/nvs/stats, damit wir sehen ob der NVS voll ist. Danke fürs Melden!

Moin,

zuerstmal vielen Dank für Dein Engagement. Aber ich erwarte grundsätzlich nicht, dass Probleme mitten in der Nacht gelöst werden :)

Zum Thema 0.8.29:

Die Version habe ich über den Webflasher und den Update-Button auf den C5 gebracht. Das lief auch alles prima und ohne Auffälligkeiten durch.
Aber danach tauchte der C5 nie wieder in meinem WLAN auf...

Dann habe ich ein "Fresh Install" gemacht und konnte danach zumindest das WLAN wieder konfigurieren. Wobei mir dabei wieder aufgefallen ist, dass bereits seit 0.8.28 das Verhalten ein anderes ist als vorher. Vor der C5-Integration kam direkt nach dem Flashen des "Fresh Install" ein Folge-Menü, in dem man WLAN konfigurieren konnte. Das kommt nun nicht mehr. Die einzige Zugangsmöglichkeit ist das sixback-WLAN, das der C5 nach einer jungfräulichen Installation aufbaut. Aus dem Webflasher heraus habe ich keine Möglichkeit mehr, den ESP32 zu konfigurieren.

Der Aufruf von sixback.local hakt nach wie vor. Mir werden beispielsweise keine presets bei den vier gefundenen Boxen angezeigt. Auch lassen sich jetzt - nach dem Fresh Install - noch keine presets auf den Boxen abspielen.

Bildschirmfoto 2026-07-04 um 11.24.07.png

Vielleicht greifen hier die bisher üblichen "Selbstheilungskräfte" von sixback und ich warte jetzt einfach mal eine halbe Stunde ab.

Alles in allem scheint das 5GHz Thema noch nicht so weit zu sein, dass man damit wirklich "werben" sollte. Aber das war uns ja vorab schon bewusst und ich will mich deswegen auch überhaupt nicht beschweren. Vielleicht kommt es auch wirklich daher, dass wir verschiedene C5-Boards einsetzen, ich bin gespannt wie es sich entwickelt, wenn ich mein C5-N4 bekommen habe.

Zitat von: tostmann am 04 Juli 2026, 02:39:44poste bitte einmal die Ausgabe von /api/nvs/stats, damit wir sehen ob der NVS voll ist.

{"used_entries":274,"free_entries":356,"total_entries":630,"namespace_count":9,"percent_used":43.49206}
Insofern: erstmal schönes Wochenende, mach Dir bitte keinen unnötigen Streß wegen sixback.
Im allerschlimmsten Fall fahre ich den 2,4GHz AccessPoint wieder hoch...

---- Edit:

Inzwischen (nach dem Verfassen dieses Beitrags) sind auch die presets wieder vorhanden.


--

Nun habe ich mich mit den WLAN Problemen beschäftigt und habe parallel ein ping auf sixback laufen lassen.

Bildschirmfoto 2026-07-04 um 12.18.25.png

Bei seq=213 habe ich sixback.local aufgerufen.
Das führt dazu, dass die WLAN Verbindung abreißt und sixback.local nicht mehr erreichbar ist.
In Folge kann natürlich auch die Webseite nicht mehr vollständig geladen werden.

Nach einiger Zeit wechselt die Rückmeldung dann von "request timeout" zu "Host is down".

Bildschirmfoto 2026-07-04 um 12.11.33.png

Noch ein paar Minuten später wird dann die WLAN Verbindung wieder hergestellt.

Bildschirmfoto 2026-07-04 um 12.13.07.png

Jetzt wird es richtig spannend:

• Ein reload der Seite "sixback.local" im ursprünglich geöffneten Tab führt jetzt NICHT zum Verlust der WLAN Verbindung.
• Das Öffnen der Seite "sixback.local" in einem neuen Tab führt reproduzierbar zum Abbruch der WLAN Verbindung.

Zitat von: betateilchen am 04 Juli 2026, 11:29:39Im allerschlimmsten Fall fahre ich den 2,4GHz AccessPoint wieder hoch...

Heute war es soweit.

Nachdem eine meiner Boxen keine presets mehr kannte und wegen der WLAN-Problematik auch nicht mehr konfiguriert werden konnte, habe ich meinen S3 wieder am 2,4GHz AP in Betrieb genommen, aktuell noch mit 0.8.27

ich arbeite aktuell wenn Zeit ist weiter daran, aber ehrlich: Bei dem Umfang welchen SixBack mittlerweile hat ist "S" wie Server-Klasse auch eher angemessen ... Was sich schon klarer abzeichnet ist der sehr knappe HEAP des C5 - weniger RAM + mehr WLAN == keine gute Kombi.

Wie gesagt: Mach Dir keinen Streß.

Meine Hoffnung ist, dass es irgendwann vielleicht auch mit dem C-Type klappt.
Bei N16R8 (auch wenn es das derzeit noch nicht als target gibt) sollten doch die Speicherbedingungen vergleichbar mit dem S3-N16R8 sein oder habe ich da etwas mißverstanden?