BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[fred_feuerstein]

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 auf .36 durchgeführt. NVS Fehler bleiben. Bspw. wenn ich einen Preset neu belegen möchte kommt rechts unten:

Code Auswählen Erweitern

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

[tostmann]

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

[betateilchen]

Hey,

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

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

Code Auswählen Erweitern

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


[tostmann]

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!

[fred_feuerstein]

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.

Code Auswählen Erweitern

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

[tostmann]

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.

[fred_feuerstein]

heute früh sieht es so aus:

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[betateilchen]

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.

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.

Code Auswählen Erweitern

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


[tostmann]

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.

[betateilchen]

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

Code Auswählen Erweitern

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


[fred_feuerstein]

@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

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