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?

Hallo, habe heute versucht einen ESP32 S3 zu flashen. Sixback.io aufgerufen und ESP32 S3 Neuinstallation ausgewählt
und die Installation auf Com8 USB Serial CH343, läuft erst erasing, dann installing, dann 2 min warten und der Zähler läuft hoch.
Nach Installation complete! und next bin ich wieder im Installationsmenue mit

SixBack (S3 8MB)
Installieren Sie SixBack (S3 8MB)
Protokolle & Konsole

Rufe ich die Seite http://sixback.local/ im Chromebrowser auf, kommt nichts, die Webseite ist nicht erreichbar.
Bei Protokolle und Gerät zurücksetzen kommen folgende Meldungen
[10:59:51]ESP-ROM:esp32s3-20210327
[10:59:51]Build:Mar 27 2021
[10:59:51]rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
[10:59:51]SPIWP:0xee
[10:59:51]mode:DIO, clock div:1
[10:59:51]load:0x3fce2820,len:0x10cc
[10:59:51]load:0x403c8700,len:0xc2c
[10:59:51]load:0x403cb700,len:0x30c0
[10:59:51]entry 0x403c88b8
[10:59:52][   536][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
[10:59:52][   573][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
[10:59:52][   579][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
[10:59:52][   585][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
[10:59:52][   643][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND

Wo muss ich suchen?
Beste Grüße

Schau mal nach, ob es in Deiner Umgebung nach einem reboot des S3 ein offenes WLAN mit dem Namen "sixback-xxxxxx" gibt. Wenn ja, damit verbinden, dann kannst Du die Verbindung des S3 zu Deinem eigenen WLAN konfigurieren.

Hallo erwin23,

das S3-DevKitC hat zwei USB-Buchsen: eine mit UART beschriftet (CH340/CH343), eine native USB. Der "Connect device to Wi-Fi"-Schritt im Browser erscheint nur beim Flashen über die UART-Buchse — über die native USB-Buchse fehlt er (genau Dein Symptom).

Dein "CH343" wäre eigentlich die richtige Buchse. Kannst Du kurz nachsehen, in welche der beiden Du physisch gesteckt hast?

Sofort läuft es so: der Stick macht nach dem Flashen ein WLAN "SixBack-..." auf — damit verbinden, im Portal Dein WLAN eintragen, fertig. Die "nvs_open NOT_FOUND"-Zeilen sind übrigens normal, kein Fehler.

Danke für euren schnellen Antworten.
Hatte das mit dem das mit dem Sixback Wlan übersehen, Jetzt geht es.
Besten Dank an euch beiden

PS: könnte man nicht auch die Temperatur neben der Versionsnummer anzeigen? Mein ESP war im Gehäuse gut warm.

Zitat von: tostmann am 07 Juli 2026, 14:40:22das S3-DevKitC hat zwei USB-Buchsen: eine mit UART beschriftet (CH340/CH343), eine native USB. Der "Connect device to Wi-Fi"-Schritt im Browser erscheint nur beim Flashen über die UART-Buchse — über die native USB-Buchse fehlt er (genau Dein Symptom).

Hallo Dirk,

sowohl die C5-Devkits als auch die C6-Devkits, die ich hier habe, besitzen ebenfalls zwei USB-Buchsen, die wie von Dir beschrieben bezeichnet sind.

Aber die Option "Connect device to WiFi" kommt bei keinem dieser Boards, egal über welchen port ich das DevKit flashe. Meines Erachtens ist das aber ein neues Verhalten, das mir erst seit den Versuchen mit dem neuen C5-target so aufgefallen ist.

Gerade getestet: bei meinem S3-DevKit kommt die Option "Connect device to WiFi" nach dem Neuflashen auch nicht mehr. (dort kam die Option früher immer zuverlässig)

In allen beschriebenen Fällen taucht die Meldung auch später nicht auf, wenn man das DevKit nochmal mit sixback.io verbindet. Bisher kam dann immer ein längeres Menü, in dem man das Board konfigurieren oder die Oberfläche aufrufen konnte - alles weg.

Hallo betateilchen,

magst Du kurz einen isolierten Test fahren? Drei Flasher-Varianten, die dasselbe S3-Binary flashen und sich nur im Manifest unterscheiden:

https://sixback.io/improv-test/

A = nur ESP32-S3 im Manifest, C = wie Produktion (5 Builds inkl. ESP32-C5), D = 4 Builds ohne C5. Bitte alle drei an einem S3 (über die UART-Buchse, "Erase device") durchspielen und je notieren, ob nach "Installation complete" der Schritt "Connect device to Wi-Fi" kommt.

Bei mir kamen alle drei sauber ins WLAN-Menü. Fehlt es bei Dir schon bei A, liegt es an Deiner Umgebung — dann bitte einmal in einem Inkognito-/frischen Browser-Profil gegentesten. Geht A, aber C nicht, ist es das Manifest mit dem C5-Eintrag. Wenn möglich im Dialog "Logs & Console" offen lassen.

Danke!

Ich werde testen und berichten.

Testumgebung: macbook neo, neu installierter Browser Chrome (bisher hatte ich auf dieser Hardware noch nichts mit sixback gemacht)

A: kein Menü
C: kein Menü
D: kein Menü

Das mit dem offenlassen von "Logs & Console" habe ich nicht geschafft. Das ist irgendwie ein exklusives Fenster, das ich weder auf dem Desktop verschieben noch parallel benutzen kann.

Es wird nach dem Flashen auch kein sixback-xxxxxx WLAN aufgemacht, das passiert erst nach dem nächsten reboot des ESP32.

Gegenvorschlag: können wir den Test mit einer 0.8.27 wiederholen (um unabhängig von der C5-Frage zu testen)?

[01:55:34]E (306) esp_image: Checksum failed. Calculated 0x4e read 0x6
[01:55:34]E (306) boot: OTA app partition slot 0 is not bootable
[01:55:34]E (306) esp_image: image at 0x310000 has invalid magic byte (nothing flashed here?)
[01:55:34]E (312) boot: OTA app partition slot 1 is not bootable
[01:55:34]E (317) boot: No bootable app partitions in the partition table
[01:55:34]ESP-ROM:esp32s3-20210327
[01:55:34]Build:Mar 27 2021
[01:55:34]rst:0x3 (RTC_SW_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
[01:55:34]Saved PC:0x403cd0e9
[01:55:34]SPIWP:0xee
[01:55:34]mode:DIO, clock div:1
[01:55:34]load:0x3fce2820,len:0x10cc
[01:55:34]load:0x403c8700,len:0xc2c
[01:55:34]load:0x403cb700,len:0x30c0
[01:55:34]entry 0x403c88b8
[01:55:34]E (306) esp_image: Checksum failed. Calculated 0xa9 read 0x6
[01:55:34]E (306) boot: OTA app partition slot 0 is not bootable
[01:55:34]E (306) esp_image: image at 0x310000 has invalid magic byte (nothing flashed here?)
[01:55:34]E (312) boot: OTA app partition slot 1 is not bootable
[01:55:34]E (317) boot: No bootable app partitions in the partition table


Hab jetzt den 2. Sixback fertig gemacht. Es kommt ein Lautsprecher zu mir ins Büro, anderes WLAN, Netzwerk, usw.
Deshalb ein 2. Sixback auf ESP32 S3 16MB.

Der kommt hinten an den Lautsprecher mit nano tape dran.

Heute kam mein C5 mit 4MB hier an. sixback .30 drauf, hat problemlos geklappt (ausgenommen der fehlende Schritt mit der WLAN Verbindung)

Die Seite sixback.local scheint damit problemlos erreichbar zu bleiben, der WLAN Verlust tritt hier aktuell nicht auf.
Heute oder morgen werde ich die Version .30 noch auf meinem anderen C5 Board (N16R8) testen.

Danke für das Update!


--

Zitat von: betateilchen am 11 Juli 2026, 16:17:42Heute oder morgen werde ich die Version .30 noch auf meinem anderen C5 Board (N16R8) testen.

Auf dem N16R8 hat sich mit der Version .30 nichts am Verlust der WLAN Verbindung geändert, sobald man sixback.local aufruft.

In den letzten Tagen hatte ich mich mit dem Zustand dahingehend arrangiert, dass sixback mit meinen 4 Boxen problemlos lief, solange man darauf verzichtet hat, das WebUI aufzurufen.

Mit der heutigen Erkenntnis bezüglich der 4MB-Variante werde ich jetzt mal diese Konstellation im Dauerbetrieb testen und schauen, ob das stabil läuft, auch wenn man das Frontend aufruft. Bisher sieht es jedenfalls gut aus.

Hier auf einem N16R8 (v0.8.30) kriege ich den Abriss nicht nachgestellt — WebUI mehrfach und parallel geöffnet, WLAN blieb stabil. Um deinen Fall einzugrenzen, brauche ich /api/status vom betroffenen Stick (harmlos, fragt keine Boxen ab): einmal frisch nach Neustart vor dem WebUI-Aufruf, einmal direkt nachdem die Verbindung wieder da ist.

Steigen zwischen den beiden wifi_reboots oder boot_count, ist der Stick durchgestartet — sonst nur kurz die WLAN-Anmeldung weg. Dazu aus demselben Status rssi und speakers_count, und: waren die Boxen am Spielen oder im Standby? Danke!

Wo sind meine Lautsprecher?  :o

Bildschirmfoto 2026-07-12 um 09.08.19.png

{"name":"SixBack","version":"0.8.30","build":"2026-07-08 13:05:14","license":"PolyForm-Noncommercial-1.0.0","copyright":"Copyright (c) 2026 Dirk Tostmann","uptime_s":48990,"wifi":{"connected":true,"ssid":"mowg","ip":"192.168.123.44","rssi":-73,"channel":40,"band":"5GHz","mac":"D0:CF:13:EB:70:C4","hostname":"sixback.local","improv_active":false,"improv_window_s":0,"captive_active":false,"captive_window_s":0},"heap":{"free":61508,"min_free":2168,"total":258224},"psram":{"free":0,"total":0},"chip":{"model":"ESP32-C5","cores":1,"revision":100,"flash_size":4194304},"cloud_replacement":{"port":8000,"base_url":"http://192.168.123.44:8000"},"speakers_count":4,"scan_in_progress":false,"groups_persist_ok":true,"health":{"boot_count":5,"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":86}}


Danke — aber der Dump ist von der falschen Box: das ist dein 4-MB-C5 (chip.flash_size 4 MB, psram 0), nicht der N16R8, der abreißt. Und dieser C5 reißt gar nicht ab: uptime 13,6 h, boot_count/wifi_reboots/crash_count = 5/0/0. Deine Boxen sind auch nicht weg (speakers_count 4), nur die Kacheln laden nicht fertig — bei so knappem Heap (dein min_free war auf 2168 Byte runter) drosselt SixBack die parallelen Box-Abfragen, damit das WLAN stehen bleibt. Kommen sie nach "Refresh status"/Reload doch?

Für den Abriss brauche ich den kompletten /api/status vom N16R8, zweimal: frisch nach Boot (vor WebUI) und direkt nach dem Reconnect. Daran sehe ich, ob boot_count/wifi_reboots steigen (Reboot) oder gleich bleiben (nur WLAN weg) — und was der N16R8 unter "psram" meldet. (Mein Gegentest neulich lief übrigens auf einem S3-N16R8 — dein N16R8 ist ja ein C5, insofern war das kein 1:1-Vergleich.)

Dass das nicht der N16R8 war, ist mir schon klar.
Im Moment habe ich den N16R8 gar nicht in Betrieb, den muss ich erstmal in ein anderes WLAN bringen, damit er mir den Betrieb nicht durcheinander bringt.

Zitat von: tostmann am 12 Juli 2026, 10:32:19Kommen sie nach "Refresh status"/Reload doch?

Ja, irgendwann sind die Kacheln der Boxen wieder vorhanden.

Zitat von: tostmann am 12 Juli 2026, 10:32:19Für den Abriss brauche ich den kompletten /api/status vom N16R8, zweimal: frisch nach Boot (vor WebUI) und direkt nach dem Reconnect. Daran sehe ich, ob boot_count/wifi_reboots steigen (Reboot) oder gleich bleiben (nur WLAN weg) — und was der N16R8 unter "psram" meldet.

Bekommst Du, sobald ich ihn wieder in Betrieb habe.

Im Moment läßt sich der WLAN-Verlust auf dem N16R8 nicht mehr reproduzieren.

Hier noch zwei Datensätze, den dritten (nach reconnect) kann ich im Moment nicht erzeugen.

Direkt nach Start, ohne bekannte Lautsprecher

{
  "name": "SixBack",
  "version": "0.8.30",
  "build": "2026-07-08 13:05:14",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 4,
  "wifi": {
    "connected": true,
    "ssid": "mowg",
    "ip": "192.168.123.46",
    "rssi": -86,
    "channel": 40,
    "band": "5GHz",
    "mac": "38:44:BE:00:7F:94",
    "hostname": "sixback.local",
    "improv_active": true,
    "improv_window_s": 27,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 80200,
    "min_free": 77488,
    "total": 258224
  },
  "psram": {
    "free": 0,
    "total": 0
  },
  "chip": {
    "model": "ESP32-C5",
    "cores": 1,
    "revision": 100,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.46:8000"
  },
  "speakers_count": 0,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "health": {
    "boot_count": 2,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "last_ping_age_s": -1
  }
}

Direkt nach Start, nach erfolgter Migration

{
  "name": "SixBack",
  "version": "0.8.30",
  "build": "2026-07-08 13:05:14",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 21,
  "wifi": {
    "connected": true,
    "ssid": "mowg",
    "ip": "192.168.123.46",
    "rssi": -77,
    "channel": 40,
    "band": "5GHz",
    "mac": "38:44:BE:00:7F:94",
    "hostname": "sixback.local",
    "improv_active": true,
    "improv_window_s": 11,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 69320,
    "min_free": 42104,
    "total": 258224
  },
  "psram": {
    "free": 0,
    "total": 0
  },
  "chip": {
    "model": "ESP32-C5",
    "cores": 1,
    "revision": 100,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.46:8000"
  },
  "speakers_count": 4,
  "scan_in_progress": true,
  "groups_persist_ok": true,
  "health": {
    "boot_count": 3,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "last_ping_age_s": -1
  }
}


Danke Dir für die beiden Dumps!

Beide sind allerdings direkt nach dem Boot entstanden (uptime 4 bzw. 21 s, Improv-Fenster noch offen) — da ist der WLAN-Abriss ja noch gar nicht passiert; die Zähler sind entsprechend sauber (crash_count 0, wifi_reboots 0, last_reset SW).

Zur Einordnung des psram-Feldes, bevor die Frage kommt: die aktuelle C5-Firmware ist ohne PSRAM gebaut, daher meldet sie auf jedem C5 psram 0 — auch auf einem R8-Board. Der nutzbare Heap (total ~258 KB) ist damit derselbe wie beim N4; das psram 0 ist also kein Fehler und kein Board-Symptom.

Was die Eingrenzung wirklich weiterbringt, ist der eine Datensatz unmittelbar nach dem Reconnect nach so einem Drop: am boot_count bzw. wifi_reboots sieht man dann, ob der Stick beim Öffnen der WebUI neu startet oder ob nur die WLAN-Assoziation kurz wegbricht (ohne Reboot) — das sind zwei ganz verschiedene Ursachen. Kein Stress, nur falls/sobald Du den Drop wieder reproduzieren kannst.

Zitat von: tostmann am 13 Juli 2026, 12:06:07nach so einem Drop: am boot_count bzw. wifi_reboots sieht man dann, ob der Stick beim Öffnen der WebUI neu startet oder ob nur die WLAN-Assoziation kurz wegbricht (ohne Reboot)

Das kann ich Dir auch so beantworten (zumindest für 0.8.29):
Der Stick bootet zu diesem Zeitpunkt nicht neu, er verliert "nur" die Verbindung zum WLAN.
Und das nicht nur kurz, sondern für mehrere Minuten.

Würde der Stick neu booten, würde er nach ein paar Sekunden die Verbindung zum WLAN neu aufbauen. Das passiert aber nicht. In meinem "ping-Protokoll" weiter oben sieht man den zeitlichen Verlauf.

Danke — dann ist es ein reiner WLAN-Abriss ohne Reboot (deckt sich mit CRASH_COUNT und WIFI_REBOOTS = 0).

v0.8.31 ist raus: /api/status hat jetzt WIFI_DISCONNECTS und LAST_WIFI_DOWN_S, und der Watchdog erkennt jetzt auch den Fall "verbunden gemeldet, aber 0.0.0.0" (verlorene DHCP-Lease). Aktualisieren über den Update existing-Button auf sixback.io (hält die Einstellungen) — nicht über das WebUI-Selbstupdate, das kann auf dem C5 am knappen Speicher scheitern.

Zwei Fragen:

1. Kommt die Verbindung nach den paar Minuten von allein zurück, oder musst Du den Stick stromlos machen?
2. Kannst Du den N16R8 mal an einem 2,4-GHz-AP mit demselben Test laufen lassen? Dein RSSI von −86 bzw. −77 dBm auf 5 GHz ist grenzwertig — das trennt Funkstrecke von Firmware.

Danach nach dem nächsten Drop einmal /api/status — dann sehen wir, ob und wie lange der Abriss erkannt wurde.

Zitat von: tostmann am 13 Juli 2026, 18:01:37Zwei Fragen:

1. Kommt die Verbindung nach den paar Minuten von allein zurück, oder musst Du den Stick stromlos machen?
2. Kannst Du den N16R8 mal an einem 2,4-GHz-AP mit demselben Test laufen lassen? Dein RSSI von −86 bzw. −77 dBm auf 5 GHz ist grenzwertig — das trennt Funkstrecke von Firmware.

Zu 1: die Verbindung kommt ohne mein Zutun wieder zustande.

Zu 2: kann ich machen. Aber das rssi ist nicht immer so schlecht. Aktuell liegt es bei -46, siehe Screenshot.

Bildschirmfoto 2026-07-13 um 19.34.22.png

Und gerade eben ist die WLAN Verbindung wieder abgerissen - noch vor einem Update.

udo@bac19a54-df62-4c97-97bb-58c955353790 ~ % ping 192.168.123.46
PING 192.168.123.46 (192.168.123.46): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
ping: sendto: No route to host
Request timeout for icmp_seq 7
ping: sendto: Host is down
Request timeout for icmp_seq 8
ping: sendto: Host is down
Request timeout for icmp_seq 9
ping: sendto: Host is down
Request timeout for icmp_seq 10
ping: sendto: Host is down
Request timeout for icmp_seq 11
ping: sendto: Host is down
Request timeout for icmp_seq 12
ping: sendto: Host is down
Request timeout for icmp_seq 13
ping: sendto: Host is down
Request timeout for icmp_seq 14
ping: sendto: Host is down
Request timeout for icmp_seq 15
ping: sendto: Host is down
Request timeout for icmp_seq 16
ping: sendto: Host is down
Request timeout for icmp_seq 17
ping: sendto: Host is down
Request timeout for icmp_seq 18
ping: sendto: Host is down
Request timeout for icmp_seq 19
ping: sendto: Host is down
Request timeout for icmp_seq 20
ping: sendto: Host is down
Request timeout for icmp_seq 21
64 bytes from 192.168.123.46: icmp_seq=3 ttl=64 time=19327.138 ms
64 bytes from 192.168.123.46: icmp_seq=4 ttl=64 time=18322.339 ms
64 bytes from 192.168.123.46: icmp_seq=5 ttl=64 time=17317.160 ms

Interessant ist, dass die seq=3 bis seq=5 nach ziemlich genau der Zeit zurückkommen, die der ESP nicht erreichbar war.

Hier der Status nach dem reconnect, anhand der uptime würde ich interpretieren, dass kein reboot stattgefunden hat.

{"name":"SixBack","version":"0.8.30","build":"2026-07-08 13:05:14","license":"PolyForm-Noncommercial-1.0.0","copyright":"Copyright (c) 2026 Dirk Tostmann","uptime_s":29636,"wifi":{"connected":true,"ssid":"mowg","ip":"192.168.123.46","rssi":-47,"channel":36,"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":63268,"min_free":2392,"total":258224},"psram":{"free":0,"total":0},"chip":{"model":"ESP32-C5","cores":1,"revision":100,"flash_size":16777216},"cloud_replacement":{"port":8000,"base_url":"http://192.168.123.46:8000"},"speakers_count":4,"scan_in_progress":false,"groups_persist_ok":true,"health":{"boot_count":4,"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":125}}


Update auf .31 mache ich später.

Danke für die vielen Dumps und die Geduld beim Debuggen — damit ließ sich das Problem sauber einkreisen.

Wir haben den WLAN-Abriss im Labor auf einem C5 nachgestellt und die Ursache gefunden: beim Öffnen des WebUIs fragt der Browser alle konfigurierten Boxen parallel ab, und eine langsam oder im Standby antwortende Box hält den kleinen Webserver sekundenlang fest. Unter dieser Last läuft dem C5 der Arbeitsspeicher aus. Wird der Heap zu knapp, kann der WLAN-Stack keine Puffer mehr anlegen — die Box bleibt zwar am AP assoziiert (kein Neustart, CRASH_COUNT und WIFI_REBOOTS bleiben 0, deckt sich mit deinen Dumps), reagiert aber minutenlang nicht mehr.

Der entscheidende Punkt: das trifft ausgerechnet den C5, weil er von allen ESP32-Varianten, die wir unterstützen, das kleinste RAM hat (C5 384 KB SRAM, C6 512 KB, der S3 zusätzlich PSRAM). Denselben Test haben wir 1:1 auf einem C6 und einem S3 gefahren — dort bleibt die Box durchgehend erreichbar, kein Abriss. Es ist also kein grundsätzliches SixBack-Problem, sondern die RAM-Grenze genau dieses Chips.

Dazu kommt ein zweites, unabhängiges Ärgernis: der C5 ist auch beim Flashen und Wiederherstellen unzuverlässig — er findet nicht verlässlich in den Bootloader zurück, was das Handling für normale Nutzer zusätzlich heikel macht.

Aus beiden Gründen sehen wir den C5 nicht länger als Ziel-Plattform für SixBack und raten davon ab. Empfehlung ist ein Mainline-Board — am robustesten ein S3 (mit PSRAM), alternativ ein C6. Auf beiden läuft der WebUI-Betrieb auch unter Last ohne Verbindungsabriss.

Ein allgemeiner Fix reitet im nächsten Release trotzdem mit (kürzere Timeouts, wenn eine Box nicht antwortet, plus etwas Caching der Box-Abfragen) — der macht das WebUI auf allen Boards unter Last flüssiger, den C5 rettet er aber nicht vor seinem RAM-Limit.

Zitat von: tostmann am 14 Juli 2026, 01:43:39das trifft ausgerechnet den C5, weil er von allen ESP32-Varianten, die wir unterstützen, das kleinste RAM hat (C5 384 KB SRAM, C6 512 KB, der S3 zusätzlich PSRAM).

Naja, mein C5 N16R8 hat ja auch PSRAM - könnte das nicht das Problem zumindest lindern, wenn man den Speicher mitnutzt? (nur für mein Verständnis gefragt)

Zitat von: tostmann am 14 Juli 2026, 01:43:39Aus beiden Gründen sehen wir den C5 nicht länger als Ziel-Plattform für SixBack und raten davon ab.

Ok, davon abzuraten ist ja ok. Aber wird es weiterhin C5 als Target bei updates geben, damit ich meinen sixback zumindest weiter betreiben kann? Solange ich damit lebe, das WebUI nicht aufzurufen, ist ja zumindest die Grundfunktion des Betriebs gegeben.

Zitat von: tostmann am 14 Juli 2026, 01:43:39Empfehlung ist ein Mainline-Board — am robustesten ein S3 (mit PSRAM), alternativ ein C6. Auf beiden läuft der WebUI-Betrieb auch unter Last ohne Verbindungsabriss.

Aber beide können eben kein 5GHz, was bei mir eine primäre Anforderung ist.

Solange es keinen anderen ESP32 gibt, der 5GHz beherrscht, würde ich gerne bei meinem C5 bleiben.
Die "Einschränkung", das WebUI nicht regelmäßig zu benutzen, stört mich viel weniger, als alleine wegen sixback ein zusätzliches 2,4GHz WLAN aufbauen zu müssen.

Zitat von: tostmann am 14 Juli 2026, 01:43:39Ein allgemeiner Fix reitet im nächsten Release trotzdem mit (kürzere Timeouts, wenn eine Box nicht antwortet, plus etwas Caching der Box-Abfragen) — der macht das WebUI auf allen Boards unter Last flüssiger, den C5 rettet er aber nicht vor seinem RAM-Limit.

Ok, verstanden.

Aktuell sind bei mir beide C5 Boards mit .30 geflasht.
Es erscheint mir wohl am sinnvollsten, das erstmal so zu belassen.

Hallo betateilchen,

kurz zur Korrektur meinerseits: du hast recht, das ESP32-C5-WROOM-1-N16R8 hat tatsächlich 8 MB PSRAM. Mein "kein PSRAM" bezog sich auf die N4-Module, mit denen ich hier teste — das war zu pauschal formuliert.

PSRAM löst das Problem aber nicht automatisch: die WLAN-Puffer müssen DMA-fähig sein und liegen per Default zwingend im internen SRAM — und die 384 KB internes SRAM sind beim C5 fix, egal ob PSRAM bestückt ist. Genau dort läuft es unter WebUI-Last über. PSRAM könnte nur indirekt entlasten, das ist Portierungs- und Messarbeit, kein Schalter.

Deshalb die ehrliche Ansage: das ist ein Non-Profit-Freizeitprojekt, ich habe keinen C5 mit PSRAM und werde mir für diesen Sonderfall auch keinen anschaffen. Mainline bleibt S3/C6. Der C5 fliegt nicht raus (dein 5-GHz-Argument ist valide), aber aktiv debuggen kann ich nur auf Hardware, die ich besitze. Der Code ist offen — wenn du den PSRAM-Weg auf deinem Board zum Laufen bringst, schaue ich mir einen PR gerne an.

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

Danke fürs gründliche Testen!

Gruß

Zitat von: tostmann am 14 Juli 2026, 12:53:45Deshalb die ehrliche Ansage: das ist ein Non-Profit-Freizeitprojekt, ich habe keinen C5 mit PSRAM und werde mir für diesen Sonderfall auch keinen anschaffen.

Naja, 5GHz würde ich jetzt nicht unbedingt als "Sonderfall" ansehen. Und dass es ein Freizeitprojekt ist, ist mir klar.

Gerne lasse ich Dir als Anerkennung für das Freizeitprojekt und für Deine immer schnelle Hilfe einen C5 mit PSRAM zukommen, schick mir einfach Deine Adresse als PN oder bestätige mir, dass die Adresse in Deinem Impressum noch aktuell ist.

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

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

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

Hallo fred,

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

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

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

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

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

Gruß

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

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

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

Zitat von: tostmann am 14 Juli 2026, 12:53:45Im nächsten Release kommt unabhängig davon ein Fix, der den Speicher-Peak im WebUI-Pfad senkt. Gut möglich, dass dir das auf dem C5 schon reicht — das müsstest du dann bei dir gegentesten.

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

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

Bildschirmfoto 2026-07-16 um 19.26.16.png

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

{
  "name": "SixBack",
  "version": "0.8.32",
  "build": "2026-07-15 23:25:40",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 857,
  "wifi": {
    "connected": true,
    "ssid": "mowg",
    "ip": "192.168.123.46",
    "rssi": -75,
    "channel": 40,
    "band": "5GHz",
    "mac": "38:44:BE:00:7F:94",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 70436,
    "min_free": 14996,
    "total": 257776
  },
  "psram": {
    "free": 0,
    "total": 0
  },
  "chip": {
    "model": "ESP32-C5",
    "cores": 1,
    "revision": 100,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.46:8000"
  },
  "speakers_count": 4,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "health": {
    "boot_count": 1,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 0,
    "last_wifi_down_s": 0,
    "last_reset": "POWERON",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 257
  }
}


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

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

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

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

Zitat von: tostmann am 17 Juli 2026, 02:28:56die neue Heap-Prüfung hatte eine viel zu hohe Schwelle, auf dem C5 wurde damit praktisch jede Preset-Abfrage abgewiesen.

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

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

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

zu deinen Fragen:

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

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

Hier der Api-Status:
{"name":"SixBack","version":"0.8.33","build":"2026-07-17 02:16:41","license":"PolyForm-Noncommercial-1.0.0","copyright":"Copyright (c) 2026 Dirk Tostmann","uptime_s":334,"wifi":{"connected":true,"ssid":"hannebambel HOME","ip":"192.168.123.173","rssi":-69,"channel":11,"band":"2.4GHz","mac":"1C:DB:D4:74:9F:44","hostname":"sixback.local","improv_active":false,"improv_window_s":0,"captive_active":false,"captive_window_s":0},"heap":{"free":112580,"min_free":55064,"total":340176,"largest_block":41972,"outbound_rejects":0},"psram":{"free":8361488,"total":8388608},"chip":{"model":"ESP32-S3","cores":2,"revision":2,"flash_size":16777216},"cloud_replacement":{"port":8000,"base_url":"http://192.168.123.173:8000"},"speakers_count":9,"scan_in_progress":false,"groups_persist_ok":true,"preset_store":{"load_ok":true,"save_fails":6,"speakers":8},"health":{"boot_count":1,"crash_count":0,"wifi_reboots":0,"heap_reboots":0,"wifi_disconnects":0,"last_wifi_down_s":0,"last_reset":"SW","wdt_subscribed":true,"wifi_down_for_s":0,"heap_low_for_s":0,"heap_low_events":0,"last_heap_low_s":0,"last_ping_age_s":34}}
Werde jetzt wieder den Import-Button nutzen.
Komischerweise hatte ich auch bei dem ganzen Status Refresh usw. bei anderen Boxen auch unter jedem Preset den Push-Button als wenn etwas geändert worden wäre. Ein Status-Button bei dem jeweiligen Speaker hat es gerichtet. Ist irgendwie komisches Verhalten.
Aber der eine Speaker bleibt bei 6 leeren Presets. Wie gesagt Import-Button genutzt (dabei kam rechts unten wieder kurz eine 502 Meldung, aber der Speaker ist erreichbar), dann nochmal Status und Browser-Reload und die 6 Presets sind wieder da...

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

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

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

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

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

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

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

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

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

Danke, ich werde die .34 testen.

Zitat von: tostmann am 17 Juli 2026, 15:56:29Workaround ab sofort: die Flotte auf zwei Sticks aufteilen — mit dem separaten Büro-Stick machst Du schon genau das Richtige, z.B. 5+4 verteilt ist die Kante weg.

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

Zitat von: betateilchen am 17 Juli 2026, 16:51:22Nur interessehalber: gibt es generell eine Möglichkeit, zwei sixback ESP32 im gleichen WLAN zu betreiben, ohne dass sie sich in Quere kommen?

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

Zitat von: tostmann am 17 Juli 2026, 15:56:29Achtung C5: kein Selbst-OTA — Update über den Webflasher ("Update existing").

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

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

Bildschirmfoto 2026-07-17 um 17.10.03.png

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

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

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



--

Zitat von: fred_feuerstein am 17 Juli 2026, 17:15:30Das würde mich auch interessieren. Dann müsste es ja mindestens eine Whitelist oder Blacklist geben, sonst findet jeder scan die zuvor entfernten Boxen wieder.

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

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

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

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

Ich rufe die ohnehin nur über die IP auf.
und Auto-Migration habe ich gleich deaktiviert. Das sollte dann auch gemacht werden.
Und unabhängig davon, ein neuer scan an einem sixback findet dann trotzdem auch die Boxen des anderen sixback. Halt mit einem Status, dass sie zu einem anderen sixback gehören.
sind aber trotzdem in der Liste.
Deswegen der Vorschlag mit entweder White- oder Blacklist, in die man die jeweiligen IP Adressen der Boxen einträgt.

Aber am liebsten wäre es mir, wenn man alle meine Boxen mit einem sixback verwalten könnte. Vielleicht hat Dirk dazu noch eine Idee, evtl. längere abfragegzeiten oder timeouts oder so etwas.

Zitat von: fred_feuerstein am 17 Juli 2026, 18:19:38Deswegen der Vorschlag mit entweder White- oder Blacklist, in die man die jeweiligen IP Adressen der Boxen einträgt.

Vermutlich würde sowas aber weit über das hinausgehen, was hinter dem eigentliche Konzept und der Zielsetzung von sixback steht. Installationen mit mehr als vier Soundtouch Boxen dürften eher nicht das typische Szenario sein.

@betateilchen, @fred: Ja, zwei SixBack im selben WLAN gehen konfliktfrei — die Peer-Erkennung ist seit langem drin: ein SixBack fasst im Auto-Mode keine Boxen an, die ein anderer lebender SixBack verwaltet. Der Ablauf aus #164 (Gruppe 1 migrieren, Auto-Mode aus, dann Gruppe 2 am zweiten Stick) ist genau richtig, und fred macht mit IP-Zugriff plus deaktiviertem Auto-Mode schon das Richtige. Manuelles Migrieren übernimmt eine Box dagegen immer bewusst — das ist der gewollte Umzugsweg zwischen den Sticks.

mDNS stimmt: beide melden sich aktuell als sixback.local, da hilft nur der Zugriff per IP. Konfigurierbarer Hostname ist notiert. Die fremden Boxen tauchen beim Scan absichtlich mit ihrem Status auf — ein simples Ausblenden in der Ansicht (kein großes Verwaltungs-Feature, da bin ich bei betateilchen) ist ebenfalls notiert.

@fred zu "alle 9 an einem Stick": längere Abfragezeiten oder Timeouts helfen da leider nicht — die Grenze ist der Platz des Preset-Speichers im Flash, nicht das Timing. Das zu heben ist der schon erwähnte größere Umbau, für den ich kein Datum nenne; bis dahin ist die Aufteilung auf zwei Sticks der ehrliche Weg.

@betateilchen zum C5 nach "Update existing": kannst Du direkt nach so einem Update einmal kurz den Strom trennen (USB ab/an) und schauen, ob er dann kommt? Bei unseren C5-Boards im Labor bleibt das native USB nach dem Flash-Reset gelegentlich hängen, bis einmal Strom weg war — ein Fresh Install verdeckt das, weil man dabei ohnehin neu ansteckt und provisioniert. Wenn der Power-Cycle nichts ändert, ist es etwas anderes und ich schaue tiefer rein.

Noch ein Hinweis in eigener Sache: in den nächsten Wochen sind Schulferien — Antworten und Releases kommen daher etwas langsamer als zuletzt gewohnt.

Zitat von: tostmann am 17 Juli 2026, 22:01:31die Peer-Erkennung ist seit langem drin: ein SixBack fasst im Auto-Mode keine Boxen an, die ein anderer lebender SixBack verwaltet.

Darauf würde ich aber (nach meinen Erfahrungen) nicht wetten...

Zitat@betateilchen zum C5 nach "Update existing": kannst Du direkt nach so einem Update einmal kurz den Strom trennen (USB ab/an) und schauen, ob er dann kommt?

Habe ich alles schon erfolglos getestet.
Können wir aber gerne nach den Schulferien nochmal genauer testen, es gibt ja einen Workaround.

Also mit 8 Lautsprechern bei SixBack klappt es bisher ohne Probleme mit den Presets, also ohne "leere" Presets. Werde weiter beobachten und berichten :)
Version .34 ist installiert.

Den 9. Lautsprecher in meinem Netzwerk habe ich nun mit einem anderen Projekt laufen: Soundtouch Reborn (STR) https://st-reborn.de/de/
Hier wird ohne externen Server alles "auf" dem Lautsprecher abgelegt, incl. WebServer zur Steuerung etc., und einige weitere Möglichkeiten.

Somit kann ich das andere Projekt auch mit testen ;)

Danke fürs Gegentesten — das ist eine wichtige Rückmeldung. Schön, dass .34 bei Dir mit 8 Boxen bisher sauber durchläuft und die leeren Presets weg sind.

Kurz zum Hintergrund, warum das jetzt hält: Der Verlust kam nicht vom WLAN oder von der Anzahl der Boxen, sondern von einem abgebrochenen Schreibvorgang in den Preset-Speicher. Blieb ein Eintrag dabei halb geschrieben zurück, hat der Speicher ihn beim nächsten Neustart als ungültig verworfen — deshalb sah danach alles aus wie frisch und leer. Seit .34 wird jeder Preset-Stand in zwei getrennte Slots geschrieben, nach dem Schreiben zurückgelesen und verglichen, und erst dann auf den neuen Stand umgeschaltet. Ein abgebrochener Schreibvorgang kann den zuletzt gültigen Stand damit nicht mehr überschreiben.

Dein "weiter beobachten" ist trotzdem genau richtig — der Fehler kam ja nur alle paar Tage, sicher ist erst eine längere ruhige Phase. Falls doch nochmal etwas auffällt, wäre ein /api/status-Dump im Moment des Problems (also vor dem Reboot/Recovery) sehr hilfreich.

Und dass Du parallel STR laufen lässt und mittestest: super. SixBack zielt bewusst auf den einfachen Fall — bis rund fünf Boxen und die sechs Tasten zurück, ohne Cloud. Für größere oder speziellere Aufbauten ist es gut, dass es daneben noch andere Wege gibt.

v0.8.35 ist raus. Zwei Sachen aus diesem Thread sind drin:

Hostname konfigurierbar. Zwei Sticks im selben Netz haben sich bisher beide als sixback.local gemeldet — mDNS-Kollision, und in der DHCP-Liste sieht man auch nicht, welcher welcher ist. Jetzt einstellbar über die Web-UI oder PUT /api/hostname; wirkt auf mDNS und den DHCP-Client-Namen. Validierung serverseitig (a-z, 0-9, Bindestrich — nicht am Anfang oder Ende; Großbuchstaben werden kleingeschrieben, max. 24 Zeichen, leer = zurück auf Default). Braucht einen Reboot, und die UI zeigt bis dahin an, dass noch einer aussteht — sie behauptet also nicht, der neue Name sei schon aktiv.

Einzelne Boxen ausblenden. Lässt sich je Box einzeln setzen. Die Box verschwindet dann aus der Liste und aus allen Auswahl-Dialogen (Zone, Stereo-Paar, DLNA-Browser, Group-Sync), und ihr Status-Polling entfällt damit auch — spart also nebenbei Netzwerk-Fan-out. Überlebt Re-Discovery und Reboot. Bewusst reine Anzeige-Sache: im Hintergrund bedient der Stick die Box weiter genau wie vorher.

Dazu noch drei Dinge:

Improv läuft jetzt auf beiden USB-Buchsen (16-MB-S3). Bisher legte ein Compile-Flag fest, ob der Provisionierungs-Handshake auf UART0 (Bridge-Chip) oder auf dem nativen USB-Serial-JTAG liegt — Boards mit nur einer Buchse und ohne Bridge brauchten deshalb ein eigenes Build-Target. Jetzt laufen zwei Improv-Instanzen parallel, und die Buchse, auf der zuerst ein vollständiges IMPROV-Magic ankommt, bekommt die Session. Gematcht wird bewusst auf das Magic und nicht aufs erste Byte: sonst sperrt ein offenes Terminal auf der einen Buchse den echten Host auf der anderen aus.

Die Anwendungs-Logs (Arduino-Serial) bleiben dabei auf UART0, da ändert sich nichts. Auf dem nativen Port läuft allerdings die IDF-Konsole mit, der Improv-Stream teilt sich die Buchse dort also mit Log-Ausgaben. Deshalb nachgemessen: 894 Improv-Frames unter Dauerlast, ~11 KB Konsolen-Ausgabe im selben Stream, kein einziger kaputter Frame. Geprüft per Checksumme und nicht per Frame-Suche — ein toleranter Parser meldet sonst fröhlich Erfolg auf einem Stream, an dem ein strikter Client erstickt.

Zwei bekannte Fälle stehen auch auf der Flasher-Seite: bei ~88 % kann der Browser in der Konsole ,,Error fetching current state: TIMEOUT" loggen — der Flash läuft normal weiter und wird fertig. Und selten kommen sich Konsole und Handshake auf dem nativen Port doch in die Quere, dann meldet der Browser ,,Improv Wi-Fi Serial not detected". In beiden Fällen: nochmal versuchen, oder die UART-Buchse nehmen.

Store-Schreibfehler sind jetzt sichtbar — Warn-Anzeige im Header, statt dass es erst nach dem nächsten Reboot auffällt. Gilt auch für die Speaker-Liste.

gabbo-Watcher (das HW-Tasten-Re-Arm für Spotify) prüft PSRAM zur Laufzeit statt zur Compile-Zeit: auf S3-Modulen ohne bestücktes PSRAM startet er gar nicht erst — dort gibt es dann folglich auch kein HW-Tasten-Re-Arm. Boards mit PSRAM sind unverändert.

Partitionen sind unverändert, also ganz normal per OTA installierbar.

Release-Notes (https://github.com/tostmann/SixBack/releases/tag/v0.8.35) · sixback.io (https://sixback.io/)

Hab heute die .35 installiert.

Vorher: mit der .34 lief das System schon tagelang mit 8 Lautsprechern vollkommen problemlos.

Heute nach dem Update auf .35 nach Reboot waren wieder 9 Lautsprecher da. Gleich den einen wieder entfernt. Somit 8 aktiv.
Aber: es kam heute (warum auch immer) schon ein paar Mal zu Aussetzern beim WebRadio, bis hin dass auf einmal wieder Presets bei ein paar Lautsprechern fehlten.
Musste bei 4 Lautsprechern (nach erfolglosem Status Refresh Gesamt und Status Refresh beim Lautsprecher) wieder die gespeicherten Presets einspielen und danach jeweils mindestens zwei Presets pro Lautsprecher mit "push" aktivieren. Dann übernimmt er komischerweise auch die anderen, für die ich noch keinen "push" gemacht habe.

Momentan steht im Header von SixBack: ⚠ store: 8 preset save fails · 19 inventory save fails
(btw: wie bekommt man den Status im Header wieder entfernt?)

Bin gespannt wie die .35 sich weiter verhält. Wie gesagt, die .34 lief mit den 8 Lautsprechern bisher am stabilsten über Tage hinweg.

edit:
jetzt nach ein paar Stunden war gerade wieder ein Lautsprecher ohne Presets, bzw. alle 6 Presets standen mit der Push-Meldung da. Konnte dann einen Sender per Push wieder speichern. Dann waren alle wieder gesetzt.
Status lief ohne Probleme durch...
Kann es sein, dass es nun auch bereits mit 8 Lautsprechern Speicher-Probleme gibt mit der .35 ?
Bei der .34 gab es die mit 8 Lautsprechern "scheinbar" nicht, dort erst ab 9 Lautsprechern.

für den Notfall, kommt man eigentlich auch wieder auf eine ältere Version (bspw. .34) zurück? Falls ja, wie?

Danke für den ausführlichen Bericht — vor allem für den Vergleich mit .34, das ist die eigentlich wertvolle Information.

Zuerst zu Deiner direkten Frage: Die Anzeige im Header ist ein Zähler seit dem letzten Neustart. Es gibt keinen Knopf zum Zurücksetzen, ein Neustart des Sticks löscht sie. Ich will Dir den Neustart aber nicht als Lösung verkaufen, denn die Anzeige ist hier nicht das Problem, sondern der Hinweis darauf.

Und ich glaube, sie erklärt genau das, was Du beschreibst. "8 preset save fails · 19 inventory save fails" heißt: Der Stick konnte 27 Mal etwas nicht in seinen Speicher schreiben. Alles, was in diesen Momenten geändert wurde, existierte danach nur noch im Arbeitsspeicher — und war beim nächsten Neustart weg. Das passt auf beide Symptome: Der neunte Lautsprecher, den Du entfernt hattest, war nach dem Neustart wieder da, weil das Entfernen nie gespeichert werden konnte. Und die Presets fehlten bei mehreren Boxen, weil die Preset-Liste denselben Weg nimmt.

Wichtig für den Vergleich mit .34: Diese Zähler gibt es erst seit .35, ich habe sie in dieser Version überhaupt erst eingebaut. Das heißt nicht automatisch, dass .34 fehlerfrei war — dieselben Schreibfehler wären dort passiert, nur ohne jede Anzeige. Ob .35 sich wirklich schlechter verhält oder ob Du jetzt zum ersten Mal siehst, was vorher unsichtbar war, kann ich von hier aus nicht entscheiden.

Was ich brauche, um weiterzukommen: einen Statusabzug, solange die Warnung im Header steht und bevor Du neu startest:

http://<IP-des-Sticks>/api/status
Darin stehen der freie Speicher und die Zähler. Ein fehlgeschlagener Schreibvorgang hat im Code genau zwei mögliche Ursachen — zu wenig freier Arbeitsspeicher im Moment des Schreibens, oder der Speicherbereich im Chip ist voll. Welche von beiden es bei Dir ist, sieht man nur an diesen Werten, und die Gegenmaßnahmen sind völlig verschieden. Ohne den Abzug kann ich nur raten, und damit ist Dir nicht geholfen.

Zwei weitere Dinge:

Der neunte Lautsprecher: Seit .35 kannst Du einzelne Boxen ausblenden, statt sie zu entfernen. Ausgeblendete Boxen verschwinden aus der Liste und aus allen Auswahldialogen und kommen bei einer erneuten Suche nicht wieder — im Gegensatz zum Entfernen. Solange die Schreibfehler aber anhalten, überlebt auch das Ausblenden den Neustart nicht; das ist eher die Lösung für danach.

Die Aussetzer beim Webradio kann ich Dir nicht erklären. Ob sie mit den Schreibfehlern zusammenhängen oder unabhängig davon sind, ist offen. Falls das wieder auftritt, wäre die ungefähre Uhrzeit hilfreich, damit ich es mit dem Statusabzug in Beziehung setzen kann.

Noch ein Hinweis, der Dich zwar nicht betrifft, aber wichtig ist: Ich habe heute einen Fehler im Web-Flasher gefunden — der Button "Update existing" konnte den Stick unter bestimmten Umständen vor der Installation komplett löschen. Betroffene Sticks starten danach gar nicht mehr und brauchen eine vollständige Neuinstallation. Dass Dein Stick nach dem Update normal weiterlief, zeigt, dass Du diesen Fall nicht erwischt hast. Behoben und bereits live — die Flasher-Seite ist korrigiert, dafür ist kein neues Release nötig. Wer über den Web-Flasher aktualisiert und dabei doch einmal gefragt wird, ob gelöscht werden soll: das Häkchen nicht setzen.

Dass .34 bei Dir über Tage mit acht Boxen ruhig lief, nehme ich ernst. Wenn .35 sich schlechter verhält, will ich wissen warum — dafür brauche ich aber den Statusabzug aus dem Fehlermoment.

Nachtrag — Deine Ergänzung habe ich erst gesehen, nachdem ich oben geantwortet hatte. Zwei Punkte daraus.

Zurück auf .34: ja, das geht jetzt. Bisher ging es nicht, weil die alten Dateien nirgends mehr lagen — sixback.io hält immer nur die aktuelle Version. Ich habe die .34-Dateien deshalb gerade an die Release-Seite gehängt:

https://github.com/tostmann/SixBack/releases/tag/v0.8.34
Dort brauchst Du zwei Dateien für Deinen Chip — welcher es ist, steht in der Statuszeile oben in der Weboberfläche (z. B. "ESP32-S3 16MB"):

sixback-<chip>-littlefs.bin
sixback-<chip>-firmware.bin
Beide lädst Du in der Weboberfläche des Sticks hoch, unter dem aufgeklappten Bereich ⚙ SYSTEM beim Firmware-Update. Wichtig ist die Reihenfolge: zuerst littlefs, dann firmware. Der Stick startet nach dem zweiten Upload von allein neu. Die Partitionen sind zwischen .34 und .35 gleich geblieben, deshalb funktioniert das in beide Richtungen; WLAN-Zugang, Presets und Spotify-Anmeldung bleiben dabei erhalten.

Ein Hinweis dazu: Nach dem Zurückgehen meldet der Stick beim nächsten "Check for update" natürlich wieder, dass .35 verfügbar ist. Nicht versehentlich draufklicken, sonst bist Du wieder da, wo Du gestartet bist.

Zu Deiner Frage, ob .35 schon bei 8 Boxen an die Grenze kommt und .34 erst bei 9: Das kann ich Dir ehrlich nicht beantworten, und ich möchte es auch nicht raten. .35 legt gegenüber .34 zwei Kleinigkeiten zusätzlich in den Speicher (den einstellbaren Gerätenamen und das Kennzeichen für ausgeblendete Boxen). Ob das den Ausschlag gibt, habe ich nicht gemessen — es klingt nach wenig, aber "klingt nach wenig" ist keine Aussage, auf die Du Dich verlassen solltest.

Genau das würde der Statusabzug zeigen, um den ich oben gebeten hatte: darin steht sowohl der freie Arbeitsspeicher als auch, wie voll der Speicherbereich ist. Damit ließe sich die Frage beantworten statt vermuten. Wenn Du also das nächste Mal die Warnung im Header siehst — einmal die Adresse aufrufen und den Text hier reinkopieren, das reicht mir.

Und danke fürs Dranbleiben und Mitschreiben, das ist genau die Art Rückmeldung, mit der sich so etwas eingrenzen lässt.

Aktuell habe ich ja noch die Status Meldung im Header.

Also hier die Ausgabe vom /api/status

{
  "name": "SixBack",
  "version": "0.8.35",
  "build": "2026-07-26 21:42:27",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 26984,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -69,
    "channel": 11,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 105588,
    "min_free": 59548,
    "total": 339184,
    "largest_block": 39924,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8358844,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 8,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 15,
    "speakers": 9
  },
  "inventory": {
    "save_fails": 45
  },
  "health": {
    "boot_count": 2,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 2,
    "last_wifi_down_s": 0,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 282
  }
}
Ansonsten wegen manuellem Downgrade: Bei meinem ESP32-S3 16MB wäre es die Version:
sixback-s3-littlefs.bin
sixback-s3-firmware.bin
oder?

So, bin erstmal auf der .34 zurück. Aber das Problem ist geblieben. Scheinbar hatte ich die ganzen Tage vorher mit der .34 keine Reboots am ESP. Deshalb lief es zuverlässig...

Also nach Flash und Reboot haben wieder bei 4 Lautsprechern die Presets gefehlt. Alle wieder eingerichtet einzeln über Import, die Anzeige unten rechts war dann ein 500er Fehler, Reload der Webseite zeigte dann die 6 neuen Presets aus dem Import beim Lautsprecher an, aber alle wieder mit PUSH Meldung. Dann wieder bei 2 bis 3 Presets nacheinander PUSH ausgewählt. Dann sind die restlichen Presets beim Speaker auch wieder gesetzt.
Das Ganze dann bei den 3 weiteren Lautsprechern auch so ähnlich weiter.

Als alles wieder eingerichtet war habe ich einfach mal einen Reboot vom ESP gemacht. Und siehe da, es fehlen wieder die entsprechenden Presets bei 4 Lautsprechern.

So wie es aussieht ist die Grenze mit dem Speicher wohl nicht bei 8, sondern scheinbar wesentlich darunter.
Wie sind Deine Erfahrungen bei anderen Usern? Laufen 4 Lautsprecher noch gut oder 5?
Könnte also sein, dass man wirklich einen 2. ESP32 braucht, um 8 und mehr Lautsprecher zu verwalten.

Ansonsten, am besten nie Rebooten ;)

Bei mir sind es 4 ST10 ohne Probleme.

Gruß aus L.E.
Uwe

v0.8.36 ist online — und sie adressiert genau das Speicherproblem aus den letzten Posts.

Was der Fix macht: TUNEIN-Presets belegen beim Speichern jetzt nur noch rund ein Zwölftel des bisherigen Platzes im internen Speicher (NVS). Treiber waren die beiden URL-Felder (Stream + Logo) — beide lassen sich aus der Sender-ID wiederherstellen und werden deshalb nicht mehr mit abgelegt.

Nachgemessen: vorher lief die Partition bei etwa 5 Lautsprechern mit voll belegten Presets voll — exakt der Fehler "partition out of space", der in Freds Status-Dump steht. Mit dem Fix waren im Test 22 Lautsprecher bei ~50 % Füllstand kein Problem.

@fred_feuerstein: dein /api/status-Dump hat die Frage entschieden — der Heap war völlig in Ordnung (min. 59 KB frei, PSRAM praktisch ungenutzt), die NVS-Partition war voll. Deine Einschätzung "wesentlich unter 8" war richtig. Und die eben gemeldeten 4 ST10 ohne Probleme passen exakt ins Bild — danke für den Datenpunkt.

Wichtig nach dem Update: der Platzgewinn greift erst, wenn ein Preset neu gespeichert wird. Nach dem Update auf .36 die Presets also einmal neu einspielen (Import bzw. Push) — danach schrumpfen die Einträge.

@fred_feuerstein: ein Punkt bleibt bei dir offen: dein Dump zeigt auch 45 fehlgeschlagene Inventar-Schreibvorgänge, und das Inventar selbst habe ich in .36 nicht angefasst. Da die Partition mit den kleinen Presets wieder viel Luft hat, erwarte ich eine deutliche Entspannung — versprechen kann ich sie nicht. Magst du nach Update + Neu-Einspielen die Kopfzeile beobachten und berichten?

Update wie gehabt: in der Weboberfläche ganz unten ⚙ SYSTEM aufklappen → Update, oder über den Flasher auf sixback.io (dessen Update-Weg ist seit gestern repariert). Für den Fall der Fälle liegen die .34-Dateien weiterhin am GitHub-Release.

Für meinen C5 habe ich zum Update den webflasher benutzt und ein fresh install gemacht.
Beim Neubelegen der presets scheitert das Rücklesen von /presets mit der bekannten Meldung "low heap" und "device busy" - bei 57kB Heap laut Kopfzeile.
Die presets scheinen aber grundsätzlich zu funktionieren.

{
  "name": "SixBack",
  "version": "0.8.36",
  "build": "2026-07-30 01:08:18",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 673,
  "wifi": {
    "connected": true,
    "ssid": "mowg",
    "ip": "192.168.123.44",
    "rssi": -76,
    "channel": 36,
    "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": 60976,
    "min_free": 7860,
    "total": 257712,
    "largest_block": 15348,
    "outbound_rejects": 38,
    "rej_floor_total": 3,
    "rej_floor_block": 35,
    "rej_inflight": 0
  },
  "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,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 0,
    "speakers": 2
  },
  "inventory": {
    "save_fails": 0
  },
  "health": {
    "boot_count": 2,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 1,
    "last_wifi_down_s": 1,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 9,
    "last_heap_low_s": 595,
    "last_ping_age_s": 72
  }
}


Zitat von: tostmann am 30 Juli 2026, 11:16:40Wichtig nach dem Update: der Platzgewinn greift erst, wenn ein Preset neu gespeichert wird. Nach dem Update auf .36 die Presets also einmal neu einspielen (Import bzw. Push) — danach schrumpfen die Einträge.

@fred_feuerstein: ein Punkt bleibt bei dir offen: dein Dump zeigt auch 45 fehlgeschlagene Inventar-Schreibvorgänge, und das Inventar selbst habe ich in .36 nicht angefasst. Da die Partition mit den kleinen Presets wieder viel Luft hat, erwarte ich eine deutliche Entspannung — versprechen kann ich sie nicht. Magst du nach Update + Neu-Einspielen die Kopfzeile beobachten und berichten?

Update auf .36 durchgeführt. NVS Fehler bleiben. Bspw. wenn ich einen Preset neu belegen möchte kommt rechts unten:
Set failed: NVS save failed (partition out of space) — remove unused speakers or try POST /api/nvs/cleanup
Ich denke, es müsste bei mir erstmal aufgeräumt werden. Also neu anfangen?! Bleibt da nur ein Fresh-Install?
Und wie sollte ich dann vorgehen. Ein Scan findet ja alle 9 Speaker, denke, dann habe ich das gleiche Problem wieder. Oder sollte ich bspw. 4 Lautsprecher wirklich ausschalten beim ersten Einrichten und Scan?!
=> ein Fresh-Install hat genau wieder alle 9 Speaker gefunden (klar) und dann habe ich begonnen die ersten Lautsprecher einzurichten, neue manuelle Pushs, Import und dann Push, das lief anfangs ganz gut, aber irgendwann kam wieder die obige Meldung mit "partition out of space"... also wieder das gleiche Problem.

Also konkreter, gerade auch im Hinblick auf den weiteren esp32-s3, den ich wahrscheinlich dann morgen in Betrieb nehme.
Also sagen wir fresh-install auf beiden esp32-s3 und dann?
Bei der Einrichtung des ersten ESP32-s3 dann 4 Lautsprecher komplett ausschalten vor dem ersten Einschalten von SixBack?
Dann die gefundenen Lautsprecher einrichten.
Dann die Lautsprecher vom 1. Sixback ausschalten und die anderen 4 wieder anklemmen? Sodass der Scan beim 2. Sixback nur die 4 Lautsprecher findet?
Soweit ok.
Aber wenn ich beide dann laufen habe und diese einen neuen Scan, bei Reboot etc. machen, finden sie jeweils die anderen Lautsprecher.
Auch wenn diese gekennzeichnet sind als zugehörig zu einem anderem Sixback oder so, sie sind doch trotzdem in der Liste und werden "verwaltet", Speicherung, NVS, ... gibt das nicht wieder das gleiche Problem?

Es wäre schön, wenn Du mal so eine Art Fahrplan für die Einrichtung skizzierst. Gerade auch im Hinblick auf die nötige Aufteilung der Lautsprecher auf mehrere SixBacks.
Ich würde die Lautsprecher aufteilen mit
Sixback 1 => 5 Lautsprecher
Sixback 2 => 4 Lautsprecher

@fred_feuerstein: dein Test hat den fehlenden Baustein geliefert — ich habe die Ursache im Labor nachgemessen, sie erklärt exakt dein "anfangs lief es gut, dann wieder partition out of space". Und der Fix dafür ist seit heute Abend online.

Was da voll lief, waren nicht mehr die Presets — es war der Sender-Cache. Jeder Sender, der zum ersten Mal abgespielt oder gepusht wird, legte Name, Stream-URL und Logo-URL im selben kleinen Einstellungs-Speicher (NVS) ab, damit der nächste Tastendruck schneller auflöst. Gemessen: rund 8 Einträge pro Sender, ohne Obergrenze. Bei deinen bis zu 54 Sendern (9 Boxen × 6 Tasten) sind das mehrere hundert von insgesamt 630 Einträgen — die Ersparnis der kleinen Presets wurde beim Abspielen Stück für Stück wieder aufgefressen. Deshalb half auch der Fresh-Install nur vorübergehend, und deshalb war meine 22-Boxen-Messung von gestern Nacht unvollständig: sie hat Presets nur angelegt, nie abgespielt — dein Praxisbericht hat das aufgedeckt.

Der Fix ist in v0.8.37: der Sender-Cache liegt jetzt im Dateisystem (dort sind knapp 10 MB frei) statt im 20-KB-Einstellungs-Speicher. Beim ersten Start nach dem Update werden die alten Cache-Einträge automatisch aus dem Einstellungs-Speicher geräumt — du bekommst den Platz also ohne weiteres Zutun zurück. Danach einfach die restlichen Boxen einrichten; ein Fresh-Install ist nicht nötig. Im Labor verifiziert: Cache-Einträge landen im Dateisystem, überleben den Neustart, und der Einstellungs-Speicher bleibt beim Abspielen konstant.

v0.8.37 behebt außerdem einen Fehler aus der .36 von gestern (Spotify- und handangelegte Stream-Presets hätten nach einem Neustart nichts mehr abgespielt; unter .36 gespeicherte reparieren sich mit dem Update von selbst). Wenn du auf der .36 oder .34 bist: direkt auf die .37 (⚙ SYSTEM → Update).

Zu deinem Fahrplan mit zwei ESP32-S3: mein Vorschlag ist, es nach dem Update erst einmal mit einem Stick zu versuchen — nach den Zahlen sollten deine 9 Boxen mit vollen Presets jetzt passen (schlanke Presets + Cache im Dateisystem), und dein Setup ist der beste Härtetest dafür. Falls du trotzdem aufteilen willst: Boxen ausschalten beim Einrichten ist nicht nötig. Entscheidend ist nur, über welchen SixBack du eine Box migrierst — sie gehört danach diesem Stick, der andere listet sie nur passiv und lässt die Finger davon. Deine Beobachtung stimmt: jeder Stick nimmt alle gefundenen Boxen in seine Liste auf (Löschen hält nicht, der nächste Scan findet sie wieder; Ausblenden ist nur Anzeige) — aber die Liste selbst ist nicht der Speicherfresser, das war der Cache.

Berichte gern, wie sich die Kopfzeile (save fails) nach Update + Einrichten verhält — die Inventar-Schreibfehler aus deinem Dump sollten mit dem freien Platz ebenfalls verschwinden, das ist aber der Teil, den ich noch nicht bei dir gemessen habe.

Hey,

vielen Dank für die 0.8.37 in der C5-N16R8-Version 8)

Das WebUI scheint jetzt auf den ersten Blick sehr viel flüssiger zu laufen als vorher.
Alle Boxen und alle presets auf den Boxen werden jetzt nach dem Aufruf des WebUI sofort gefunden und angezeigt.
Hoffentlich war das eben nicht nur ein "Zufall"...

{
  "name": "SixBack",
  "version": "0.8.37",
  "build": "2026-07-30 19:15:38",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 303,
  "wifi": {
    "connected": true,
    "ssid": "mowg",
    "ip": "192.168.123.44",
    "rssi": -73,
    "channel": 36,
    "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": 60328,
    "min_free": 25288,
    "total": 255328,
    "largest_block": 15348,
    "outbound_rejects": 27,
    "rej_floor_total": 0,
    "rej_floor_block": 27,
    "rej_inflight": 0
  },
  "psram": {
    "free": 8360816,
    "total": 8388608
  },
  "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,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 0,
    "speakers": 4
  },
  "inventory": {
    "save_fails": 0
  },
  "health": {
    "boot_count": 1,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 0,
    "last_wifi_down_s": 0,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 3
  }
}


