v0.8.30 — no-PSRAM heap headroom (#121) + WebUI stability under load

v0.8.30 — no-PSRAM heap headroom (#121) + WebUI stability under load

• fix: no-PSRAM chips (C5/C6/C3) skip the eager Spotify init, freeing ~18-22 KB heap; fixes the WebUI page-load crash that dropped Wi-Fi under load (FHEM #144729, #121)
• fix: heap-floor guards on page-serving + refresh-status as a safety net under heavy concurrency
• build: improv pin -> 31cfd22 (drop forced channel in connectToStrongest, avoids AP_STA MIC failure at captive provisioning)
• docs: web-flasher UART vs native-USB socket hint for provisioning

Verified on no-PSRAM C5 (1-tab crash 3/8 -> 0/8), S3 no regression. App-only, OTA-compatible.

v0.8.29 — Auto-Migrate toggle persistence + honest NVS save

Fixes

• fix(auto-mode): PUT /api/auto-mode now reports the real persist result instead of always returning ok:true. saveAutoModeConfig returns a bool and the handler returns HTTP 500 + the actually-stored value when the NVS write fails — so the Web UI surfaces a failure instead of a false success. This was the root cause of the Auto-Migrate at Boot switch silently snapping back (FHEM #144729).
• fix(auto-mode): sixback-auto/config now uses the cleanup-retry NVS save (purge regenerable caches on a full partition, then retry), like the other user-settings stores.
• feat(groups): the stereo-pair group store uses the same cleanup-retry save, and /api/status gains a groups_persist_ok health flag. Speaker-facing BMX responses are unchanged (still 201/200) — the failure is surfaced to the operator, not the frozen device firmware.
• build(c5): online TLS-OTA self-update is marked unsupported on the no-PSRAM C5 (the mbedtls/HW-AES buffers can't be allocated on its heap); the pull now reports cleanly instead of a cryptic error. Local multipart /api/ota (USB / web-flasher) is unaffected.

Verified end-to-end on a freshly-erased C5: a non-default toggle value now survives a reboot. App-only change (no partition change) — OTA-compatible.

Flash / update: https://sixback.io/

v0.8.28 — ESP32-C5 dual-band target + provisioning hardening

New target: ESP32-C5 (dual-band Wi-Fi 6). Both provisioning paths verified on real C5 hardware, each ending in a 5 GHz association with reboot-persistent credentials. Web flasher at https://sixback.io/ auto-detects the chip.

Provisioning hardening (all chips):

• Captive portal: the WiFi scan now runs asynchronously instead of blocking the web-server task — on dual-band chips the ~9 s two-band scan tripped the 5 s task watchdog and rebooted the device the moment the setup page loaded (an endless reboot loop during setup).
• The setup window is idle-based (5 min since last interaction, 30 min hard cap) instead of a hard 5-minute cutoff, and an in-flight connect attempt is never aborted at window end.
• After a successful portal setup the device restarts once, so the Web UI comes up reliably.
• Improv-Serial: stray serial bytes after the 120 s window no longer wedge an unprovisioned device.
• Fresh external builds work again (the improv-wifi-busware pin now references a commit that exists on the public remote).

Update via OTA (Settings → Check for update) or https://sixback.io/.

v0.8.27

Highlights

• Refresh status no longer freezes the Web UI on large speaker zones. The 🔄 Refresh status used to run the whole inventory probe (per-speaker Telnet/BMX status check, a stale-view retry, and a Spotify-source pull) synchronously inside the single request the browser was waiting on — so on a big zone the UI locked up at the first step. The probe now runs in a background task (the same pattern as Discover): the UI stays responsive and polls until it finishes, and the HTTP client gained a request timeout so no call can hang forever. (reported on the FHEM forum)
• Optional Web UI password protection. You can now enable an optional HTTP Digest login for the Web UI and its /api (off by default; configured via /api/ui-auth). It gates only the Web UI / API surface — the endpoints the speakers themselves talk to stay open, so device compatibility is unaffected. On a plain-HTTP LAN this is deterrence, not a substitute for network isolation. (#31)
• ESP32-C5 build-target skeleton — groundwork only, not yet a shipping target (no C5 hardware validated).

Update

Install or update over-the-air from https://sixback.io/. An OTA update keeps your device's WiFi, presets and settings (NVS is preserved).

v0.8.26 — SixBack badge on the speaker display

Speakers with a built-in display (SoundTouch 20 / 30) now show a "SIX BACK" badge as the source icon, instead of a blank icon.

Until now SixBack served a blank placeholder for the source icon that the speaker fetches from the local server, so nothing appeared on the display. It now serves a small SixBack wordmark for every source (TuneIn, custom/LAN streams) — so the speaker's display shows, right on the device, that the source is served by SixBack, your local cloud replacement.

It's a deliberate own-brand badge rather than a third-party logo. Verified on real ST30 hardware. (The per-station logo of an individual station can't be shown on these displays — that's a limitation of the speaker's panel, not of SixBack.)

Update over the air via System → Check for update, or re-flash from https://sixback.io/.

v0.8.25 — Clock display toggle (ST20/ST30) + STORED_MUSIC self-heal (#30)

Clock display on/off for ST20 / ST30

Speakers that have a display (SoundTouch 20 / 30) now get a 🕒 Clock display on/off switch on their card in the Web UI. SixBack toggles the device clock directly on the speaker (:8090/clockDisplay), and the switch only appears on speakers that actually have a display. Verified on real ST30 hardware — the display is a plain on/off (it has no dimming), so there is no brightness control.

STORED_MUSIC source self-heal (#30)

Fixes a case where pushing a DLNA / STORED_MUSIC preset could fail ("speaker hardware out of sync") after a power outage rebooted your whole network: the speaker came back before its DLNA media servers were rediscovered, so its STORED_MUSIC source was never re-registered — while TuneIn and DLNA browsing kept working, which is exactly the symptom. SixBack now detects this on its periodic status check and re-registers the source automatically, with no user action needed.

---

Existing sticks update over the air — no re-flash required.

v0.8.23 — Hardware preset buttons re-armed (#15) + WebUI security + speaker fingerprint

v0.8.23 — Hardware preset buttons re-armed (#15), WebUI security headers, speaker fingerprint

Hardware preset buttons work again for cold Internet-Radio slots (#15)

A physical press of a preset button (1–6) on the speaker is now detected in real time over the Bose gabbo notification WebSocket (ws://<speaker>:8080/, reachable on the LAN). When a Local-Internet-Radio slot fails to start from a cold/idle speaker — no playback state, or INVALID_SOURCE — SixBack re-arms it through the native ORION /select, the same path the WebUI Play button got in v0.8.20, now hardware-triggered. So the physical button just plays the station again.

Implemented as a small hand-rolled RFC6455 WebSocket client (zero new dependencies), kept open per owned speaker that actually has Internet-Radio presets, with a three-layer loop-guard against re-select storms and an active liveness ping + idle-reconnect.

Availability: ESP32-S3 / S3-8MB only (needs PSRAM). Compiled out (no-op) on C3 / C6 / ESP32-classic.

WebUI security headers

The device Web UI now ships a Content-Security-Policy and X-Content-Type-Options: nosniff as defense-in-depth against XSS from untrusted data rendered in the UI (RadioBrowser / TuneIn / DLNA station names, custom stream URLs). The single-file UI is inline-heavy, so script-src keeps 'unsafe-inline'; the hardening is frame-ancestors 'none' / object-src 'none' / base-uri / form-action plus https-only img / connect.

Speaker hardware fingerprint

The speaker's moduleType (sm2 / scm) and variant (rhino / mojo / spotty) are now parsed from /info and surfaced in /api/speakers, so hardware revisions that the model name (e.g. SoundTouch 20) hides can be told apart for support.

Also

Hardening from an internal code review of the new WebSocket client: active liveness detection so a silently-dropped connection reconnects instead of going deaf, explicit connect/read timeouts, and frame-parser robustness fixes.

---

Flash or update from https://sixback.io/.

v0.8.22 — Rename fix for migrated speakers + status reliability

Rename now works on migrated speakers. A cloud-bound speaker doesn't apply a rename locally — it delegates it to its cloud account endpoint. SixBack now handles that callback (PUT /streaming/account/{a}/device/{deviceId}), so renaming from the Web UI sticks on migrated speakers too. (The earlier "one rename per power-on" explanation was wrong and has been corrected.)

Speaker status reliability. Fixed a status-tile flicker where the reachability fall-back probe hit the wrong port and reported a live speaker as offline — it now targets the speaker's BMX port, with a longer timeout and a 2-strike debounce before a card flips to offline.

OTA hardening. A size-scaled stall backstop aborts a transfer that stops making progress, scaled to image size instead of a fixed timeout.

Docs. README Status table refreshed to v0.8.22; rename mechanism corrected; v0.8.19 / 0.8.20 / 0.8.21 rows added.

Install / update: web flasher at https://sixback.io/ — or pull over the air from the Web UI.

v0.8.21 — More robust migration on weak WiFi

v0.8.21 — More robust migration on weak WiFi

• Migration retry: the telnet migration step now retries (3×, with backoff), so a single dropped packet on a weak WiFi link no longer aborts the whole migration. If it still can't reach the speaker, the error points at the likely cause — a weak signal — and shows the ESP's RSSI, instead of a generic "command failed". (Discussion #28)
• Placement tip surfaced by that case: put the SixBack stick near your router / access point, not near the Bose speaker — the two only talk over the LAN; what matters is a strong link between the ESP and your AP. The C6/C3 have a weaker antenna (and no PSRAM) than an S3, so they're more placement-sensitive.
• CPU clock: now set to each chip's maximum (240 MHz on S3, 160 MHz on C3/C6) instead of a hardcoded 240 that logged a harmless error on C3/C6.
• Internal: framework include paths are resolved portably instead of via a hardcoded absolute path (no behaviour change).

Update: System → Check for update (OTA), or the web flasher's "Update existing" button (keeps your WiFi and presets).

Relates to Discussion #28.

v0.8.20 — Custom-radio presets play reliably from the web UI

v0.8.20 — Custom-radio presets play reliably from the web UI

Clicking a Custom Stations (internet-radio) preset in the web UI now re-resolves the stream before playing, instead of emulating a preset-key press. That's the path that reliably starts the speaker's playback engine, so a custom-radio preset plays from cold — including after you've switched to another preset and back.

• Previously, playing a custom-radio preset from the UI could leave the speaker connected but silent (flashing white LED, no audio), because a plain preset-key press doesn't re-arm a cold custom-radio source.
• Other sources (TuneIn, etc.) are unchanged. The physical preset button on the speaker is also unchanged — the Bose firmware sends no event when it's pressed, so SixBack can't re-arm the source for it; trigger custom radio from the web UI for reliable playback.

Verified on a SoundTouch 10: from a cold source the old button-press path connected but never started audio, while the new path starts playback every time.

Build: the platform is now pinned to pioarduino 55.03.37 so every build host produces the same binaries.

Update: System → Check for update (OTA), or the web flasher's "Update existing" button (keeps your WiFi and presets).

Resolves Discussion #15.