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.