Danke für die Rückmeldung — und für den Dump gleich mit dazu.

Der bestätigt genau das, was ich sehen wollte: Board sauber als C5 mit 16 MB Flash und 8 MB PSRAM erkannt, die .37 vom Abend drauf, Presets und Inventar ohne einen einzigen fehlgeschlagenen Schreibvorgang. Das ist der erste Feldbeleg für die neue 16-MB-Variante überhaupt.

Zum flüssigeren WebUI bin ich vorsichtig: warum das so ist, habe ich nicht gemessen. Der interne Arbeitsspeicher ist auf dem 16-MB-Board praktisch genauso groß wie auf dem kleinen C5 — es liegt also nicht einfach an "mehr RAM". Ein paar Grenzwerte im Code fallen mit PSRAM großzügiger aus, das würde dazu passen, ist aber eben Vermutung und keine Messung. Dein "hoffentlich nicht nur Zufall" ist an der Stelle die ehrlichere Formulierung als alles, was ich dir jetzt erklären könnte.

Einen Wert habe ich mir aus dem Dump notiert und auf die Liste gesetzt: 27 abgelehnte Box-Abfragen, und zwar alle aus derselben Ursache — nicht zu wenig freier Speicher insgesamt (davon hast du reichlich), sondern zu wenig am Stück. Der Schwellwert dafür liegt fest bei 16 KB, dein größter freier Block stand im Snapshot bei 15,3 KB. Das ist der einzige Grenzwert, der nicht mitwächst, wenn PSRAM da ist — die Prüfung schaut per Konstruktion nur auf den internen Speicher. Gemerkt, wird gemessen; ich drehe da nichts blind hoch, der Wert schützt eine Reservierung, die wirklich am Stück gebraucht wird.

