BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[betateilchen]

An einer Lösung mit Sender-Logo arbeite ich noch...

works as designed...

Du darfst diesen Dateianhang nicht ansehen.

[fred_feuerstein]

Senderlogos lasse ich mir auch von meinen Favoritensendern über ein DOIF in ein Reading schreiben, welche dann über die TabletUI auf meinen Wandtablets auf den entsprechenden Stellen angezeigt werden.

[tostmann]

Senderlogos lasse ich mir auch von meinen Favoritensendern über ein DOIF in ein Reading schreiben

Wo Du gerade da bist, eine Rückfrage zu Deinem Setup mit den 9-10 Boxen: in v0.8.27 steckt eine nicht-blockierende Status-Aktualisierung, die genau das Zappeln der Status-Anzeige adressiert, das Du beschrieben hattest (Anzeige wechselt, obwohl der Lautsprecher aktiv ist und Musik durchläuft — bei Dir mit vielen Boxen deutlich häufiger als mit zweien). Bist Du schon auf 0.8.27, und falls ja: läuft die Status-Anzeige bei Deinen 9-10 Boxen jetzt ruhig, oder zappelt sie noch?

[betateilchen]

Heute habe ich unachtsamerweise einen zweiten ESP32 mit sixback geflasht, der hat dann direkt angefangen, die vorhandenen Boxen auf sich selbst zu migrieren. Das hat einiges an Verwirrung gestiftet.

Inzwischen habe ich alle vier betroffenen Boxen wieder eingefangen und siehe da - nach dem Ausflug und der Rückkehr zum "Heimat sixback" ist jetzt plötzlich auch das viel diskutierte sixback Logo sichtbar.



--

[fred_feuerstein]

Wo Du gerade da bist, eine Rückfrage zu Deinem Setup mit den 9-10 Boxen: in v0.8.27 steckt eine nicht-blockierende Status-Aktualisierung, die genau das Zappeln der Status-Anzeige adressiert, das Du beschrieben hattest (Anzeige wechselt, obwohl der Lautsprecher aktiv ist und Musik durchläuft — bei Dir mit vielen Boxen deutlich häufiger als mit zweien). Bist Du schon auf 0.8.27, und falls ja: läuft die Status-Anzeige bei Deinen 9-10 Boxen jetzt ruhig, oder zappelt sie noch?

Es wechselt auch in der 0.8.27 noch von "grün" auf "weiss" und wieder mal auf "grün", obwohl die Box die ganze Zeit einen Stream abspielt. Wechselt irgendwie zyklisch hin und her.

[tostmann]

danke fürs Nachtesten auf 0.8.27 und für die Rückmeldung — gut zu wissen, dass das zyklische grün↔weiß bei Deinen 9-10 Boxen noch da ist.

Einordnung dazu: das ist ein reines Anzeige-Artefakt im Webfrontend. Der Status-Poll fragt periodisch jede Box ab; bei vielen Boxen überlappen sich der Poll und die Eigen-Statusmeldung der Box, und die Anzeige kippt für einen Moment auf weiß, bevor sie wieder auf grün einrastet. Dahinter steckt nichts Funktionales — die Box streamt durch, die Presets bleiben belegt, die Tasten lösen aus. Der non-blocking-Refresh in 0.8.27 hat das Zappeln seltener gemacht, aber bei Deiner Boxen-Zahl offensichtlich nicht ganz weg.

Ehrlich zur Priorität: das eigentliche Ziel war, die sechs Hardware-Tasten ohne die Bose-Cloud zurückzuholen — und das läuft. Den Status-Punkt im Webfrontend hübscher zu polieren steht bei mir bewusst weit hinten; ich nehme ihn auf die Liste, aber das Frontend zu perfektionieren ist nicht, wo gerade die Energie reingeht.

Wo ich aber sofort hellhörig werde: wenn bei den vielen Boxen etwas Funktionales hakt — Aussetzer im Audio, eine Taste die nicht greift, eine Box die nicht migriert. Das wäre dann kein Kosmetik-Thema und würde ich mir gleich ansehen. Sag bei sowas gern Bescheid.

[betateilchen]

