BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[tostmann]

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.

[fred_feuerstein]

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

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

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?

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.

Code Auswählen Erweitern

{
  "used_entries": 504,
  "free_entries": 126,
  "total_entries": 630,
  "namespace_count": 15,
  "percent_used": 80
}

Code Auswählen Erweitern

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

[tostmann]

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:

Code Auswählen Erweitern

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

[tostmann]

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:

Code Auswählen Erweitern

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

[fred_feuerstein]

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

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.

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.

[tostmann]

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:

Code Auswählen Erweitern

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