Falls du magst: schau bei Gelegenheit nochmal auf den Status, wenn das Gerät ein paar Stunden gelaufen ist. Interessant ist, ob die Zahl weiter steigt — dann würdest du irgendwann auch real ein "device busy" sehen, und dann hat der Punkt mehr Dringlichkeit als heute.

Und ja: dass hier überhaupt vernünftige Testhardware auf dem Tisch liegt, hat ein Sponsor beigetragen. ;) Danke!

Hab die .37 auch installiert. Direkt nach dem reboot waren alle Presets da. Das flüssigere WebIf kann ich bestätigen.

Habe dann noch drei mal den esp32 rebootet. Presets waren immer da.

Der eine save Fehler den er bisher anzeigt, der kommt denke ich von der 9. ausgeblendeten Box?
Da sonst alle Presets auch nach reboot da sind.

Ansonsten erstmal lieben Dank. Das ist jetzt wirklich ein riesen Unterschied und Fortschritt im Projekt.

Hier auch der Status, bin gerade am Handy, da ist die Ausgabe leider nicht formatiert.

{"name":"SixBack","version":"0.8.37","build":"2026-07-30 19:13:40","license":"PolyForm-Noncommercial-1.0.0","copyright":"Copyright (c) 2026 Dirk Tostmann","uptime_s":277,"wifi":{"connected":true,"ssid":"hannebambel HOME","ip":"192.168.123.173","rssi":-24,"channel":11,"band":"2.4GHz","mac":"1C:DB:D4:74:9F:44","hostname":"sixback.local","improv_active":false,"improv_window_s":0,"captive_active":false,"captive_window_s":0},"heap":{"free":118784,"min_free":86756,"total":339184,"largest_block":49140,"outbound_rejects":0},"psram":{"free":8362664,"total":8388608},"chip":{"model":"ESP32-S3","cores":2,"revision":2,"flash_size":16777216},"cloud_replacement":{"port":8000,"base_url":"http://192.168.123.173:8000"},"speakers_count":9,"scan_in_progress":false,"groups_persist_ok":true,"preset_store":{"load_ok":true,"save_fails":1,"speakers":8},"inventory":{"save_fails":0},"health":{"boot_count":1,"crash_count":0,"wifi_reboots":0,"heap_reboots":0,"wifi_disconnects":0,"last_wifi_down_s":0,"last_reset":"SW","wdt_subscribed":true,"wifi_down_for_s":0,"heap_low_for_s":0,"heap_low_events":0,"last_heap_low_s":0,"last_ping_age_s":-1}}