Zu dem grün/weiß Thema auch noch eine Anmerkung von mir: das tritt sehr sporadisch auch bei meinen vier Boxen auf. Aber da das Frontend bei mir nicht zur "täglichen Nutzung" der Boxen verwendet wird, habe ich das inzwischen einfach als kosmetische Unzulänglichkeit eingestuft, die auf die Funktion keinerlei Einfluss hat.

In meinem Urlaub diese Woche habe ich versucht, aus dem Quellcode die Dateien für meinen ESP32-S3 zu erzeugen. Aber trotz vieler Versuche ist mir das nicht gelungen. Irgendwelche Abhängigkeiten können nicht aufgelöst werden. Allerdings muss ich auch dazusagen, dass ich mich mit PlatformIO noch nie anfreunden konnte. Mein Ziel im Erfolgsfall wäre gewesen, mich am Thema "5GHz" zu versuchen. Aber solange mir nichtmal das Kompilieren für eine bereits unterstützte Plattform gelingt, macht dieses Vorhaben für mich keinen Sinn.

[betateilchen]

Heute hatte ich endlich mal Zeit und Lust, meine neue "Bose Cloud" ordentlich zu verpacken

Du darfst diesen Dateianhang nicht ansehen.

Du darfst diesen Dateianhang nicht ansehen.

Angebracht ist das Ganze inzwischen per Klettband an der Rückseite einer ST20,
der vorhandene USB port reicht für die Versorgung aus und
liefert auch im Standby Modus der Box die benötigte Versorgungsspannung.

Du darfst diesen Dateianhang nicht ansehen.

Nun hoffe ich nur, dass das sixback-Logo nicht markenrechtlich geschützt ist



---

[betateilchen]

In meinem Urlaub diese Woche habe ich versucht, aus dem Quellcode die Dateien für meinen ESP32-S3 zu erzeugen. Aber trotz vieler Versuche ist mir das nicht gelungen. Irgendwelche Abhängigkeiten können nicht aufgelöst werden.

Inzwischen habe ich eine VM mit Debian aufgesetzt, weil ich vermutete, es könnte was mit der Installation auf macOS zu tun haben.
Aber dem war wohl nicht so, denn genau an der gleichen Stelle wie auf dem mac bricht auch die Projektkonfiguration unter Trixie ab:

Du darfst diesen Dateianhang nicht ansehen.

Wenn ich das "Anhängsel" hinter der url entferne, läuft die Konfiguration durch.
Aber irgendwas muss das ja bedeuten.
Was geht da schief und wie bekomme ich diese library vielleicht doch installiert?



---

[tostmann]

Hallo betateilchen,

das liegt nicht an deinem Setup, sondern an einem kaputten Pin im Repo. In der platformio.ini ist die Improv-Lib auf einen festen Commit festgenagelt, den es auf GitHub nicht (mehr) gibt — der wurde durch einen Rebase ersetzt. PlatformIO klont das Lib-Repo deshalb erfolgreich, kann dann aber den angegebenen Commit nicht auschecken (git reset --hard ... schlägt fehl → "Konnte Objekt nicht parsen" / VCSBaseException). Bei mir baut es nur durch, weil der alte Commit noch in meinem lokalen PlatformIO-Cache liegt; bei einem frischen Build fehlt er.

Sofort-Workaround bei dir: In der platformio.ini die improv-wifi-busware-Zeile (im Block [common], lib_deps) auf den aktuellen Stand zeigen lassen. Entweder den Commit-Suffix komplett weglassen:

Code Auswählen Erweitern

    https://github.com/tostmann/improv-wifi-busware.git

oder gezielt auf den aktuellen Commit pinnen:

Code Auswählen Erweitern

    https://github.com/tostmann/improv-wifi-busware.git#768256c01e5ba42acd3d638fee39959bb9f8853c

Danach einmal den Lib-Cache des Projekts leeren, damit PlatformIO neu zieht (pio pkg uninstall / .pio-Ordner im Projekt löschen) und neu bauen.

Ich korrigiere den Pin im Repo und ziehe das in den nächsten Release; dann ist der Schritt nicht mehr nötig. Danke fürs Melden.

[betateilchen]

Hallo Dirk,

das mit dem Weglassen hatte ich schon erfolgreich probiert.

Inzwischen habe ich auch gesehen, dass es für den C5 schon Ansätze in der platform.ini gibt.
Mein C5 DevKit ist übrigens speichermäßig als N16R8 gekennzeichnet.

