BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

Begonnen von tostmann, 21 Mai 2026, 00:26:36

Vorheriges Thema - Nächstes Thema

fred_feuerstein

#150
Was bedeuten die markierten Einträge bei den beiden Presets? Das war jeweils mal eine Spotify Playlist, die über Sixback per drag/drop draufgezogen wurde. Aber aktuell sind andere Presets gespeichert, jeweils eine Zeile drüber sieht man es.
Beim Auslesen über das fhem BOSEST erscheinen als Presets nach wie vor nur die markierten Einträge bei den beiden Presets.

Also 1. Frage, was bedeutet es und 2. Frage wie bekomme ich die markierten Einträge wieder weg? (vorab: Reboot der Box hat nichts gebracht)

=> edit: ok, ein Reboot von Sixback hat geholfen. Nun passt es wieder. Nur die Frage 1 bleibt, was bedeuten die markierten Einträge bei über sixback hinterlegten Spotify Playlists.

Gruß, Fred

NEU: FHEM auf Raspberry PI 5, OS: Bookworm, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

tostmann

Hallo fred,

die markierte Zeile ist kein Preset, sondern die Spotify-Bindung des Slots — eine eigene Ebene neben dem Preset.

Wenn Du eine Playlist per Drag&Drop auf einen Slot ziehst, schreibt SixBack zwei Dinge: die Bindung (Slot → Playlist) und zusätzlich ein TuneIn-Preset namens "🎵 <Playlist>" auf den Speaker. Das zweite ist der Trick, mit dem die Hardware-Taste überhaupt Spotify starten kann: der Speaker spielt formal einen TuneIn-Sender, SixBack fängt den Aufruf ab und startet stattdessen Spotify. Deshalb steht im Speaker — und damit in dem, was BOSEST ausliest — der Playlist-Name und nicht der Sender.

Ziehst Du später einen normalen Sender auf den Slot, wird nur das Preset ersetzt. Die Bindung bleibt liegen und wird weiter angezeigt, obwohl sie nichts mehr tut: bei belegtem Slot spielt die Taste den Sender, die Bindung wird ignoriert. Harmlos also, aber die Anzeige führt in die Irre — das war eine Lücke unsererseits.

Im nächsten Release ist das behoben: beim Überschreiben eines Slots wird die alte Bindung jetzt automatisch mit entfernt, und an der Spotify-Zeile gibt es ein ✕, mit dem Du eine Bindung jederzeit manuell löschen kannst — das Preset bleibt dabei unangetastet.

Eine Rückfrage: was genau hat der SixBack-Reboot bei Dir gerichtet — die Spotify-Zeilen in der Oberfläche oder das, was BOSEST ausliest? Das hilft mir einzuordnen, ob da noch etwas anderes klemmt.

Gruß

fred_feuerstein

#152
Ja, der SixBack Reboot hat, nachdem die Presets auf eine andere Quelle verwiesen haben, auch diese Bindung entfernt. Somit hat auch die Anzeige in fhem etc. wieder gepasst.
Aber schön, wenn künftig ein "X" hinter der Bindungszeile ist, um diese auch direkt löschen zu können.

Heute früh hatte ich mal wieder das Problem, dass 3 Lautsprecher keine Presets mehr hatten. Reboot von den Lautsprechern und Reboot von SixBack hat nichts gebracht. Habe dann die gespeicherten Presets per Import wieder eingespielt jeweils. Gibts da einen Trick? Denn nach dem Einspielen der Presets bei einem Lautsprecher muss man dann "manuell" alle 6 einzeln per "Push" auf dem Speaker speichern, bzw. teilweise hat er nach dem 3. Preset-Push komischerweise die anderen 3 auch "übernommen".

Das Problem mit 6 leeren Presets bei Lautsprechern habe ich sporadisch. Konnte noch keinen Grund feststellen. Netzwerk, WLAN, Sixback, etc. läuft bzw. lief alles ganz normal, nur eben die Presets von ein paar Lautsprechern sind manchmal weg. Häufigkeit ggfs. alle 10 Tage mal...

Gruß, Fred

NEU: FHEM auf Raspberry PI 5, OS: Bookworm, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

betateilchen

