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

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.

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!