Das Kompilieren für C5 hat auch funktioniert, das sixback WLAN wird auch gefunden und das Portal ist erreichbar, aber ich kann dort noch keine Verbindung zu meinem Netzwerk herstellen. Na, mal schauen...
Ein kleines Erfolgserlebnis hatte ich dann ja doch noch.

Code Auswählen Erweitern

Looking for upload port...
Uploading /home/udo/pio-build/bosefix32/c5/firmware.bin
esptool v5.1.2
Connected to ESP32-C5 on /dev/ttyACM0:
Chip type:          ESP32-C5 (revision v1.0)
Features:           Wi-Fi 6 (dual-band), BT 5 (LE), IEEE802.15.4, Single Core + LP Core, 240MHz
Crystal frequency:  48MHz
MAC:                38:44:be:ff:fe:00:7f:94
BASE MAC:           38:44:be:00:7f:94
MAC_EXT:            ff:fe


[tostmann]

allo betateilchen,

freut mich, dass der Workaround gegriffen hat und der C5 schon so weit kommt — Kompilieren, eigenes "sixback"-WLAN und erreichbares Portal sind genau die Schritte, die laufen sollen. Das ist schon das halbe Spiel.

Genau an der Stelle, an der du jetzt hängst — Portal da, aber die Box verbindet sich nicht mit deinem WLAN — steckt auch der Grund, warum der C5 bei uns derzeit NICHT als offizielles Release dabei ist. Auf einem C5-Board hier hat sich der Stick sauber verbunden (auch auf 5 GHz), auf anderer C5-Hardware bekommen wir aber trotz gutem Empfang reproduzierbar keine Verbindung zum Access Point zustande — und zwar auf beiden Bändern. Das sieht nach einem HF-/Hardware-Varianten-Thema aus, das wir noch nicht dingfest gemacht haben. Solange das nicht über die verschiedenen C5-Boards hinweg zuverlässig läuft, wollen wir den C5 nicht ausliefern: ein Target, das auf dem eigenen Tisch funktioniert, beim Anwender aber genau so stehenbleibt wie bei dir gerade, ist kein gutes Release. Lieber ehrlich "noch nicht" als ein C5-Image, das die Hälfte der Leute nicht ins Netz bekommt.

Wichtig ist mir der Punkt: am C5 als Chip liegt es nicht, und am Build und Flashen offensichtlich auch nicht — bei dir kompiliert es ja, läuft, und das Portal steht. Der eine offene Punkt ist eng umrissen: das zuverlässige Einbuchen ins heimische WLAN über die verschiedenen C5-Boards hinweg — und genau da stehst du gerade auch.

Was du gern versuchen kannst (und woran wir wirklich interessiert sind):

- Der env:c5 ist aktuell auf ein 4-MB-DevKit ohne PSRAM zugeschnitten (board esp32-c5-devkitc1-n4, partitions-4mb.csv). Auf deinem N16R8 läuft das auf dem 4-MB-Layout einfach mit, der Rest von Flash und PSRAM liegt brach — das ist NICHT die Ursache des Verbindungsproblems, nur zur Einordnung.
- Zum Eingrenzen: häng ihn testweise an ein reines 2,4-GHz-Netz. Wenn schon 2,4 GHz nicht joint, ist es genau die Wand, die wir auch sehen; wenn 2,4 geht und nur 5 GHz nicht, wäre das ein sehr nützliches Signal.
- Falls es bei dir doch verbindet: gib hier unbedingt Bescheid — du wärst ein zusätzlicher Datenpunkt auf echter Hardware, und du hast ja genau die 5-GHz-Motivation. Der Code liegt offen, Beobachtungen und PRs sind willkommen.

Viel Erfolg, und danke fürs Dranbleiben — gerade die C5-Rückmeldungen bringen uns hier weiter.

[betateilchen]

Moin,

was ich zu meinem DevKit definitiv sagen kann:

• Verbindung zu 5GHz WLAN funktioniert grundsätzlich problemlos und ist stabil
• Verbindung zu 2.4GHz WLAN funktioniert grundsätzlich problemlos und ist stabil

Dabei spreche ich jetzt aber nicht von sixback, sondern von einer anderen getesteten Applikation, die ich über die Arduino IDE auf das DevKit gebracht habe.