#153
Zitat von: tostmann am 14 Juli 2026, 12:53:45Im nächsten Release kommt unabhängig davon ein Fix, der den Speicher-Peak im WebUI-Pfad senkt. Gut möglich, dass dir das auf dem C5 schon reicht — das müsstest du dann bei dir gegentesten.

Bei mir funktioniert das Auslesen von /presets mit .32 nicht mehr.

Im WebUI werden keine presets angezeigt, wenn ich versuche, den Status zu aktualisieren, bricht der Vorgang beim Auslesen von /presets mit der Meldung "device busy (low heap)" oder so ähnlich ab. Die Meldung wird nur extrem kurz angezeigt, bevor sich das Fenster schließt.

Du darfst diesen Dateianhang nicht ansehen.

Laut /api/status sieht heap aber nicht so ganz schlecht aus.

{
  "name": "SixBack",
  "version": "0.8.32",
  "build": "2026-07-15 23:25:40",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 857,
  "wifi": {
    "connected": true,
    "ssid": "mowg",
    "ip": "192.168.123.46",
    "rssi": -75,
    "channel": 40,
    "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": 70436,
    "min_free": 14996,
    "total": 257776
  },
  "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": 1,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 0,
    "last_wifi_down_s": 0,
    "last_reset": "POWERON",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 257
  }
}
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

tostmann

v0.8.33 ist raus (sixback.io, OTA + Web-Flasher; GitHub-Release-Notes haben die Details).

@betateilchen: das "device busy (low heap)" war ein Fehler von mir in .32 — die neue Heap-Prüfung hatte eine viel zu hohe Schwelle, auf dem C5 wurde damit praktisch jede Preset-Abfrage abgewiesen. In .33 behoben und auf einem C5 verifiziert. Auf dem C5 bitte per Web-Flasher aktualisieren, Knopf "Update existing" (behält WLAN/Presets/Spotify — Online-OTA ist auf dem C5 ja bewusst aus). /api/status zeigt jetzt zusätzlich largest_block und outbound_rejects. Und: die beiden C5 sind angekommen — vielen Dank! Der erste läuft schon im Testaufbau.

@fred: Deinen sporadischen Preset-Verlust nehme ich ernst. .33 baut dafür Diagnose ein: /api/status zeigt jetzt preset_store.load_ok und save_fails — und solange der gespeicherte Preset-Bestand unlesbar sein sollte, bekommen die Boxen beim Sync ein 404 statt einer leeren Liste und behalten ihre Presets. Zum Eingrenzen der Ursache:
  • Welchen Import hast Du zur Wiederherstellung benutzt — Datei-Import (⬆) oder "Import from device"?
  • Hattest Du zwischen Entdecken und Import den Refresh-Knopf gedrückt?
  • Welche 3 Boxen waren betroffen — sind das die mit Fritzbox-/DLNA-Presets?
  • Welche SixBack-Version lief am 16.07. früh?
  • Beim nächsten Vorfall bitte VOR der Wiederherstellung einmal /api/status sichern (Text kopieren reicht).

betateilchen

Zitat von: tostmann am 17 Juli 2026, 02:28:56die neue Heap-Prüfung hatte eine viel zu hohe Schwelle, auf dem C5 wurde damit praktisch jede Preset-Abfrage abgewiesen.

Danke für die Korrektur, sowas ähnliches hatte ich schon vermutet.
 
Bei drei von vier Boxen werden die Presets jetzt auch wieder angezeigt, bei der vierten Box tritt wieder die "low heap" Meldung (bei freiem Speicher zwischen 45 und 62kB) auf. Das Ganze lasse ich jetzt mal ohne geöffnetes WebUI eine Weile laufen und werde beobachten, ob sich das irgendwann von selbst erledigt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

fred_feuerstein