Das ist die Rückmeldung, auf die ich gewartet habe — danke fürs Nachtesten samt Dump.

Der wichtigste Wert darin ist einer, den ich dir beim letzten Mal ausdrücklich nicht versprechen konnte: die fehlgeschlagenen Inventar-Schreibvorgänge stehen jetzt bei 0. Vorher waren es 45. Das war der Teil, den ich bei dir noch nicht gemessen hatte — er hat sich mit dem freigewordenen Platz erledigt. Dazu 9 Boxen auf einem einzigen Stick, Presets nach drei Neustarts unverändert da, keine Abstürze. Der Zwei-Stick-Fahrplan kann damit erst einmal in der Schublade bleiben.

Zu dem einen verbliebenen Speicherfehler muss ich dich in zwei Punkten korrigieren.

Erstens: mit der ausgeblendeten Box hat er nichts zu tun. Ausblenden ist reine Anzeige — der Preset-Speicher kennt diese Eigenschaft nicht und filtert nicht danach. Auch die "8" neben den 9 gefundenen Boxen ist kein Fehler: gezählt werden dort nur Boxen, die im Preset-Speicher einen Eintrag haben, und den bekommt eine Box erst, wenn für sie einmal etwas gespeichert wurde.

Zweitens, und das ist der unbequemere Teil: ich kann dir aus deinem Dump nicht sagen, was dieser eine Fehler war. Hinter dem Zähler stecken zwei gegensätzliche Fälle:

• Der Arbeitsspeicher war für einen Moment knapp und das Schreiben wurde absichtlich abgebrochen — der alte Stand bleibt unangetastet, nichts geht verloren, der nächste Schreibvorgang heilt es. Harmlos.
• Der Einstellungs-Speicher hat das Schreiben abgelehnt — in aller Regel, weil der Platz nicht reicht. Das wäre die alte Kante, und dann wäre dein Fall noch nicht ganz durch.

Beides landet heute in derselben Zahl. Das ist mein Versäumnis — bei den abgelehnten Box-Abfragen gibt es diese Aufschlüsselung längst, beim Preset-Speicher fehlte sie. Ich habe sie nachgezogen: ab der nächsten Version werden die beiden Ursachen getrennt ausgewiesen, und zwar nur dann, wenn überhaupt etwas schiefgegangen ist.

Damit du nach dem Update nicht ins Leere schaust: diese Zähler laufen immer nur seit dem letzten Neustart. Nach Update und Reboot steht da also erst einmal wieder null — dein alter Einzelfehler wird nicht nachträglich einsortiert. Interessant ist, ob im normalen Betrieb wieder etwas aufläuft, und wenn ja, in welchem der beiden Töpfe. Bleibt es bei null: Thema erledigt. Taucht wieder etwas auf: dann sehen wir zum ersten Mal, was es wirklich ist, statt zu raten.

Und danke für das Fazit — dass ausgerechnet dein Setup mit den 9 Boxen der Härtetest war, hat dem Projekt mehr gebracht als jede Labormessung hier.

heute früh sieht es so aus:

⚠ store: 7 preset save fails · 4 inventory save fails

{
  "name": "SixBack",
  "version": "0.8.37",
  "build": "2026-07-30 19:13:40",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 39553,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -24,
    "channel": 11,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 109852,
    "min_free": 60496,
    "total": 339184,
    "largest_block": 35828,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8358644,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 9,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 7,
    "speakers": 9
  },
  "inventory": {
    "save_fails": 4
  },
  "health": {
    "boot_count": 1,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 0,
    "last_wifi_down_s": 0,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 250
  }
}
Aber alle Presets sind da.

Dann dachte, ok, mach nochmal einen Reboot vom ESP. Dann kam er nicht mehr zurück, erst das Trennen vom Strom, kurz warten und wieder anstecken konnte ihn wieder starten.
Direkt nach dem Reboot standen die Presets bei einer Box alle mit der Push-Meldung drunter da. Es stand auch im Header: 1 preset save fails.
Habe dann einen "Refresh-Status" gemacht.
Dadurch waren auch bei dieser Box die Presets wieder korrekt, laut Anzeige.

Aber jetzt steht wieder:
⚠ store: 7 preset save fails · 10 inventory save fails

Hier der status:
{
  "name": "SixBack",
  "version": "0.8.37",
  "build": "2026-07-30 19:13:40",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 282,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -76,
    "channel": 11,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 120032,
    "min_free": 80428,
    "total": 339184,
    "largest_block": 49140,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8358384,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 9,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 7,
    "speakers": 9
  },
  "inventory": {
    "save_fails": 10
  },
  "health": {
    "boot_count": 1,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 0,
    "last_wifi_down_s": 0,
    "last_reset": "POWERON",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": -1
  }
}
aber ich störe mich daran jetzt erstmal nicht. Wichtig ist, dass auch nach dem Reboot "scheinbar" keine Presets verloren sind und man max. 1x Refresh-Status machen muss, ggfs. auch nur "Status" bei der einen Box.
Ist also auf jeden Fall eine große Verbesserung.

Zitat von: tostmann am 30 Juli 2026, 20:27:11Einen Wert habe ich mir aus dem Dump notiert und auf die Liste gesetzt: 27 abgelehnte Box-Abfragen, und zwar alle aus derselben Ursache — nicht zu wenig freier Speicher insgesamt (davon hast du reichlich), sondern zu wenig am Stück.

Falls du magst: schau bei Gelegenheit nochmal auf den Status, wenn das Gerät ein paar Stunden gelaufen ist. Interessant ist, ob die Zahl weiter steigt

Sieht nicht so aus, als ob das ein "schleichend schlimmer werdendes" Thema wäre.
Gestern Abend hatte ich den ESP nochmal umgezogen vom PC zur ST20, wo er an der Rückseite klebt.
Gute zwölf Stunden nach dem Boot stehen nur zwei solcher Fälle im Status.

{
  "name": "SixBack",
  "version": "0.8.37",
  "build": "2026-07-30 19:15:38",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 44802,
  "wifi": {
    "connected": true,
    "ssid": "mowg",
    "ip": "192.168.123.44",
    "rssi": -70,
    "channel": 36,
    "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": 56948,
    "min_free": 31668,
    "total": 255328,
    "largest_block": 19444,
    "outbound_rejects": 2,
    "rej_floor_total": 0,
    "rej_floor_block": 2,
    "rej_inflight": 0
  },
  "psram": {
    "free": 8348804,
    "total": 8388608
  },
  "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,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 0,
    "speakers": 4
  },
  "inventory": {
    "save_fails": 0
  },
  "health": {
    "boot_count": 2,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 0,
    "last_wifi_down_s": 0,
    "last_reset": "POWERON",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 98
  }
}


v0.8.38 ist soeben erschienen — ein reines Diagnose-Release, und der direkte Anlass sind Freds Zähler von heute früh.

Was drin ist:

1. Die Speicherfehler-Zähler sagen jetzt, warum. Bisher landeten zwei völlig verschiedene Fälle in derselben Zahl: ein kurzzeitiger Arbeitsspeicher-Engpass beim Schreiben (harmlos — der alte Stand bleibt unangetastet, der nächste Schreibvorgang heilt es) und ein vom Einstellungs-Speicher abgelehnter Schreibvorgang (die echte Kapazitätskante). Ab dieser Version weist der Status unter preset_store beide getrennt aus — save_heap_aborts und save_nvs_fails — und zwar nur dann, wenn überhaupt etwas schiefgegangen ist. Zusätzlich landet bei einem abgelehnten Schreibvorgang der konkrete Fehler im seriellen Log.

@Fred: deine 7/10 von heute früh kann ich mit der .37 schlicht nicht zuordnen — genau das ändert sich jetzt. Wenn nach dem Update wieder etwas aufläuft, poste einfach den Status; dann sehen wir erstmals, welcher der beiden Töpfe es ist, statt zu raten. (Wie gehabt: die Zähler laufen seit dem letzten Neustart, nach dem Update stehen sie also erst einmal auf null.)

2. Die Schwelle für "zu wenig Speicher am Stück" bei Box-Abfragen ist von 16 auf 8 KB gesenkt. Anlass war der Status vom C5: dort wurden 27 Abfragen allein an dieser Prüfung abgewiesen, obwohl sie durchgegangen wären. Der neue Wert ist im Labor nachgemessen, nicht geraten.

Update wie üblich: in der Weboberfläche ganz unten ⚙ SYSTEM aufklappen → Firmware update, oder über den Webflasher auf sixback.io. Partitionen sind unverändert, das Update ist für alle Varianten OTA-tauglich. Beide Testgeräte hier liefen exakt diese Binaries vorab über 13 Stunden stabil.

@Fred noch zu deinem Reboot-Hänger (ESP kam nach Software-Reboot nicht zurück, erst Stromtrennung half): das war bisher ein Einzelfall und ist aus der Ferne nicht bestimmbar — ich habe es notiert. Falls es wieder passiert, wäre der Status unmittelbar davor (falls noch erreichbar) bzw. die Info, was das Gerät zuletzt getan hat, hilfreich.

@betateilchen: danke für den zweiten Status — 2 statt 27 nach zwölf Stunden beantwortet die offene Frage, das Thema eskaliert nicht. Mit der neuen Schwelle sollten auch diese 2 verschwinden.

Zitat von: tostmann am 31 Juli 2026, 11:16:57@betateilchen: danke für den zweiten Status — 2 statt 27 nach zwölf Stunden beantwortet die offene Frage, das Thema eskaliert nicht. Mit der neuen Schwelle sollten auch diese 2 verschwinden.

Sieht gut aus mit .38:

"heap":{"free":61632,"min_free":42476,"total":255328,"largest_block":24564,"outbound_rejects":0}


Zitat von: tostmann am 31 Juli 2026, 11:16:57@Fred noch zu deinem Reboot-Hänger (ESP kam nach Software-Reboot nicht zurück, erst Stromtrennung half): das war bisher ein Einzelfall und ist aus der Ferne nicht bestimmbar — ich habe es notiert. Falls es wieder passiert, wäre der Status unmittelbar davor (falls noch erreichbar) bzw. die Info, was das Gerät zuletzt getan hat, hilfreich.

das kam auch bisher noch nicht vor. Und der Status zuvor war der 1. Status im letzten Posting von mir. Das war direkt vor dem Reboot.
Würde das aber aktuell auch nicht speziell bewerten und schauen ob sowas wieder mal vorkommt.

Ansonsten bin ich jetzt auch auf der .38

Direkt nach dem Reboot nach dem Update:
bei 2 der 8 Lautsprecher stehen die Presets alle auf "Push". Ein Browser Reload (also kein Status-Refresh benötigt) zeigt es dann wieder korrekt ohne die Push-Buttons bei den Presets an.
Dann sieht es bei allen 8 Lautsprechern gut aus.

Allerdings im Header bereits: ⚠ store: 1 preset save fail

{
  "name": "SixBack",
  "version": "0.8.38",
  "build": "2026-07-30 21:47:14",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 75,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -25,
    "channel": 11,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 124216,
    "min_free": 91096,
    "total": 339176,
    "largest_block": 59380,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8363308,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 9,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 1,
    "speakers": 8,
    "save_heap_aborts": 0,
    "save_nvs_fails": 1
  },
  "inventory": {
    "save_fails": 0
  },
  "health": {
    "boot_count": 2,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 1,
    "last_wifi_down_s": 0,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": -1
  }
}
Ich schaue weiter, ob noch Fehler kommen und melde dann den Status.

Es hat sich wieder etwas getan:
⚠ store: 1 preset save fail · 3 inventory save fails

{"name":"SixBack","version":"0.8.38","build":"2026-07-30 21:47:14","license":"PolyForm-Noncommercial-1.0.0","copyright":"Copyright (c) 2026 Dirk Tostmann","uptime_s":92667,"wifi":{"connected":true,"ssid":"hannebambel HOME","ip":"192.168.123.173","rssi":-22,"channel":11,"band":"2.4GHz","mac":"1C:DB:D4:74:9F:44","hostname":"sixback.local","improv_active":false,"improv_window_s":0,"captive_active":false,"captive_window_s":0},"heap":{"free":99020,"min_free":65576,"total":339176,"largest_block":44020,"outbound_rejects":0},"psram":{"free":8326572,"total":8388608},"chip":{"model":"ESP32-S3","cores":2,"revision":2,"flash_size":16777216},"cloud_replacement":{"port":8000,"base_url":"http://192.168.123.173:8000"},"speakers_count":9,"scan_in_progress":false,"groups_persist_ok":true,"preset_store":{"load_ok":true,"save_fails":1,"speakers":8,"save_heap_aborts":0,"save_nvs_fails":1},"inventory":{"save_fails":3},"health":{"boot_count":2,"crash_count":0,"wifi_reboots":0,"heap_reboots":0,"wifi_disconnects":1,"last_wifi_down_s":0,"last_reset":"SW","wdt_subscribed":true,"wifi_down_for_s":0,"heap_low_for_s":0,"heap_low_events":0,"last_heap_low_s":0,"last_ping_age_s":260}}
Was ich häufig habe: der Aufruf der sixback Seite zeigt bei ein paar Lautsprechern die Push-meldungen unter den Presets.
ein Browser reload reicht dann.

Und generell (entgegen meiner Mitteilung nach der.37) ist das webinterface bei mir nun sehr viel langsamer geworden als vorher.

Da es bei dem Problem mit den Push Meldungen scheinbar nur ein Anzeige Problem im Browser ist, weil ggfs. nicht alle Infos rechtzeitig zur Anzeige zu Verfügung stehen, könnte das ja auch auf ein Performance Problem hindeuten.
WLAN Verbindung schließe ich mal aus. Der sixback klebt quasi am Router...

Und noch ein Vorschlag:
Wäre es nicht besser, die punkte:
- Share diagnostic snapshots
- Web UI password
- Hostname (.local)
in den System-Bereich zu verschieben, damit man die Punkte zusammen mit System auch ausblenden kann.

@Fred: danke für den Status — genau dafür war der Split gedacht, und er hat direkt geliefert: save_heap_aborts 0 / save_nvs_fails 1 heißt, der Heap-Zweig (übergelaufenes JSON bei Speicherknappheit) ist als Ursache raus. Passt auch zu deinem Dump: der Heap war zu dem Zeitpunkt völlig gesund.

Was der Zähler genau bedeutet (damit die 1 richtig eingeordnet ist): er zählt erst hoch, wenn ein Save dreimal hintereinander fehlgeschlagen ist — erster Versuch plus zwei Wiederholungen, vor denen die Firmware automatisch regenerierbare Caches aus dem NVS räumt, um Platz zu schaffen. Der aktive Preset-Stand wird dabei konstruktionsbedingt nie angefasst (A/B-Verfahren: geschrieben wird immer nur eine Kopie, die erst nach erfolgreichem Zurücklesen aktiv wird). Deshalb sind bei dir trotz des Fehlschlags alle Presets da.

Was der Zähler nicht verrät: ob die NVS-Partition in dem Moment wirklich voll/knapp war oder ob es ein vorübergehender Schreib- bzw. Verifikationsfehler war. Dass es innerhalb der ersten Sekunden nach dem Boot passiert ist und spätere Saves offenbar durchliefen, macht mich da noch nicht festlegungsbereit.

Dazu eine Bitte — dafür brauchst du kein Update, der Endpoint ist in deiner S3-Version schon drin: ruf bitte einmal jetzt und einmal direkt nach dem nächsten Reboot

http://<stick-ip>/api/nvs/stats
ab und poste die Ausgabe (used/free/total entries). Daran sehen wir, ob der NVS-Speicher bei 9 Boxen tatsächlich an der Kante läuft oder komfortabel Platz hat — das entscheidet, wo ich weitergrabe.

Falls du den Stick gelegentlich per USB am Rechner hast: beim Auftreten steht die genaue Fehlerursache im seriellen Log (Zeilen, die mit [nvs-save] bzw. [nvs-cleanup] beginnen). Kein Muss — die stats-Ausgabe ist der wichtigere Datenpunkt.

Eine Beobachtung noch, ausdrücklich als offene Frage und nicht als Erklärung: in beiden Fällen (dein Post von gestern früh und jetzt) trat der eine save fail zusammen mit dem ,,Presets stehen auf Push"-Phänomen direkt nach dem Reboot auf. Dass ein reiner Browser-Reload es behebt, deutet auf die Anzeige-Seite — aber ob die beiden Dinge zusammenhängen, weiß ich noch nicht. Falls du die Push-Anzeige wieder siehst: steht der save-fail-Hinweis im Header dann schon vor dem Reload? Das würde die Reihenfolge klären.

