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.