#156
Zitat von: tostmann am 17 Juli 2026, 02:28:56@fred: Deinen sporadischen Preset-Verlust nehme ich ernst. .33 baut dafür Diagnose ein: /api/status zeigt jetzt preset_store.load_ok und save_fails — und solange der gespeicherte Preset-Bestand unlesbar sein sollte, bekommen die Boxen beim Sync ein 404 statt einer leeren Liste und behalten ihre Presets. Zum Eingrenzen der Ursache:
  • Welchen Import hast Du zur Wiederherstellung benutzt — Datei-Import (⬆) oder "Import from device"?
  • Hattest Du zwischen Entdecken und Import den Refresh-Knopf gedrückt?
  • Welche 3 Boxen waren betroffen — sind das die mit Fritzbox-/DLNA-Presets?
  • Welche SixBack-Version lief am 16.07. früh?
  • Beim nächsten Vorfall bitte VOR der Wiederherstellung einmal /api/status sichern (Text kopieren reicht).


zu deinen Fragen:
  • ich hatte Datei Import gemacht (habe von allen Boxen den entsprechenden Export nach Einrichtung erstellt), wo wäre denn der Punkt "Import from device" zu finden?
  • ich hatte Browser-Reload, Status beim Speaker und Gesamt-Refresh getestet. Hatte alles nicht geholfen, die Presets waren leer.
  • bei mir hat jede Box 1 Preset auf eine Playlist von der Fritzbox. Die anderen Presets sind Radio-Kanäle von tunein über SixBack. Bei 1 Box habe ich 2 Playlists von Spotify drauf.
  • es lief die .29 - werde jetzt mal auf die .33 gehen.
  • /api/status werde ich wenn es mal wieder vorkommt sichern

edit:
bin nun auf der .33 und nach dem Update kam bei einer Box gleich das Problem mit leeren Presets. Refresh zeigt bei dieser Box kurz Fehler 502, nicht erreichbar. Danach Status beim Speaker selbst läuft durch, aber presets sind leer. Im Anschluss Gesamt Refresh läuft durch und zeigt bei dem Speaker 0/6. Also leere Presets.

Hier der Api-Status:
{"name":"SixBack","version":"0.8.33","build":"2026-07-17 02:16:41","license":"PolyForm-Noncommercial-1.0.0","copyright":"Copyright (c) 2026 Dirk Tostmann","uptime_s":334,"wifi":{"connected":true,"ssid":"hannebambel HOME","ip":"192.168.123.173","rssi":-69,"channel":11,"band":"2.4GHz","mac":"1C:DB:D4:74:9F:44","hostname":"sixback.local","improv_active":false,"improv_window_s":0,"captive_active":false,"captive_window_s":0},"heap":{"free":112580,"min_free":55064,"total":340176,"largest_block":41972,"outbound_rejects":0},"psram":{"free":8361488,"total":8388608},"chip":{"model":"ESP32-S3","cores":2,"revision":2,"flash_size":16777216},"cloud_replacement":{"port":8000,"base_url":"http://192.168.123.173:8000"},"speakers_count":9,"scan_in_progress":false,"groups_persist_ok":true,"preset_store":{"load_ok":true,"save_fails":6,"speakers":8},"health":{"boot_count":1,"crash_count":0,"wifi_reboots":0,"heap_reboots":0,"wifi_disconnects":0,"last_wifi_down_s":0,"last_reset":"SW","wdt_subscribed":true,"wifi_down_for_s":0,"heap_low_for_s":0,"heap_low_events":0,"last_heap_low_s":0,"last_ping_age_s":34}}
Werde jetzt wieder den Import-Button nutzen.
Komischerweise hatte ich auch bei dem ganzen Status Refresh usw. bei anderen Boxen auch unter jedem Preset den Push-Button als wenn etwas geändert worden wäre. Ein Status-Button bei dem jeweiligen Speaker hat es gerichtet. Ist irgendwie komisches Verhalten.
Aber der eine Speaker bleibt bei 6 leeren Presets. Wie gesagt Import-Button genutzt (dabei kam rechts unten wieder kurz eine 502 Meldung, aber der Speaker ist erreichbar), dann nochmal Status und Browser-Reload und die 6 Presets sind wieder da...
Gruß, Fred

NEU: FHEM auf Raspberry PI 5, OS: Bookworm, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

fred_feuerstein

#157
Zwischendurch mal den aktuellen Stand bei meiner einzelnen Box im Büro (anderes WLAN, Netzwerk etc.) mit separatem SixBack:

Gruß, Fred

NEU: FHEM auf Raspberry PI 5, OS: Bookworm, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art