BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[tostmann]

Ja, das ist normal.

Zum Vergleich, hier gerade gemessen:

Code Auswählen Erweitern

Stick    Boxen  belegt
S3          3    268 / 630
C6          3    277 / 630
deiner      1    263 / 630

Zwei Sticks mit drei Boxen liegen also praktisch gleichauf mit deinem mit einer. Der Verbrauch steckt fast vollständig im Grundbedarf, nicht in der Anzahl der Boxen — eine Box mehr kostet nur wenige Einträge.

Deine zweite Zahl passt dazu: die 7 Stream-Adressen haben 48 Einträge gekostet, also rund 7 pro Adresse.

Woraus sich der Grundbedarf im Einzelnen zusammensetzt, habe ich nicht aufgeschlüsselt.

[betateilchen]

@Dirk nur mal interessehalber: wird bei Dir der C5 N16R8 mit "Identify my board" korrekt erkannt?

Bei mir kommt da immer eine 4MB Version als Ergebnis.
In sixback.local steht dann korrekt 16MB.

[tostmann]

Danke fürs Melden — das lag nicht an deinem Board, sondern an der Board-Erkennung der Flasher-Seite. Ich konnte es hier an einem C5 mit 16 MB nachstellen.

Ursache: die Bibliothek hinter "Identify my board" (esptool-js) spricht beim C5 den SPI-Controller des C3 an, Basis 0x60002000 statt 0x60003000. Der Flash-Chip antwortet damit überhaupt nicht, und die Bibliothek fällt still auf "4MB" zurück — von einem echten 4-MB-Fund nicht zu unterscheiden. Der C6 war genauso betroffen, da fiel es nur nie auf, weil 4 MB dort zufällig stimmt.

Ist gefixt und seit eben live: die Seite korrigiert die Basis selbst und liest die Flash-Kennung roh. Wenn sie nichts lesen kann, markiert sie jetzt gar kein Image mehr, statt eins zu empfehlen.

Magst du das unabhängig nachprüfen? https://sixback.io/boards.html mit deinem C5 N16R8 — hier wird jetzt das 16-MB-Image als passend markiert. Falls bei dir etwas anderes herauskommt, poste bitte die "Detected:"-Zeile.

[betateilchen]

Magst du das unabhängig nachprüfen? https://sixback.io/boards.html mit deinem C5 N16R8 — hier wird jetzt das 16-MB-Image als passend markiert.

Sieht gut aus.
Danke fürs Kümmern.

Du darfst diesen Dateianhang nicht ansehen.

[tostmann]

@betateilchen: kurze Rückmeldung, was aus Deinem "der C5 wird als 4-MB-Version erkannt" geworden ist — der Hinweis ist bis zu Espressif durchgelaufen.

Die Ursache lag nicht in SixBack, sondern in esptool-js, der Bibliothek hinter dem Web-Flasher: sie benutzt für C5, C6, C61 und H2 die SPI-Registerbasis des C3 (0x60002000 statt 0x60003000). Dadurch kam die Flash-ID als 0 zurück und die Größenerkennung fiel still auf "4MB" zurück — von echten 4 MB nicht zu unterscheiden. Auf der Flasher-Seite ist das seit dem 17.08. korrigiert, das hattest Du ja gegengetestet.

Upstream gab es dazu ein seit November offenes Issue ohne Ursachenanalyse. Ich habe die Messungen dort hinterlegt, und Espressif hat den Fix daraufhin selbst umgesetzt und um Review gebeten. Beim Nachmessen fiel noch ein zweiter, älterer Fehler auf (Flashen mit "detect" als Flash-Größe schlug immer fehl) — der ist im selben Pull Request mit erledigt.

https://github.com/espressif/esptool-js/issues/217
https://github.com/espressif/esptool-js/pull/253
https://github.com/espressif/esptool-js/issues/254

Gemerged ist der PR noch nicht. Sobald er in einer Release-Version landet, profitiert davon jedes Projekt, das esptool-js benutzt — nicht nur unseres. Danke für die Meldung.

[erwin23]

Hallo,
ich habe das Problem, das einige Sender aus Tunein nicht funktionieren, hier z.B. der RBB88.8 !
Ist das nur bei mir so? Hänge mal die Presets dran. Fehlerhaft ist der Preset 2

Code Auswählen Erweitern

<presets>
<preset id="1">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s228737" sourceAccount="" isPresetable="true">
<itemName>NDR 2 Hamburg</itemName>
<containerArt>https://sixback.io/stations/tunein-logo/s228737</containerArt>
</ContentItem>
</preset>
<preset id="2" createdOn="1787225403" updatedOn="1787225403">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s25677" sourceAccount="" isPresetable="true">
<itemName>rbb 88,8</itemName>
</ContentItem>
</preset>
<preset id="3">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s50412" sourceAccount="" isPresetable="true">
<itemName>Bremen Zwei</itemName>
<containerArt>https://sixback.io/stations/tunein-logo/s50412</containerArt>
</ContentItem>
</preset>
Beste Grüße

[betateilchen]

rbb88.8 funktioniert hier problemlos.

Code Auswählen Erweitern

<preset id="6" createdOn="1787227879" updatedOn="1787227879">
<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s25677" sourceAccount="" isPresetable="true">
<itemName>rbb 88,8</itemName>
</ContentItem>
</preset>

und spielt wunderbar.

[tostmann]

@erwin23: Ich habe die beiden Presets verglichen — der ContentItem in Deinem Preset 2 und der in betateilchens Preset 6 sind identisch, bis auf Nummer und Zeitstempel. Die Station ist auch unauffällig: s25677 liefert bei TuneIn eine reine MP3 mit 128 kbit, kein AAC und kein HLS, also keiner der beiden Fälle, die hier früher Ärger gemacht haben. Und ich habe Deinen ContentItem wortgleich auf einem SoundTouch 10 angespielt: läuft, über eine Minute stabil, mit Live-Text vom Sender.