Den Reboot-Hänger habe ich notiert — solange er nicht wieder auftritt, sehe ich das wie du.

Zitat von: tostmann am 01 August 2026, 15:39:56,,Presets stehen auf Push"-Phänomen direkt nach dem Reboot auf. Dass ein reiner Browser-Reload es behebt, deutet auf die Anzeige-Seite — aber ob die beiden Dinge zusammenhängen, weiß ich noch nicht. Falls du die Push-Anzeige wieder siehst: steht der save-fail-Hinweis im Header dann schon vor dem Reload? Das würde die Reihenfolge klären.

Das Phänomen mit "Presets stehen auf Push" hatte ich vor .38 auch regelmäßig. Aktuell ist mir das nicht mehr aufgefallen. Meistens hatte dann Geduld geholfen, das hat sich quasi immer von selbst erledigt.
Falls man ungeduldig war, hatte dann statt eines Browser-Refresh auch geholfen, wenn man bei der Box bei einem beliebigen preset auf "push" geklickt hat. Vermutlich hat das dann auch den Neuaufbau der angezeigten Seite im Browser ausgelöst. Eine Fehlermeldung wegen "save failed" hatte ich in diesen Fällen aber nicht.

den aktuellen Preset Save Fail den ich da habe, das ist immer noch der "eine" direkt nach dem Booten.
Aktuelle Uptime 1d 6h.
Neu hinzugekommen sind heute früh eben die 3 Inventory Save Fails.

Ansonsten ist es scheinbar wirklich ein Anzeige-Problem mit den "Push-Meldungen" bei den Preset von ein oder zwei Boxen (unterschiedliche und oft andere), was sich die Browser Reload beheben lässt. Sehe ich also auch weniger als Problem.

Aktuell, also bei momentan:
⚠ store: 1 preset save fail · 3 inventory save fails

sind die /api/nvs/stats so:
{
  "used_entries": 498,
  "free_entries": 132,
  "total_entries": 630,
  "namespace_count": 15,
  "percent_used": 79.04762
}
und nun habe ich mal einen Reboot gestartet. Mal sehen:

{
  "used_entries": 498,
  "free_entries": 132,
  "total_entries": 630,
  "namespace_count": 15,
  "percent_used": 79.04762
}
Also gleiche Werte.

Danke für die Zahlen — genau das brauchte ich.

Zu den nvs/stats: 79 % belegt / 132 freie Entries ist per se noch kein kritischer Füllstand. Der Save-Mechanismus hält beim Schreiben kurzzeitig den alten und den neuen Stand parallel im Flash (deshalb überlebt der aktive Stand einen fehlgeschlagenen Save) und braucht daher konstruktionsbedingt etwas Luft — entscheidend ist, ob der größte Einzel-Store beim Schreiben in die freien Entries passt. Dass deine Werte vor und nach dem Reboot identisch sind, zeigt zumindest: da wächst und leckt nichts.

Zum ,,einen" preset save fail nach dem Boot: die save-fail-Zähler zählen seit dem letzten Boot, sie werden nicht persistiert. Dein Muster heißt also: bei jedem Boot schlägt genau ein Save kurz nach dem Start fehl, danach läuft es über einen Tag sauber. Zu einer echten Platzgrenze passt das nicht — die würde auch später zuschlagen, und deine freien Entries sind ja stabil. Das ist ein Boot-Zeitfenster-Effekt; die Ursache kann ich noch nicht festnageln.

Was mir beim Durchsehen des Codes aufgefallen ist: die Firmware selbst stößt in deiner Konstellation (alle Boxen längst migriert) beim Boot keinen Preset-Save an — sämtliche Schreibpfade in den Preset-Store laufen über die Web-Oberfläche. Irgendetwas außerhalb des Sticks speichert also direkt nach dem Boot. Daher zwei Fragen:

• Ist bei dir typischerweise ein Browser-Tab mit der SixBack-Oberfläche offen, wenn der Stick rebootet?
• Greift FHEM (oder etwas anderes) automatisiert auf den Stick zu — auch nur lesend/pollend wäre interessant zu wissen?

Falls ja, würde das zeitlich auch zum ,,Presets auf Push"-Phänomen direkt nach dem Reboot passen — ob die beiden Dinge wirklich zusammenhängen, ist aber offen.

Die 3 inventory save fails von heute früh sind für mich das interessantere Signal, weil sie im laufenden Betrieb passiert sind. Weißt du noch, ob da zeitgleich etwas mit den Boxen los war (eine offline/online gegangen, Netzwerk-Ereignis)? Kamen die drei vermutlich auf einen Schlag oder verteilt?

Falls du seriell mitlesen kannst: die Zeilen, die mit "[nvs-save]" bzw. "[nvs-cleanup]" beginnen, aus der ersten Minute nach dem Boot würden die Fehlerklasse eindeutig machen — da steht konkret drin, ob der Write gar nicht erst gestartet wurde (inkl. ,,brauche ~X Entries, frei Y" zum genauen Zeitpunkt) oder ob er beim Schreiben bzw. Verifizieren scheiterte, und nebenbei liefern sie die realen Größen deiner Stores. Das wäre der letzte fehlende Baustein.

Zur Einordnung: Handlungsdruck sehe ich keinen — ein fehlgeschlagener Save verliert keine Presets (der aktive Stand bleibt unangetastet, der nächste erfolgreiche Save heilt), es werden dabei nur die im letzten Post beschriebenen regenerierbaren Caches aufgeräumt. Deine Presets sind ja nachweislich stabil.

Zitat von: tostmann am 02 August 2026, 00:43:38Ist bei dir typischerweise ein Browser-Tab mit der SixBack-Oberfläche offen, wenn der Stick rebootet?

Ja, ein Browser-Tab ist offen während eines gewollten Reboots (entweder nach Firmware Update oder klick auf Reboot)

Zitat von: tostmann am 02 August 2026, 00:43:38Greift FHEM (oder etwas anderes) automatisiert auf den Stick zu — auch nur lesend/pollend wäre interessant zu wissen?

es greift kein anderes System automatisiert auf SixBack zu. Also weder fhem noch was anderes.

Der eine Presets Save Fail kommt nicht direkt nach Reboot. Wenn nach Reboot Sixback wieder da ist habe ich ja das Anzeige-Problem bei ein oder zwei Lautsprechern mit "Push"... Wenn ich den Browser-Refresh der Seite anstosse um das zu lösen, dann kommt meist der Save Fail bei den Presets aber die Anzeige passt wieder.
Aber es kommt dann auch kein weiterer Save-Fail mehr hinzu.

Zitat von: tostmann am 02 August 2026, 00:43:38Die 3 inventory save fails von heute früh sind für mich das interessantere Signal, weil sie im laufenden Betrieb passiert sind. Weißt du noch, ob da zeitgleich etwas mit den Boxen los war (eine offline/online gegangen, Netzwerk-Ereignis)? Kamen die drei vermutlich auf einen Schlag oder verteilt?

Nein, da kann ich aktuell noch nichts eingrenzen. Aber die 3 waren auf einen Schlag da.

Aktuell keine weiteren Inventory Save Fails.

SixBack seit 13 Stunden online und ⚠ store: 2 preset save fails.

Eben war es nur 1 Save Fails als ich SixBack aufgerufen habe. Dann wieder Push-Meldungen bei 3 Lautsprechern. Browser Refresh, Anzeige passt wieder, aber es stehen nun 2 preset save fails.

{
  "used_entries": 504,
  "free_entries": 126,
  "total_entries": 630,
  "namespace_count": 15,
  "percent_used": 80
}
{
  "name": "SixBack",
  "version": "0.8.38",
  "build": "2026-07-30 21:47:14",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 50295,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -22,
    "channel": 11,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 111244,
    "min_free": 68736,
    "total": 339176,
    "largest_block": 50164,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8358916,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 9,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 2,
    "speakers": 9,
    "save_heap_aborts": 0,
    "save_nvs_fails": 2
  },
  "inventory": {
    "save_fails": 0
  },
  "health": {
    "boot_count": 1,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 0,
    "last_wifi_down_s": 0,
    "last_reset": "POWERON",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 191
  }
}
wie gesagt, das WebInterface ist insgesamt träge geworden, dauert einfach eine ganze Weile bis die Lautsprecher und die Presets gefüllt werden. Und ich denke, wenn es etwas zu lange dauert bleiben ein paar Lautsprecher mit den Push-Meldungen stehen. Ist aber wie schon verifiziert nur ein Anzeige-Problem.

Deine Beobachtung aus dem letzten Post — der Save-Fail kommt beim Browser-Refresh, nicht beim Boot — war der entscheidende Hinweis. Damit ließ sich der Pfad im Code eingrenzen, und ich bin fündig geworden. Es sind zwei getrennte Dinge, die beide beim (Neu-)Laden der Seite passieren.

Zur Push-Anzeige: beim Seitenaufbau fragt der Stick für jede Box parallel deren aktuelle Hardware-Presets ab. Schlägt so eine Abfrage fehl (Timeout, Box antwortet gerade nicht — bei 9 Boxen parallel kann das passieren), zeigt die Oberfläche das fälschlich als auf der Box ist nichts an, mit Push-Knopf — statt zu sagen Box gerade nicht erreichbar. Beim nächsten erfolgreichen Abruf (Reload, oder der Kontrollabruf nach einem Push) stimmt die Anzeige wieder. Das erklärt auch betateilchens Beobachtungen (Geduld heilt, Push-Klick heilt) und warum es wechselnde Boxen trifft. Reines Anzeigeproblem, wie ihr beide schon vermutet habt — aber jetzt mit benennbarer Ursache.

Zum Save-Fail: die Weboberfläche macht bei jedem frischen Seitenaufbau einen Abgleich — hat der Stick für eine Box noch keine Presets gespeichert, die Box selbst aber welche, importiert er sie automatisch (der Erstinstallations-Komfort). Dieser Import schreibt den kompletten Preset-Speicher neu in den Flash. Und bei dir gab es genau so eine Box: deine Statusabzüge zeigten bisher 9 Boxen im Inventar, aber nur 8 mit gespeicherten Presets — im heutigen Abzug sind es erstmals 9. Jeder frische Seitenaufbau hat diesen Import samt Schreibversuch ausgelöst, und der Schreibversuch scheitert bei dir. Eine Frage dazu: gibt es bei dir eine Box, für die du nie Presets über SixBack verwaltet hast (die aber selbst welche gespeichert hat)? Das würde das Bild abrunden.

Damit klärt sich auch dein offener Browser-Tab: nach einem Stick-Reboot lädt die offene Seite sich selbst neu (damit man nach einem Update nicht von Hand nachladen muss) — jeder Reboot mit offenem Tab ist also automatisch so ein frischer Seitenaufbau. Deshalb sah es nach einem Boot-Effekt aus, obwohl es keiner ist.

Offen bleibt, WARUM der Schreibversuch bei dir scheitert (Platz-Ablehnung vorab, Fehler beim Schreiben, oder Fehler beim Gegenlesen) — das steht nur in den seriellen Meldungen. Die gute Nachricht aus dem Befund: du musst dafür keinen Boot mehr abpassen. Serielle Konsole öffnen, in der Weboberfläche F5 drücken — wenn der Fail kommt, stehen die Zeilen sofort da:

[nvs-save] ...
[nvs-cleanup] ...
Wenn du das bei Gelegenheit einmal machen könntest, wäre die Fehlerklasse eindeutig. Auch dein zweiter Fail von gestern (der bei 13 h Laufzeit) ist mit dem Import allein noch nicht restlos erklärt — dieselben Zeilen würden das gleich mitklären.

Zur Einordnung wie gehabt: verloren geht dabei nichts, der aktive Bestand bleibt bei einem fehlgeschlagenen Save unangetastet. Beide Baustellen — die irreführende Push-Anzeige und der Import-Schreibversuch bei jedem Seitenaufbau — liegen auf meiner Seite; ich entschärfe sie in einer der nächsten Versionen.

v0.8.39 ist online. Die Partitionen sind unverändert, das Update geht also einfach über ⚙ SYSTEM in der Weboberfläche (Check for update → Install) oder frisch über sixback.io; die Dateien hängen wie immer auch am GitHub-Release.

Der Release setzt um, was sich aus den letzten Posts hier ergeben hat — freds Beobachtung, dass der save fail am Browser-Refresh hängt und nicht am Boot, war der entscheidende Hinweis. Drei Änderungen:

1. Eine Box, die auf die Preset-Abfrage nicht rechtzeitig antwortet, wird nicht mehr als ,,leer" angezeigt. Genau daraus entstanden die ,,Presets stehen auf Push"-Meldungen bei wechselnden Boxen: ein fehlgeschlagener Abruf lief durch denselben Pfad wie eine echte leere Antwort, und die Karte zeigte ,,on speaker: (empty)" samt Push-Knopf. Jetzt gilt ein fehlgeschlagener Abruf als unbekannt — der letzte bekannte Stand bleibt stehen, ansonsten steht am Slot ,,not reachable — retrying", es gibt dafür keinen Push-Knopf, und es wird automatisch nachgelesen. Das erklärt auch, warum bei betateilchen Geduld oder ein Klick auf Push das Problem ,,heilte": beides führte schlicht zu einem neuen, diesmal erfolgreichen Abruf.

2. Der automatische Preset-Import von einer Box meldet jetzt ehrlich, wenn das Speichern in den Flash gescheitert ist. Bisher meldete er Erfolg, die Presets lagen dann aber nur im RAM und waren beim nächsten Neustart weg, ohne dass irgendwo etwas davon zu sehen war. Jetzt kommt eine klare Meldung in der Oberfläche, zusätzlich zum bekannten ⚠-store-Hinweis im Kopf.

3. Ein gescheiterter Import wiederholt sich nicht mehr bei jedem Seitenaufbau. Jeder dieser Versuche schrieb den kompletten Preset-Bestand neu und räumte im Fehlerfall regenerierbare Caches weg — bei einem Gerät an der Speichergrenze passierte das bei jedem Reload aufs Neue. Jetzt pausiert der automatische Import für die betroffene Box, bis irgendein Speichern wieder durchläuft oder der Stick neu startet.

Zur Einordnung, damit keine falschen Erwartungen entstehen: die Warum-Frage — weshalb der Schreibversuch bei dir, fred, überhaupt scheitert — ist damit noch nicht beantwortet. Du wirst nach einem Reboot beim ersten Seitenaufbau voraussichtlich weiterhin einen save fail sehen, jetzt aber mit klarer Meldung und ohne stilles Wiederholen. Meine Fragen aus dem letzten Post bleiben deshalb aktuell, besonders die, ob es bei dir eine Box gibt, deren Presets du nie über SixBack verwaltet hast.

Ein Hinweis zum seriellen Mitlesen, weil sich das mit .39 leicht ändert: da der Import nach einem Fehlschlag pausiert, löst F5 den Schreibversuch nicht mehr jedes Mal aus. Zwei einfache Wege bleiben — den ersten Seitenaufbau nach einem Reboot mit offener serieller Konsole erwischen, oder einfach irgendein Preset einmal neu speichern; auch das schreibt den kompletten Bestand und läuft in denselben Fehler, die Zeilen erscheinen sofort:

[nvs-save] ...
[nvs-cleanup] ...
Noch zur Verifikation: die Fehlerpfade lassen sich im Feld schlecht nachstellen, deshalb wurde mit einem Testbuild geprüft, der den Schreibfehler künstlich erzwingt — gemeldeter Fehlschlag, unterdrückte Wiederholung und automatische Wieder-Freigabe nach einem erfolgreichen Speichern sind auf Hardware bestätigt.

Erstmal Danke für Deine super schnellen Reaktionen... (hast wohl auch nicht gerne ToDos auf deiner internen Liste :D )

Zitat von: tostmann am 02 August 2026, 12:23:05Eine Frage dazu: gibt es bei dir eine Box, für die du nie Presets über SixBack verwaltet hast (die aber selbst welche gespeichert hat)? Das würde das Bild abrunden.

Also bei mir werden 8 Lautsprecher über SixBack verwaltet. 1 Lautsprecher (bzw. ist es ein Soundtouch Wireles Link) wird über ST Reborn gesteuert. Dieses Device ist in SixBack als HIDE markiert und ausgeblendet. Mehr kann ich hier ja nicht machen, löschen bringt auch nichts, weil ein Reboot ihn automatisch wieder findet.
Dazu bräuchte es eine White- oder Blacklist mit IPs der gewünschten Lautsprecher.

Das mit dem Log werde ich versuchen. Kann den Stick morgen tagsüber mal an den PC hängen und ausprobieren welche Meldungen kommen.

hab eben auf die .39 upgedated:
Nach dem ersten Reboot der Seitenrefresh sah eigentlich gut aus. Aber unten rechts kam als er fertig war kurz eine Meldung, Presets could not be write in the flash ... und dass sie beim nächsten Reboot verloren wären .... oder so ähnlich. Die Meldung war zu schnell weg.
Im Header steht also wieder 1 Preset save fail.
Anzeige sieht aber komplett gut aus.

OK. Also ich werde das morgen mit dem Log mal testen und schauen ob man was sieht.

Danke fürs schnelle Update und die Rückmeldung. Dass die Anzeige jetzt komplett gut aussieht, ist genau das, was der erste der drei Fixes bewirken sollte — der Push-Phantom-Teil ist damit vom Tisch.

Die Meldung, die zu schnell weg war

Da hast du gleich zwei Fehler auf einmal gefunden. Erstens verschwand jede Meldung nach vier Sekunden, egal was drinstand — auch eine, die sagt, dass die Presets nur im RAM stehen und beim nächsten Neustart weg sind. Zweitens war ausgerechnet diese Meldung im Code gar nicht als Fehler markiert, sie wurde also grün wie eine Erfolgsmeldung angezeigt. Beim Nachsehen kamen noch 19 weitere Fehlermeldungen dazu, die aus demselben Grund grün und flüchtig waren: Push failed, Play failed, Import failed, Set/Swap/Rename und die Ablehnungen beim Drag-and-Drop.

Ab dem nächsten Update bleiben rote Fehlermeldungen stehen, bis man sie wegklickt — Klick auf die Meldung selbst oder auf das ×. Grüne Erfolgsmeldungen verschwinden weiter nach vier Sekunden. Falls das im Alltag stört, gibt es dann im System-Bereich einen Schalter "Keep error messages on screen", der es wieder auf das alte Verhalten zurückstellt. Der Schalter gilt für den Browser, in dem du ihn umlegst, und wird nicht auf dem Stick gespeichert — auf einem Gerät, dem der Flash-Platz ausgeht, hat eine reine Anzeige-Einstellung dort nichts verloren.

Zum versteckten Wireless Link

Der ist nach allem, was ich im Code sehe, nicht der Auslöser. Versteckte Geräte werden gar nicht erst geladen, und damit läuft für sie auch kein automatischer Preset-Import. Der Import, der bei dir den Schreibfehler auslöst, gehört also zu einer der acht Boxen, die du tatsächlich über SixBack verwaltest.

Eine Rückfrage dazu, damit ich das nicht falsch annehme: klappst du die Zeile "N hidden speaker(s) — click to show" unter der Geräteliste manchmal auf? Solange die zugeklappt bleibt, gilt das oben Gesagte. Im aufgeklappten Zustand wird die versteckte Box mitgeladen, und dann kann sie sehr wohl mitspielen.

Warum es genau ein Fehler pro Neustart ist

Das deckt sich mit deiner Beobachtung, dass danach kein weiterer dazukommt. Wenn ein Import den Flash nicht schreiben kann, merkt sich SixBack dieses Gerät und versucht es nicht wieder — allerdings nur bis zum nächsten Neustart, denn diese Merkliste steht im RAM. Nach jedem Reboot gibt es also genau einen Versuch, der scheitert, danach ist Ruhe. Deshalb springt der Zähler im Header auf 1 und bleibt dort.

Was damit ausdrücklich nicht geklärt ist: warum der Schreibvorgang überhaupt scheitert. Dein Dump zeigt 504 von 630 belegten Einträgen, und das ist die Kapazitätsgrenze, an der wir das im Labor ebenfalls reproduzieren konnten. Was seit v0.8.34 gilt, ist, dass an dieser Kante ein sauberer Fehler entsteht statt eines Datenverlusts — größer wird die Kapazität dadurch nicht.

Zum Log morgen

Serielle Konsole mit 115200 Baud, und interessant sind genau zwei Zeilenarten:

[import] <Geraet>: N Presets im RAM, aber NVS-Persist FEHLGESCHLAGEN
[nvs-save] FAIL ...

Die erste sagt, welche Box es ist. Die zweite sagt, woran es liegt: je nachdem steht dort REFUSED (der Platz reicht schon vor dem Schreiben nicht), FAIL putBytes (das Schreiben selbst bricht ab), FAIL readback oder FAIL gen-commit. Das ist der Unterschied zwischen "Partition voll" und "es stimmt etwas anderes nicht", und genau den kann ich aus der Ferne nicht raten — deshalb ist dein Log der nächste sinnvolle Schritt und nicht noch eine Vermutung von mir.