Was fällt mir sonst noch auf?

• Beim Kompilieren von sixback gibt es ein paar Warnungen, aber es läuft trotzdem bis zum Upload durch.
• Aktuell taucht das sixback-WLAN nicht mehr auf.
• Die Flash Größe wird wohl automatisch erkannt.

Code Auswählen Erweitern

Configuring flash size...
Auto-detected flash size: 16MB
Flash will be erased from 0x00002000 to 0x00007fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x001d2fff...
Flash parameters set to 0x024f.


Environment    Status    Duration
-------------  --------  ------------
c5             SUCCESS   00:01:07.373

Und wenn ich mir aktuell den device monitor anschaue, sehe ich, dass das devkit sich in einer Dauer-Bootschleife befindet. Sehr merkwürdig.

Code Auswählen Erweitern

06:26:24.917 > Rebooting...
06:26:24.917 > ESP-ROM:esp32c5-eco2-20250121
06:26:24.936 > Build:Jan 21 2025
06:26:24.936 > rst:0xc (SW_CPU),boot:0x18 (SPI_FAST_FLASH_BOOT)
06:26:24.936 > Core0 Saved PC:0x4080aca4
06:26:24.936 > SPI mode:DIO, clock div:1
06:26:24.948 > load:0x408556b0,len:0x1258
06:26:24.948 > load:0x4084bba0,len:0xca4
06:26:24.948 > load:0x4084e5a0,len:0x315c
06:26:24.948 > entry 0x4084bba0
06:26:26.294 > E (1366) MSPI Timing: Failed to allocate dummy cacheline for PSRAM memory barrier!
06:26:26.295 > [     6][I][esp32-hal-psram.c:106] psramAddToHeap(): PSRAM added to the heap.
06:26:26.816 >
06:26:26.876 > assert failed: lfs_fs_grow_ lfs.c:5263 (block_count >= lfs->block_count)


[betateilchen]

Der env:c5 ist aktuell auf ein 4-MB-DevKit ohne PSRAM zugeschnitten (board esp32-c5-devkitc1-n4, partitions-4mb.csv).

Da steht bei mir zwar was anderes in der platformio.ini, aber ich habe das jetzt mal so eingetragen, wie von Dir angegben. Jetzt startet der C5 zumindest mal wieder so weit, dass das sixback-WLAN auftaucht. Aber noch während der Eingabe im Portal schlägt dann wieder die Reboot-Schleife zu. Deshalb kann ich da überhaupt nichts dauerhaft eingeben.

Code Auswählen Erweitern

06:33:22.471 > ESP-ROM:esp32c5-eco2-20250121
06:33:22.471 > Build:Jan 21 2025
06:33:22.486 > rst:0x1 (POWERON),boot:0x59 (SPI_FAST_FLASH_BOOT)
06:33:22.486 > SPI mode:DIO, clock div:1
06:33:22.486 > load:0x408556b0,len:0x1258
06:33:22.486 > load:0x4084bba0,len:0xca4
06:33:22.491 > load:0x4084e5a0,len:0x315c
06:33:22.491 > entry 0x4084bba0
06:33:23.782 > E (1303) MSPI Timing: Failed to allocate dummy cacheline for PSRAM memory barrier!
06:33:23.782 > [     2][I][esp32-hal-psram.c:106] psramAddToHeap(): PSRAM added to the heap.
06:33:24.310 > [   532][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
06:33:24.339 > [   561][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
06:33:24.345 > [   567][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
06:33:24.351 > [   573][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
06:33:24.993 > [  1216][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND


[tostmann]

Moin,

danke, das grenzt es sauber ein. Dein DevKit verbindet mit einer anderen App auf 2,4 UND 5 GHz stabil → die Funk-HW deines Boards ist ok; die sixback-Nicht-Verbindung liegt bei dir damit FW/Config-seitig bei uns, nicht am RF. Guter Datenpunkt.

Ehrlich zur Prio: C5 steht bei uns zeitlich gerade nicht auf der Agenda — wir bekommen das 5-GHz-Verhalten über die verschiedenen C5-Boards hinweg nicht zuverlässig dicht und treiben es aktuell nicht aktiv weiter. Aber: einen konkreten PR dazu nehmen wir hier gern an und testen ihn.

Gruß