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.