Ausgelöst wird es beim ersten Laden der Seite nach einem Neustart, oder wenn du irgendein Preset speicherst. Ein bloßer F5-Refresh reicht seit v0.8.39 nicht mehr, weil der gescheiterte Import ja gesperrt wird.

Zur White-/Blacklist

Der Punkt ist berechtigt: HIDE ist heute reine Anzeige, das Gerät bleibt im Inventar und wird beim Reboot wiedergefunden. Ich würde damit trotzdem warten, bis dein Log da ist. Wenn der Schreibfehler an einer der acht verwalteten Boxen hängt, löst eine Ignore-Liste ihn nämlich nicht, und ich möchte ungern die falsche Baustelle aufmachen.

vorab. den Hidden-Speaker klappe ich nicht auf. Es ist also nur die eine Zeile zu sehen: 1 hidden speaker(s) — click to show


Ansonsten. Habe nach dem Reboot (angeschlossen am PC) mal geschaut, was für Log-Einträge kommen.

[11:03:45][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=9603 blob=4846 wrote=0 (hs)
[11:03:45][nvs-cleanup] sixback-pre/presets save fail — pass1 purging caches + retry
...
[11:03:45][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=9603 blob=4846 wrote=0 (hs)
[11:03:45][nvs-cleanup] sixback-pre/presets pass1-fail — pass2 wider purge
...
[11:03:46][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=9603 blob=4846 wrote=0 (hs)
[11:03:46][nvs-cleanup] sixback-pre/presets -> STILL-FAIL — NVS partition genuinely full (aktiver Stand bleibt konsistent)
[11:03:46][preset] saveToNVS FAILED (nvs write, #1)
[11:03:46][import] B0D5CC3D160E: 6 Presets im RAM, aber NVS-Persist FEHLGESCHLAGEN
[11:03:48][heartbeat] up=30s  RSSI=-76  free-heap=117276  PSRAM-free=8352284
...

Also es sieht so aus. Habe jetzt "unzählige" Neustarts gemacht. Neben dem reinen Anzeigeproblem (teilweise mit Push-Meldung, teilweise sogar mal wieder "leere Presets"), was verschiene Lautsprecher betreffen kann, was aber mit Browser-Refresh behoben werden kann, kommt der Save-Fail eigentlich immer bei der gleichen Box.

Die Box funktioniert aber ohne Probleme, hat ihre Speicher etc. Und im Webif sieht genau diese Box auch dementsprechend aus.

Es ist halt beim Reboot im Webif die besagte "grüne" Meldung zu sehen, die eigentlich rot sein sollte. Wie vorher schon beschrieben.

Ansonsten läuft alles.

Vielleicht sollte ich diese Box nochmal komplett zurücksetzen und neu starten?! Das werde ich testen.

fange ein neues Posting an...

Habe diese "Problembox" nun mal zurückgesetzt und neu eingerichtet, WLAN, usw. Nun ist sie in SixBack wieder zu sehen. Es steht aber noch dort, dass sie bereits migriert ist.
Egal. Habe auch Resync-Sources durchgeführt.

alle 6 Presets sind leer bei der Box. Auch nach Reboot vom SixBack.

Aber ich kann keine Presets speichern. Wenn ich versuchen einen Radio Sender auf einen Preset zu ziehen, kommt wieder die "grüne" Meldung unten rechts.
Und im Log tauchen diese Meldungen auf:
[11:48:14][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=8305 blob=3918 wrote=0 (hs)
[11:48:14][nvs-cleanup] sixback-pre/presets save fail — pass1 purging caches + retry
[11:48:14][134575][E][Preferences.cpp:539] getBytesLength(): nvs_get_blob len fail: presets~ NOT_FOUND
[11:48:14][134584][E][Preferences.cpp:93] remove(): nvs_erase_key fail: presets~ NOT_FOUND
[11:48:14][134891][E][Preferences.cpp:291] putBytes(): nvs_set_blob fail: presets~ NOT_ENOUGH_SPACE
[11:48:14][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=8305 blob=3918 wrote=0 (hs)
[11:48:14][nvs-cleanup] sixback-pre/presets pass1-fail — pass2 wider purge
[11:48:15][135021][E][Preferences.cpp:539] getBytesLength(): nvs_get_blob len fail: presets~ NOT_FOUND
[11:48:15][135029][E][Preferences.cpp:93] remove(): nvs_erase_key fail: presets~ NOT_FOUND
[11:48:15][135245][E][Preferences.cpp:291] putBytes(): nvs_set_blob fail: presets~ NOT_ENOUGH_SPACE
[11:48:15][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=8305 blob=3918 wrote=0 (hs)
[11:48:15][nvs-cleanup] sixback-pre/presets -> STILL-FAIL — NVS partition genuinely full (aktiver Stand bleibt konsistent)
[11:48:15][preset] saveToNVS FAILED (nvs write, #1)
Demnach kann ich diese Box nicht mehr einrichten. Selbst der PlayBack eines Radio-Senders als Preview auf dieser Box scheitert mit einem "Speaker-Preview Error HTTP 502".

werde die Box nun mal versuchen mit dem 2. SixBack (den ich bisher nicht brauchte) einzurichten.


edit:
Box ist nun mit dem 2. SixBack wieder eingerichtet. Und im Anschluss habe ich sie wieder auf den 1. SixBack migriert.

D.h. ich lebe jetzt erstmal mit den Save-Fails und beobachte weiter was mir noch so auffällt.

Möchte echt vermeiden einen 2. SixBack zu benötigen.

sorry, noch ein Post...

Jetzt sind ja wieder 8 Lautsprecher (alle verwaltet vom SixBack) zu sehen und die Wireless Link (9. Lautsprecher steht auf HIDE).
Screenshot 2026-08-03 092645.jpg

komischerweise habe ich seit dem nun keine "Push-Meldungen" mehr bei irgendeinem der 8 Lautsprecher gesehen... bisher.

Aber trotzdem wieder:
⚠ store: 1 preset save fail · 7 inventory save fails


Eine Frage noch zu den eigenen Stream-Urls. Diese kann man ja Exportierung und importieren.
Hatte hier bisher immer 8 Streams abgelegt. Wo sind die auf dem SixBack gespeichert? In einem kritischen Speicherbereich?
Hab die URLS nun dort erstmal gelöscht:
Screenshot 2026-08-03 131722.jpg

Wenn die eher unkritisch sind importiere ich sie auch wieder. Aktuell werden sie eigentlich aber nicht benötigt. Mache momentan alles über tunein (die haben einfach die besten Infos als Anzeige auf den Lautsprecher-Displays, u.a. Titel-Infos, usw. das gibts nur bei TuneIn)

Danke für die Logs und die Screenshots — damit ist das Bild jetzt vollständig, und deine Experimente haben die Diagnose sogar noch schärfer gemacht. Der Reihe nach.

Was dein Log endgültig beweist

[E][Preferences.cpp:291] putBytes(): nvs_set_blob fail: presets~ NOT_ENOUGH_SPACE
Diese Zeile ist der rohe Fehlercode aus dem Speichersystem selbst, und er beantwortet die Warum-Frage abschließend: der reservierte Flash-Bereich (NVS) hat schlicht nicht mehr genug Platz. Kein Defekt, keine Größenbeschränkung eines einzelnen Datensatzes — der Bereich ist voll. Dein gescheiterter Versuch, einen Sender per Drag-and-Drop auf ein Preset zu ziehen, bestätigt leider auch die unangenehme Konsequenz aus meinem Befund: in diesem Zustand kann der Stick gar keine Preset-Änderung dauerhaft speichern, an keiner Box. Die NOT_FOUND-Zeilen dazwischen sind übrigens harmlos — da prüft die Schutzmechanik einen Reserve-Ablageplatz, der noch nicht existiert; das ist der Normalfall, kein Fehler.

Auch die 7 inventory save fails passen exakt ins Bild: die Geräteliste schreibt in denselben Bereich, dein Neu-Einrichten und Zurück-Migrieren hat mehrere Schreibversuche ausgelöst, und die sind an derselben Grenze gescheitert. Gleiche Ursache, kein zweites Problem.

Zur Box selbst: schade um die sechs Presets — die existierten dauerhaft nur auf der Box, weil der Stick sie ja nie sichern konnte; genau davor wollte ich dich noch warnen, da warst du schneller. Gut, dass du sie über den zweiten Stick wiederherstellen konntest. Den Preview-Fehler (HTTP 502) in diesem Fenster kann ich von hier aus nicht sicher zuordnen — falls er nach dem Neu-Einrichten wieder auftaucht, sag Bescheid.

Deine Stream-Frage — und warum das Löschen ein Volltreffer gewesen sein könnte

Ja: die eigenen Stream-URLs liegen im selben reservierten Bereich, als ein gemeinsamer Datensatz mit den vollen URLs. Acht Einträge mit langen URLs sind dort ein spürbarer Posten. Dein Löschen war also genau der richtige Gedanke — es gibt echten Platz frei, und es ist gut möglich, dass das deine Lage bereits entspannt hat.

Deshalb eine konkrete Bitte: zieh einfach nochmal einen Sender auf ein Preset. Wenn das jetzt ohne Fehlermeldung durchgeht, ist der Knoten geplatzt — und beim nächsten Seitenaufbau übernimmt der Stick dann auch die Presets der neu eingerichteten Box wieder automatisch (der Automatik-Import pausiert nach einem Fehlschlag absichtlich, bis irgendein Speichern wieder klappt — ein erfolgreiches manuelles Speichern löst diese Pause).

Zwei ehrliche Anmerkungen dazu: Ob das Löschen der Streams selbst dauerhaft gespeichert wurde, zeigt erst ein Neustart des Sticks — bleiben die Streams danach weg, ist es gesichert. Die Chancen stehen gut, weil dieser Schreibvorgang winzig ist, aber versprechen kann ich es nicht. Und mit dem Wieder-Importieren würde ich warten: jeder Import belegt den Platz wieder, und du stehst mit neun Boxen ohnehin dicht an der Grenze. Solange TuneIn dich abdeckt, lass sie draußen, bis ich die Ablage umgestellt habe.

Wie es weitergeht

An der Einordnung ändert sich nichts: das ist eine Grenze der jetzigen Ablage (ein gemeinsamer Datensatz für alle Boxen), nicht deiner Hardware. Der saubere Weg ist, die Presets pro Box einzeln abzulegen — dann muss bei einer Änderung nicht mehr alles auf einmal passen, und eine einzelne Box kann den Rest nicht blockieren. Das schaue ich mir jetzt an und melde mich, wenn es dazu etwas Belastbares gibt. Einen zweiten SixBack brauchst du dafür ausdrücklich nicht — dein Fall hat die Diagnose komplett gemacht, danke für die Geduld und die gründlichen Rückmeldungen.

ein weiteres Speichern eines Presets geht nicht. Gerade probiert. Speicher scheint voll zu sein.

Ok. Aber momentan haben ja alle ihre passenden Presets. Also erstmal OK soweit.

Danke fürs sofortige Ausprobieren — das Ergebnis ist zwar ernüchternd, aber es ist eine wertvolle Antwort.

Ehrlich eingeordnet gibt es dafür zwei mögliche Erklärungen, und ich kann von hier nicht unterscheiden, welche zutrifft. Entweder hat das Löschen der Streams schlicht nicht genug Platz freigegeben. Oder — und das muss ich offen zugeben — das Löschen selbst wurde gar nicht dauerhaft gespeichert: es läuft nämlich durch denselben klemmenden Schreibpfad wie alles andere, und die Oberfläche zeigt dessen Ergebnis nicht an. Das ist dieselbe Sorte Schweigen, die ich bei der Import-Meldung schon einräumen musste; auch das kommt auf die Fix-Liste.

Den Unterschied siehst du ganz nebenbei beim nächsten regulären Neustart des Sticks: tauchen die acht Streams dann wieder auf, war es das Zweite. Kein Extra-Test nötig — nur falls es dir auffällt, sag kurz Bescheid.

Ansonsten musst du an deinem Setup nichts weiter machen: alle Boxen haben ihre Presets, und dein Gerät läuft stabil — die Schutzmechanik hält den gespeicherten Stand ja zuverlässig fest. Die eigentliche Lösung liegt bei mir: die Ablage pro Box umzustellen, damit ein einzelner großer Schreibvorgang gar nicht mehr nötig ist. Genau daran, dass sich dein Gerät derzeit auch durch Löschen nicht selbst freischaufeln kann, sieht man übrigens, warum das der richtige Weg ist — jede Verkleinerung ist im Moment selbst ein Schreibvorgang und scheitert an derselben Grenze. Danke für deine Geduld heute, das war ein produktiver Tag für die Diagnose.

(offtopic - nur interessehalber)

Zitat von: tostmann am 03 August 2026, 23:07:42Die eigentliche Lösung liegt bei mir: die Ablage pro Box umzustellen

Was war die Intention dahinter, eine Ablage pro Box umzusetzen?

"Früher" - zu Bose-Zeiten - hatten alle Boxen eines Accounts die gleichen presets, und wenn an einer Box ein preset geändert wurde, wurde das auf die anderen Boxen übertragen. Grundsätzlich fand ich das sehr praktisch, weil ich immer genau wusste, welchen Sender ich höre, wenn ich "Preset 5" drücke - egal auf welcher Box.

Gute Frage — und ich merke, dass "Ablage pro Box" missverständlich war. Es geht dabei nicht um das Bedienmodell, sondern nur darum, wie der Stick die Presets intern in seinen Flash schreibt.

Bisher legt er den Stand aller Boxen als einen einzigen großen Datensatz ab. Jede Änderung an einer einzigen Box schreibt also den kompletten Block neu — und genau der ist bei fred an die Kapazitätsgrenze gestoßen. Ab sofort bekommt jede Box ihren eigenen kleinen Datensatz; ein Speichern schreibt dann rund ein Kilobyte statt des Gesamtblocks. Das ist reine Speichertechnik, an der Oberfläche ändert sich dadurch nichts.

Am Bedienmodell ändert sich auch deshalb nichts, weil SixBack die Presets von Anfang an pro Box geführt hat — jede Box hat ihre eigene Karte mit ihren sechs Slots. Ohne Cloud-Account steht eben erstmal jede Box für sich.

Dein Bose-Verhalten (überall dieselbe Belegung) gibt es trotzdem, nur explizit statt automatisch: der Button "⇄ Sync presets to group" kopiert die sechs Slots einer Quell-Box auf beliebige Ziel-Boxen. Das befüllt zunächst die Ablage im Stick; anschließend zeigt jede Ziel-Box einen "Push 1-6"-Button, der die Belegung dann tatsächlich auf die Tasten der Box schreibt. Danach liegt auf jeder Box unter derselben Taste derselbe Sender. Der Unterschied zu früher ist, dass eine spätere Änderung an einer Box nicht von selbst auf die anderen wandert — das Kopieren müsstest du dann erneut anstoßen.

Und damit direkt zur guten Nachricht für den ganzen Thread: v0.8.40 ist soeben erschienen und enthält genau diese Umstellung — zusammen mit den versprochenen Fixes an den Fehlermeldungen: Fehler erscheinen jetzt rot statt grün und bleiben stehen, bis man sie wegklickt (wem das zu aufdringlich ist: abschaltbar unter System), und die Preset-Abfrage nicht erreichbarer Boxen pausiert nach drei schnellen Versuchen, statt im Sekundentakt weiterzulaufen.

fred, für dich konkret: Update über ⚙ SYSTEM im Web-Interface oder über sixback.io — das Update selbst schreibt an deinem vollen Speicherbereich vorbei und funktioniert trotz der Schreibsperre, das hat dein Sprung auf 0.8.39 ja schon gezeigt. Beim ersten Start danach stellt der Stick die Ablage automatisch um; genau dieser Weg, inklusive deiner randvollen Ausgangslage, ist auf Test-Hardware nachgestellt und verifiziert. Danach zieh bitte einmal testweise einen Sender auf ein Preset — das sollte jetzt wieder speichern. Und falls deine acht gelöschten Streams nach dem Update wieder auftauchen, wäre das nebenbei die Bestätigung, dass die Löschung damals nie ankam: dann lösch sie einfach nochmal und sag kurz Bescheid, ob sie nach einem weiteren Neustart weg bleiben.

Noch ein Hinweis fürs Protokoll: eine ältere Firmware liest die neue Ablage nicht. Wer von 0.8.40 wieder zurück auf eine ältere Version geht, sieht im Stick zunächst einen leeren Preset-Store, der sich per Auto-Import von den Boxen neu füllt — die Presets auf den Boxen selbst bleiben davon unberührt.

vorab: die eigenen Stream-Adressen waren nach der Löschung tatsächlich gelöscht, auch nach Reboot also nicht mehr zu sehen.

Ansonsten: Bin nun auf der .40

Erster Boot danach: bei der einen "bekannten" Box standen die Presets auf Push. Browser reload. Dann sind die Sender ok. Unten rechts wieder die Meldung, dass die Presets nicht alle gespeichert werden konnten, ... wie gehabt.

Ein manueller Drop eines neuen Radiosenders auf ein Preset bei der Box kommt auch die Meldung, dass nicht gespeichert werden kann.
Ein Push bei dem Preset speichert es über den bekannten Weg dann trotzdem auf der Box, aber halt nicht auf dem SixBack.

Dann nochmal einen Reboot gemacht.

Nun stehen bei dieser Box alle Presets auf den von der Box erhaltenen Einträgen mit jeweils einem Empty Eintrag von SixBack als "neuen" Sender darunter. Klar, SixBack hat ja keine der Presets dieser Box gespeichert. Also wieder manuell die einzelnen Einträge draufgezogen. Dabei kamen teilweise grüne Meldungen, dass gespeichert wurde, teilweise rote Meldungen, dass nvs voll wäre.
Am Ende sah es wieder gut aus.

Dann neuer Reboot. Nun ist der SixBack erstmal nicht erreichbar. Hat also das Reboot nicht geschafft.
Bin leider unterwegs und kann von hier nicht den Stecker ziehen.

Werde ihn also später zuhause vom Strom trennen und nochmal starten lassen.

Meine Vermutung wäre nun, dass bei der Box nicht mehr alle Presets mit PUSH erscheinen, sondern eben nur die, die er nicht speichern konnte... Bin gespannt.

Mein bisheriges Fazit: Bin mit den 8 Lautsprechern immer noch an bzw. leicht über der Grenze. Bei ca. 2 oder 3 Presets kam keine Fehlermeldung wegen Speicherung. Also ist es wohl "etwas" besser als vorher.
Somit wäre bei mir wohl mit 7 Lautsprechern alles belegt! Werde es aber nun so belassen, da ich nicht wegen dem 8. Lautsprecher und dem 9. Device (Wireless Link mit anderem Projekt) einen weiteren SixBack laufen lassen möchte.

Denke ich kann da erstmal so mit umgehen.




edit:  SixBack war wieder erreichbar... Und wie meine Vermutung oben hat es sich bestätigt. Bei der Box sind die Push-Meldungen nur bei 2 Presets. Scheinbar sind bis auf 2 Presets nun alle im Sixback gespeichert.

Zitat von: fred_feuerstein am 01 August 2026, 14:33:54Und noch ein Vorschlag:
Wäre es nicht besser, die punkte:
- Share diagnostic snapshots
- Web UI password
- Hostname (.local)
in den System-Bereich zu verschieben, damit man die Punkte zusammen mit System auch ausblenden kann.

Ich möchte das nochmal aufgreifen. Mit
- Keep error messages on screen
ist ja nun noch ein weiterer Punkt hinzugekommen.

Der Übersichtlichkeit wegen fände ich es besser, diese mittlerweile 4 Punkte, die man ja ohnehin nicht laufend ändern muss, in den SYSTEM Bereich zu verschieben, damit es mit dem SYSTEM Tab (also den System-Infos, Update usw.) zusammen ein- und ausgeblendet werden kann.

Screenshot 2026-08-06 075340.jpg


Theoretisch eigentlich auch den Punkt oben auf der SixBack-Seite:
- Auto-Migrate at Boot.
Der könnte auch in den SYSTEM-Bereich verschoben werden, da im "Normalfall" nur einmal bei der ersten Einrichtung benötigt.

Das würde die Seite übersichtlicher halten.

Alternativ könntest Du auch, wenn SYSTEM nicht dafür verwendet werden soll, einen weiteren TAB unterhalb von SYSTEM einbauen. Bspw. CONFIG, den man dann auch auf- und einklappen kann.

Was meinst Du?

Zitat von: fred_feuerstein am 06 August 2026, 07:55:27eigentlich auch den Punkt oben auf der SixBack-Seite:
- Auto-Migrate at Boot.
Der könnte auch in den SYSTEM-Bereich verschoben werden, da im "Normalfall" nur einmal bei der ersten Einrichtung benötigt.

Laßt bitte diesen Schalter da, wo er jetzt ist.
Manchmal möchte man die Auto-Migration abschalten, bevor sie anfängt zu suchen.
Dafür hat man nur ein sehr kurzes Zeitfenster und da möchte ich nicht auch noch Tabs aufklappen müssen, um den Schalter zu finden.

Bei den restlichen Vorschlägen bin ich prinzipiell dabei.
Obwohl mich auch der jetzige Seitenaufbau nicht wirklich stört.

@fred: Danke für den ausführlichen Bericht zur .40 — das Bild passt zu dem, was die Umstellung erreichen sollte. Gespeichert wird jetzt pro Box einzeln: was beim Schreiben noch Platz gefunden hat, übersteht den Reboot; nur was nicht mehr gepasst hat, steht danach wieder auf Push. Vorher scheiterte stattdessen die eine große Schreiboperation komplett. Mehr Gesamtplatz zaubert das nicht — dein Fazit "mit 7 Lautsprechern wäre alles belegt, mit 8 knapp drüber" deckt sich mit meiner Erwartung.

Zu dem Stick, der nach dem Reboot erst mal nicht erreichbar war: aus der Ferne kann ich dazu nichts Belastbares sagen, und raten will ich nicht. Falls das wieder auftritt: einmal http://<stick-ip>/api/status aufrufen und mir aus dem health-Block die Werte boot_count und crash_count posten — daran sehe ich, ob der Stick beim Hochfahren abgestürzt und neu gestartet ist oder einfach nur lange gebraucht hat.

Zum UI-Vorschlag: einverstanden, das ist konsequent. Die vier Punkte (Share diagnostic snapshots, Web UI password, Keep error messages on screen, Hostname) wandern in den SYSTEM-Bereich — dann sind sie zusammen mit den System-Infos mit einem Klick aus dem Blickfeld, und die Seite gehört wieder den Lautsprechern. Einen zusätzlichen CONFIG-Tab spare ich mir dafür: SYSTEM ist ja genau der Sammelplatz für alles, was man selten anfasst.

@betateilchen: Punkt genommen — Auto-Migrate at Boot bleibt, wo er ist. Das ist der einzige Schalter, den man schnell erreichen muss, bevor die Migration loslegt; der gehört nicht hinter einen Klapp-Bereich.

Kommt mit einem der nächsten Updates.

v0.8.41 ist da — mit den Umbauten aus euren beiden Vorschlägen.

@fred: wie zugesagt sind die vier selten geänderten Punkte (Share diagnostic snapshots, Web UI password, Keep error messages on screen, Hostname) jetzt im SYSTEM-Bereich. Damit klappen sie zusammen mit den System-Infos weg und die Seite gehört wieder den Lautsprechern. Einen zusätzlichen CONFIG-Tab habe ich mir gespart — SYSTEM ist ohnehin der Platz für alles, was man einmal einstellt und dann liegen lässt.

@betateilchen: Auto-Migrate at Boot bleibt wie gewünscht oben stehen. Das Zeitfenster, in dem man ihn ausschalten will, ist zu kurz, um vorher noch etwas aufklappen zu müssen.

Dazu zwei Dinge, die mit dem Speicherplatz zu tun haben und beim letzten Mal noch offen waren:

Eigene Stream-Adressen melden jetzt ehrlich, ob sie gespeichert wurden. Die Stream-Liste wurde bisher als Ganzes weggeschrieben und das Ergebnis verworfen — Anlegen, Importieren und Löschen meldeten also immer Erfolg. Bei vollem Speicher war das denkbar ungünstig: ein gelöschter Sender war vom Bildschirm verschwunden, lag aber weiter im Flash und kam beim nächsten Neustart zurück. Genau deshalb war die Frage "hat das Löschen der Streams Platz gebracht?" nicht zu beantworten. Jetzt sagt das Gerät, was wirklich passiert ist: beim Anlegen, dass der Eintrag nur im Speicher steht und beim Neustart weg ist, beim Löschen, dass der Sender nach einem Neustart wieder auftaucht.

Nicht erreichbare Lautsprecher sehen nicht mehr aktuell aus. Antwortet eine Box nicht, zeigt die Oberfläche weiter den letzten bekannten Stand — das ist richtig so, besser als eine Box, die fälschlich leer wirkt. Dieser Stand sah aber aus wie frisch gelesen, man konnte also gegen eine Anzeige von vor ein paar Minuten pushen. Solche Einträge sind jetzt mit (stale) markiert, solange die Box schweigt.

Update wie immer über die Weboberfläche unter SYSTEM → Online update, oder per Webflasher.

Getestet auf ESP32-S3, -C6 und -C5, inklusive des Falls "Speicher wirklich voll" und einem Neustart, der beweist, dass die neuen Meldungen stimmen.

Das ist prima mit dem Verschieben der 4 Einträge in den System Tab.

Den Auto Migrate Eintrag oben, da habt ihr ja recht, den muss man auch mal schnell erreichen können.

Zitat von: tostmann am 06 August 2026, 17:37:59@betateilchen: Auto-Migrate at Boot bleibt wie gewünscht oben stehen. Das Zeitfenster, in dem man ihn ausschalten will, ist zu kurz, um vorher noch etwas aufklappen zu müssen.

Für den Wunschzettel, wenn mal alles andere erledigt ist:
Beim Aufruf von http://sixback.local/stop die Oberfläche direkt mit ausgeschalteter Migration erreichen...

Hallo fred,

v0.8.42 ist raus — mit einem Fix, der genau an dem Muster hängt, das dein Status-Dump in #156 gezeigt hat.

Zur Erinnerung die Kette dort: eine Box, deren Presets nie in den Flash geschrieben wurden, hat nach dem nächsten Neustart keinen Eintrag mehr im Speicher des Sticks — und war danach auch am Lautsprecher selbst leer. Der zweite Teil war der eigentlich böse: die Presets lagen ja im Gerät.

Ursache: wenn der Stick die Account-Abfrage des Lautsprechers beantwortet und der Geräte-Block darin keine Preset-Liste enthält, liest die Bose-Firmware das nicht als ,,unverändert", sondern als ,,der Account hat keine Presets" — und löscht ihre eigenen. Nur eine ,,keine Daten"-Antwort lässt sie in Ruhe.

Der Schutz dagegen war da, hat aber die falsche Frage gestellt: er hat die ganze Flotte betrachtet und nur geschwiegen, wenn keine Box Presets hatte und keine einen DLNA-Server kannte. Eine einzige Box mit Presets — oder ein einziger Medienserver im Netz — hat die Antwort für alle anderen freigegeben. Ab v0.8.42 zählt nur noch die Box, die gerade fragt.

Für dich heißt das: du hast seit v0.8.34 keine leeren Presets mehr gemeldet, und daran ändert sich nichts. Neu ist das Netz darunter — sollte doch mal eine Slice nicht in den Flash kommen, bleiben die Presets im Gerät erhalten und der automatische Import holt sie zurück, statt dass sie beim nächsten Boot verschwinden.

Ein Nebeneffekt, den ich dazusagen will: bei einer Box, die ihre DLNA-Quellen noch nie registriert hat, braucht das erste DLNA-Preset einen Account-Zyklus, bevor es abspielbar ist. Durchsuchen ist nicht betroffen, bestehende Registrierungen auch nicht.

Partitionen sind unverändert, das Update geht also normal über die Luft.

Das liest sich gut. Aber es stimmt, ich habe leere Presets schon länger nicht mehr gesehen.

Momentan sieht es so aus, dass bei der 8. Box wohl 1 Preset nicht mehr in den nvs passt.
der Rest scheint zu passen.

Eigene Stream URLs habe ich aber nicht mehr angelegt, bzw. meine gesicherte Liste importiert. Wird aktuell nicht mehr benötigt.
es waren alternative URLs von meine Favoriten Radio Sendern, also alternativ zu tunein.
Aber tunein ist super von der Anzeige mit Titeln, sendungsinfos usw. Das gibt's bei anderen streaming URLs nicht.

Danke — der Satz mit der 8. Box hat mich stutzig gemacht, und ich habe das gleich nachgestellt. Ergebnis: dein Fall ist ein anderer als der, den v0.8.42 behebt, und der ist noch offen.

v0.8.42 schützt den Fall, dass die Kopie einer Box im Stick komplett fehlt. Bei dir fehlt sie nicht, sie hat eine Lücke — 5 von 6 Presets sind gespeichert, eines nicht.

Was ich gemessen habe: ist die Kopie unvollständig, schickt der Stick dem Lautsprecher eine Preset-Liste mit entsprechend weniger Einträgen. Das ist für die Bose-Firmware keine Unklarheit, sondern eine Ansage — sie gleicht sich darauf ab und verwirft den fehlenden Platz am Gerät. Im Test war das Preset am Lautsprecher weg, ohne dass ich ihn angefasst oder neu gestartet hätte; es reichte, den Eintrag im Stick zu löschen.

Heißt für dich: das eine Preset, das nicht mehr ins NVS passt, fehlt vermutlich nicht nur in der Weboberfläche, sondern wird dir auch an der Box gelöscht.

Die gute Nachricht: kaputt ist dabei nichts. Sobald der Eintrag wieder im Stick steht, holt sich der Lautsprecher ihn von selbst zurück — im Test in unter 15 Sekunden, ohne Zutun.

Was ich noch nicht weiß und deshalb nicht behaupte: ob ein fehlgeschlagener Speichervorgang den Eintrag bis zum nächsten Neustart des Sticks im Arbeitsspeicher hält. Davon hängt ab, ob das sofort greift oder erst nach einem Neustart. Wenn du magst, hilf mir da mit einem Blick auf http://<dein-stick>/api/status — interessant sind die Werte unter preset_store, also save_fails und speakers. Damit kann ich das einordnen, statt zu raten.

Einen Fix habe ich dafür noch nicht; ich habe den Pfad heute erst gefunden. Es gibt zwei denkbare Wege und beide haben Nebenwirkungen, das will ich in Ruhe entscheiden statt schnell

"/stop" - Auf den Wunschzettel — mit einem Vorbehalt, den ich beim Nachsehen gefunden habe.

Abschalten plus Oberfläche in einem Aufruf ist die kleine Hälfte. Der Haken sitzt im Boot-Pass: der Task liest die Config genau einmal, entscheidet vor dem Boot-Delay (default 10 s) und schaut danach nicht mehr hin. Ein /stop, das nur das NVS-Flag umlegt, wirkt also ab dem nächsten Start, hält den bereits angelaufenen Durchlauf aber nicht an — und genau das würde man bei dem Namen erwarten. Dafür braucht es zusätzlich ein Abbruch-Flag, das der Pass zwischen den Boxen prüft.

Zweitens muss die Seite den zurückgelesenen Stand zeigen und nicht den gewünschten: der NVS-Write kann fehlschlagen — dein C5-Fall, wo der Toggle nach dem Reboot zurücksprang.

Drittens, der Vollständigkeit halber: ein GET, der Zustand ändert, ist per eingebettetem img-Tag von jeder fremden Seite auslösbar. Die Richtung ist nur off, der Schaden also überschaubar, aber unerwähnt einbauen will ich es nicht.

Frage, damit ich das Richtige baue: reicht "ab nächstem Boot aus", oder soll /stop einen bereits laufenden Pass abbrechen?

Zitat von: tostmann am 08 August 2026, 12:24:43Frage, damit ich das Richtige baue: reicht "ab nächstem Boot aus", oder soll /stop einen bereits laufenden Pass abbrechen?

"Ab dem nächsten Boot" wäre mir zu spät. Es soll erst gar keine Migration gestartet werden.

Vielleicht wäre es viel einfacher, das Zeitfenster bis zum Start zu verlängern. Es ist doch prinzipiell egal, ob die Migration 20 Sekunden oder 120 Sekunden nach dem Booten losläuft.

Oder nach einem "Fresh Install" die Auto-Migration nicht per default zu aktivieren.

In beiden Fällen wäre für mich /stop entbehrlich.

Machen wir: 20 Sekunden im nächsten Release. Heute sind es 10, insofern verdoppelt sich das Fenster. Dazu kommt das Neulesen der Config unmittelbar vor dem Start — ohne das wirkt ein Abschalten während des Fensters gar nicht, weil der Task die Einstellung bislang genau einmal liest, vor dem Delay.

Deutlich länger will ich es nicht machen, und der Grund ist der Anwender, der nicht mitliest: der flasht über den Webflasher, provisioniert das WLAN und erwartet, dass die sechs Tasten danach wieder tun, was sie sollen — ohne eine einzige Einstellung anzufassen. Jede Minute, in der nach dem Provisionieren scheinbar nichts passiert, geht bei dem als Fehlschlag durch. Die Automatik ist für ihn kein Komfort, sondern der Zweck des Sticks.

Ein Hinweis noch zur Uhr: das Fenster beginnt nicht beim Einschalten, sondern erst wenn der Stick im WLAN ist — beim frisch geflashten Gerät also direkt nach dem Improv-Connect.

Zitat von: tostmann am 07 August 2026, 16:58:36Was ich noch nicht weiß und deshalb nicht behaupte: ob ein fehlgeschlagener Speichervorgang den Eintrag bis zum nächsten Neustart des Sticks im Arbeitsspeicher hält. Davon hängt ab, ob das sofort greift oder erst nach einem Neustart. Wenn du magst, hilf mir da mit einem Blick auf http://<dein-stick>/api/status — interessant sind die Werte unter preset_store, also save_fails und speakers. Damit kann ich das einordnen, statt zu raten.

Hier die aktuellen Werte vor dem geplanten Reboot. Laufzeit seit Aktualisierung auf die .42
⚠ store: 1 preset save fail · 6 inventory save fails

{
  "name": "SixBack",
  "version": "0.8.41",
  "build": "2026-08-06 17:20:23",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 228653,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -24,
    "channel": 11,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 109872,
    "min_free": 74044,
    "total": 339144,
    "largest_block": 42996,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8364216,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 9,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 1,
    "speakers": 8,
    "save_heap_aborts": 0,
    "save_nvs_fails": 1
  },
  "inventory": {
    "save_fails": 6
  },
  "health": {
    "boot_count": 4,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 3,
    "last_wifi_down_s": 0,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 33
  }
}
Jetzt Reboot. (kein geöffneter SixBack im Browser)

Erster Aufruf. Keine Header-Zeile mit Speicherfehlern.

{
  "name": "SixBack",
  "version": "0.8.41",
  "build": "2026-08-06 17:20:23",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 151,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -77,
    "channel": 11,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 124908,
    "min_free": 97648,
    "total": 339144,
    "largest_block": 65524,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8361004,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 9,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 0,
    "speakers": 8
  },
  "inventory": {
    "save_fails": 0
  },
  "health": {
    "boot_count": 5,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 4,
    "last_wifi_down_s": 0,
    "last_reset": "POWERON",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": -1
  }
}
Die 8. Box zeigt einen Preset so an:

Screenshot 2026-08-09 102814.jpg

Hier drücke ich dann auf das "X".

unten rechts, rote Meldung: Undo failed: HTTP 500
Browser refresh.
der eine Preset ist nun ok, da von der Box geholt.

Header: ⚠ store: 1 preset save fail

{
  "name": "SixBack",
  "version": "0.8.41",
  "build": "2026-08-06 17:20:23",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 279,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -76,
    "channel": 11,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 122332,
    "min_free": 91760,
    "total": 339144,
    "largest_block": 61428,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8363360,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 9,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 1,
    "speakers": 8,
    "save_heap_aborts": 0,
    "save_nvs_fails": 1
  },
  "inventory": {
    "save_fails": 0
  },
  "health": {
    "boot_count": 5,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 4,
    "last_wifi_down_s": 0,
    "last_reset": "POWERON",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": -1
  }
}

Zitat von: fred_feuerstein am 09 August 2026, 10:31:14Header: ⚠ store: 1 preset save fail

Code Auswählen Erweitern

{
  "name": "SixBack",
  "version": "0.8.41",
  "build": "2026-08-06 17:20:23",


Das sieht aber nicht nach .42 aus...

betateilchen hat recht: dein Stick läuft auf 0.8.41. Der Dump sagt version 0.8.41 mit build 2026-08-06 17:20:23 — die .42 trägt einen Build vom 07.08. Bitte zieh das Update nach. Die .42 bringt einen Schutz für den Fall, dass der Stick die Preset-Kopie einer Box komplett verloren hat — dann antwortet er der Box nicht mehr mit einer leeren Liste. Deinen Fall an der 8. Box deckt das allerdings noch nicht ab: dort fehlt ein einzelner Eintrag in einer ansonsten vorhandenen Kopie, und diesen Pfad habe ich noch nicht abgesichert; das steht bei mir als offener Punkt.

Der Dump beantwortet trotzdem zwei Dinge, die ich letzte Woche noch offen lassen musste. Erstens: save_nvs_fails steht auf 1, save_heap_aborts auf 0. Es ist also der Schreibvorgang ins NVS, der scheitert, nicht knapper Arbeitsspeicher — dein Heap sieht in allen drei Dumps gesund aus. Zweitens die Frage, ob ein fehlgeschlagener Speichervorgang bis zum Neustart im RAM überlebt: ja. Der Store schreibt erst in den Arbeitsspeicher und danach ins NVS, ein Fehlschlag lässt den RAM-Stand unberührt. Deshalb war der Preset nach dem Browser-Refresh wieder da. Die Lücke wirkt sich erst beim nächsten Boot aus.

Wenn du auf .42 bist und es wieder auftritt: nochmal derselbe Dump, dann sehe ich, ob sich an den Zählern etwas ändert.

ja, scheinbar hatte ich das Update auf die .42 bisher nur bei meinem 2. SixBack im Büro gemacht...

nun aber auch auf meinem Hauptstick.

Das Handling nach dem Update/Reboot etc. ist aber 100Prozent gleich wie in Beitrag #222 von mir beschrieben.

Hier der Status nach dem Update und Reboot mit 1x Preset Save Fail.

{
  "name": "SixBack",
  "version": "0.8.42",
  "build": "2026-08-07 13:56:43",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 4462,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -24,
    "channel": 5,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 111844,
    "min_free": 88904,
    "total": 339144,
    "largest_block": 52212,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8359648,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 9,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 1,
    "speakers": 8,
    "save_heap_aborts": 0,
    "save_nvs_fails": 1
  },
  "inventory": {
    "save_fails": 0
  },
  "health": {
    "boot_count": 6,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 6,
    "last_wifi_down_s": 1,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 262
  }
}

Danke — damit ist es auf .41 und .42 dasselbe Bild, dein Fall bleibt also offen.

Was der Dump sagt: save_nvs_fails steht auf 1, save_heap_aborts auf 0. Es scheitert das Schreiben in den Flash, nicht der Arbeitsspeicher. Ob der Bereich schlicht voll ist, weiß ich noch nicht — das kann der Stick selbst beantworten:

http://<dein-stick>/api/nvs/stats
Bitte einmal direkt nach einem Neustart und einmal unmittelbar nachdem das ✕ wieder den 500er gebracht hat. Interessant ist free_entries.

hier direkt nach Neustart, noch vor dem Preset Save Fehler:

used_entries   494
free_entries   136
total_entries   630
namespace_count   15
percent_used   78.4127

und hier nach der Korrektur bei der 8. Box und Browser Refresh:

used_entries   488
free_entries   142
total_entries   630
namespace_count   15
percent_used   77.46032

Danke, die Zahlen waren eindeutig: von deinen 136 freien Einträgen sind 126 eine Seite, die der Speicher sich dauerhaft für seine eigene Verwaltung reserviert und nie herausgibt. Real nutzbar waren also 10 — zu wenig für eine Preset-Slice. Der Speicher ist wirklich voll, auch wenn die Anzeige 78 Prozent sagt.

v0.8.43 ist raus. Damit wird das Preset, dessen Speichern fehlschlägt, nicht mehr an der Box gelöscht. Der Stick merkt sich einen fehlgeschlagenen Schreibvorgang und holt sich die Lücke beim nächsten Start vom Lautsprecher zurück, statt ihm eine unvollständige Liste zu schicken. Am Testgerät habe ich das an der echt vollen Partition nachgestellt: über vier Neustarts blieb das betroffene Preset jedes Mal auf der Box und war danach auch im Stick wieder da.

Ehrlich dazu: mehr Platz schafft das nicht. Solange der Speicher voll ist, wird das Speichern dieses einen Presets weiter fehlschlagen — nur der Verlust an der Box ist weg, und das ✕ sollte dir den 500er nicht mehr in Kombination mit einem verschwundenen Preset bescheren.

Update wie immer über SYSTEM → Online update. Wenn es wieder auftritt, gerne nochmal derselbe Dump plus die nvs/stats-Zahlen.

hab die .43 gleich installiert.

Direkt nach erstem Reboot steht der eine Preset wie gestern auf dem Screenshot da mit dem "X" muss er dann weggeklickt werden. Auch mit der 500er Meldung, dann Browser Refresh und im Header der Preset Save Fail.

Vor "X" und Refresh:
used_entries   488
free_entries   142
total_entries   630
namespace_count   15
percent_used   77.46032

Nach "X" und Refresh:
used_entries   489
free_entries   141
total_entries   630
namespace_count   15
percent_used   77.61905

{
  "name": "SixBack",
  "version": "0.8.43",
  "build": "2026-08-09 21:05:09",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 309,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -23,
    "channel": 5,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 123584,
    "min_free": 87992,
    "total": 339128,
    "largest_block": 59380,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8363376,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 9,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 1,
    "speakers": 8,
    "save_heap_aborts": 0,
    "save_nvs_fails": 1
  },
  "inventory": {
    "save_fails": 0
  },
  "health": {
    "boot_count": 1,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 0,
    "last_wifi_down_s": 0,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 9
  }
}
Dann nochmal Reboot als Test. Der eine Preset bei der Box steht wieder mit Push/X da, was erneut weggeklickt werden muss.
Also für mich kein Unterschied sichtbar.

Was du beschreibst, ist der vorgesehene Zustand — der Gewinn von .43 liegt an der Box, nicht im Browser: das Preset wird dort nicht mehr gelöscht. Und der eine belegte Eintrag mehr in deinen Zahlen (488 → 489) ist genau der neue Schutzmarker, den .43 bei einem fehlgeschlagenen Speichern setzt. Der Mechanismus ist bei dir also nachweislich aktiv.

Das ✕ musst du ab jetzt nicht mehr klicken. Mit gesetztem Marker holt sich der Stick die Lücke nach jedem Neustart selbst von der Box zurück — angestoßen von deren erster Anfrage beim Stick, das dauert bis zu eine Minute. Direkt nach dem Reboot steht die Meldung also noch da; nach kurzem Warten und einem Browser-Reload sollte sie von allein verschwinden. Falls sie das bei dir nach ein paar Minuten nicht tut, wäre genau das eine wichtige Rückmeldung. Der "Preset Save Fail" im Header wird dagegen wiederkommen, und der 500er beim ✕ auch: beide sagen ehrlich, dass der zurückgeholte Stand nicht in den Flash passt — von deinen 141 freien Einträgen sind nach Abzug der Reserve 15 nutzbar, das Speichern einer Box braucht mehr.

Zum Platz selbst ist zu sagen: die Einstellungs-Partition ist fix 20 KB groß und per Online-Update nicht vergrößerbar, weil direkt dahinter die App-Partitionen liegen — umpartitionieren ginge nur per USB-Neuflash, und der löscht alle Einstellungen, also das Gegenteil von dem, was du willst. Der Hebel, der bleibt, ist, dass die Firmware pro Box mit weniger Einträgen auskommt.

Zitat von: tostmann am 10 August 2026, 10:43:15Das ✕ musst du ab jetzt nicht mehr klicken. Mit gesetztem Marker holt sich der Stick die Lücke nach jedem Neustart selbst von der Box zurück — angestoßen von deren erster Anfrage beim Stick, das dauert bis zu eine Minute. Direkt nach dem Reboot steht die Meldung also noch da; nach kurzem Warten und einem Browser-Reload sollte sie von allein verschwinden. Falls sie das bei dir nach ein paar Minuten nicht tut, wäre genau das eine wichtige Rückmeldung. Der "Preset Save Fail" im Header wird dagegen wiederkommen, und der 500er beim ✕ auch: beide sagen ehrlich, dass der zurückgeholte Stand nicht in den Flash passt — von deinen 141 freien Einträgen sind nach Abzug der Reserve 15 nutzbar, das Speichern einer Box braucht mehr.

Das "X" bei dem einen Preset verschwindet hier nicht automatisch nach einem Browser-Reload. Hab jetzt nach SixBack Reboot über 5 Minuten gewartet.
Der "Problem-Preset" auf der Box ist kein TuneIn, sondern ein Preset auf lokales NAS. Aber das dürfte ja keinen Unterschied machen, oder?

Zitat von: tostmann am 10 August 2026, 10:43:15Zum Platz selbst ist zu sagen: die Einstellungs-Partition ist fix 20 KB groß und per Online-Update nicht vergrößerbar, weil direkt dahinter die App-Partitionen liegen — umpartitionieren ginge nur per USB-Neuflash, und der löscht alle Einstellungen, also das Gegenteil von dem, was du willst. Der Hebel, der bleibt, ist, dass die Firmware pro Box mit weniger Einträgen auskommt.

d.h. diese Einstellungs-Partition könnte man schon etwas vergrößern? Aktuell 20kb auf bspw. 40kb würde denke ich alle Probleme lösen, oder? Habe die Presets ja pro Box gespeichert, also wäre ein Neu-Flash nicht so ein riesen Problem. Sind ja auch fast überall die gleichen 6 Presets auf den Lautsprechern. Spotify ist auch fix wieder eingestellt.
Würde aber bedeuten, dass alle User einmal neu starten müssten oder?
Also eher unpraktikabel... ??
Dann doch so wie bisher. Wie gesagt, ich komme ja klar damit.

 

Zitat von: tostmann am 10 August 2026, 10:43:15Zum Platz selbst ist zu sagen: die Einstellungs-Partition ist fix 20 KB groß und per Online-Update nicht vergrößerbar, weil direkt dahinter die App-Partitionen liegen — umpartitionieren ginge nur per USB-Neuflash,

Als Softwareentwickler sehe ich das so:

• Bisher gibt es ja keine definierte Maximalzahl von Boxen pro Stick.
  
  
• Wenn es technisch die Möglichkeit gäbe, die Partition zu vergrößern (und sei es per Neu-Flash) dann sollte man diese Möglichkeit m.E. auch nutzen. Dabei könnte man dann eine Partitionsgröße wählen, die eine bestimmte Anzahl Boxen zuverlässig verwalten kann (z.B. 12 Boxen) und diesen Maximalumfang dann in die Dokumentation übernehmen. Danach gäbe es dann hoffentlich keine Diskussion zum Thema "Boxen-Anzahl" mehr, man würde auf die festgeschriebene Zahl verweisen.
  
  
• Ja, es mag ein Breaking Change sein. Aber die aktuelle Situation halte ich grundsätzlich für weniger zumutbar, als einmal neu flashen zu müssen. Zumal wir uns ja versionmäßig immer noch im Bereich 0.xxx bewegen, da sollte man mit solchen Changes grundsätzlich rechnen.

Bei mir im Test heilt genau dieser Zustand: nach dem Neustart ist die Lücke erst da, und sobald die Box das nächste Mal beim Stick anfragt, holt er sich das Preset von ihr zurück — bei mir nach gut einer halben Minute. Bei dir passiert das offenbar nicht, und von außen sehe ich nicht, woran es hängt.

Könntest du den Stick einmal per USB an den Rechner hängen und die serielle Ausgabe über einen Neustart mitschreiben, 115200 Baud? Interessant sind die ersten zwei Minuten nach dem Boot, vor allem Zeilen mit:

[bmx][safe]
[bmx][heal]

Die sagen mir, ob der Stick den Heilversuch überhaupt startet und woran er scheitert.

v0.8.44 ist raus, mit zwei Dingen aus diesem Thread.

@betateilchen: Das Zeitfenster vor der automatischen Migration ist jetzt 20 Sekunden. Wichtiger ist die zweite Hälfte — der Schalter hat während des Fensters vorher überhaupt nicht gewirkt: die Migration hat die Einstellung einmal beim Start gelesen und noch vor der Wartezeit geprüft, ein Umlegen danach lief ins Leere und der Durchlauf startete trotzdem. Ein längeres Fenster allein hätte dir also nichts gebracht. Jetzt wird unmittelbar vor der ersten Box neu gelesen. Wer den Schalter schon einmal benutzt hat, trägt die alten 10 Sekunden in seinen Einstellungen — genau dieser Wert wird beim Laden angehoben, sonst hättest du von der Änderung nichts gesehen.

@fred_feuerstein: Ein Speaker-Eintrag speichert nicht mehr den kompletten Firmware-String der Box, sondern nur noch den Versionsteil. Der Rest war ein Build-Stempel, den nichts auswertet, der aber unverhältnismäßig teuer war: die Daten werden mit einem kleinen Fenster komprimiert, und die zusätzlichen Zeichen schieben einen Eintrag darüber hinaus, sodass die untereinander fast gleichen Einträge sich nicht mehr gegenseitig wegkomprimieren. An einem Datensatz mit neun Boxen gemessen: 80 Speicher-Einträge mit Stempel, 28 ohne. Das schafft keinen Platz auf einer schon vollen Partition, lässt aber deutlich mehr davon für alles andere übrig. Nach dem Update und einem Neustart wären die nvs/stats-Zahlen nochmal interessant — daran sieht man direkt, ob es bei dir reicht.

Update wie immer über SYSTEM → Online update.

Hier die stats Zahlen nach Install/Reboot der .44

used_entries   489
free_entries   141
total_entries   630
namespace_count   15
percent_used   77.61905

der eine Preset steht wie gewohnt auf PUSH/X und korrigiert sich auch nicht automatisch. Habe jetzt ca. 5 Minuten gewartet und dann erst Browser Refresh gemacht, ohne Erfolg und dann eben das X gedrückt und wieder Browser Refresh.

Hier die Stats nach dem Prozedere:

used_entries   489
free_entries   141
total_entries   630
namespace_count   15
percent_used   77.61905

Also kein Unterschied zu sehen.

Dann nochmal ein Reboot, gleiches Ergebnis. Auch nach über 5 Minuten hat sich der eine Preset nicht korrigiert.

bzgl. Log  ( [bmx][safe]  / [bmx][heal]  ), das kann ich erst heute Abend oder morgen früh versuchen, wenn ich zuhause bin.

Zitat von: tostmann am 10 August 2026, 22:55:12Bei mir im Test heilt genau dieser Zustand: nach dem Neustart ist die Lücke erst da, und sobald die Box das nächste Mal beim Stick anfragt, holt er sich das Preset von ihr zurück — bei mir nach gut einer halben Minute. Bei dir passiert das offenbar nicht, und von außen sehe ich nicht, woran es hängt.

Könntest du den Stick einmal per USB an den Rechner hängen und die serielle Ausgabe über einen Neustart mitschreiben, 115200 Baud? Interessant sind die ersten zwei Minuten nach dem Boot, vor allem Zeilen mit:

Code Auswählen Erweitern

[bmx][safe]
[bmx][heal]

Die sagen mir, ob der Stick den Heilversuch überhaupt startet und woran er scheitert.

also ich finde solche Einträge gar nicht im Log. Habe das Log mal angehängt von den ersten Minuten nach Reboot. Am Ende sieht man dann glaube ich auch, das Wegklicken vom "X" und Refresh.

@fred_feuerstein, @betateilchen — danke fürs Dranbleiben, das Thema ist vom Tisch.

Fred, dein Log war eindeutig. Die entscheidende Zeile ist diese:

[nvs-save] REFUSED ns=sixback-pre key=... blob=541
           (brauche ~26 entries, verfuegbar 15 = frei 141 - GC-Reserve 126)

Der Einstellungsspeicher ist voll. Jeder Speaker belegt darin einen Teil, und bei deiner Anzahl Boxen reicht der Platz für keinen weiteren Schreibvorgang mehr — auch nicht für den, der wieder aufräumen würde. Deshalb ändern sich deine Zahlen nach dem Update nicht, und deshalb bleibt der eine Preset auf PUSH stehen: der Stick kann ihn schlicht nicht speichern. Nebenbei trifft es auch dein Spotify-Token, das aus demselben Grund keinen Neustart übersteht.

Betateilchen, dein Vorschlag mit der Partitionierung war richtig. Umgesetzt ist er als eigene Variante, damit sie niemand versehentlich erwischt, der sie nicht braucht:

https://sixback.io/max/

Statt 630 Entries hat sie 6930, also das Elffache. Ansonsten ist es dieselbe Firmware in derselben Version: gleiche Funktionen, gleiche Oberfläche, und Updates laufen danach wieder ganz normal über die Update-Funktion des Sticks.

Zwei Dinge vorher:

1. Die Variante teilt den Speicher anders auf und lässt sich deshalb nur komplett neu schreiben. Der Stick verliert dabei seine Presets. Sichert sie vorher über die Export-Schaltfläche in der Oberfläche und spielt sie danach wieder ein. Eure Boxen behalten ihre Presets die ganze Zeit über — es geht nur um die Kopie auf dem Stick.

2. Sie läuft nur auf Boards mit 16 MB Flash (ESP32-S3 oder ESP32-C5). Das N16 im Modulnamen sagt es; falls unklar, hilft die Board-Seite auf sixback.io weiter.

Beides ist auf Testhardware durchgelaufen, auf S3 wie auf C5, inklusive eines anschließenden Updates über WLAN. Meldet euch, wenn etwas hakt.

natürlich gleich ausprobiert.

Mit der Box und dem "Problem"-Preset hatte ich etwas Probleme beim Einrichten. Hat aber dann geklappt. Dummerweise war der Preset der nicht gespeichert wurde ausgerechnet auch ein DLNA Preset und der wollte die ganze Zeit nicht. Erst etliche Reboots etc. und ein Abspielen eines Streams von einem der DLNA Server über die Bose-App hat es gerichtet. Nun ist er wieder gespeichert und übersteht auch den Reboot vom ESP.

Hier die nvs stats:

used_entries   676
free_entries   6254
total_entries   6930
namespace_count   12
percent_used   9.75469

Spotify ist wieder eingerichet und connected. Ausserdem auch die 8 eigenen Stream-Adressen.
Die 9. Box (der wireless Link) ist erstmal weiterhin als HIDE eingefügt, da er über das ST Reborn Projekt läuft.

Ansonsten alles OK soweit!

Vielen Dank!

Im Büro am anderen Standort habe ich meinen 2. Sixback in Betrieb mit einer Soundtouch 20 Box.
Dort ist auch die .45 installiert, allerdings in der "normalen" Version, also nicht "max".

Was mich wundert. Es ist ja nur ein Lautsprecher, keine persönlichen Streams gespeichert, kein Spotify verknüpft.
Aber der Speicher ist über 40% belegt:

used_entries   263
free_entries   367
total_entries   630
namespace_count   12
percent_used   41.74603

ist das normal?

Habe testweise mal 7 persönliche Stream-Urls gespeichert. Dann steigt der belegte Speicher auf knapp 50%:

used_entries   311
free_entries   319
total_entries   630
namespace_count   12
percent_used   49.36508

Ist ja alles ok und kein direktes Problem. Aber wie gesagt, es ist nur ein Lautsprecher verbunden.

Ja, das ist normal.

Zum Vergleich, hier gerade gemessen:

Stick    Boxen  belegt
S3          3    268 / 630
C6          3    277 / 630
deiner      1    263 / 630

Zwei Sticks mit drei Boxen liegen also praktisch gleichauf mit deinem mit einer. Der Verbrauch steckt fast vollständig im Grundbedarf, nicht in der Anzahl der Boxen — eine Box mehr kostet nur wenige Einträge.

Deine zweite Zahl passt dazu: die 7 Stream-Adressen haben 48 Einträge gekostet, also rund 7 pro Adresse.

Woraus sich der Grundbedarf im Einzelnen zusammensetzt, habe ich nicht aufgeschlüsselt.

@Dirk nur mal interessehalber: wird bei Dir der C5 N16R8 mit "Identify my board" korrekt erkannt?

Bei mir kommt da immer eine 4MB Version als Ergebnis.
In sixback.local steht dann korrekt 16MB.

Danke fürs Melden — das lag nicht an deinem Board, sondern an der Board-Erkennung der Flasher-Seite. Ich konnte es hier an einem C5 mit 16 MB nachstellen.

Ursache: die Bibliothek hinter "Identify my board" (esptool-js) spricht beim C5 den SPI-Controller des C3 an, Basis 0x60002000 statt 0x60003000. Der Flash-Chip antwortet damit überhaupt nicht, und die Bibliothek fällt still auf "4MB" zurück — von einem echten 4-MB-Fund nicht zu unterscheiden. Der C6 war genauso betroffen, da fiel es nur nie auf, weil 4 MB dort zufällig stimmt.

Ist gefixt und seit eben live: die Seite korrigiert die Basis selbst und liest die Flash-Kennung roh. Wenn sie nichts lesen kann, markiert sie jetzt gar kein Image mehr, statt eins zu empfehlen.

Magst du das unabhängig nachprüfen? https://sixback.io/boards.html (https://sixback.io/boards.html) mit deinem C5 N16R8 — hier wird jetzt das 16-MB-Image als passend markiert. Falls bei dir etwas anderes herauskommt, poste bitte die "Detected:"-Zeile.

Zitat von: tostmann am 17 August 2026, 17:07:40Magst du das unabhängig nachprüfen? https://sixback.io/boards.html (https://sixback.io/boards.html) mit deinem C5 N16R8 — hier wird jetzt das 16-MB-Image als passend markiert.

Sieht gut aus.
Danke fürs Kümmern.

Bildschirmfoto 2026-08-17 um 19.06.48.png

@betateilchen: kurze Rückmeldung, was aus Deinem "der C5 wird als 4-MB-Version erkannt" geworden ist — der Hinweis ist bis zu Espressif durchgelaufen.

Die Ursache lag nicht in SixBack, sondern in esptool-js, der Bibliothek hinter dem Web-Flasher: sie benutzt für C5, C6, C61 und H2 die SPI-Registerbasis des C3 (0x60002000 statt 0x60003000). Dadurch kam die Flash-ID als 0 zurück und die Größenerkennung fiel still auf "4MB" zurück — von echten 4 MB nicht zu unterscheiden. Auf der Flasher-Seite ist das seit dem 17.08. korrigiert, das hattest Du ja gegengetestet.

Upstream gab es dazu ein seit November offenes Issue ohne Ursachenanalyse. Ich habe die Messungen dort hinterlegt, und Espressif hat den Fix daraufhin selbst umgesetzt und um Review gebeten. Beim Nachmessen fiel noch ein zweiter, älterer Fehler auf (Flashen mit "detect" als Flash-Größe schlug immer fehl) — der ist im selben Pull Request mit erledigt.

https://github.com/espressif/esptool-js/issues/217
https://github.com/espressif/esptool-js/pull/253
https://github.com/espressif/esptool-js/issues/254

Gemerged ist der PR noch nicht. Sobald er in einer Release-Version landet, profitiert davon jedes Projekt, das esptool-js benutzt — nicht nur unseres. Danke für die Meldung.

Hallo,
ich habe das Problem, das einige Sender aus Tunein nicht funktionieren, hier z.B. der RBB88.8 !
Ist das nur bei mir so? Hänge mal die Presets dran. Fehlerhaft ist der Preset 2

<presets>
<preset id="1">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s228737" sourceAccount="" isPresetable="true">
<itemName>NDR 2 Hamburg</itemName>
<containerArt>https://sixback.io/stations/tunein-logo/s228737</containerArt>
</ContentItem>
</preset>
<preset id="2" createdOn="1787225403" updatedOn="1787225403">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s25677" sourceAccount="" isPresetable="true">
<itemName>rbb 88,8</itemName>
</ContentItem>
</preset>
<preset id="3">
<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>
Beste Grüße

rbb88.8 funktioniert hier problemlos.

<preset id="6" createdOn="1787227879" updatedOn="1787227879">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s25677" sourceAccount="" isPresetable="true">
<itemName>rbb 88,8</itemName>
</ContentItem>
</preset>

und spielt wunderbar.

@erwin23: Ich habe die beiden Presets verglichen — der ContentItem in Deinem Preset 2 und der in betateilchens Preset 6 sind identisch, bis auf Nummer und Zeitstempel. Die Station ist auch unauffällig: s25677 liefert bei TuneIn eine reine MP3 mit 128 kbit, kein AAC und kein HLS, also keiner der beiden Fälle, die hier früher Ärger gemacht haben. Und ich habe Deinen ContentItem wortgleich auf einem SoundTouch 10 angespielt: läuft, über eine Minute stabil, mit Live-Text vom Sender.

Der Unterschied liegt damit nicht am Preset. Vier Fragen, damit ich weiterkomme:

- Welche SixBack-Version läuft bei Dir, und auf welchem Stick? Steht auf der Startseite unter sixback.local.
- Welches Speaker-Modell, und welcher Firmware-Stand?
- Was passiert genau, wenn Du Preset 2 drückst: bleibt es still, kommt die englische Ansage "not compatible", oder springt die Box nach ein paar Sekunden zurück?
- Du schreibst "einige Sender": laufen NDR 2 und Bremen Zwei aus Deinen Presets 1 und 3 auf derselben Box? Und welche gehen sonst noch nicht?