BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[betateilchen]

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

[tostmann]

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!

[betateilchen]

Wo sind meine Lautsprecher? 

Du darfst diesen Dateianhang nicht ansehen.

Code Auswählen Erweitern

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


[tostmann]

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

[betateilchen]

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.

Kommen sie nach "Refresh status"/Reload doch?

Ja, irgendwann sind die Kacheln der Boxen wieder vorhanden.

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.

Bekommst Du, sobald ich ihn wieder in Betrieb habe.

[betateilchen]

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.

Code Auswählen Erweitern

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


Code Auswählen Erweitern

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


[tostmann]

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.

[betateilchen]

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

[tostmann]

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.

[betateilchen]

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.

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.

Du darfst diesen Dateianhang nicht ansehen.

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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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


[betateilchen]

Update auf .31 mache ich später.

[tostmann]

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.

[betateilchen]

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

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)

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

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.

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.

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.

Ok, verstanden.

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

[tostmann]

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ß