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.