Der Unterschied liegt damit nicht am Preset. Vier Fragen, damit ich weiterkomme:

- Welche SixBack-Version läuft bei Dir, und auf welchem Stick? Steht auf der Startseite unter sixback.local.
- Welches Speaker-Modell, und welcher Firmware-Stand?
- Was passiert genau, wenn Du Preset 2 drückst: bleibt es still, kommt die englische Ansage "not compatible", oder springt die Box nach ein paar Sekunden zurück?
- Du schreibst "einige Sender": laufen NDR 2 und Bremen Zwei aus Deinen Presets 1 und 3 auf derselben Box? Und welche gehen sonst noch nicht?

[erwin23]

Ich habe den ESP32 S3 neu geflasht und die Presets neu eingerichtet.
Jetzt geht auch Rbb88.8. Weiss der Teufel was das war.
Beste Grüße

[tostmann]

Danke — und ein Angebot, falls ihr Lust habt

Erst das, was zwischen den Bug-Reports untergeht: danke an fred_feuerstein und betateilchen. Eure Mitschnitte und das geduldige Nachstellen sind der Grund, warum aus etlichen Fehlern überhaupt Fixes geworden sind — die Portal-Reboot-Schleife wäre ohne Report von außen nie aufgefallen. Reports, die beschreiben was passiert ist statt was der Melder vermutet, sind selten.

Weil ihr ohnehin ESP32-Hardware auf dem Tisch habt: nebenher ist etwas fertig geworden, das für FHEM interessanter sein könnte als für Home Assistant.

Ein Thread Border Router, der auf dem Host fast nichts hinterlässt

Der Router läuft komplett in der Firmware des Sticks — kein RCP, kein Co-Prozessor. Die Verbindung zum Rechner ist der USB-Port des Chips; host-seitig macht ein Container daraus ein Netzwerk-Interface, und danach habt ihr eine IPv6-Route ins Thread-Netz.

Und genau das ist der Punkt für uns: kein otbr-agent, kein wpantund, kein Thread-Stack, kein Radio-Treiber. Nachgesehen, nichts davon liegt auf dem Rechner. Was läuft, sind zwei Python-Prozesse, ein tap-Interface, eine Route. Das gesamte Protokoll steckt auf dem Stick. Also nichts, was einer FHEM-Installation ins Gehege kommt, keine Daemon-Sammlung, die man sich ins System holt, und keine Abhängigkeit von der Home-Assistant-Welt — es gibt das Ganze als HA-Add-on und als normales Docker-Image, und der Docker-Weg hat mit HA nichts zu tun.

Nebeneffekt derselben Bauweise: das Thread-Netz überlebt alles auf dem Host. Container neu starten, austauschen, aktualisieren — das Mesh läuft weiter, weil es im Stick liegt. Gemessen: 18 Stunden ohne Reset über zwei Container-Updates hinweg.

... bevor jemand Zeit investiert

Ihr bekommt IP-Erreichbarkeit ins Thread-Netz. Ihr bekommt kein Matter. Im offiziellen FHEM-Modulverzeichnis liegen 619 Module, keines für Matter oder Thread. Eine fertige Matter-Lampe wird durch den Border Router allein also kein FHEM-Device — dafür fehlt der Protokoll-Stack samt Commissioning, und den löst dieses Projekt nicht.

Sinnvoll ist es heute für Geräte im Thread-Netz, die schlicht IP sprechen: eigene Firmware, CoAP, HTTP. Die erreicht ihr dann wie alles andere im Netz.

Hardware

ESP32-C6 mit 4 MB Flash am nativen USB-Port — das ist der Dauerbetrieb. Der C5 läuft auch, unverändert gebaut, hier gerade mit einem produktiven Netz; rund 130 KB freier Speicher gegen 265 KB beim C6. Vorbehalt: auf dem getesteten C5 setzte die Verbindung über den chipeigenen USB-Port gelegentlich aus, bis der Chip zurückgesetzt wurde — nicht jedes Mal, beim C6 nie; ein Board mit UART-Brücke macht das harmlos. Der H2 kann es nicht, dafür liefert Espressif keine Bibliothek.

Sticktausch ohne Neu-Anlernen

Die Netzdaten des Sticks landen in einer 24-KB-Datei, die in den HA-Backups mitläuft. Heute ausprobiert: von einem C6 gesichert, auf einen C5 zurückgespielt, C6 abgezogen, C5 an dessen Platz — das Mesh formte sich mit allen Knoten neu und die angelernte Lampe schaltete wieder, ohne ein einziges Gerät neu anzulernen. Die Datei überträgt die vollständige Identität des Routers; entsprechend dürfen zwei Sticks mit derselben Sicherung nie gleichzeitig senden.

Code Auswählen Erweitern

Quellen:  https://github.com/tostmann/THBR
Image:    docker pull tostmann/thbr

Lizenz PolyForm Noncommercial 1.0.0 — privat und nichtkommerziell frei.

Was mich interessieren würde

Was habt ihr an Hardware da, C6 oder C5? Und was wollt ihr über Thread erreichen — fertige Matter-Geräte oder eigene? Beim ersten sage ich gleich, dass der Weg in FHEM heute nicht zu Ende ist. Beim zweiten wird es interessant. Und wenn ihr gerade keine Lust auf ein weiteres Bastelprojekt habt: völlig in Ordnung, dann bleibt es beim Dank.

Inspiriert durch Matthias Kleines Youtube-Film "IKEA und Matter - wirklich so viele Probleme?"