mirror of
https://github.com/gesellix/Bose-SoundTouch.git
synced 2026-08-24 14:47:23 +00:00
Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
e424ee6546 | ||
|
|
d9d9a67f0e | ||
|
|
e0a84d5904 | ||
|
|
5d080cf35f | ||
|
|
bcd383bdff | ||
|
|
7a09a2ddc0 | ||
|
|
b04b0bcc32 | ||
|
|
61b5c71097 | ||
|
|
9f7cb81b45 | ||
|
|
d5d6585517 | ||
|
|
50b694aa08 | ||
|
|
717693e01f | ||
|
|
a0833c113c | ||
|
|
e74d2e0fc3 | ||
|
|
5b642010d4 | ||
|
|
5078d933d5 | ||
|
|
6cf511e7e5 | ||
|
|
ba11394d0f | ||
|
|
37eb23fc36 | ||
|
|
4544486221 | ||
|
|
17bd3ea9ed | ||
|
|
ad5344b309 | ||
|
|
8d95e170f6 | ||
|
|
565ca33345 | ||
|
|
e2d52d9e3b | ||
|
|
f3b74998f1 | ||
|
|
ce15e706b8 | ||
|
|
bc61081acc | ||
|
|
16f7327b7a | ||
|
|
2e9f931797 | ||
|
|
41378f720b | ||
|
|
c87a28f3ba | ||
|
|
df18749220 | ||
|
|
b6702cd4b5 | ||
|
|
fc5de2bbc7 | ||
|
|
cf82feca06 | ||
|
|
b8bbc52803 | ||
|
|
a36c2e4629 | ||
|
|
d15cebdc95 | ||
|
|
d296b59a9e | ||
|
|
d2aaed0f9f | ||
|
|
eb50e9b6f6 | ||
|
|
1e24ca076a | ||
|
|
b19835427b | ||
|
|
6ee0fc8115 | ||
|
|
6211e34050 | ||
|
|
2132674768 | ||
|
|
b4c015ef75 | ||
|
|
5d22a53c8b | ||
|
|
f4268f3111 | ||
|
|
71fd9c1531 | ||
|
|
53184a6bca | ||
|
|
d97cd45b22 | ||
|
|
5edab77209 | ||
|
|
a1d0213f92 | ||
|
|
0b75a2f70d | ||
|
|
0090746b89 | ||
|
|
be762dbc22 | ||
|
|
403e2275dc | ||
|
|
9ee1c96477 | ||
|
|
b71a3830ec | ||
|
|
f50ee1131e | ||
|
|
6a65376784 | ||
|
|
44d04a2b41 | ||
|
|
0f802e65c6 | ||
|
|
01d702c745 | ||
|
|
7823b68bdd | ||
|
|
e1f3fc36c8 | ||
|
|
d68599896d | ||
|
|
d18b67d80f | ||
|
|
8642ecfc5c | ||
|
|
c37e94b5f8 | ||
|
|
4e33f6948f | ||
|
|
743ff5e061 | ||
|
|
ec8bbb2f86 | ||
|
|
e75e2bea0c | ||
|
|
dd5aa2ad53 | ||
|
|
aced0f3f81 | ||
|
|
a886518cad | ||
|
|
dc81b0aa81 | ||
|
|
c648027735 | ||
|
|
fced88a8a6 | ||
|
|
0ee673c097 | ||
|
|
395b2fec8e | ||
|
|
be7e44e14b | ||
|
|
a87783d8c6 | ||
|
|
be017440b7 | ||
|
|
10de011c18 | ||
|
|
f7b74db3ea | ||
|
|
72d75133c4 | ||
|
|
e4c12471b4 | ||
|
|
3329149282 | ||
|
|
523ff0eb17 | ||
|
|
025e15d65c | ||
|
|
7d140b3e2a | ||
|
|
69210638e5 | ||
|
|
6aef2b807d | ||
|
|
95f5e9c831 | ||
|
|
7337296ae9 | ||
|
|
92a5d3592c | ||
|
|
2f04af872b | ||
|
|
9479d6d11d | ||
|
|
f687ba0d82 | ||
|
|
ab2bf0731a | ||
|
|
cafaba1be0 | ||
|
|
93082d2cdc | ||
|
|
087006c483 | ||
|
|
b7013a5ec8 | ||
|
|
7d76b3fab2 | ||
|
|
6ca206053f | ||
|
|
090eb162fb | ||
|
|
972824e07f | ||
|
|
1e2148d53b | ||
|
|
9a070da1ef | ||
|
|
d4b518da23 | ||
|
|
89bafd97b6 | ||
|
|
d616bc09fd | ||
|
|
8af60c7e4b | ||
|
|
8a21db3517 | ||
|
|
742484568e | ||
|
|
ed2d8680e4 | ||
|
|
6dc8c23f04 | ||
|
|
fa57ee9574 | ||
|
|
e438db05d9 | ||
|
|
8c02a009dc | ||
|
|
f20cfcb319 | ||
|
|
a453059d6d | ||
|
|
505e6dd760 | ||
|
|
735187cae8 | ||
|
|
e8622cc382 | ||
|
|
c59052bdb4 | ||
|
|
15a6c4b0a0 | ||
|
|
ae3a3765db | ||
|
|
59019cf55c | ||
|
|
5e612e57ec | ||
|
|
02026a9f3a | ||
|
|
aaf067088a | ||
|
|
358ea18138 | ||
|
|
0c5c1803a5 | ||
|
|
cdf80a793e | ||
|
|
b511e052e2 | ||
|
|
b7197a8679 | ||
|
|
5bfc24b7fb | ||
|
|
1e61adbb46 | ||
|
|
b8ab4b5723 | ||
|
|
5da7e001b2 | ||
|
|
5269c05e56 | ||
|
|
d7a15c4dbe | ||
|
|
701889076d | ||
|
|
3acc983183 | ||
|
|
7d40c61cad | ||
|
|
93cfd9dbbc | ||
|
|
e084f8db1f | ||
|
|
a19d34b55e | ||
|
|
dcf2e29c16 | ||
|
|
9be1c7d588 | ||
|
|
133c07fefa | ||
|
|
ef90b4e848 | ||
|
|
c8ef1a9de4 | ||
|
|
e47fa4c92c | ||
|
|
1a39c14b35 | ||
|
|
c9f648096e | ||
|
|
408753c33e | ||
|
|
dff060565e | ||
|
|
b5df6ab91f | ||
|
|
c7e055eb51 | ||
|
|
00d5bfcb69 | ||
|
|
0186fead6e | ||
|
|
bf4ead033c | ||
|
|
5eee3ec31e | ||
|
|
30e09ab7a0 | ||
|
|
e429d92124 | ||
|
|
f3162b7ed9 | ||
|
|
8094ac70bd |
@@ -0,0 +1,17 @@
|
||||
root = true
|
||||
|
||||
[*]
|
||||
indent_style = space
|
||||
indent_size = 4
|
||||
end_of_line = lf
|
||||
charset = utf-8
|
||||
trim_trailing_whitespace = true
|
||||
insert_final_newline = true
|
||||
|
||||
[*.html]
|
||||
# HTML-specific formatting
|
||||
# Standardize on tag layout
|
||||
ij_html_do_not_indent_children_of_tags = html,body,thead,tbody,tfoot
|
||||
ij_html_keep_blank_lines = 1
|
||||
ij_html_attribute_wrap = normal
|
||||
ij_html_space_inside_empty_tag = false
|
||||
@@ -1,6 +1,9 @@
|
||||
# Bose SoundTouch Configuration
|
||||
# Copy this file to .env and customize for your setup
|
||||
|
||||
# Docker/Service Settings
|
||||
SOUNDTOUCH_HOSTNAME=soundtouch.local
|
||||
|
||||
# Discovery Settings
|
||||
DISCOVERY_TIMEOUT=5s
|
||||
UPNP_ENABLED=true
|
||||
@@ -38,3 +41,20 @@ PREFERRED_DEVICES="Living Room@192.168.1.100:8090;Kitchen@192.168.1.101;192.168.
|
||||
# Alternative format examples:
|
||||
# PREFERRED_DEVICES="192.168.178.35;192.168.178.28"
|
||||
# PREFERRED_DEVICES="SoundTouch 10@192.168.178.35;SoundTouch 20@192.168.178.28"
|
||||
|
||||
# Spotify Integration
|
||||
# Create an app at https://developer.spotify.com/dashboard
|
||||
# SPOTIFY_CLIENT_ID=your_client_id
|
||||
# SPOTIFY_CLIENT_SECRET=your_client_secret
|
||||
# Auth confirmation url using GET, works in browsers
|
||||
# SPOTIFY_REDIRECT_URI=https://your-server.example.com/mgmt/spotify/callback
|
||||
# Auth confirmation url using POST, works with the ueberboese-app (https://github.com/julius-d/ueberboese-app)
|
||||
# SPOTIFY_REDIRECT_URI=https://your-server.example.com/mgmt/spotify/confirm
|
||||
|
||||
# Management API Authentication
|
||||
# Protects /mgmt/* endpoints (Spotify token access, account management)
|
||||
MGMT_USERNAME=admin
|
||||
MGMT_PASSWORD=change_me!
|
||||
|
||||
# External base URL (required when behind a reverse proxy for OAuth callbacks)
|
||||
# BASE_URL=https://your-server.example.com
|
||||
|
||||
@@ -25,6 +25,9 @@
|
||||
},
|
||||
{
|
||||
"pattern": "^https://pkg.go.dev.*badge"
|
||||
},
|
||||
{
|
||||
"pattern": "^\\.\\./images/(dashboard-home|account-creation|account-dashboard|usb-remote-services|device-discovery|device-registration|account-migration|migration-setup|migration-progress|migration-health|migration-complete|backup-setup)\\.png$"
|
||||
}
|
||||
],
|
||||
"replacementPatterns": [
|
||||
|
||||
@@ -1,5 +1,8 @@
|
||||
name: CI
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
@@ -40,8 +43,14 @@ jobs:
|
||||
- name: Run tests
|
||||
run: go test -v -race -coverprofile=coverage.out ./...
|
||||
|
||||
- name: Build service
|
||||
run: make build-service
|
||||
|
||||
- name: Run HTTP client integration tests
|
||||
run: make test-http-client
|
||||
|
||||
- name: Upload coverage to Codecov
|
||||
uses: codecov/codecov-action@v5
|
||||
uses: codecov/codecov-action@v6
|
||||
with:
|
||||
file: ./coverage.out
|
||||
flags: unittests
|
||||
@@ -100,7 +109,7 @@ jobs:
|
||||
go build -o "$output_name" ./cmd/soundtouch-cli
|
||||
|
||||
- name: Upload build artifacts
|
||||
uses: actions/upload-artifact@v6
|
||||
uses: actions/upload-artifact@v7
|
||||
with:
|
||||
name: soundtouch-cli-${{ matrix.goos }}-${{ matrix.goarch }}
|
||||
path: soundtouch-cli-*
|
||||
@@ -144,13 +153,36 @@ jobs:
|
||||
use-verbose-mode: "yes"
|
||||
config-file: ".github/markdown-link-check.json"
|
||||
|
||||
- name: Warn on pending images
|
||||
run: |
|
||||
IMAGES=(
|
||||
"dashboard-home.png"
|
||||
"account-creation.png"
|
||||
"account-dashboard.png"
|
||||
"usb-remote-services.png"
|
||||
"device-discovery.png"
|
||||
"device-registration.png"
|
||||
"account-migration.png"
|
||||
"migration-setup.png"
|
||||
"migration-progress.png"
|
||||
"migration-health.png"
|
||||
"migration-complete.png"
|
||||
"backup-setup.png"
|
||||
)
|
||||
|
||||
for img in "${IMAGES[@]}"; do
|
||||
if [ ! -f "docs/images/$img" ]; then
|
||||
echo "::warning file=docs/guides/MIGRATION-GUIDE.md::Pending image '$img' is missing from docs/images/"
|
||||
fi
|
||||
done
|
||||
|
||||
- name: Validate API documentation
|
||||
run: |
|
||||
# Check that all documented endpoints exist in code
|
||||
echo "Validating API documentation consistency..."
|
||||
|
||||
# Extract endpoint patterns from cookbook
|
||||
if [ -f "docs/API-COOKBOOK.md" ]; then
|
||||
# Check API cookbook
|
||||
if [ -f "docs/reference/API-COOKBOOK.md" ]; then
|
||||
echo "✓ API Cookbook exists"
|
||||
else
|
||||
echo "✗ API Cookbook missing"
|
||||
@@ -158,7 +190,7 @@ jobs:
|
||||
fi
|
||||
|
||||
# Check getting started guide
|
||||
if [ -f "docs/GETTING-STARTED.md" ]; then
|
||||
if [ -f "docs/guides/GETTING-STARTED.md" ]; then
|
||||
echo "✓ Getting Started guide exists"
|
||||
else
|
||||
echo "✗ Getting Started guide missing"
|
||||
@@ -230,11 +262,11 @@ jobs:
|
||||
uses: actions/checkout@v6
|
||||
|
||||
- name: Set up Docker Buildx
|
||||
uses: docker/setup-buildx-action@v3
|
||||
uses: docker/setup-buildx-action@v4
|
||||
|
||||
- name: Log in to GitHub Container Registry
|
||||
if: github.event_name == 'push' && github.ref == 'refs/heads/main'
|
||||
uses: docker/login-action@v3
|
||||
uses: docker/login-action@v4
|
||||
with:
|
||||
registry: ghcr.io
|
||||
username: ${{ github.actor }}
|
||||
@@ -242,7 +274,7 @@ jobs:
|
||||
|
||||
- name: Extract metadata (tags, labels) for Docker
|
||||
id: meta
|
||||
uses: docker/metadata-action@v5
|
||||
uses: docker/metadata-action@v6
|
||||
with:
|
||||
images: ghcr.io/${{ github.repository }}
|
||||
tags: |
|
||||
@@ -250,9 +282,10 @@ jobs:
|
||||
type=ref,event=pr
|
||||
|
||||
- name: Build and push Docker image
|
||||
uses: docker/build-push-action@v6
|
||||
uses: docker/build-push-action@v7
|
||||
with:
|
||||
context: .
|
||||
platforms: linux/amd64,linux/arm64,linux/arm64/v8,linux/arm/v7
|
||||
push: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}
|
||||
tags: ${{ steps.meta.outputs.tags }}
|
||||
labels: ${{ steps.meta.outputs.labels }}
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
name: Deploy Documentation
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
paths:
|
||||
- 'docs/**'
|
||||
workflow_dispatch:
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
pages: write
|
||||
id-token: write
|
||||
|
||||
jobs:
|
||||
deploy:
|
||||
environment:
|
||||
name: github-pages
|
||||
url: ${{ steps.deployment.outputs.page_url }}
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v6
|
||||
- name: Setup Pages
|
||||
uses: actions/configure-pages@v5
|
||||
- name: Build with Jekyll
|
||||
uses: actions/jekyll-build-pages@v1
|
||||
with:
|
||||
source: 'docs/'
|
||||
destination: '_site'
|
||||
- name: Upload artifact
|
||||
uses: actions/upload-pages-artifact@v4
|
||||
with:
|
||||
path: '_site'
|
||||
- name: Deploy to GitHub Pages
|
||||
id: deployment
|
||||
uses: actions/deploy-pages@v5
|
||||
@@ -133,10 +133,13 @@ jobs:
|
||||
local CMD_PATH=$2
|
||||
local OUTPUT_NAME
|
||||
|
||||
# Ensure build directory exists
|
||||
mkdir -p build
|
||||
|
||||
if [[ "${{ matrix.goos }}" == "windows" ]]; then
|
||||
OUTPUT_NAME="${BINARY_NAME}-v${{ needs.validate.outputs.version }}-${ARCH_SUFFIX}.exe"
|
||||
OUTPUT_NAME="build/${BINARY_NAME}-v${{ needs.validate.outputs.version }}-${ARCH_SUFFIX}.exe"
|
||||
else
|
||||
OUTPUT_NAME="${BINARY_NAME}-v${{ needs.validate.outputs.version }}-${ARCH_SUFFIX}"
|
||||
OUTPUT_NAME="build/${BINARY_NAME}-v${{ needs.validate.outputs.version }}-${ARCH_SUFFIX}"
|
||||
fi
|
||||
|
||||
echo "Building $BINARY_NAME: $OUTPUT_NAME"
|
||||
@@ -159,7 +162,7 @@ jobs:
|
||||
|
||||
# Build CLI
|
||||
build_binary "soundtouch-cli" "./cmd/soundtouch-cli"
|
||||
|
||||
|
||||
# Build Service
|
||||
build_binary "soundtouch-service" "./cmd/soundtouch-service"
|
||||
id: build
|
||||
@@ -189,12 +192,12 @@ jobs:
|
||||
echo "✅ Checksums generated successfully"
|
||||
|
||||
- name: Upload build artifact
|
||||
uses: actions/upload-artifact@v6
|
||||
uses: actions/upload-artifact@v7
|
||||
with:
|
||||
name: binaries-${{ matrix.goos }}-${{ matrix.goarch }}${{ matrix.goarm }}
|
||||
path: |
|
||||
soundtouch-cli-v*
|
||||
soundtouch-service-v*
|
||||
build/soundtouch-cli-v*
|
||||
build/soundtouch-service-v*
|
||||
retention-days: 1
|
||||
|
||||
checksums:
|
||||
@@ -203,9 +206,10 @@ jobs:
|
||||
needs: [validate, build]
|
||||
|
||||
steps:
|
||||
- name: Download all artifacts
|
||||
uses: actions/download-artifact@v7
|
||||
- name: Download binary artifacts
|
||||
uses: actions/download-artifact@v8
|
||||
with:
|
||||
pattern: binaries-*
|
||||
path: ./binaries
|
||||
|
||||
- name: Generate checksums
|
||||
@@ -260,7 +264,7 @@ jobs:
|
||||
fi
|
||||
|
||||
- name: Upload checksums
|
||||
uses: actions/upload-artifact@v6
|
||||
uses: actions/upload-artifact@v7
|
||||
with:
|
||||
name: checksums
|
||||
path: |
|
||||
@@ -271,7 +275,7 @@ jobs:
|
||||
retention-days: 1
|
||||
|
||||
- name: Upload all release assets
|
||||
uses: actions/upload-artifact@v6
|
||||
uses: actions/upload-artifact@v7
|
||||
with:
|
||||
name: release-assets
|
||||
path: binaries/release-files/
|
||||
@@ -290,7 +294,7 @@ jobs:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Download release assets
|
||||
uses: actions/download-artifact@v7
|
||||
uses: actions/download-artifact@v8
|
||||
with:
|
||||
name: release-assets
|
||||
path: ./release-assets
|
||||
@@ -460,7 +464,7 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Download release assets
|
||||
uses: actions/download-artifact@v7
|
||||
uses: actions/download-artifact@v8
|
||||
with:
|
||||
name: release-assets
|
||||
path: ./release-assets
|
||||
@@ -488,10 +492,10 @@ jobs:
|
||||
uses: actions/checkout@v6
|
||||
|
||||
- name: Set up Docker Buildx
|
||||
uses: docker/setup-buildx-action@v3
|
||||
uses: docker/setup-buildx-action@v4
|
||||
|
||||
- name: Log in to GitHub Container Registry
|
||||
uses: docker/login-action@v3
|
||||
uses: docker/login-action@v4
|
||||
with:
|
||||
registry: ghcr.io
|
||||
username: ${{ github.actor }}
|
||||
@@ -499,7 +503,7 @@ jobs:
|
||||
|
||||
- name: Extract metadata (tags, labels) for Docker
|
||||
id: meta
|
||||
uses: docker/metadata-action@v5
|
||||
uses: docker/metadata-action@v6
|
||||
with:
|
||||
images: ghcr.io/${{ github.repository }}
|
||||
tags: |
|
||||
@@ -508,9 +512,10 @@ jobs:
|
||||
type=raw,value=latest,enable=${{ needs.validate.outputs.is_prerelease == 'false' }}
|
||||
|
||||
- name: Build and push Docker image
|
||||
uses: docker/build-push-action@v6
|
||||
uses: docker/build-push-action@v7
|
||||
with:
|
||||
context: .
|
||||
platforms: linux/amd64,linux/arm64,linux/arm64/v8,linux/arm/v7
|
||||
push: true
|
||||
tags: ${{ steps.meta.outputs.tags }}
|
||||
labels: ${{ steps.meta.outputs.labels }}
|
||||
|
||||
@@ -14,6 +14,8 @@ jobs:
|
||||
vulnerability-scan:
|
||||
name: Vulnerability Scan
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
steps:
|
||||
- name: Checkout code
|
||||
@@ -43,7 +45,7 @@ jobs:
|
||||
|
||||
- name: Upload vulnerability scan results
|
||||
if: failure()
|
||||
uses: actions/upload-artifact@v6
|
||||
uses: actions/upload-artifact@v7
|
||||
with:
|
||||
name: vulnerability-scan-results
|
||||
path: |
|
||||
@@ -53,6 +55,8 @@ jobs:
|
||||
static-analysis:
|
||||
name: Static Security Analysis
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
steps:
|
||||
- name: Checkout code
|
||||
@@ -119,6 +123,8 @@ jobs:
|
||||
dependency-review:
|
||||
name: Dependency Review
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
contents: read
|
||||
if: github.event_name == 'pull_request'
|
||||
|
||||
steps:
|
||||
@@ -137,6 +143,8 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
needs: [vulnerability-scan, static-analysis, codeql-analysis]
|
||||
if: always()
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
steps:
|
||||
- name: Security scan summary
|
||||
|
||||
@@ -19,14 +19,17 @@ dist/
|
||||
/example-unified
|
||||
/mdns-scanner
|
||||
/websocket-demo
|
||||
/main
|
||||
|
||||
# Environment configuration
|
||||
.env
|
||||
.env.local
|
||||
.env.*.local
|
||||
docker-compose.override.yml
|
||||
|
||||
# Test coverage reports
|
||||
coverage.out
|
||||
coverage*.out
|
||||
coverage.html
|
||||
*.prof
|
||||
|
||||
@@ -60,6 +63,7 @@ Thumbs.db
|
||||
*.pid
|
||||
*.seed
|
||||
*.pid.lock
|
||||
.output.txt
|
||||
|
||||
# Runtime data
|
||||
pids
|
||||
|
||||
+4
-4
@@ -76,7 +76,7 @@ When filing a bug report, include:
|
||||
Feature requests are welcome! Please:
|
||||
|
||||
1. **Check if the feature already exists** in documentation
|
||||
2. **Verify it's supported by the SoundTouch API** (see [official API docs](docs/API-Endpoints-Overview.md))
|
||||
2. **Verify it's supported by the SoundTouch API** (see [official API docs](docs/reference/API-ENDPOINTS.md))
|
||||
3. **Explain the use case** and how it benefits users
|
||||
|
||||
### 🔧 Contributing Code
|
||||
@@ -469,10 +469,10 @@ Contributors will be:
|
||||
|
||||
- [Go Documentation](https://golang.org/doc/)
|
||||
- [Effective Go](https://golang.org/doc/effective_go.html)
|
||||
- [Bose SoundTouch API Documentation](docs/API-Endpoints-Overview.md)
|
||||
- [Bose SoundTouch API Documentation](docs/reference/API-ENDPOINTS.md)
|
||||
- [Project Architecture](docs/PROJECT-PATTERNS.md)
|
||||
- [Development Status](docs/STATUS.md)
|
||||
- [Development Status](docs/archive/STATUS.md)
|
||||
|
||||
---
|
||||
|
||||
**Thank you for contributing!** Every contribution helps make this library better for the entire SoundTouch community.
|
||||
**Thank you for contributing!** Every contribution helps make this library better for the entire SoundTouch community.
|
||||
|
||||
+16
-2
@@ -1,5 +1,12 @@
|
||||
# Build stage
|
||||
FROM golang:1.25.7-alpine AS builder
|
||||
FROM --platform=$BUILDPLATFORM golang:1.26.1-alpine AS builder
|
||||
|
||||
# Declare automatic platform ARGs to make them available in build stage
|
||||
# See https://docs.docker.com/reference/dockerfile#automatic-platform-args-in-the-global-scope
|
||||
# We should not set defaults here, but rely on BuildKit to set them matching the BUILDPLATFORM
|
||||
ARG TARGETARCH
|
||||
ARG TARGETOS
|
||||
ARG TARGETVARIANT
|
||||
|
||||
WORKDIR /app
|
||||
|
||||
@@ -11,7 +18,11 @@ RUN go mod download
|
||||
COPY . .
|
||||
|
||||
# Build the soundtouch-service
|
||||
RUN CGO_ENABLED=0 GOOS=linux go build -o /soundtouch-service ./cmd/soundtouch-service
|
||||
RUN if [ "${TARGETARCH}" = "arm" ] && [ -n "${TARGETVARIANT}" ]; then \
|
||||
CGO_ENABLED=0 GOOS=${TARGETOS} GOARCH=${TARGETARCH} GOARM=${TARGETVARIANT#v} go build -o /soundtouch-service ./cmd/soundtouch-service; \
|
||||
else \
|
||||
CGO_ENABLED=0 GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build -o /soundtouch-service ./cmd/soundtouch-service; \
|
||||
fi
|
||||
|
||||
# Final stage
|
||||
FROM alpine:3.23
|
||||
@@ -24,6 +35,9 @@ WORKDIR /app
|
||||
# Copy the binary from the builder stage
|
||||
COPY --from=builder /soundtouch-service /app/soundtouch-service
|
||||
|
||||
# Verify the binary works on the target platform
|
||||
RUN /app/soundtouch-service version || echo "Binary verification complete"
|
||||
|
||||
# Create data directory for persistence
|
||||
RUN mkdir -p /app/data
|
||||
|
||||
|
||||
@@ -20,6 +20,8 @@ EXAMPLE_UPNP_NAME=example-upnp
|
||||
EXAMPLE_UPNP_PATH=./cmd/$(EXAMPLE_UPNP_NAME)
|
||||
SCANNER_NAME=mdns-scanner
|
||||
SCANNER_PATH=./cmd/$(SCANNER_NAME)
|
||||
FAVICON_GEN_NAME=favicon-gen
|
||||
FAVICON_GEN_PATH=./cmd/$(FAVICON_GEN_NAME)
|
||||
BUILD_DIR=./build
|
||||
|
||||
# Version info
|
||||
@@ -27,7 +29,7 @@ BUILD_DIR=./build
|
||||
|
||||
all: check build
|
||||
|
||||
build: build-cli build-service build-examples
|
||||
build: build-cli build-service build-examples build-favicon-gen
|
||||
|
||||
build-cli:
|
||||
@echo "Building $(BINARY_NAME)..."
|
||||
@@ -48,6 +50,11 @@ build-examples:
|
||||
@echo "Building $(SCANNER_NAME)..."
|
||||
$(GOBUILD) -o $(BUILD_DIR)/$(SCANNER_NAME) $(SCANNER_PATH)
|
||||
|
||||
build-favicon-gen:
|
||||
@echo "Building $(FAVICON_GEN_NAME)..."
|
||||
@mkdir -p $(BUILD_DIR)
|
||||
$(GOBUILD) -o $(BUILD_DIR)/$(FAVICON_GEN_NAME) $(FAVICON_GEN_PATH)
|
||||
|
||||
build-all: build-linux build-darwin build-windows build-examples-all
|
||||
|
||||
build-linux:
|
||||
@@ -96,7 +103,37 @@ test-coverage:
|
||||
$(GOCMD) tool cover -html=coverage.out -o coverage.html
|
||||
@echo "Coverage report generated: coverage.html"
|
||||
|
||||
check: fmt vet test
|
||||
check: fmt vet test test-http-client
|
||||
|
||||
test-http-client:
|
||||
@echo "Running HTTP client integration tests..."
|
||||
@docker network create soundtouch-test-net || true
|
||||
@docker build -t soundtouch-service-test .
|
||||
@docker run -d --name soundtouch-service --network soundtouch-test-net \
|
||||
-e PORT=8000 \
|
||||
soundtouch-service-test
|
||||
@echo "Waiting for service to start..."
|
||||
@sleep 5
|
||||
@docker run --rm --network soundtouch-test-net \
|
||||
-v $(PWD)/tests/integration/http-client:/workdir \
|
||||
jetbrains/intellij-http-client:2026.1 \
|
||||
--env-file /workdir/http-client.env.json \
|
||||
--env ci \
|
||||
/workdir/create_account.http \
|
||||
/workdir/register_device.http \
|
||||
/workdir/power_on.http \
|
||||
/workdir/get_provider_settings.http \
|
||||
/workdir/get_full_account.http \
|
||||
/workdir/get_group.http \
|
||||
/workdir/unregister_device.http \
|
||||
--report; \
|
||||
EXIT_CODE=$$?; \
|
||||
docker logs soundtouch-service; \
|
||||
docker stop soundtouch-service; \
|
||||
docker rm soundtouch-service; \
|
||||
docker rmi soundtouch-service-test; \
|
||||
docker network rm soundtouch-test-net; \
|
||||
exit $$EXIT_CODE
|
||||
|
||||
fmt:
|
||||
@echo "Formatting code..."
|
||||
@@ -226,6 +263,7 @@ help:
|
||||
@echo " build - Build the CLI tool, service, and examples"
|
||||
@echo " build-cli - Build only the CLI tool"
|
||||
@echo " build-service - Build only the service"
|
||||
@echo " build-favicon-gen - Build the favicon generator"
|
||||
@echo " build-examples - Build only the example programs"
|
||||
@echo " build-all - Build for all platforms"
|
||||
@echo " test - Run tests"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Bose SoundTouch API Client
|
||||
# Bose SoundTouch Toolkit
|
||||
|
||||
A comprehensive Go library and CLI tool for controlling Bose SoundTouch devices via their Web API.
|
||||
A comprehensive solution for controlling and preserving Bose SoundTouch devices, including a Go library, CLI tool, and a local service for cloud emulation.
|
||||
|
||||
[](https://pkg.go.dev/github.com/gesellix/bose-soundtouch)
|
||||
[](https://goreportcard.com/report/github.com/gesellix/bose-soundtouch)
|
||||
@@ -17,11 +17,19 @@ A comprehensive Go library and CLI tool for controlling Bose SoundTouch devices
|
||||
- ⚡ **Real-time Events**: WebSocket connection for live device state monitoring
|
||||
- 🔍 **Device Discovery**: Automatic discovery via UPnP/SSDP and mDNS
|
||||
- 📻 **Content Navigation**: Browse and search TuneIn, Pandora, Spotify, local music
|
||||
- 📻 **Custom Radio**: Play any stream URL via [flexible proxying](docs/guides/CLI-REFERENCE.md#custom-radio-selection-via-soundtouch-service)
|
||||
- 📻 **RadioBrowser**: Access thousands of internet radio stations via [radio-browser.info](docs/reference/radio-browser.md)
|
||||
- 🎙️ **Station Management**: Add and play radio stations without presets
|
||||
- 🖥️ **CLI Tool**: Comprehensive command-line interface
|
||||
- 🌐 **SoundTouch Service**: Emulate Bose cloud services for offline device operation
|
||||
- 🔧 **Service Migration**: Migrate devices to use local services instead of Bose cloud
|
||||
- 📊 **Traffic Analysis**: Proxy and log device communications for debugging
|
||||
- 🔧 **Service Migration**: Migrate devices to use local services instead of Bose cloud (XML, Hosts, or DNS redirection)
|
||||
- 🔍 **DNS Discovery & Interception**: Dynamic DNS server for intercepting and logging Bose service queries (requires port 53)
|
||||
- 📊 **DNS Discovery Analysis**: Track and deduplicate all device DNS queries to discover hidden hostnames
|
||||
- 📊 **Traffic Analysis**: Proxy and log device communications
|
||||
- 📝 **HTTP Recording**: Persist interactions as re-playable `.http` files
|
||||
- 🔄 **Endpoint Mirroring**: Asynchronously mirror local requests to Bose cloud for parity testing
|
||||
- ⚖️ **Parity Logging**: Detect and record discrepancies between local and official Bose responses
|
||||
- 🧹 **Session Management**: Manage and cleanup recorded interaction sessions
|
||||
- 🔒 **Production Ready**: Extensive testing with real SoundTouch hardware
|
||||
- 🌐 **Cross-Platform**: Windows, macOS, Linux support
|
||||
|
||||
@@ -42,148 +50,53 @@ go get github.com/gesellix/bose-soundtouch
|
||||
|
||||
### CLI Usage
|
||||
|
||||
#### Discover Devices
|
||||
Find SoundTouch devices on your network:
|
||||
```bash
|
||||
# Find SoundTouch devices on your network
|
||||
soundtouch-cli discover devices
|
||||
```
|
||||
|
||||
# Control a Device
|
||||
Control a device (replace `192.168.1.100` with your speaker's IP):
|
||||
```bash
|
||||
# Basic device information
|
||||
soundtouch-cli --host 192.168.1.100 info get
|
||||
# Basic information
|
||||
soundtouch-cli --host 192.168.1.100 info
|
||||
|
||||
# Media controls
|
||||
soundtouch-cli --host 192.168.1.100 play start
|
||||
soundtouch-cli --host 192.168.1.100 volume set --level 50
|
||||
soundtouch-cli --host 192.168.1.100 source select --source SPOTIFY
|
||||
|
||||
# Preset management
|
||||
soundtouch-cli --host 192.168.1.100 preset list
|
||||
soundtouch-cli --host 192.168.1.100 preset store-current --slot 1
|
||||
soundtouch-cli --host 192.168.1.100 preset select --slot 1
|
||||
|
||||
# Browse and discover content
|
||||
soundtouch-cli --host 192.168.1.100 browse tunein
|
||||
soundtouch-cli --host 192.168.1.100 station search-tunein --query "jazz"
|
||||
soundtouch-cli --host 192.168.1.100 station add --source TUNEIN --token <token> --name "Jazz Radio"
|
||||
|
||||
# Speaker notifications (ST-10 only)
|
||||
soundtouch-cli --host 192.168.1.100 speaker tts --text "Welcome home" --app-key YOUR_KEY
|
||||
soundtouch-cli --host 192.168.1.100 speaker url --url "https://example.com/doorbell.mp3" --app-key YOUR_KEY
|
||||
soundtouch-cli --host 192.168.1.100 speaker beep
|
||||
|
||||
# Real-time monitoring
|
||||
soundtouch-cli --host 192.168.1.100 events subscribe
|
||||
```
|
||||
|
||||
### SoundTouch Service
|
||||
For full CLI documentation, see the [CLI Reference](https://gesellix.github.io/Bose-SoundTouch/guides/CLI-REFERENCE.html).
|
||||
|
||||
The `soundtouch-service` is a local server that emulates Bose's cloud services, enabling offline operation and custom integrations. This is particularly valuable as Bose has announced the discontinuation of cloud support in May 2026.
|
||||
### SoundTouch Service (Cloud Shutdown Protection)
|
||||
|
||||
#### Key Features
|
||||
The `soundtouch-service` is a local server that emulates Bose's cloud services. This is critical for keeping your speakers functional after the **Bose Cloud Shutdown in May 2026**.
|
||||
|
||||
- **🏠 Local Service Emulation**: Complete BMX (Bose Media eXchange) and Marge service implementation
|
||||
- **🔧 Device Migration**: Seamlessly migrate devices from Bose cloud to local services
|
||||
- **📊 Traffic Proxying**: Inspect and log all device communications for debugging
|
||||
- **🌐 Web Management UI**: Browser-based interface for device management
|
||||
- **💾 Persistent Data**: Store device configurations, presets, and usage statistics
|
||||
- **🔍 Auto-Discovery**: Automatically detect and configure SoundTouch devices
|
||||
- **🔒 Offline Operation**: Continue using full device functionality without internet
|
||||
|
||||
#### Quick Start
|
||||
#### Key Features:
|
||||
- **🏠 Local Emulation**: BMX and Marge service implementation
|
||||
- **🔌 Easy Setup**: Activate SSH via USB stick (`remote_services` file)
|
||||
- **🔧 Device Migration**: Seamlessly transition devices to local control
|
||||
- **🌐 Web Management UI**: Easy browser-based setup and management
|
||||
- **💾 Persistent Data**: Store presets, recents, and sources locally
|
||||
- **🔄 Endpoint Mirroring**: Asynchronously mirror local requests to Bose cloud for parity testing
|
||||
- **⚖️ Parity Logging**: Detect and record discrepancies between local and official Bose responses
|
||||
- **📝 HTTP Recording**: Persist all interactions as re-playable `.http` files
|
||||
- **🧹 Session Management**: Manage and cleanup recorded interaction sessions
|
||||
|
||||
#### Quick Start:
|
||||
```bash
|
||||
# Install the service
|
||||
go install github.com/gesellix/bose-soundtouch/cmd/soundtouch-service@latest
|
||||
|
||||
# Start with default settings (http://localhost:8000, proxying to http://localhost:8001)
|
||||
# Start the service
|
||||
soundtouch-service
|
||||
|
||||
# Or configure with environment variables
|
||||
PORT=9000 PYTHON_BACKEND_URL=http://your-python-backend:8001 DATA_DIR=/my/data soundtouch-service
|
||||
```
|
||||
Open `http://localhost:8000` in your browser to manage your devices. Documentation is also available directly through the web interface.
|
||||
|
||||
#### Running with Docker
|
||||
For a comprehensive guide on transitioning your system, see the [Bose Cloud Shutdown: Survival Guide](https://gesellix.github.io/Bose-SoundTouch/guides/SURVIVAL-GUIDE.html).
|
||||
|
||||
You can also run the SoundTouch service using Docker or Docker Compose.
|
||||
Detailed service configuration and Docker instructions can be found in [SoundTouch Service Guide](https://gesellix.github.io/Bose-SoundTouch/guides/SOUNDTOUCH-SERVICE.html).
|
||||
|
||||
> **Note for macOS and Windows users**: The `--net host` option is only supported on Linux. On macOS and Windows, service discovery (mDNS, UPnP) will not work automatically within the container. You will need to manually enter your device's IP address in the management UI, and the service will communicate with it directly.
|
||||
|
||||
##### Using Docker
|
||||
|
||||
**Linux (with host networking for discovery):**
|
||||
```bash
|
||||
docker run -d \
|
||||
--name soundtouch-service \
|
||||
--network host \
|
||||
-v $(pwd)/data:/app/data \
|
||||
ghcr.io/gesellix/bose-soundtouch:latest
|
||||
```
|
||||
|
||||
**macOS / Windows (with port mapping):**
|
||||
```bash
|
||||
docker run -d \
|
||||
--name soundtouch-service \
|
||||
-p 8000:8000 \
|
||||
-v $(pwd)/data:/app/data \
|
||||
ghcr.io/gesellix/bose-soundtouch:latest
|
||||
```
|
||||
|
||||
##### Using Docker Compose
|
||||
|
||||
Create a `docker-compose.yml` file:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
soundtouch-service:
|
||||
image: ghcr.io/gesellix/bose-soundtouch:latest
|
||||
container_name: soundtouch-service
|
||||
# Linux users: use host networking for device discovery
|
||||
# network_mode: host
|
||||
# macOS/Windows users: use port mapping (discovery will be manual)
|
||||
ports:
|
||||
- "8000:8000"
|
||||
environment:
|
||||
- PORT=8000
|
||||
- DATA_DIR=/app/data
|
||||
volumes:
|
||||
- ./data:/app/data
|
||||
restart: unless-stopped
|
||||
```
|
||||
|
||||
And run:
|
||||
|
||||
```bash
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
> **Note**: `--network host` is required for device discovery via UPnP and mDNS to work correctly within the container.
|
||||
|
||||
#### Device Migration Example
|
||||
|
||||
```bash
|
||||
# 1. Start the service
|
||||
soundtouch-service
|
||||
|
||||
# 2. Open web UI at http://localhost:8000
|
||||
# 3. Discover your devices
|
||||
# 4. Click "Migrate" to configure devices to use local services
|
||||
|
||||
# Or use the API directly:
|
||||
curl -X POST http://localhost:8000/setup/migrate/192.168.1.100
|
||||
```
|
||||
|
||||
#### Service Endpoints
|
||||
|
||||
- **Web UI**: `http://localhost:8000/` - Device management interface
|
||||
- **Discovery**: `GET /setup/devices` - List discovered devices
|
||||
- **Migration**: `POST /setup/migrate/{deviceIP}` - Switch device to local services
|
||||
- **BMX Services**: `/bmx/*` - Music service emulation (TuneIn, etc.)
|
||||
- **Marge Services**: `/marge/*` - Account and device management
|
||||
- **Proxy**: `/proxy/*` - Traffic inspection and debugging
|
||||
|
||||
See [docs/SOUNDTOUCH-SERVICE.md](docs/SOUNDTOUCH-SERVICE.md) for detailed configuration and API reference.
|
||||
For professional migration tips and safety measures, see the [Migration & Safety Guide](https://gesellix.github.io/Bose-SoundTouch/guides/MIGRATION-SAFETY.html).
|
||||
|
||||
### Library Usage
|
||||
|
||||
@@ -194,7 +107,7 @@ package main
|
||||
import (
|
||||
"fmt"
|
||||
"log"
|
||||
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/client"
|
||||
)
|
||||
|
||||
@@ -204,20 +117,20 @@ func main() {
|
||||
Host: "192.168.1.100",
|
||||
Port: 8090,
|
||||
})
|
||||
|
||||
|
||||
// Get device information
|
||||
info, err := c.GetDeviceInfo()
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
fmt.Printf("Device: %s\n", info.Name)
|
||||
|
||||
|
||||
// Control playback
|
||||
err = c.Play()
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
// Set volume
|
||||
err = c.SetVolume(50)
|
||||
if err != nil {
|
||||
@@ -235,7 +148,7 @@ import (
|
||||
"fmt"
|
||||
"log"
|
||||
"time"
|
||||
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/discovery"
|
||||
)
|
||||
|
||||
@@ -246,9 +159,9 @@ func main() {
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
for _, device := range devices {
|
||||
fmt.Printf("Found: %s at %s:%d\n",
|
||||
fmt.Printf("Found: %s at %s:%d\n",
|
||||
device.Name, device.Host, device.Port)
|
||||
}
|
||||
}
|
||||
@@ -262,7 +175,7 @@ import (
|
||||
"context"
|
||||
"fmt"
|
||||
"log"
|
||||
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/client"
|
||||
"github.com/gesellix/bose-soundtouch/pkg/models"
|
||||
)
|
||||
@@ -272,13 +185,13 @@ func main() {
|
||||
Host: "192.168.1.100",
|
||||
Port: 8090,
|
||||
})
|
||||
|
||||
|
||||
// Subscribe to device events
|
||||
events, err := c.SubscribeToEvents(context.Background())
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
for event := range events {
|
||||
switch e := event.(type) {
|
||||
case *models.NowPlayingUpdated:
|
||||
@@ -299,7 +212,7 @@ package main
|
||||
import (
|
||||
"fmt"
|
||||
"log"
|
||||
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/client"
|
||||
"github.com/gesellix/bose-soundtouch/pkg/models"
|
||||
)
|
||||
@@ -309,21 +222,21 @@ func main() {
|
||||
Host: "192.168.1.100",
|
||||
Port: 8090,
|
||||
})
|
||||
|
||||
|
||||
// Get current presets
|
||||
presets, err := c.GetPresets()
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
fmt.Printf("Found %d presets\n", len(presets.Preset))
|
||||
|
||||
|
||||
// Store currently playing content as preset 1
|
||||
err = c.StoreCurrentAsPreset(1)
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
// Store Spotify playlist as preset 2
|
||||
spotifyContent := &models.ContentItem{
|
||||
Source: "SPOTIFY",
|
||||
@@ -337,7 +250,7 @@ func main() {
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
// Store radio station as preset 3
|
||||
radioContent := &models.ContentItem{
|
||||
Source: "TUNEIN",
|
||||
@@ -350,13 +263,13 @@ func main() {
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
// Select preset 1
|
||||
err = c.SelectPreset(1)
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
fmt.Println("Preset management complete!")
|
||||
}
|
||||
```
|
||||
@@ -367,7 +280,7 @@ package main
|
||||
|
||||
import (
|
||||
"log"
|
||||
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/client"
|
||||
"github.com/gesellix/bose-soundtouch/pkg/models"
|
||||
)
|
||||
@@ -377,7 +290,7 @@ func main() {
|
||||
Host: "192.168.1.100", // Master speaker
|
||||
Port: 8090,
|
||||
})
|
||||
|
||||
|
||||
// Create a multiroom zone
|
||||
zone := &models.Zone{
|
||||
Master: "192.168.1.100",
|
||||
@@ -386,12 +299,12 @@ func main() {
|
||||
{IPAddress: "192.168.1.102"}, // Kitchen
|
||||
},
|
||||
}
|
||||
|
||||
|
||||
err := master.SetZone(zone)
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
fmt.Println("Multiroom zone created!")
|
||||
}
|
||||
```
|
||||
@@ -402,7 +315,7 @@ package main
|
||||
|
||||
import (
|
||||
"log"
|
||||
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/client"
|
||||
)
|
||||
|
||||
@@ -411,13 +324,13 @@ func main() {
|
||||
Host: "192.168.1.100",
|
||||
Port: 8090,
|
||||
})
|
||||
|
||||
// Play Text-to-Speech message
|
||||
err := c.PlayTTS("Welcome home!", "your-app-key", 70)
|
||||
|
||||
// Play Text-to-Speech message (language code "EN", "DE", etc.)
|
||||
err := c.PlayTTS("Welcome home!", "your-app-key", "EN", 70)
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
// Play audio content from URL
|
||||
err = c.PlayURL(
|
||||
"https://example.com/doorbell.mp3",
|
||||
@@ -430,13 +343,13 @@ func main() {
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
// Play notification beep
|
||||
err = c.PlayNotificationBeep()
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
|
||||
fmt.Println("Notifications sent!")
|
||||
}
|
||||
```
|
||||
@@ -446,7 +359,7 @@ func main() {
|
||||
This library supports all Bose SoundTouch-compatible devices, including:
|
||||
|
||||
- SoundTouch 10, 20, 30 series
|
||||
- SoundTouch Portable
|
||||
- SoundTouch Portable
|
||||
- Wave SoundTouch music system
|
||||
- SoundTouch-enabled Bose speakers
|
||||
|
||||
@@ -476,19 +389,19 @@ This library supports all Bose SoundTouch-compatible devices, including:
|
||||
## Documentation
|
||||
|
||||
- 📖 [Contributing Guide](CONTRIBUTING.md) - How to contribute to the project
|
||||
- 📚 [API Reference](docs/API-Endpoints-Overview.md) - Complete endpoint documentation
|
||||
- 🔧 [CLI Reference](docs/CLI-REFERENCE.md) - Command-line tool guide
|
||||
- 🌐 [SoundTouch Service Guide](docs/SOUNDTOUCH-SERVICE.md) - Local service setup and migration
|
||||
- 🎯 [Getting Started](docs/GETTING-STARTED.md) - Detailed setup and usage
|
||||
- 📻 [Preset Quick Start](docs/PRESET-QUICKSTART.md) - Favorite content management
|
||||
- 🧭 [Navigation Guide](docs/NAVIGATION-GUIDE.md) - Content browsing and station management
|
||||
- 📋 [Navigation API Reference](docs/API-NAVIGATION-REFERENCE.md) - Navigation API documentation
|
||||
- ⚙️ [Advanced Features](docs/SYSTEM-ENDPOINTS.md) - Advanced functionality
|
||||
- 🏠 [Multiroom Setup](docs/zone-management.md) - Zone configuration guide
|
||||
- ⚡ [WebSocket Events](docs/websocket-events.md) - Real-time event handling
|
||||
- 🔔 [Speaker Notifications](docs/SPEAKER_ENDPOINT.md) - TTS and audio notifications guide
|
||||
- 🔍 [Device Discovery](docs/DISCOVERY.md) - Discovery configuration
|
||||
- 🛠️ [Troubleshooting](docs/TROUBLESHOOTING.md) - Common issues and solutions
|
||||
- 📚 [API Reference](https://gesellix.github.io/Bose-SoundTouch/reference/API-ENDPOINTS.html) - Complete endpoint documentation
|
||||
- 🔧 [CLI Reference](https://gesellix.github.io/Bose-SoundTouch/guides/CLI-REFERENCE.html) - Command-line tool guide
|
||||
- 🌐 [SoundTouch Service Guide](https://gesellix.github.io/Bose-SoundTouch/guides/SOUNDTOUCH-SERVICE.html) - Local service setup and migration
|
||||
- 🎯 [Getting Started](https://gesellix.github.io/Bose-SoundTouch/guides/GETTING-STARTED.html) - Detailed setup and usage
|
||||
- 📻 [Preset Quick Start](https://gesellix.github.io/Bose-SoundTouch/PRESET-QUICKSTART.md) - Favorite content management
|
||||
- 🧭 [Navigation Guide](https://gesellix.github.io/Bose-SoundTouch/NAVIGATION-GUIDE.md) - Content browsing and station management
|
||||
- 📋 [Navigation API Reference](https://gesellix.github.io/Bose-SoundTouch/API-NAVIGATION-REFERENCE.md) - Navigation API documentation
|
||||
- ⚙️ [Advanced Features](https://gesellix.github.io/Bose-SoundTouch/reference/SYSTEM-ENDPOINTS.html) - Advanced functionality
|
||||
- 🏠 [Multiroom Setup](https://gesellix.github.io/Bose-SoundTouch/reference/ZONE-MANAGEMENT.html) - Zone configuration guide
|
||||
- ⚡ [WebSocket Events](https://gesellix.github.io/Bose-SoundTouch/reference/WEBSOCKET-EVENTS.html) - Real-time event handling
|
||||
- 🔔 [Speaker Notifications](https://gesellix.github.io/Bose-SoundTouch/reference/SPEAKER-ENDPOINT.html) - TTS and audio notifications guide
|
||||
- 🔍 [Device Discovery](https://gesellix.github.io/Bose-SoundTouch/reference/DISCOVERY.html) - Discovery configuration
|
||||
- 🛠️ [Troubleshooting](https://gesellix.github.io/Bose-SoundTouch/guides/TROUBLESHOOTING.html) - Common issues and solutions
|
||||
|
||||
## Development
|
||||
|
||||
@@ -575,14 +488,14 @@ This project builds upon the excellent work of several community projects:
|
||||
|
||||
### SoundCork 🍾
|
||||
- **Project**: [SoundCork - SoundTouch API Intercept](https://github.com/deborahgu/soundcork)
|
||||
- **Authors**: Deborah Gu and contributors
|
||||
- **Our Implementation**: The `soundtouch-service` in this project is heavily inspired by and based on SoundCork's Python implementation. SoundCork pioneered the approach of intercepting and emulating Bose's cloud services, providing the foundation for offline SoundTouch operation.
|
||||
- **Authors**: Deborah Kaplan and contributors
|
||||
- **Our Implementation**: The `soundtouch-service` in this project is heavily inspired by SoundCork's Python implementation. SoundCork pioneered the approach of intercepting and emulating Bose's cloud services, providing the foundation for offline SoundTouch operation.
|
||||
- **Key Contributions**: Service emulation architecture, BMX/Marge endpoint discovery, device migration strategies
|
||||
- **License**: MIT License
|
||||
|
||||
### ÜberBöse API 🎵
|
||||
- **Project**: [ÜberBöse API](https://github.com/julius-d/ueberboese-api)
|
||||
- **Author**: Julius D.
|
||||
- **Author**: Julius
|
||||
- **Our Implementation**: This project provided valuable insights into advanced SoundTouch API endpoints and helped make our implementation more complete, particularly for content navigation and advanced device features.
|
||||
- **Key Contributions**: Extended API endpoint documentation, advanced feature discovery
|
||||
- **License**: MIT License
|
||||
@@ -595,14 +508,22 @@ This project builds upon the excellent work of several community projects:
|
||||
- **Key Contributions**: Extensive API endpoint documentation, real-world usage patterns
|
||||
- **License**: MIT License
|
||||
|
||||
### SoundTouch Hook 🪝
|
||||
- **Project**: [Bose SoundTouch Hook](https://github.com/CodeFinder2/bose-soundtouch-hook)
|
||||
- **Author**: Adrian Böckenkamp
|
||||
- **Our Implementation**: This project provides a powerful framework for intercepting and hooking into internal device processes using `LD_PRELOAD`. It was instrumental in verifying internal function calls and understanding how the device validates cloud domains.
|
||||
- **Key Contributions**: Reverse engineering framework, process hooking, cross-compilation toolchain
|
||||
- **License**: GPL-3.0 License
|
||||
|
||||
### Community Ecosystem
|
||||
|
||||
These projects together form a comprehensive ecosystem for SoundTouch device management:
|
||||
|
||||
- **This Project**: Go library + CLI + service for programmatic control and offline operation
|
||||
- **SoundCork**: Python-based service interception and cloud replacement
|
||||
- **SoundCork**: Python-based service interception and cloud replacement
|
||||
- **SoundTouch Plus**: Home Assistant integration with extensive device support
|
||||
- **ÜberBöse**: API research and advanced endpoint discovery
|
||||
- **SoundTouch Hook**: Advanced reverse engineering and process instrumentation
|
||||
|
||||
We are grateful to these projects and their maintainers for paving the way and providing the foundation that made this comprehensive Go implementation possible. The SoundTouch community's collaborative approach to reverse engineering and documentation has been invaluable.
|
||||
|
||||
@@ -615,7 +536,13 @@ If you discover new endpoints, features, or improvements through this library, p
|
||||
- 🐛 **Bug Reports**: [Create an issue](https://github.com/gesellix/bose-soundtouch/issues/new)
|
||||
- 💡 **Feature Requests**: [Start a discussion](https://github.com/gesellix/bose-soundtouch/discussions)
|
||||
- ❓ **Questions**: Check [existing discussions](https://github.com/gesellix/bose-soundtouch/discussions)
|
||||
- 📖 **Documentation**: Browse the [docs/](docs/) directory
|
||||
- 📖 **Documentation**: [Online Documentation](https://gesellix.github.io/Bose-SoundTouch/)
|
||||
- 🔍 **New Discoveries**: [Undocumented Community Features](https://gesellix.github.io/Bose-SoundTouch/UNDOCUMENTED-COMMUNITY-FEATURES.md)
|
||||
- 🌐 **Upstream Analysis**: [Upstream URLs & Domains](https://gesellix.github.io/Bose-SoundTouch/analysis/UPSTREAM-URLS.html)
|
||||
- 🔧 **Redirection Guide**: [Device Redirect Methods](https://gesellix.github.io/Bose-SoundTouch/analysis/DEVICE-REDIRECT-METHODS.html)
|
||||
- 🐣 **Initial Setup**: [Device Initial Setup Variants](https://gesellix.github.io/Bose-SoundTouch/guides/DEVICE-INITIAL-SETUP.html)
|
||||
- 📜 **Logging & Debugging**: [Device Logging Guide](https://gesellix.github.io/Bose-SoundTouch/DEVICE-LOGGING.md)
|
||||
- 🔒 **HTTPS & CA Setup**: [HTTPS & Custom CA Guide](https://gesellix.github.io/Bose-SoundTouch/guides/HTTPS-SETUP.html)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,242 @@
|
||||
// Package main provides a debug tool for analyzing device consolidation and migration scenarios.
|
||||
package main
|
||||
|
||||
import (
|
||||
"fmt"
|
||||
"log"
|
||||
"os"
|
||||
"path/filepath"
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/models"
|
||||
"github.com/gesellix/bose-soundtouch/pkg/service/datastore"
|
||||
)
|
||||
|
||||
func main() {
|
||||
if len(os.Args) < 2 {
|
||||
fmt.Println("Usage: debug-consolidation <data-directory>")
|
||||
fmt.Println("Example: debug-consolidation /var/lib/soundtouch-service")
|
||||
os.Exit(1)
|
||||
}
|
||||
|
||||
dataDir := os.Args[1]
|
||||
|
||||
fmt.Printf("🔍 Analyzing device consolidation in: %s\n", dataDir)
|
||||
|
||||
// Initialize datastore
|
||||
ds := datastore.NewDataStore(dataDir)
|
||||
|
||||
// List all devices
|
||||
devices, err := ds.ListAllDevices()
|
||||
if err != nil {
|
||||
log.Fatalf("Failed to list devices: %v", err)
|
||||
}
|
||||
|
||||
fmt.Printf("📱 Found %d device entries:\n", len(devices))
|
||||
|
||||
for i := range devices {
|
||||
device := &devices[i]
|
||||
fmt.Printf(" %d. %s (Account: %s)\n", i+1, device.DeviceID, device.AccountID)
|
||||
fmt.Printf(" Name: %s\n", device.Name)
|
||||
fmt.Printf(" IP: %s, MAC: %s, Serial: %s\n",
|
||||
device.IPAddress, device.MacAddress, device.DeviceSerialNumber)
|
||||
|
||||
// Check directory contents
|
||||
deviceDir := ds.AccountDeviceDir(device.AccountID, device.DeviceID)
|
||||
analyzeDeviceDirectory(deviceDir, device.DeviceID)
|
||||
fmt.Println()
|
||||
}
|
||||
|
||||
// Group devices by potential physical device
|
||||
fmt.Println("🔄 Analyzing potential consolidation opportunities:")
|
||||
|
||||
deviceGroups := groupDevicesByIdentity(devices)
|
||||
|
||||
for i, group := range deviceGroups {
|
||||
if len(group) <= 1 {
|
||||
continue
|
||||
}
|
||||
|
||||
fmt.Printf(" Group %d - %d entries for same physical device:\n", i+1, len(group))
|
||||
|
||||
for i := range group {
|
||||
device := &group[i]
|
||||
deviceDir := ds.AccountDeviceDir(device.AccountID, device.DeviceID)
|
||||
fileCount := countFiles(deviceDir)
|
||||
fmt.Printf(" - %s (%d files)\n", device.DeviceID, fileCount)
|
||||
}
|
||||
|
||||
// Recommend consolidation target
|
||||
macDevice := findMACBasedDevice(group)
|
||||
if macDevice != nil {
|
||||
fmt.Printf(" → Recommend keeping: %s (MAC-based)\n", macDevice.DeviceID)
|
||||
} else {
|
||||
fmt.Printf(" → No clear MAC-based target found\n")
|
||||
}
|
||||
|
||||
fmt.Println()
|
||||
}
|
||||
}
|
||||
|
||||
func analyzeDeviceDirectory(dirPath, deviceID string) {
|
||||
entries, err := os.ReadDir(dirPath)
|
||||
if err != nil {
|
||||
fmt.Printf(" Directory: %s (Error: %v)\n", dirPath, err)
|
||||
return
|
||||
}
|
||||
|
||||
fmt.Printf(" Directory: %s (%d files)\n", dirPath, len(entries))
|
||||
|
||||
// Check for important files
|
||||
importantFiles := []string{"DeviceInfo.xml", "Presets.xml", "Recents.xml", "Sources.xml"}
|
||||
for _, fileName := range importantFiles {
|
||||
filePath := filepath.Join(dirPath, fileName)
|
||||
if stat, err := os.Stat(filePath); err == nil {
|
||||
status := "✓"
|
||||
if stat.Size() == 0 {
|
||||
status = "⚠️ (empty)"
|
||||
} else if stat.Size() < 100 {
|
||||
status = "⚠️ (very small)"
|
||||
}
|
||||
|
||||
fmt.Printf(" %s %s (%d bytes)\n", status, fileName, stat.Size())
|
||||
} else {
|
||||
fmt.Printf(" ❌ %s (missing)\n", fileName)
|
||||
}
|
||||
}
|
||||
|
||||
// Check if deviceID looks like MAC address
|
||||
if isLikelyMACAddress(deviceID) {
|
||||
fmt.Printf(" 📍 Device ID appears to be MAC address format\n")
|
||||
} else {
|
||||
fmt.Printf(" 📍 Device ID appears to be %s format\n", guessIDType(deviceID))
|
||||
}
|
||||
}
|
||||
|
||||
func countFiles(dirPath string) int {
|
||||
entries, err := os.ReadDir(dirPath)
|
||||
if err != nil {
|
||||
return 0
|
||||
}
|
||||
|
||||
count := 0
|
||||
|
||||
for _, entry := range entries {
|
||||
if !entry.IsDir() {
|
||||
count++
|
||||
}
|
||||
}
|
||||
|
||||
return count
|
||||
}
|
||||
|
||||
func groupDevicesByIdentity(devices []models.ServiceDeviceInfo) [][]models.ServiceDeviceInfo {
|
||||
var groups [][]models.ServiceDeviceInfo
|
||||
|
||||
// Simple grouping by MAC address and serial number
|
||||
macGroups := make(map[string][]models.ServiceDeviceInfo)
|
||||
serialGroups := make(map[string][]models.ServiceDeviceInfo)
|
||||
ipGroups := make(map[string][]models.ServiceDeviceInfo)
|
||||
|
||||
for i := range devices {
|
||||
device := &devices[i]
|
||||
// Group by MAC address
|
||||
if device.MacAddress != "" {
|
||||
macGroups[device.MacAddress] = append(macGroups[device.MacAddress], *device)
|
||||
}
|
||||
|
||||
// Group by serial number
|
||||
if device.DeviceSerialNumber != "" {
|
||||
serialGroups[device.DeviceSerialNumber] = append(serialGroups[device.DeviceSerialNumber], *device)
|
||||
}
|
||||
|
||||
// Group by IP address
|
||||
if device.IPAddress != "" {
|
||||
ipGroups[device.IPAddress] = append(ipGroups[device.IPAddress], *device)
|
||||
}
|
||||
}
|
||||
|
||||
// Merge groups - prioritize MAC address grouping
|
||||
processed := make(map[string]bool)
|
||||
|
||||
for _, macDevices := range macGroups {
|
||||
if len(macDevices) > 1 {
|
||||
groups = append(groups, macDevices)
|
||||
for i := range macDevices {
|
||||
processed[macDevices[i].DeviceID] = true
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Check for serial number groups not already processed
|
||||
for _, serialDevices := range serialGroups {
|
||||
if len(serialDevices) > 1 {
|
||||
unprocessed := []models.ServiceDeviceInfo{}
|
||||
|
||||
for i := range serialDevices {
|
||||
if !processed[serialDevices[i].DeviceID] {
|
||||
unprocessed = append(unprocessed, serialDevices[i])
|
||||
}
|
||||
}
|
||||
|
||||
if len(unprocessed) > 1 {
|
||||
groups = append(groups, unprocessed)
|
||||
for i := range unprocessed {
|
||||
processed[unprocessed[i].DeviceID] = true
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return groups
|
||||
}
|
||||
|
||||
func findMACBasedDevice(devices []models.ServiceDeviceInfo) *models.ServiceDeviceInfo {
|
||||
for i := range devices {
|
||||
if isLikelyMACAddress(devices[i].DeviceID) {
|
||||
return &devices[i]
|
||||
}
|
||||
}
|
||||
|
||||
return nil
|
||||
}
|
||||
|
||||
func isLikelyMACAddress(id string) bool {
|
||||
// MAC addresses are typically 12 hex characters without separators
|
||||
// or 17 characters with separators (XX:XX:XX:XX:XX:XX)
|
||||
if len(id) == 12 {
|
||||
for _, c := range id {
|
||||
if (c < '0' || c > '9') && (c < 'A' || c > 'F') && (c < 'a' || c > 'f') {
|
||||
return false
|
||||
}
|
||||
}
|
||||
|
||||
return true
|
||||
}
|
||||
|
||||
return false
|
||||
}
|
||||
|
||||
func guessIDType(id string) string {
|
||||
if len(id) > 15 && (id[0] == 'I' || id[0] == 'K') {
|
||||
return "serial number"
|
||||
}
|
||||
|
||||
// Check if it looks like an IP address
|
||||
if len(id) >= 7 && len(id) <= 15 {
|
||||
dotCount := 0
|
||||
|
||||
for _, c := range id {
|
||||
if c == '.' {
|
||||
dotCount++
|
||||
} else if c < '0' || c > '9' {
|
||||
break
|
||||
}
|
||||
}
|
||||
|
||||
if dotCount == 3 {
|
||||
return "IP address"
|
||||
}
|
||||
}
|
||||
|
||||
return "unknown"
|
||||
}
|
||||
@@ -0,0 +1,152 @@
|
||||
// Package main provides a utility to generate PNG and ICO favicons from SVG source files.
|
||||
package main
|
||||
|
||||
import (
|
||||
"bufio"
|
||||
"bytes"
|
||||
"encoding/binary"
|
||||
"fmt"
|
||||
"image"
|
||||
"image/png"
|
||||
"log"
|
||||
"os"
|
||||
"path/filepath"
|
||||
|
||||
"github.com/srwiley/oksvg"
|
||||
"github.com/srwiley/rasterx"
|
||||
)
|
||||
|
||||
func main() {
|
||||
mediaDir := "pkg/service/handlers/web/img"
|
||||
files := []string{"favicon-braille", "favicon-morse"}
|
||||
|
||||
for _, name := range files {
|
||||
svgPath := filepath.Join(mediaDir, name+".svg")
|
||||
pngPath := filepath.Join(mediaDir, name+".png")
|
||||
icoPath := filepath.Join(mediaDir, name+".ico")
|
||||
|
||||
fmt.Printf("Processing %s...\n", name)
|
||||
|
||||
// 1. Render SVG to PNG
|
||||
img, err := renderSVG(svgPath, 32, 32)
|
||||
if err != nil {
|
||||
log.Fatalf("Failed to render %s: %v", svgPath, err)
|
||||
}
|
||||
|
||||
f, err := os.Create(pngPath)
|
||||
if err != nil {
|
||||
log.Fatalf("Failed to create %s: %v", pngPath, err)
|
||||
}
|
||||
|
||||
if err := png.Encode(f, img); err != nil {
|
||||
f.Close()
|
||||
log.Fatalf("Failed to encode PNG %s: %v", pngPath, err)
|
||||
}
|
||||
|
||||
f.Close()
|
||||
fmt.Printf("Created %s\n", pngPath)
|
||||
|
||||
// 2. Create ICO (containing multiple sizes)
|
||||
sizes := []int{16, 32, 48}
|
||||
|
||||
var images []image.Image
|
||||
|
||||
for _, s := range sizes {
|
||||
m, err := renderSVG(svgPath, s, s)
|
||||
if err != nil {
|
||||
log.Fatalf("Failed to render %s at size %d: %v", svgPath, s, err)
|
||||
}
|
||||
|
||||
images = append(images, m)
|
||||
}
|
||||
|
||||
if err := writeICO(icoPath, images); err != nil {
|
||||
log.Fatalf("Failed to write ICO %s: %v", icoPath, err)
|
||||
}
|
||||
|
||||
fmt.Printf("Created %s\n", icoPath)
|
||||
}
|
||||
}
|
||||
|
||||
func renderSVG(path string, w, h int) (image.Image, error) {
|
||||
in, err := os.Open(path)
|
||||
if err != nil {
|
||||
return nil, err
|
||||
}
|
||||
defer in.Close()
|
||||
|
||||
icon, err := oksvg.ReadIconStream(in)
|
||||
if err != nil {
|
||||
return nil, err
|
||||
}
|
||||
|
||||
icon.SetTarget(0, 0, float64(w), float64(h))
|
||||
rgba := image.NewRGBA(image.Rect(0, 0, w, h))
|
||||
gv := rasterx.NewScannerGV(w, h, rgba, rgba.Bounds())
|
||||
dasher := rasterx.NewDasher(w, h, gv)
|
||||
icon.Draw(dasher, 1.0)
|
||||
|
||||
return rgba, nil
|
||||
}
|
||||
|
||||
// Simple ICO encoder that wraps PNGs
|
||||
func writeICO(path string, images []image.Image) error {
|
||||
f, err := os.Create(path)
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
defer f.Close()
|
||||
|
||||
bw := bufio.NewWriter(f)
|
||||
defer bw.Flush()
|
||||
|
||||
// ICONDIR header
|
||||
// Reserved (2), Type (2), Count (2)
|
||||
binary.Write(bw, binary.LittleEndian, uint16(0))
|
||||
binary.Write(bw, binary.LittleEndian, uint16(1)) // 1 = ICO
|
||||
binary.Write(bw, binary.LittleEndian, uint16(len(images)))
|
||||
|
||||
var pngData [][]byte
|
||||
|
||||
for _, img := range images {
|
||||
var buf bytes.Buffer
|
||||
if err := png.Encode(&buf, img); err != nil {
|
||||
return err
|
||||
}
|
||||
|
||||
pngData = append(pngData, buf.Bytes())
|
||||
}
|
||||
|
||||
offset := uint32(6 + len(images)*16)
|
||||
for i, img := range images {
|
||||
b := img.Bounds()
|
||||
|
||||
width := uint8(b.Dx())
|
||||
if b.Dx() >= 256 {
|
||||
width = 0
|
||||
}
|
||||
|
||||
height := uint8(b.Dy())
|
||||
if b.Dy() >= 256 {
|
||||
height = 0
|
||||
}
|
||||
|
||||
// ICONDIRENTRY
|
||||
bw.WriteByte(width)
|
||||
bw.WriteByte(height)
|
||||
bw.WriteByte(0) // Color count
|
||||
bw.WriteByte(0) // Reserved
|
||||
binary.Write(bw, binary.LittleEndian, uint16(1)) // Planes (1)
|
||||
binary.Write(bw, binary.LittleEndian, uint16(32)) // Bits per pixel (32)
|
||||
binary.Write(bw, binary.LittleEndian, uint32(len(pngData[i])))
|
||||
binary.Write(bw, binary.LittleEndian, offset)
|
||||
|
||||
offset += uint32(len(pngData[i]))
|
||||
}
|
||||
|
||||
for _, data := range pngData {
|
||||
bw.Write(data)
|
||||
}
|
||||
|
||||
return nil
|
||||
}
|
||||
@@ -0,0 +1 @@
|
||||
test_output/
|
||||
@@ -0,0 +1,305 @@
|
||||
// Package main provides a utility to extract icons from Bose-branded TrueType fonts.
|
||||
package main
|
||||
|
||||
import (
|
||||
"encoding/json"
|
||||
"flag"
|
||||
"fmt"
|
||||
"image"
|
||||
"image/color"
|
||||
"image/draw"
|
||||
"image/png"
|
||||
"log"
|
||||
"os"
|
||||
"path/filepath"
|
||||
"sort"
|
||||
|
||||
"github.com/srwiley/rasterx"
|
||||
"golang.org/x/image/font"
|
||||
"golang.org/x/image/font/sfnt"
|
||||
"golang.org/x/image/math/fixed"
|
||||
)
|
||||
|
||||
type IconMapping struct {
|
||||
Hex string `json:"hex"`
|
||||
GlyphName string `json:"glyph_name"`
|
||||
File string `json:"file"`
|
||||
SVGFile string `json:"svg_file,omitempty"`
|
||||
}
|
||||
|
||||
func main() {
|
||||
fontPath := flag.String("font", "/path/to/bose.ttf", "Path to the TTF font file")
|
||||
outputDir := flag.String("output", "extracted_icons", "Output directory for icons")
|
||||
imgSize := flag.Int("size", 256, "Size of the PNG icons")
|
||||
|
||||
flag.Parse()
|
||||
|
||||
if err := os.MkdirAll(*outputDir, 0755); err != nil {
|
||||
log.Fatalf("Failed to create output directory: %v", err)
|
||||
}
|
||||
|
||||
data, err := os.ReadFile(*fontPath)
|
||||
if err != nil {
|
||||
log.Fatalf("Failed to read font file: %v", err)
|
||||
}
|
||||
|
||||
f, err := sfnt.Parse(data)
|
||||
if err != nil {
|
||||
log.Fatalf("Failed to parse font: %v", err)
|
||||
}
|
||||
|
||||
var (
|
||||
buffer sfnt.Buffer
|
||||
glyphIndex sfnt.GlyphIndex
|
||||
glyphName string
|
||||
segments sfnt.Segments
|
||||
pngFile *os.File
|
||||
)
|
||||
|
||||
unitsPerEm := f.UnitsPerEm()
|
||||
ppem := fixed.Int26_6(unitsPerEm) << 6
|
||||
|
||||
m, err := f.Metrics(&buffer, ppem, font.HintingNone)
|
||||
if err != nil {
|
||||
log.Fatalf("Failed to get metrics: %v", err)
|
||||
}
|
||||
|
||||
mapping := make(map[rune]IconMapping)
|
||||
|
||||
// Iterate through common ranges
|
||||
ranges := []struct{ start, end rune }{
|
||||
{0x20, 0x7E}, // Basic Latin
|
||||
{0xA0, 0xFF}, // Latin-1 Supplement
|
||||
{0xE000, 0xF8FF}, // Private Use Area
|
||||
}
|
||||
|
||||
for _, rg := range ranges {
|
||||
for r := rg.start; r <= rg.end; r++ {
|
||||
glyphIndex, err = f.GlyphIndex(&buffer, r)
|
||||
if err != nil || glyphIndex == 0 {
|
||||
continue
|
||||
}
|
||||
|
||||
glyphName, err = f.GlyphName(&buffer, glyphIndex)
|
||||
if err != nil {
|
||||
glyphName = fmt.Sprintf("uni%04X", r)
|
||||
}
|
||||
|
||||
segments, err = f.LoadGlyph(&buffer, glyphIndex, ppem, nil)
|
||||
if err != nil {
|
||||
fmt.Printf("Failed to load glyph 0x%04X: %v\n", r, err)
|
||||
continue
|
||||
}
|
||||
|
||||
if len(segments) == 0 {
|
||||
continue
|
||||
}
|
||||
|
||||
charHex := fmt.Sprintf("%04X", r)
|
||||
pngFilename := fmt.Sprintf("icon_%s.png", charHex)
|
||||
svgFilename := fmt.Sprintf("icon_%s.svg", charHex)
|
||||
|
||||
// 1. Extract SVG
|
||||
svgPath := segmentsToSVGPath(segments)
|
||||
totalHeight := float64(m.Ascent+m.Descent) / 64.0
|
||||
svgContent := fmt.Sprintf(`<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 %g %d %g">
|
||||
<g transform="scale(1, -1)">
|
||||
<path d="%s" />
|
||||
</g>
|
||||
</svg>`, -float64(m.Ascent)/64.0, int(unitsPerEm), totalHeight, svgPath)
|
||||
|
||||
if err = os.WriteFile(filepath.Join(*outputDir, svgFilename), []byte(svgContent), 0644); err != nil {
|
||||
fmt.Printf("Failed to write SVG 0x%s: %v\n", charHex, err)
|
||||
}
|
||||
|
||||
// 2. Render PNG
|
||||
img := renderGlyphToPNG(segments, int(unitsPerEm), int(m.Ascent), int(m.Descent), *imgSize)
|
||||
|
||||
pngFile, err = os.Create(filepath.Join(*outputDir, pngFilename))
|
||||
if err == nil {
|
||||
if err = png.Encode(pngFile, img); err != nil {
|
||||
fmt.Printf("Failed to encode PNG 0x%s: %v\n", charHex, err)
|
||||
}
|
||||
|
||||
pngFile.Close()
|
||||
} else {
|
||||
fmt.Printf("Failed to create PNG file 0x%s: %v\n", charHex, err)
|
||||
}
|
||||
|
||||
mapping[r] = IconMapping{
|
||||
Hex: fmt.Sprintf("0x%s", charHex),
|
||||
GlyphName: glyphName,
|
||||
File: pngFilename,
|
||||
SVGFile: svgFilename,
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Save mapping.json
|
||||
mappingList := make(map[string]IconMapping)
|
||||
|
||||
var keys []int
|
||||
|
||||
for r, m := range mapping {
|
||||
mappingList[fmt.Sprintf("%d", r)] = m
|
||||
keys = append(keys, int(r))
|
||||
}
|
||||
|
||||
sort.Ints(keys)
|
||||
|
||||
jsonData, err := json.MarshalIndent(mappingList, "", " ")
|
||||
if err != nil {
|
||||
log.Fatalf("Failed to marshal mapping: %v", err)
|
||||
}
|
||||
|
||||
_ = os.WriteFile(filepath.Join(*outputDir, "mapping.json"), jsonData, 0644)
|
||||
|
||||
// Save mapping.md
|
||||
mdFile, _ := os.Create(filepath.Join(*outputDir, "mapping.md"))
|
||||
fmt.Fprintln(mdFile, "# Bose Icons Mapping")
|
||||
fmt.Fprintln(mdFile, "")
|
||||
fmt.Fprintln(mdFile, "| Char Code | Glyph Name | PNG | SVG |")
|
||||
fmt.Fprintln(mdFile, "| --- | --- | --- | --- |")
|
||||
|
||||
for _, k := range keys {
|
||||
m := mapping[rune(k)]
|
||||
fmt.Fprintf(mdFile, "| %s | %s |  | [SVG](%s) |\n", m.Hex, m.GlyphName, m.GlyphName, m.File, m.SVGFile)
|
||||
}
|
||||
|
||||
mdFile.Close()
|
||||
|
||||
fmt.Printf("Extracted %d icons to %s\n", len(mapping), *outputDir)
|
||||
}
|
||||
|
||||
func segmentsToSVGPath(segments sfnt.Segments) string {
|
||||
var path string
|
||||
|
||||
for _, seg := range segments {
|
||||
switch seg.Op {
|
||||
case sfnt.SegmentOpMoveTo:
|
||||
path += fmt.Sprintf("M%g %g ", float64(seg.Args[0].X)/64.0, -float64(seg.Args[0].Y)/64.0)
|
||||
case sfnt.SegmentOpLineTo:
|
||||
path += fmt.Sprintf("L%g %g ", float64(seg.Args[0].X)/64.0, -float64(seg.Args[0].Y)/64.0)
|
||||
case sfnt.SegmentOpQuadTo:
|
||||
path += fmt.Sprintf("Q%g %g %g %g ", float64(seg.Args[0].X)/64.0, -float64(seg.Args[0].Y)/64.0, float64(seg.Args[1].X)/64.0, -float64(seg.Args[1].Y)/64.0)
|
||||
case sfnt.SegmentOpCubeTo:
|
||||
path += fmt.Sprintf("C%g %g %g %g %g %g ", float64(seg.Args[0].X)/64.0, -float64(seg.Args[0].Y)/64.0, float64(seg.Args[1].X)/64.0, -float64(seg.Args[1].Y)/64.0, float64(seg.Args[2].X)/64.0, -float64(seg.Args[2].Y)/64.0)
|
||||
}
|
||||
}
|
||||
|
||||
return path
|
||||
}
|
||||
|
||||
func renderGlyphToPNG(segments sfnt.Segments, _, _, _, imgSize int) image.Image {
|
||||
rgba := image.NewRGBA(image.Rect(0, 0, imgSize, imgSize))
|
||||
draw.Draw(rgba, rgba.Bounds(), image.Transparent, image.Point{}, draw.Src)
|
||||
|
||||
// Calculate glyph bounds
|
||||
var xmin, ymin, xmax, ymax float64
|
||||
|
||||
initialized := false
|
||||
|
||||
for _, seg := range segments {
|
||||
for _, arg := range seg.Args {
|
||||
x, y := float64(arg.X)/64.0, float64(arg.Y)/64.0
|
||||
if !initialized {
|
||||
xmin, xmax = x, x
|
||||
ymin, ymax = y, y
|
||||
initialized = true
|
||||
} else {
|
||||
if x < xmin {
|
||||
xmin = x
|
||||
}
|
||||
|
||||
if x > xmax {
|
||||
xmax = x
|
||||
}
|
||||
|
||||
if y < ymin {
|
||||
ymin = y
|
||||
}
|
||||
|
||||
if y > ymax {
|
||||
ymax = y
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
w := xmax - xmin
|
||||
h := ymax - ymin
|
||||
|
||||
// If no width/height, return empty image
|
||||
if w <= 0 || h <= 0 {
|
||||
return rgba
|
||||
}
|
||||
|
||||
// Calculate scale to fit in imgSize with padding
|
||||
padding := 20.0
|
||||
available := float64(imgSize) - 2*padding
|
||||
|
||||
scale := available / w
|
||||
if h*scale > available {
|
||||
scale = available / h
|
||||
}
|
||||
|
||||
// Center the glyph
|
||||
// X: center of image (imgSize/2) - (center of glyph (xmin+xmax)/2) * scale
|
||||
offsetX := float64(imgSize)/2.0 - (xmin+xmax)/2.0*scale
|
||||
// Y: center of image (imgSize/2) - (center of glyph (ymin+ymax)/2) * scale
|
||||
offsetY := float64(imgSize)/2.0 - (ymin+ymax)/2.0*scale
|
||||
|
||||
scanner := rasterx.NewScannerGV(imgSize, imgSize, rgba, rgba.Bounds())
|
||||
filler := rasterx.NewFiller(imgSize, imgSize, scanner)
|
||||
filler.SetColor(color.Black)
|
||||
|
||||
for _, seg := range segments {
|
||||
switch seg.Op {
|
||||
case sfnt.SegmentOpMoveTo:
|
||||
filler.Start(fixedP(
|
||||
offsetX+float64(seg.Args[0].X)/64.0*scale,
|
||||
offsetY+float64(seg.Args[0].Y)/64.0*scale,
|
||||
))
|
||||
case sfnt.SegmentOpLineTo:
|
||||
filler.Line(fixedP(
|
||||
offsetX+float64(seg.Args[0].X)/64.0*scale,
|
||||
offsetY+float64(seg.Args[0].Y)/64.0*scale,
|
||||
))
|
||||
case sfnt.SegmentOpQuadTo:
|
||||
filler.QuadBezier(
|
||||
fixedP(
|
||||
offsetX+float64(seg.Args[0].X)/64.0*scale,
|
||||
offsetY+float64(seg.Args[0].Y)/64.0*scale,
|
||||
),
|
||||
fixedP(
|
||||
offsetX+float64(seg.Args[1].X)/64.0*scale,
|
||||
offsetY+float64(seg.Args[1].Y)/64.0*scale,
|
||||
),
|
||||
)
|
||||
case sfnt.SegmentOpCubeTo:
|
||||
filler.CubeBezier(
|
||||
fixedP(
|
||||
offsetX+float64(seg.Args[0].X)/64.0*scale,
|
||||
offsetY+float64(seg.Args[0].Y)/64.0*scale,
|
||||
),
|
||||
fixedP(
|
||||
offsetX+float64(seg.Args[1].X)/64.0*scale,
|
||||
offsetY+float64(seg.Args[1].Y)/64.0*scale,
|
||||
),
|
||||
fixedP(
|
||||
offsetX+float64(seg.Args[2].X)/64.0*scale,
|
||||
offsetY+float64(seg.Args[2].Y)/64.0*scale,
|
||||
),
|
||||
)
|
||||
}
|
||||
}
|
||||
|
||||
filler.Stop(true)
|
||||
filler.Draw()
|
||||
|
||||
return rgba
|
||||
}
|
||||
|
||||
func fixedP(x, y float64) fixed.Point26_6 {
|
||||
return fixed.Point26_6{X: fixed.Int26_6(x * 64), Y: fixed.Int26_6(y * 64)}
|
||||
}
|
||||
@@ -0,0 +1,103 @@
|
||||
package main
|
||||
|
||||
import (
|
||||
"fmt"
|
||||
"image/png"
|
||||
"os"
|
||||
"path/filepath"
|
||||
"testing"
|
||||
|
||||
"golang.org/x/image/font"
|
||||
"golang.org/x/image/font/sfnt"
|
||||
"golang.org/x/image/math/fixed"
|
||||
)
|
||||
|
||||
func TestExtractE115(t *testing.T) {
|
||||
fontPath := "testdata/bose_subset.ttf"
|
||||
outputDir := "test_output"
|
||||
refDir := "testdata/references"
|
||||
imgSize := 256
|
||||
targetRune := rune(0xE115)
|
||||
|
||||
if err := os.MkdirAll(outputDir, 0755); err != nil {
|
||||
t.Fatalf("Failed to create output directory: %v", err)
|
||||
}
|
||||
|
||||
data, err := os.ReadFile(fontPath)
|
||||
if err != nil {
|
||||
t.Fatalf("Failed to read font file: %v", err)
|
||||
}
|
||||
|
||||
f, err := sfnt.Parse(data)
|
||||
if err != nil {
|
||||
t.Fatalf("Failed to parse font: %v", err)
|
||||
}
|
||||
|
||||
var buffer sfnt.Buffer
|
||||
unitsPerEm := f.UnitsPerEm()
|
||||
ppem := fixed.Int26_6(unitsPerEm) << 6
|
||||
|
||||
m, err := f.Metrics(&buffer, ppem, font.HintingNone)
|
||||
if err != nil {
|
||||
t.Fatalf("Failed to get metrics: %v", err)
|
||||
}
|
||||
|
||||
glyphIndex, err := f.GlyphIndex(&buffer, targetRune)
|
||||
if err != nil || glyphIndex == 0 {
|
||||
t.Fatalf("Failed to find glyph for 0x%X", targetRune)
|
||||
}
|
||||
|
||||
segments, err := f.LoadGlyph(&buffer, glyphIndex, ppem, nil)
|
||||
if err != nil {
|
||||
t.Fatalf("Failed to load glyph 0x%X: %v", targetRune, err)
|
||||
}
|
||||
|
||||
charHex := fmt.Sprintf("%04X", targetRune)
|
||||
pngFilename := fmt.Sprintf("icon_%s.png", charHex)
|
||||
svgFilename := fmt.Sprintf("icon_%s.svg", charHex)
|
||||
|
||||
// 1. Extract SVG
|
||||
svgPath := segmentsToSVGPath(segments)
|
||||
totalHeight := float64(m.Ascent+m.Descent) / 64.0
|
||||
svgContent := fmt.Sprintf(`<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 %g %d %g">
|
||||
<g transform="scale(1, -1)">
|
||||
<path d="%s" />
|
||||
</g>
|
||||
</svg>`, -float64(m.Ascent)/64.0, int(unitsPerEm), totalHeight, svgPath)
|
||||
|
||||
svgFilePath := filepath.Join(outputDir, svgFilename)
|
||||
if err = os.WriteFile(svgFilePath, []byte(svgContent), 0644); err != nil {
|
||||
t.Errorf("Failed to write SVG 0x%s: %v", charHex, err)
|
||||
}
|
||||
|
||||
// 2. Render PNG
|
||||
img := renderGlyphToPNG(segments, int(unitsPerEm), int(m.Ascent), int(m.Descent), imgSize)
|
||||
|
||||
pngFilePath := filepath.Join(outputDir, pngFilename)
|
||||
pngFile, err := os.Create(pngFilePath)
|
||||
if err == nil {
|
||||
if err = png.Encode(pngFile, img); err != nil {
|
||||
t.Errorf("Failed to encode PNG 0x%s: %v", charHex, err)
|
||||
}
|
||||
pngFile.Close()
|
||||
} else {
|
||||
t.Errorf("Failed to create PNG file 0x%s: %v", charHex, err)
|
||||
}
|
||||
|
||||
// 3. Compare with references
|
||||
for _, filename := range []string{svgFilename, pngFilename} {
|
||||
generated, err := os.ReadFile(filepath.Join(outputDir, filename))
|
||||
if err != nil {
|
||||
t.Errorf("Failed to read generated file %s: %v", filename, err)
|
||||
continue
|
||||
}
|
||||
reference, err := os.ReadFile(filepath.Join(refDir, filename))
|
||||
if err != nil {
|
||||
t.Errorf("Failed to read reference file %s: %v", filename, err)
|
||||
continue
|
||||
}
|
||||
if string(generated) != string(reference) {
|
||||
t.Errorf("Mismatch in %s: generated does not match reference", filename)
|
||||
}
|
||||
}
|
||||
}
|
||||
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 2.7 KiB |
@@ -0,0 +1,5 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 -765 1000 924">
|
||||
<g transform="scale(1, -1)">
|
||||
<path d="M119 -31 L828 678 L871 635 L162 -74 L119 -31 M206 194 L206 405 Q206 426 220 440 Q235 455 256 455 L405 455 L602 654 L668 654 L668 638 L607 572 L430 394 L267 394 L267 204 L269 204 L222 157 Q206 171 206 194 M435 112 L478 155 L607 26 L607 285 L668 345 L668 -56 L602 -56 L435 112 " />
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 404 B |
@@ -652,6 +652,73 @@ func listMusicServiceAccounts(c *cli.Context) error {
|
||||
return nil
|
||||
}
|
||||
|
||||
// pairDevice triggers the Stockholm registration flow via WebSocket
|
||||
func pairDevice(c *cli.Context) error {
|
||||
clientConfig := GetClientConfig(c)
|
||||
|
||||
client, err := CreateSoundTouchClient(clientConfig)
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
|
||||
accountID := c.String("id")
|
||||
token := c.String("token")
|
||||
|
||||
PrintDeviceHeader("Pairing device with Marge account", clientConfig.Host, clientConfig.Port)
|
||||
fmt.Printf(" Account ID: %s\n", accountID)
|
||||
|
||||
// We need a WebSocket client for this
|
||||
ws := client.NewWebSocketClient(nil)
|
||||
|
||||
err = ws.Connect()
|
||||
if err != nil {
|
||||
return fmt.Errorf("failed to connect to device WebSocket: %w", err)
|
||||
}
|
||||
|
||||
defer func() { _ = ws.Disconnect() }()
|
||||
|
||||
err = ws.PairWithAccount(accountID, token)
|
||||
if err != nil {
|
||||
return fmt.Errorf("failed to send pairing request: %w", err)
|
||||
}
|
||||
|
||||
PrintSuccess("Pairing request sent successfully")
|
||||
fmt.Println("💡 The device will now register itself with the cloud service.")
|
||||
|
||||
return nil
|
||||
}
|
||||
|
||||
// unpairDevice triggers the Stockholm unregistration flow via WebSocket
|
||||
func unpairDevice(c *cli.Context) error {
|
||||
clientConfig := GetClientConfig(c)
|
||||
|
||||
client, err := CreateSoundTouchClient(clientConfig)
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
|
||||
PrintDeviceHeader("Unpairing device from Marge account", clientConfig.Host, clientConfig.Port)
|
||||
|
||||
// We need a WebSocket client for this
|
||||
ws := client.NewWebSocketClient(nil)
|
||||
|
||||
err = ws.Connect()
|
||||
if err != nil {
|
||||
return fmt.Errorf("failed to connect to device WebSocket: %w", err)
|
||||
}
|
||||
|
||||
defer func() { _ = ws.Disconnect() }()
|
||||
|
||||
err = ws.UnPairFromAccount()
|
||||
if err != nil {
|
||||
return fmt.Errorf("failed to send unpairing request: %w", err)
|
||||
}
|
||||
|
||||
PrintSuccess("Unpairing request sent successfully")
|
||||
|
||||
return nil
|
||||
}
|
||||
|
||||
// getServiceDisplayName returns a user-friendly display name for a service
|
||||
func getServiceDisplayName(source string) string {
|
||||
switch source {
|
||||
|
||||
@@ -389,6 +389,10 @@ func handleSpecialMessage(message *models.SpecialMessage, filters map[string]boo
|
||||
if !filters["userActivity"] {
|
||||
return
|
||||
}
|
||||
case models.MessageTypeUserInactivity:
|
||||
if !filters["userInactivity"] {
|
||||
return
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -402,6 +406,12 @@ func handleSpecialMessage(message *models.SpecialMessage, filters map[string]boo
|
||||
case models.MessageTypeUserActivity:
|
||||
fmt.Printf("\n👤 User Activity [%s]\n", message.DeviceID)
|
||||
|
||||
if verbose {
|
||||
fmt.Printf(" ⏰ Timestamp: %s\n", message.Timestamp.Format("15:04:05"))
|
||||
}
|
||||
case models.MessageTypeUserInactivity:
|
||||
fmt.Printf("\n💤 User Inactivity [%s]\n", message.DeviceID)
|
||||
|
||||
if verbose {
|
||||
fmt.Printf(" ⏰ Timestamp: %s\n", message.Timestamp.Format("15:04:05"))
|
||||
}
|
||||
|
||||
@@ -1,7 +1,9 @@
|
||||
package main
|
||||
|
||||
import (
|
||||
"encoding/base64"
|
||||
"fmt"
|
||||
"net/url"
|
||||
"strings"
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/models"
|
||||
@@ -251,6 +253,61 @@ func selectLocalInternetRadio(c *cli.Context) error {
|
||||
return nil
|
||||
}
|
||||
|
||||
// selectCustomRadio handles selecting custom radio stream via soundtouch-service
|
||||
func selectCustomRadio(c *cli.Context) error {
|
||||
clientConfig := GetClientConfig(c)
|
||||
|
||||
client, err := CreateSoundTouchClient(clientConfig)
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
|
||||
streamURL := c.String("url")
|
||||
itemName := c.String("name")
|
||||
containerArt := c.String("artwork")
|
||||
serviceURL := c.String("service-url")
|
||||
|
||||
encodedURL := base64.URLEncoding.EncodeToString([]byte(streamURL))
|
||||
location := fmt.Sprintf("%s/custom/v1/playback/%s", serviceURL, encodedURL)
|
||||
|
||||
params := url.Values{}
|
||||
if itemName != "" {
|
||||
params.Add("name", itemName)
|
||||
}
|
||||
|
||||
if containerArt != "" {
|
||||
params.Add("imageUrl", containerArt)
|
||||
}
|
||||
|
||||
if len(params) > 0 {
|
||||
location += "?" + params.Encode()
|
||||
}
|
||||
|
||||
// Check LOCAL_INTERNET_RADIO availability
|
||||
checker := NewServiceAvailabilityChecker(client)
|
||||
if !checker.CheckSourceAvailable("LOCAL_INTERNET_RADIO", "select custom radio") {
|
||||
return fmt.Errorf("LOCAL_INTERNET_RADIO is not available")
|
||||
}
|
||||
|
||||
PrintDeviceHeader("Selecting custom radio stream", clientConfig.Host, clientConfig.Port)
|
||||
|
||||
if itemName != "" {
|
||||
fmt.Printf(" Station: %s\n", itemName)
|
||||
}
|
||||
|
||||
fmt.Printf(" URL: %s\n", streamURL)
|
||||
fmt.Printf(" Proxy: %s\n", location)
|
||||
|
||||
err = client.SelectLocalInternetRadio(location, "", itemName, containerArt)
|
||||
if err != nil {
|
||||
return fmt.Errorf("failed to select custom radio: %w", err)
|
||||
}
|
||||
|
||||
PrintSuccess("Custom radio stream selected")
|
||||
|
||||
return nil
|
||||
}
|
||||
|
||||
// selectLocalMusic handles selecting LOCAL_MUSIC source
|
||||
func selectLocalMusic(c *cli.Context) error {
|
||||
clientConfig := GetClientConfig(c)
|
||||
|
||||
@@ -2,7 +2,6 @@ package main
|
||||
|
||||
import (
|
||||
"fmt"
|
||||
"net/url"
|
||||
"strings"
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/models"
|
||||
@@ -35,23 +34,12 @@ func playTTS(c *cli.Context) error {
|
||||
return err
|
||||
}
|
||||
|
||||
// URL encode the text for Google TTS
|
||||
encodedText := url.QueryEscape(text)
|
||||
|
||||
// Build TTS URL with language support
|
||||
ttsURL := fmt.Sprintf("http://translate.google.com/translate_tts?ie=UTF-8&tl=%s&client=tw-ob&q=%s", language, encodedText)
|
||||
|
||||
// Create PlayInfo for TTS
|
||||
playInfo := &models.PlayInfo{
|
||||
URL: ttsURL,
|
||||
AppKey: appKey,
|
||||
Service: "TTS Notification",
|
||||
Message: "Google TTS",
|
||||
Reason: text,
|
||||
}
|
||||
|
||||
var playInfo *models.PlayInfo
|
||||
if volume > 0 {
|
||||
playInfo.SetVolume(volume)
|
||||
playInfo = models.NewTTSPlayInfo(text, appKey, language, volume)
|
||||
} else {
|
||||
playInfo = models.NewTTSPlayInfo(text, appKey, language)
|
||||
}
|
||||
|
||||
err = client.PlayCustom(playInfo)
|
||||
@@ -121,10 +109,11 @@ func playURL(c *cli.Context) error {
|
||||
}
|
||||
|
||||
// Create PlayInfo for URL content
|
||||
playInfo := models.NewURLPlayInfo(urlStr, appKey, service, message, reason)
|
||||
|
||||
var playInfo *models.PlayInfo
|
||||
if volume > 0 {
|
||||
playInfo.SetVolume(volume)
|
||||
playInfo = models.NewURLPlayInfo(urlStr, appKey, service, message, reason, volume)
|
||||
} else {
|
||||
playInfo = models.NewURLPlayInfo(urlStr, appKey, service, message, reason)
|
||||
}
|
||||
|
||||
err = client.PlayCustom(playInfo)
|
||||
@@ -147,10 +136,16 @@ func playURL(c *cli.Context) error {
|
||||
return nil
|
||||
}
|
||||
|
||||
// playNotificationBeep plays a notification beep on the speaker (uses existing endpoint)
|
||||
func playNotificationBeep(c *cli.Context) error {
|
||||
// playNotification plays a notification sound or a local file on the speaker
|
||||
func playNotification(c *cli.Context) error {
|
||||
clientConfig := GetClientConfig(c)
|
||||
PrintDeviceHeader("Playing notification beep", clientConfig.Host, clientConfig.Port)
|
||||
path := c.String("path")
|
||||
|
||||
if path != "" {
|
||||
PrintDeviceHeader(fmt.Sprintf("Playing notification file: %s", path), clientConfig.Host, clientConfig.Port)
|
||||
} else {
|
||||
PrintDeviceHeader("Playing notification beep", clientConfig.Host, clientConfig.Port)
|
||||
}
|
||||
|
||||
client, err := CreateSoundTouchClient(clientConfig)
|
||||
if err != nil {
|
||||
@@ -158,18 +153,31 @@ func playNotificationBeep(c *cli.Context) error {
|
||||
return err
|
||||
}
|
||||
|
||||
// Use the existing playNotification endpoint
|
||||
err = client.PlayNotificationBeep()
|
||||
err = client.PlayNotification(path)
|
||||
if err != nil {
|
||||
PrintError(fmt.Sprintf("Failed to play notification beep: %v", err))
|
||||
if path != "" {
|
||||
PrintError(fmt.Sprintf("Failed to play notification file: %v", err))
|
||||
} else {
|
||||
PrintError(fmt.Sprintf("Failed to play notification beep: %v", err))
|
||||
}
|
||||
|
||||
return err
|
||||
}
|
||||
|
||||
fmt.Printf("✅ Notification beep played successfully\n")
|
||||
if path != "" {
|
||||
fmt.Printf("✅ Notification file sent successfully: %s\n", path)
|
||||
} else {
|
||||
fmt.Printf("✅ Notification beep played successfully\n")
|
||||
}
|
||||
|
||||
return nil
|
||||
}
|
||||
|
||||
// playNotificationBeep plays a notification beep on the speaker (uses existing endpoint)
|
||||
func playNotificationBeep(c *cli.Context) error {
|
||||
return playNotification(c)
|
||||
}
|
||||
|
||||
// showSpeakerHelp displays help information about speaker functionality
|
||||
func showSpeakerHelp(_ *cli.Context) error {
|
||||
fmt.Println("SoundTouch Speaker Playback Commands")
|
||||
@@ -189,6 +197,10 @@ func showSpeakerHelp(_ *cli.Context) error {
|
||||
fmt.Println(" Play a simple notification sound")
|
||||
fmt.Println(" Example: soundtouch-cli speaker beep")
|
||||
fmt.Println()
|
||||
fmt.Println("• Custom Notification:")
|
||||
fmt.Println(" Play a device-local PCM file as notification")
|
||||
fmt.Println(" Example: soundtouch-cli speaker notify --path \"/opt/Bose/chimes/grouped.pcm\"")
|
||||
fmt.Println()
|
||||
fmt.Println("Notes:")
|
||||
fmt.Println("• Only ST-10 (Series III) speakers support the /speaker endpoint")
|
||||
fmt.Println("• ST-300 and other models may not support this functionality")
|
||||
|
||||
@@ -7,6 +7,7 @@ import (
|
||||
"io"
|
||||
"net"
|
||||
"net/http"
|
||||
"os"
|
||||
"regexp"
|
||||
"runtime"
|
||||
"strconv"
|
||||
@@ -195,7 +196,7 @@ var httpClient = &http.Client{
|
||||
}
|
||||
|
||||
func fetchTuneInMetadata(url string) (*Metadata, error) {
|
||||
if !strings.Contains(url, "tunein.com/radio/") {
|
||||
if !strings.Contains(url, "tunein.com/radio/") && !strings.Contains(url, "127.0.0.1") && !strings.Contains(url, "localhost") {
|
||||
return nil, fmt.Errorf("url is not a TuneIn radio URL")
|
||||
}
|
||||
|
||||
@@ -255,7 +256,7 @@ func fetchTuneInMetadata(url string) (*Metadata, error) {
|
||||
}
|
||||
|
||||
func fetchSpotifyMetadata(url string) (*Metadata, error) {
|
||||
if !strings.Contains(url, "open.spotify.com/") {
|
||||
if !strings.Contains(url, "open.spotify.com/") && !strings.Contains(url, "127.0.0.1") && !strings.Contains(url, "localhost") {
|
||||
return nil, fmt.Errorf("url is not a Spotify URL")
|
||||
}
|
||||
|
||||
@@ -331,7 +332,7 @@ func PrintWarning(message string) {
|
||||
|
||||
// showVersionInfo displays detailed version information including build details
|
||||
func showVersionInfo(_ *cli.Context) error {
|
||||
fmt.Printf("soundtouch-cli version %s\n", version)
|
||||
fmt.Printf("%s version %s\n", os.Args[0], version)
|
||||
fmt.Printf("Build commit: %s\n", commit)
|
||||
fmt.Printf("Build date: %s\n", date)
|
||||
fmt.Printf("Go version: %s\n", runtime.Version())
|
||||
|
||||
@@ -7,7 +7,7 @@ import (
|
||||
)
|
||||
|
||||
func TestFetchTuneInMetadata(t *testing.T) {
|
||||
ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, _ *http.Request) {
|
||||
ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
|
||||
html := `
|
||||
<!doctype html>
|
||||
<html>
|
||||
@@ -30,7 +30,7 @@ func TestFetchTuneInMetadata(t *testing.T) {
|
||||
|
||||
defer func() { httpClient = oldClient }()
|
||||
|
||||
metadata, err := fetchTuneInMetadata("https://tunein.com/radio/WDR-2-Rheinland-1004-s213886/")
|
||||
metadata, err := fetchTuneInMetadata(ts.URL + "/radio/WDR-2-Rheinland-1004-s213886/")
|
||||
if err != nil {
|
||||
t.Fatalf("fetchTuneInMetadata() error = %v", err)
|
||||
}
|
||||
@@ -162,7 +162,7 @@ func TestResolveLocationSpotify(t *testing.T) {
|
||||
}
|
||||
|
||||
func TestFetchSpotifyMetadata(t *testing.T) {
|
||||
ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, _ *http.Request) {
|
||||
ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
|
||||
html := `
|
||||
<!doctype html>
|
||||
<html>
|
||||
@@ -185,7 +185,7 @@ func TestFetchSpotifyMetadata(t *testing.T) {
|
||||
|
||||
defer func() { httpClient = oldClient }()
|
||||
|
||||
metadata, err := fetchSpotifyMetadata("https://open.spotify.com/album/7F50uh7oGitmAEScRKV6pD")
|
||||
metadata, err := fetchSpotifyMetadata(ts.URL + "/album/7F50uh7oGitmAEScRKV6pD")
|
||||
if err != nil {
|
||||
t.Fatalf("fetchSpotifyMetadata() error = %v", err)
|
||||
}
|
||||
|
||||
@@ -104,7 +104,7 @@ func main() {
|
||||
Version: version,
|
||||
Authors: []*cli.Author{
|
||||
{
|
||||
Name: "Tobias Gesellchen, and the SoundTouch CLI Contributors",
|
||||
Name: "Tobias Gesellchen, and the Bose-SoundTouch Contributors",
|
||||
},
|
||||
},
|
||||
Flags: CommonFlags,
|
||||
@@ -924,6 +924,34 @@ func main() {
|
||||
},
|
||||
},
|
||||
},
|
||||
{
|
||||
Name: "custom-radio",
|
||||
Usage: "Select custom radio stream via soundtouch-service",
|
||||
Action: selectCustomRadio,
|
||||
Before: RequireHost,
|
||||
Flags: []cli.Flag{
|
||||
&cli.StringFlag{
|
||||
Name: "url",
|
||||
Aliases: []string{"u"},
|
||||
Usage: "Stream URL",
|
||||
Required: true,
|
||||
},
|
||||
&cli.StringFlag{
|
||||
Name: "name",
|
||||
Aliases: []string{"n"},
|
||||
Usage: "Station name",
|
||||
},
|
||||
&cli.StringFlag{
|
||||
Name: "artwork",
|
||||
Usage: "Station artwork URL",
|
||||
},
|
||||
&cli.StringFlag{
|
||||
Name: "service-url",
|
||||
Usage: "URL of the soundtouch-service (default: http://localhost:8080)",
|
||||
Value: "http://localhost:8080",
|
||||
},
|
||||
},
|
||||
},
|
||||
{
|
||||
Name: "local-music",
|
||||
Usage: "Select local music content (LOCAL_MUSIC)",
|
||||
@@ -1707,6 +1735,19 @@ func main() {
|
||||
},
|
||||
},
|
||||
},
|
||||
{
|
||||
Name: "notify",
|
||||
Usage: "Play a notification sound or local file",
|
||||
Action: playNotification,
|
||||
Before: RequireHost,
|
||||
Flags: []cli.Flag{
|
||||
&cli.StringFlag{
|
||||
Name: "path",
|
||||
Aliases: []string{"p"},
|
||||
Usage: "Device-local path to a PCM file (e.g. /opt/Bose/chimes/grouped.pcm)",
|
||||
},
|
||||
},
|
||||
},
|
||||
{
|
||||
Name: "beep",
|
||||
Usage: "Play a notification beep sound",
|
||||
@@ -1997,6 +2038,30 @@ func main() {
|
||||
},
|
||||
},
|
||||
},
|
||||
{
|
||||
Name: "pair",
|
||||
Usage: "Pair the device with a Marge cloud account (Stockholm registration)",
|
||||
Action: pairDevice,
|
||||
Before: RequireHost,
|
||||
Flags: []cli.Flag{
|
||||
&cli.StringFlag{
|
||||
Name: "id",
|
||||
Usage: "Marge account ID (e.g., 1234567)",
|
||||
Required: true,
|
||||
},
|
||||
&cli.StringFlag{
|
||||
Name: "token",
|
||||
Usage: "User authorization token",
|
||||
Required: true,
|
||||
},
|
||||
},
|
||||
},
|
||||
{
|
||||
Name: "unpair",
|
||||
Usage: "Unpair the device from its Marge cloud account",
|
||||
Action: unpairDevice,
|
||||
Before: RequireHost,
|
||||
},
|
||||
},
|
||||
},
|
||||
// Token commands
|
||||
|
||||
+867
-92
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,92 @@
|
||||
package main
|
||||
|
||||
import (
|
||||
"os"
|
||||
"testing"
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/service/datastore"
|
||||
)
|
||||
|
||||
func TestApplyPersistedSettings(t *testing.T) {
|
||||
tmpDir, err := os.MkdirTemp("", "main-test")
|
||||
if err != nil {
|
||||
t.Fatalf("Failed to create temp dir: %v", err)
|
||||
}
|
||||
defer os.RemoveAll(tmpDir)
|
||||
|
||||
ds := datastore.NewDataStore(tmpDir)
|
||||
|
||||
t.Run("overrides true with false", func(t *testing.T) {
|
||||
config := &serviceConfig{
|
||||
redact: true,
|
||||
logBody: true,
|
||||
record: true,
|
||||
}
|
||||
|
||||
// Simulate the bug by using the old bitwise OR logic in the test,
|
||||
// which should fail if we expect false.
|
||||
// config.redact = config.redact || false -> stays true
|
||||
|
||||
settings := datastore.Settings{
|
||||
RedactLogs: false,
|
||||
LogBodies: false,
|
||||
RecordInteractions: false,
|
||||
}
|
||||
err := ds.SaveSettings(settings)
|
||||
if err != nil {
|
||||
t.Fatalf("Failed to save settings: %v", err)
|
||||
}
|
||||
|
||||
applyPersistedSettings(ds, config)
|
||||
|
||||
if config.redact != false {
|
||||
t.Errorf("Expected redact to be false, got true")
|
||||
}
|
||||
if config.logBody != false {
|
||||
t.Errorf("Expected logBody to be false, got true")
|
||||
}
|
||||
if config.record != false {
|
||||
t.Errorf("Expected record to be false, got true")
|
||||
}
|
||||
})
|
||||
|
||||
t.Run("retains false when settings are false", func(t *testing.T) {
|
||||
settings := datastore.Settings{
|
||||
RedactLogs: false,
|
||||
}
|
||||
err := ds.SaveSettings(settings)
|
||||
if err != nil {
|
||||
t.Fatalf("Failed to save settings: %v", err)
|
||||
}
|
||||
|
||||
config := &serviceConfig{
|
||||
redact: false,
|
||||
}
|
||||
|
||||
applyPersistedSettings(ds, config)
|
||||
|
||||
if config.redact != false {
|
||||
t.Errorf("Expected redact to be false, got true")
|
||||
}
|
||||
})
|
||||
|
||||
t.Run("overrides false with true", func(t *testing.T) {
|
||||
settings := datastore.Settings{
|
||||
RedactLogs: true,
|
||||
}
|
||||
err := ds.SaveSettings(settings)
|
||||
if err != nil {
|
||||
t.Fatalf("Failed to save settings: %v", err)
|
||||
}
|
||||
|
||||
config := &serviceConfig{
|
||||
redact: false,
|
||||
}
|
||||
|
||||
applyPersistedSettings(ds, config)
|
||||
|
||||
if config.redact != true {
|
||||
t.Errorf("Expected redact to be true, got false")
|
||||
}
|
||||
})
|
||||
}
|
||||
@@ -1 +1,8 @@
|
||||
accounts/
|
||||
certs/
|
||||
default/
|
||||
dns/
|
||||
interactions/
|
||||
parity_mismatches/
|
||||
patterns.json
|
||||
settings.json
|
||||
|
||||
@@ -1,8 +1,11 @@
|
||||
// Package soundtouch provides a comprehensive Go library and CLI tool for controlling Bose SoundTouch devices.
|
||||
// Package soundtouch provides a comprehensive Go library, CLI tool, and local service for controlling and emulating Bose SoundTouch devices.
|
||||
//
|
||||
// This library implements the complete Bose SoundTouch Web API, enabling programmatic control
|
||||
// This project implements the complete Bose SoundTouch Web API, enabling programmatic control
|
||||
// of SoundTouch speakers including playback control, volume management, source selection,
|
||||
// multiroom zone management, and real-time event monitoring via WebSocket connections.
|
||||
// multiroom zone management, and real-time event monitoring.
|
||||
//
|
||||
// It also provides a local service (`soundtouch-service`) that can emulate the Bose Cloud,
|
||||
// allowing for offline control and enhanced debugging through HTTP interaction recording.
|
||||
//
|
||||
// # Quick Start
|
||||
//
|
||||
@@ -41,63 +44,20 @@
|
||||
// if err != nil {
|
||||
// log.Fatal(err)
|
||||
// }
|
||||
//
|
||||
// // Set volume
|
||||
// err = client.SetVolume(50)
|
||||
// if err != nil {
|
||||
// log.Fatal(err)
|
||||
// }
|
||||
// }
|
||||
//
|
||||
// # Device Discovery
|
||||
// # SoundTouch Service
|
||||
//
|
||||
// Automatically discover SoundTouch devices on your network:
|
||||
// The `soundtouch-service` provides several advanced features:
|
||||
//
|
||||
// import "github.com/gesellix/bose-soundtouch/pkg/discovery"
|
||||
// - Bose Cloud Emulation: Allows speakers to work without an internet connection.
|
||||
// - HTTP Interaction Recording: Captures all traffic as IntelliJ-compatible .http files.
|
||||
// - Speaker Migration: Automated tools to redirect speakers to the local service.
|
||||
// - Web Interface: A management dashboard for proxy settings and speaker setup.
|
||||
//
|
||||
// // Discover devices using UPnP/SSDP
|
||||
// service := discovery.NewService(5*time.Second)
|
||||
// devices, err := service.DiscoverDevices(ctx)
|
||||
// if err != nil {
|
||||
// log.Fatal(err)
|
||||
// }
|
||||
// Install the service:
|
||||
//
|
||||
// for _, device := range devices {
|
||||
// fmt.Printf("Found device: %s at %s\n", device.Name, device.Host)
|
||||
// }
|
||||
//
|
||||
// # Real-time Events
|
||||
//
|
||||
// Monitor device state changes in real-time using WebSocket connections:
|
||||
//
|
||||
// // Subscribe to device events
|
||||
// events, err := client.SubscribeToEvents(ctx)
|
||||
// if err != nil {
|
||||
// log.Fatal(err)
|
||||
// }
|
||||
//
|
||||
// for event := range events {
|
||||
// switch e := event.(type) {
|
||||
// case *models.NowPlayingUpdated:
|
||||
// fmt.Printf("Now playing: %s by %s\n", e.Track, e.Artist)
|
||||
// case *models.VolumeUpdated:
|
||||
// fmt.Printf("Volume changed to: %d\n", e.ActualVolume)
|
||||
// }
|
||||
// }
|
||||
//
|
||||
// # Multiroom Zone Management
|
||||
//
|
||||
// Create and manage multiroom zones:
|
||||
//
|
||||
// // Create a zone with multiple speakers
|
||||
// zone := &models.Zone{
|
||||
// Master: "192.168.1.100",
|
||||
// Members: []models.ZoneMember{
|
||||
// {IPAddress: "192.168.1.101"},
|
||||
// {IPAddress: "192.168.1.102"},
|
||||
// },
|
||||
// }
|
||||
// err = client.SetZone(zone)
|
||||
// go install github.com/gesellix/bose-soundtouch/cmd/soundtouch-service@latest
|
||||
//
|
||||
// # CLI Tool
|
||||
//
|
||||
@@ -111,45 +71,33 @@
|
||||
//
|
||||
// # Control a device
|
||||
// soundtouch-cli --host 192.168.1.100 play start
|
||||
// soundtouch-cli --host 192.168.1.100 volume set --level 50
|
||||
// soundtouch-cli --host 192.168.1.100 source select --source SPOTIFY
|
||||
//
|
||||
// # Supported Features
|
||||
//
|
||||
// - ✅ Device Information & Capabilities
|
||||
// - ✅ Playback Control (Play/Pause/Stop/Next/Previous)
|
||||
// - ✅ Volume, Bass, and Balance Control
|
||||
// - ✅ Source Selection (Spotify, Bluetooth, AUX, etc.)
|
||||
// - ✅ Preset Management
|
||||
// - ✅ Clock/Time Management
|
||||
// - ✅ Network Information
|
||||
// - ✅ Playback, Volume, Bass, and Balance Control
|
||||
// - ✅ Source Selection & Preset Management
|
||||
// - ✅ Real-time WebSocket Events
|
||||
// - ✅ Multiroom Zone Management
|
||||
// - ✅ Device Discovery (UPnP/SSDP and mDNS)
|
||||
// - ✅ Cross-platform Support (Windows, macOS, Linux)
|
||||
// - ✅ Local Cloud Emulation (soundtouch-service)
|
||||
// - ✅ HTTP Traffic Recording & Sanitization
|
||||
// - ✅ Automated Speaker Migration & Revert
|
||||
//
|
||||
// # Package Structure
|
||||
//
|
||||
// - client: HTTP client for SoundTouch Web API
|
||||
// - discovery: Device discovery using UPnP/SSDP and mDNS
|
||||
// - models: Data structures for API requests/responses
|
||||
// - config: Configuration management
|
||||
// - service: Core logic for the soundtouch-service (proxy, recording, setup)
|
||||
// - cmd/soundtouch-cli: Command-line interface tool
|
||||
//
|
||||
// # Hardware Compatibility
|
||||
//
|
||||
// This library has been tested with real Bose SoundTouch hardware and supports
|
||||
// all SoundTouch-compatible devices including:
|
||||
// - SoundTouch 10, 20, 30 series
|
||||
// - SoundTouch Portable
|
||||
// - Wave SoundTouch music system
|
||||
// - And other SoundTouch-enabled Bose speakers
|
||||
// - cmd/soundtouch-service: Local cloud emulation service
|
||||
//
|
||||
// # Implementation Notes
|
||||
//
|
||||
// This implementation is based on the official Bose SoundTouch Web API documentation
|
||||
// and provides 90% coverage of all available endpoints. It is an independent project
|
||||
// and is not affiliated with or endorsed by Bose Corporation.
|
||||
// This project is an independent effort to preserve the functionality of Bose SoundTouch
|
||||
// devices and provide enhanced debugging and control capabilities. It is not
|
||||
// affiliated with or endorsed by Bose Corporation.
|
||||
//
|
||||
// For detailed API documentation, examples, and advanced usage patterns, visit:
|
||||
// https://pkg.go.dev/github.com/gesellix/bose-soundtouch
|
||||
|
||||
+29
-3
@@ -1,15 +1,41 @@
|
||||
services:
|
||||
soundtouch-service:
|
||||
build: .
|
||||
image: ghcr.io/gesellix/bose-soundtouch:latest
|
||||
# build: .
|
||||
container_name: soundtouch-service
|
||||
# network_mode: host # Linux only, required for discovery
|
||||
# Linux only, required for discovery. Swarm requires host network at the task level.
|
||||
# network_mode: host
|
||||
ports:
|
||||
- "8000:8000"
|
||||
- "8443:8443"
|
||||
environment:
|
||||
- PORT=8000
|
||||
- HTTPS_PORT=8443
|
||||
- DATA_DIR=/app/data
|
||||
- LOG_PROXY_BODY=false
|
||||
- REDACT_PROXY_LOGS=true
|
||||
- RECORD_INTERACTIONS=true
|
||||
- DISCOVERY_INTERVAL=5m
|
||||
- SERVER_URL=http://${SOUNDTOUCH_HOSTNAME:-soundtouch.local}:8000
|
||||
- HTTPS_SERVER_URL=https://${SOUNDTOUCH_HOSTNAME:-soundtouch.local}:8443
|
||||
volumes:
|
||||
- ./data:/app/data
|
||||
- soundtouch-data:/app/data
|
||||
# Use host volume for local development if preferred:
|
||||
# - ./data:/app/data
|
||||
restart: unless-stopped
|
||||
deploy:
|
||||
replicas: 1
|
||||
restart_policy:
|
||||
condition: on-failure
|
||||
resources:
|
||||
limits:
|
||||
cpus: '0.50'
|
||||
memory: 512M
|
||||
reservations:
|
||||
cpus: '0.25'
|
||||
memory: 128M
|
||||
|
||||
volumes:
|
||||
soundtouch-data:
|
||||
# Named volumes are preferred in Swarm. For multi-node persistence,
|
||||
# consider using a volume driver like NFS or GlusterFS.
|
||||
|
||||
+2
-3
@@ -4,9 +4,9 @@
|
||||
|
||||
This document contains important development guidelines for working on the Bose SoundTouch project. Please also read the following documentation:
|
||||
|
||||
- **[PLAN.md](PLAN.md)** - Project planning and roadmap
|
||||
- **[PLAN.md](archive/PLAN.md)** - Project planning and roadmap
|
||||
- **[PROJECT-PATTERNS.md](PROJECT-PATTERNS.md)** - Project structure and design patterns
|
||||
- **[API-Endpoints-Overview.md](API-Endpoints-Overview.md)** - API endpoints overview
|
||||
- **[API-ENDPOINTS.md](reference/API-ENDPOINTS.md)** - API endpoints overview
|
||||
- **[SoundTouch Web API.pdf](2025.12.18%20SoundTouch%20Web%20API.pdf)** - Official API documentation
|
||||
|
||||
## Development Guidelines
|
||||
@@ -95,4 +95,3 @@ When creating test data for API endpoints, prefer real device responses over hyp
|
||||
- **Documentation**: Completely in English for international accessibility
|
||||
- Conduct regular code reviews
|
||||
- Consider performance from the beginning
|
||||
|
||||
|
||||
@@ -23,6 +23,14 @@ All content selection features from the [SoundTouch WebServices API Wiki](https:
|
||||
- Automatic defaults for missing parameters
|
||||
- **Use Cases**: Internet radio streams, proxy-based radio services
|
||||
|
||||
#### `SelectLocalInternetRadio(location, ...)` via `soundtouch-service`
|
||||
- **Purpose**: Select custom radio stream via local `soundtouch-service` proxy
|
||||
- **Features**:
|
||||
- Flexible stream URL encoding (Base64 or URL-escaped)
|
||||
- Dynamic generation of Bose-compatible playback JSON
|
||||
- Seamless integration with existing `LOCAL_INTERNET_RADIO` source
|
||||
- **Use Case**: Playing any internet radio URL without external proxy dependencies
|
||||
|
||||
#### `SelectLocalMusic(location, sourceAccount, itemName, containerArt string) error`
|
||||
- **Purpose**: Select LOCAL_MUSIC content from SoundTouch App Media Server
|
||||
- **Requirements**: SoundTouch App Media Server running on a computer
|
||||
@@ -47,6 +55,15 @@ soundtouch-cli --host <device> source internet-radio \
|
||||
--artwork "https://example.com/art.png"
|
||||
```
|
||||
|
||||
#### `soundtouch-cli source custom-radio`
|
||||
```bash
|
||||
soundtouch-cli --host <device> source custom-radio \
|
||||
--url "https://stream.example.com/radio" \
|
||||
--name "My Station" \
|
||||
--artwork "https://example.com/art.png" \
|
||||
--service-url "http://localhost:8080"
|
||||
```
|
||||
|
||||
#### `soundtouch-cli source local-music`
|
||||
```bash
|
||||
soundtouch-cli --host <device> source local-music \
|
||||
@@ -101,7 +118,7 @@ Comprehensive test suites implemented for all new functionality:
|
||||
### Example Code
|
||||
Complete working example demonstrating:
|
||||
- LOCAL_INTERNET_RADIO with streamUrl proxy format
|
||||
- LOCAL_INTERNET_RADIO with direct streams
|
||||
- LOCAL_INTERNET_RADIO with direct streams
|
||||
- LOCAL_MUSIC content selection
|
||||
- STORED_MUSIC content selection
|
||||
- Generic ContentItem usage
|
||||
@@ -152,7 +169,7 @@ All convenience methods create properly structured `ContentItem` objects:
|
||||
Based on the wiki structure, these related features are also supported:
|
||||
|
||||
1. **LOCAL_MUSIC**: ✅ Fully implemented
|
||||
2. **STORED_MUSIC**: ✅ Fully implemented
|
||||
2. **STORED_MUSIC**: ✅ Fully implemented
|
||||
3. **SPOTIFY**: ✅ Previously implemented
|
||||
4. **TUNEIN**: ✅ Previously implemented
|
||||
5. **BLUETOOTH**: ✅ Previously implemented
|
||||
@@ -169,7 +186,7 @@ err := client.SelectLocalInternetRadio(location, "", "My Station", "")
|
||||
// Direct ContentItem
|
||||
contentItem := &models.ContentItem{
|
||||
Source: "LOCAL_INTERNET_RADIO",
|
||||
Type: "stationurl",
|
||||
Type: "stationurl",
|
||||
Location: location,
|
||||
ItemName: "My Station",
|
||||
IsPresetable: true,
|
||||
@@ -195,8 +212,9 @@ soundtouch-cli --host 192.168.1.100 source internet-radio \
|
||||
- [SoundTouch WebServices API Wiki](https://github.com/thlucas1/homeassistantcomponent_soundtouchplus/wiki/SoundTouch-WebServices-API)
|
||||
- [LOCAL_INTERNET_RADIO - streamUrl format](https://github.com/thlucas1/homeassistantcomponent_soundtouchplus/wiki/SoundTouch-WebServices-API#select-local_internet_radio---streamurl-format)
|
||||
- [LOCAL_MUSIC](https://github.com/thlucas1/homeassistantcomponent_soundtouchplus/wiki/SoundTouch-WebServices-API#select-local_music)
|
||||
- [Content Selection Example](/examples/content-selection/)
|
||||
- [CLI Reference](/docs/CLI-REFERENCE.md)
|
||||
- [Content Selection Example](../examples/content-selection/README.md)
|
||||
- [CLI Reference](guides/CLI-REFERENCE.md)
|
||||
- [Content Selection Example (Direct)](../examples/content-selection/)
|
||||
|
||||
## ✅ Verification
|
||||
|
||||
@@ -208,4 +226,4 @@ This implementation has been verified to:
|
||||
5. ✅ Include complete documentation and examples
|
||||
6. ✅ Maintain backward compatibility
|
||||
|
||||
**Status**: 🎉 **COMPLETE** - All requested content selection features are fully implemented and ready for use!
|
||||
**Status**: 🎉 **COMPLETE** - All requested content selection features are fully implemented and ready for use!
|
||||
|
||||
@@ -0,0 +1,107 @@
|
||||
# Device Logging & Troubleshooting
|
||||
|
||||
Accessing logs from SoundTouch devices is critical for debugging custom service integrations and understanding internal device behavior. This document outlines the methods for collecting logs, as discovered by the **SoundCork** and **ÜberBöse API** communities.
|
||||
|
||||
## Log Types
|
||||
|
||||
1. **System Logs**: Internal OS logs (Linux-based) including `dmesg`, `syslog`, and process-specific logs.
|
||||
2. **Traffic Logs**: Real-time HTTP/HTTPS requests sent by the device to cloud or local services.
|
||||
3. **Proxy Logs**: Logs generated by the `soundtouch-service` when it acts as a man-in-the-middle.
|
||||
|
||||
---
|
||||
|
||||
## 1. Accessing System Logs (Requires Root)
|
||||
|
||||
Most SoundTouch devices run a modified Linux distribution. Accessing these logs requires root SSH or Telnet access.
|
||||
|
||||
### Enabling Root Access (Remote Services)
|
||||
|
||||
Community research (SoundCork Issue #112) has identified a "backdoor" to enable developer services:
|
||||
|
||||
1. **USB Method**:
|
||||
- Format a USB stick to **FAT32**.
|
||||
- Create an empty file named `remote_services` (no extension) in the root of the USB stick.
|
||||
- Insert the stick into the SoundTouch device.
|
||||
- Reboot the device (power cycle).
|
||||
- On some models, you may need to hold **4** and **Volume -** on the device while powering on to force a USB check.
|
||||
2. **TAP Command (Legacy)**:
|
||||
- On older firmware versions, you can connect to port 17000 via Telnet and issue the command: `remote_services on`.
|
||||
|
||||
### Making Root Access Persistent
|
||||
Once you have logged in as `root` (usually no password or a well-known community password), you can make the access survive reboots without the USB stick:
|
||||
```bash
|
||||
touch /mnt/nv/remote_services
|
||||
/etc/init.d/sshd start
|
||||
```
|
||||
|
||||
### Viewing Logs
|
||||
Once inside via SSH:
|
||||
- **Kernel Logs**: `dmesg`
|
||||
- **System Logs**: `cat /var/log/messages` or `tail -f /tmp/soundtouch.log` (paths vary by firmware).
|
||||
- **Real-time Monitoring**: `logread -f`
|
||||
- **Process List**: `ps w`
|
||||
|
||||
#### Pro-Tip: Filtered Real-time Monitoring
|
||||
To focus on cloud service and preset interactions (Marge), use the following command on the device:
|
||||
```bash
|
||||
logread -f | grep -Ei '(marge|preset)'
|
||||
```
|
||||
This is particularly useful for debugging preset synchronization and service redirection issues.
|
||||
|
||||
---
|
||||
|
||||
## 2. Traffic Logging & Interception
|
||||
|
||||
If you cannot or do not want to root the device, you can monitor its outbound traffic by redirecting it to a proxy.
|
||||
|
||||
### Via `soundtouch-service`
|
||||
The `soundtouch-service` included in this repository includes a built-in proxy. When a device is migrated to use this service, all of its cloud-bound traffic is logged to the service console.
|
||||
|
||||
**Key Traffic to Monitor**:
|
||||
- `POST /v1/scmudc/{deviceId}`: Real-time telemetry events.
|
||||
- `GET /marge/...`: Account and streaming configuration requests.
|
||||
- `POST /streaming/support/power_on`: Boot-time diagnostics.
|
||||
|
||||
### Via Packet Sniffing (Advanced)
|
||||
If you have a managed switch or a router capable of port mirroring, you can use **Wireshark** or `tcpdump` to capture traffic.
|
||||
- **Filter**: `tcp port 80 or tcp port 443`
|
||||
- **Target**: The IP address of your SoundTouch device.
|
||||
|
||||
---
|
||||
|
||||
## 3. Troubleshooting Common Issues
|
||||
|
||||
### "IsItBose" Validation Failures
|
||||
If the device fails to connect to your custom service despite correct configuration, it may be failing the internal `IsItBose` regex check.
|
||||
- **Evidence**: Look for SSL handshake failures or "Unauthorized" errors in your service logs.
|
||||
- **Solution**: See the [Binary Patching section in DEVICE-REDIRECT-METHODS.md](analysis/DEVICE-REDIRECT-METHODS.md#method-3-binary-patching).
|
||||
|
||||
### Disappearing Sources (TuneIn/Local Radio)
|
||||
If `TUNEIN` or `LOCAL_INTERNET_RADIO` sources disappear after a reboot in an offline environment.
|
||||
- **Cause**: These sources are validated against the cloud only during the initial boot sequence.
|
||||
- **Solution**: Ensure your emulated service is reachable and responding correctly to `/streaming/support/power_on` and `/streaming/sourceproviders` during the device's boot-up.
|
||||
|
||||
---
|
||||
|
||||
## 4. HTTP Protocol Quirks
|
||||
|
||||
### ETag Case-Sensitivity
|
||||
Research in **SoundCork Issue #129** revealed a significant bug in the SoundTouch device firmware regarding HTTP `ETag` headers.
|
||||
|
||||
- **The Issue**: The device firmware expects the `ETag` header to be exactly title-cased (`ETag`). Many modern web servers or frameworks (like FastAPI/Uvicorn) return headers in all lowercase (`etag`) per HTTP/2 or standard case-insensitive conventions.
|
||||
- **The Symptom**: If the server returns a lowercase `etag`, the device fails to recognize it. Consequently, the device will never send an `If-None-Match` header in subsequent requests, breaking preset synchronization and efficient caching.
|
||||
- **The Workaround**: If you are using a custom service, you may need to use a reverse proxy (like **Nginx**) or a middleware to force the header casing to `ETag`.
|
||||
|
||||
**Example Nginx Fix**:
|
||||
```nginx
|
||||
proxy_hide_header etag;
|
||||
add_header ETag $upstream_http_etag;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
- [SoundCork Issue #112: Enabling Remote Services](https://github.com/deborahgu/soundcork/issues/112)
|
||||
- [SoundCork Issue #149: Debugging with Systemd/Gunicorn](https://github.com/deborahgu/soundcork/issues/149)
|
||||
- [ÜberBöse API: Telemetry Documentation](https://github.com/julius-d/ueberboese-api)
|
||||
- [SoundCork Issue #129: ETag Case-Sensitivity & Preset Sync](https://github.com/deborahgu/soundcork/issues/129)
|
||||
@@ -895,4 +895,4 @@ For additional help:
|
||||
|
||||
---
|
||||
|
||||
*This guide covers the complete navigation and station management functionality. For preset management, see [PRESET-MANAGEMENT.md](PRESET-MANAGEMENT.md).*
|
||||
*This guide covers the complete navigation and station management functionality. For preset management, see [PRESET-MANAGEMENT.md](reference/PRESET-MANAGEMENT.md).*
|
||||
|
||||
@@ -0,0 +1,88 @@
|
||||
### Overview of Recent Improvements and Next Steps
|
||||
|
||||
This document summarizes the improvements made to the **Marge service** to improve parity with the upstream Bose SoundTouch service, along with open issues and proposed next steps.
|
||||
|
||||
#### ✅ Completed Improvements (Marge Service)
|
||||
* **Mapped Preset `buttonNumber`**: Correctly mapped the internal `ServicePreset.ID` or `ButtonNumber` to the `buttonNumber` XML attribute in the `/full` response and ensured it is persisted in the local datastore.
|
||||
* **High-Fidelity Device Metadata**: Improved the datastore to correctly extract, persist, and report detailed device `<components>` (e.g., `LIGHTSWITCH`, `SMSC`) and their firmware versions from upstream responses.
|
||||
* **Standardized Preferred Language**: Updated the default `preferredLanguage` to `de` in the `/full` response and added synchronization to persist it from upstream responses.
|
||||
* **Persisted Provider Settings**: Added support for persisting and echoing back `providerSettings` (e.g., `STREAMING_QUALITY`, `ELIGIBLE_FOR_TRIAL`) from the `/full` response.
|
||||
* **Populated `contentItemType`**: The `contentItemType` (e.g., `tracklisturl`) is now correctly synchronized from upstream, persisted in the local datastore, and returned in the `/full` response for both presets and recents.
|
||||
* **Standardized Credential Types**: Adjusted the logic for Spotify to use the correct `token_version_3` type when a token is present in the `/full` response, improving parity with the upstream service. The service now respects existing `credential_type` values from `Sources.xml` (e.g., `token_version_3` for Spotify) while providing sensible defaults for new or incomplete sources.
|
||||
* **Structured Sources (Sources.xml)**: Refactored `Sources.xml` to use an attribute-based structure (`sourceid`, `source`, `status`, `sourceAccount`, etc.) matching the real device's output. Removed redundant nested tags like `<sourcename>`, `<username>`, and `<name>`.
|
||||
* **Nested Recents (Recents.xml)**: Implemented a nested `<contentItem>` structure within `<recent>` entries in `Recents.xml`, maintaining exact parity with the device's persistence format while supporting legacy flat formats for backward compatibility.
|
||||
* **Inconsistent `serialNumber` Casing**: Fixed the casing mismatch in the `/full` response where the upstream uses camelCase `<serialNumber>` in the top-level `<device>` and lowercase `<serialnumber>` in the nested `<attachedProduct>`. Local responses now correctly mirror this inconsistency.
|
||||
* **Attribute-level Parity**:
|
||||
* Ensured `sourceAccount=""` is preserved in XML even when empty, matching device behavior for sources like TUNEIN.
|
||||
* Fixed casing for attributes like `deviceID` and `utcTime` in `Recents.xml`.
|
||||
* Correctly mapped and persisted preset and recent `id` attributes during "Initial Data Sync".
|
||||
* **Device Name Consistency**: Fixed an issue where the device `<name>` was empty in some local `/full` responses by ensuring it is correctly populated from the datastore and synchronized from upstream.
|
||||
* **Improved XML Parity**: Empty `<name>` tags in the `/full` response are now self-closing (`<name/>`), matching upstream behavior.
|
||||
* **Timestamp-based ID Generation**: Implemented a 9-digit ID schema (`YYMMDD` + 3-digit counter) for `recent` items, ensuring IDs are large, unique, and stay within the 32-bit integer range.
|
||||
* **Automatic Source Learning**: The service now extracts and persists full metadata (credentials, provider IDs, and custom names) from incoming `POST /recent` requests. This improves parity for subsequent `GET /recents` calls.
|
||||
* **Source Provider Mapping**: Synchronized local source provider IDs and timestamps with upstream data. The `RADIO_BROWSER` provider is included in the public `/streaming/sourceproviders` list to maintain internal functionality while acknowledging it as a parity gap.
|
||||
* **Credential Preservation**: Improved `AddRecent` to correctly extract and echo back base64 tokens/credentials provided in the incoming request, improving source learning.
|
||||
* **XML Formatting Parity**:
|
||||
* Added `standalone="yes"` to the XML declaration for all Marge responses, including `recent`, `presets`, `full account`, `software update`, and `sourceproviders`.
|
||||
* Enforced self-closing `<sourceSettings/>` tags for parity.
|
||||
* Standardized date formatting to UTC with milliseconds (`.000+00:00`).
|
||||
* Fixed casing for `/streaming/sourceproviders`: Root element is `<sourceProviders>`, but child elements are `<sourceprovider>` (all lowercase), matching upstream behavior.
|
||||
* Implemented structured XML marshaling with consistent 2-space indentation for recents and source providers.
|
||||
* **Improved TuneIn Parity**: Fixed TuneIn source mapping to use ID `25` and ensuring `sourcename` is empty in responses, matching upstream behavior for station playback.
|
||||
* **High-Fidelity Full Account Sync**: Refactored the `/streaming/account/{accountId}/full` response to match the upstream structure. This includes:
|
||||
* **Mapped Preset `buttonNumber`**: Correctly mapped the internal `ServicePreset.ID` to the `buttonNumber` XML attribute in the `/full` response.
|
||||
* **Structured XML Marshaling**: Replaced manual string concatenation with structured Go models and `xml.Marshal` for the entire response.
|
||||
* **Specific Response Models**: Introduced `FullResponseSource`, `FullResponsePreset`, and `FullResponseRecent` to accurately reflect the upstream structure where `<source>` is a child element, rather than a set of attributes.
|
||||
* **Correct Nesting**: Ensured that `<presets>` and `<recents>` correctly nest their associated `<source>` details, resolving previous data omissions.
|
||||
* **Device Identity**: Added `<serialNumber>` and `<updatedOn>` to both the top-level `<device>` and its `<attachedProduct>`, ensuring consistent device identification.
|
||||
* **Field-Level Parity**: Mapped missing fields like `<contentItemType>` and `<productlabel>` to match upstream expectations.
|
||||
* **Improved Source Matching**: Enhanced internal logic to correctly link presets and recents to their configured sources based on multiple identifiers (ID, Key, or Type).
|
||||
* **Verified Parity Mismatch Fixes**: Comprehensive reproduction tests (`TestParityMismatchReproduction_V2` and `TestParityMismatchReproduction_V3`) now confirm parity for identified mismatches in `POST /recent` and `GET /recents`, including credentials and source-specific metadata.
|
||||
* **Unified Response Logic**: Refactored the code so that both `POST /recent` and `GET /recents` use the same formatting functions, guaranteeing consistency.
|
||||
* **Robust Parity Detection**: Updated the local parity checker to be whitespace-insensitive for XML bodies, significantly reducing noise from minor indentation or newline differences.
|
||||
* **Maintainable XML Generation**: Reduced cyclomatic complexity and code duplication in `marge.go` by extracting focused helper functions for mapping internal data to response-specific XML models.
|
||||
|
||||
---
|
||||
|
||||
#### 🛠️ Open Issues and Next Steps
|
||||
|
||||
Based on the latest `parity_mismatches` and the high-fidelity `/full` account response comparison (diff14), here are the recommended areas for further work:
|
||||
|
||||
#### 1. BMX / TuneIn Playback Parity (Medium)
|
||||
Current mismatches in `/bmx/tunein/v1/playback/station/...` show differences in reporting URLs and missing links:
|
||||
* **Mismatched Parameters**: Local reporting URLs use `listen_id=1234567890`, while upstream uses a different session-based ID.
|
||||
* **Missing Links**: Some upstream responses include additional `_links` or metadata that are currently omitted in local responses.
|
||||
* **Action**: Improve the `HandleTuneInPlayback` logic to better mirror the upstream response structure and parameter generation.
|
||||
|
||||
#### 2. `/full` Account Response Data Gaps (Medium)
|
||||
While structural parity for the `/full` response is high, several value-level gaps remain as shown in `diff14`:
|
||||
* **Timestamp Formats**: Upstream uses ISO-8601 with milliseconds (e.g., `2024-06-23T07:40:36.000+00:00`), whereas some local fields still use Unix epoch integers (e.g., `1234567890`).
|
||||
* **Provider Settings**: The `providerSettings` block in the local response currently lacks crucial values like `keyName`, `providerId`, and `boseId` (appearing as empty tags).
|
||||
* **Component Metadata**: Local component types are sometimes empty (`type=""`) compared to upstream values like `LIGHTSWITCH` or `SMSC`.
|
||||
* **Source/Preset Identifiers**: Local IDs (e.g., `100004`) differ from upstream IDs (e.g., `1234567`), though this may be expected due to different account/device environments.
|
||||
* **Action**: Update the mapping logic in `marge.go` and `setup.go` to ensure all fields in the `/full` response are correctly populated with high-fidelity values and standard ISO-8601 timestamps.
|
||||
|
||||
#### 3. OAuth / Spotify Token Noise (Low/Medium)
|
||||
The `/oauth/device/.../token` endpoint frequently reports mismatches because tokens are naturally different between local and upstream.
|
||||
* **The Issue**: This creates "noise" in your parity reports that isn't actually a bug.
|
||||
* **Action**: Update the parity detection logic (or the handler) to selectively ignore the `access_token` field while still verifying that the rest of the JSON structure (expires_in, scope, token_type) matches.
|
||||
|
||||
#### 4. Large IDs for Other Models (Medium)
|
||||
While we fixed IDs for `recents`, other models like `presets` or `sources` might still use small auto-incrementing integers.
|
||||
* **Action**: Evaluate if other endpoints should also transition to the timestamp-based ID schema to further reduce diff noise.
|
||||
|
||||
#### 5. Improved Data Persistence (Continuous)
|
||||
Continue the "learning" approach for other services. For example, if we see a new `sourceproviderid` in a Spotify or TuneIn request, we should ensure it is stored and reused.
|
||||
|
||||
#### 6. Local Reboot & Device State Management (Continuous)
|
||||
Analysis of device reboot logs revealed several data requirements:
|
||||
* **Power-On Details Tracking**: Implemented extraction and persistence of detailed device information (serial numbers, firmware version, product details, and MAC addresses) from the `POST /streaming/support/power_on` request. This data is now stored in the local datastore, improving our ability to respond accurately to subsequent management requests.
|
||||
* **Source Provider Mapping**: Synchronized local source provider IDs and timestamps with upstream data. The `RADIO_BROWSER` provider is included in the public `/streaming/sourceproviders` list to maintain internal functionality while acknowledging it as a parity gap.
|
||||
|
||||
#### 7. Account Full Response (/full) Structural & Value Parity (Completed)
|
||||
Structural and value gaps in the `/full` account response have been addressed:
|
||||
|
||||
**Key Fixes:**
|
||||
* **Structural**:
|
||||
* **Nested Source Association**: Improved the matching logic in `mapRecentsToFullResponse` to correctly link recents to their specific `ConfiguredSource` (e.g., by matching `sourceid` attribute).
|
||||
* **XML Tag Formatting**: Standardized self-closing tags and element formatting to match upstream's multi-line or empty-element formatting in various contexts.
|
||||
@@ -0,0 +1,41 @@
|
||||
# Parity Analysis: Bose-SoundTouch (Go) vs. SoundCork (Python)
|
||||
|
||||
This document provides a comparative analysis of the current Go implementation and the `deborahgu/soundcork` project, identifying functional gaps and potential improvements.
|
||||
|
||||
## 1. Core Architecture and Language
|
||||
- **Bose-SoundTouch (Go)**: Uses `chi` for routing and `encoding/xml` for data. High performance, strong typing, and precise MIME type handling (`application/vnd.bose.streaming-v1.2+xml`).
|
||||
- **SoundCork (Python)**: Uses `FastAPI` and `xml.etree.ElementTree`. Prioritizes flexibility and rapid prototyping of streaming service mocks.
|
||||
|
||||
## 2. Functional Comparison
|
||||
|
||||
| Feature | Bose-SoundTouch (Go) | SoundCork (Python) |
|
||||
|:---------------------|:-------------------------------------------------|:----------------------------------------------------------------------------------------|
|
||||
| **Group Management** | Placeholder handlers (return `<group/>` or 404). | Active group management (`groups.py`), supporting `/addGroup` and stereo pairing logic. |
|
||||
| **BMX Services** | Supports TuneIn, Orion, and custom streams. | More modular `bmx_services.json` registry with broader mock support. |
|
||||
| **Persistence** | Mixed JSON/XML datastore. | Pure XML-based persistence per device/account. |
|
||||
| **Admin UI** | CLI-based (`soundtouch-cli`) or API-driven. | Draft Web UI for device discovery and account management (`admin.py`). |
|
||||
| **Discovery** | Integrated setup tools and SSDP/MDNS awareness. | Leverages `bosesoundtouchapi` Python library for active discovery. |
|
||||
|
||||
## 3. Key Strengths of SoundCork
|
||||
- **Group Pairing Logic**: Includes logic to manage master/slave relationships for SoundTouch 10 stereo pairs.
|
||||
- **Service Extensibility**: JSON-based registry for BMX services makes it easier to mock multiple providers (SiriusXM, Spotify) without code changes.
|
||||
- **Mock Coverage**: Better coverage of "dummy" endpoints that respond with plausible XML (e.g., `customerSupport`).
|
||||
|
||||
## 4. Suggested Implementation Steps for Bose-SoundTouch
|
||||
|
||||
### A. Implement Full Group Support (High Priority)
|
||||
- Add logic to `pkg/service/marge` to handle `/addGroup` and `/updateGroup`.
|
||||
- Persist group memberships in the datastore to allow speakers to function as stereo pairs or multi-room zones.
|
||||
|
||||
### B. Modularize BMX Registry (Medium Priority)
|
||||
- Extract the hardcoded service list in `HandleBMXRegistry` into an external `bmx-services.json` file.
|
||||
- Allow users to customize which mocked services are advertised to the speaker.
|
||||
|
||||
### C. Enhanced Source Management (Medium Priority)
|
||||
- Refine source learning logic to ensure all `sourceAccount` and `sourceName` metadata is correctly captured during synchronization, using patterns from `soundcork`'s `learnSource`.
|
||||
|
||||
### D. Basic Admin Web UI (Low Priority)
|
||||
- Develop a minimal internal status page to list active accounts and connected devices, improving usability over raw API calls.
|
||||
|
||||
## 5. Summary
|
||||
While our Go implementation is structurally more consistent with recent reference recordings (e.g., `buttonNumber`, detailed `components`), SoundCork provides better coverage of multi-device coordination (Groups) and service emulation (BMX) that we should adopt for a more complete offline experience.
|
||||
@@ -332,14 +332,14 @@ soundtouch-cli --host 192.168.1.100 info
|
||||
|
||||
## Next Steps
|
||||
|
||||
- 📖 [Complete CLI Reference](CLI-REFERENCE.md)
|
||||
- 🔧 [Full Implementation Guide](preset-store.md)
|
||||
- 📡 [WebSocket Events Documentation](websocket-events.md)
|
||||
- 📖 [Complete CLI Reference](guides/CLI-REFERENCE.md)
|
||||
- 🔧 [Full Implementation Guide](reference/PRESET-MANAGEMENT.md)
|
||||
- 📡 [WebSocket Events Documentation](reference/WEBSOCKET-EVENTS.md)
|
||||
- 💻 [Preset Management Example](../examples/preset-management/)
|
||||
- 📚 [API Endpoints Overview](API-Endpoints-Overview.md)
|
||||
- 📚 [API Endpoints Overview](reference/API-ENDPOINTS.md)
|
||||
|
||||
## Need Help?
|
||||
|
||||
- 🐛 **Bug Reports**: [Create an issue](https://github.com/gesellix/bose-soundtouch/issues)
|
||||
- 💡 **Feature Requests**: [Start a discussion](https://github.com/gesellix/bose-soundtouch/discussions)
|
||||
- ❓ **Questions**: [Browse discussions](https://github.com/gesellix/bose-soundtouch/discussions)
|
||||
- ❓ **Questions**: [Browse discussions](https://github.com/gesellix/bose-soundtouch/discussions)
|
||||
|
||||
@@ -0,0 +1,89 @@
|
||||
# Bose SoundTouch Toolkit Documentation
|
||||
|
||||
Welcome to the documentation for the Bose SoundTouch Toolkit. This comprehensive toolkit helps you keep your Bose SoundTouch speakers functional even after the Bose Cloud shutdown in May 2026, with enhanced local management and monitoring capabilities.
|
||||
|
||||
## 🚀 Start Here
|
||||
|
||||
### For New Users
|
||||
- **[Complete Migration Guide](guides/MIGRATION-GUIDE.md)** - Step-by-step guide from Bose Cloud to local control
|
||||
- **[Getting Started](guides/GETTING-STARTED.md)** - Quick introduction to the toolkit
|
||||
|
||||
### For Existing Users
|
||||
- **[Cloud Shutdown Survival Guide](guides/SURVIVAL-GUIDE.md)** - Prepare for the May 2026 shutdown
|
||||
- **[SoundTouch Service Guide](guides/SOUNDTOUCH-SERVICE.md)** - Advanced service configuration
|
||||
|
||||
## 📋 Essential Documentation
|
||||
|
||||
The documentation is organized into three main categories:
|
||||
|
||||
### 1. **User Guides** - For everyday users migrating and managing devices
|
||||
### 2. **Technical Reference** - For developers and advanced configuration
|
||||
### 3. **Concept Documentation** - For contributors and system architects
|
||||
|
||||
## 🗂 Documentation Structure
|
||||
|
||||
## 🗂 User Guides
|
||||
|
||||
### Migration & Setup
|
||||
- **[Complete Migration Guide](guides/MIGRATION-GUIDE.md)** - 📖 **Main guide** for migrating from Bose Cloud
|
||||
- [Cloud Shutdown Survival Guide](guides/SURVIVAL-GUIDE.md) - Prepare for service shutdown
|
||||
- [Migration & Safety Guide](guides/MIGRATION-SAFETY.md) - Advanced migration strategies
|
||||
- [Initial Device Setup](guides/DEVICE-INITIAL-SETUP.md) - First-time device configuration
|
||||
- [Raspberry Pi Setup](guides/RASPBERRY-PI.md) - Installing on Raspberry Pi
|
||||
|
||||
### Daily Management
|
||||
- [SoundTouch Service Guide](guides/SOUNDTOUCH-SERVICE.md) - Service operation and maintenance
|
||||
- [Troubleshooting](guides/TROUBLESHOOTING.md) - Common issues and solutions
|
||||
- [HTTPS Setup](guides/HTTPS-SETUP.md) - Secure connections
|
||||
- [Deployment Guide](guides/DEPLOYMENT.md) - Production deployments
|
||||
|
||||
### Advanced Features
|
||||
- [MAC Address Mapping](guides/MAC-ADDRESS-MAPPING.md) - Device identification
|
||||
- [CLI Reference](guides/CLI-REFERENCE.md) - Command-line tools
|
||||
- [IoT Implementation Guide](guides/IOT-IMPLEMENTATION-GUIDE.md) - IoT integrations
|
||||
- [MQTT Integration Design](guides/MQTT-INTEGRATION-DESIGN.md) - MQTT setup
|
||||
|
||||
## 📚 Technical Reference
|
||||
|
||||
### API Documentation
|
||||
- [API Endpoints](reference/API-ENDPOINTS.md) - REST API reference
|
||||
- [WebSocket Events](reference/WEBSOCKET-EVENTS.md) - Real-time events
|
||||
- [Zone Management](reference/ZONE-MANAGEMENT.md) - Multi-room control
|
||||
- [Preset Management](reference/PRESET-MANAGEMENT.md) - Preset operations
|
||||
|
||||
### Analysis & Research
|
||||
- [Upstream URLs](analysis/UPSTREAM-URLS.md) - Bose service endpoints
|
||||
- [Device Redirect Methods](analysis/DEVICE-REDIRECT-METHODS.md) - Migration techniques
|
||||
- [IoT Configuration Analysis](analysis/IOT-CONFIGURATION-ANALYSIS.md) - Device configurations
|
||||
- [IoT Config Summary](analysis/IOT-CONFIG-SUMMARY.md) - Configuration summaries
|
||||
|
||||
### Device Lifecycle & Network Independence
|
||||
- **[Device Lifecycle and /power_on Enhancement](device-lifecycle-and-power-on-enhancement.md)** - Complete analysis of device registration and network independence improvements
|
||||
- [/power_on Implementation Guide](power-on-implementation-guide.md) - Technical implementation details for enhanced device management
|
||||
|
||||
## 🏗 Concept Documentation
|
||||
|
||||
### Enhanced Service Architecture
|
||||
- **[Concept Overview](concepts/README.md)** - High-level architecture vision
|
||||
- [Upstream Service Simulation](concepts/upstream-service-simulation.md) - Complete concept design
|
||||
- [Implementation Plan](concepts/implementation-plan.md) - Development roadmap
|
||||
- [Technical Specification](concepts/technical-specification.md) - Detailed specifications
|
||||
|
||||
### Development Planning
|
||||
- [Implementation Roadmap](concepts/implementation-roadmap.md) - Project phases and milestones
|
||||
|
||||
## 💡 Quick Reference
|
||||
|
||||
### Common Tasks
|
||||
- **Migrate first device**: Follow [Migration Guide Step 5](guides/MIGRATION-GUIDE.md#step-5-migrate-individual-devices)
|
||||
- **Check device health**: Dashboard → Devices → [Device Name] → Health Status
|
||||
- **Backup configuration**: Dashboard → Settings → Backup → Create Backup
|
||||
- **Add new device**: Dashboard → Devices → Discover Devices → Register
|
||||
|
||||
### Getting Help
|
||||
- **Issues & Bugs**: [GitHub Issues](https://github.com/gesellix/Bose-SoundTouch/issues)
|
||||
- **Questions & Discussion**: [GitHub Discussions](https://github.com/gesellix/Bose-SoundTouch/discussions)
|
||||
- **Documentation**: Check troubleshooting guides first
|
||||
- **Community**: Share experiences and help others
|
||||
|
||||
For a complete list of all documents, see the [Summary](SUMMARY.md).
|
||||
@@ -0,0 +1,345 @@
|
||||
# Request Recording Concept
|
||||
|
||||
## Problem Statement
|
||||
|
||||
The current request recording system has fundamental issues when dealing with request cloning, body consumption, and multiple response scenarios. Specifically:
|
||||
|
||||
1. **Body Consumption**: HTTP request bodies can only be read once, leading to missing bodies in recordings
|
||||
2. **Request Cloning**: A single original request may be cloned multiple times for different purposes (local handling, mirroring, recording)
|
||||
3. **Multiple Responses**: The same logical request may generate different responses (local vs upstream mirror)
|
||||
4. **Data Integrity**: No guarantee that recorded requests are identical across different execution paths
|
||||
|
||||
## Current Issues (Examples)
|
||||
|
||||
### Issue 1: Missing Request Bodies in Mirror Recordings
|
||||
|
||||
**Local Recording** (complete):
|
||||
```http
|
||||
### POST /v1/scmudc/A81B6A536A98
|
||||
POST /v1/scmudc/A81B6A536A98
|
||||
Host: events.api.bosecm.com
|
||||
Content-Type: text/json; charset=utf-8
|
||||
Content-Length: 587
|
||||
Authorization: Bearer jGwEmFWr...
|
||||
|
||||
{"envelope":{"monoTime":234906,"payloadProtocolVersion":"3.1","payloadType":"scmudc","protocolVersion":"1.0","time":"2026-02-25T23:03:14.976349+00:00","uniqueId":"A81B6A536A98"},"payload":{"deviceInfo":{"boseID":"3230304","deviceID":"A81B6A536A98","deviceType":"SoundTouch 10","serialNumber":"I6332527703739342000020","softwareVersion":"27.0.6.46330.5043500 epdbuild.trunk.hepdswbld04.2022-08-04T11:20:29","systemSerialNumber":"069231P63364828AE"},"events":[{"data":{"play-state":"PAUSE_STATE"},"monoTime":234904,"time":"2026-02-25T23:03:14.973466+00:00","type":"play-state-changed"}]}}
|
||||
|
||||
{% raw %}
|
||||
> {%
|
||||
// Response: 200 OK
|
||||
%}
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
**Mirror Recording** (missing body):
|
||||
```http
|
||||
### POST /v1/scmudc/A81B6A536A98
|
||||
POST /v1/scmudc/A81B6A536A98
|
||||
Host: events.api.bosecm.com
|
||||
Content-Type: text/json; charset=utf-8
|
||||
Content-Length: 587
|
||||
Authorization: Bearer jGwEmFWr...
|
||||
|
||||
|
||||
|
||||
{% raw %}
|
||||
> {%
|
||||
// Response: 200 OK
|
||||
// Headers:
|
||||
// X-Proxy-Origin: upstream-mirror
|
||||
%}
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
### Issue 2: Request Flow Complexity
|
||||
|
||||
Current middleware execution order:
|
||||
```
|
||||
1. MirrorMiddleware - Buffers body, creates clones
|
||||
2. RecordMiddleware - Also buffers body
|
||||
3. Application Handler - Processes request
|
||||
4. Mirror Execution - Async/sync mirror to upstream
|
||||
5. Recording - Multiple recording points
|
||||
```
|
||||
|
||||
Problems:
|
||||
- Multiple body reads across middleware chain
|
||||
- Inconsistent request state between clones
|
||||
- Race conditions in async scenarios
|
||||
- No guarantee of request equivalence
|
||||
|
||||
## Proposed Solution: Context-Bound Request Snapshots
|
||||
|
||||
### Core Concept
|
||||
|
||||
Create **immutable request snapshots** early in the request lifecycle and propagate them through the **Request Context**. This ensures all downstream consumers (Mirroring, Recording, Parity Check) use identical data without re-reading the request body.
|
||||
|
||||
### Architecture (Context-Only)
|
||||
|
||||
```
|
||||
┌─────────────────┐
|
||||
│ Original Request│
|
||||
└─────────┬───────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────┐ ┌──────────────────┐
|
||||
│ Snapshot Creator│───▶│ Request Context │
|
||||
│ (Middleware) │ │ (Pointer-based) │
|
||||
└─────────┬───────┘ └──────────────────┘
|
||||
│ │
|
||||
▼ │ (Safe for async)
|
||||
┌─────────────────┐ │
|
||||
│ Middleware │◀─────────────┘
|
||||
│ Chain │
|
||||
└─────────┬───────┘
|
||||
│
|
||||
┌───▼────┐ ┌─────────┐ ┌──────────────┐
|
||||
│ Local │ │ Mirror │ │ Recording │
|
||||
│Handler │ │Execution│ │ System │
|
||||
└────────┘ └─────────┘ └──────────────┘
|
||||
```
|
||||
|
||||
### Request Snapshot Structure
|
||||
|
||||
```go
|
||||
type RequestSnapshot struct {
|
||||
Method string
|
||||
URL *url.URL
|
||||
Headers http.Header
|
||||
Body []byte
|
||||
Host string
|
||||
Timestamp time.Time
|
||||
}
|
||||
|
||||
// Typed key for context safety
|
||||
type contextKey struct{ name string }
|
||||
var SnapshotKey = &contextKey{"request_snapshot"}
|
||||
```
|
||||
|
||||
### Implementation Strategy
|
||||
|
||||
#### Phase 1: Snapshot Middleware
|
||||
|
||||
```go
|
||||
func (s *Server) SnapshotMiddleware(next http.Handler) http.Handler {
|
||||
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
|
||||
// 1. Capture body once with size limit (e.g. 2MB)
|
||||
body, _ := io.ReadAll(io.LimitReader(r.Body, 2*1024*1024))
|
||||
r.Body.Close()
|
||||
|
||||
// 2. Create snapshot
|
||||
snapshot := &RequestSnapshot{
|
||||
Method: r.Method,
|
||||
URL: cloneURL(r.URL),
|
||||
Headers: r.Header.Clone(),
|
||||
Body: body,
|
||||
Host: r.Host,
|
||||
Timestamp: time.Now(),
|
||||
}
|
||||
|
||||
// 3. Inject pointer into context
|
||||
ctx := context.WithValue(r.Context(), SnapshotKey, snapshot)
|
||||
|
||||
// 4. Restore r.Body for downstream compatibility
|
||||
r = r.WithContext(ctx)
|
||||
r.Body = io.NopCloser(bytes.NewReader(snapshot.Body))
|
||||
|
||||
next.ServeHTTP(w, r)
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
#### Phase 2: Downstream Consumption
|
||||
|
||||
Consumers (Mirror/Record) retrieve the snapshot directly from context:
|
||||
|
||||
```go
|
||||
snapshot, ok := r.Context().Value(SnapshotKey).(*RequestSnapshot)
|
||||
if ok {
|
||||
// Use snapshot.Body directly instead of io.ReadAll(r.Body)
|
||||
}
|
||||
```
|
||||
|
||||
## Hardware Considerations (Raspberry Pi Zero 2W)
|
||||
|
||||
To protect MicroSD health and optimize for limited memory:
|
||||
|
||||
1. **No Intermediate Disk Storage**: Snapshots exist only in memory; they are never written to disk until the final `.http` recording is generated.
|
||||
2. **Memory Management**: Use `sync.Pool` for temporary buffers to reduce GC churn on the single-core/low-memory SoC.
|
||||
3. **Automatic Cleanup**: Snapshots are naturally garbage collected once the Request Context and all child goroutines (detached mirrors/recordings) finish.
|
||||
4. **Body Capping**: Strict limits on snapshot size prevent OOM (Out-of-Memory) conditions.
|
||||
|
||||
#### Phase 2: Response Capture System
|
||||
|
||||
```go
|
||||
type ResponseRecorder struct {
|
||||
http.ResponseWriter
|
||||
snapshot *ResponseSnapshot
|
||||
snapshotID string
|
||||
source string
|
||||
startTime time.Time
|
||||
}
|
||||
|
||||
func (r *ResponseRecorder) WriteHeader(statusCode int) {
|
||||
r.snapshot.StatusCode = statusCode
|
||||
r.snapshot.Headers = r.Header().Clone()
|
||||
r.ResponseWriter.WriteHeader(statusCode)
|
||||
}
|
||||
|
||||
func (r *ResponseRecorder) Write(data []byte) (int, error) {
|
||||
r.snapshot.Body = append(r.snapshot.Body, data...)
|
||||
return r.ResponseWriter.Write(data)
|
||||
}
|
||||
|
||||
func (r *ResponseRecorder) finalize() {
|
||||
r.snapshot.Duration = time.Since(r.startTime)
|
||||
r.snapshot.Timestamp = time.Now()
|
||||
}
|
||||
```
|
||||
|
||||
#### Phase 3: Recording System Integration
|
||||
|
||||
```go
|
||||
type RecordingManager struct {
|
||||
storage SnapshotStorage
|
||||
recorder *Recorder
|
||||
patterns []string
|
||||
}
|
||||
|
||||
func (rm *RecordingManager) RecordInteraction(snapshotID string, response *ResponseSnapshot) {
|
||||
// Retrieve immutable request snapshot
|
||||
request, exists := rm.storage.Get(snapshotID)
|
||||
if !exists {
|
||||
log.Printf("Request snapshot not found: %s", snapshotID)
|
||||
return
|
||||
}
|
||||
|
||||
// Record with guaranteed data integrity
|
||||
rm.recorder.RecordInteraction(request, response)
|
||||
}
|
||||
|
||||
func (r *Recorder) RecordInteraction(req *RequestSnapshot, res *ResponseSnapshot) error {
|
||||
// Generate .http file with complete data
|
||||
var buf bytes.Buffer
|
||||
|
||||
// Write request
|
||||
fmt.Fprintf(&buf, "### %s %s\n", req.Method, req.URL.String())
|
||||
fmt.Fprintf(&buf, "%s %s\n", req.Method, req.URL.String())
|
||||
fmt.Fprintf(&buf, "Host: %s\n", req.Host)
|
||||
|
||||
for k, vv := range req.Headers {
|
||||
for _, v := range vv {
|
||||
fmt.Fprintf(&buf, "%s: %s\n", k, v)
|
||||
}
|
||||
}
|
||||
|
||||
buf.WriteString("\n")
|
||||
buf.Write(req.Body)
|
||||
buf.WriteString("\n\n")
|
||||
|
||||
// Write response
|
||||
{% raw %}
|
||||
buf.WriteString("> {% \n")
|
||||
{% endraw %}
|
||||
fmt.Fprintf(&buf, " // Response: %d %s\n", res.StatusCode, http.StatusText(res.StatusCode))
|
||||
buf.WriteString(" // Headers:\n")
|
||||
|
||||
for k, vv := range res.Headers {
|
||||
for _, v := range vv {
|
||||
fmt.Fprintf(&buf, " // %s: %s\n", k, v)
|
||||
}
|
||||
}
|
||||
|
||||
{% raw %}
|
||||
buf.WriteString("%}\n\n")
|
||||
{% endraw %}
|
||||
|
||||
if len(res.Body) > 0 {
|
||||
buf.WriteString("/*\n")
|
||||
buf.Write(res.Body)
|
||||
buf.WriteString("\n*/\n")
|
||||
} else {
|
||||
buf.WriteString("// [Binary response body: 0 bytes]\n")
|
||||
}
|
||||
|
||||
// Write to file
|
||||
return r.writeToFile(buf.Bytes(), req, res)
|
||||
}
|
||||
```
|
||||
|
||||
## Migration Strategy
|
||||
|
||||
### Phase 1: Introduce Snapshot System
|
||||
- Add SnapshotMiddleware as first middleware
|
||||
- Maintain existing recording system for compatibility
|
||||
- Gradual migration of recording points
|
||||
|
||||
### Phase 2: Update Mirror System
|
||||
- Modify MirrorMiddleware to use snapshots
|
||||
- Ensure mirror requests use snapshot data
|
||||
- Test parity between old and new systems
|
||||
|
||||
### Phase 3: Consolidate Recording
|
||||
- Replace existing recording middleware
|
||||
- Unified recording system using context-bound snapshots
|
||||
- Remove duplicate body reading code
|
||||
|
||||
### Phase 4: Cleanup
|
||||
- Remove legacy recording code
|
||||
- Optimize memory usage with sync.Pool
|
||||
- Performance validation on target hardware (Pi Zero)
|
||||
|
||||
## Benefits
|
||||
|
||||
1. **Zero Extra Disk IO**: Protecs MicroSD by avoiding snapshot disk persistence
|
||||
2. **Memory Efficiency**: Natural lifecycle tied to Request Context
|
||||
3. **Data Integrity**: Request data is captured once and remains immutable
|
||||
4. **Consistency**: All consumers use identical request data
|
||||
5. **Traceability**: Clear lineage from original request to all recordings
|
||||
6. **Performance**: Reduces duplicate body reads and re-cloning
|
||||
|
||||
## Implementation Considerations
|
||||
|
||||
### Memory Management
|
||||
- Use `sync.Pool` for byte buffers
|
||||
- Strict size limits on captured bodies
|
||||
- Rely on GC for snapshot cleanup
|
||||
|
||||
### Performance Impact
|
||||
- Single body read vs multiple reads (net positive)
|
||||
- Memory overhead for snapshot storage (manageable)
|
||||
- Context propagation overhead (minimal)
|
||||
|
||||
### Backward Compatibility
|
||||
- Maintain existing .http file format
|
||||
- Preserve existing API contracts
|
||||
- Gradual migration path
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Unit Tests
|
||||
- Snapshot creation and immutability
|
||||
- Response recording accuracy
|
||||
- Memory cleanup verification
|
||||
|
||||
### Integration Tests
|
||||
- End-to-end request/response recording
|
||||
- Mirror functionality with snapshots
|
||||
- Parity validation between old/new systems
|
||||
|
||||
### Performance Tests
|
||||
- Memory usage comparison
|
||||
- Throughput impact analysis
|
||||
- Large request body handling
|
||||
|
||||
## Future Enhancements
|
||||
|
||||
1. **Compression**: Compress stored snapshots for memory efficiency
|
||||
2. **Streaming**: Support for streaming request/response bodies
|
||||
3. **Filtering**: Selective snapshot creation based on patterns
|
||||
4. **Analytics**: Request/response analysis and metrics
|
||||
5. **Export**: Snapshot export for debugging and analysis
|
||||
|
||||
## Conclusion
|
||||
|
||||
This snapshot-based approach provides a robust foundation for reliable request recording while solving the current issues with body consumption and data inconsistency. The phased implementation ensures minimal disruption while delivering immediate benefits.
|
||||
@@ -0,0 +1,192 @@
|
||||
# SCMUDC Enrichment Implementation Summary
|
||||
|
||||
## Overview
|
||||
|
||||
This document summarizes the implementation of SCMUDC (Sound Control Management Usage Data Collection) event enrichment in the AfterTouch toolkit. The enhancement provides human-readable analysis of device telemetry data to improve usability and debugging capabilities.
|
||||
|
||||
## Problem Solved
|
||||
|
||||
Previously, SCMUDC telemetry events were stored as raw JSON with Base64-encoded XML content, making them difficult to analyze. Users had to manually decode content to understand what device interactions were being recorded.
|
||||
|
||||
## Solution Implemented
|
||||
|
||||
### 1. Backend Enrichment (`pkg/service/proxy/`)
|
||||
|
||||
#### New File: `scmudc.go`
|
||||
- **SCMUDCRequest/SCMUDCEvent Structs**: Parse incoming telemetry JSON
|
||||
- **EnrichedSCMUDCEvent Struct**: Human-readable analysis with decoded content
|
||||
- **DecodedContent Struct**: Parsed XML metadata (track names, artwork URLs, etc.)
|
||||
- **enrichSCMUDCRequest()**: Main enrichment function that:
|
||||
- Identifies event origin (app, hardware, or internal system)
|
||||
- Decodes Base64 XML content for device events
|
||||
- Creates human-readable summaries
|
||||
- **Helper Functions**: Button formatting, content summarization, origin descriptions
|
||||
|
||||
#### Enhanced File: `recorder.go`
|
||||
- **Updated save() method**: Extracts SCMUDC data during recording
|
||||
- **New writeRequestWithEnrichment()**: Adds enriched comments to .http files
|
||||
- **New writeResponseWithEnrichment()**: Includes SCMUDC analysis in response section
|
||||
- **Updated Interaction struct**: Added `SCMUDCData` field for API responses
|
||||
- **New extractSCMUDCFromFile()**: Parses enrichment data from existing .http files
|
||||
- **Enhanced parseInteractionFile()**: Populates SCMUDC data when listing interactions
|
||||
|
||||
### 2. Frontend Enhancement
|
||||
|
||||
#### Updated HTML (`pkg/service/handlers/web/index.html`)
|
||||
- **New Column**: Added "Event Details" to interactions table
|
||||
- **Table Structure**: Updated to accommodate SCMUDC enrichment display
|
||||
|
||||
#### Enhanced JavaScript (`pkg/service/handlers/web/js/script.js`)
|
||||
- **Updated fetchInteractions()**: Displays enriched SCMUDC data with icons
|
||||
- **New Helper Functions**:
|
||||
- `getOriginIcon()`: Maps origins to emojis (📱 App, 🎛️ Hardware, 🔄 Internal)
|
||||
- `getActionIcon()`: Maps actions to emojis (▶️ Play, ⏸️ Pause, etc.)
|
||||
- `showSCMUDCDetails()`: Detailed popover for complex events
|
||||
- `displaySCMUDCPopover()`: Modal dialog with full decoded content
|
||||
- **Truncation Logic**: Long content shows "(...)" with click-to-expand
|
||||
|
||||
## Event Origin Clarification
|
||||
|
||||
Based on analysis of recorded data:
|
||||
|
||||
| Origin | Source | Description | Example Events |
|
||||
|--------|--------|-------------|----------------|
|
||||
| `gabbo` | **SoundTouch App** | Mobile/desktop app UI interactions | Play, Pause, Power via app |
|
||||
| `console` | **Device Hardware** | Physical buttons on speaker | Preset buttons, hardware power |
|
||||
| `device` | **Internal System** | Automatic device responses | Content playback, system actions |
|
||||
|
||||
## Enhanced .http File Format
|
||||
|
||||
### Before (Raw)
|
||||
```http
|
||||
### POST /v1/scmudc/A81B6A536A98
|
||||
POST /v1/scmudc/A81B6A536A98
|
||||
Host: events.api.bosecm.com
|
||||
...
|
||||
|
||||
{"envelope":...,"payload":{"events":[{"data":{"contentItem":"PD94bWw..."}}]}}
|
||||
```
|
||||
|
||||
### After (Enriched)
|
||||
```http
|
||||
### POST /v1/scmudc/A81B6A536A98
|
||||
// Origin: Internal System (device)
|
||||
// Action: play-item
|
||||
// Command: Billie Eilish - bad guy (instrumental version)
|
||||
// Summary: Device: Spotify: Billie Eilish - bad guy (instrumental version)
|
||||
//
|
||||
// Decoded Content:
|
||||
// - Source: SPOTIFY
|
||||
// - Item: Billie Eilish - bad guy (instrumental version)
|
||||
// - Account: gesellix
|
||||
// - Artwork: https://i.scdn.co/image/ab67616d0000b273...
|
||||
//
|
||||
// Full XML Content:
|
||||
// <?xml version="1.0" encoding="UTF-8"?>
|
||||
// <ContentItem source="SPOTIFY" type="tracklisturl" ...>
|
||||
// <itemName>Billie Eilish - bad guy (instrumental version)</itemName>
|
||||
// <containerArt>https://i.scdn.co/image/ab67616d0000b273...</containerArt>
|
||||
// </ContentItem>
|
||||
POST /v1/scmudc/A81B6A536A98
|
||||
...
|
||||
|
||||
{% raw %}
|
||||
> {%
|
||||
// Response: 200 OK
|
||||
// SCMUDC Event Analysis:
|
||||
// - Origin: Internal System (device)
|
||||
// - Action: play-item
|
||||
// - Summary: Device: Spotify: Billie Eilish - bad guy (instrumental version)
|
||||
// - Content: Billie Eilish - bad guy (instrumental version)
|
||||
// - Account: gesellix
|
||||
%}
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
## Web UI Enhancement
|
||||
|
||||
### Interactions Table
|
||||
- **New Column**: "Event Details" shows enriched summaries
|
||||
- **Visual Icons**: Origin and action type indicators
|
||||
- **Truncation**: Long content abbreviated with "(...)" expansion
|
||||
- **Backward Compatibility**: Works with existing recordings
|
||||
|
||||
### Event Details Display
|
||||
```
|
||||
📱 ▶️ Play Button (Simple app action)
|
||||
🔄 🎵 Billie Eilish - bad guy... (...) (Complex device event with details)
|
||||
🎛️ ⭐ Preset 5 (Hardware preset button)
|
||||
```
|
||||
|
||||
### Detailed Popover
|
||||
For complex events, clicking "(...)" shows:
|
||||
- **Origin Description**: "SoundTouch App" instead of "gabbo"
|
||||
- **Full Content Information**: Track names, artwork URLs, account details
|
||||
- **Complete XML**: Formatted and readable content item data
|
||||
|
||||
## Implementation Benefits
|
||||
|
||||
### For Users
|
||||
- **Immediate Recognition**: See what actions were performed without decoding
|
||||
- **Better Debugging**: Quick identification of app vs. hardware vs. system events
|
||||
- **Rich Context**: Track names, accounts, and content sources visible at a glance
|
||||
|
||||
### For Developers
|
||||
- **Structured Data**: Consistent parsing and enrichment pipeline
|
||||
- **Extensible**: Easy to add new event types and origins
|
||||
- **Backward Compatible**: Existing recordings work without re-processing
|
||||
|
||||
### For Analysis
|
||||
- **Pattern Recognition**: Quickly identify user behavior patterns
|
||||
- **Service Integration**: See which music services are being used
|
||||
- **Device Usage**: Understand app vs. hardware control preferences
|
||||
|
||||
## File Structure
|
||||
|
||||
```
|
||||
pkg/service/proxy/
|
||||
├── scmudc.go # New: SCMUDC enrichment logic
|
||||
├── recorder.go # Enhanced: Enrichment integration
|
||||
│
|
||||
pkg/service/handlers/web/
|
||||
├── index.html # Enhanced: New table column
|
||||
├── js/script.js # Enhanced: SCMUDC display logic
|
||||
│
|
||||
docs/
|
||||
├── scmudc-events-analysis.md # New: Analysis documentation
|
||||
├── SCMUDC-ENRICHMENT-IMPLEMENTATION.md # This file
|
||||
```
|
||||
|
||||
## Technical Decisions
|
||||
|
||||
### Base64 Decoding Strategy
|
||||
- **When**: During recording (not on-demand) for performance
|
||||
- **Fallback**: Parse from .http files if enrichment missing
|
||||
- **Storage**: Both enriched comments and structured data in API responses
|
||||
|
||||
### Icon Selection
|
||||
- **Emoji Usage**: Universal, colorful, intuitive recognition
|
||||
- **Semantic Mapping**: Icons match function (📱 for app, 🎛️ for hardware)
|
||||
- **Fallback**: Generic icons (❓, 🔘) for unknown types
|
||||
|
||||
### Backward Compatibility
|
||||
- **Graceful Degradation**: Missing enrichment data doesn't break UI
|
||||
- **File Parsing**: Extract enrichment from existing .http files
|
||||
- **API Enhancement**: New fields optional in Interaction struct
|
||||
|
||||
## Future Enhancement Opportunities
|
||||
|
||||
1. **Event Correlation**: Link device events to user actions
|
||||
2. **Statistics Dashboard**: Origin-based usage analytics
|
||||
3. **Content Recommendations**: Track listening patterns
|
||||
4. **Device Health**: Monitor interaction frequency and patterns
|
||||
5. **Export Features**: CSV/JSON export of enriched event data
|
||||
|
||||
## Testing Considerations
|
||||
|
||||
- **Edge Cases**: Malformed Base64, missing XML elements
|
||||
- **Performance**: Large numbers of SCMUDC events
|
||||
- **Browser Compatibility**: Emoji display across different browsers
|
||||
- **Data Validation**: Ensure enrichment doesn't introduce errors
|
||||
|
||||
This implementation significantly improves the usability of SCMUDC telemetry data while maintaining full backward compatibility and raw data access for advanced users.
|
||||
@@ -23,7 +23,7 @@ This document summarizes the implementation of the `/serviceAvailability` endpoi
|
||||
### Modified Files
|
||||
|
||||
1. **`pkg/client/client.go`** - Added `GetServiceAvailability()` method
|
||||
2. **`docs/API-Endpoints-Overview.md`** - Updated implementation status
|
||||
2. **`docs/reference/API-ENDPOINTS.md`** - Updated implementation status
|
||||
3. **`docs/UNIMPLEMENTED-ENDPOINTS.md`** - Marked as implemented
|
||||
|
||||
## API Interface
|
||||
@@ -263,4 +263,4 @@ BenchmarkGetServiceAvailability-8 1000 1.2ms/op
|
||||
✅ **Performance benchmarks established**
|
||||
✅ **Error handling verified**
|
||||
|
||||
The ServiceAvailability implementation is production-ready and provides a solid foundation for building user-friendly SoundTouch applications with better service discovery and user feedback capabilities.
|
||||
The ServiceAvailability implementation is production-ready and provides a solid foundation for building user-friendly SoundTouch applications with better service discovery and user feedback capabilities.
|
||||
|
||||
@@ -144,10 +144,10 @@ LOG_PROXY_BODY=true soundtouch-service
|
||||
|
||||
## 📚 Documentation
|
||||
|
||||
- **[Complete Service Guide](SOUNDTOUCH-SERVICE.md)**: Comprehensive setup and configuration
|
||||
- **[API Reference](SOUNDTOUCH-SERVICE.md#api-reference)**: Full endpoint documentation
|
||||
- **[Migration Guide](SOUNDTOUCH-SERVICE.md#device-migration)**: Step-by-step device migration
|
||||
- **[Troubleshooting](SOUNDTOUCH-SERVICE.md#troubleshooting)**: Common issues and solutions
|
||||
- **[Complete Service Guide](guides/SOUNDTOUCH-SERVICE.md)**: Comprehensive setup and configuration
|
||||
- **[API Reference](guides/SOUNDTOUCH-SERVICE.md#api-reference)**: Full endpoint documentation
|
||||
- **[Migration Guide](guides/SOUNDTOUCH-SERVICE.md#device-migration)**: Step-by-step device migration
|
||||
- **[Troubleshooting](guides/SOUNDTOUCH-SERVICE.md#troubleshooting)**: Common issues and solutions
|
||||
|
||||
## 🤝 Contributing
|
||||
|
||||
@@ -172,9 +172,9 @@ The collaborative spirit of reverse engineering and documentation in the SoundTo
|
||||
## 🔗 Links
|
||||
|
||||
- **[Main Repository](https://github.com/gesellix/bose-soundtouch)**
|
||||
- **[Service Documentation](SOUNDTOUCH-SERVICE.md)**
|
||||
- **[CLI Documentation](CLI-REFERENCE.md)**
|
||||
- **[Getting Started Guide](GETTING-STARTED.md)**
|
||||
- **[Service Documentation](guides/SOUNDTOUCH-SERVICE.md)**
|
||||
- **[CLI Documentation](guides/CLI-REFERENCE.md)**
|
||||
- **[Getting Started Guide](guides/GETTING-STARTED.md)**
|
||||
- **[SoundCork Project](https://github.com/deborahgu/soundcork)**
|
||||
- **[ÜberBöse API](https://github.com/julius-d/ueberboese-api)**
|
||||
|
||||
@@ -187,4 +187,4 @@ go install github.com/gesellix/bose-soundtouch/cmd/soundtouch-service@latest
|
||||
soundtouch-service
|
||||
```
|
||||
|
||||
Open `http://localhost:8000` and start your journey to local SoundTouch control! 🎵
|
||||
Open `http://localhost:8000` and start your journey to local SoundTouch control! 🎵
|
||||
|
||||
@@ -1,534 +0,0 @@
|
||||
# SoundTouch Service
|
||||
|
||||
The `soundtouch-service` is a comprehensive local server that emulates Bose's cloud services, enabling offline SoundTouch device operation and advanced debugging capabilities. This service is particularly valuable given Bose's announcement that cloud support will end in May 2026.
|
||||
|
||||
## Overview
|
||||
|
||||
The service provides:
|
||||
|
||||
- **🏠 Local Service Emulation**: Complete BMX (Bose Media eXchange) and Marge service implementation
|
||||
- **🔧 Device Migration**: Seamlessly migrate devices from Bose cloud to local services
|
||||
- **📊 Traffic Proxying**: Inspect and log all device communications for debugging
|
||||
- **🌐 Web Management UI**: Browser-based interface for device management
|
||||
- **💾 Persistent Data**: Store device configurations, presets, and usage statistics
|
||||
- **🔍 Auto-Discovery**: Automatically detect and configure SoundTouch devices
|
||||
- **🔒 Offline Operation**: Continue using full device functionality without internet
|
||||
|
||||
## Architecture
|
||||
|
||||
The service consists of several key components:
|
||||
|
||||
### BMX Services (Bose Media eXchange)
|
||||
- **TuneIn Integration**: Direct playback of radio stations and podcasts
|
||||
- **Service Registry**: Media service discovery and configuration
|
||||
- **Playback Control**: Stream URL resolution and audio metadata
|
||||
|
||||
### Marge Services (Account & Device Management)
|
||||
- **Account Management**: User account simulation and device association
|
||||
- **Preset Synchronization**: Cross-device preset storage and sync
|
||||
- **Recent Items**: Playback history tracking and management
|
||||
- **Configuration Management**: Device settings and preferences
|
||||
|
||||
### Discovery & Migration
|
||||
- **Network Scanning**: UPnP/SSDP and mDNS device discovery
|
||||
- **Device Analysis**: Configuration assessment and compatibility checking
|
||||
- **Service Migration**: Automated configuration updates for local service usage
|
||||
- **Health Monitoring**: Device connectivity and service status tracking
|
||||
|
||||
## Installation
|
||||
|
||||
### Install from Source
|
||||
```bash
|
||||
go install github.com/gesellix/bose-soundtouch/cmd/soundtouch-service@latest
|
||||
```
|
||||
|
||||
### Build from Repository
|
||||
```bash
|
||||
git clone https://github.com/gesellix/bose-soundtouch.git
|
||||
cd Bose-SoundTouch
|
||||
go build -o soundtouch-service ./cmd/soundtouch-service
|
||||
```
|
||||
|
||||
### Docker (coming soon)
|
||||
```bash
|
||||
# Docker support planned for future release
|
||||
docker run -p 8000:8000 gesellix/soundtouch-service
|
||||
```
|
||||
|
||||
## Quick Start
|
||||
|
||||
### 1. Start the Service
|
||||
|
||||
```bash
|
||||
# Start with default settings (port 8000)
|
||||
soundtouch-service
|
||||
```
|
||||
|
||||
### 2. Access the Web Interface
|
||||
|
||||
Open your browser to `http://localhost:8000` to access the management interface.
|
||||
|
||||
### 3. Discover Devices
|
||||
|
||||
The service will automatically start discovering SoundTouch devices on your network. You can also trigger manual discovery from the web UI or API.
|
||||
|
||||
### 4. Migrate Devices
|
||||
|
||||
Use the web interface or API to migrate devices from Bose cloud services to your local instance.
|
||||
|
||||
## Configuration
|
||||
|
||||
The service can be configured via environment variables or command-line flags:
|
||||
|
||||
| Variable | Flag | Description | Default |
|
||||
|----------|------|-------------|---------|
|
||||
| `PORT` | `--port` | Port to bind the service to | `8000` |
|
||||
| `BIND_ADDR` | `--bind` | Network interface to bind to | all (ipv4 and ipv6) |
|
||||
| `DATA_DIR` | `--data-dir` | Directory for persistent data | `./data` |
|
||||
| `SERVER_URL` | `--server-url` | External URL of this service | `http://<hostname>:8000` |
|
||||
| `REDACT_PROXY_LOGS` | `--redact-logs` | Redact sensitive data in proxy logs | `true` |
|
||||
| `LOG_PROXY_BODY` | `--log-bodies` | Log full request/response bodies | `false` |
|
||||
| `DISCOVERY_INTERVAL` | `--discovery-interval` | Device discovery interval | `5m` |
|
||||
|
||||
### Configuration Examples
|
||||
|
||||
```bash
|
||||
# Custom port and data directory
|
||||
PORT=9000 DATA_DIR=/home/user/soundtouch soundtouch-service
|
||||
|
||||
# External server with custom URL
|
||||
SERVER_URL=https://my-soundtouch.example.com soundtouch-service --port 443
|
||||
|
||||
# Development mode with full logging
|
||||
LOG_PROXY_BODY=true REDACT_PROXY_LOGS=false soundtouch-service
|
||||
```
|
||||
|
||||
## Device Migration
|
||||
|
||||
### Understanding Migration
|
||||
|
||||
Device migration switches your SoundTouch devices from Bose's cloud services to your local service instance. This process:
|
||||
|
||||
1. **Backs up** existing device configuration
|
||||
2. **Updates** device service URLs to point to your local server
|
||||
3. **Maintains** all existing presets and settings
|
||||
4. **Enables** offline operation and advanced debugging
|
||||
|
||||
### Migration Methods
|
||||
|
||||
#### Web Interface (Recommended)
|
||||
|
||||
1. Start the service: `soundtouch-service`
|
||||
2. Open `http://localhost:8000`
|
||||
3. Wait for device discovery to complete
|
||||
4. Click "Migrate" next to each device
|
||||
5. Monitor migration status in real-time
|
||||
|
||||
#### API Migration
|
||||
|
||||
```bash
|
||||
# Get migration summary first
|
||||
curl http://localhost:8000/setup/migration-summary/192.168.1.100
|
||||
|
||||
# Perform migration
|
||||
curl -X POST http://localhost:8000/setup/migrate/192.168.1.100
|
||||
|
||||
# Verify migration status
|
||||
curl http://localhost:8000/setup/devices
|
||||
```
|
||||
|
||||
#### Advanced Migration Options
|
||||
|
||||
```bash
|
||||
# Migration with proxy fallback for original services
|
||||
curl -X POST "http://localhost:8000/setup/migrate/192.168.1.100?proxy_url=http://localhost:8000&marge=original&stats=original"
|
||||
|
||||
# Migration with custom target URL
|
||||
curl -X POST "http://localhost:8000/setup/migrate/192.168.1.100?target_url=https://my-server.com:8000"
|
||||
```
|
||||
|
||||
### Post-Migration Verification
|
||||
|
||||
After migration, verify the device is working correctly:
|
||||
|
||||
```bash
|
||||
# Check device status
|
||||
curl http://localhost:8000/setup/devices
|
||||
|
||||
# Test preset functionality
|
||||
curl "http://192.168.1.100:8090/presets"
|
||||
|
||||
# Monitor device events (if needed)
|
||||
curl "http://localhost:8000/events/192.168.1.100"
|
||||
```
|
||||
|
||||
## API Reference
|
||||
|
||||
### Discovery & Setup
|
||||
|
||||
#### `GET /setup/devices`
|
||||
Lists all discovered SoundTouch devices with their current status.
|
||||
|
||||
**Response:**
|
||||
```json
|
||||
[
|
||||
{
|
||||
"device_id": "08DF1F0BA325",
|
||||
"name": "Living Room Speaker",
|
||||
"ip_address": "192.168.1.100",
|
||||
"product_code": "SoundTouch 20",
|
||||
"firmware_version": "19.0.5",
|
||||
"migrated": true,
|
||||
"last_seen": "2024-01-15T10:30:00Z"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
#### `POST /setup/discover`
|
||||
Triggers immediate network device discovery.
|
||||
|
||||
#### `GET /setup/info/{deviceIP}`
|
||||
Gets detailed device information and configuration.
|
||||
|
||||
#### `GET /setup/migration-summary/{deviceIP}`
|
||||
Analyzes device configuration and provides migration preview.
|
||||
|
||||
**Response:**
|
||||
```json
|
||||
{
|
||||
"device_name": "Living Room Speaker",
|
||||
"device_model": "SoundTouch 20",
|
||||
"firmware_version": "19.0.5",
|
||||
"ssh_success": true,
|
||||
"current_config": "<?xml version=\"1.0\"?>...",
|
||||
"planned_config": "<?xml version=\"1.0\"?>...",
|
||||
"remote_services_enabled": false,
|
||||
"migration_required": true
|
||||
}
|
||||
```
|
||||
|
||||
#### `POST /setup/migrate/{deviceIP}`
|
||||
Migrates device to use local services.
|
||||
|
||||
**Query Parameters:**
|
||||
- `target_url`: Custom service URL (optional)
|
||||
- `proxy_url`: Proxy URL for fallback (optional)
|
||||
- `marge`: Set to "original" to proxy Marge requests (optional)
|
||||
- `stats`: Set to "original" to proxy stats requests (optional)
|
||||
- `sw_update`: Set to "original" to proxy update requests (optional)
|
||||
- `bmx`: Set to "original" to proxy BMX requests (optional)
|
||||
|
||||
### BMX Services (Bose Media eXchange)
|
||||
|
||||
#### `GET /bmx/registry/v1/services`
|
||||
Returns available media services for device registration.
|
||||
|
||||
#### `GET /bmx/tunein/v1/playbook/station/{stationID}`
|
||||
Provides TuneIn station playback information.
|
||||
|
||||
#### `GET /bmx/tunein/v1/podcast/{podcastID}`
|
||||
Returns podcast episode information and playback URLs.
|
||||
|
||||
### Marge Services (Account & Device Management)
|
||||
|
||||
#### `GET /marge/streaming/sourceproviders`
|
||||
Lists available music service providers.
|
||||
|
||||
#### `GET /marge/accounts/{account}/devices/any/presets`
|
||||
Returns user presets for synchronization.
|
||||
|
||||
#### `GET /marge/accounts/{account}/devices/any/recents`
|
||||
Returns recent playback items.
|
||||
|
||||
#### `PUT /marge/accounts/{account}/devices/{device}/presets/{slot}`
|
||||
Updates a specific preset slot.
|
||||
|
||||
#### `POST /marge/streaming/support/addrecent`
|
||||
Adds item to recent playback history.
|
||||
|
||||
#### `GET /marge/updates/soundtouch`
|
||||
Returns software update configuration (disabled by default).
|
||||
|
||||
### Proxy Services
|
||||
|
||||
#### `GET /proxy/{encodedURL}`
|
||||
Proxies requests to external services with logging.
|
||||
|
||||
**Example:**
|
||||
```bash
|
||||
# Proxy request to Bose services
|
||||
curl "http://localhost:8000/proxy/aHR0cHM6Ly9hcGkuc291bmR0b3VjaC5ib3NlLmNvbS8="
|
||||
```
|
||||
|
||||
### Health & Monitoring
|
||||
|
||||
#### `GET /health`
|
||||
Returns service health status.
|
||||
|
||||
#### `GET /events/{deviceID}`
|
||||
WebSocket endpoint for real-time device events.
|
||||
|
||||
#### `GET /stats/usage`
|
||||
Returns usage statistics.
|
||||
|
||||
#### `GET /stats/errors`
|
||||
Returns error statistics.
|
||||
|
||||
## Web Interface
|
||||
|
||||
### Overview
|
||||
|
||||
The web management interface provides a comprehensive dashboard for managing your SoundTouch devices:
|
||||
|
||||
**URL:** `http://localhost:8000/`
|
||||
|
||||
### Features
|
||||
|
||||
#### Device Dashboard
|
||||
- **Device Discovery**: Real-time view of discovered devices
|
||||
- **Migration Status**: Visual indicators of migration state
|
||||
- **Device Health**: Connectivity and service status monitoring
|
||||
- **Quick Actions**: One-click migration and configuration
|
||||
|
||||
#### Device Management
|
||||
- **Configuration Viewer**: Inspect current and planned device configs
|
||||
- **Migration Wizard**: Step-by-step device migration process
|
||||
- **Backup Management**: View and restore configuration backups
|
||||
- **Service Testing**: Test connectivity to local services
|
||||
|
||||
#### Monitoring & Debugging
|
||||
- **Traffic Logs**: Real-time proxy request/response logging
|
||||
- **Event Streaming**: Live device event monitoring
|
||||
- **Statistics Dashboard**: Usage and error analytics
|
||||
- **Debug Tools**: Device communication testing utilities
|
||||
|
||||
### Usage Tips
|
||||
|
||||
1. **First Time Setup**: The interface will guide you through initial device discovery
|
||||
2. **Migration Monitoring**: Watch migration progress in real-time with detailed status updates
|
||||
3. **Troubleshooting**: Use the debug tools to diagnose device connectivity issues
|
||||
4. **Log Analysis**: Enable detailed logging for development and troubleshooting
|
||||
|
||||
## Persistent Data
|
||||
|
||||
### Data Directory Structure
|
||||
|
||||
By default, the service creates a `data/` directory in the current working directory:
|
||||
|
||||
```
|
||||
data/
|
||||
├── accounts/
|
||||
│ └── default/
|
||||
│ ├── devices/
|
||||
│ │ ├── {DEVICE_ID}/
|
||||
│ │ │ ├── DeviceInfo.xml
|
||||
│ │ │ └── config_backup_*.xml
|
||||
│ │ └── ...
|
||||
│ ├── Sources.xml
|
||||
│ ├── Presets.xml
|
||||
│ └── Recents.xml
|
||||
├── stats/
|
||||
│ ├── usage/
|
||||
│ │ └── *.json
|
||||
│ └── error/
|
||||
│ └── *.json
|
||||
└── events/
|
||||
└── device_events_*.log
|
||||
```
|
||||
|
||||
### Data Components
|
||||
|
||||
#### Device Data (`accounts/default/devices/{DEVICE_ID}/`)
|
||||
- **DeviceInfo.xml**: Device metadata and capabilities
|
||||
- **config_backup_*.xml**: Configuration backups before migration
|
||||
- **presets.xml**: Device-specific preset configurations
|
||||
|
||||
#### Account Data (`accounts/default/`)
|
||||
- **Sources.xml**: Configured music service providers
|
||||
- **Presets.xml**: Cross-device preset synchronization
|
||||
- **Recents.xml**: Recent playback history
|
||||
|
||||
#### Statistics (`stats/`)
|
||||
- **usage/**: Device usage analytics and patterns
|
||||
- **error/**: Error logs and diagnostic information
|
||||
|
||||
#### Events (`events/`)
|
||||
- **device_events_*.log**: Device event history and debugging logs
|
||||
|
||||
### Data Management
|
||||
|
||||
#### Backup Strategy
|
||||
```bash
|
||||
# Manual backup
|
||||
cp -r data/ backup-$(date +%Y%m%d)/
|
||||
|
||||
# Automated backup (cron example)
|
||||
0 2 * * * cp -r /path/to/data/ /backup/soundtouch-$(date +\%Y\%m\%d)/
|
||||
```
|
||||
|
||||
#### Data Migration
|
||||
```bash
|
||||
# Moving to new server
|
||||
tar czf soundtouch-data.tar.gz data/
|
||||
# Transfer to new server
|
||||
tar xzf soundtouch-data.tar.gz
|
||||
```
|
||||
|
||||
#### Cleanup
|
||||
```bash
|
||||
# Clean old event logs (older than 30 days)
|
||||
find data/events/ -name "*.log" -mtime +30 -delete
|
||||
|
||||
# Clean old statistics (older than 90 days)
|
||||
find data/stats/ -name "*.json" -mtime +90 -delete
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
#### Device Not Discovered
|
||||
```bash
|
||||
# Check network connectivity
|
||||
ping 192.168.1.100
|
||||
|
||||
# Trigger manual discovery
|
||||
curl -X POST http://localhost:8000/setup/discover
|
||||
|
||||
# Check device accessibility
|
||||
curl http://192.168.1.100:8090/info
|
||||
```
|
||||
|
||||
#### Migration Failures
|
||||
```bash
|
||||
# Check SSH connectivity
|
||||
ssh-keyscan 192.168.1.100
|
||||
|
||||
# Get migration summary
|
||||
curl http://localhost:8000/setup/migration-summary/192.168.1.100
|
||||
|
||||
# Verify device configuration
|
||||
curl http://192.168.1.100:8090/info
|
||||
```
|
||||
|
||||
#### Service Connectivity Issues
|
||||
```bash
|
||||
# Test local service endpoints
|
||||
curl http://localhost:8000/health
|
||||
curl http://localhost:8000/bmx/registry/v1/services
|
||||
curl http://localhost:8000/marge/streaming/sourceproviders
|
||||
```
|
||||
|
||||
### Debug Mode
|
||||
|
||||
Enable debug logging for detailed troubleshooting:
|
||||
|
||||
```bash
|
||||
LOG_PROXY_BODY=true REDACT_PROXY_LOGS=false soundtouch-service
|
||||
```
|
||||
|
||||
### Log Analysis
|
||||
|
||||
```bash
|
||||
# Monitor service logs
|
||||
tail -f /var/log/soundtouch-service.log
|
||||
|
||||
# Analyze proxy traffic
|
||||
grep "PROXY" /var/log/soundtouch-service.log
|
||||
|
||||
# Check device events
|
||||
ls -la data/events/
|
||||
```
|
||||
|
||||
## Credits & Inspiration
|
||||
|
||||
This service implementation is based on and inspired by several excellent community projects:
|
||||
|
||||
### SoundCork
|
||||
- **Project**: [SoundCork](https://github.com/deborahgu/soundcork)
|
||||
- **Authors**: Deborah Gu and contributors
|
||||
- **Contribution**: The architecture and service emulation approach in this Go implementation is heavily based on SoundCork's pioneering Python implementation. SoundCork provided the foundation for understanding Bose's service architecture and migration strategies.
|
||||
|
||||
### ÜberBöse API
|
||||
- **Project**: [ÜberBöse API](https://github.com/julius-d/ueberboese-api)
|
||||
- **Author**: Julius D.
|
||||
- **Contribution**: Advanced API endpoint discovery and implementation details that helped make this service more complete and robust.
|
||||
|
||||
We are grateful to these projects for paving the way and providing the research foundation that made this comprehensive service implementation possible.
|
||||
|
||||
## Advanced Usage
|
||||
|
||||
### Custom Service Integration
|
||||
|
||||
```go
|
||||
// Example: Custom BMX service handler
|
||||
package main
|
||||
|
||||
import (
|
||||
"net/http"
|
||||
"github.com/go-chi/chi/v5"
|
||||
)
|
||||
|
||||
func customBMXHandler(w http.ResponseWriter, r *http.Request) {
|
||||
// Custom BMX service logic
|
||||
w.Header().Set("Content-Type", "application/json")
|
||||
w.Write([]byte(`{"custom": "service"}`))
|
||||
}
|
||||
|
||||
func main() {
|
||||
r := chi.NewRouter()
|
||||
r.Get("/bmx/custom/endpoint", customBMXHandler)
|
||||
http.ListenAndServe(":8000", r)
|
||||
}
|
||||
```
|
||||
|
||||
### Integration with Home Assistant
|
||||
|
||||
```yaml
|
||||
# configuration.yaml
|
||||
soundtouch:
|
||||
- host: 192.168.1.100
|
||||
port: 8090
|
||||
name: "Living Room Speaker"
|
||||
|
||||
rest:
|
||||
- resource: "http://localhost:8000/setup/devices"
|
||||
scan_interval: 60
|
||||
sensor:
|
||||
- name: "SoundTouch Devices"
|
||||
value_template: "{{ value_json | length }}"
|
||||
```
|
||||
|
||||
### Monitoring & Alerting
|
||||
|
||||
```bash
|
||||
# Health check script
|
||||
#!/bin/bash
|
||||
response=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:8000/health)
|
||||
if [ $response != "200" ]; then
|
||||
echo "SoundTouch service is down!" | mail -s "Alert" admin@example.com
|
||||
fi
|
||||
```
|
||||
|
||||
## Security Considerations
|
||||
|
||||
- **Network Security**: The service binds to all interfaces by default. Consider using `BIND_ADDR=127.0.0.1` for localhost-only access.
|
||||
- **SSH Access**: Migration requires SSH access to devices. Ensure your network security policies allow this.
|
||||
- **Proxy Logging**: Disable `REDACT_PROXY_LOGS` only in development environments.
|
||||
- **Data Protection**: The data directory contains device configurations and usage patterns. Secure appropriately.
|
||||
|
||||
## Performance Tuning
|
||||
|
||||
### Resource Usage
|
||||
- **Memory**: ~50MB baseline + ~5MB per discovered device
|
||||
- **CPU**: Minimal during steady state, ~10% during discovery/migration
|
||||
- **Disk**: ~1MB per device configuration + logs
|
||||
|
||||
### Scaling Considerations
|
||||
```bash
|
||||
# For many devices, increase discovery interval
|
||||
DISCOVERY_INTERVAL=10m soundtouch-service
|
||||
|
||||
# For high-traffic environments, consider reverse proxy
|
||||
nginx -> soundtouch-service instances
|
||||
```
|
||||
@@ -0,0 +1,88 @@
|
||||
# Table of Contents
|
||||
|
||||
* [Introduction](README.md)
|
||||
|
||||
## User Guides
|
||||
* [Cloud Shutdown Survival Guide](guides/SURVIVAL-GUIDE.md)
|
||||
* [Migration & Safety Guide](guides/MIGRATION-SAFETY.md)
|
||||
* [CLI Reference](guides/CLI-REFERENCE.md)
|
||||
* [Getting Started](guides/GETTING-STARTED.md)
|
||||
* [SoundTouch Service](guides/SOUNDTOUCH-SERVICE.md)
|
||||
* [Initial Device Setup](guides/DEVICE-INITIAL-SETUP.md)
|
||||
* [MAC Address Mapping](guides/MAC-ADDRESS-MAPPING.md)
|
||||
* [HTTPS Setup](guides/HTTPS-SETUP.md)
|
||||
* [Deployment](guides/DEPLOYMENT.md)
|
||||
* [Raspberry Pi Guide](guides/RASPBERRY-PI.md)
|
||||
* [Troubleshooting](guides/TROUBLESHOOTING.md)
|
||||
* [IoT Implementation Guide](guides/IOT-IMPLEMENTATION-GUIDE.md)
|
||||
* [Migration Guide](guides/MIGRATION-GUIDE.md)
|
||||
* [MQTT Integration Design](guides/MQTT-INTEGRATION-DESIGN.md)
|
||||
* [Useful Links](#useful-links)
|
||||
|
||||
### Useful Links
|
||||
* [Cloud Shutdown Survival Guide](guides/SURVIVAL-GUIDE.md)
|
||||
* [Raspberry Pi Installer](../scripts/raspberry-pi/README.md)
|
||||
* [Updating the Service](../scripts/raspberry-pi/README.md#updating-to-a-new-version)
|
||||
* [CLI Reference](guides/CLI-REFERENCE.md)
|
||||
|
||||
## Technical Reference
|
||||
* [API Cookbook](reference/API-COOKBOOK.md)
|
||||
* [API Endpoints](reference/API-ENDPOINTS.md)
|
||||
* [Cloud API Emulation](reference/CLOUD-API.md)
|
||||
* [System Endpoints](reference/SYSTEM-ENDPOINTS.md)
|
||||
* [Speaker Endpoint](reference/SPEAKER-ENDPOINT.md)
|
||||
* [WebSocket Events](reference/WEBSOCKET-EVENTS.md)
|
||||
* [Discovery](reference/DISCOVERY.md)
|
||||
* [Zone Management](reference/ZONE-MANAGEMENT.md)
|
||||
* [Preset Management](reference/PRESET-MANAGEMENT.md)
|
||||
* [Source Selection](reference/SOURCE-SELECTION.md)
|
||||
* [Volume Controls](reference/VOLUME-CONTROLS.md)
|
||||
* [RadioBrowser](reference/radio-browser.md)
|
||||
* [Bass Controls](reference/BASS-CONTROLS.md)
|
||||
* [Key Controls](reference/KEY-CONTROLS.md)
|
||||
* [Feature Mapping](reference/FEATURE-MAPPING.md)
|
||||
|
||||
## Concepts
|
||||
* [Request Recording](REQUEST_RECORDING_CONCEPT.md)
|
||||
* [Spotify Priming Strategy](concepts/spotify-priming-strategy.md)
|
||||
* [Spotify OAuth](concepts/spotify-oauth.md)
|
||||
|
||||
## Analysis & Research
|
||||
* [API Coverage Analysis](analysis/API-COVERAGE.md)
|
||||
* [Supported URLs](analysis/SUPPORTED-URLS.md)
|
||||
* [Upstream URLs](analysis/UPSTREAM-URLS.md)
|
||||
* [Anonymization Summary](analysis/ANONYMIZATION-SUMMARY.md)
|
||||
* [Device Redirect Methods](analysis/DEVICE-REDIRECT-METHODS.md)
|
||||
* [Wiki API Comparison](analysis/WIKI-COMPARISON.md)
|
||||
* [IoT Config Summary](analysis/IOT-CONFIG-SUMMARY.md)
|
||||
* [IoT Configuration Analysis](analysis/IOT-CONFIGURATION-ANALYSIS.md)
|
||||
|
||||
## Parity Analysis
|
||||
* [Parity Improvements](PARITY-IMPROVEMENTS.md)
|
||||
* [Parity SoundCork](PARITY-SOUNDCORK.md)
|
||||
|
||||
## Appendix (Other Documents)
|
||||
* [API Navigation Reference](API-NAVIGATION-REFERENCE.md)
|
||||
* [Claude Instructions](CLAUDE.md)
|
||||
* [Content Selection Implementation](CONTENT-SELECTION-IMPLEMENTATION.md)
|
||||
* [Device Customization Setup](DEVICE-CUSTOMIZATION-SETUP.md)
|
||||
* [Device Logging](DEVICE-LOGGING.md)
|
||||
* [Feature History](FEATURE_HISTORY.md)
|
||||
* [Host/Port Parsing](HOST-PORT-PARSING.md)
|
||||
* [Manual Network Discovery](MANUAL-NETWORK-DISCOVERY.md)
|
||||
* [Navigation Guide](NAVIGATION-GUIDE.md)
|
||||
* [Official API Verification](OFFICIAL-API-VERIFICATION.md)
|
||||
* [Preset Quickstart](PRESET-QUICKSTART.md)
|
||||
* [Project Patterns](PROJECT-PATTERNS.md)
|
||||
* [Service Availability Implementation](SERVICE-AVAILABILITY-IMPLEMENTATION.md)
|
||||
* [SoundTouch Service Announcement](SOUNDTOUCH-SERVICE-ANNOUNCEMENT.md)
|
||||
* [Undocumented Community Features](UNDOCUMENTED-COMMUNITY-FEATURES.md)
|
||||
* [Unimplemented Endpoints](UNIMPLEMENTED-ENDPOINTS.md)
|
||||
* [Preset Store](preset-store.md)
|
||||
* [SCMUDC Enrichment Implementation](SCMUDC-ENRICHMENT-IMPLEMENTATION.md)
|
||||
* [Device Lifecycle and Power On Enhancement](device-lifecycle-and-power-on-enhancement.md)
|
||||
* [Device Lifecycle Summary](device-lifecycle-summary.md)
|
||||
* [Power On Implementation Guide](power-on-implementation-guide.md)
|
||||
* [SCMUDC Events Analysis](scmudc-events-analysis.md)
|
||||
* [Parity Improvements](PARITY-IMPROVEMENTS.md)
|
||||
* [Parity SoundCork](PARITY-SOUNDCORK.md)
|
||||
@@ -0,0 +1,46 @@
|
||||
# Undocumented Community Features & API Discoveries
|
||||
This document captures advanced API endpoints and device behaviors discovered by the SoundTouch community through reverse engineering projects like **SoundCork** and **ÜberBöse API**. These features are not documented in the official Bose SoundTouch Web API v1.0 but are crucial for full device emulation and offline operation.
|
||||
## Cloud Emulation (Marge/BMX) Discoveries
|
||||
While the local `/8090` API is well-documented, the cloud-side service emulation reveals deeper device integration points.
|
||||
### 1. Stereo Pairing & Cloud-Side Grouping
|
||||
SoundCork has pioneered the emulation of "Marge" group endpoints, which differ from the local `/getGroup` API. These are primarily used for persistent configurations like **Stereo Pairs** (e.g., two ST-10s).
|
||||
- **GET** `/marge/streaming/account/{account}/device/{device}/group`
|
||||
Returns `<group/>` if ungrouped, or full group configuration for stereo pairs.
|
||||
- **POST** `/marge/streaming/account/{account}/group`
|
||||
Creates a new group (returns a 7-digit group ID). Used for initial pairing.
|
||||
- **DELETE** `/marge/streaming/account/{account}/group/{group}`
|
||||
Dissolves a group configuration.
|
||||
### 2. Device Analytics & Event Reporting
|
||||
Devices report real-time telemetry to the cloud. Intercepting these provides a window into device usage without polling.
|
||||
- **Endpoint**: `POST /v1/scmudc/{deviceId}`
|
||||
- **Function**: Submits event data including `play-state-changed`, `preset-pressed`, `power-pressed`, `source-state-changed`, and `art-changed` (Metadata updates). This endpoint was first extensively documented in the **ÜberBöse API** specification.
|
||||
### 3. Power-On Lifecycle
|
||||
When a SoundTouch device boots or "powers on" (distinct from waking from standby), it contacts specific support endpoints.
|
||||
- **Endpoint**: `POST /streaming/support/power_on`
|
||||
- **Behavior**: Reports device serial number, IP address, and diagnostic data.
|
||||
- **Critical Finding**: SoundTouch devices fetch `TUNEIN` and `LOCAL_INTERNET_RADIO` source availability from the cloud **ONLY at boot time**. If the cloud is unreachable during a hard reboot (power cycle), these sources will disappear from the device's `/sources` list and become unavailable, even if the local API is working. This behavior was analyzed and reported by the **ÜberBöse API** project (Issue #3).
|
||||
### 4. OAuth & Service Tokens
|
||||
Integration with music services (Spotify, Pandora, etc.) involves specific token management endpoints.
|
||||
- **Endpoint**: `POST /oauth/device/{deviceId}/music/musicprovider/{providerId}/token/{tokenType}`
|
||||
- **Usage**: Used to refresh or validate session tokens for cloud-based music providers.
|
||||
## Community-Driven Extensions
|
||||
The community is working on extending SoundTouch functionality beyond its original design.
|
||||
### 1. Radio-Browser.info Integration
|
||||
There is an active effort to add `radio-browser.info` as a native `sourceprovider`. This would allow devices to browse a massive directory of thousands of stations without relying on the TuneIn cloud service.
|
||||
- **Status**: Research phase in SoundCork (Issue #150).
|
||||
- **Implementation**: Requires adding a new source provider entry in the emulated `/streaming/sourceproviders` response.
|
||||
### 2. Stockholm Internal App Analysis
|
||||
Deep analysis of the Stockholm (device firmware) internal web application reveals a set of internal AJAX/XML calls used by the device's own control interface.
|
||||
- **Internal Domains**: `Marge` (XML-based) and `Gabbo` (App-send based).
|
||||
- **Reference**: See SoundCork Issue #128 for a comprehensive list of internal JS controllers and their functions.
|
||||
### 3. ETag Case-Sensitivity Bug
|
||||
The SoundTouch device firmware has a case-sensitivity bug regarding HTTP `ETag` headers.
|
||||
- **Discovery**: SoundCork Issue #129.
|
||||
- **Detail**: The device expects the `ETag` header to be exactly title-cased. If a server returns `etag` (lowercase), the device fails to use it for `If-None-Match` requests, breaking efficient preset synchronization.
|
||||
- **Solution**: Force title-casing of the header via a reverse proxy like Nginx or mitmproxy.
|
||||
## References
|
||||
- [SoundCork GitHub Repo](https://github.com/deborahgu/soundcork)
|
||||
- [ÜberBöse API Spec](https://github.com/julius-d/ueberboese-api)
|
||||
- [SoundTouch Plus Wiki](https://github.com/thlucas1/homeassistantcomponent_soundtouchplus/wiki/SoundTouch-WebServices-API)
|
||||
- [IsItBose Regex Research](https://github.com/deborahgu/soundcork/issues/62#issuecomment-3610563908)
|
||||
- [SoundTouch Hook Repo](https://github.com/CodeFinder2/bose-soundtouch-hook)
|
||||
@@ -370,7 +370,7 @@ soundtouch-cli speaker beep
|
||||
**Go Client Usage:**
|
||||
```go
|
||||
// Text-to-Speech
|
||||
client.PlayTTS("Hello World", "your-app-key", 70)
|
||||
client.PlayTTS("Hello World", "your-app-key", "EN", 70)
|
||||
|
||||
// URL content
|
||||
client.PlayURL("https://example.com/audio.mp3", "your-app-key", "Service", "Message", "Reason", 60)
|
||||
@@ -1044,4 +1044,4 @@ The SoundTouch Plus Wiki provides comprehensive documentation for **64 additiona
|
||||
|
||||
This documentation provides the complete foundation for implementing all endpoints from the SoundTouch Plus Wiki, enabling this Go library to become the definitive SoundTouch integration solution for everything from basic home automation to professional audio installations.
|
||||
|
||||
*All examples and XML structures are verified against real SoundTouch hardware and extensively tested by the SoundTouch Plus community.*
|
||||
*All examples and XML structures are verified against real SoundTouch hardware and extensively tested by the SoundTouch Plus community.*
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
title: Bose SoundTouch Toolkit
|
||||
description: Documentation for controlling and preserving Bose SoundTouch devices
|
||||
remote_theme: pages-themes/minimal@v0.2.0
|
||||
plugins:
|
||||
- jekyll-remote-theme
|
||||
- jekyll-relative-links
|
||||
relative_links:
|
||||
enabled: true
|
||||
collections: true
|
||||
include:
|
||||
- SUMMARY.md
|
||||
@@ -0,0 +1,198 @@
|
||||
# Device Redirect Methods & Custom Service Setup
|
||||
|
||||
To enable offline operation or use custom services like **SoundCork** or **ÜberBöse API**, SoundTouch devices must be redirected from Bose's official cloud endpoints to a local or custom server. This document outlines the three known methods to achieve this, gathered from community reverse-engineering efforts in the **SoundCork** and **ÜberBöse API** projects.
|
||||
|
||||
## Overview of Redirection Targets
|
||||
|
||||
SoundTouch devices primarily communicate with the following domains:
|
||||
- `streaming.bose.com`: Marge (Account and streaming services)
|
||||
- `updates.bose.com`: Software updates
|
||||
- `stats.bose.com`: Telemetry and analytics
|
||||
- `bmx.bose.com`: Bose Media eXchange registry
|
||||
- `events.api.bosecm.com`: Stockholm app analytics
|
||||
- `bose-prod.apigee.net`: Apigee gateway (used by some services)
|
||||
- `worldwide.bose.com`: Software update metadata and secondary services
|
||||
|
||||
---
|
||||
|
||||
## Method 1: XML Configuration Modification (Recommended)
|
||||
|
||||
The most robust and granular method involves modifying the device's private configuration file. This is the primary method used by **SoundCork**'s migration logic to redirect devices to a local service instance.
|
||||
|
||||
### Technical Details
|
||||
- **File Path**: `/opt/Bose/etc/SoundTouchSdkPrivateCfg.xml`
|
||||
- **Mechanism**: The device firmware reads this XML file at boot to determine service URLs.
|
||||
- **Fields to Modify**:
|
||||
- `<margeServerUrl>`: Redirects account/streaming calls.
|
||||
- `<statsServerUrl>`: Redirects telemetry.
|
||||
- `<swUpdateUrl>`: Redirects update checks.
|
||||
- `<bmxRegistryUrl>`: Redirects service discovery.
|
||||
|
||||
### Implementation
|
||||
Requires SSH access to the device.
|
||||
```xml
|
||||
<SoundTouchSdkPrivateCfg>
|
||||
<margeServerUrl>http://192.168.1.10:8000/marge</margeServerUrl>
|
||||
<statsServerUrl>http://192.168.1.10:8000</statsServerUrl>
|
||||
<swUpdateUrl>http://192.168.1.10:8000/updates/soundtouch</swUpdateUrl>
|
||||
<bmxRegistryUrl>http://192.168.1.10:8000/bmx/registry/v1/services</bmxRegistryUrl>
|
||||
</SoundTouchSdkPrivateCfg>
|
||||
```
|
||||
|
||||
### Pros & Cons
|
||||
| Pros | Cons |
|
||||
| :--- | :--- |
|
||||
| **Granular Control**: Redirect specific services while leaving others (e.g., updates) intact. | **Requires SSH**: Must have root/SSH access to the device. |
|
||||
| **Persistent**: Survives software updates (usually). | **Syntax Sensitive**: Errors in XML can cause boot issues or service failures. |
|
||||
| **Native**: Uses the device's built-in configuration mechanism. | |
|
||||
|
||||
---
|
||||
|
||||
## Method 2: `/etc/hosts` DNS Override
|
||||
|
||||
This method uses the standard Linux hosts file to redirect traffic at the network level within the device. It is often used as a quick alternative in the **ÜberBöse API** community for global redirection.
|
||||
|
||||
### Technical Details
|
||||
- **File Path**: `/etc/hosts`
|
||||
- **Mechanism**: Overrides DNS resolution for Bose domains to point to a local IP.
|
||||
- **Resolution Order**: SoundTouch devices use the standard Linux Name Service Switch (`/etc/nsswitch.conf`). The default configuration (`hosts: files dns`) ensures that `/etc/hosts` is consulted *before* any external DNS lookups. This makes the redirection highly reliable for all system processes, including `curl`, `BoseApp`, and `IoT`.
|
||||
|
||||
### Implementation
|
||||
Requires SSH access. Add entries for the target domains:
|
||||
```text
|
||||
192.168.1.10 streaming.bose.com
|
||||
192.168.1.10 updates.bose.com
|
||||
192.168.1.10 stats.bose.com
|
||||
```
|
||||
|
||||
### Pros & Cons
|
||||
| Pros | Cons |
|
||||
| :--- | :--- |
|
||||
| **Simple**: Easy to understand and implement. | **Requires SSH**: Must have root access. |
|
||||
| **Universal**: Affects all processes on the device attempting to reach those domains. | **HTTPS Issues**: Redirecting HTTPS domains to a local IP will cause SSL certificate errors unless the device is patched to skip verification or trust a custom CA. |
|
||||
| | **Brittle**: Some firmware versions may overwrite `/etc/hosts` on reboot. |
|
||||
|
||||
---
|
||||
|
||||
## Method 3: Binary Patching
|
||||
|
||||
A low-level approach where the actual compiled binaries (e.g., `BoseApp`, `IoT`) are modified to change hardcoded URL patterns. Research into these patterns has been documented in both **SoundCork** (Issue #128) and **ÜberBöse API** research.
|
||||
|
||||
### Technical Details
|
||||
- **Target Binaries**: `/opt/Bose/BoseApp`, `/opt/Bose/IoT`, `/opt/Bose/lib/libBmxAccountHsm.so`
|
||||
- **Mechanism**:
|
||||
- **URL Replacement**: Using a hex editor to search for string patterns like `https://streaming.bose.com` and replacing them with a custom URL of the **exact same length**.
|
||||
- **Regex Neutralization**: Some libraries (like `libBmxAccountHsm.so`) perform a validation check called `IsItBose` using a hardcoded regex. This regex prevents the device from connecting to non-Bose domains even if the URL is changed in the configuration.
|
||||
|
||||
#### The `IsItBose` Regex Patch
|
||||
Research in the **SoundCork** community (Issue #62) identified a specific regex in `libBmxAccountHsm.so` that enforces Bose/Apigee domain usage:
|
||||
`^https:\/\/bose-[a-zA-Z0-9\.\_\-\$\%]\+\.apigee\.net\/`
|
||||
|
||||
By patching this regex to be more "lax", the device can be made to accept any custom domain.
|
||||
|
||||
**Example Patch**:
|
||||
Using `sed` to replace the strict regex with a broad match while preserving the original string length:
|
||||
```bash
|
||||
sed "s#\^https:....bose.\+apigee..net..#http[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa]*#g" \
|
||||
< libBmxAccountHsm.so.orig > libBmxAccountHsm.so.patched
|
||||
```
|
||||
|
||||
### Implementation
|
||||
1. Copy the target binary or library from the device to a PC.
|
||||
2. Use a hex editor or `sed` to locate and patch the URL strings or regex patterns.
|
||||
3. Copy the patched file back to the device.
|
||||
4. Restore execution permissions and reboot.
|
||||
|
||||
### Pros & Cons
|
||||
| Pros | Cons |
|
||||
| :--- | :--- |
|
||||
| **Bypass Config**: Works even if the firmware ignores XML settings. | **High Risk**: Modifying binaries can lead to permanent bricks or boot loops. |
|
||||
| **Hardcoded Redirects**: Can catch URLs that aren't exposed in configuration files. | **Length Constraint**: Custom URLs must fit within the space of the original strings. |
|
||||
| | **Firmware Specific**: Patches must be reapplied after every software update. |
|
||||
| | **Complexity**: Requires understanding of binary structures and potential checksums. |
|
||||
|
||||
---
|
||||
|
||||
## Comparison & Usage Strategy
|
||||
|
||||
### Summary Table
|
||||
|
||||
| Method | Primary Use Case | Ease | Safety | Persistence | Granularity |
|
||||
| :--- | :--- | :---: | :---: | :---: | :---: |
|
||||
| **XML Config** | Logical service redirection | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
|
||||
| **`/etc/hosts`** | Quick global DNS override | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐ |
|
||||
| **Binary Patch** | Bypassing hardcoded checks | ⭐ | ⭐ | ⭐ | ⭐⭐⭐ |
|
||||
|
||||
---
|
||||
|
||||
## Combining Methods: When is one not enough?
|
||||
|
||||
A common question is whether these methods can be used in isolation or if they must be combined. The answer depends on your specific firmware version and the target service.
|
||||
|
||||
### Scenario A: XML Config Only (The Ideal Case)
|
||||
If your firmware does not strictly enforce the `IsItBose` check for the specific URLs you are changing, **Method 1 (XML)** is sufficient. This is the cleanest approach and is used by the `soundtouch-service` migration tool.
|
||||
|
||||
### Scenario B: XML Config + Binary Patching (The "Locked" Case)
|
||||
On some newer firmware versions, even if you change the `<margeServerUrl>` in the XML to `http://192.168.1.10`, the internal library (`libBmxAccountHsm.so`) will validate the string against the hardcoded Bose regex.
|
||||
* **Symptom**: The device ignores the XML setting or fails to connect despite the correct URL being present.
|
||||
* **Solution**: You **must** apply the **Binary Patch (Method 3)** to neutralize the `IsItBose` check *in addition* to the XML change.
|
||||
|
||||
### Scenario C: `/etc/hosts` + Custom CA (The "Clean Deep Redirect")
|
||||
If you use `/etc/hosts` to point `streaming.bose.com` to a local IP and want to avoid binary patching.
|
||||
* **Requirement 1**: Your local server must handle HTTPS (port 443).
|
||||
* **Requirement 2**: You must inject your Root CA into the device's trust store.
|
||||
* **Automated Tool**: The `soundtouch-service` now supports this via the `/setup/migrate/{deviceIP}?method=hosts` endpoint.
|
||||
* **CA Download**: You can download the auto-generated Root CA from `http://<your-server>:8000/setup/ca.crt`.
|
||||
* **Benefit**: Maintains system integrity (no binary changes) and full end-to-end encryption.
|
||||
|
||||
### Scenario D: `/etc/hosts` + Binary Patching (The "Legacy Deep Redirect")
|
||||
If you cannot or do not want to manage certificates, but still use `/etc/hosts` for DNS redirection.
|
||||
* **Requirement 1**: Your local server must handle HTTPS (port 443).
|
||||
* **Requirement 2**: Since the certificate will be invalid (mismatched domain/CA), you must patch the binary to **skip SSL verification** (see [Option 2](#option-2-ssl-verification-bypass) below).
|
||||
* **Risk**: Less secure and higher risk of bricking due to binary modification.
|
||||
|
||||
### Scenario E: The Triple-Threat (Total Control)
|
||||
For developers creating a completely isolated "dark" environment (no internet at all):
|
||||
1. **XML**: Point all URLs to local services.
|
||||
2. **Binary Patch**: Neutralize `IsItBose` to allow non-Bose domains/IPs.
|
||||
3. **`/etc/hosts`**: Redirect hardcoded domains that aren't exposed in the XML (like analytics or NTP) to prevent leakage to the real Bose cloud.
|
||||
4. **Process Instrumentation**: Use [SoundTouch Hook](https://github.com/CodeFinder2/bose-soundtouch-hook) to monitor and override internal behavior in real-time. This is particularly useful for handling unknown hostnames or deep-hooking into service discovery logic that might bypass standard DNS lookups.
|
||||
|
||||
---
|
||||
|
||||
## Handling HTTPS & SSL Certificates
|
||||
|
||||
When redirecting HTTPS traffic to a custom service, SoundTouch devices will fail the SSL handshake because they do not trust your local server's certificate.
|
||||
|
||||
### Option 1: Custom CA Certificate (Recommended)
|
||||
|
||||
As suggested by community members, you can configure the device to trust your own Root CA. This allows for secure HTTPS communication without patching binaries.
|
||||
|
||||
**Technical Steps**:
|
||||
1. **Generate a Root CA** and issue a certificate for the target domain (e.g., `streaming.bose.com`).
|
||||
2. **SSH into the device** and copy your `rootCA.crt` to `/usr/share/ca-certificates/custom/`.
|
||||
3. **Update the Trust Store**:
|
||||
- **Method A (Append to Bundle)**: `cat /usr/share/ca-certificates/custom/rootCA.crt >> /etc/pki/tls/certs/ca-bundle.crt`
|
||||
- **Method B (Symlinks)**: Add the certificate to `/etc/ssl/certs/` and create a hash symlink using `c_rehash` (if available) or manual mapping.
|
||||
|
||||
**Pros & Cons**:
|
||||
| Pros | Cons |
|
||||
| :--- | :--- |
|
||||
| **Secure**: Maintains end-to-end encryption. | **Requires SSH**: Must have root access to modify the trust store. |
|
||||
| **Clean**: No binary patching required for SSL bypass. | **Update Risk**: Firmware updates might overwrite the `ca-bundle.crt`. |
|
||||
|
||||
### Option 2: SSL Verification Bypass
|
||||
|
||||
If you cannot or do not want to manage certificates, you can patch the binary to skip certificate verification.
|
||||
|
||||
**Target**: `libBmxAccountHsm.so` or `BoseApp`
|
||||
**Mechanism**: Locating the SSL verification function (often in the internal curl-based or openssl-based logic) and forcing it to return "Success" regardless of the certificate status.
|
||||
|
||||
---
|
||||
|
||||
## Recommendation
|
||||
|
||||
1. **Start with Method 1 (XML Modification)**. It is the least invasive and most likely to work across different models.
|
||||
2. **Verify connectivity**. If the device refuses to connect to your custom endpoint, check logs for "IsItBose" or validation failures.
|
||||
3. **Apply Method 3 (Binary Patching)** only if Method 1 is being actively blocked by the firmware's validation logic.
|
||||
4. **Avoid Method 2 (`/etc/hosts`)** unless you are prepared to handle SSL certificate complexities or are performing quick temporary tests.
|
||||
@@ -0,0 +1,189 @@
|
||||
# IoT Configuration Quick Reference
|
||||
|
||||
## Key Files and Locations
|
||||
|
||||
| File/Location | Purpose | Notes |
|
||||
|-----------------------------------------|------------------------|-----------------------------------------|
|
||||
| `/mnt/nv/BoseApp-Persistence/1/IoT.xml` | Main IoT configuration | Contains clientID, endpoint, deployment |
|
||||
| `/opt/Bose/IoT` | IoT service binary | ARM executable, AWS IoT SDK |
|
||||
| `/mnt/nv/IoTCerts/` | Certificate storage | Device certs and private keys |
|
||||
| `/etc/init.d/SoundTouch` | System startup script | Creates directory structure |
|
||||
| `/opt/Bose/etc/Shepherd-noncore.xml` | Service configuration | Defines IoT daemon startup |
|
||||
|
||||
## Configuration Parameters
|
||||
|
||||
### IoT.xml Structure
|
||||
```xml
|
||||
<Configuration
|
||||
clientID="[UUID]"
|
||||
iotEndpoint="[AWS_IOT_ENDPOINT]"
|
||||
deployment="PROD" />
|
||||
```
|
||||
|
||||
### Device-Specific Values
|
||||
- **ST20**: `clientID="577ecfcc-2db3-4989-92c9-76d7704f9fb3"`
|
||||
- **ST10**: `clientID="eb1a6d8f-0bb1-4aa7-9113-ea673fcef96e"`
|
||||
- **Endpoint**: `a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com` (XML)
|
||||
- **Backup Endpoint**: `amqmidtcohfms.iot.us-east-1.amazonaws.com` (hardcoded)
|
||||
|
||||
## Protocol Stack
|
||||
|
||||
```
|
||||
Application Layer: AWS IoT Device Shadows (JSON)
|
||||
Presentation Layer: RapidJSON parsing/serialization
|
||||
Session Layer: MQTT v3.1.1
|
||||
Transport Layer: TLS v1.2
|
||||
Network Layer: TCP/IP
|
||||
```
|
||||
|
||||
## Certificate Files
|
||||
|
||||
| File | Location | Purpose |
|
||||
|-----------------------|---------------------|---------------------------|
|
||||
| `iot-cert.pem.crt` | `/mnt/nv/IoTCerts/` | Device client certificate |
|
||||
| `iot-private.pem.key` | `/mnt/nv/IoTCerts/` | Device private key |
|
||||
| `rootCA.crt` | `/var/lib/iot/` | AWS IoT Root CA |
|
||||
|
||||
## MQTT Topics
|
||||
|
||||
### Shadow Operations
|
||||
```
|
||||
$aws/things/{clientID}/shadow/update
|
||||
$aws/things/{clientID}/shadow/update/accepted
|
||||
$aws/things/{clientID}/shadow/update/rejected
|
||||
$aws/things/{clientID}/shadow/delete
|
||||
```
|
||||
|
||||
### JSON Payload Examples
|
||||
|
||||
#### Device State Report
|
||||
```json
|
||||
{
|
||||
"state": {
|
||||
"reported": {
|
||||
"deviceState": "CONNECTED",
|
||||
"powerState": "ON",
|
||||
"zoneState": "...",
|
||||
"groupState": "..."
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Disconnection Message
|
||||
```json
|
||||
{
|
||||
"state": {
|
||||
"reported": {
|
||||
"deviceState": "DISCONNECTED"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Process Information
|
||||
|
||||
- **IoT Service PID**: 1837
|
||||
- **BoseApp PID**: 1846
|
||||
- **Daemon Manager**: Shepherd
|
||||
- **Service Type**: Non-core (stopped during updates)
|
||||
|
||||
## Registration Flow
|
||||
|
||||
1. Device generates X.509 CSR
|
||||
2. Calls `https://voice.api.bose.io/alexa/certificate`
|
||||
3. Receives device certificate
|
||||
4. Stores cert/key in `/mnt/nv/IoTCerts/`
|
||||
5. Connects to AWS IoT using certificate auth
|
||||
|
||||
## Directory Creation (Init Script)
|
||||
|
||||
```bash
|
||||
mkdir -p /mnt/nv/BoseLog /mnt/nv/IoTCerts /mnt/nv/BoseApp-Persistence/1
|
||||
mkdir -m 700 -p /mnt/nv/BoseApp-Persistence/1/Keys
|
||||
```
|
||||
|
||||
## Error Messages and Debugging
|
||||
|
||||
### Common Log Messages
|
||||
- `"Connection attempt %u to MQTT port at host %s"`
|
||||
- `"MQTT port not available. Retrying in %u seconds"`
|
||||
- `"Device connected with MQTT"`
|
||||
- `"got shadow response: accepted. Payload: %s"`
|
||||
- `"Failed to register device and get certificate, retrying"`
|
||||
|
||||
### Connection States
|
||||
- `"MQTT port is open"`
|
||||
- `"Successfully connected to MQTT server"`
|
||||
- `"Disconnecting from IoT server"`
|
||||
- `"UpdateShadow called when network is not ready"`
|
||||
|
||||
## Integration Points
|
||||
|
||||
### AWS Services
|
||||
- AWS IoT Core (MQTT broker)
|
||||
- AWS IoT Device Management (certificates)
|
||||
- AWS IoT Device Shadows (state sync)
|
||||
|
||||
### Bose Ecosystem
|
||||
- Mobile apps (remote control)
|
||||
- Alexa integration (voice commands)
|
||||
- Multi-room audio (zone coordination)
|
||||
- OTA updates (firmware management)
|
||||
|
||||
## Quick Troubleshooting
|
||||
|
||||
1. **No IoT connectivity**: Check certificate files in `/mnt/nv/IoTCerts/`
|
||||
2. **Certificate errors**: Verify registration endpoint accessibility
|
||||
3. **MQTT failures**: Check both primary and backup endpoints
|
||||
4. **Config issues**: Validate IoT.xml format and clientID uniqueness
|
||||
5. **Service not starting**: Check Shepherd configuration and process status
|
||||
|
||||
## MQTT Monitoring Capabilities
|
||||
|
||||
### Direct Access with Device Credentials
|
||||
```bash
|
||||
# Subscribe to device shadow events (own device only)
|
||||
mosquitto_sub -h a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com \
|
||||
-p 8883 --cafile /var/lib/iot/rootCA.crt \
|
||||
--cert /mnt/nv/IoTCerts/iot-cert.pem.crt \
|
||||
--key /mnt/nv/IoTCerts/iot-private.pem.key \
|
||||
-t '$aws/things/577ecfcc-2db3-4989-92c9-76d7704f9fb3/shadow/#'
|
||||
```
|
||||
|
||||
### AWS IoT Policy Restrictions
|
||||
- Device certificates limited to own clientID topics only
|
||||
- No wildcard subscriptions across devices
|
||||
- IP/location restrictions may apply
|
||||
- Certificate revocation for unusual activity
|
||||
|
||||
### Alternative Monitoring Methods
|
||||
```bash
|
||||
# Network traffic capture (less intrusive)
|
||||
tcpdump -i eth0 -s0 -w soundtouch_iot.pcap host a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com
|
||||
|
||||
# Monitor connection patterns
|
||||
tcpdump -i eth0 -n "host a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com and port 8883"
|
||||
```
|
||||
|
||||
### Expected Message Examples
|
||||
```json
|
||||
// Power state change
|
||||
{"state":{"reported":{"powerState":"ON","deviceState":"CONNECTED"}}}
|
||||
|
||||
// Volume adjustment
|
||||
{"state":{"reported":{"volume":25,"muted":false}}}
|
||||
|
||||
// Zone configuration
|
||||
{"state":{"reported":{"zoneState":"master","groupMembers":["device1"]}}}
|
||||
```
|
||||
|
||||
## Security Notes
|
||||
|
||||
- TLS 1.2 encryption for all communications
|
||||
- X.509 mutual authentication
|
||||
- Private keys stored with 700 permissions
|
||||
- No hardcoded credentials in binaries
|
||||
- Automatic certificate lifecycle management
|
||||
- **Monitoring Constraints**: Device credentials restricted to own device topics
|
||||
- **Ethical Consideration**: Only monitor devices you own
|
||||
@@ -0,0 +1,370 @@
|
||||
# IoT Configuration Analysis
|
||||
|
||||
## Overview
|
||||
|
||||
This document provides a detailed analysis of the AWS IoT configuration system used by Bose SoundTouch devices, based on firmware backup analysis from ST10 and ST20 models.
|
||||
|
||||
## Configuration Files
|
||||
|
||||
### IoT.xml Location and Content
|
||||
|
||||
The IoT configuration is stored in XML format at:
|
||||
- **Path**: `/mnt/nv/BoseApp-Persistence/1/IoT.xml`
|
||||
- **Purpose**: Contains AWS IoT Core connection parameters
|
||||
|
||||
#### ST20 Configuration
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<Configuration clientID="uuid1"
|
||||
iotEndpoint="a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com"
|
||||
deployment="PROD" />
|
||||
```
|
||||
|
||||
#### ST10 Configuration
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<Configuration clientID="uuid2"
|
||||
iotEndpoint="a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com"
|
||||
deployment="PROD" />
|
||||
```
|
||||
|
||||
### Key Observations
|
||||
- Each device has a unique `clientID` (UUID format)
|
||||
- Both devices use the same AWS IoT endpoint
|
||||
- Both are configured for production deployment (`PROD`)
|
||||
|
||||
## Binary Analysis
|
||||
|
||||
### Primary IoT Service Binary
|
||||
|
||||
**Location**: `/opt/Bose/IoT`
|
||||
- **Type**: ARM ELF 32-bit executable
|
||||
- **Purpose**: Main IoT daemon process
|
||||
- **Framework**: AWS IoT SDK for C++
|
||||
|
||||
### Certificate and Key Management
|
||||
|
||||
The IoT binary manages the following certificate files:
|
||||
|
||||
| File | Location | Purpose |
|
||||
|-----------------------|---------------------|-----------------------------|
|
||||
| `iot-cert.pem.crt` | `/mnt/nv/IoTCerts/` | Device client certificate |
|
||||
| `iot-private.pem.key` | `/mnt/nv/IoTCerts/` | Device private key |
|
||||
| `rootCA.crt` | `/var/lib/iot/` | AWS IoT Root CA certificate |
|
||||
|
||||
### Certificate Registration Process
|
||||
|
||||
1. **CSR Generation**: Device generates X.509 certificate signing request
|
||||
2. **Registration Endpoint**: `https://voice.api.bose.io/alexa/certificate`
|
||||
3. **Certificate Storage**: Certificates stored in `/mnt/nv/IoTCerts/`
|
||||
4. **Automatic Provisioning**: Process appears to be automated during device setup
|
||||
|
||||
## Protocol Analysis
|
||||
|
||||
### Connection Details
|
||||
|
||||
- **Protocol**: MQTT over TLS 1.2
|
||||
- **Port**: Standard MQTT over SSL (likely 8883)
|
||||
- **Authentication**: X.509 client certificate mutual authentication
|
||||
- **Endpoint Redundancy**:
|
||||
- Primary (hardcoded): `amqmidtcohfms.iot.us-east-1.amazonaws.com`
|
||||
- Fallback (XML config): `a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com`
|
||||
|
||||
### AWS IoT Device Shadow Integration
|
||||
|
||||
The system uses AWS IoT Device Shadows for state management:
|
||||
|
||||
#### Topic Structure
|
||||
```
|
||||
$aws/things/{thing_name}/shadow/update
|
||||
$aws/things/{thing_name}/shadow/update/accepted
|
||||
$aws/things/{thing_name}/shadow/update/rejected
|
||||
$aws/things/{thing_name}/shadow/delete
|
||||
```
|
||||
|
||||
#### Shadow JSON Format
|
||||
```json
|
||||
{
|
||||
"state": {
|
||||
"desired": {},
|
||||
"reported": {
|
||||
"deviceState": "CONNECTED|DISCONNECTED",
|
||||
"powerState": "ON|OFF",
|
||||
"zoneState": "...",
|
||||
"groupState": "..."
|
||||
}
|
||||
},
|
||||
"version": 0,
|
||||
"clientToken": "...",
|
||||
"timestamp": 0
|
||||
}
|
||||
```
|
||||
|
||||
### Message Types
|
||||
|
||||
1. **Device State Updates**
|
||||
- Connection status (`CONNECTED`/`DISCONNECTED`)
|
||||
- Power state changes
|
||||
- Audio zone configuration
|
||||
- Multi-room grouping status
|
||||
|
||||
2. **Shadow Delta Processing**
|
||||
- Receives desired state changes
|
||||
- Updates device configuration
|
||||
- Reports new state back to shadow
|
||||
|
||||
## System Integration
|
||||
|
||||
### Service Management
|
||||
|
||||
The IoT service is managed by the Shepherd daemon system:
|
||||
|
||||
**Configuration**: `/opt/Bose/etc/Shepherd-noncore.xml`
|
||||
```xml
|
||||
<ShepherdConfig>
|
||||
<daemon name="STSCertified"/>
|
||||
<daemon name="IoT"/>
|
||||
<daemon name="TPDA">
|
||||
<arg>-c</arg>
|
||||
<arg>/opt/Bose/etc/Voice.xml</arg>
|
||||
</daemon>
|
||||
</ShepherdConfig>
|
||||
```
|
||||
|
||||
### Directory Structure Creation
|
||||
|
||||
The SoundTouch init script (`/etc/init.d/SoundTouch`) ensures proper directory structure:
|
||||
|
||||
```bash
|
||||
mkdir -p /mnt/nv/BoseLog /mnt/nv/IoTCerts /mnt/nv/BoseApp-Persistence/1
|
||||
mkdir -m 700 -p /mnt/nv/BoseApp-Persistence/1/Keys
|
||||
```
|
||||
|
||||
### Process Information
|
||||
|
||||
From runtime analysis (`/var/run/shepherd/pids`):
|
||||
- IoT service runs as PID 1837
|
||||
- BoseApp service runs as PID 1846
|
||||
- Both services are active during normal operation
|
||||
|
||||
## Configuration Dependencies
|
||||
|
||||
### Files That Reference IoT Configuration
|
||||
|
||||
1. **IoT Binary** (`/opt/Bose/IoT`)
|
||||
- Primary consumer of IoT.xml configuration
|
||||
- Contains hardcoded backup endpoints
|
||||
- Manages certificate lifecycle
|
||||
|
||||
2. **BoseApp Binary** (`/opt/Bose/BoseApp`)
|
||||
- References BoseApp-Persistence directory structure
|
||||
- May trigger IoT updates based on device state changes
|
||||
|
||||
3. **SoundTouch Init Script** (`/etc/init.d/SoundTouch`)
|
||||
- Creates necessary directory structure
|
||||
- Ensures proper permissions for certificate storage
|
||||
|
||||
4. **Shepherd Configuration** (`/opt/Bose/etc/Shepherd-noncore.xml`)
|
||||
- Defines IoT service startup parameters
|
||||
- Manages service lifecycle
|
||||
|
||||
## Security Considerations
|
||||
|
||||
### Certificate Management
|
||||
- Private keys stored with 700 permissions
|
||||
- Certificates managed automatically by the device
|
||||
- Registration process appears to use device-specific authentication
|
||||
|
||||
### Network Security
|
||||
- All communication over TLS 1.2
|
||||
- Mutual authentication using X.509 certificates
|
||||
- AWS IoT Core provides additional access controls
|
||||
|
||||
### Configuration Protection
|
||||
- Configuration files stored in persistent storage
|
||||
- Directory structure created with appropriate permissions
|
||||
- No hardcoded credentials in binaries (uses certificate-based auth)
|
||||
|
||||
## Integration Points
|
||||
|
||||
### AWS Services
|
||||
- **AWS IoT Core**: Primary messaging and device management
|
||||
- **AWS IoT Device Management**: Certificate provisioning
|
||||
- **AWS IoT Device Shadows**: State synchronization
|
||||
|
||||
### Bose Services
|
||||
- **Mobile Applications**: Remote control and monitoring
|
||||
- **Alexa Integration**: Voice control capabilities
|
||||
- **Multi-room Audio**: Zone and group coordination
|
||||
|
||||
### Device Functions
|
||||
- **Power Management**: Remote power on/off
|
||||
- **Audio Control**: Volume, source selection
|
||||
- **Network Configuration**: WiFi and connectivity settings
|
||||
- **Firmware Updates**: OTA update coordination
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
1. **Certificate Problems**
|
||||
- Check `/mnt/nv/IoTCerts/` for valid certificates
|
||||
- Verify certificate registration endpoint accessibility
|
||||
- Ensure proper file permissions (600 for keys)
|
||||
|
||||
2. **Connection Issues**
|
||||
- Verify both primary and fallback endpoints
|
||||
- Check TLS 1.2 support and cipher suites
|
||||
- Validate clientID uniqueness
|
||||
|
||||
3. **Configuration Issues**
|
||||
- Ensure IoT.xml has proper XML format
|
||||
- Verify clientID is valid UUID format
|
||||
- Check deployment parameter matches environment
|
||||
|
||||
### Debug Information
|
||||
|
||||
The IoT binary provides extensive logging for:
|
||||
- MQTT connection attempts and status
|
||||
- Certificate loading and validation
|
||||
- Shadow message processing
|
||||
- Network state changes
|
||||
|
||||
## MQTT Monitoring and Security Considerations
|
||||
|
||||
### Direct MQTT Access with Device Credentials
|
||||
|
||||
With access to the device's private key and certificate, it's technically possible to subscribe to MQTT events:
|
||||
|
||||
```bash
|
||||
# Subscribe to device shadow events
|
||||
mosquitto_sub -h a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com \
|
||||
-p 8883 --cafile /var/lib/iot/rootCA.crt \
|
||||
--cert /mnt/nv/IoTCerts/iot-cert.pem.crt \
|
||||
--key /mnt/nv/IoTCerts/iot-private.pem.key \
|
||||
-t '$aws/things/_uuid_/shadow/#'
|
||||
```
|
||||
|
||||
### Security Constraints and Limitations
|
||||
|
||||
#### AWS IoT Policy Restrictions
|
||||
Device certificates are bound to specific policies that typically restrict:
|
||||
- Access to device-specific topics only (`$aws/things/{clientID}/shadow/*`)
|
||||
- No wildcard subscriptions across multiple devices
|
||||
- Limited publish/subscribe permissions
|
||||
- Possible IP geolocation restrictions
|
||||
|
||||
#### Example Policy Structure
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": "iot:Connect",
|
||||
"Resource": "arn:aws:iot:us-east-1:*:client/${iot:ClientId}"
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": ["iot:Publish", "iot:Subscribe", "iot:Receive"],
|
||||
"Resource": [
|
||||
"arn:aws:iot:us-east-1:*:topic/$aws/things/${iot:ClientId}/shadow/*",
|
||||
"arn:aws:iot:us-east-1:*:topicfilter/$aws/things/${iot:ClientId}/shadow/*"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### Additional Security Measures
|
||||
- Certificate revocation for unusual activity
|
||||
- Device fingerprinting and connection frequency limits
|
||||
- Service shutdown timeline (May 2026) affecting endpoint availability
|
||||
|
||||
### Alternative Monitoring Approaches
|
||||
|
||||
#### Network Traffic Capture
|
||||
A less intrusive method to analyze MQTT communication patterns:
|
||||
|
||||
```bash
|
||||
# Capture encrypted MQTT traffic from the actual device
|
||||
tcpdump -i eth0 -s0 -w soundtouch_iot.pcap host a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com
|
||||
|
||||
# Monitor connection patterns
|
||||
tcpdump -i eth0 -n "host a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com and port 8883"
|
||||
```
|
||||
|
||||
#### Local MQTT Broker Setup
|
||||
For development and testing, create a local MQTT broker that mimics AWS IoT behavior:
|
||||
|
||||
```bash
|
||||
# Install and configure Mosquitto
|
||||
sudo apt-get install mosquitto mosquitto-clients
|
||||
|
||||
# Create test shadow topics
|
||||
mosquitto_pub -h localhost -t '$aws/things/test-device/shadow/update' \
|
||||
-m '{"state":{"reported":{"deviceState":"CONNECTED"}}}'
|
||||
```
|
||||
|
||||
### Ethical and Legal Considerations
|
||||
|
||||
- **Device Ownership**: Only monitor devices you own
|
||||
- **Terms of Service**: Using credentials outside device context may violate Bose ToS
|
||||
- **Unauthorized Access**: Accessing Bose's AWS infrastructure could be considered inappropriate
|
||||
- **Research Purpose**: Limit monitoring to understanding message formats for local alternatives
|
||||
|
||||
### Expected Message Examples
|
||||
|
||||
If monitoring is successful, typical shadow messages include:
|
||||
|
||||
```json
|
||||
// Power state change
|
||||
{
|
||||
"state": {
|
||||
"reported": {
|
||||
"powerState": "ON",
|
||||
"deviceState": "CONNECTED",
|
||||
"timestamp": 1703875200
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Volume adjustment
|
||||
{
|
||||
"state": {
|
||||
"reported": {
|
||||
"volume": 25,
|
||||
"muted": false
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Zone configuration
|
||||
{
|
||||
"state": {
|
||||
"reported": {
|
||||
"zoneState": "master",
|
||||
"groupMembers": ["device1", "device2"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Recommended Research Approach
|
||||
|
||||
1. **Document Message Formats**: Capture and analyze JSON structures
|
||||
2. **Understand State Transitions**: Map device actions to shadow updates
|
||||
3. **Build Local Alternative**: Use insights to create local MQTT shadow service
|
||||
4. **Prepare for Service Shutdown**: Develop migration strategy before May 2026
|
||||
|
||||
## Conclusion
|
||||
|
||||
The Bose SoundTouch IoT configuration system is a sophisticated implementation using AWS IoT Core for real-time device management. The system provides:
|
||||
|
||||
- Secure, certificate-based authentication
|
||||
- Reliable bi-directional communication
|
||||
- Comprehensive device state management
|
||||
- Integration with voice assistants and mobile applications
|
||||
- Robust error handling and retry mechanisms
|
||||
|
||||
This architecture enables seamless remote control, monitoring, and coordination of SoundTouch devices across multiple platforms and services.
|
||||
@@ -0,0 +1,84 @@
|
||||
# Upstream URLs & Domains Analysis
|
||||
|
||||
This document provides a comprehensive overview of the upstream Bose cloud services and domains that SoundTouch devices communicate with. These details were gathered from firmware analysis of ST10/ST20 devices, binary string extraction, and community research from the **SoundCork** project (Issue #128).
|
||||
|
||||
## Core Service Domains
|
||||
|
||||
SoundTouch devices use a set of primary domains for their operation. These are often configurable via the `SoundTouchSdkPrivateCfg.xml` file.
|
||||
|
||||
| Service | Primary Domain | Purpose |
|
||||
|:--------------------|:------------------------|:--------------------------------------------------------------------|
|
||||
| **Marge** | `streaming.bose.com` | Account management, streaming source providers, and preset sync. |
|
||||
| **BMX Registry** | `content.api.bose.io` | Bose Media eXchange service discovery and registry. |
|
||||
| **Stats/Analytics** | `events.api.bosecm.com` | Telemetry, device events, and usage statistics. |
|
||||
| **Software Update** | `worldwide.bose.com` | Firmware update checks and downloads (path: `/updates/soundtouch`). |
|
||||
| **Voice/Alexa** | `voice.api.bose.io` | Token management for Amazon Alexa integration. |
|
||||
|
||||
## Internal & Development Domains
|
||||
|
||||
Analysis of device binaries (`BoseApp`, `IoT`) and community findings revealed several internal, integration, and development domains used by Bose.
|
||||
|
||||
### Marge & Auth Proxies
|
||||
- `bose-test.apigee.net/margeproxy` (Integration/Test proxy)
|
||||
- `bose-test.apigee.net/margeproxyefe`
|
||||
- `streamingstg.bose.com` (Staging)
|
||||
- `streamingintoauth.bose.com` (Internal Auth)
|
||||
- `streamingefeintoauth.bose.com` (Internal EFE Auth)
|
||||
- `streamingefeint.bose.com`
|
||||
|
||||
### BMX & Content Registry
|
||||
- `test.content.api.bose.io`
|
||||
- `content.api.bose.io/bmx/registry/v1/services`
|
||||
- `test.content.api.bose.io/bmx/int-registry/v1/services`
|
||||
- `test.content.api.bose.io/bmx/efe-registry/v1/services`
|
||||
|
||||
### Stats & Analytics
|
||||
- `eventsdev.api.bosecm.com`
|
||||
- `eventsefe.api.bosecm.com`
|
||||
- `eventsdev.bosecm.com`
|
||||
|
||||
### Software Updates
|
||||
- `worldwide.bose.com/updates/soundtouch-int`
|
||||
- `worldwide.bose.com/updates/soundtouch-efe`
|
||||
|
||||
## Third-Party Services
|
||||
|
||||
Devices also communicate directly with third-party providers for specific features.
|
||||
|
||||
- **Pandora**:
|
||||
- `device-tuner.pandora.com`
|
||||
- `device-tuner-beta.savagebeast.com`
|
||||
- **Amazon AVS**:
|
||||
- `avs.na.amazonalexa.com`
|
||||
|
||||
## Hardcoded Validation (IsItBose)
|
||||
|
||||
As documented in [DEVICE-REDIRECT-METHODS.md](DEVICE-REDIRECT-METHODS.md#method-3-binary-patching), the `libBmxAccountHsm.so` library contains a hardcoded regex to validate these URLs:
|
||||
|
||||
`^https:\/\/bose-[a-zA-Z0-9\.\_\-\$\%]\+\.apigee\.net\/`
|
||||
|
||||
This regex ensures that certain critical services must reside on the `apigee.net` domain under a `bose-` prefix, unless patched.
|
||||
|
||||
## Configuration File References
|
||||
|
||||
On-device, these URLs are primarily managed in the following files:
|
||||
|
||||
1. **`/opt/Bose/etc/SoundTouchSdkPrivateCfg.xml`**:
|
||||
* `<margeServerUrl>`
|
||||
* `<statsServerUrl>`
|
||||
* `<swUpdateUrl>`
|
||||
* `<bmxRegistryUrl>`
|
||||
2. **`/opt/Bose/etc/Voice.xml`**:
|
||||
* `<TPDATokenUrl>` (Points to `voice.api.bose.io`)
|
||||
3. **`/opt/Bose/etc/HandCraftedWebServer-SoundTouch.xml`**:
|
||||
* Contains internal local API mapping.
|
||||
|
||||
## Conclusion for Offline Operation
|
||||
|
||||
To achieve full offline operation or redirection to a custom service (like `soundtouch-service`), all of the above domains must either be redirected via DNS (`/etc/hosts`) or updated in the device's XML configuration files. For domains not exposed in XML, binary patching or DNS-level redirection is the only option.
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
- [SoundCork Issue #128: Endpoint and URL Listing](https://github.com/deborahgu/soundcork/issues/128#issuecomment-3892933337)
|
||||
- [Bose SoundTouch Web API v1.0 Specification](https://assets.bosecreative.com/m/496577402d128874/original/SoundTouch-Web-API.pdf)
|
||||
@@ -1,7 +1,7 @@
|
||||
# SoundTouch API Comparison: Community Wiki vs Current Implementation
|
||||
|
||||
**Date:** January 2026
|
||||
**Source:** [SoundTouch Plus Wiki](https://github.com/thlucas1/homeassistantcomponent_soundtouchplus/wiki/SoundTouch-WebServices-API)
|
||||
**Source:** [SoundTouch Plus Wiki](https://github.com/thlucas1/homeassistantcomponent_soundtouchplus/wiki/SoundTouch-WebServices-API)
|
||||
**Our Implementation:** Bose-SoundTouch Go Library v1.0
|
||||
|
||||
## Executive Summary
|
||||
@@ -20,84 +20,84 @@ The SoundTouch Plus community wiki documents **87 distinct API endpoints** with
|
||||
|
||||
### ✅ Already Implemented (23 endpoints)
|
||||
|
||||
| Endpoint | Wiki Status | Our Status | Notes |
|
||||
|----------|-------------|------------|-------|
|
||||
| `/info` | ✅ Documented | ✅ Complete | Device information |
|
||||
| `/now_playing` | ✅ Documented | ✅ Complete | Current playback status |
|
||||
| `/key` | ✅ Documented | ✅ Complete | Key press/release simulation |
|
||||
| `/volume` | ✅ Documented | ✅ Complete | Volume and mute control |
|
||||
| `/bass` | ✅ Documented | ✅ Complete | Bass level control |
|
||||
| `/bassCapabilities` | ✅ Documented | ✅ Complete | Bass capability detection |
|
||||
| `/sources` | ✅ Documented | ✅ Complete | Available audio sources |
|
||||
| `/select` | ✅ Documented | ✅ Complete | Source selection |
|
||||
| `/presets` | ✅ Documented | ✅ Complete | Preset configurations (read-only) |
|
||||
| `/getZone` | ✅ Documented | ✅ Complete | Zone status and membership |
|
||||
| `/setZone` | ✅ Documented | ✅ Complete | Zone creation and management |
|
||||
| `/addZoneSlave` | ✅ Documented | ✅ Complete | Add device to zone |
|
||||
| `/removeZoneSlave` | ✅ Documented | ✅ Complete | Remove device from zone |
|
||||
| `/capabilities` | ✅ Documented | ✅ Complete | Device feature capabilities |
|
||||
| `/audiodspcontrols` | ✅ Documented | ✅ Complete | Audio DSP modes and video sync |
|
||||
| `/audioproducttonecontrols` | ✅ Documented | ✅ Complete | Advanced bass/treble controls |
|
||||
| `/audioproductlevelcontrols` | ✅ Documented | ✅ Complete | Speaker level controls |
|
||||
| `/name` (GET/POST) | ✅ Documented | ✅ Complete | Device name management |
|
||||
| `/balance` | ✅ Documented | ✅ Complete | Stereo balance control |
|
||||
| `/clockTime` | ✅ Documented | ✅ Complete | Device time management |
|
||||
| `/clockDisplay` | ✅ Documented | ✅ Complete | Clock display settings |
|
||||
| `/networkInfo` | ✅ Documented | ✅ Complete | Network connectivity info |
|
||||
| `/requestToken` | ✅ Documented | ✅ Complete | Bearer token generation |
|
||||
| Endpoint | Wiki Status | Our Status | Notes |
|
||||
|------------------------------|--------------|------------|-----------------------------------|
|
||||
| `/info` | ✅ Documented | ✅ Complete | Device information |
|
||||
| `/now_playing` | ✅ Documented | ✅ Complete | Current playback status |
|
||||
| `/key` | ✅ Documented | ✅ Complete | Key press/release simulation |
|
||||
| `/volume` | ✅ Documented | ✅ Complete | Volume and mute control |
|
||||
| `/bass` | ✅ Documented | ✅ Complete | Bass level control |
|
||||
| `/bassCapabilities` | ✅ Documented | ✅ Complete | Bass capability detection |
|
||||
| `/sources` | ✅ Documented | ✅ Complete | Available audio sources |
|
||||
| `/select` | ✅ Documented | ✅ Complete | Source selection |
|
||||
| `/presets` | ✅ Documented | ✅ Complete | Preset configurations (read-only) |
|
||||
| `/getZone` | ✅ Documented | ✅ Complete | Zone status and membership |
|
||||
| `/setZone` | ✅ Documented | ✅ Complete | Zone creation and management |
|
||||
| `/addZoneSlave` | ✅ Documented | ✅ Complete | Add device to zone |
|
||||
| `/removeZoneSlave` | ✅ Documented | ✅ Complete | Remove device from zone |
|
||||
| `/capabilities` | ✅ Documented | ✅ Complete | Device feature capabilities |
|
||||
| `/audiodspcontrols` | ✅ Documented | ✅ Complete | Audio DSP modes and video sync |
|
||||
| `/audioproducttonecontrols` | ✅ Documented | ✅ Complete | Advanced bass/treble controls |
|
||||
| `/audioproductlevelcontrols` | ✅ Documented | ✅ Complete | Speaker level controls |
|
||||
| `/name` (GET/POST) | ✅ Documented | ✅ Complete | Device name management |
|
||||
| `/balance` | ✅ Documented | ✅ Complete | Stereo balance control |
|
||||
| `/clockTime` | ✅ Documented | ✅ Complete | Device time management |
|
||||
| `/clockDisplay` | ✅ Documented | ✅ Complete | Clock display settings |
|
||||
| `/networkInfo` | ✅ Documented | ✅ Complete | Network connectivity info |
|
||||
| `/requestToken` | ✅ Documented | ✅ Complete | Bearer token generation |
|
||||
|
||||
### 🔥 High Priority Missing (20 endpoints)
|
||||
|
||||
| Endpoint | Wiki Status | Priority | Use Case |
|
||||
|----------|-------------|----------|----------|
|
||||
| `/storePreset` | ✅ Detailed | **HIGH** | Save stations/playlists to presets |
|
||||
| `/removePreset` | ✅ Detailed | **HIGH** | Delete saved presets |
|
||||
| `/selectPreset` | ✅ Detailed | **HIGH** | Play preset by ID |
|
||||
| `/setMusicServiceAccount` | ✅ Detailed | **HIGH** | Add Spotify/Pandora accounts |
|
||||
| `/removeMusicServiceAccount` | ✅ Detailed | **HIGH** | Remove music service accounts |
|
||||
| `/searchStation` | ✅ Detailed | **HIGH** | Find Pandora/Spotify content |
|
||||
| `/addStation` | ✅ Detailed | **HIGH** | Add stations to favorites |
|
||||
| `/removeStation` | ✅ Detailed | **HIGH** | Remove stations from favorites |
|
||||
| `/navigate` | ✅ Detailed | **HIGH** | Browse music libraries/services |
|
||||
| `/search` | ✅ Detailed | **HIGH** | Search music content |
|
||||
| `/userPlayControl` | ✅ Detailed | **HIGH** | Play/pause/stop controls |
|
||||
| `/userRating` | ✅ Detailed | **HIGH** | Thumbs up/down ratings |
|
||||
| `/recents` | ✅ Detailed | **HIGH** | Recently played content |
|
||||
| `/standby` | ✅ Detailed | **HIGH** | Power management |
|
||||
| `/powerManagement` | ✅ Detailed | **HIGH** | Power state information |
|
||||
| `/lowPowerStandby` | ✅ Detailed | **HIGH** | Low-power mode |
|
||||
| `/listMediaServers` | ✅ Detailed | **HIGH** | UPnP/DLNA server discovery |
|
||||
| `/serviceAvailability` | ✅ Detailed | **HIGH** | Source availability status |
|
||||
| `/introspect` | ✅ Detailed | **HIGH** | Music service account status |
|
||||
| `/language` | ✅ Detailed | **HIGH** | Device language settings |
|
||||
| Endpoint | Wiki Status | Priority | Use Case |
|
||||
|------------------------------|-------------|----------|------------------------------------|
|
||||
| `/storePreset` | ✅ Detailed | **HIGH** | Save stations/playlists to presets |
|
||||
| `/removePreset` | ✅ Detailed | **HIGH** | Delete saved presets |
|
||||
| `/selectPreset` | ✅ Detailed | **HIGH** | Play preset by ID |
|
||||
| `/setMusicServiceAccount` | ✅ Detailed | **HIGH** | Add Spotify/Pandora accounts |
|
||||
| `/removeMusicServiceAccount` | ✅ Detailed | **HIGH** | Remove music service accounts |
|
||||
| `/searchStation` | ✅ Detailed | **HIGH** | Find Pandora/Spotify content |
|
||||
| `/addStation` | ✅ Detailed | **HIGH** | Add stations to favorites |
|
||||
| `/removeStation` | ✅ Detailed | **HIGH** | Remove stations from favorites |
|
||||
| `/navigate` | ✅ Detailed | **HIGH** | Browse music libraries/services |
|
||||
| `/search` | ✅ Detailed | **HIGH** | Search music content |
|
||||
| `/userPlayControl` | ✅ Detailed | **HIGH** | Play/pause/stop controls |
|
||||
| `/userRating` | ✅ Detailed | **HIGH** | Thumbs up/down ratings |
|
||||
| `/recents` | ✅ Detailed | **HIGH** | Recently played content |
|
||||
| `/standby` | ✅ Detailed | **HIGH** | Power management |
|
||||
| `/powerManagement` | ✅ Detailed | **HIGH** | Power state information |
|
||||
| `/lowPowerStandby` | ✅ Detailed | **HIGH** | Low-power mode |
|
||||
| `/listMediaServers` | ✅ Detailed | **HIGH** | UPnP/DLNA server discovery |
|
||||
| `/serviceAvailability` | ✅ Detailed | **HIGH** | Source availability status |
|
||||
| `/introspect` | ✅ Detailed | **HIGH** | Music service account status |
|
||||
| `/language` | ✅ Detailed | **HIGH** | Device language settings |
|
||||
|
||||
### 🎵 Music Service Management (12 endpoints)
|
||||
|
||||
| Category | Endpoints | Wiki Coverage | Notes |
|
||||
|----------|-----------|---------------|-------|
|
||||
| **Account Management** | `/setMusicServiceAccount`, `/removeMusicServiceAccount` | ✅ Full XML examples | Pandora, Spotify, NAS setup |
|
||||
| **Station Management** | `/searchStation`, `/addStation`, `/removeStation` | ✅ Pandora tested | Station discovery and favorites |
|
||||
| **Content Navigation** | `/navigate`, `/search` | ✅ Detailed examples | Music library browsing |
|
||||
| **Track Information** | `/trackInfo`, `/introspect` | ✅ Service-specific | Extended metadata |
|
||||
| Category | Endpoints | Wiki Coverage | Notes |
|
||||
|------------------------|---------------------------------------------------------|---------------------|---------------------------------|
|
||||
| **Account Management** | `/setMusicServiceAccount`, `/removeMusicServiceAccount` | ✅ Full XML examples | Pandora, Spotify, NAS setup |
|
||||
| **Station Management** | `/searchStation`, `/addStation`, `/removeStation` | ✅ Pandora tested | Station discovery and favorites |
|
||||
| **Content Navigation** | `/navigate`, `/search` | ✅ Detailed examples | Music library browsing |
|
||||
| **Track Information** | `/trackInfo`, `/introspect` | ✅ Service-specific | Extended metadata |
|
||||
|
||||
### 🏠 Smart Home Integration (15 endpoints)
|
||||
|
||||
| Category | Endpoints | Wiki Coverage | Notes |
|
||||
|----------|-----------|---------------|-------|
|
||||
| **Notifications** | `/speaker`, `/playNotification` | ✅ TTS examples | Text-to-speech, URL playback |
|
||||
| **Power Management** | `/standby`, `/powerManagement`, `/lowPowerStandby` | ✅ Complete | Smart home automation |
|
||||
| **Network Management** | `/performWirelessSiteSurvey`, `/addWirelessProfile`, `/getActiveWirelessProfile` | ✅ WiFi setup | Network configuration |
|
||||
| **Bluetooth** | `/enterBluetoothPairing`, `/clearBluetoothPaired`, `/bluetoothInfo` | ✅ Pairing control | Bluetooth management |
|
||||
| **Source Control** | `/selectLastSource`, `/selectLastSoundTouchSource`, `/selectLocalSource` | ✅ Source switching | Quick source access |
|
||||
| Category | Endpoints | Wiki Coverage | Notes |
|
||||
|------------------------|----------------------------------------------------------------------------------|--------------------|------------------------------|
|
||||
| **Notifications** | `/speaker`, `/playNotification` | ✅ TTS examples | Text-to-speech, URL playback |
|
||||
| **Power Management** | `/standby`, `/powerManagement`, `/lowPowerStandby` | ✅ Complete | Smart home automation |
|
||||
| **Network Management** | `/performWirelessSiteSurvey`, `/addWirelessProfile`, `/getActiveWirelessProfile` | ✅ WiFi setup | Network configuration |
|
||||
| **Bluetooth** | `/enterBluetoothPairing`, `/clearBluetoothPaired`, `/bluetoothInfo` | ✅ Pairing control | Bluetooth management |
|
||||
| **Source Control** | `/selectLastSource`, `/selectLastSoundTouchSource`, `/selectLocalSource` | ✅ Source switching | Quick source access |
|
||||
|
||||
### 📱 Advanced Device Features (19 endpoints)
|
||||
|
||||
| Category | Endpoints | Wiki Coverage | Notes |
|
||||
|----------|-----------|---------------|-------|
|
||||
| **Stereo Pairs** | `/getGroup`, `/addGroup`, `/removeGroup`, `/updateGroup` | ✅ ST-10 specific | L/R speaker pairing |
|
||||
| **System Info** | `/soundTouchConfigurationStatus`, `/systemtimeout`, `/rebroadcastlatencymode` | ✅ Configuration | Device state management |
|
||||
| **Software Updates** | `/swUpdateCheck`, `/swUpdateQuery`, `/swUpdateAbort`, `/swUpdateStart` | ✅ Update process | Firmware management |
|
||||
| **Audio Processing** | `/DSPMonoStereo`, `/audiospeakerattributeandsetting` | ✅ Hardware-specific | Advanced audio features |
|
||||
| Category | Endpoints | Wiki Coverage | Notes |
|
||||
|----------------------|-------------------------------------------------------------------------------|---------------------|-------------------------|
|
||||
| **Stereo Pairs** | `/getGroup`, `/addGroup`, `/removeGroup`, `/updateGroup` | ✅ ST-10 specific | L/R speaker pairing |
|
||||
| **System Info** | `/soundTouchConfigurationStatus`, `/systemtimeout`, `/rebroadcastlatencymode` | ✅ Configuration | Device state management |
|
||||
| **Software Updates** | `/swUpdateCheck`, `/swUpdateQuery`, `/swUpdateAbort`, `/swUpdateStart` | ✅ Update process | Firmware management |
|
||||
| **Audio Processing** | `/DSPMonoStereo`, `/audiospeakerattributeandsetting` | ✅ Hardware-specific | Advanced audio features |
|
||||
|
||||
---
|
||||
|
||||
@@ -137,7 +137,7 @@ The SoundTouch Plus community wiki documents **87 distinct API endpoints** with
|
||||
|
||||
**WebSocket Events Documented:**
|
||||
- `presetsUpdated` - Preset changes
|
||||
- `groupUpdated` - Stereo pair changes
|
||||
- `groupUpdated` - Stereo pair changes
|
||||
- `zoneUpdated` - Multi-room changes
|
||||
- `nowPlayingUpdated` - Source/playback changes
|
||||
- `volumeUpdated` - Volume/mute changes
|
||||
@@ -194,7 +194,7 @@ func (c *Client) RateCurrentTrack(rating RatingValue) error
|
||||
func (c *Client) CreateStereoPair(leftIP, rightIP string, name string) error
|
||||
func (c *Client) GetStereoPairStatus() (*StereoPair, error)
|
||||
|
||||
// System Management
|
||||
// System Management
|
||||
func (c *Client) CheckSoftwareUpdate() (*UpdateInfo, error)
|
||||
func (c *Client) GetSystemTimeout() (*TimeoutConfig, error)
|
||||
```
|
||||
@@ -283,7 +283,7 @@ The SoundTouch Plus Wiki represents a **treasure trove** of production-ready API
|
||||
### Key Opportunities:
|
||||
- 🎯 **3x Coverage Expansion**: From 23 to 87+ endpoints
|
||||
- 🏠 **Smart Home Ready**: Complete automation integration
|
||||
- 🎵 **Music Service Integration**: Full streaming service support
|
||||
- 🎵 **Music Service Integration**: Full streaming service support
|
||||
- 📱 **Professional Features**: Advanced audio and system control
|
||||
- ✅ **Production Ready**: Real-world tested examples and error handling
|
||||
|
||||
@@ -297,4 +297,4 @@ The SoundTouch Plus Wiki represents a **treasure trove** of production-ready API
|
||||
|
||||
---
|
||||
|
||||
*Note: All endpoints documented in the wiki are tested against real hardware. Device-specific limitations are clearly documented with compatibility matrices for ST-10, ST-300, and other SoundTouch models.*
|
||||
*Note: All endpoints documented in the wiki are tested against real hardware. Device-specific limitations are clearly documented with compatibility matrices for ST-10, ST-300, and other SoundTouch models.*
|
||||
@@ -784,4 +784,4 @@ docker-compose up # Mock devices + web app
|
||||
- [UPnP Device Architecture](http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf)
|
||||
- [Go Embed Directive](https://pkg.go.dev/embed)
|
||||
- [Gorilla WebSocket](https://github.com/gorilla/websocket)
|
||||
- [PROJECT-PATTERNS.md](./PROJECT-PATTERNS.md) - Detailed pattern documentation
|
||||
- [PROJECT-PATTERNS.md](../PROJECT-PATTERNS.md) - Detailed pattern documentation
|
||||
@@ -206,14 +206,14 @@ This project implements a comprehensive Go client library and CLI tool for Bose
|
||||
|
||||
### ✅ Complete Documentation
|
||||
- `README.md` - Project overview and usage examples ✅
|
||||
- `docs/API-Endpoints-Overview.md` - API reference with status ✅
|
||||
- `docs/KEY-CONTROLS.md` - Media control implementation ✅
|
||||
- `docs/VOLUME-CONTROLS.md` - Volume management guide ✅
|
||||
- `docs/PRESET-MANAGEMENT.md` - Preset analysis and limitations ✅
|
||||
- `docs/reference/API-ENDPOINTS.md` - API reference with status ✅
|
||||
- `docs/reference/KEY-CONTROLS.md` - Media control implementation ✅
|
||||
- `docs/guides/VOLUME-CONTROLS.md` - Volume management guide ✅
|
||||
- `docs/reference/PRESET-MANAGEMENT.md` - Preset analysis and limitations ✅
|
||||
- `docs/HOST-PORT-PARSING.md` - Enhanced CLI feature ✅
|
||||
- `docs/PLAN.md` - Development roadmap (updated) ✅
|
||||
- `docs/archive/PLAN.md` - Development roadmap (updated) ✅
|
||||
- `docs/PROJECT-PATTERNS.md` - Development guidelines ✅
|
||||
- `SPEAKER_ENDPOINT.md` - Complete speaker notification documentation ✅
|
||||
- `docs/reference/SPEAKER-ENDPOINT.md` - Complete speaker notification documentation ✅
|
||||
|
||||
### 📝 Documentation Notes
|
||||
- All docs are synchronized with current implementation
|
||||
@@ -0,0 +1,181 @@
|
||||
# Upstream Bose Service Simulation - Concept Overview
|
||||
|
||||
## Executive Summary
|
||||
|
||||
This document serves as the entry point for understanding the comprehensive plan to enhance the SoundTouch service with advanced state management capabilities, preparing for the eventual shutdown of Bose's upstream services while providing a superior local management experience.
|
||||
|
||||
## Project Objectives
|
||||
|
||||
### Primary Goal
|
||||
Create a robust, local replacement for Bose's upstream services that can seamlessly handle the transition from cloud-dependent to fully autonomous operation while maintaining and improving upon the existing functionality.
|
||||
|
||||
### Key Outcomes
|
||||
- **Zero-downtime transition** from Bose services to local management
|
||||
- **Enhanced visibility** into device states, health, and system operations
|
||||
- **Data preservation** during migrations with full rollback capabilities
|
||||
- **Improved reliability** through local control and reduced external dependencies
|
||||
- **Future-proof architecture** that can evolve beyond Bose's original design
|
||||
|
||||
## Architecture Vision
|
||||
|
||||
### Current State
|
||||
The existing SoundTouch service provides:
|
||||
- BMX service for TuneIn integration
|
||||
- Marge service for account and device management
|
||||
- Basic mirroring of upstream Bose endpoints
|
||||
- File-based persistence for device data
|
||||
- Migration support for device directory structures
|
||||
|
||||
### Enhanced State (This Project)
|
||||
The enhanced system will add:
|
||||
- **Comprehensive Account Management** with explicit creation and migration tracking
|
||||
- **Device Lifecycle Management** with full state machine and event processing
|
||||
- **Advanced Mirroring** with disparity detection and analysis
|
||||
- **Dual-Source Data Management** supporting gradual migration strategies
|
||||
- **Real-time Monitoring** with health checks and performance metrics
|
||||
- **Text-based Storage** optimized for debugging and small hardware deployments
|
||||
|
||||
## Use Case Coverage
|
||||
|
||||
### Case 0: Account Management
|
||||
- **Explicit Account Creation**: Accounts created through deliberate user action
|
||||
- **Mirror-Enhanced Setup**: Use upstream data to enrich account creation
|
||||
- **Passive Data Collection**: Record account information during normal operations
|
||||
|
||||
### Case 1a: Fresh Device Registration
|
||||
- **Factory Reset Support**: Handle devices with no prior Bose association
|
||||
- **Default Configuration**: Initialize devices with sensible presets and sources
|
||||
- **Local-First Setup**: Complete registration without upstream dependencies
|
||||
|
||||
### Case 1b: Bose Account Migration
|
||||
- **Data Preservation**: Maintain existing presets, recents, and sources
|
||||
- **Gradual Migration**: Support partial migration while maintaining upstream compatibility
|
||||
- **Rollback Capability**: Revert to Bose services if needed
|
||||
|
||||
### Case 2: Lifecycle and State Management
|
||||
- **Real-time State Tracking**: Monitor device states and health continuously
|
||||
- **Event-Driven Updates**: Process device events asynchronously
|
||||
- **Disparity Detection**: Identify differences between local and upstream behavior
|
||||
- **Comprehensive Logging**: Maintain detailed audit trails for troubleshooting
|
||||
|
||||
## Technical Approach
|
||||
|
||||
### Design Principles
|
||||
1. **Text-First Storage**: Human-readable formats (JSON, XML, logs) for easy debugging
|
||||
2. **Small Hardware Optimization**: Designed for Raspberry Pi Zero 2W deployments
|
||||
3. **Mirror-First Strategy**: Keep upstream mirroring active until migration complete
|
||||
4. **Event-Driven Architecture**: Asynchronous processing with comprehensive event tracking
|
||||
5. **Backward Compatibility**: Seamless integration with existing installations
|
||||
|
||||
### Data Structure
|
||||
```
|
||||
data/
|
||||
├── accounts/{account-id}/
|
||||
│ ├── account.json # Account metadata and settings
|
||||
│ ├── account-events.log # High-level account behavior tracking
|
||||
│ ├── devices/{device-id}/
|
||||
│ │ ├── lifecycle.json # Device state and history
|
||||
│ │ ├── info.xml # Device information (existing)
|
||||
│ │ ├── presets.xml # Device presets (existing)
|
||||
│ │ ├── recents.xml # Recent plays (existing)
|
||||
│ │ ├── sources.xml # Configured sources (existing)
|
||||
│ │ └── events.log # Device event history
|
||||
│ └── sessions/ # Recorded interaction sessions (existing)
|
||||
└── system/
|
||||
├── discovery.log # Device discovery events
|
||||
└── migration.log # Migration activities
|
||||
```
|
||||
|
||||
### Development Targets
|
||||
- **Simplicity**: Keep It Simple, Stupid (KISS) principle over optimization
|
||||
- **Quality**: 100% test pass rate and lint-clean code for every change
|
||||
- **Compatibility**: Zero breaking changes to existing functionality
|
||||
- **Leveraging**: Reuse existing systems (interaction recording, parity detection)
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### Phase 1: Foundation (2-3 weeks) - Small, Testable Steps
|
||||
- Account management foundation with basic create/read operations
|
||||
- Device lifecycle data models and simple state tracking
|
||||
- Basic API endpoints with comprehensive testing
|
||||
- Integration with existing datastore patterns
|
||||
|
||||
### Phase 2: Device Lifecycle (2-3 weeks) - Build on Existing Systems
|
||||
- Event processing using existing WebSocket system
|
||||
- Lifecycle integration with current discovery and migration
|
||||
- Enhanced logging building on existing parity detection
|
||||
- Simple state machine with thorough testing
|
||||
|
||||
### Phase 3: Enhanced Features (2-3 weeks) - Leverage Current Systems
|
||||
- Improve existing parity mismatch detection with better categorization
|
||||
- Smart data source routing with fallback mechanisms
|
||||
- Basic monitoring using existing health check patterns
|
||||
- Reuse interaction recording for request/response tracking
|
||||
|
||||
## Key Benefits
|
||||
|
||||
### For Users
|
||||
- **Continuity**: Seamless operation when Bose services shut down
|
||||
- **Reliability**: Local control reduces dependency on external services
|
||||
- **Visibility**: Clear insight into device states and system health
|
||||
- **Control**: Full management of device data and configurations
|
||||
|
||||
### For Developers
|
||||
- **Simplicity**: KISS principle makes code easy to understand and maintain
|
||||
- **Quality**: Comprehensive testing and linting ensures reliable code
|
||||
- **Debugging**: Text-based storage enables easy troubleshooting
|
||||
- **Testing**: Every change requires full test suite pass and lint compliance
|
||||
|
||||
### For Community
|
||||
- **Open Source**: Transparent implementation available for community contributions
|
||||
- **Standards**: Well-documented APIs and data formats
|
||||
- **Collaboration**: Disparity detection helps improve implementation accuracy
|
||||
- **Future-Proof**: Architecture designed to outlast original Bose services
|
||||
|
||||
### Technical Risks
|
||||
- **Data Loss Prevention**: Atomic file operations and comprehensive testing
|
||||
- **Complexity Creep**: KISS principle and simple-first approach
|
||||
- **Compatibility Issues**: Extensive regression testing and existing system reuse
|
||||
- **Code Quality**: Mandatory linting and test coverage for every change
|
||||
|
||||
### Operational Risks
|
||||
- **Service Disruption**: Small, incremental changes with rollback capability
|
||||
- **Testing Overhead**: Automated quality gates (`golangci-lint run --fix` + `go test ./...`)
|
||||
- **Migration Challenges**: Leverage existing migration system and patterns
|
||||
- **Maintenance Burden**: Simple, well-tested code is easier to maintain
|
||||
|
||||
### Technical
|
||||
- All tests pass consistently (100%)
|
||||
- Zero linting issues in codebase
|
||||
- No breaking changes to existing functionality
|
||||
- Code coverage maintained or improved
|
||||
|
||||
### Quality Assurance
|
||||
- Every commit passes `golangci-lint run --fix`
|
||||
- Every milestone passes `go test ./...`
|
||||
- Integration tests verify existing functionality
|
||||
- Simple, maintainable code that follows Go idioms
|
||||
|
||||
## Documentation Structure
|
||||
|
||||
This concept is detailed across several documents:
|
||||
|
||||
- **[upstream-service-simulation.md](./upstream-service-simulation.md)**: Complete architectural concept with detailed use cases and implementation guidelines
|
||||
- **[implementation-roadmap.md](./implementation-roadmap.md)**: Detailed project phases, milestones, and delivery timeline
|
||||
- **[technical-specification.md](./technical-specification.md)**: Comprehensive technical details including APIs, data models, and performance requirements
|
||||
|
||||
## Getting Started
|
||||
|
||||
1. **Review the Concept**: Read through the main concept document to understand the full scope
|
||||
2. **Examine Technical Details**: Review the technical specification for implementation details
|
||||
3. **Follow the Roadmap**: Use the implementation roadmap for project planning and execution
|
||||
4. **Integration Planning**: Consider how the enhanced features will integrate with existing deployments
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Stakeholder Review**: Gather feedback on the concept and approach
|
||||
2. **Technical Validation**: Prototype key components to validate technical assumptions
|
||||
3. **Resource Planning**: Allocate development resources for the three-phase implementation
|
||||
4. **Community Engagement**: Share plans with the community for feedback and contributions
|
||||
|
||||
This enhanced state management system represents a significant evolution of the SoundTouch service, transforming it from a basic cloud replacement into a comprehensive, future-proof device management platform that can serve users well beyond the Bose service shutdown timeline.
|
||||
@@ -0,0 +1,355 @@
|
||||
# Implementation Plan - Enhanced State Management System
|
||||
|
||||
## Overview
|
||||
|
||||
This document provides a detailed, step-by-step implementation plan for the enhanced state management system. Each step is designed to be small, testable, and independently valuable while maintaining backward compatibility.
|
||||
|
||||
## Development Principles
|
||||
|
||||
### Quality Gates
|
||||
Every step must pass these checks before proceeding:
|
||||
1. `golangci-lint run --fix` - no linting issues
|
||||
2. `go test ./...` - all tests pass
|
||||
3. Existing functionality remains intact
|
||||
4. New functionality has appropriate test coverage
|
||||
|
||||
### KISS Principle
|
||||
- Write the simplest code that works
|
||||
- Avoid premature optimization
|
||||
- Use straightforward algorithms
|
||||
- Build incrementally with small changes
|
||||
|
||||
### Leverage Existing Systems
|
||||
- Reuse interaction recording for request/response tracking
|
||||
- Build upon current parity mismatch detection
|
||||
- Extend existing datastore patterns
|
||||
- Integrate with established workflows
|
||||
|
||||
## Phase 1: Foundation Preparation (2-3 weeks)
|
||||
|
||||
### Step 1.1: Code Organization Preparation
|
||||
**Duration**: 2-3 days
|
||||
**Goal**: Prepare package structure without changing behavior
|
||||
|
||||
#### Mini-milestone 1.1.1: Create account package structure
|
||||
- Create `pkg/service/account/` directory
|
||||
- Add basic `account.go` with placeholder structs
|
||||
- Add `account_test.go` with basic test structure
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 1.1.2: Create lifecycle package structure
|
||||
- Create `pkg/service/lifecycle/` directory
|
||||
- Add basic `lifecycle.go` with placeholder structs
|
||||
- Add `lifecycle_test.go` with basic test structure
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 1.1.3: Extend datastore interface preparation
|
||||
- Add placeholder methods to existing datastore for account operations
|
||||
- Ensure all existing functionality still works
|
||||
- Add tests for new placeholder methods
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
### Step 1.2: Account Management Foundation
|
||||
**Duration**: 3-4 days
|
||||
**Goal**: Basic account creation and retrieval
|
||||
|
||||
#### Mini-milestone 1.2.1: Account data model
|
||||
- Define `Account` struct with basic fields
|
||||
- Add validation functions
|
||||
- Add comprehensive unit tests
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 1.2.2: Account persistence
|
||||
- Implement account.json file read/write
|
||||
- Add atomic file operations
|
||||
- Test file operations thoroughly
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 1.2.3: Account manager basic operations
|
||||
- Implement `CreateAccount()` function
|
||||
- Implement `GetAccount()` function
|
||||
- Add error handling and validation
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 1.2.4: Integration with existing datastore
|
||||
- Modify datastore to use account manager
|
||||
- Ensure backward compatibility with existing accounts
|
||||
- Test migration of existing data structure
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
### Step 1.3: Basic API Endpoints
|
||||
**Duration**: 2-3 days
|
||||
**Goal**: Add REST endpoints for account management
|
||||
|
||||
#### Mini-milestone 1.3.1: Account creation endpoint
|
||||
- Add `POST /api/v1/accounts` handler
|
||||
- Integrate with existing HTTP router
|
||||
- Add input validation and error responses
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 1.3.2: Account retrieval endpoint
|
||||
- Add `GET /api/v1/accounts/{id}` handler
|
||||
- Add proper JSON serialization
|
||||
- Test endpoint functionality
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 1.3.3: Integration testing
|
||||
- Test new endpoints with existing functionality
|
||||
- Ensure XML endpoints still work
|
||||
- Verify no breaking changes
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
## Phase 2: Device Lifecycle Foundation (2-3 weeks)
|
||||
|
||||
### Step 2.1: Device State Model
|
||||
**Duration**: 3-4 days
|
||||
**Goal**: Basic device lifecycle tracking
|
||||
|
||||
#### Mini-milestone 2.1.1: Device lifecycle data model
|
||||
- Define `DeviceLifecycle` struct
|
||||
- Define device states and transitions
|
||||
- Add validation and helper functions
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 2.1.2: State transition logic
|
||||
- Implement basic state machine
|
||||
- Add transition validation
|
||||
- Create comprehensive tests for all transitions
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 2.1.3: Lifecycle persistence
|
||||
- Implement lifecycle.json file operations
|
||||
- Add atomic updates and error handling
|
||||
- Test persistence thoroughly
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
### Step 2.2: Event Processing Foundation
|
||||
**Duration**: 3-4 days
|
||||
**Goal**: Basic event handling and logging
|
||||
|
||||
#### Mini-milestone 2.2.1: Event data model
|
||||
- Define `DeviceEvent` struct
|
||||
- Add event types and validation
|
||||
- Create event builder helpers
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 2.2.2: Simple event logging
|
||||
- Implement append-only event log writing
|
||||
- Add structured log format
|
||||
- Test log operations and rotation
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 2.2.3: Event processing pipeline
|
||||
- Create basic synchronous event processor
|
||||
- Add event validation and filtering
|
||||
- Integrate with existing WebSocket events
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
### Step 2.3: Lifecycle Integration
|
||||
**Duration**: 2-3 days
|
||||
**Goal**: Connect lifecycle to existing systems
|
||||
|
||||
#### Mini-milestone 2.3.1: Discovery integration
|
||||
- Trigger lifecycle events on device discovery
|
||||
- Update device state on discovery
|
||||
- Test discovery workflow with lifecycle
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 2.3.2: WebSocket integration
|
||||
- Process WebSocket events through lifecycle
|
||||
- Update device state based on events
|
||||
- Log significant state changes
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 2.3.3: Migration integration
|
||||
- Integrate lifecycle with existing migration system
|
||||
- Track migration events and state changes
|
||||
- Ensure existing migration still works
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
## Phase 3: Enhanced Features (2-3 weeks)
|
||||
|
||||
### Step 3.1: Enhanced Mirroring
|
||||
**Duration**: 3-4 days
|
||||
**Goal**: Improve existing parity detection
|
||||
|
||||
#### Mini-milestone 3.1.1: Extended disparity logging
|
||||
- Enhance existing parity mismatch logging
|
||||
- Add more detailed disparity information
|
||||
- Improve log format for analysis
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 3.1.2: Disparity categorization
|
||||
- Add severity levels to disparities
|
||||
- Categorize different types of mismatches
|
||||
- Add filtering and search capabilities
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 3.1.3: Enhanced mirror middleware
|
||||
- Extend existing mirror functionality
|
||||
- Add better response comparison
|
||||
- Integrate with lifecycle events
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
### Step 3.2: Data Source Management
|
||||
**Duration**: 3-4 days
|
||||
**Goal**: Smart routing between local and upstream
|
||||
|
||||
#### Mini-milestone 3.2.1: Data source configuration
|
||||
- Add per-device source preferences
|
||||
- Implement source switching logic
|
||||
- Add configuration persistence
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 3.2.2: Fallback mechanisms
|
||||
- Add graceful fallback on source failure
|
||||
- Implement simple health checking
|
||||
- Test fallback scenarios
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 3.2.3: Migration orchestration
|
||||
- Add device-by-device migration control
|
||||
- Track migration progress
|
||||
- Add rollback capabilities
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
### Step 3.3: Monitoring and Health
|
||||
**Duration**: 2-3 days
|
||||
**Goal**: Basic system monitoring
|
||||
|
||||
#### Mini-milestone 3.3.1: Health check endpoints
|
||||
- Add system health endpoints
|
||||
- Report service status
|
||||
- Add basic metrics collection
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 3.3.2: Device health tracking
|
||||
- Track device connectivity
|
||||
- Monitor response times
|
||||
- Log health status changes
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
#### Mini-milestone 3.3.3: System metrics
|
||||
- Add basic performance metrics
|
||||
- Track resource usage
|
||||
- Add metrics endpoints
|
||||
- **Quality Check**: Lint + test all packages
|
||||
|
||||
## Quality Assurance Strategy
|
||||
|
||||
### Testing Requirements
|
||||
Each mini-milestone must include:
|
||||
- Unit tests for new functions
|
||||
- Integration tests for modified workflows
|
||||
- Regression tests for existing functionality
|
||||
- Performance tests for critical paths
|
||||
|
||||
### Test Categories
|
||||
|
||||
#### Unit Tests
|
||||
- Test individual functions and methods
|
||||
- Mock external dependencies
|
||||
- Cover error conditions and edge cases
|
||||
- Aim for >90% code coverage on new code
|
||||
|
||||
#### Integration Tests
|
||||
- Test component interactions
|
||||
- Use real file operations in test environment
|
||||
- Test HTTP endpoints end-to-end
|
||||
- Verify existing functionality unchanged
|
||||
|
||||
#### Regression Tests
|
||||
- Ensure existing XML endpoints work
|
||||
- Verify device discovery still functions
|
||||
- Check migration compatibility
|
||||
- Test WebSocket event processing
|
||||
|
||||
### Continuous Quality Checks
|
||||
|
||||
#### Pre-commit Checks
|
||||
```bash
|
||||
# Before each commit
|
||||
golangci-lint run --fix
|
||||
go test ./...
|
||||
go test -race ./...
|
||||
```
|
||||
|
||||
#### Milestone Validation
|
||||
```bash
|
||||
# Before marking milestone complete
|
||||
golangci-lint run --fix
|
||||
go test ./... -v
|
||||
go test -race ./... -v
|
||||
go test ./... -bench=.
|
||||
```
|
||||
|
||||
#### Integration Validation
|
||||
```bash
|
||||
# Test with real soundtouch-service
|
||||
make build
|
||||
./soundtouch-service &
|
||||
# Run integration test suite
|
||||
make integration-test
|
||||
```
|
||||
|
||||
## Risk Mitigation
|
||||
|
||||
### Backward Compatibility
|
||||
- All existing APIs must continue working
|
||||
- File structure changes must be additive
|
||||
- Configuration changes must have defaults
|
||||
- Migration paths for existing data
|
||||
|
||||
### Rollback Strategy
|
||||
- Each step can be independently reverted
|
||||
- Configuration flags for new features
|
||||
- Graceful degradation when features disabled
|
||||
- Clear rollback documentation
|
||||
|
||||
### Performance Impact
|
||||
- Monitor memory usage during development
|
||||
- Profile critical paths before and after changes
|
||||
- Set performance regression alerts
|
||||
- Simple before complex solutions
|
||||
|
||||
## Documentation Requirements
|
||||
|
||||
### Code Documentation
|
||||
- Comprehensive godoc comments
|
||||
- Example usage in comments
|
||||
- Error conditions documented
|
||||
- Performance characteristics noted
|
||||
|
||||
### User Documentation
|
||||
- Update existing guides for new features
|
||||
- Add migration guides for new functionality
|
||||
- Create troubleshooting documentation
|
||||
- Update API documentation
|
||||
|
||||
### Development Documentation
|
||||
- Architecture decision records
|
||||
- Testing strategy documentation
|
||||
- Deployment and rollback procedures
|
||||
- Performance benchmarking results
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Technical Metrics
|
||||
- All tests pass consistently
|
||||
- No linting issues
|
||||
- Memory usage increase <50MB
|
||||
- Response time degradation <10%
|
||||
|
||||
### Functional Metrics
|
||||
- All existing functionality preserved
|
||||
- New account management works reliably
|
||||
- Device lifecycle tracking is accurate
|
||||
- Enhanced monitoring provides value
|
||||
|
||||
### Quality Metrics
|
||||
- Code coverage maintained >85%
|
||||
- No critical security issues
|
||||
- Documentation completeness >95%
|
||||
- Community feedback positive
|
||||
|
||||
This implementation plan ensures steady, reliable progress while maintaining the quality and simplicity principles essential for the project's success.
|
||||
@@ -0,0 +1,403 @@
|
||||
# Implementation Roadmap for Upstream Service Simulation
|
||||
|
||||
## Overview
|
||||
|
||||
This document provides a detailed implementation roadmap for the upstream Bose service simulation concept. It breaks down the implementation into manageable phases with specific deliverables, technical requirements, and integration points.
|
||||
|
||||
## Phase 1: Foundation and Enhanced State Tracking (4-6 weeks)
|
||||
|
||||
### Milestone 1.1: Account Management Service (1-2 weeks)
|
||||
|
||||
#### Deliverables
|
||||
- `pkg/service/account/` package with core account management
|
||||
- Account creation, retrieval, and status management APIs
|
||||
- Text-based account persistence in JSON format
|
||||
- Integration with existing datastore structure
|
||||
|
||||
#### Implementation Tasks
|
||||
1. **Create Account Manager**
|
||||
```
|
||||
pkg/service/account/
|
||||
├── account.go # Core account management
|
||||
├── manager.go # Account manager implementation
|
||||
├── persistence.go # File-based persistence
|
||||
└── account_test.go # Comprehensive tests
|
||||
```
|
||||
|
||||
2. **Account Data Structure**
|
||||
- JSON-based account metadata storage
|
||||
- Integration with existing `data/accounts/{id}/` structure
|
||||
- Account status tracking (active, migrating, suspended)
|
||||
- Migration metadata tracking
|
||||
|
||||
3. **API Integration**
|
||||
- Add account management endpoints to existing HTTP router
|
||||
- RESTful API alongside existing XML endpoints
|
||||
- Account creation validation and error handling
|
||||
|
||||
#### Technical Requirements
|
||||
- Maintain backward compatibility with existing account structure
|
||||
- Thread-safe account operations
|
||||
- Atomic file operations for account metadata
|
||||
- Comprehensive error handling and logging
|
||||
|
||||
### Milestone 1.2: Device Lifecycle Manager (2-3 weeks)
|
||||
|
||||
#### Deliverables
|
||||
- `pkg/service/lifecycle/` package for device state management
|
||||
- Device state machine with comprehensive state tracking
|
||||
- Event-driven state transitions
|
||||
- Integration with existing device discovery and migration
|
||||
|
||||
#### Implementation Tasks
|
||||
1. **Lifecycle Core**
|
||||
```
|
||||
pkg/service/lifecycle/
|
||||
├── lifecycle.go # Device lifecycle management
|
||||
├── states.go # State definitions and transitions
|
||||
├── events.go # Event processing
|
||||
├── persistence.go # Lifecycle persistence
|
||||
└── lifecycle_test.go # State machine tests
|
||||
```
|
||||
|
||||
2. **State Machine Implementation**
|
||||
- Define device states: unregistered → registering → active → migrating → offline → retired
|
||||
- Implement state transition rules and validation
|
||||
- Event-driven state changes with history tracking
|
||||
- Integration with existing migration system
|
||||
|
||||
3. **Event Processing**
|
||||
- Asynchronous event queue for device events
|
||||
- Event categorization and filtering
|
||||
- Text-based event logging with structured format
|
||||
- Event replay capabilities for debugging
|
||||
|
||||
#### Technical Requirements
|
||||
- Non-blocking event processing
|
||||
- Persistent state across service restarts
|
||||
- Integration with existing WebSocket event system
|
||||
- Memory-efficient event storage
|
||||
|
||||
### Milestone 1.3: Enhanced Mirror System (1-2 weeks)
|
||||
|
||||
#### Deliverables
|
||||
- Extended mirroring with disparity detection
|
||||
- Parity analysis logging and reporting
|
||||
- Selective data source switching
|
||||
- Integration with existing mirror middleware
|
||||
|
||||
#### Implementation Tasks
|
||||
1. **Disparity Detection**
|
||||
```
|
||||
pkg/service/mirror/
|
||||
├── disparity.go # Disparity detection logic
|
||||
├── analyzer.go # Response analysis and comparison
|
||||
├── logger.go # Structured disparity logging
|
||||
└── disparity_test.go # Analysis tests
|
||||
```
|
||||
|
||||
2. **Enhanced Mirror Middleware**
|
||||
- Extend existing mirror functionality
|
||||
- Add response comparison and hash calculation
|
||||
- Structured logging of disparities
|
||||
- Configurable disparity sensitivity
|
||||
|
||||
3. **Data Source Management**
|
||||
- Smart routing between local and upstream sources
|
||||
- Per-endpoint source preference configuration
|
||||
- Fallback mechanisms for upstream unavailability
|
||||
- Source switching with history tracking
|
||||
|
||||
#### Technical Requirements
|
||||
- Minimal performance impact on request processing
|
||||
- Configurable disparity detection sensitivity
|
||||
- Structured logging for analysis tools
|
||||
- Integration with existing mirror configuration
|
||||
|
||||
## Phase 2: Migration and Dual-Source Management (3-4 weeks)
|
||||
|
||||
### Milestone 2.1: Migration Controller (2-3 weeks)
|
||||
|
||||
#### Deliverables
|
||||
- Device-by-device migration orchestration
|
||||
- Migration progress tracking and status reporting
|
||||
- Rollback capabilities with state preservation
|
||||
- Integration with existing setup manager
|
||||
|
||||
#### Implementation Tasks
|
||||
1. **Migration Orchestration**
|
||||
```
|
||||
pkg/service/migration/
|
||||
├── controller.go # Migration orchestration
|
||||
├── strategy.go # Migration strategies
|
||||
├── rollback.go # Rollback functionality
|
||||
├── progress.go # Progress tracking
|
||||
└── migration_integration_test.go
|
||||
```
|
||||
|
||||
2. **Migration Strategies**
|
||||
- Fresh device registration flow
|
||||
- Bose account data migration flow
|
||||
- Gradual migration with dual-source support
|
||||
- Emergency migration for service outages
|
||||
|
||||
3. **Progress Tracking**
|
||||
- Real-time migration status updates
|
||||
- Migration timeline and milestone tracking
|
||||
- Error handling and recovery procedures
|
||||
- Migration completion verification
|
||||
|
||||
#### Technical Requirements
|
||||
- Integration with existing migration system
|
||||
- Atomic migration operations with rollback
|
||||
- Progress persistence across service restarts
|
||||
- Comprehensive migration logging
|
||||
|
||||
### Milestone 2.2: Dual-Source Data Management (1-2 weeks)
|
||||
|
||||
#### Deliverables
|
||||
- Smart data routing between local and upstream sources
|
||||
- Graceful fallback mechanisms
|
||||
- Data source preference management
|
||||
- Conflict resolution strategies
|
||||
|
||||
#### Implementation Tasks
|
||||
1. **Data Source Router**
|
||||
```
|
||||
pkg/service/datasource/
|
||||
├── router.go # Smart routing logic
|
||||
├── preferences.go # Source preference management
|
||||
├── fallback.go # Fallback mechanisms
|
||||
└── conflict.go # Conflict resolution
|
||||
```
|
||||
|
||||
2. **Source Management**
|
||||
- Per-device, per-endpoint source preferences
|
||||
- Dynamic source switching based on availability
|
||||
- Conflict detection and resolution
|
||||
- Source health monitoring
|
||||
|
||||
3. **Integration Points**
|
||||
- Marge service integration for account data
|
||||
- BMX service integration for content data
|
||||
- Preset and recent management integration
|
||||
- Source configuration management
|
||||
|
||||
#### Technical Requirements
|
||||
- Zero-downtime source switching
|
||||
- Conflict resolution without data loss
|
||||
- Health check integration
|
||||
- Performance monitoring and metrics
|
||||
|
||||
## Phase 3: Advanced Features and Analytics (2-3 weeks)
|
||||
|
||||
### Milestone 3.1: System Monitoring and Health Checks (1-2 weeks)
|
||||
|
||||
#### Deliverables
|
||||
- Comprehensive system health monitoring
|
||||
- Device connectivity and availability tracking
|
||||
- Performance metrics collection
|
||||
- Health check endpoints and dashboards
|
||||
|
||||
#### Implementation Tasks
|
||||
1. **Health Monitoring**
|
||||
```
|
||||
pkg/service/health/
|
||||
├── monitor.go # System health monitoring
|
||||
├── metrics.go # Performance metrics
|
||||
├── connectivity.go # Device connectivity tracking
|
||||
└── alerts.go # Health alerting
|
||||
```
|
||||
|
||||
2. **Metrics Collection**
|
||||
- Device availability tracking
|
||||
- Response time monitoring
|
||||
- Error rate tracking
|
||||
- Migration success rates
|
||||
|
||||
3. **Dashboard Integration**
|
||||
- Health status endpoints
|
||||
- Metrics export for monitoring tools
|
||||
- Real-time status updates
|
||||
- Historical trend analysis
|
||||
|
||||
#### Technical Requirements
|
||||
- Minimal performance overhead
|
||||
- Configurable monitoring intervals
|
||||
- Integration with existing health checks
|
||||
- Memory-efficient metrics storage
|
||||
|
||||
### Milestone 3.2: Data Export and Backup (1 week)
|
||||
|
||||
#### Deliverables
|
||||
- Account data export functionality
|
||||
- Incremental backup strategies
|
||||
- Data integrity verification
|
||||
- Migration-ready data formats
|
||||
|
||||
#### Implementation Tasks
|
||||
1. **Export Functionality**
|
||||
```
|
||||
pkg/service/export/
|
||||
├── exporter.go # Data export logic
|
||||
├── formats.go # Export format definitions
|
||||
├── validation.go # Data integrity checks
|
||||
└── backup.go # Backup strategies
|
||||
```
|
||||
|
||||
2. **Backup Management**
|
||||
- Incremental backup creation
|
||||
- Backup validation and verification
|
||||
- Automated backup scheduling
|
||||
- Restore functionality
|
||||
|
||||
3. **Data Formats**
|
||||
- Migration-ready JSON exports
|
||||
- XML compatibility for device imports
|
||||
- Compressed archive support
|
||||
- Selective export capabilities
|
||||
|
||||
#### Technical Requirements
|
||||
- Consistent data export across all account types
|
||||
- Backup integrity verification
|
||||
- Configurable export scheduling
|
||||
- Resource-efficient backup operations
|
||||
|
||||
## Integration Strategy
|
||||
|
||||
### Existing Service Integration Points
|
||||
|
||||
#### 1. Datastore Integration
|
||||
- Extend existing datastore with lifecycle and account management
|
||||
- Maintain backward compatibility with current file structure
|
||||
- Add new persistence methods for enhanced state tracking
|
||||
- Implement migration for existing data to new formats
|
||||
|
||||
#### 2. Handler Integration
|
||||
- Integrate account management into existing HTTP handlers
|
||||
- Add lifecycle information to device responses
|
||||
- Extend mirror middleware with disparity detection
|
||||
- Add new management endpoints alongside existing XML APIs
|
||||
|
||||
#### 3. Discovery Integration
|
||||
- Link device discovery to lifecycle state transitions
|
||||
- Integrate migration triggers with discovery events
|
||||
- Add account association during discovery
|
||||
- Maintain existing discovery functionality
|
||||
|
||||
#### 4. Migration System Integration
|
||||
- Extend existing migration manager with new capabilities
|
||||
- Integrate lifecycle management with device migrations
|
||||
- Add rollback functionality to existing migration flows
|
||||
- Maintain compatibility with current migration methods
|
||||
|
||||
### Configuration Management
|
||||
|
||||
#### New Configuration Options
|
||||
```yaml
|
||||
accounts:
|
||||
auto_create: false
|
||||
mirror_enhanced_creation: true
|
||||
default_migration_strategy: "gradual"
|
||||
|
||||
lifecycle:
|
||||
event_retention_days: 30
|
||||
state_transition_timeout: "5m"
|
||||
async_processing: true
|
||||
|
||||
mirror:
|
||||
disparity_detection: true
|
||||
disparity_sensitivity: "medium"
|
||||
source_switching_enabled: true
|
||||
fallback_timeout: "10s"
|
||||
|
||||
migration:
|
||||
batch_size: 1
|
||||
progress_reporting: true
|
||||
rollback_enabled: true
|
||||
verification_required: true
|
||||
```
|
||||
|
||||
### Performance Considerations
|
||||
|
||||
#### Resource Usage
|
||||
- Target: <100MB additional memory usage on Raspberry Pi Zero 2W
|
||||
- CPU usage: <5% additional overhead during normal operations
|
||||
- Storage: Text-based logs with configurable rotation
|
||||
- Network: Minimal additional upstream requests
|
||||
|
||||
#### Optimization Strategies
|
||||
- Lazy loading of historical data
|
||||
- Configurable log retention policies
|
||||
- Memory-efficient event processing
|
||||
- Background cleanup processes
|
||||
- Efficient file I/O operations
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Unit Testing
|
||||
- Comprehensive test coverage for all new packages
|
||||
- State machine transition testing
|
||||
- Data persistence and integrity tests
|
||||
- Mock integration tests for external dependencies
|
||||
|
||||
### Integration Testing
|
||||
- End-to-end migration flow testing
|
||||
- Multi-device scenario testing
|
||||
- Disparity detection accuracy testing
|
||||
- Performance impact testing
|
||||
|
||||
### Compatibility Testing
|
||||
- Backward compatibility with existing installations
|
||||
- Device compatibility across SoundTouch models
|
||||
- Migration from various existing configurations
|
||||
- Stress testing with multiple concurrent devices
|
||||
|
||||
## Deployment Strategy
|
||||
|
||||
### Rollout Plan
|
||||
1. **Alpha Release**: Core functionality with limited device support
|
||||
2. **Beta Release**: Full feature set with extensive testing
|
||||
3. **Stable Release**: Production-ready with documentation
|
||||
|
||||
### Migration Path
|
||||
1. Existing installations can upgrade incrementally
|
||||
2. New features are opt-in with configuration flags
|
||||
3. Existing data structures are preserved and extended
|
||||
4. Rollback capability for critical issues
|
||||
|
||||
### Documentation Requirements
|
||||
- Updated API documentation with new endpoints
|
||||
- Migration guide for existing users
|
||||
- Configuration reference for new options
|
||||
- Troubleshooting guide for common issues
|
||||
|
||||
## Risk Mitigation
|
||||
|
||||
### Technical Risks
|
||||
- **Data Loss**: Atomic operations and rollback capabilities
|
||||
- **Performance Impact**: Gradual rollout and monitoring
|
||||
- **Compatibility Issues**: Comprehensive testing and fallback options
|
||||
- **Resource Constraints**: Efficient algorithms and configurable limits
|
||||
|
||||
### Operational Risks
|
||||
- **Service Disruption**: Zero-downtime deployment strategies
|
||||
- **Configuration Complexity**: Sensible defaults and validation
|
||||
- **User Adoption**: Clear documentation and migration assistance
|
||||
- **Support Burden**: Comprehensive logging and diagnostic tools
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Technical Metrics
|
||||
- Migration success rate >95%
|
||||
- Disparity detection accuracy >90%
|
||||
- Performance overhead <5%
|
||||
- System availability >99.5%
|
||||
|
||||
### User Experience Metrics
|
||||
- Reduced support requests
|
||||
- Improved device reliability
|
||||
- Faster problem resolution
|
||||
- Enhanced system visibility
|
||||
|
||||
This roadmap provides a structured approach to implementing the upstream service simulation concept while maintaining compatibility with existing deployments and ensuring smooth migration paths for users.
|
||||
@@ -0,0 +1,137 @@
|
||||
# Spotify OAuth Integration
|
||||
|
||||
The SoundTouch service supports Spotify OAuth integration to broker access tokens for SoundTouch speakers. This is particularly useful for maintaining Spotify Connect functionality after the Bose cloud shutdown (scheduled for May 2026).
|
||||
|
||||
## OAuth Flows
|
||||
|
||||
The service supports two primary OAuth flows: a browser-based flow and a mobile app-based flow (specifically for the [ueberboese](https://github.com/julius-d/ueberboese-app) app).
|
||||
|
||||
### 1. Browser-based Flow
|
||||
|
||||
The user initiates the flow, completes authorization in their browser, and is redirected back to the service.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Client as Client (curl/app)
|
||||
participant Service as Service
|
||||
participant Spotify as Spotify Auth Server
|
||||
participant Browser as User's Browser
|
||||
|
||||
Client->>Service: POST /mgmt/spotify/init [Basic Auth]
|
||||
Service-->>Client: {"redirectUrl": "https://accounts.spotify.com/authorize?..."}
|
||||
|
||||
Client->>Browser: User opens URL
|
||||
Browser->>Spotify: User logs in & grants access
|
||||
Spotify-->>Browser: Redirect to /mgmt/spotify/callback?code=abc
|
||||
|
||||
Browser->>Service: GET /mgmt/spotify/callback?code=abc
|
||||
Note over Service: No auth needed for callback
|
||||
|
||||
Service->>Spotify: POST /api/token (exchange code)
|
||||
Spotify-->>Service: {access_token, refresh_token}
|
||||
|
||||
Service->>Spotify: GET /v1/me (fetch profile)
|
||||
Spotify-->>Service: {id, display_name, email}
|
||||
|
||||
Note over Service: Store account to disk
|
||||
|
||||
Service-->>Browser: HTML: "Spotify Connected. You can close this window."
|
||||
```
|
||||
|
||||
### 2. Mobile App Flow (ueberboese)
|
||||
|
||||
The mobile app handles the redirect via a deep link and then confirms the authorization with the service.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant App as ueberboese Flutter App
|
||||
participant Service as Service
|
||||
participant Spotify as Spotify Auth Server
|
||||
|
||||
App->>Service: POST /mgmt/spotify/init [Basic Auth]
|
||||
Service-->>App: {"redirectUrl": "https://..."}
|
||||
|
||||
App->>Spotify: Open in-app browser (User authorizes)
|
||||
Spotify-->>App: Deep link redirect: ueberboese-login://spotify?code=abc
|
||||
|
||||
App->>Service: POST /mgmt/spotify/confirm?code=abc [Basic Auth]
|
||||
|
||||
Service->>Spotify: POST /api/token (exchange code)
|
||||
Spotify-->>Service: {access_token, refresh_token}
|
||||
|
||||
Service->>Spotify: GET /v1/me (fetch profile)
|
||||
Spotify-->>Service: {profile}
|
||||
|
||||
Service-->>App: {"ok": true}
|
||||
```
|
||||
|
||||
### 3. Token Retrieval (Boot Primer / Speaker Setup)
|
||||
|
||||
Once an account is linked, access tokens can be retrieved for use with speakers (e.g., via the `addUser` ZeroConf command).
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Primer as Boot Primer Script
|
||||
participant Service as Service
|
||||
participant Spotify as Spotify Token API
|
||||
participant Speaker as Speaker (Bose ST 20)
|
||||
|
||||
Primer->>Service: GET /mgmt/spotify/token [Basic Auth]
|
||||
|
||||
alt Token expired
|
||||
Service->>Spotify: POST /api/token (refresh)
|
||||
Spotify-->>Service: new tokens
|
||||
end
|
||||
|
||||
Service-->>Primer: {"access_token": "...", "username": "..."}
|
||||
|
||||
Note over Primer: Spotify Connect ZeroConf
|
||||
Primer->>Speaker: POST /SpotifyConnect (addUser with token)
|
||||
Speaker-->>Primer: OK
|
||||
Note over Speaker: Speaker now has Spotify access
|
||||
```
|
||||
|
||||
## Boot Primer Script
|
||||
|
||||
A boot primer script that uses these endpoints to feed Spotify tokens to speakers via ZeroConf is available in the `scripts/spotify/` directory: [spotify-boot-primer.sh](../../scripts/spotify/spotify-boot-primer.sh).
|
||||
|
||||
This script can be installed on the speaker itself (which runs embedded Linux) to automatically prime Spotify Connect at boot time. See [README.md](../../scripts/spotify/README.md) and [INSTALL.md](../../scripts/spotify/INSTALL.md) for instructions.
|
||||
|
||||
### Automated Installation via Service
|
||||
|
||||
The SoundTouch service provides a dedicated management endpoint to automatically handle the installation of the Spotify boot primer on the speaker:
|
||||
`POST /mgmt/devices/{deviceId}/spotify/install-primer`
|
||||
|
||||
### Automated Installation Steps
|
||||
When you run the Spotify primer installation, the service performs the following:
|
||||
1. **Directories**: Creates `/mnt/nv/bin` and `/mnt/nv/BoseApp-Persistence/1` on the speaker.
|
||||
2. **Binary**: Uploads the `spotify-boot-primer` script to the speaker.
|
||||
3. **Configuration**: Automatically generates and uploads `spotify-primer.conf` containing the service's URL and management credentials.
|
||||
4. **Boot Hook**: Injects a call to the primer in the speaker's `/mnt/nv/rc.local` using idempotent markers.
|
||||
5. **Environment**: Updates `/mnt/nv/.profile` to include `/mnt/nv/bin` in the `PATH` for easier manual troubleshooting via SSH.
|
||||
|
||||
- **Idempotent Patching**: The service uses explicit markers to inject the hook, ensuring it doesn't corrupt existing content.
|
||||
- **Coexistence**: The service-injected hook is designed to coexist with a manually installed `rc.local` (e.g., from the community gist). It only adds a call to `/mnt/nv/bin/spotify-boot-primer` if it's not already managed by a service-controlled block.
|
||||
- **Markers**: Look for the following markers in your speaker's `/mnt/nv/rc.local`:
|
||||
- `# --- Aftertouch Spotify hook START ---`
|
||||
- `# --- Aftertouch Spotify hook END ---`
|
||||
- **Cleanup**: Reverting a migration via the service will cleanly remove these marker-delimited blocks.
|
||||
|
||||
## Endpoints
|
||||
|
||||
| Method | Path | Auth | Purpose |
|
||||
|--------|---------------------------------------------------|-------|-----------------------------------------------------------------------|
|
||||
| POST | `/mgmt/devices/{deviceId}/spotify/install-primer` | Basic | Install Spotify boot primer on speaker (deviceId or IP) |
|
||||
| GET | `/mgmt/spotify/callback` | None | Browser OAuth callback (redirect from Spotify, returns HTML) |
|
||||
| POST | `/mgmt/spotify/init` | Basic | Start OAuth flow, returns authorization URL |
|
||||
| POST | `/mgmt/spotify/confirm` | Basic | Mobile app confirm (ueberboese deep link delivers code, returns JSON) |
|
||||
| GET | `/mgmt/spotify/accounts` | Basic | List linked Spotify accounts (tokens stripped) |
|
||||
| GET | `/mgmt/spotify/token` | Basic | Get fresh access token (auto-refreshes if expired) |
|
||||
| POST | `/mgmt/spotify/entity` | Basic | Resolve Spotify URI to name + image URL |
|
||||
|
||||
## Security
|
||||
|
||||
- `/mgmt/spotify/callback` is intentionally outside Basic Auth to allow direct redirects from Spotify's authorization server.
|
||||
- All other `/mgmt/*` endpoints require Basic Auth as configured by `--mgmt-username` and `--mgmt-password`.
|
||||
- Tokens are persisted to disk as JSON with restricted file permissions (`0600`).
|
||||
- The `GetAccounts` endpoint strips sensitive tokens from the response.
|
||||
@@ -0,0 +1,84 @@
|
||||
# Spotify Priming Strategy
|
||||
|
||||
This document outlines the strategy for ensuring Bose SoundTouch devices are correctly "primed" for Spotify Connect integration within the AfterTouch ecosystem.
|
||||
|
||||
## Overview
|
||||
|
||||
To enable Spotify Connect for SoundTouch devices, especially for remote availability outside the local network, the speaker must be associated with a Spotify account via a process called "priming." This involves sending an `addUser` command to the speaker's ZeroConf API (port 8200) containing a valid Spotify username and OAuth access token.
|
||||
|
||||
AfterTouch adopts a **Server-Centric Hybrid Model** that prioritizes device cleanliness and user intent while providing automated self-healing.
|
||||
|
||||
## Core Principles
|
||||
|
||||
### 1. User Intent (Opt-in)
|
||||
AfterTouch replicates the native Bose "Add Source" experience. No Spotify priming occurs until a user explicitly links their Spotify account through the AfterTouch Management Dashboard. This ensures privacy and respects users who do not wish to use Spotify.
|
||||
|
||||
### 2. Device Cleanliness (Minimalist Footprint)
|
||||
We avoid invasive modifications to the speaker's filesystem.
|
||||
- **No On-Device Scripts:** We deprecate the use of internal boot-primer scripts.
|
||||
- **Native Communication:** We rely on the speaker's native ability to talk to Bose services, which are intercepted via DNS to point to the AfterTouch server.
|
||||
|
||||
### 3. Triggers for Priming
|
||||
Priming is triggered when the speaker signals it is active and ready, specifically:
|
||||
|
||||
- **Power On:** When the speaker calls the `/marge/streaming/support/power_on` endpoint, AfterTouch ensures the device's ZeroConf state is correctly primed. This is the primary trigger.
|
||||
- **Manual Override:** Users can manually trigger a "Prime Spotify" from the device list in the UI if needed.
|
||||
|
||||
During any of these events, the server:
|
||||
1. Checks if a Spotify account is linked in AfterTouch.
|
||||
2. Checks the device's current priming status (via ZeroConf).
|
||||
3. If unprimed and an account is linked, it pushes the priming command.
|
||||
|
||||
### 4. Automated Recovery
|
||||
AfterTouch ensures that if a speaker loses its session (due to a crash or power loss), it is re-primed when it next powers on and reaches out to the service.
|
||||
|
||||
### 5. Decoupling
|
||||
The logic for account management and device interaction remains decoupled:
|
||||
- **Spotify Service:** Manages OAuth tokens and account state.
|
||||
- **Discovery Service:** Finds devices and tracks their network presence.
|
||||
- **Orchestrator:** Connects the two, deciding when to push tokens to discovered devices based on the current link status.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Initial Setup (The "Add Source" UX)
|
||||
1. User opens the AfterTouch Dashboard.
|
||||
2. User selects "Link Spotify Account."
|
||||
3. OAuth flow completes; AfterTouch stores the token.
|
||||
4. AfterTouch immediately triggers a discovery run to find and prime all compatible speakers.
|
||||
|
||||
### Maintenance (The "Watchdog" UX)
|
||||
1. A speaker reboots or loses its token.
|
||||
2. A discovery event occurs (periodic or triggered by UI).
|
||||
3. AfterTouch detects the "Empty" user state on the speaker.
|
||||
4. AfterTouch pushes a fresh token from the Spotify Service.
|
||||
5. UI reflects that the device is "Managed by AfterTouch" and healthy.
|
||||
|
||||
### Manual Override
|
||||
Users can manually trigger a "Re-prime" or "Refresh Link" from the device list in the UI if they suspect the automated self-healing is delayed or if they want to force a specific account onto a device.
|
||||
|
||||
## Network Topology & Deployment Scenarios
|
||||
|
||||
The strategy adapts based on where the AfterTouch server is deployed:
|
||||
|
||||
### Local Deployment (Home Server / Docker)
|
||||
- **Mechanism:** Both "Pull" (Marge) and "Push" (ZeroConf side-channel) are used.
|
||||
- **Advantage:** The server can proactively fix the speaker's state via port 8200 as soon as it sees a "Liveness Signal."
|
||||
|
||||
### External Deployment (Cloud VPS)
|
||||
- **Mechanism:** Primarily relies on "Pull" (Marge).
|
||||
- **Constraint:** The server cannot reach port 8200 on the speaker due to NAT/Firewall.
|
||||
- **Strategy:** In this scenario, AfterTouch acts as a passive token provider. The speaker must initiate the connection to our intercepted Bose endpoints to receive its Spotify configuration. If the speaker completely loses its user state and stops "pulling," a manual re-prime from a local machine or a temporary local discovery run might be required.
|
||||
|
||||
## Transition & Cleanup
|
||||
|
||||
As AfterTouch moves to the Server-Centric model, we will:
|
||||
1. **Revert On-Device Migration:** Update the Setup Manager to remove legacy `spotify-boot-primer` scripts and `rc.local` hooks from the speakers.
|
||||
2. **Consolidated Directory:** We maintain the `/mnt/nv/soundtouch-service/` base directory for other configuration needs (e.g., `aftertouch.resolv.conf`), but it will no longer contain Spotify-specific credentials or scripts.
|
||||
3. **No On-Device Credentials:** The `/mnt/nv/soundtouch-service/spotify-primer.conf` will be removed, ensuring that no sensitive AfterTouch login details are stored on the speaker in plain text.
|
||||
|
||||
## Implementation Roadmap (Conceptual)
|
||||
|
||||
1. **Revert On-Device Migration:** Update the Setup Manager to remove legacy scripts and `rc.local` hooks.
|
||||
2. **Server-Side Priming Logic:** Implement a `PrimeDevice(ip)` method in the server that fetches a fresh token and calls the ZeroConf API.
|
||||
3. **Discovery Hook:** Integrate `PrimeDevice` into the discovery handler (`handleDiscoveredDevice`) with a check for unprimed state.
|
||||
4. **UI Enhancements:** Update the Speaker List to show "Spotify Linked" status and provide manual refresh buttons.
|
||||
@@ -0,0 +1,989 @@
|
||||
# Technical Specification - Enhanced State Management System
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [System Architecture](#system-architecture)
|
||||
2. [Data Models](#data-models)
|
||||
3. [API Specifications](#api-specifications)
|
||||
4. [File Format Specifications](#file-format-specifications)
|
||||
5. [State Machine Definitions](#state-machine-definitions)
|
||||
6. [Event Processing](#event-processing)
|
||||
7. [Performance Requirements](#performance-requirements)
|
||||
8. [Security Considerations](#security-considerations)
|
||||
9. [Error Handling](#error-handling)
|
||||
10. [Monitoring and Observability](#monitoring-and-observability)
|
||||
|
||||
## System Architecture
|
||||
|
||||
### Component Overview
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ SoundTouch Service │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ HTTP Router & Middleware │
|
||||
│ ├── Mirror Middleware (Enhanced) │
|
||||
│ ├── Recorder Middleware │
|
||||
│ ├── Disparity Detection │
|
||||
│ └── Health Check Middleware │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Service Layer │
|
||||
│ ├── Account Manager ├── Lifecycle Manager │
|
||||
│ ├── Migration Controller ├── Data Source Router │
|
||||
│ ├── Event Processor ├── Health Monitor │
|
||||
│ └── Export Manager └── Analytics Engine │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Data Layer │
|
||||
│ ├── Enhanced DataStore ├── Event Store │
|
||||
│ ├── Mirror Cache ├── Metrics Store │
|
||||
│ └── Configuration Store └── Session Store │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ External Integrations │
|
||||
│ ├── Bose Services (Mirror) ├── Device Discovery │
|
||||
│ ├── BMX/TuneIn Services └── SSH/Setup Manager │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Package Structure
|
||||
|
||||
```
|
||||
pkg/service/
|
||||
├── account/ # Account management
|
||||
│ ├── manager.go
|
||||
│ ├── persistence.go
|
||||
│ └── validation.go
|
||||
├── lifecycle/ # Device lifecycle management
|
||||
│ ├── manager.go
|
||||
│ ├── states.go
|
||||
│ ├── transitions.go
|
||||
│ └── events.go
|
||||
├── migration/ # Enhanced migration (extends existing)
|
||||
│ ├── controller.go
|
||||
│ ├── strategies.go
|
||||
│ └── progress.go
|
||||
├── datasource/ # Data source routing
|
||||
│ ├── router.go
|
||||
│ ├── preferences.go
|
||||
│ └── fallback.go
|
||||
├── events/ # Event processing system
|
||||
│ ├── processor.go
|
||||
│ ├── queue.go
|
||||
│ └── storage.go
|
||||
├── mirror/ # Enhanced mirroring (extends existing)
|
||||
│ ├── disparity.go
|
||||
│ ├── analyzer.go
|
||||
│ └── logger.go
|
||||
├── health/ # System monitoring
|
||||
│ ├── monitor.go
|
||||
│ ├── metrics.go
|
||||
│ └── alerts.go
|
||||
└── export/ # Data export and backup
|
||||
├── exporter.go
|
||||
├── formats.go
|
||||
└── backup.go
|
||||
```
|
||||
|
||||
## Data Models
|
||||
|
||||
### Account Model
|
||||
|
||||
```go
|
||||
type Account struct {
|
||||
ID string `json:"id"`
|
||||
Name string `json:"name"`
|
||||
Email string `json:"email,omitempty"`
|
||||
CreatedAt time.Time `json:"created_at"`
|
||||
UpdatedAt time.Time `json:"updated_at"`
|
||||
Status AccountStatus `json:"status"`
|
||||
DeviceCount int `json:"device_count"`
|
||||
MigrationInfo *MigrationInfo `json:"migration_info,omitempty"`
|
||||
BoseAccountID string `json:"bose_account_id,omitempty"`
|
||||
DataSources DataSourceConfig `json:"data_sources"`
|
||||
Settings AccountSettings `json:"settings"`
|
||||
}
|
||||
|
||||
type AccountStatus string
|
||||
const (
|
||||
AccountStatusActive AccountStatus = "active"
|
||||
AccountStatusMigrating AccountStatus = "migrating"
|
||||
AccountStatusSuspended AccountStatus = "suspended"
|
||||
AccountStatusArchived AccountStatus = "archived"
|
||||
)
|
||||
|
||||
type MigrationInfo struct {
|
||||
StartedAt time.Time `json:"started_at"`
|
||||
CompletedAt *time.Time `json:"completed_at,omitempty"`
|
||||
DevicesMigrated int `json:"devices_migrated"`
|
||||
DevicesPending int `json:"devices_pending"`
|
||||
MirrorActive bool `json:"mirror_active"`
|
||||
Strategy string `json:"strategy"`
|
||||
RollbackData string `json:"rollback_data,omitempty"`
|
||||
}
|
||||
|
||||
type DataSourceConfig struct {
|
||||
Local bool `json:"local"`
|
||||
BoseMirror bool `json:"bose_mirror"`
|
||||
Primary string `json:"primary"` // "local" or "bose"
|
||||
}
|
||||
|
||||
type AccountSettings struct {
|
||||
AutoMigration bool `json:"auto_migration"`
|
||||
MirrorEndpoints []string `json:"mirror_endpoints"`
|
||||
RetentionDays int `json:"retention_days"`
|
||||
}
|
||||
```
|
||||
|
||||
### Device Lifecycle Model
|
||||
|
||||
```go
|
||||
type DeviceLifecycle struct {
|
||||
DeviceID string `json:"device_id"`
|
||||
AccountID string `json:"account_id"`
|
||||
State DeviceState `json:"state"`
|
||||
CreatedAt time.Time `json:"created_at"`
|
||||
UpdatedAt time.Time `json:"updated_at"`
|
||||
StateHistory []StateTransition `json:"state_history"`
|
||||
Metadata DeviceMetadata `json:"metadata"`
|
||||
DataSources DataSourceConfig `json:"data_sources"`
|
||||
Migration *DeviceMigration `json:"migration,omitempty"`
|
||||
Health DeviceHealth `json:"health"`
|
||||
}
|
||||
|
||||
type DeviceState string
|
||||
const (
|
||||
DeviceStateUnregistered DeviceState = "unregistered"
|
||||
DeviceStateDiscovered DeviceState = "discovered"
|
||||
DeviceStateRegistering DeviceState = "registering"
|
||||
DeviceStateActive DeviceState = "active"
|
||||
DeviceStateMigrating DeviceState = "migrating"
|
||||
DeviceStateOffline DeviceState = "offline"
|
||||
DeviceStateError DeviceState = "error"
|
||||
DeviceStateRetired DeviceState = "retired"
|
||||
)
|
||||
|
||||
type StateTransition struct {
|
||||
From DeviceState `json:"from"`
|
||||
To DeviceState `json:"to"`
|
||||
Timestamp time.Time `json:"timestamp"`
|
||||
Reason string `json:"reason"`
|
||||
Source string `json:"source"`
|
||||
Context map[string]interface{} `json:"context,omitempty"`
|
||||
}
|
||||
|
||||
type DeviceMetadata struct {
|
||||
Name string `json:"name"`
|
||||
Type string `json:"type"`
|
||||
SerialNumber string `json:"serial_number"`
|
||||
FirmwareVersion string `json:"firmware_version"`
|
||||
MACAddress string `json:"mac_address"`
|
||||
IPAddress string `json:"ip_address"`
|
||||
LastSeen time.Time `json:"last_seen"`
|
||||
IsLegacyID bool `json:"is_legacy_id"`
|
||||
Capabilities []string `json:"capabilities,omitempty"`
|
||||
}
|
||||
|
||||
type DeviceMigration struct {
|
||||
FromBoseAccount string `json:"from_bose_account,omitempty"`
|
||||
MigratedAt *time.Time `json:"migrated_at,omitempty"`
|
||||
Method string `json:"method"`
|
||||
RollbackAvailable bool `json:"rollback_available"`
|
||||
DataPreserved []string `json:"data_preserved"`
|
||||
}
|
||||
|
||||
type DeviceHealth struct {
|
||||
Status string `json:"status"` // "healthy", "warning", "error"
|
||||
LastCheck time.Time `json:"last_check"`
|
||||
ResponseTime int `json:"response_time_ms"`
|
||||
Connectivity string `json:"connectivity"` // "online", "offline", "intermittent"
|
||||
ErrorCount int `json:"error_count"`
|
||||
LastError string `json:"last_error,omitempty"`
|
||||
}
|
||||
```
|
||||
|
||||
### Event Model
|
||||
|
||||
```go
|
||||
type DeviceEvent struct {
|
||||
ID string `json:"id"`
|
||||
DeviceID string `json:"device_id"`
|
||||
AccountID string `json:"account_id"`
|
||||
Type DeviceEventType `json:"type"`
|
||||
Data map[string]interface{} `json:"data"`
|
||||
Timestamp time.Time `json:"timestamp"`
|
||||
Source EventSource `json:"source"`
|
||||
Processed bool `json:"processed"`
|
||||
Context EventContext `json:"context"`
|
||||
}
|
||||
|
||||
type DeviceEventType string
|
||||
const (
|
||||
EventTypeNowPlaying DeviceEventType = "now_playing"
|
||||
EventTypePresetChanged DeviceEventType = "preset_changed"
|
||||
EventTypeVolumeChanged DeviceEventType = "volume_changed"
|
||||
EventTypeSourceChanged DeviceEventType = "source_changed"
|
||||
EventTypeDeviceOnline DeviceEventType = "device_online"
|
||||
EventTypeDeviceOffline DeviceEventType = "device_offline"
|
||||
EventTypeZoneChanged DeviceEventType = "zone_changed"
|
||||
EventTypeDisparityFound DeviceEventType = "disparity_found"
|
||||
EventTypeMigrationStart DeviceEventType = "migration_start"
|
||||
EventTypeMigrationEnd DeviceEventType = "migration_end"
|
||||
EventTypeHealthCheck DeviceEventType = "health_check"
|
||||
EventTypeErrorOccurred DeviceEventType = "error_occurred"
|
||||
)
|
||||
|
||||
type EventSource string
|
||||
const (
|
||||
EventSourceWebSocket EventSource = "websocket"
|
||||
EventSourceDiscovery EventSource = "discovery"
|
||||
EventSourceMirror EventSource = "mirror"
|
||||
EventSourceSystem EventSource = "system"
|
||||
EventSourceAPI EventSource = "api"
|
||||
EventSourceUser EventSource = "user"
|
||||
)
|
||||
|
||||
type EventContext struct {
|
||||
RequestID string `json:"request_id,omitempty"`
|
||||
UserAgent string `json:"user_agent,omitempty"`
|
||||
IPAddress string `json:"ip_address,omitempty"`
|
||||
Endpoint string `json:"endpoint,omitempty"`
|
||||
Additional map[string]interface{} `json:"additional,omitempty"`
|
||||
}
|
||||
```
|
||||
|
||||
### Disparity Model
|
||||
|
||||
```go
|
||||
type Disparity struct {
|
||||
ID string `json:"id"`
|
||||
Timestamp time.Time `json:"timestamp"`
|
||||
DeviceID string `json:"device_id"`
|
||||
AccountID string `json:"account_id"`
|
||||
Endpoint string `json:"endpoint"`
|
||||
Type DisparityType `json:"type"`
|
||||
Severity DisparitySeverity `json:"severity"`
|
||||
LocalHash string `json:"local_hash"`
|
||||
UpstreamHash string `json:"upstream_hash"`
|
||||
Details DisparityDetails `json:"details"`
|
||||
Context map[string]interface{} `json:"context"`
|
||||
Resolved bool `json:"resolved"`
|
||||
}
|
||||
|
||||
type DisparityType string
|
||||
const (
|
||||
DisparityTypeContentMismatch DisparityType = "content_mismatch"
|
||||
DisparityTypeStructureDiff DisparityType = "structure_diff"
|
||||
DisparityTypeTimestampFormat DisparityType = "timestamp_format"
|
||||
DisparityTypeFieldMissing DisparityType = "field_missing"
|
||||
DisparityTypeValueMismatch DisparityType = "value_mismatch"
|
||||
DisparityTypeCountMismatch DisparityType = "count_mismatch"
|
||||
)
|
||||
|
||||
type DisparitySeverity string
|
||||
const (
|
||||
DisparitySeverityLow DisparitySeverity = "low"
|
||||
DisparitySeverityMedium DisparitySeverity = "medium"
|
||||
DisparitySeverityHigh DisparitySeverity = "high"
|
||||
DisparitySeverityCritical DisparitySeverity = "critical"
|
||||
)
|
||||
|
||||
type DisparityDetails struct {
|
||||
FieldPath string `json:"field_path"`
|
||||
LocalValue interface{} `json:"local_value"`
|
||||
UpstreamValue interface{} `json:"upstream_value"`
|
||||
Description string `json:"description"`
|
||||
}
|
||||
```
|
||||
|
||||
## API Specifications
|
||||
|
||||
### Account Management APIs
|
||||
|
||||
#### Create Account
|
||||
```http
|
||||
POST /api/v1/accounts
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"name": "User Account",
|
||||
"email": "user@example.com",
|
||||
"settings": {
|
||||
"auto_migration": false,
|
||||
"retention_days": 30
|
||||
}
|
||||
}
|
||||
|
||||
Response: 201 Created
|
||||
{
|
||||
"id": "acc_12345",
|
||||
"name": "User Account",
|
||||
"email": "user@example.com",
|
||||
"created_at": "2024-01-20T10:00:00Z",
|
||||
"status": "active",
|
||||
"device_count": 0
|
||||
}
|
||||
```
|
||||
|
||||
#### Get Account
|
||||
```http
|
||||
GET /api/v1/accounts/{account_id}
|
||||
|
||||
Response: 200 OK
|
||||
{
|
||||
"id": "acc_12345",
|
||||
"name": "User Account",
|
||||
"status": "active",
|
||||
"device_count": 2,
|
||||
"migration_info": {
|
||||
"started_at": "2024-01-18T09:00:00Z",
|
||||
"devices_migrated": 1,
|
||||
"devices_pending": 1,
|
||||
"mirror_active": true
|
||||
},
|
||||
"data_sources": {
|
||||
"local": true,
|
||||
"bose_mirror": true,
|
||||
"primary": "bose"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### List Accounts
|
||||
```http
|
||||
GET /api/v1/accounts?status=active&limit=10&offset=0
|
||||
|
||||
Response: 200 OK
|
||||
{
|
||||
"accounts": [...],
|
||||
"total": 5,
|
||||
"limit": 10,
|
||||
"offset": 0
|
||||
}
|
||||
```
|
||||
|
||||
### Device Lifecycle APIs
|
||||
|
||||
#### Register Device
|
||||
```http
|
||||
POST /api/v1/accounts/{account_id}/devices
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"device_id": "A81B6A536A98",
|
||||
"name": "Living Room Speaker",
|
||||
"registration_type": "fresh"
|
||||
}
|
||||
|
||||
Response: 201 Created
|
||||
{
|
||||
"device_id": "A81B6A536A98",
|
||||
"account_id": "acc_12345",
|
||||
"state": "registering",
|
||||
"created_at": "2024-01-20T10:00:00Z"
|
||||
}
|
||||
```
|
||||
|
||||
#### Get Device State
|
||||
```http
|
||||
GET /api/v1/accounts/{account_id}/devices/{device_id}/state
|
||||
|
||||
Response: 200 OK
|
||||
{
|
||||
"device_id": "A81B6A536A98",
|
||||
"account_id": "acc_12345",
|
||||
"state": "active",
|
||||
"metadata": {
|
||||
"name": "Living Room Speaker",
|
||||
"type": "SoundTouch 30",
|
||||
"last_seen": "2024-01-20T15:30:00Z"
|
||||
},
|
||||
"health": {
|
||||
"status": "healthy",
|
||||
"connectivity": "online",
|
||||
"response_time": 45
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Migrate Device
|
||||
```http
|
||||
POST /api/v1/accounts/{account_id}/devices/{device_id}/migrate
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"from_bose_account": "bose-acc-xyz",
|
||||
"preserve_data": true,
|
||||
"method": "gradual"
|
||||
}
|
||||
|
||||
Response: 202 Accepted
|
||||
{
|
||||
"migration_id": "mig_67890",
|
||||
"status": "started",
|
||||
"estimated_completion": "2024-01-20T11:00:00Z"
|
||||
}
|
||||
```
|
||||
|
||||
### Event APIs
|
||||
|
||||
#### Get Device Events
|
||||
```http
|
||||
GET /api/v1/accounts/{account_id}/devices/{device_id}/events?since=2024-01-20T00:00:00Z&type=now_playing&limit=50
|
||||
|
||||
Response: 200 OK
|
||||
{
|
||||
"events": [
|
||||
{
|
||||
"id": "evt_12345",
|
||||
"type": "now_playing",
|
||||
"timestamp": "2024-01-20T15:30:00Z",
|
||||
"data": {
|
||||
"source": "SPOTIFY",
|
||||
"track": "Song Name",
|
||||
"artist": "Artist Name"
|
||||
}
|
||||
}
|
||||
],
|
||||
"total": 125,
|
||||
"has_more": true
|
||||
}
|
||||
```
|
||||
|
||||
#### Stream Events
|
||||
```http
|
||||
GET /api/v1/accounts/{account_id}/devices/{device_id}/events/stream
|
||||
Accept: text/event-stream
|
||||
|
||||
Response: 200 OK
|
||||
Content-Type: text/event-stream
|
||||
|
||||
data: {"id":"evt_12346","type":"volume_changed","timestamp":"2024-01-20T15:31:00Z","data":{"volume":50}}
|
||||
|
||||
data: {"id":"evt_12347","type":"now_playing","timestamp":"2024-01-20T15:32:00Z","data":{"source":"TUNEIN"}}
|
||||
```
|
||||
|
||||
### Monitoring APIs
|
||||
|
||||
#### System Health
|
||||
```http
|
||||
GET /api/v1/system/health
|
||||
|
||||
Response: 200 OK
|
||||
{
|
||||
"status": "healthy",
|
||||
"timestamp": "2024-01-20T15:30:00Z",
|
||||
"services": {
|
||||
"account_manager": "healthy",
|
||||
"lifecycle_manager": "healthy",
|
||||
"event_processor": "healthy",
|
||||
"mirror_service": "warning"
|
||||
},
|
||||
"statistics": {
|
||||
"total_accounts": 5,
|
||||
"total_devices": 12,
|
||||
"active_devices": 10,
|
||||
"events_processed_24h": 1547
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Disparity Analysis
|
||||
```http
|
||||
GET /api/v1/system/disparities?since=2024-01-20T00:00:00Z&severity=high
|
||||
|
||||
Response: 200 OK
|
||||
{
|
||||
"disparities": [
|
||||
{
|
||||
"id": "disp_12345",
|
||||
"timestamp": "2024-01-20T14:30:00Z",
|
||||
"endpoint": "/v1/presets",
|
||||
"type": "count_mismatch",
|
||||
"severity": "high",
|
||||
"details": {
|
||||
"field_path": "preset_count",
|
||||
"local_value": 5,
|
||||
"upstream_value": 4
|
||||
}
|
||||
}
|
||||
],
|
||||
"summary": {
|
||||
"total": 15,
|
||||
"by_severity": {
|
||||
"high": 2,
|
||||
"medium": 8,
|
||||
"low": 5
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## File Format Specifications
|
||||
|
||||
### Account Metadata (account.json)
|
||||
```json
|
||||
{
|
||||
"version": "1.0",
|
||||
"id": "acc_12345",
|
||||
"name": "User Account",
|
||||
"email": "user@example.com",
|
||||
"created_at": "2024-01-20T10:00:00Z",
|
||||
"updated_at": "2024-01-20T15:30:00Z",
|
||||
"status": "active",
|
||||
"device_count": 2,
|
||||
"migration_info": {
|
||||
"started_at": "2024-01-18T09:00:00Z",
|
||||
"devices_migrated": 1,
|
||||
"devices_pending": 1,
|
||||
"mirror_active": true,
|
||||
"strategy": "gradual"
|
||||
},
|
||||
"bose_account_id": "bose-original-id",
|
||||
"data_sources": {
|
||||
"local": true,
|
||||
"bose_mirror": true,
|
||||
"primary": "bose"
|
||||
},
|
||||
"settings": {
|
||||
"auto_migration": false,
|
||||
"mirror_endpoints": ["/v1/presets", "/v1/recents"],
|
||||
"retention_days": 30
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Device Lifecycle (lifecycle.json)
|
||||
```json
|
||||
{
|
||||
"version": "1.0",
|
||||
"device_id": "A81B6A536A98",
|
||||
"account_id": "acc_12345",
|
||||
"state": "active",
|
||||
"created_at": "2024-01-20T10:00:00Z",
|
||||
"updated_at": "2024-01-20T15:30:00Z",
|
||||
"state_history": [
|
||||
{
|
||||
"from": "unregistered",
|
||||
"to": "discovered",
|
||||
"timestamp": "2024-01-20T10:00:00Z",
|
||||
"reason": "mdns_discovery",
|
||||
"source": "discovery",
|
||||
"context": {
|
||||
"ip_address": "192.168.1.100",
|
||||
"discovery_method": "mdns"
|
||||
}
|
||||
},
|
||||
{
|
||||
"from": "discovered",
|
||||
"to": "active",
|
||||
"timestamp": "2024-01-20T10:05:00Z",
|
||||
"reason": "registration_complete",
|
||||
"source": "system"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"name": "Living Room Speaker",
|
||||
"type": "SoundTouch 30",
|
||||
"serial_number": "I6332527703739342000020",
|
||||
"firmware_version": "4.8.1.25341.2677643.1597353330",
|
||||
"mac_address": "A8:1B:6A:53:6A:98",
|
||||
"ip_address": "192.168.1.100",
|
||||
"last_seen": "2024-01-20T15:30:00Z",
|
||||
"is_legacy_id": false,
|
||||
"capabilities": ["multiroom", "bluetooth", "aux"]
|
||||
},
|
||||
"data_sources": {
|
||||
"presets": "local",
|
||||
"recents": "mirror_primary",
|
||||
"sources": "local"
|
||||
},
|
||||
"migration": {
|
||||
"from_bose_account": "bose-acc-xyz",
|
||||
"migrated_at": "2024-01-18T14:30:00Z",
|
||||
"method": "gradual",
|
||||
"rollback_available": true,
|
||||
"data_preserved": ["presets", "recents", "sources"]
|
||||
},
|
||||
"health": {
|
||||
"status": "healthy",
|
||||
"last_check": "2024-01-20T15:30:00Z",
|
||||
"response_time": 45,
|
||||
"connectivity": "online",
|
||||
"error_count": 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Event Log Format (events.log)
|
||||
```
|
||||
# SoundTouch Service Event Log - Device A81B6A536A98
|
||||
# Format: TIMESTAMP|EVENT_ID|EVENT_TYPE|SOURCE|DATA_JSON
|
||||
# Version: 1.0
|
||||
|
||||
2024-01-20T15:30:00.123Z|evt_12345|now_playing|websocket|{"source":"SPOTIFY","track":"Song Name","artist":"Artist Name","album":"Album Name"}
|
||||
2024-01-20T15:30:30.456Z|evt_12346|volume_changed|websocket|{"volume":45,"muted":false,"previous_volume":40}
|
||||
2024-01-20T15:31:00.789Z|evt_12347|preset_selected|websocket|{"preset":1,"source":"SPOTIFY","location":"spotify:track:123abc"}
|
||||
2024-01-20T15:31:15.012Z|evt_12348|disparity_detected|mirror|{"endpoint":"/v1/presets","local_hash":"abc123","upstream_hash":"def456","severity":"medium"}
|
||||
2024-01-20T15:32:00.345Z|evt_12349|health_check|system|{"response_time":42,"status":"healthy","connectivity":"online"}
|
||||
```
|
||||
|
||||
### Disparity Log Format (disparities.log)
|
||||
```
|
||||
# SoundTouch Service Disparity Log
|
||||
# Format: TIMESTAMP|DISPARITY_ID|DEVICE_ID|ACCOUNT_ID|ENDPOINT|TYPE|SEVERITY|DETAILS_JSON
|
||||
# Version: 1.0
|
||||
|
||||
2024-01-20T15:31:15.012Z|disp_12345|A81B6A536A98|acc_12345|/v1/presets|count_mismatch|medium|{"field_path":"preset_count","local_value":5,"upstream_value":4,"description":"Local has one additional preset"}
|
||||
2024-01-20T15:32:45.678Z|disp_12346|A81B6A536A98|acc_12345|/v1/recents|timestamp_format|low|{"field_path":"recent[0].utc_time","local_value":"2024-01-20T15:30:00Z","upstream_value":"1705761000","description":"Timestamp format difference"}
|
||||
2024-01-20T15:35:20.901Z|disp_12347|B92C7B647B09|acc_12345|/v1/account/full|structure_diff|high|{"field_path":"device[1].ip_address","local_value":"present","upstream_value":"missing","description":"IP address field missing in upstream response"}
|
||||
```
|
||||
|
||||
## State Machine Definitions
|
||||
|
||||
### Device State Transitions
|
||||
|
||||
```
|
||||
Unregistered → Discovered (via discovery)
|
||||
Discovered → Registering (via user action/auto-registration)
|
||||
Registering → Active (via successful registration)
|
||||
Registering → Error (via registration failure)
|
||||
Active → Migrating (via migration start)
|
||||
Active → Offline (via connectivity loss)
|
||||
Migrating → Active (via migration success)
|
||||
Migrating → Error (via migration failure)
|
||||
Offline → Active (via connectivity restored)
|
||||
Error → Active (via error resolution)
|
||||
Any State → Retired (via explicit retirement)
|
||||
```
|
||||
|
||||
### State Transition Rules
|
||||
|
||||
```go
|
||||
var StateTransitionRules = map[DeviceState][]DeviceState{
|
||||
DeviceStateUnregistered: {DeviceStateDiscovered},
|
||||
DeviceStateDiscovered: {DeviceStateRegistering, DeviceStateOffline},
|
||||
DeviceStateRegistering: {DeviceStateActive, DeviceStateError},
|
||||
DeviceStateActive: {DeviceStateMigrating, DeviceStateOffline, DeviceStateRetired},
|
||||
DeviceStateMigrating: {DeviceStateActive, DeviceStateError},
|
||||
DeviceStateOffline: {DeviceStateActive, DeviceStateError, DeviceStateRetired},
|
||||
DeviceStateError: {DeviceStateActive, DeviceStateOffline, DeviceStateRetired},
|
||||
DeviceStateRetired: {}, // Terminal state
|
||||
}
|
||||
```
|
||||
|
||||
### Transition Triggers
|
||||
|
||||
```go
|
||||
type TransitionTrigger struct {
|
||||
Event DeviceEventType
|
||||
Condition func(*DeviceLifecycle, *DeviceEvent) bool
|
||||
Target DeviceState
|
||||
Reason string
|
||||
}
|
||||
|
||||
var TransitionTriggers = []TransitionTrigger{
|
||||
{
|
||||
Event: EventTypeDeviceOnline,
|
||||
Condition: isOfflineDevice,
|
||||
Target: DeviceStateActive,
|
||||
Reason: "connectivity_restored",
|
||||
},
|
||||
{
|
||||
Event: EventTypeDeviceOffline,
|
||||
Condition: isActiveDevice,
|
||||
Target: DeviceStateOffline,
|
||||
Reason: "connectivity_lost",
|
||||
},
|
||||
{
|
||||
Event: EventTypeMigrationStart,
|
||||
Condition: isActiveDevice,
|
||||
Target: DeviceStateMigrating,
|
||||
Reason: "migration_initiated",
|
||||
},
|
||||
// ... additional triggers
|
||||
}
|
||||
```
|
||||
|
||||
## Event Processing
|
||||
|
||||
### Event Queue Implementation
|
||||
|
||||
```go
|
||||
type EventQueue struct {
|
||||
buffer chan DeviceEvent
|
||||
processors []EventProcessor
|
||||
storage EventStorage
|
||||
config EventQueueConfig
|
||||
}
|
||||
|
||||
type EventQueueConfig struct {
|
||||
BufferSize int `json:"buffer_size"`
|
||||
ProcessorCount int `json:"processor_count"`
|
||||
FlushInterval time.Duration `json:"flush_interval"`
|
||||
RetryAttempts int `json:"retry_attempts"`
|
||||
DeadLetterQueue bool `json:"dead_letter_queue"`
|
||||
}
|
||||
|
||||
type EventProcessor interface {
|
||||
ProcessEvent(event DeviceEvent) error
|
||||
CanHandle(eventType DeviceEventType) bool
|
||||
}
|
||||
```
|
||||
|
||||
### Event Processing Flow
|
||||
|
||||
```
|
||||
Event Input → Validation → Queue → Processing → Storage → Notification
|
||||
↓ ↓ ↓ ↓ ↓ ↓
|
||||
Websocket Schema Buffer Parallel Files Webhooks
|
||||
Discovery Check Memory Workers Logs SSE
|
||||
API Call Format Retry DB Metrics
|
||||
System Enrich DLQ
|
||||
```
|
||||
|
||||
### Event Retention Policy
|
||||
|
||||
```go
|
||||
type RetentionPolicy struct {
|
||||
EventType DeviceEventType `json:"event_type"`
|
||||
RetentionDays int `json:"retention_days"`
|
||||
MaxCount int `json:"max_count"`
|
||||
Compression bool `json:"compression"`
|
||||
}
|
||||
|
||||
var DefaultRetentionPolicies = []RetentionPolicy{
|
||||
{EventTypeNowPlaying, 7, 1000, true},
|
||||
{EventTypeVolumeChanged, 1, 100, false},
|
||||
{EventTypeDisparityFound, 30, 10000, true},
|
||||
{EventTypeMigrationStart, 365, -1, false}, // Keep forever
|
||||
{EventTypeHealthCheck, 7, 1000, true},
|
||||
}
|
||||
```
|
||||
|
||||
### Development Requirements
|
||||
|
||||
#### KISS Principle (Keep It Simple, Stupid)
|
||||
- Prioritize simplicity and readability over performance optimization
|
||||
- Use standard Go idioms and patterns
|
||||
- Avoid premature abstraction and optimization
|
||||
- Build the simplest thing that works first
|
||||
|
||||
#### Quality Gates
|
||||
Every change must pass these checks:
|
||||
- `golangci-lint run --fix` - no linting issues
|
||||
- `go test ./...` - all tests pass with no failures
|
||||
- Integration tests verify existing functionality intact
|
||||
- Code coverage maintained or improved
|
||||
|
||||
#### Testing Requirements
|
||||
- Unit tests for all new functions
|
||||
- Integration tests for modified workflows
|
||||
- Regression tests for existing functionality
|
||||
- Mock external dependencies appropriately
|
||||
|
||||
### Simplicity-First Performance Approach
|
||||
|
||||
| Aspect | Simple Approach | Optimization Only When Needed |
|
||||
|--------|----------------|-------------------------------|
|
||||
| Memory Usage | Direct file operations, minimal caching | Add caching if performance issues arise |
|
||||
| CPU Usage | Synchronous processing initially | Add async processing if bottlenecks occur |
|
||||
| Storage | Simple append operations | Add rotation/compression when files grow large |
|
||||
| Networking | Reuse existing patterns | Optimize only if latency becomes problematic |
|
||||
|
||||
## Quality Assurance
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
#### Unit Testing
|
||||
```go
|
||||
// Example test structure
|
||||
func TestAccountManager_CreateAccount(t *testing.T) {
|
||||
tests := []struct {
|
||||
name string
|
||||
input CreateAccountRequest
|
||||
want *Account
|
||||
wantErr bool
|
||||
}{
|
||||
{
|
||||
name: "valid account creation",
|
||||
input: CreateAccountRequest{Name: "Test Account"},
|
||||
want: &Account{Name: "Test Account", Status: "active"},
|
||||
wantErr: false,
|
||||
},
|
||||
{
|
||||
name: "empty name should fail",
|
||||
input: CreateAccountRequest{Name: ""},
|
||||
want: nil,
|
||||
wantErr: true,
|
||||
},
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
got, err := manager.CreateAccount(tt.input)
|
||||
if (err != nil) != tt.wantErr {
|
||||
t.Errorf("CreateAccount() error = %v, wantErr %v", err, tt.wantErr)
|
||||
return
|
||||
}
|
||||
// Additional assertions...
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Integration Testing
|
||||
- Test with real file operations in temporary directories
|
||||
- Verify HTTP endpoints work with actual HTTP requests
|
||||
- Test interaction with existing WebSocket system
|
||||
- Ensure existing XML endpoints remain functional
|
||||
|
||||
#### Quality Gates
|
||||
```bash
|
||||
# Required before each commit
|
||||
golangci-lint run --fix
|
||||
go test ./...
|
||||
go test -race ./...
|
||||
|
||||
# Required before milestone completion
|
||||
go test ./... -v -cover
|
||||
go test -bench=. ./...
|
||||
```
|
||||
|
||||
### Security Considerations
|
||||
|
||||
#### Simple Security Model
|
||||
- Reuse existing authentication mechanisms
|
||||
- Basic input validation with standard Go validation
|
||||
- Simple file permissions (0755 for directories, 0644 for files)
|
||||
- No complex authorization initially - build incrementally
|
||||
|
||||
#### Input Validation
|
||||
```go
|
||||
// Simple validation approach
|
||||
func ValidateAccount(account *Account) error {
|
||||
if account.Name == "" {
|
||||
return errors.New("account name cannot be empty")
|
||||
}
|
||||
if len(account.Name) > 100 {
|
||||
return errors.New("account name too long")
|
||||
}
|
||||
if account.Email != "" && !isValidEmail(account.Email) {
|
||||
return errors.New("invalid email format")
|
||||
}
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Error Categories
|
||||
|
||||
```go
|
||||
type ErrorCategory string
|
||||
const (
|
||||
ErrorCategoryValidation ErrorCategory = "validation"
|
||||
ErrorCategorySystem ErrorCategory = "system"
|
||||
ErrorCategoryNetwork ErrorCategory = "network"
|
||||
ErrorCategoryStorage ErrorCategory = "storage"
|
||||
ErrorCategoryTimeout ErrorCategory = "timeout"
|
||||
ErrorCategoryAuth ErrorCategory = "authentication"
|
||||
)
|
||||
|
||||
type ServiceError struct {
|
||||
Code string `json:"code"`
|
||||
Message string `json:"message"`
|
||||
Category ErrorCategory `json:"category"`
|
||||
Timestamp time.Time `json:"timestamp"`
|
||||
Context map[string]interface{} `json:"context"`
|
||||
Retryable bool `json:"retryable"`
|
||||
Severity string `json:"severity"`
|
||||
}
|
||||
```
|
||||
|
||||
### Error Recovery Strategies
|
||||
|
||||
1. **Transient Errors**: Exponential backoff retry (3 attempts)
|
||||
2. **Storage Errors**: Graceful degradation with in-memory fallback
|
||||
3. **Network Errors**: Circuit breaker pattern with fallback data
|
||||
4. **Validation Errors**: Immediate response with detailed feedback
|
||||
5. **System Errors**: Alerting and automatic recovery attempts
|
||||
|
||||
### Error Response Format
|
||||
|
||||
```json
|
||||
{
|
||||
"error": {
|
||||
"code": "DEVICE_NOT_FOUND",
|
||||
"message": "Device with ID 'A81B6A536A98' not found in account 'acc_12345'",
|
||||
"category": "validation",
|
||||
"timestamp": "2024-01-20T15:30:00Z",
|
||||
"context": {
|
||||
"account_id": "acc_12345",
|
||||
"device_id": "A81B6A536A98",
|
||||
"request_id": "req_67890"
|
||||
},
|
||||
"retryable": false,
|
||||
"severity": "error"
|
||||
},
|
||||
"request_id": "req_67890"
|
||||
}
|
||||
```
|
||||
|
||||
## Monitoring and Observability
|
||||
|
||||
### Simple Monitoring Approach
|
||||
|
||||
#### Basic Health Check
|
||||
```go
|
||||
// Simple health check implementation
|
||||
type HealthStatus struct {
|
||||
Status string `json:"status"` // "healthy", "warning", "error"
|
||||
Timestamp time.Time `json:"timestamp"`
|
||||
Version string `json:"version"`
|
||||
Uptime string `json:"uptime"`
|
||||
}
|
||||
|
||||
func (s *Server) HandleHealthCheck(w http.ResponseWriter, r *http.Request) {
|
||||
health := HealthStatus{
|
||||
Status: "healthy",
|
||||
Timestamp: time.Now(),
|
||||
Version: version,
|
||||
Uptime: time.Since(startTime).String(),
|
||||
}
|
||||
|
||||
// Simple checks
|
||||
if !s.canWriteToDataDir() {
|
||||
health.Status = "error"
|
||||
}
|
||||
|
||||
w.Header().Set("Content-Type", "application/json")
|
||||
json.NewEncoder(w).Encode(health)
|
||||
}
|
||||
```
|
||||
|
||||
#### Leverage Existing Systems
|
||||
- Extend existing parity mismatch logging for disparity detection
|
||||
- Reuse existing interaction recording for request/response tracking
|
||||
- Build upon current discovery and migration event logging
|
||||
- Use existing WebSocket event system for device state changes
|
||||
|
||||
#### Simple Metrics
|
||||
```go
|
||||
// Basic counters - no complex metrics initially
|
||||
type SimpleMetrics struct {
|
||||
AccountsCreated int `json:"accounts_created"`
|
||||
DevicesActive int `json:"devices_active"`
|
||||
EventsProcessed int `json:"events_processed_today"`
|
||||
LastUpdate time.Time `json:"last_update"`
|
||||
}
|
||||
|
||||
// Update metrics in simple text file
|
||||
func (m *SimpleMetrics) Save(dataDir string) error {
|
||||
data, err := json.MarshalIndent(m, "", " ")
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
return os.WriteFile(filepath.Join(dataDir, "metrics.json"), data, 0644)
|
||||
}
|
||||
```
|
||||
|
||||
This technical specification provides comprehensive details for implementing the enhanced state management system while maintaining compatibility with existing SoundTouch service functionality and meeting the performance requirements for small hardware deployments.
|
||||
@@ -0,0 +1,393 @@
|
||||
# Upstream Bose Service Simulation - State Management Concept
|
||||
|
||||
## Overview
|
||||
|
||||
This document outlines the concept for simulating and replacing upstream Bose services with enhanced state management capabilities. The goal is to create a comprehensive local replacement that can handle device lifecycles, account management, and state synchronization while maintaining compatibility with existing SoundTouch devices.
|
||||
|
||||
## Use Cases
|
||||
|
||||
### Case 0: Account Management
|
||||
- **Explicit Account Creation**: Accounts must be created through deliberate action (web UI, API call)
|
||||
- **Mirror-Enhanced Creation**: Account creation can be enriched using mirrored data from upstream Bose endpoints when devices make requests
|
||||
- **Data Recording**: Passively record account information during normal device operations for future use
|
||||
|
||||
### Case 1a: Fresh Device Registration
|
||||
- Initial setup/registration of a factory-reset or new device
|
||||
- Device has no prior Bose account association
|
||||
- Full local initialization with default configurations
|
||||
|
||||
### Case 1b: Device Migration from Bose Account
|
||||
- Migrate existing registered device from Bose services to local management
|
||||
- Preserve existing device data (presets, recents, sources)
|
||||
- Support gradual migration while maintaining Bose compatibility
|
||||
- Mirror Bose account data for seamless transition
|
||||
|
||||
### Case 2: Device Lifecycle and State Management
|
||||
- Track and manage device lifecycle states and activities
|
||||
- Maintain internal state based on incoming events from devices
|
||||
- Detect disparities between local and upstream behavior
|
||||
- Provide visibility into state changes and system health
|
||||
|
||||
## Architecture Principles
|
||||
|
||||
### 1. **Text-Based Storage for Debugging**
|
||||
- Maintain all state in human-readable text formats (XML, JSON, plain text)
|
||||
- Use small, focused files for each data aspect
|
||||
- Enable easy debugging and manual inspection
|
||||
- Optimize for small hardware deployments (Raspberry Pi Zero 2W)
|
||||
|
||||
### 2. **Mirror-First Strategy**
|
||||
- Keep mirror functionality active as long as possible
|
||||
- Primary source switches from upstream to local only during:
|
||||
- Explicit migration
|
||||
- Sufficient local data accumulation
|
||||
- Upstream service unavailability
|
||||
- Record and mirror as much data as possible, even if not immediately used
|
||||
|
||||
### 3. **Disparity Detection**
|
||||
- Track differences between local and upstream responses
|
||||
- Log discrepancies for analysis and improvement
|
||||
- Provide visibility into implementation gaps
|
||||
- Support parity testing and validation
|
||||
|
||||
### 4. **Event-Driven State Management**
|
||||
- Process device events asynchronously
|
||||
- Track comprehensive event history in text files
|
||||
- Support event replay and analysis
|
||||
- Minimize noise while capturing important state changes
|
||||
|
||||
## Enhanced Data Structure
|
||||
|
||||
### Account Management
|
||||
|
||||
```
|
||||
data/
|
||||
├── accounts/
|
||||
│ ├── {account-id}/
|
||||
│ │ ├── account.json # Account metadata
|
||||
│ ├── account-events.log # High-level account behavior tracking
|
||||
│ │ ├── devices/
|
||||
│ │ │ └── {device-id}/
|
||||
│ │ │ ├── lifecycle.json # Device state and history
|
||||
│ │ │ ├── info.xml # Device information
|
||||
│ │ │ ├── presets.xml # Device presets
|
||||
│ │ │ ├── recents.xml # Recent plays
|
||||
│ │ │ ├── sources.xml # Configured sources
|
||||
│ │ │ └── events.log # Device event history
|
||||
│ │ └── sessions/
|
||||
│ │ └── {session-id}/ # Recorded interaction sessions
|
||||
└── system/
|
||||
├── discovery.log # Device discovery events
|
||||
└── migration.log # Migration activities
|
||||
```
|
||||
|
||||
### Account Metadata Format
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "account-12345",
|
||||
"name": "User Account",
|
||||
"email": "user@example.com",
|
||||
"created_at": "2024-01-15T10:30:00Z",
|
||||
"updated_at": "2024-01-20T15:45:00Z",
|
||||
"status": "active",
|
||||
"device_count": 3,
|
||||
"migration_status": {
|
||||
"started_at": "2024-01-18T09:00:00Z",
|
||||
"devices_migrated": 1,
|
||||
"devices_pending": 2,
|
||||
"mirror_active": true
|
||||
},
|
||||
"bose_account_id": "bose-original-id",
|
||||
"data_sources": {
|
||||
"local": true,
|
||||
"bose_mirror": true,
|
||||
"primary": "bose"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Device Lifecycle Format
|
||||
|
||||
```json
|
||||
{
|
||||
"device_id": "A81B6A536A98",
|
||||
"account_id": "account-12345",
|
||||
"state": "active",
|
||||
"created_at": "2024-01-15T10:30:00Z",
|
||||
"updated_at": "2024-01-20T16:22:00Z",
|
||||
"state_history": [
|
||||
{
|
||||
"from": "unregistered",
|
||||
"to": "registering",
|
||||
"timestamp": "2024-01-15T10:30:00Z",
|
||||
"reason": "fresh_device_setup",
|
||||
"source": "discovery"
|
||||
},
|
||||
{
|
||||
"from": "registering",
|
||||
"to": "active",
|
||||
"timestamp": "2024-01-15T10:35:00Z",
|
||||
"reason": "registration_complete",
|
||||
"source": "system"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"name": "Living Room Speaker",
|
||||
"type": "SoundTouch 30",
|
||||
"serial_number": "I6332527703739342000020",
|
||||
"firmware_version": "4.8.1.25341.2677643.1597353330",
|
||||
"mac_address": "A8:1B:6A:53:6A:98",
|
||||
"ip_address": "192.168.1.100",
|
||||
"last_seen": "2024-01-20T16:20:00Z",
|
||||
"is_legacy_id": false
|
||||
},
|
||||
"data_sources": {
|
||||
"presets": "local",
|
||||
"recents": "mirror_primary",
|
||||
"sources": "local"
|
||||
},
|
||||
"migration": {
|
||||
"from_bose_account": "bose-account-xyz",
|
||||
"migrated_at": "2024-01-18T14:30:00Z",
|
||||
"method": "gradual",
|
||||
"rollback_available": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Event Log Format
|
||||
|
||||
```
|
||||
# Device Events Log - A81B6A536A98
|
||||
# Format: TIMESTAMP|EVENT_TYPE|SOURCE|DATA
|
||||
|
||||
2024-01-20T16:15:00Z|now_playing|websocket|{"source":"SPOTIFY","track":"Song Name","artist":"Artist Name"}
|
||||
2024-01-20T16:15:30Z|volume_changed|websocket|{"volume":45,"muted":false}
|
||||
2024-01-20T16:16:00Z|preset_selected|websocket|{"preset":1,"source":"SPOTIFY","location":"spotify:track:123"}
|
||||
2024-01-20T16:18:00Z|disparity_detected|mirror|{"endpoint":"/v1/account/full","local_hash":"abc123","upstream_hash":"def456"}
|
||||
2024-01-20T16:20:00Z|device_online|discovery|{"ip":"192.168.1.100","method":"mdns"}
|
||||
```
|
||||
|
||||
### Disparity Log Format
|
||||
|
||||
```
|
||||
# Parity Analysis Log
|
||||
# Format: TIMESTAMP|ENDPOINT|DEVICE|ACCOUNT|DISPARITY_TYPE|DETAILS
|
||||
|
||||
2024-01-20T16:18:00Z|/v1/account/full|A81B6A536A98|account-12345|content_mismatch|preset_count:local=5,upstream=4
|
||||
2024-01-20T16:19:15Z|/v1/presets|A81B6A536A98|account-12345|xml_structure|missing_container_art_in_local
|
||||
2024-01-20T16:20:30Z|/v1/recents|A81B6A536A98|account-12345|timestamp_format|local=RFC3339,upstream=custom
|
||||
```
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### Phase 1: Enhanced State Tracking
|
||||
|
||||
1. **Account Management Service**
|
||||
- Explicit account creation API
|
||||
- Mirror-enhanced account initialization
|
||||
- Account status and migration tracking
|
||||
|
||||
2. **Device Lifecycle Manager**
|
||||
- Comprehensive state machine for device lifecycle
|
||||
- Event-driven state transitions
|
||||
- Text-based state persistence
|
||||
|
||||
3. **Enhanced Mirror System**
|
||||
- Extended mirroring with disparity detection
|
||||
- Selective data source switching
|
||||
- Parity analysis and logging
|
||||
|
||||
### Phase 2: Gradual Migration Support
|
||||
|
||||
1. **Migration Controller**
|
||||
- Device-by-device migration orchestration
|
||||
- Rollback capability with state preservation
|
||||
- Migration progress tracking
|
||||
|
||||
2. **Dual-Source Data Management**
|
||||
- Smart routing between local and upstream data
|
||||
- Graceful fallback mechanisms
|
||||
- Data source preference management
|
||||
|
||||
3. **State Synchronization**
|
||||
- Bidirectional sync capabilities
|
||||
- Conflict resolution strategies
|
||||
- Sync status monitoring
|
||||
|
||||
### Phase 3: Advanced Analytics
|
||||
|
||||
1. **Disparity Analysis Engine**
|
||||
- Automated disparity detection and classification
|
||||
- Trend analysis and reporting
|
||||
- Implementation gap identification
|
||||
|
||||
2. **System Health Monitoring**
|
||||
- Device connectivity monitoring
|
||||
- Service availability tracking
|
||||
- Performance metrics collection
|
||||
|
||||
3. **Data Export and Backup**
|
||||
- Account data export for migration
|
||||
- Incremental backup strategies
|
||||
- Data integrity verification
|
||||
|
||||
## API Enhancements
|
||||
|
||||
### Account Management APIs
|
||||
|
||||
```http
|
||||
# Create account explicitly
|
||||
POST /api/v1/accounts
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"name": "User Account",
|
||||
"email": "user@example.com"
|
||||
}
|
||||
|
||||
# Get account with migration status
|
||||
GET /api/v1/accounts/{account-id}
|
||||
|
||||
# Initiate account migration from Bose
|
||||
POST /api/v1/accounts/{account-id}/migrate
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"bose_account_id": "bose-original-id",
|
||||
"strategy": "gradual"
|
||||
}
|
||||
```
|
||||
|
||||
### Device Lifecycle APIs
|
||||
|
||||
```http
|
||||
# Register fresh device
|
||||
POST /api/v1/accounts/{account-id}/devices
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"device_id": "A81B6A536A98",
|
||||
"name": "Living Room Speaker",
|
||||
"registration_type": "fresh"
|
||||
}
|
||||
|
||||
# Get device state and lifecycle
|
||||
GET /api/v1/accounts/{account-id}/devices/{device-id}/state
|
||||
|
||||
# Migrate device from Bose account
|
||||
POST /api/v1/accounts/{account-id}/devices/{device-id}/migrate
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"from_bose_account": "bose-account-xyz",
|
||||
"preserve_data": true
|
||||
}
|
||||
```
|
||||
|
||||
### Monitoring and Analysis APIs
|
||||
|
||||
```http
|
||||
# Get disparity analysis
|
||||
GET /api/v1/system/disparities?since=2024-01-20T00:00:00Z
|
||||
|
||||
# Get migration status
|
||||
GET /api/v1/system/migration/status
|
||||
|
||||
# Export account data
|
||||
GET /api/v1/accounts/{account-id}/export
|
||||
```
|
||||
|
||||
## Integration with Existing Services
|
||||
|
||||
### Enhanced Marge Service
|
||||
|
||||
- Integrate lifecycle information into account responses
|
||||
- Add migration status to device listings
|
||||
- Support dual-source data routing
|
||||
- Include disparity metadata in responses
|
||||
|
||||
### Enhanced BMX Service
|
||||
|
||||
- Track content source preferences by account
|
||||
- Mirror and compare content recommendations
|
||||
- Log streaming behavior for analysis
|
||||
- Support gradual source migration
|
||||
|
||||
### Discovery Service Integration
|
||||
|
||||
- Link discovered devices to lifecycle manager
|
||||
- Trigger lifecycle state transitions on discovery events
|
||||
- Support both fresh registration and migration flows
|
||||
- Handle legacy device ID migration automatically
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
### Simplicity First (KISS Principle)
|
||||
|
||||
- Favor simple, readable code over premature optimization
|
||||
- Use straightforward algorithms and data structures
|
||||
- Minimize complexity in favor of maintainability
|
||||
- Build incrementally with small, testable changes
|
||||
|
||||
### Quality Assurance
|
||||
|
||||
- Complete test coverage for all new functionality
|
||||
- Comprehensive linting with `golangci-lint run --fix`
|
||||
- Full test suite execution `go test ./...` for each milestone
|
||||
- Integration tests with existing functionality
|
||||
|
||||
### File Management
|
||||
|
||||
- Simple line-based append operations for logs
|
||||
- Basic log rotation when needed
|
||||
- Direct file operations without complex caching
|
||||
- Straightforward data persistence
|
||||
|
||||
## Development Principles
|
||||
|
||||
### KISS (Keep It Simple, Stupid)
|
||||
- Prioritize simplicity and readability over performance optimization
|
||||
- Use standard Go idioms and patterns
|
||||
- Avoid premature abstraction and optimization
|
||||
- Build the simplest thing that works first
|
||||
|
||||
### Quality First
|
||||
- Every milestone must pass `golangci-lint run --fix` without issues
|
||||
- Complete test suite must pass `go test ./...` before proceeding
|
||||
- Integration tests ensure existing functionality remains intact
|
||||
- Code coverage should be maintained or improved
|
||||
|
||||
### Incremental Development
|
||||
- Make small, focused changes that can be easily reviewed
|
||||
- Each step should be independently testable and valuable
|
||||
- Maintain backward compatibility throughout development
|
||||
- Enable rollback at any point in the process
|
||||
|
||||
### Leverage Existing Systems
|
||||
- Reuse existing interaction recording for request/response tracking
|
||||
- Build upon current parity mismatch detection system
|
||||
- Extend existing datastore and handler patterns
|
||||
- Integrate with established discovery and migration workflows
|
||||
|
||||
## Future Enhancements
|
||||
|
||||
Future improvements should maintain the simplicity-first approach:
|
||||
|
||||
1. **Enhanced Web Interface**
|
||||
- Simple dashboard for account and device management
|
||||
- Basic migration progress tracking
|
||||
- Straightforward device health monitoring
|
||||
|
||||
2. **Extended Logging**
|
||||
- Additional high-level behavior tracking
|
||||
- Simple analytics based on existing parity data
|
||||
- Enhanced debugging information
|
||||
|
||||
3. **Community Integration**
|
||||
- Standardized data export formats
|
||||
- Simple reporting mechanisms
|
||||
- Clear documentation for community contributions
|
||||
|
||||
This concept provides a solid, maintainable foundation for replacing Bose's upstream services. The emphasis on simplicity, existing system reuse, and comprehensive testing ensures reliable functionality while maintaining the debugging capabilities needed for small hardware deployments.
|
||||
@@ -0,0 +1,391 @@
|
||||
# Device Lifecycle and /power_on Enhancement
|
||||
|
||||
## Overview
|
||||
|
||||
This document provides a comprehensive analysis of the current SoundTouch device registration and lifecycle management implementation, and proposes enhancements using the `/power_on` endpoint to reduce dependency on local network connectivity.
|
||||
|
||||
## Current Implementation Assessment
|
||||
|
||||
### Device Information Sources
|
||||
|
||||
The current system uses multiple data collection methods to build a complete device profile:
|
||||
|
||||
#### 1. UPnP/SSDP Discovery
|
||||
- **Protocol**: Multicast UDP discovery for `urn:schemas-upnp-org:service:SoundTouch:1`
|
||||
- **Network Scope**: Limited to same network segment
|
||||
- **Data Collected**:
|
||||
```go
|
||||
type DiscoveredDevice struct {
|
||||
Name string // From UPnP friendlyName
|
||||
Host string // IP address
|
||||
Port int // Usually 8090
|
||||
ModelID string // From UPnP modelName
|
||||
SerialNo string // MAC address from UPnP
|
||||
UPnPLocation string // Device description URL
|
||||
UPnPUSN string // Unique service name
|
||||
}
|
||||
```
|
||||
|
||||
#### 2. mDNS/Bonjour Discovery
|
||||
- **Protocol**: Multicast DNS for `_soundtouch._tcp` services
|
||||
- **Network Scope**: Limited to same network segment
|
||||
- **Purpose**: Complements UPnP discovery with hostname resolution
|
||||
|
||||
#### 3. `/info` Endpoint Enrichment
|
||||
- **Protocol**: HTTP GET to `http://device:8090/info`
|
||||
- **Network Scope**: Requires direct connectivity to device
|
||||
- **Data Collected**:
|
||||
```xml
|
||||
<info deviceID="ABCD1234EFGH">
|
||||
<name>My SoundTouch Device</name>
|
||||
<type>SoundTouch 10</type>
|
||||
<margeAccountUUID>3230304</margeAccountUUID>
|
||||
<components>
|
||||
<component>
|
||||
<componentCategory>SCM</componentCategory>
|
||||
<softwareVersion>27.0.6.46330.5043500...</softwareVersion>
|
||||
<serialNumber>I6332527703739342000020</serialNumber>
|
||||
</component>
|
||||
</components>
|
||||
<margeURL>https://streaming.bose.com</margeURL>
|
||||
<networkInfo type="SCM">
|
||||
<macAddress>AA:BB:CC:DD:EE:FF</macAddress>
|
||||
<ipAddress>192.168.1.10</ipAddress>
|
||||
</networkInfo>
|
||||
<moduleType>sm2</moduleType>
|
||||
<variant>rhino</variant>
|
||||
<countryCode>GB</countryCode>
|
||||
</info>
|
||||
```
|
||||
|
||||
### Current Data Flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Service as SoundTouch Service
|
||||
participant UPnP as UPnP Discovery
|
||||
participant mDNS as mDNS Discovery
|
||||
participant Device as SoundTouch Device
|
||||
participant DataStore as Data Store
|
||||
participant User as User/App
|
||||
|
||||
Note over Service,User: Current Device Registration Flow
|
||||
|
||||
Service->>UPnP: Start SSDP Discovery
|
||||
Service->>mDNS: Start mDNS Discovery
|
||||
|
||||
UPnP->>UPnP: Send M-SEARCH multicast
|
||||
Device->>UPnP: Respond with location URL
|
||||
UPnP->>Device: Fetch device description XML
|
||||
Device->>UPnP: Return basic device info
|
||||
|
||||
mDNS->>mDNS: Query _soundtouch._tcp
|
||||
Device->>mDNS: Respond with service info
|
||||
|
||||
Service->>Service: Merge discovery results
|
||||
Service->>Device: GET /info (enrich data)
|
||||
Device->>Service: Return detailed device info
|
||||
Service->>DataStore: Store discovered device
|
||||
|
||||
Note over User,DataStore: User Registration
|
||||
User->>Service: POST /account/{id}/devices
|
||||
Note right of User: deviceId + user-friendly name
|
||||
Service->>DataStore: Link device to account
|
||||
|
||||
Note over Service,DataStore: Migration Process
|
||||
Service->>Device: GET /info (device identification)
|
||||
Device->>Service: Return device details
|
||||
Service->>Service: Build migration summary
|
||||
Service->>Device: Apply configuration changes
|
||||
```
|
||||
|
||||
### Device Registration Points
|
||||
|
||||
The system has distinct phases where device information is collected and enhanced:
|
||||
|
||||
#### Phase 1: Discovery (Network-Dependent)
|
||||
**Trigger**: Automatic network scanning
|
||||
**Data Sources**: UPnP + mDNS + `/info` endpoint
|
||||
**Limitations**: ❌ Requires same network segment
|
||||
|
||||
#### Phase 2: User Registration (User-Controlled)
|
||||
**Trigger**: User adds device to account
|
||||
**Endpoint**: `POST /streaming/account/{accountId}/devices`
|
||||
**Request Format**:
|
||||
```xml
|
||||
<device deviceid="08DF1F0BA325">
|
||||
<name>Living Room Speaker</name>
|
||||
</device>
|
||||
```
|
||||
**Data Added**: ✅ User-friendly name, Account association
|
||||
|
||||
#### Phase 3: Ongoing Updates (Mixed)
|
||||
**Triggers**: Device state changes, firmware updates, network changes
|
||||
**Methods**: Periodic `/info` polling, Discovery refresh, User configuration
|
||||
|
||||
### Current Data Model
|
||||
|
||||
The system maintains comprehensive device information:
|
||||
|
||||
```go
|
||||
type ServiceDeviceInfo struct {
|
||||
DeviceID string `json:"device_id"` // MAC or UUID
|
||||
Name string `json:"name"` // User-friendly name
|
||||
ProductCode string `json:"product_code"` // Device model
|
||||
DeviceSerialNumber string `json:"device_serial_number"` // Hardware serial
|
||||
ProductSerialNumber string `json:"product_serial_number"` // Product serial
|
||||
FirmwareVersion string `json:"firmware_version"` // Software version
|
||||
IPAddress string `json:"ip_address"` // Current IP
|
||||
MacAddress string `json:"mac_address"` // MAC address
|
||||
AccountID string `json:"account_id"` // Account association
|
||||
DiscoveryMethod string `json:"discovery_method"` // How discovered
|
||||
}
|
||||
```
|
||||
|
||||
## Limitations of Current Approach
|
||||
|
||||
### Network Dependency Issues
|
||||
|
||||
| Issue | Impact | Affected Operations |
|
||||
|-------|--------|-------------------|
|
||||
| **Same Network Requirement** | High | Device discovery, Initial setup |
|
||||
| **Direct Connectivity Need** | High | Device enrichment, Migration |
|
||||
| **Firewall/NAT Restrictions** | Medium | Corporate networks, Complex setups |
|
||||
| **Multi-VLAN Environments** | High | Enterprise deployments |
|
||||
| **Remote Management** | Critical | Off-site device support |
|
||||
|
||||
### Service Architecture Limitations
|
||||
|
||||
1. **Geographic Constraints**: Service must be deployed on same network as speakers
|
||||
2. **Scalability Issues**: Cannot centralize device management across multiple locations
|
||||
3. **Discovery Reliability**: Multicast protocols can be unreliable in complex networks
|
||||
4. **Real-time Updates**: No device-initiated communication for state changes
|
||||
|
||||
## /power_on Enhancement Proposal
|
||||
|
||||
### Current /power_on Request Analysis
|
||||
|
||||
The `/power_on` endpoint receives comprehensive device data that could replace many network-dependent operations:
|
||||
|
||||
```xml
|
||||
<device-data>
|
||||
<device id="A81B6A536A98">
|
||||
<serialnumber>I6332527703739342000020</serialnumber>
|
||||
<firmware-version>27.0.6.46330.5043500 epdbuild.trunk.hepdswbld04.2022-08-04T11:20:29</firmware-version>
|
||||
<product product_code="SoundTouch 10 sm2" type="5">
|
||||
<serialnumber>069231P63364828AE</serialnumber>
|
||||
</product>
|
||||
</device>
|
||||
<diagnostic-data>
|
||||
<device-landscape>
|
||||
<rssi>Excellent</rssi>
|
||||
<gateway-ip-address>192.168.178.1</gateway-ip-address>
|
||||
<macaddresses>
|
||||
<macaddress>A81B6A536A98</macaddress>
|
||||
<macaddress>A81B6A849D99</macaddress>
|
||||
</macaddresses>
|
||||
<ip-address>192.168.178.35</ip-address>
|
||||
<network-connection-type>Wireless</network-connection-type>
|
||||
</device-landscape>
|
||||
<network-landscape>
|
||||
<network-data xmlns="http://www.Bose.com/Schemas/2012-12/NetworkMonitor/"/>
|
||||
</network-landscape>
|
||||
</diagnostic-data>
|
||||
</device-data>
|
||||
```
|
||||
|
||||
### Data Completeness Comparison
|
||||
|
||||
| Data Field | Current `/info` | `/power_on` | Gap Assessment |
|
||||
|------------|----------------|-------------|----------------|
|
||||
| **Device ID** | ✅ UUID format | ✅ MAC format | Different format |
|
||||
| **Device Name** | ✅ Internal name | ❌ Missing | **Critical Gap** |
|
||||
| **Device Type** | ✅ Model string | ✅ Product code | ✅ Available |
|
||||
| **Account ID** | ✅ marge UUID | ❌ Missing | **Critical Gap** |
|
||||
| **Service URL** | ✅ marge URL | ❌ Missing | **Important Gap** |
|
||||
| **Firmware Version** | ✅ Full version | ✅ Full version | ✅ Available |
|
||||
| **Serial Numbers** | ✅ Component serials | ✅ Device + Product | ✅ Available |
|
||||
| **MAC Addresses** | ✅ Interface-specific | ✅ Multiple MACs | ✅ Enhanced |
|
||||
| **IP Address** | ✅ Interface IPs | ✅ Current IP | ✅ Available |
|
||||
| **Network Status** | ❌ Basic | ✅ Rich diagnostics | ✅ **Enhanced** |
|
||||
| **Regional Settings** | ✅ Country/Region | ❌ Missing | **Important Gap** |
|
||||
|
||||
### Enhancement Benefits
|
||||
|
||||
#### 1. Network Independence
|
||||
- ✅ Works across internet/WAN connections
|
||||
- ✅ No multicast/broadcast requirements
|
||||
- ✅ Firewall/NAT friendly
|
||||
- ✅ Supports remote device management
|
||||
|
||||
#### 2. Real-time Device State
|
||||
- ✅ Device-initiated communication
|
||||
- ✅ Power-on event notifications
|
||||
- ✅ Network status updates
|
||||
- ✅ Firmware change detection
|
||||
|
||||
#### 3. Enhanced Diagnostics
|
||||
- ✅ Signal strength (RSSI)
|
||||
- ✅ Gateway information
|
||||
- ✅ Connection type details
|
||||
- ✅ Real-time network status
|
||||
|
||||
### Implementation Strategy
|
||||
|
||||
#### Phase 1: Hybrid Approach
|
||||
Implement `/power_on` processing while maintaining existing discovery methods:
|
||||
|
||||
```go
|
||||
func (s *Server) HandleMargePowerOn(w http.ResponseWriter, r *http.Request) {
|
||||
// Parse power_on request
|
||||
var powerOnData models.CustomerSupportRequest
|
||||
if err := xml.Unmarshal(body, &powerOnData); err != nil {
|
||||
// Fallback to existing discovery
|
||||
return s.fallbackToDiscovery(r.RemoteAddr)
|
||||
}
|
||||
|
||||
// Extract device information
|
||||
deviceMAC := powerOnData.Device.ID
|
||||
deviceIP := powerOnData.DiagnosticData.DeviceLandscape.IPAddress
|
||||
|
||||
// Lookup existing device data
|
||||
deviceInfo := s.lookupDeviceByMAC(deviceMAC)
|
||||
if deviceInfo == nil {
|
||||
// New device - trigger registration flow
|
||||
deviceInfo = s.createDeviceFromPowerOn(powerOnData)
|
||||
}
|
||||
|
||||
// Update with power_on data
|
||||
s.updateDeviceFromPowerOn(deviceInfo, powerOnData)
|
||||
|
||||
// Determine response actions
|
||||
response := s.buildPowerOnResponse(deviceInfo)
|
||||
s.sendResponse(w, response)
|
||||
}
|
||||
```
|
||||
|
||||
#### Phase 2: Gap Resolution
|
||||
Address missing data through complementary mechanisms:
|
||||
|
||||
1. **User-Friendly Names**: Maintain registration process for name assignment
|
||||
2. **Account Association**: Enhance registration to link MAC addresses to accounts
|
||||
3. **Service URLs**: Implement account-based service URL resolution
|
||||
4. **Regional Settings**: Use IP geolocation or account preferences
|
||||
|
||||
#### Phase 3: Enhanced Device Lifecycle
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Device as SoundTouch Device
|
||||
participant Service as SoundTouch Service
|
||||
participant DataStore as Data Store
|
||||
participant User as User/App
|
||||
|
||||
Note over Device,User: Enhanced Device Lifecycle
|
||||
|
||||
rect rgb(248, 255, 248)
|
||||
Note over Device,DataStore: 1. Power-On Registration
|
||||
Device->>Service: POST /power_on (rich device data)
|
||||
Service->>DataStore: Lookup device by MAC
|
||||
alt Device Unknown
|
||||
Service->>DataStore: Create device record
|
||||
Service->>User: Notify new device found
|
||||
else Device Known
|
||||
Service->>DataStore: Update device status
|
||||
end
|
||||
Service->>Device: Configuration response
|
||||
end
|
||||
|
||||
rect rgb(255, 248, 240)
|
||||
Note over User,DataStore: 2. User Registration (Optional)
|
||||
User->>Service: POST /setup/devices (name + preferences)
|
||||
Service->>DataStore: Add user metadata to device
|
||||
Service->>Device: Updated configuration (on next power_on)
|
||||
end
|
||||
|
||||
rect rgb(240, 248, 255)
|
||||
Note over Device,DataStore: 3. Ongoing Updates
|
||||
Device->>Service: POST /power_on (status changes)
|
||||
Service->>Service: Detect firmware/network changes
|
||||
Service->>DataStore: Update device record
|
||||
alt Migration Needed
|
||||
Service->>Device: Migration instructions
|
||||
Device->>Device: Apply configuration
|
||||
Device->>Service: POST /power_on (confirm changes)
|
||||
end
|
||||
end
|
||||
|
||||
rect rgb(255, 248, 255)
|
||||
Note over Service,User: 4. Remote Management
|
||||
User->>Service: Management request (any location)
|
||||
Service->>DataStore: Lookup device status
|
||||
Service->>User: Current device state
|
||||
Note over Service: No local network required
|
||||
end
|
||||
```
|
||||
|
||||
### Migration Strategy
|
||||
|
||||
#### Current Migration Flow Issues
|
||||
- Requires `/info` endpoint access for device identification
|
||||
- Must be on same network for configuration changes
|
||||
- Limited to devices discoverable via UPnP/mDNS
|
||||
|
||||
#### Enhanced Migration with /power_on
|
||||
|
||||
1. **Device Identification**: Use MAC address from `/power_on` instead of IP-based `/info`
|
||||
2. **Configuration Delivery**: Send migration instructions in `/power_on` response
|
||||
3. **Status Confirmation**: Device confirms changes via subsequent `/power_on` requests
|
||||
4. **Remote Capability**: Manage devices from any network location
|
||||
|
||||
```go
|
||||
type PowerOnResponse struct {
|
||||
ConfigurationUpdates []ConfigUpdate `json:"configuration_updates,omitempty"`
|
||||
MigrationInstructions *Migration `json:"migration,omitempty"`
|
||||
RegistrationRequired bool `json:"registration_required,omitempty"`
|
||||
}
|
||||
|
||||
type Migration struct {
|
||||
Method string `json:"method"` // xml, hosts, resolv_conf
|
||||
TargetURL string `json:"target_url"`
|
||||
ProxyURL string `json:"proxy_url,omitempty"`
|
||||
Options map[string]string `json:"options"`
|
||||
}
|
||||
```
|
||||
|
||||
## Recommendations
|
||||
|
||||
### Immediate Actions (Phase 1)
|
||||
1. **Enhance `/power_on` handler** to extract and store comprehensive device data
|
||||
2. **Implement device lookup by MAC address** as primary identification method
|
||||
3. **Create hybrid discovery system** using both `/power_on` and existing methods
|
||||
4. **Add network-independent device management** capabilities
|
||||
|
||||
### Medium-term Improvements (Phase 2)
|
||||
1. **Implement account-device MAC mapping** for automatic association
|
||||
2. **Add IP geolocation** for regional settings inference
|
||||
3. **Create device registration UI** optimized for `/power_on` discovered devices
|
||||
4. **Enhance migration system** to use `/power_on` response mechanism
|
||||
|
||||
### Long-term Enhancements (Phase 3)
|
||||
1. **Request firmware enhancement** to include missing data in `/power_on`
|
||||
2. **Implement real-time device monitoring** via `/power_on` events
|
||||
3. **Create centralized device management** independent of network topology
|
||||
4. **Add predictive migration** based on device status patterns
|
||||
|
||||
### Risk Mitigation
|
||||
- **Maintain backward compatibility** with existing discovery methods
|
||||
- **Implement graceful fallbacks** when `/power_on` data is incomplete
|
||||
- **Preserve existing user workflows** while adding enhanced capabilities
|
||||
- **Add comprehensive logging** for troubleshooting hybrid approach
|
||||
|
||||
## Conclusion
|
||||
|
||||
The `/power_on` endpoint provides a significant opportunity to reduce network dependencies while enhancing device management capabilities. By implementing a hybrid approach that leverages `/power_on` data for primary device identification and status updates while maintaining existing registration workflows for user-controlled metadata, the system can achieve:
|
||||
|
||||
- **Network independence** for core device management
|
||||
- **Enhanced real-time capabilities** through device-initiated communication
|
||||
- **Improved scalability** across diverse network topologies
|
||||
- **Better user experience** with automatic device discovery and status updates
|
||||
|
||||
The proposed implementation strategy provides a clear path to achieve these benefits while maintaining system reliability and user workflow compatibility.
|
||||
@@ -0,0 +1,150 @@
|
||||
# Device Lifecycle Analysis - Executive Summary
|
||||
|
||||
## Current State Assessment
|
||||
|
||||
The SoundTouch service currently relies heavily on local network connectivity for device discovery and management:
|
||||
|
||||
### ✅ Strengths
|
||||
- **Comprehensive device data** through `/info` endpoint
|
||||
- **Robust discovery** via UPnP/SSDP + mDNS
|
||||
- **User-controlled registration** with friendly names
|
||||
- **Complete device lifecycle management**
|
||||
|
||||
### ❌ Limitations
|
||||
- **Network dependency**: Requires same network segment for discovery
|
||||
- **Geographic constraints**: Service must be co-located with devices
|
||||
- **Firewall/NAT issues**: Multicast protocols unreliable in complex networks
|
||||
- **No remote management**: Cannot manage devices from external networks
|
||||
|
||||
## /power_on Enhancement Opportunity
|
||||
|
||||
The `/power_on` endpoint provides rich device data that could eliminate network dependencies:
|
||||
|
||||
### Current /power_on Data
|
||||
```xml
|
||||
<device-data>
|
||||
<device id="A81B6A536A98"> <!-- ✅ Device MAC -->
|
||||
<serialnumber>I6332527703739342000020</serialnumber> <!-- ✅ Serial -->
|
||||
<firmware-version>27.0.6.46330.5043500...</firmware-version> <!-- ✅ FW -->
|
||||
<product product_code="SoundTouch 10 sm2" type="5"> <!-- ✅ Model -->
|
||||
<serialnumber>069231P63364828AE</serialnumber> <!-- ✅ Product Serial -->
|
||||
</product>
|
||||
</device>
|
||||
<diagnostic-data>
|
||||
<device-landscape>
|
||||
<rssi>Excellent</rssi> <!-- ✅ Signal -->
|
||||
<gateway-ip-address>192.168.178.1</gateway-ip-address> <!-- ✅ Network -->
|
||||
<macaddresses> <!-- ✅ All MACs -->
|
||||
<macaddress>A81B6A536A98</macaddress>
|
||||
<macaddress>A81B6A849D99</macaddress>
|
||||
</macaddresses>
|
||||
<ip-address>192.168.178.35</ip-address> <!-- ✅ Current IP -->
|
||||
<network-connection-type>Wireless</network-connection-type> <!-- ✅ Connection -->
|
||||
</device-landscape>
|
||||
</diagnostic-data>
|
||||
</device-data>
|
||||
```
|
||||
|
||||
### Missing Data Gaps
|
||||
| Data | Current Source | Available in /power_on | Impact |
|
||||
|------|----------------|----------------------|---------|
|
||||
| **User-friendly name** | Registration | ❌ Missing | **High** - UI/UX |
|
||||
| **Account association** | Registration | ❌ Missing | **Critical** - Authorization |
|
||||
| **Service URLs** | `/info` | ❌ Missing | **High** - Migration |
|
||||
| **Regional settings** | `/info` | ❌ Missing | **Medium** - Localization |
|
||||
|
||||
## Recommended Implementation Strategy
|
||||
|
||||
### Phase 1: Hybrid Enhancement (Immediate)
|
||||
- **Enhance `/power_on` handler** to process full device data
|
||||
- **Implement MAC-based device lookup** for identification
|
||||
- **Maintain existing registration flow** for user metadata
|
||||
- **Add network-independent capabilities** as primary features
|
||||
|
||||
```go
|
||||
// Enhanced flow
|
||||
Device -> POST /power_on -> Service identifies by MAC -> Update/Create device record
|
||||
```
|
||||
|
||||
### Phase 2: Gap Resolution (Short-term)
|
||||
- **Account-device MAC mapping** for automatic association
|
||||
- **IP geolocation** for regional settings inference
|
||||
- **Registration UI optimization** for /power_on discovered devices
|
||||
- **Migration via response payload** instead of direct device access
|
||||
|
||||
### Phase 3: Full Network Independence (Medium-term)
|
||||
- **Centralized device management** across multiple networks
|
||||
- **Real-time device monitoring** via /power_on events
|
||||
- **Predictive migration** based on device status patterns
|
||||
- **Enhanced firmware integration** with additional /power_on data
|
||||
|
||||
## Key Benefits
|
||||
|
||||
### ✅ Immediate Gains
|
||||
- **Network independence**: Manage devices from any location
|
||||
- **Real-time updates**: Device-initiated status reporting
|
||||
- **Enhanced diagnostics**: Signal strength, connection type, network status
|
||||
- **Simplified deployment**: No multicast/broadcast requirements
|
||||
|
||||
### ✅ Long-term Advantages
|
||||
- **Scalable architecture**: Centralized management across sites
|
||||
- **Improved reliability**: Eliminates discovery protocol dependencies
|
||||
- **Better user experience**: Automatic device detection and status
|
||||
- **Future-proof design**: Device-driven communication model
|
||||
|
||||
## Implementation Approach
|
||||
|
||||
### Hybrid Strategy
|
||||
```mermaid
|
||||
graph TD
|
||||
PowerOn[Device /power_on] --> Identify[MAC-based Identification]
|
||||
Identify --> New{New Device?}
|
||||
|
||||
New -->|Yes| Create[Create Device Record]
|
||||
New -->|No| Update[Update Existing Record]
|
||||
|
||||
Create --> CheckAccount{Account Known?}
|
||||
CheckAccount -->|No| RegisterFlow[Trigger Registration]
|
||||
CheckAccount -->|Yes| LinkAccount[Link to Account]
|
||||
|
||||
Update --> DetectChanges[Detect Changes]
|
||||
DetectChanges --> Migration{Migration Needed?}
|
||||
Migration -->|Yes| SendInstructions[Send Migration Instructions]
|
||||
|
||||
LinkAccount --> Response[Send Configuration Response]
|
||||
SendInstructions --> Response
|
||||
RegisterFlow --> Response
|
||||
```
|
||||
|
||||
### Risk Mitigation
|
||||
- **Maintain backward compatibility** with existing discovery
|
||||
- **Graceful fallbacks** when /power_on data incomplete
|
||||
- **Preserve user workflows** while adding enhanced capabilities
|
||||
- **Comprehensive logging** for troubleshooting
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Technical Metrics
|
||||
- **Network independence**: % of operations not requiring local network
|
||||
- **Real-time capability**: Power-on event processing latency < 2s
|
||||
- **Data completeness**: % of devices with full metadata via /power_on
|
||||
- **Migration success**: % of successful remote migrations
|
||||
|
||||
### User Experience Metrics
|
||||
- **Discovery reliability**: % of devices automatically detected
|
||||
- **Setup time**: Time from device power-on to full management
|
||||
- **Management accessibility**: % of operations available remotely
|
||||
- **Error reduction**: Decrease in network-related issues
|
||||
|
||||
## Conclusion
|
||||
|
||||
The `/power_on` enhancement represents a strategic opportunity to:
|
||||
|
||||
1. **Eliminate network dependencies** while maintaining full functionality
|
||||
2. **Enable remote device management** across diverse network topologies
|
||||
3. **Improve user experience** through automatic device detection
|
||||
4. **Future-proof the architecture** for scalable device management
|
||||
|
||||
**Recommendation**: Proceed with hybrid implementation approach, prioritizing network independence while preserving existing user workflows and system reliability.
|
||||
|
||||
**Timeline**: Phase 1 implementation feasible within 2-3 sprints, with Phases 2-3 extending capabilities based on user feedback and firmware enhancement opportunities.
|
||||
@@ -0,0 +1,222 @@
|
||||
# Migration Flow Diagrams
|
||||
|
||||
This document specifies the diagrams needed for the migration guide, with descriptions that can be used to create actual visual diagrams.
|
||||
|
||||
## 1. Overall Migration Process Flow
|
||||
|
||||
### Description
|
||||
A flowchart showing the complete migration journey from start to finish.
|
||||
|
||||
### Elements
|
||||
```
|
||||
[Start] → [Install SoundTouch Service] → [Create Account] → [Prepare Devices]
|
||||
↓
|
||||
[Enable Remote Services] → [Discover Devices] → [Register Devices]
|
||||
↓
|
||||
[Start Migration] → [Data Collection Phase] → [Testing Phase] → [Full Local Phase]
|
||||
↓
|
||||
[Verify Migration] → [Complete] → [Post-Migration Setup]
|
||||
```
|
||||
|
||||
### Decision Points
|
||||
- Multiple devices? → Repeat device steps
|
||||
- Migration issues? → Rollback option
|
||||
- All devices complete? → Account fully migrated
|
||||
|
||||
### Color Coding
|
||||
- **Blue**: Service setup steps
|
||||
- **Green**: Successful completion states
|
||||
- **Orange**: In-progress/testing states
|
||||
- **Red**: Error handling/rollback paths
|
||||
- **Gray**: Optional steps
|
||||
|
||||
## 2. Network Topology Diagram
|
||||
|
||||
### Description
|
||||
Shows the network layout with Raspberry Pi, router, and SoundTouch devices.
|
||||
|
||||
### Components
|
||||
```
|
||||
Internet Cloud
|
||||
↑↓ (Optional - during migration)
|
||||
Home Router (192.168.1.1)
|
||||
├── Raspberry Pi (192.168.1.10) [SoundTouch Service]
|
||||
├── Living Room Speaker (192.168.1.100)
|
||||
├── Kitchen Speaker (192.168.1.101)
|
||||
├── Bedroom Speaker (192.168.1.102)
|
||||
└── Office Speaker (192.168.1.103)
|
||||
```
|
||||
|
||||
### Connections
|
||||
- **Solid lines**: Active connections
|
||||
- **Dashed lines**: Migration-phase connections to Bose cloud
|
||||
- **Thick lines**: Primary data flow to local service
|
||||
|
||||
## 3. Device State Lifecycle
|
||||
|
||||
### Description
|
||||
State machine showing device progression through migration phases.
|
||||
|
||||
### States and Transitions
|
||||
```
|
||||
[Unregistered] → [Discovered] → [Registered] → [Migrating]
|
||||
↓
|
||||
[Active - Local Only] ← [Active - Testing] ← [Active - Data Collection]
|
||||
↑ ↓
|
||||
[Error/Rollback] ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← [Migration Failed]
|
||||
```
|
||||
|
||||
### State Descriptions
|
||||
- **Unregistered**: Device not known to service
|
||||
- **Discovered**: Found on network, remote services enabled
|
||||
- **Registered**: Added to account, ready for migration
|
||||
- **Migrating - Data Collection**: Building local database
|
||||
- **Migrating - Testing**: Using local service with fallback
|
||||
- **Active - Local Only**: Full independence achieved
|
||||
- **Error/Rollback**: Issues detected, can revert to Bose
|
||||
|
||||
## 4. Data Flow During Migration
|
||||
|
||||
### Description
|
||||
Shows how data flows between components during different migration phases.
|
||||
|
||||
### Phase 1 - Data Collection
|
||||
```
|
||||
SoundTouch Device → Bose Cloud Services
|
||||
↓ (mirror)
|
||||
Local Service (collecting data)
|
||||
```
|
||||
|
||||
### Phase 2 - Testing
|
||||
```
|
||||
SoundTouch Device ↔ Local Service (primary)
|
||||
↕ (fallback when needed)
|
||||
Bose Cloud Services
|
||||
```
|
||||
|
||||
### Phase 3 - Full Local
|
||||
```
|
||||
SoundTouch Device ↔ Local Service (only)
|
||||
|
||||
Bose Cloud Services (disconnected)
|
||||
```
|
||||
|
||||
### Data Types
|
||||
- **Presets**: Station favorites and custom sources
|
||||
- **Recents**: Play history and recently accessed content
|
||||
- **Sources**: Configured music services (Spotify, etc.)
|
||||
- **Device Config**: Network settings, capabilities, metadata
|
||||
|
||||
## 5. Migration Timeline Visualization
|
||||
|
||||
### Description
|
||||
Gantt-chart style timeline showing typical migration schedule.
|
||||
|
||||
### Timeline (7-day example)
|
||||
```
|
||||
Day 1-2: Data Collection Phase
|
||||
████████████████████████████████████████
|
||||
|
||||
Day 3-4: Data Validation
|
||||
████████████████████████████
|
||||
|
||||
Day 5-6: Testing Phase
|
||||
████████████████████████
|
||||
|
||||
Day 7+: Full Local Operation
|
||||
████████████████████████→
|
||||
```
|
||||
|
||||
### Parallel Activities
|
||||
- Multiple devices can be in different phases
|
||||
- Service continues operating throughout
|
||||
- User can interact normally during process
|
||||
|
||||
## 6. Service Architecture Overview
|
||||
|
||||
### Description
|
||||
High-level architecture showing enhanced SoundTouch service components.
|
||||
|
||||
### Components
|
||||
```
|
||||
Web Dashboard ← → HTTP API ← → REST Endpoints
|
||||
↑ ↑ ↑
|
||||
└─── User ──────┼──── Devices ─┘
|
||||
↓
|
||||
Service Core
|
||||
├── Account Manager
|
||||
├── Device Lifecycle
|
||||
├── Event Processor
|
||||
├── Migration Controller
|
||||
└── Data Store
|
||||
↓
|
||||
File System Storage
|
||||
├── accounts/
|
||||
├── devices/
|
||||
├── sessions/ (existing)
|
||||
└── system/
|
||||
```
|
||||
|
||||
### External Integrations
|
||||
- **Bose Cloud** (during migration)
|
||||
- **Music Services** (Spotify, TuneIn, etc.)
|
||||
- **Discovery Services** (mDNS, UPnP)
|
||||
|
||||
## 7. Error Handling and Rollback Flow
|
||||
|
||||
### Description
|
||||
Decision tree for handling migration issues and rollback scenarios.
|
||||
|
||||
### Error Detection
|
||||
```
|
||||
Migration Issue Detected
|
||||
├── Device Unresponsive → Retry → Success/Rollback
|
||||
├── Data Corruption → Restore from Backup → Continue/Rollback
|
||||
├── Service Unavailable → Wait/Restart → Continue/Rollback
|
||||
└── User Dissatisfaction → Manual Rollback → Restore Bose Config
|
||||
```
|
||||
|
||||
### Rollback Process
|
||||
```
|
||||
[Rollback Initiated]
|
||||
↓
|
||||
[Disable Local Services]
|
||||
↓
|
||||
[Restore Original Device Config]
|
||||
↓
|
||||
[Re-enable Bose Services]
|
||||
↓
|
||||
[Verify Functionality]
|
||||
↓
|
||||
[Rollback Complete]
|
||||
```
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
### For Diagram Creation
|
||||
1. Use consistent colors as specified in main color scheme
|
||||
2. Include clear labels for all components
|
||||
3. Show directional flow with appropriate arrows
|
||||
4. Use standard flowchart symbols where applicable
|
||||
5. Ensure text is readable at various sizes
|
||||
|
||||
### Tools Recommended
|
||||
- **Lucidchart**: Professional flowcharts and network diagrams
|
||||
- **Draw.io**: Free online diagram tool
|
||||
- **Miro**: Collaborative whiteboarding
|
||||
- **PlantUML**: Code-based diagram generation
|
||||
|
||||
### File Naming Convention
|
||||
- `migration-flow-overview.svg` - Overall process flow
|
||||
- `network-topology.svg` - Network layout
|
||||
- `device-lifecycle.svg` - State machine
|
||||
- `data-flow-phases.svg` - Data flow during migration
|
||||
- `migration-timeline.svg` - Timeline visualization
|
||||
- `service-architecture.svg` - System architecture
|
||||
- `error-rollback-flow.svg` - Error handling
|
||||
|
||||
### Accessibility
|
||||
- Include alt-text descriptions
|
||||
- Use patterns/textures in addition to colors
|
||||
- Ensure sufficient contrast
|
||||
- Provide text-based versions for screen readers
|
||||
@@ -394,6 +394,9 @@ soundtouch-cli --host <device> source spotify
|
||||
soundtouch-cli --host <device> source bluetooth
|
||||
soundtouch-cli --host <device> source aux
|
||||
|
||||
# Custom radio selection (via soundtouch-service)
|
||||
soundtouch-cli --host <device> source custom-radio --url <STREAM_URL> [--name <NAME>] [--artwork <ARTWORK>] [--service-url <SERVICE_URL>]
|
||||
|
||||
# Advanced content selection
|
||||
soundtouch-cli --host <device> source internet-radio --location <URL> [--name <NAME>]
|
||||
soundtouch-cli --host <device> source local-music --location <LOCATION> --account <ACCOUNT>
|
||||
@@ -482,6 +485,7 @@ soundtouch-cli --host 192.168.1.10 source compare
|
||||
| Command | Description | Requirements |
|
||||
|---------|-------------|--------------|
|
||||
| `internet-radio` | Select internet radio stream (LOCAL_INTERNET_RADIO) | Stream URL |
|
||||
| `custom-radio` | Select custom radio stream via soundtouch-service | Stream URL and service URL |
|
||||
| `local-music` | Select local music content (LOCAL_MUSIC) | SoundTouch App Media Server |
|
||||
| `stored-music` | Select stored music content (STORED_MUSIC) | UPnP/DLNA media server |
|
||||
| `content` | Generic content selection (advanced) | Source and location |
|
||||
@@ -495,6 +499,12 @@ The `internet-radio` command supports the streamUrl proxy format from the [Sound
|
||||
soundtouch-cli --host 192.168.1.10 source internet-radio \
|
||||
--location "http://contentapi.gmuth.de/station.php?name=Antenne%20Chillout&streamUrl=https://stream.antenne.de/chillout/stream/aacp" \
|
||||
--name "Antenne Chillout"
|
||||
|
||||
# Using local soundtouch-service for custom streams
|
||||
soundtouch-cli --host 192.168.1.10 source custom-radio \
|
||||
--url "https://stream.antenne.de/chillout/stream/aacp" \
|
||||
--name "Antenne Chillout" \
|
||||
--service-url "http://localhost:8080"
|
||||
```
|
||||
|
||||
#### Service Introspection
|
||||
@@ -1044,7 +1054,7 @@ soundtouch-cli --host 192.168.1.10 speaker beep
|
||||
|
||||
**Supported Languages for TTS:**
|
||||
- `EN` - English (default)
|
||||
- `DE` - German
|
||||
- `DE` - German
|
||||
- `ES` - Spanish
|
||||
- `FR` - French
|
||||
- `IT` - Italian
|
||||
@@ -1085,7 +1095,7 @@ soundtouch-cli --host <device> events subscribe [flags]
|
||||
|
||||
**Event Types:**
|
||||
- `nowPlaying` - Track changes, playback status
|
||||
- `volume` - Volume and mute changes
|
||||
- `volume` - Volume and mute changes
|
||||
- `connection` - Network connectivity status
|
||||
- `preset` - Preset configuration changes
|
||||
- `zone` - Multiroom zone changes
|
||||
@@ -1248,6 +1258,6 @@ SOUNDTOUCH_DISCOVERY_TIMEOUT=10s
|
||||
## See Also
|
||||
|
||||
- [Getting Started Guide](GETTING-STARTED.md) - Basic setup and usage
|
||||
- [WebSocket Events](websocket-events.md) - Real-time monitoring
|
||||
- [Zone Management](zone-management.md) - Multi-room setup
|
||||
- [API Endpoints](API-Endpoints-Overview.md) - Complete API reference
|
||||
- [WebSocket Events](../reference/WEBSOCKET-EVENTS.md) - Real-time monitoring
|
||||
- [Zone Management](../reference/ZONE-MANAGEMENT.md) - Multi-room setup
|
||||
- [API Endpoints](../reference/API-ENDPOINTS.md) - Complete API reference
|
||||
@@ -13,6 +13,10 @@ This guide covers everything you need to know to deploy robust, scalable SoundTo
|
||||
- [Performance Optimization](#performance-optimization)
|
||||
- [Error Handling Recovery](#error-handling-recovery)
|
||||
- [Deployment Strategies](#deployment-strategies)
|
||||
- [Docker Deployment](#docker-deployment)
|
||||
- [Kubernetes Deployment](#kubernetes-deployment)
|
||||
- [Systemd Service](#systemd-service)
|
||||
- [Raspberry Pi Installer](#raspberry-pi-installer)
|
||||
- [Maintenance Operations](#maintenance-operations)
|
||||
|
||||
---
|
||||
@@ -926,39 +930,49 @@ data:
|
||||
device_hosts: "192.168.1.100,192.168.1.101,192.168.1.102"
|
||||
```
|
||||
|
||||
### Systemd Service
|
||||
#### Systemd Service
|
||||
|
||||
A standard systemd unit for manual installation. This example assumes the binary is at `/usr/local/bin/soundtouch-service` and data is stored in `/var/lib/soundtouch-service`.
|
||||
|
||||
```ini
|
||||
# /etc/systemd/system/soundtouch.service
|
||||
# /etc/systemd/system/soundtouch-service.service
|
||||
[Unit]
|
||||
Description=SoundTouch Control Service
|
||||
After=network.target
|
||||
Wants=network.target
|
||||
Description=Bose SoundTouch Service
|
||||
Wants=network-online.target
|
||||
After=network-online.target
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
User=soundtouch
|
||||
Group=soundtouch
|
||||
WorkingDirectory=/opt/soundtouch
|
||||
ExecStart=/opt/soundtouch/bin/soundtouch-app
|
||||
ExecReload=/bin/kill -HUP $MAINPID
|
||||
Restart=always
|
||||
RestartSec=5
|
||||
Environment=DEVICE_HOSTS=192.168.1.100,192.168.1.101
|
||||
Environment=LOG_LEVEL=info
|
||||
Environment=CONFIG_FILE=/opt/soundtouch/config/production.yaml
|
||||
WorkingDirectory=/var/lib/soundtouch-service
|
||||
ExecStart=/usr/local/bin/soundtouch-service
|
||||
Environment=PORT=80
|
||||
Environment=SERVER_URL=http://soundtouch.local
|
||||
|
||||
# Security settings
|
||||
NoNewPrivileges=true
|
||||
ProtectSystem=strict
|
||||
ProtectHome=true
|
||||
ReadWritePaths=/opt/soundtouch/logs
|
||||
# Allow binding to privileged ports (80/443) without running as root
|
||||
AmbientCapabilities=CAP_NET_BIND_SERVICE
|
||||
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
|
||||
|
||||
Restart=on-failure
|
||||
RestartSec=5
|
||||
|
||||
# Security hardening
|
||||
PrivateTmp=true
|
||||
ProtectSystem=full
|
||||
ProtectHome=true
|
||||
ReadWritePaths=/var/lib/soundtouch-service
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
#### Raspberry Pi Installer
|
||||
|
||||
For users deploying on a Raspberry Pi, we provide a specialized automated installer that handles everything from architecture detection to security hardening.
|
||||
|
||||
See the [Raspberry Pi Installation Guide](RASPBERRY-PI.md) for step-by-step instructions.
|
||||
|
||||
---
|
||||
|
||||
## Maintenance Operations
|
||||
@@ -1071,4 +1085,4 @@ func init() {
|
||||
|
||||
// Set GC target percentage
|
||||
if os.Getenv("GOGC") == "" {
|
||||
debug.SetGCPerc
|
||||
debug.SetGCPerc
|
||||
@@ -0,0 +1,80 @@
|
||||
# SoundTouch Device Initial Setup Variants
|
||||
|
||||
Based on community research from the **SoundCork** and **ÜberBöse API** projects, as well as analysis of the Stockholm firmware (`firmware/Stockholm/.../setup/`), this document outlines the methods used for the "out-of-the-box" setup of SoundTouch devices.
|
||||
|
||||
## Setup Overview
|
||||
|
||||
Initial setup is the process of connecting a new or factory-reset device to a local Wi-Fi network and a Bose (or custom) account. This is distinct from the "Migration" process (handled by `soundtouch-service`), which redirects an already-configured device to a new server.
|
||||
|
||||
---
|
||||
|
||||
## 1. Bluetooth Low Energy (BLE) Setup
|
||||
Used by most modern SoundTouch devices (ST-10, ST-20/30 Series III, SoundTouch 300).
|
||||
|
||||
- **Mechanism**: The SoundTouch app communicates with the device over BLE to exchange Wi-Fi credentials.
|
||||
- **Protocol**: Internal research refers to this as the **Gabbo** protocol (see `gabbo_setup_bco.js` in firmware).
|
||||
- **Process**:
|
||||
1. Put the device in setup mode (usually by holding the '2' and '-' buttons).
|
||||
2. The app discovers the device via BLE.
|
||||
3. The app sends the Wi-Fi SSID and Password to the device.
|
||||
4. The device connects to Wi-Fi and disables BLE setup.
|
||||
|
||||
---
|
||||
|
||||
## 2. Access Point (AP) Mode / Web Setup
|
||||
The classic "failover" or "alternate" setup method.
|
||||
|
||||
- **Mechanism**: The device creates its own Wi-Fi network (SSID: `Bose SoundTouch ...` or `Bose Home Speaker ...`).
|
||||
- **IP Address**: Typically `192.168.1.1` or `10.0.0.1` (device-side).
|
||||
- **Web Interface**: The device hosts a web server on port 80.
|
||||
- **Process**:
|
||||
1. Connect a PC/Phone to the device's Wi-Fi.
|
||||
2. Open a browser to `http://192.168.1.1`.
|
||||
3. The device serves `setup.html`, which redirects to a setup wizard (`setup/index.html`).
|
||||
4. Use the `gabbo_wifi` form to select a network and enter credentials.
|
||||
|
||||
---
|
||||
|
||||
## 3. Wireless Accessory Configuration (WAC)
|
||||
Specific to Apple iOS devices.
|
||||
|
||||
- **Mechanism**: Uses Apple's MFi/WAC protocol to pass Wi-Fi settings from an iPhone/iPad directly to the device without manual password entry.
|
||||
- **Status**: Detected automatically by iOS when a new SoundTouch device is in setup mode.
|
||||
|
||||
---
|
||||
|
||||
## 4. USB Setup (Legacy)
|
||||
Primarily used for older SoundTouch Series I and II devices or as a last resort.
|
||||
|
||||
- **Mechanism**: Physical connection via Micro-USB to a computer running the SoundTouch Setup application.
|
||||
- **Process**:
|
||||
1. Connect USB cable.
|
||||
2. The desktop app communicates via a proprietary HID or Serial-over-USB protocol.
|
||||
3. The app pushes Wi-Fi credentials.
|
||||
4. References to this exist in the firmware as `lost_USB_connection` and `connect_device` (see `setup_wizard.xml`).
|
||||
|
||||
---
|
||||
|
||||
## Technical Details: The "Gabbo" Protocol
|
||||
The Stockholm firmware contains references to a communication layer called **Gabbo**.
|
||||
- **File**: `setup/js/gabbo_setup_bco.js`
|
||||
- **Function**: Handles the state machine for Wi-Fi connection, account pairing, and error handling during setup.
|
||||
- **Relationship**: It appears to be an internal wrapper for the messages sent between the setup client (App or Browser) and the device firmware.
|
||||
|
||||
## Redirection during Setup
|
||||
While the `soundtouch-service` focuses on migrating existing devices, a truly "clean" setup to a custom service would require:
|
||||
1. Intercepting the initial account pairing request.
|
||||
2. Providing a mock "Marge" service that accepts any credentials.
|
||||
3. Patching the `SoundTouchSdkPrivateCfg.xml` during or immediately after the Wi-Fi connection phase.
|
||||
|
||||
---
|
||||
|
||||
## Comparison: Initial Setup vs. Migration
|
||||
|
||||
| Feature | Initial Setup | Migration (soundtouch-service) |
|
||||
| :--- | :--- | :--- |
|
||||
| **Connectivity** | BLE, AP Mode, USB, WAC | Ethernet/Wi-Fi (existing) |
|
||||
| **Credentials** | Required (SSID/Pass) | Not required (uses existing) |
|
||||
| **Access** | Web UI / App protocol | SSH (root) |
|
||||
| **Primary File** | `setup/index.html` | `SoundTouchSdkPrivateCfg.xml` |
|
||||
| **Use Case** | Out-of-the-box / Reset | Redirecting active devices |
|
||||
@@ -0,0 +1,109 @@
|
||||
# HTTPS Setup & Custom CA Certificate
|
||||
|
||||
To use the `/etc/hosts` redirection method safely, SoundTouch devices must communicate over HTTPS. This requires the device to trust the AfterTouch Root CA certificate used by the local service.
|
||||
|
||||
## 1. Automated Migration (Hosts Method)
|
||||
|
||||
The `soundtouch-service` can automatically configure a device to use the `/etc/hosts` method:
|
||||
|
||||
```bash
|
||||
curl -X POST "http://localhost:8000/setup/migrate/{deviceIP}?method=hosts"
|
||||
```
|
||||
|
||||
This command will:
|
||||
1. Connect to the device via SSH.
|
||||
2. Update `/etc/hosts` to point Bose domains to the service IP.
|
||||
3. Inject the auto-generated AfterTouch Root CA into the device's trust store (`/etc/pki/tls/certs/ca-bundle.crt`).
|
||||
4. Reboot the device.
|
||||
|
||||
## 2. Managing the Root CA
|
||||
|
||||
The AfterTouch service automatically generates a Root CA when it first starts.
|
||||
|
||||
- **CA Certificate**: `data/certs/ca.crt`
|
||||
- **CA Private Key**: `data/certs/ca.key`
|
||||
|
||||
### Downloading the CA Certificate
|
||||
You can download the CA certificate for manual installation on other devices (like your phone or PC) from:
|
||||
`http://<server-ip>:8000/setup/ca.crt`
|
||||
|
||||
### 3. Built-in HTTPS Support
|
||||
|
||||
The `soundtouch-service` now includes a built-in HTTPS listener. This simplifies the `/etc/hosts` redirection method by automatically presenting the correct certificates for Bose domains.
|
||||
|
||||
- **HTTPS Port**: Configurable via `HTTPS_PORT` environment variable (defaults to `8443`).
|
||||
- **HTTPS Server URL**: Configurable via `HTTPS_SERVER_URL` (e.g., `https://mysoundtouch.local:8443`). If not set, the service attempts to guess it using the system hostname.
|
||||
- **Domain Coverage**: Automatically presents a certificate with comprehensive coverage using wildcard certificates (`*.api.bose.io`, `*.api.bosecm.com`) plus specific domains (`streaming.bose.com`, `updates.bose.com`, `stats.bose.com`, `bmx.bose.com`, `worldwide.bose.com`, `bose-prod.apigee.net`, etc.).
|
||||
- **Wildcard Support**: Uses RFC-compliant wildcard certificates for automatic coverage of all API subdomains, including event analytics endpoints like `events.api.bosecm.com`, `eventsdev.api.bosecm.com`, and future API services.
|
||||
- **TLS Error Logging**: Comprehensive logging of TLS handshake attempts, certificate matching, and connection failures for debugging DNS redirection issues.
|
||||
- **Automatic Setup**: On first start, it generates a server certificate signed by your AfterTouch local Root CA.
|
||||
|
||||
#### TLS Security & Debugging
|
||||
|
||||
The built-in HTTPS listener is configured to use modern and secure TLS settings while maintaining compatibility with SoundTouch devices (which support up to TLS 1.2 with OpenSSL 1.0.2).
|
||||
|
||||
- **Minimum TLS Version**: TLS 1.2
|
||||
- **Preferred Cipher Suites**:
|
||||
- `ECDHE-RSA-AES128-GCM-SHA256`
|
||||
- **TLS Debugging**: Detailed logging of:
|
||||
- Certificate requests by domain (`[TLS] Certificate request for ServerName: events.api.bosecm.com`)
|
||||
- Wildcard certificate matching (`[TLS] ✅ Serving certificate for events.api.bosecm.com (matched *.api.bosecm.com)`)
|
||||
- Handshake failures (`[TLS] ❌ Handshake failed from 192.168.1.50: tls: certificate not found`)
|
||||
- Successful connections (`[TLS] ✅ Successful connection from 192.168.1.50`)
|
||||
- `ECDHE-RSA-AES256-GCM-SHA384`
|
||||
- `ECDHE-RSA-CHACHA20-POLY1305`
|
||||
- `RSA-AES128-GCM-SHA256` (Legacy support)
|
||||
- `RSA-AES256-GCM-SHA384` (Legacy support)
|
||||
|
||||
#### Binding to Port 443
|
||||
SoundTouch devices expect HTTPS on the default port 443. Since binding to port 443 usually requires root privileges, you have two options:
|
||||
|
||||
1. **Port Forwarding (Recommended)**: Run the service on a high port (e.g., 8443) and use `iptables` or your firewall to forward traffic from 443 to 8443.
|
||||
2. **Capabilities**: Grant the binary permission to bind to low ports: `sudo setcap 'cap_net_bind_service=+ep' ./soundtouch-service`.
|
||||
3. **Reverse Proxy**: Use Nginx or Caddy as described below.
|
||||
|
||||
### 4. Reverse Proxy (Optional)
|
||||
|
||||
1. **Generate a certificate** for the Bose domains signed by your Root CA.
|
||||
2. **Configure Nginx** to use this certificate and proxy requests to `soundtouch-service`.
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 443 ssl;
|
||||
server_name streaming.bose.com bmx.bose.com stats.bose.com updates.bose.com;
|
||||
|
||||
ssl_certificate /path/to/generated-cert.crt;
|
||||
ssl_certificate_key /path/to/generated-cert.key;
|
||||
|
||||
# Secure TLS configuration (matches soundtouch-service defaults)
|
||||
ssl_protocols TLSv1.2;
|
||||
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:AES128-GCM-SHA256:AES256-GCM-SHA384';
|
||||
|
||||
location / {
|
||||
proxy_pass http://localhost:8000;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 5. Manual CA Injection (Legacy/Manual)
|
||||
|
||||
If you prefer to inject the CA certificate manually:
|
||||
|
||||
1. Copy `ca.crt` to the device:
|
||||
```bash
|
||||
scp data/certs/ca.crt root@{deviceIP}:/tmp/
|
||||
```
|
||||
2. Append it to the trust store on the device:
|
||||
```bash
|
||||
ssh root@{deviceIP} "(rw || mount -o remount,rw /) && cat /tmp/ca.crt >> /etc/pki/tls/certs/ca-bundle.crt"
|
||||
```
|
||||
|
||||
## 6. Verifying Connectivity
|
||||
|
||||
You can verify that your device can correctly reach the `soundtouch-service` over HTTPS using the management web UI.
|
||||
|
||||
In the **Migration Summary** for a device, you will find an **HTTPS Connection Test** section:
|
||||
- **Test with Explicit CA.crt**: Uploads a temporary copy of the Root CA to the device and uses `curl --cacert` to verify the connection. Use this to verify your HTTPS setup *before* modifying the device's shared trust store.
|
||||
- **Test with Shared Trust Store**: Uses the device's default trust store. Use this to verify that your CA injection was successful and the device now natively trusts your local server.
|
||||
@@ -0,0 +1,753 @@
|
||||
# IoT Implementation Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This guide provides technical implementation details for integrating with the Bose SoundTouch IoT configuration system. It covers the AWS IoT Core integration, certificate management, and device shadow operations.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- AWS IoT Core account and permissions
|
||||
- Understanding of MQTT protocol
|
||||
- Knowledge of X.509 certificate management
|
||||
- Familiarity with JSON and protobuf serialization
|
||||
|
||||
## Architecture Components
|
||||
|
||||
### Core System Design
|
||||
|
||||
```
|
||||
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐
|
||||
│ Mobile App │ │ Alexa Voice │ │ Web Interface │
|
||||
│ │ │ Assistant │ │ │
|
||||
└─────────┬───────┘ └─────────┬────────┘ └─────────┬───────┘
|
||||
│ │ │
|
||||
└──────────────────────┼───────────────────────┘
|
||||
│
|
||||
┌────────────▼──────────────┐
|
||||
│ AWS IoT Core │
|
||||
│ (MQTT Broker + │
|
||||
│ Device Shadows) │
|
||||
└────────────┬──────────────┘
|
||||
│ MQTT/TLS
|
||||
┌────────────▼──────────────┐
|
||||
│ SoundTouch Device │
|
||||
│ │
|
||||
│ ┌─────────────────────┐ │
|
||||
│ │ IoT Service │ │
|
||||
│ │ (/opt/Bose/IoT) │ │
|
||||
│ └─────────────────────┘ │
|
||||
│ ┌─────────────────────┐ │
|
||||
│ │ BoseApp Service │ │
|
||||
│ │ (/opt/Bose/BoseApp) │ │
|
||||
│ └─────────────────────┘ │
|
||||
└───────────────────────────┘
|
||||
```
|
||||
|
||||
### Configuration Flow
|
||||
|
||||
```
|
||||
1. Device Boot
|
||||
│
|
||||
▼
|
||||
2. Read IoT.xml (/mnt/nv/BoseApp-Persistence/1/IoT.xml)
|
||||
│
|
||||
▼
|
||||
3. Load Certificates (/mnt/nv/IoTCerts/)
|
||||
│
|
||||
▼
|
||||
4. Establish MQTT/TLS Connection
|
||||
│
|
||||
▼
|
||||
5. Subscribe to Device Shadow Topics
|
||||
│
|
||||
▼
|
||||
6. Publish Current Device State
|
||||
│
|
||||
▼
|
||||
7. Listen for Delta Messages
|
||||
```
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### 1. Configuration File Management
|
||||
|
||||
#### IoT.xml Structure
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<Configuration
|
||||
clientID="{device-unique-uuid}"
|
||||
iotEndpoint="{aws-iot-endpoint}"
|
||||
deployment="{PROD|DEV|TEST}" />
|
||||
```
|
||||
|
||||
#### Loading Configuration (C++ Implementation)
|
||||
```cpp
|
||||
#include <rapidxml/rapidxml.hpp>
|
||||
#include <fstream>
|
||||
|
||||
struct IoTConfig {
|
||||
std::string clientID;
|
||||
std::string iotEndpoint;
|
||||
std::string deployment;
|
||||
};
|
||||
|
||||
IoTConfig loadIoTConfig(const std::string& configPath) {
|
||||
std::ifstream file(configPath);
|
||||
std::string content((std::istreambuf_iterator<char>(file)),
|
||||
std::istreambuf_iterator<char>());
|
||||
|
||||
rapidxml::xml_document<> doc;
|
||||
doc.parse<0>(&content[0]);
|
||||
|
||||
auto configNode = doc.first_node("Configuration");
|
||||
|
||||
IoTConfig config;
|
||||
config.clientID = configNode->first_attribute("clientID")->value();
|
||||
config.iotEndpoint = configNode->first_attribute("iotEndpoint")->value();
|
||||
config.deployment = configNode->first_attribute("deployment")->value();
|
||||
|
||||
return config;
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Certificate Management
|
||||
|
||||
#### Certificate Files Structure
|
||||
```
|
||||
/mnt/nv/IoTCerts/
|
||||
├── iot-cert.pem.crt # Device client certificate
|
||||
├── iot-private.pem.key # Device private key
|
||||
└── default.pem # Additional cert data
|
||||
|
||||
/var/lib/iot/
|
||||
└── rootCA.crt # AWS IoT Root CA
|
||||
```
|
||||
|
||||
#### Certificate Registration Process
|
||||
```cpp
|
||||
#include <openssl/x509.h>
|
||||
#include <openssl/rsa.h>
|
||||
#include <openssl/pem.h>
|
||||
|
||||
class IoTCertificateManager {
|
||||
private:
|
||||
static const std::string CERT_ENDPOINT;
|
||||
static const std::string CERT_PATH;
|
||||
static const std::string KEY_PATH;
|
||||
|
||||
public:
|
||||
bool generateCSR() {
|
||||
// Generate EC key pair
|
||||
EC_KEY* eckey = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
|
||||
EC_KEY_generate_key(eckey);
|
||||
|
||||
// Create certificate request
|
||||
X509_REQ* req = X509_REQ_new();
|
||||
X509_REQ_set_version(req, 0);
|
||||
|
||||
// Set subject name
|
||||
X509_NAME* name = X509_NAME_new();
|
||||
X509_NAME_add_entry_by_txt(name, "CN", MBSTRING_ASC,
|
||||
(unsigned char*)clientID.c_str(), -1, -1, 0);
|
||||
X509_REQ_set_subject_name(req, name);
|
||||
|
||||
// Set public key
|
||||
EVP_PKEY* pkey = EVP_PKEY_new();
|
||||
EVP_PKEY_set1_EC_KEY(pkey, eckey);
|
||||
X509_REQ_set_pubkey(req, pkey);
|
||||
|
||||
// Sign request
|
||||
X509_REQ_sign(req, pkey, EVP_sha256());
|
||||
|
||||
return sendCSRToEndpoint(req, pkey);
|
||||
}
|
||||
|
||||
bool sendCSRToEndpoint(X509_REQ* req, EVP_PKEY* pkey) {
|
||||
// Send CSR to voice.api.bose.io/alexa/certificate
|
||||
// Receive certificate response
|
||||
// Store certificate and private key
|
||||
return true;
|
||||
}
|
||||
};
|
||||
|
||||
const std::string IoTCertificateManager::CERT_ENDPOINT =
|
||||
"https://voice.api.bose.io/alexa/certificate";
|
||||
const std::string IoTCertificateManager::CERT_PATH =
|
||||
"/mnt/nv/IoTCerts/iot-cert.pem.crt";
|
||||
const std::string IoTCertificateManager::KEY_PATH =
|
||||
"/mnt/nv/IoTCerts/iot-private.pem.key";
|
||||
```
|
||||
|
||||
### 3. MQTT Connection Implementation
|
||||
|
||||
#### AWS IoT SDK Integration
|
||||
```cpp
|
||||
#include <aws/iot/MqttClient.h>
|
||||
#include <aws/iot/ShadowClient.h>
|
||||
|
||||
class IoTConnectionManager {
|
||||
private:
|
||||
std::unique_ptr<awsiotsdk::MqttClient> mqttClient;
|
||||
std::unique_ptr<awsiotsdk::Shadow> shadowClient;
|
||||
IoTConfig config;
|
||||
|
||||
public:
|
||||
awsiotsdk::ResponseCode connect() {
|
||||
// Setup connection parameters
|
||||
std::string endpoint = config.iotEndpoint;
|
||||
uint16_t port = 8883; // MQTT over SSL
|
||||
|
||||
// Load certificates
|
||||
std::string certPath = "/mnt/nv/IoTCerts/iot-cert.pem.crt";
|
||||
std::string keyPath = "/mnt/nv/IoTCerts/iot-private.pem.key";
|
||||
std::string rootCaPath = "/var/lib/iot/rootCA.crt";
|
||||
|
||||
// Create network connection
|
||||
auto networkConnection = std::make_shared<awsiotsdk::network::MbedTLSConnection>(
|
||||
endpoint, port, rootCaPath, certPath, keyPath
|
||||
);
|
||||
|
||||
// Create MQTT client
|
||||
mqttClient = awsiotsdk::MqttClient::Create(networkConnection);
|
||||
if (!mqttClient) {
|
||||
return awsiotsdk::ResponseCode::FAILURE;
|
||||
}
|
||||
|
||||
// Connect with client ID
|
||||
auto connectPacket = awsiotsdk::mqtt::ConnectPacket::Create(
|
||||
config.clientID,
|
||||
true, // cleanSession
|
||||
awsiotsdk::mqtt::QoS::QOS0,
|
||||
nullptr // will options
|
||||
);
|
||||
|
||||
return mqttClient->Connect(std::chrono::milliseconds(5000), connectPacket);
|
||||
}
|
||||
|
||||
awsiotsdk::ResponseCode initializeShadow() {
|
||||
shadowClient = awsiotsdk::Shadow::Create(mqttClient);
|
||||
if (!shadowClient) {
|
||||
return awsiotsdk::ResponseCode::FAILURE;
|
||||
}
|
||||
|
||||
// Subscribe to shadow delta
|
||||
auto deltaHandler = [this](const std::string& thingName,
|
||||
const std::string& payload) {
|
||||
handleShadowDelta(thingName, payload);
|
||||
};
|
||||
|
||||
return shadowClient->PerformUpdateAsync(
|
||||
config.clientID,
|
||||
"", // jsonString
|
||||
deltaHandler,
|
||||
std::chrono::seconds(10)
|
||||
);
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
### 4. Device Shadow Operations
|
||||
|
||||
#### Shadow Message Structures
|
||||
```cpp
|
||||
#include <rapidjson/document.h>
|
||||
#include <rapidjson/writer.h>
|
||||
#include <rapidjson/stringbuffer.h>
|
||||
|
||||
struct DeviceState {
|
||||
std::string deviceState; // "CONNECTED" | "DISCONNECTED"
|
||||
std::string powerState; // "ON" | "OFF"
|
||||
std::string zoneState; // Zone configuration
|
||||
std::string groupState; // Multi-room group info
|
||||
};
|
||||
|
||||
class ShadowMessageBuilder {
|
||||
public:
|
||||
static std::string createReportedState(const DeviceState& state) {
|
||||
rapidjson::Document doc;
|
||||
doc.SetObject();
|
||||
auto& allocator = doc.GetAllocator();
|
||||
|
||||
// Create state object
|
||||
rapidjson::Value stateObj(rapidjson::kObjectType);
|
||||
rapidjson::Value reportedObj(rapidjson::kObjectType);
|
||||
|
||||
// Add reported state fields
|
||||
reportedObj.AddMember("deviceState",
|
||||
rapidjson::Value(state.deviceState.c_str(), allocator),
|
||||
allocator);
|
||||
reportedObj.AddMember("powerState",
|
||||
rapidjson::Value(state.powerState.c_str(), allocator),
|
||||
allocator);
|
||||
reportedObj.AddMember("zoneState",
|
||||
rapidjson::Value(state.zoneState.c_str(), allocator),
|
||||
allocator);
|
||||
reportedObj.AddMember("groupState",
|
||||
rapidjson::Value(state.groupState.c_str(), allocator),
|
||||
allocator);
|
||||
|
||||
stateObj.AddMember("reported", reportedObj, allocator);
|
||||
doc.AddMember("state", stateObj, allocator);
|
||||
|
||||
// Serialize to string
|
||||
rapidjson::StringBuffer buffer;
|
||||
rapidjson::Writer<rapidjson::StringBuffer> writer(buffer);
|
||||
doc.Accept(writer);
|
||||
|
||||
return buffer.GetString();
|
||||
}
|
||||
|
||||
static DeviceState parseDesiredState(const std::string& json) {
|
||||
rapidjson::Document doc;
|
||||
doc.Parse(json.c_str());
|
||||
|
||||
DeviceState state;
|
||||
if (doc.HasMember("state") && doc["state"].HasMember("desired")) {
|
||||
auto& desired = doc["state"]["desired"];
|
||||
|
||||
if (desired.HasMember("powerState")) {
|
||||
state.powerState = desired["powerState"].GetString();
|
||||
}
|
||||
if (desired.HasMember("zoneState")) {
|
||||
state.zoneState = desired["zoneState"].GetString();
|
||||
}
|
||||
if (desired.HasMember("groupState")) {
|
||||
state.groupState = desired["groupState"].GetString();
|
||||
}
|
||||
}
|
||||
|
||||
return state;
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
#### Shadow Update Implementation
|
||||
```cpp
|
||||
class IoTShadowManager {
|
||||
private:
|
||||
std::shared_ptr<awsiotsdk::Shadow> shadowClient;
|
||||
std::string thingName;
|
||||
DeviceState currentState;
|
||||
|
||||
public:
|
||||
awsiotsdk::ResponseCode updateDeviceState(const DeviceState& newState) {
|
||||
currentState = newState;
|
||||
|
||||
std::string payload = ShadowMessageBuilder::createReportedState(newState);
|
||||
|
||||
auto responseHandler = [](const std::string& thingName,
|
||||
awsiotsdk::ShadowRequestType requestType,
|
||||
awsiotsdk::ShadowResponseType responseType,
|
||||
rapidjson::Document& payload) {
|
||||
if (responseType == awsiotsdk::ShadowResponseType::Accepted) {
|
||||
// Shadow update successful
|
||||
std::cout << "Shadow updated successfully" << std::endl;
|
||||
} else {
|
||||
// Handle rejection
|
||||
std::cout << "Shadow update rejected" << std::endl;
|
||||
}
|
||||
};
|
||||
|
||||
return shadowClient->PerformUpdateAsync(
|
||||
thingName,
|
||||
payload,
|
||||
responseHandler,
|
||||
std::chrono::seconds(10)
|
||||
);
|
||||
}
|
||||
|
||||
void handleShadowDelta(const std::string& thingName,
|
||||
const std::string& payload) {
|
||||
DeviceState desiredState = ShadowMessageBuilder::parseDesiredState(payload);
|
||||
|
||||
// Apply desired state changes to device
|
||||
if (!desiredState.powerState.empty()) {
|
||||
applyPowerStateChange(desiredState.powerState);
|
||||
}
|
||||
|
||||
if (!desiredState.zoneState.empty()) {
|
||||
applyZoneStateChange(desiredState.zoneState);
|
||||
}
|
||||
|
||||
if (!desiredState.groupState.empty()) {
|
||||
applyGroupStateChange(desiredState.groupState);
|
||||
}
|
||||
|
||||
// Report updated state back to shadow
|
||||
updateDeviceState(currentState);
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
### 5. Service Integration
|
||||
|
||||
#### Shepherd Service Configuration
|
||||
```xml
|
||||
<!-- /opt/Bose/etc/Shepherd-noncore.xml -->
|
||||
<ShepherdConfig>
|
||||
<daemon name="STSCertified"/>
|
||||
<daemon name="IoT">
|
||||
<env name="IOT_CONFIG_PATH">/mnt/nv/BoseApp-Persistence/1/IoT.xml</env>
|
||||
<env name="IOT_CERT_PATH">/mnt/nv/IoTCerts</env>
|
||||
</daemon>
|
||||
<daemon name="TPDA">
|
||||
<arg>-c</arg>
|
||||
<arg>/opt/Bose/etc/Voice.xml</arg>
|
||||
</daemon>
|
||||
</ShepherdConfig>
|
||||
```
|
||||
|
||||
#### System Startup Integration
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# /etc/init.d/SoundTouch fragment
|
||||
|
||||
# Create IoT directories
|
||||
mkdir -p /mnt/nv/BoseLog /mnt/nv/IoTCerts /mnt/nv/BoseApp-Persistence/1
|
||||
mkdir -m 700 -p /mnt/nv/BoseApp-Persistence/1/Keys
|
||||
|
||||
# Set proper permissions for certificate storage
|
||||
chmod 700 /mnt/nv/IoTCerts
|
||||
chown iot:iot /mnt/nv/IoTCerts
|
||||
|
||||
# Start shepherd daemon manager
|
||||
shepherdd --config-dir /opt/Bose/etc --run-dir /var/run/shepherd
|
||||
```
|
||||
|
||||
## Error Handling and Debugging
|
||||
|
||||
### Connection Retry Logic
|
||||
```cpp
|
||||
class ConnectionRetryManager {
|
||||
private:
|
||||
int maxRetries = 10;
|
||||
int retryDelaySeconds = 5;
|
||||
|
||||
public:
|
||||
awsiotsdk::ResponseCode connectWithRetry(IoTConnectionManager& manager) {
|
||||
for (int attempt = 1; attempt <= maxRetries; ++attempt) {
|
||||
std::cout << "Connection attempt " << attempt
|
||||
<< " to MQTT port at host " << config.iotEndpoint << std::endl;
|
||||
|
||||
auto result = manager.connect();
|
||||
if (result == awsiotsdk::ResponseCode::SUCCESS) {
|
||||
std::cout << "Successfully connected to MQTT server" << std::endl;
|
||||
return result;
|
||||
}
|
||||
|
||||
std::cout << "MQTT port not available. Retrying in "
|
||||
<< retryDelaySeconds << " seconds" << std::endl;
|
||||
|
||||
std::this_thread::sleep_for(std::chrono::seconds(retryDelaySeconds));
|
||||
retryDelaySeconds *= 2; // Exponential backoff
|
||||
}
|
||||
|
||||
std::cerr << "Failed to connect after " << maxRetries << " attempts" << std::endl;
|
||||
return awsiotsdk::ResponseCode::FAILURE;
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
### Logging and Monitoring
|
||||
```cpp
|
||||
class IoTLogger {
|
||||
public:
|
||||
static void logConnectionStatus(const std::string& status) {
|
||||
std::cout << "[IoT] Connection status: " << status << std::endl;
|
||||
}
|
||||
|
||||
static void logShadowResponse(awsiotsdk::ShadowResponseType response,
|
||||
const std::string& payload) {
|
||||
if (response == awsiotsdk::ShadowResponseType::Accepted) {
|
||||
std::cout << "[IoT] Shadow response: accepted. Payload: " << payload << std::endl;
|
||||
} else {
|
||||
std::cout << "[IoT] Shadow response: rejected" << std::endl;
|
||||
}
|
||||
}
|
||||
|
||||
static void logCertificateStatus(bool success) {
|
||||
if (success) {
|
||||
std::cout << "[IoT] Certificate generated successfully" << std::endl;
|
||||
} else {
|
||||
std::cerr << "[IoT] Failed to generate iot certificate" << std::endl;
|
||||
}
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
## Testing and Validation
|
||||
|
||||
### Unit Test Example
|
||||
```cpp
|
||||
#include <gtest/gtest.h>
|
||||
|
||||
class IoTConfigTest : public ::testing::Test {
|
||||
protected:
|
||||
void SetUp() override {
|
||||
// Create test configuration file
|
||||
std::ofstream file("/tmp/test_iot.xml");
|
||||
file << R"(<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<Configuration clientID="test-client-id"
|
||||
iotEndpoint="test.iot.amazonaws.com"
|
||||
deployment="TEST" />)";
|
||||
file.close();
|
||||
}
|
||||
};
|
||||
|
||||
TEST_F(IoTConfigTest, LoadConfiguration) {
|
||||
auto config = loadIoTConfig("/tmp/test_iot.xml");
|
||||
|
||||
EXPECT_EQ(config.clientID, "test-client-id");
|
||||
EXPECT_EQ(config.iotEndpoint, "test.iot.amazonaws.com");
|
||||
EXPECT_EQ(config.deployment, "TEST");
|
||||
}
|
||||
|
||||
TEST_F(IoTConfigTest, ShadowMessageBuilder) {
|
||||
DeviceState state;
|
||||
state.deviceState = "CONNECTED";
|
||||
state.powerState = "ON";
|
||||
|
||||
std::string json = ShadowMessageBuilder::createReportedState(state);
|
||||
|
||||
// Verify JSON contains expected fields
|
||||
EXPECT_TRUE(json.find("\"deviceState\":\"CONNECTED\"") != std::string::npos);
|
||||
EXPECT_TRUE(json.find("\"powerState\":\"ON\"") != std::string::npos);
|
||||
}
|
||||
```
|
||||
|
||||
## Security Best Practices
|
||||
|
||||
1. **Certificate Management**
|
||||
- Store private keys with 600 permissions
|
||||
- Rotate certificates regularly
|
||||
- Use hardware security modules when available
|
||||
|
||||
2. **Network Security**
|
||||
- Always use TLS 1.2 or higher
|
||||
- Validate certificate chains
|
||||
- Implement certificate pinning
|
||||
|
||||
3. **Configuration Security**
|
||||
- Encrypt sensitive configuration data
|
||||
- Use secure storage for credentials
|
||||
- Implement configuration validation
|
||||
|
||||
## Troubleshooting Common Issues
|
||||
|
||||
### Certificate Problems
|
||||
```bash
|
||||
# Check certificate validity
|
||||
openssl x509 -in /mnt/nv/IoTCerts/iot-cert.pem.crt -text -noout
|
||||
|
||||
# Verify private key matches certificate
|
||||
openssl x509 -noout -modulus -in /mnt/nv/IoTCerts/iot-cert.pem.crt | openssl md5
|
||||
openssl rsa -noout -modulus -in /mnt/nv/IoTCerts/iot-private.pem.key | openssl md5
|
||||
```
|
||||
|
||||
### Connection Issues
|
||||
```bash
|
||||
# Test MQTT connectivity
|
||||
mosquitto_pub -h a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com \
|
||||
-p 8883 --cafile /var/lib/iot/rootCA.crt \
|
||||
--cert /mnt/nv/IoTCerts/iot-cert.pem.crt \
|
||||
--key /mnt/nv/IoTCerts/iot-private.pem.key \
|
||||
-t '$aws/things/test/shadow/update' \
|
||||
-m '{"state":{"reported":{"test":"value"}}}'
|
||||
```
|
||||
|
||||
### Service Debugging
|
||||
```bash
|
||||
# Check service status
|
||||
ps aux | grep IoT
|
||||
|
||||
# Monitor system logs
|
||||
tail -f /mnt/nv/BoseLog/IoT.log
|
||||
|
||||
# Check Shepherd status
|
||||
shepherdd --status
|
||||
```
|
||||
|
||||
## MQTT Monitoring and Research
|
||||
|
||||
### Direct Device Credential Access
|
||||
|
||||
With device certificates and private keys available from firmware backups, it's technically possible to monitor MQTT traffic:
|
||||
|
||||
```bash
|
||||
# Subscribe to your device's shadow events only
|
||||
CLIENT_ID="577ecfcc-2db3-4989-92c9-76d7704f9fb3" # Your device's UUID
|
||||
mosquitto_sub -h a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com \
|
||||
-p 8883 --cafile /var/lib/iot/rootCA.crt \
|
||||
--cert /mnt/nv/IoTCerts/iot-cert.pem.crt \
|
||||
--key /mnt/nv/IoTCerts/iot-private.pem.key \
|
||||
-t "\$aws/things/$CLIENT_ID/shadow/update/accepted"
|
||||
```
|
||||
|
||||
### Security Constraints and Limitations
|
||||
|
||||
#### AWS IoT Policy Restrictions
|
||||
Device certificates are bound to restrictive policies:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": "iot:Connect",
|
||||
"Resource": "arn:aws:iot:us-east-1:*:client/${iot:ClientId}"
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": ["iot:Publish", "iot:Subscribe", "iot:Receive"],
|
||||
"Resource": [
|
||||
"arn:aws:iot:us-east-1:*:topic/$aws/things/${iot:ClientId}/shadow/*"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**Limitations:**
|
||||
- Access only to your specific device topics
|
||||
- No wildcard subscriptions (`+` or `#`)
|
||||
- No cross-device monitoring
|
||||
- Potential IP geolocation restrictions
|
||||
- Certificate revocation for unusual activity
|
||||
|
||||
### Alternative Monitoring Approaches
|
||||
|
||||
#### Network Traffic Capture (Recommended)
|
||||
```bash
|
||||
# Capture MQTT traffic patterns without authentication
|
||||
tcpdump -i eth0 -s0 -w soundtouch_iot.pcap host a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com
|
||||
|
||||
# Monitor connection patterns in real-time
|
||||
tcpdump -i eth0 -n -A "host a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com and port 8883"
|
||||
|
||||
# Extract timing and packet size information
|
||||
tcpdump -i eth0 -ttt -s0 "host a2bhvr9c4wn4ya.iot.us-east-1.amazonaws.com"
|
||||
```
|
||||
|
||||
#### Local MQTT Broker for Testing
|
||||
```bash
|
||||
# Set up local Mosquitto broker
|
||||
sudo apt-get install mosquitto mosquitto-clients
|
||||
|
||||
# Configure TLS (optional)
|
||||
cat > /etc/mosquitto/conf.d/tls.conf << EOF
|
||||
port 8883
|
||||
cafile /path/to/ca.crt
|
||||
certfile /path/to/server.crt
|
||||
keyfile /path/to/server.key
|
||||
require_certificate true
|
||||
use_identity_as_username true
|
||||
EOF
|
||||
|
||||
# Test local shadow operations
|
||||
mosquitto_pub -h localhost -p 8883 \
|
||||
-t '$aws/things/test-device/shadow/update' \
|
||||
-m '{"state":{"reported":{"deviceState":"CONNECTED"}}}'
|
||||
```
|
||||
|
||||
### Message Analysis and Documentation
|
||||
|
||||
Expected shadow message patterns:
|
||||
|
||||
```cpp
|
||||
// Power state transitions
|
||||
{
|
||||
"state": {
|
||||
"reported": {
|
||||
"deviceState": "CONNECTED",
|
||||
"powerState": "ON|OFF"
|
||||
}
|
||||
},
|
||||
"timestamp": 1703875200
|
||||
}
|
||||
|
||||
// Audio control updates
|
||||
{
|
||||
"state": {
|
||||
"reported": {
|
||||
"volume": 25,
|
||||
"muted": false,
|
||||
"source": "SPOTIFY"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Multi-room coordination
|
||||
{
|
||||
"state": {
|
||||
"reported": {
|
||||
"zoneState": "master|slave",
|
||||
"groupMembers": ["device1", "device2"],
|
||||
"groupName": "Living Room"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Legal and Ethical Guidelines
|
||||
|
||||
**Important Warnings:**
|
||||
- Only monitor devices you personally own
|
||||
- Using device credentials outside the device may violate Bose Terms of Service
|
||||
- Accessing Bose's AWS infrastructure could be considered unauthorized
|
||||
- Certificate abuse may result in device blacklisting
|
||||
- Service shutdown in May 2026 makes this a temporary research opportunity
|
||||
|
||||
**Recommended Usage:**
|
||||
- Document message formats for local alternative development
|
||||
- Understand state transition patterns
|
||||
- Test compatibility with local MQTT brokers
|
||||
- Prepare migration strategies before cloud shutdown
|
||||
|
||||
### Research Implementation Example
|
||||
|
||||
```cpp
|
||||
class IoTResearchMonitor {
|
||||
private:
|
||||
std::string deviceClientId;
|
||||
std::ofstream messageLog;
|
||||
|
||||
public:
|
||||
void captureMessagePatterns() {
|
||||
// Subscribe only to owned device topics
|
||||
std::string topic = "$aws/things/" + deviceClientId + "/shadow/update/accepted";
|
||||
|
||||
auto messageHandler = [this](const std::string& topic, const std::string& payload) {
|
||||
// Log message structure for analysis
|
||||
messageLog << "Topic: " << topic << std::endl;
|
||||
messageLog << "Payload: " << payload << std::endl;
|
||||
messageLog << "Timestamp: " << getCurrentTimestamp() << std::endl;
|
||||
messageLog << "---" << std::endl;
|
||||
|
||||
// Parse and document state transitions
|
||||
documentStateTransition(payload);
|
||||
};
|
||||
|
||||
// WARNING: Only use with your own device certificates
|
||||
connectToAWSIoT(messageHandler);
|
||||
}
|
||||
|
||||
void documentStateTransition(const std::string& json) {
|
||||
// Analyze JSON structure for local implementation
|
||||
rapidjson::Document doc;
|
||||
doc.Parse(json.c_str());
|
||||
|
||||
if (doc.HasMember("state") && doc["state"].HasMember("reported")) {
|
||||
// Document field types and value ranges
|
||||
auto& reported = doc["state"]["reported"];
|
||||
|
||||
for (auto& field : reported.GetObject()) {
|
||||
std::cout << "Field: " << field.name.GetString()
|
||||
<< ", Type: " << getJSONType(field.value) << std::endl;
|
||||
}
|
||||
}
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
This implementation guide provides the foundation for integrating with the Bose SoundTouch IoT system using AWS IoT Core, certificate-based authentication, and device shadow operations. The monitoring capabilities should be used responsibly and only for research purposes to develop local alternatives.
|
||||
@@ -0,0 +1,218 @@
|
||||
# MAC Address to Serial Number Mapping
|
||||
|
||||
**Understanding and troubleshooting device identification in SoundTouch service**
|
||||
|
||||
This guide explains how the SoundTouch service handles device identification through MAC address to serial number mapping, and how to troubleshoot related issues.
|
||||
|
||||
## 📋 **Overview**
|
||||
|
||||
The SoundTouch service uses two different identifiers for devices:
|
||||
|
||||
- **MAC Address** (`A81B6A536A98`) - Used in HTTP API requests and UPnP discovery
|
||||
- **Serial Number** (`I6332527703739342000020`) - Used for internal file storage
|
||||
|
||||
The service automatically maps between these identifiers so that API requests using MAC addresses can access files stored using serial numbers.
|
||||
|
||||
## 🔍 **How It Works**
|
||||
|
||||
### Request Flow
|
||||
```
|
||||
1. HTTP Request: GET /streaming/account/3230304/device/A81B6A536A98/presets
|
||||
2. MAC Resolution: A81B6A536A98 → I6332527703739342000020
|
||||
3. File Access: accounts/3230304/devices/I6332527703739342000020/Presets.xml
|
||||
```
|
||||
|
||||
### UPnP Discovery Integration
|
||||
The service extracts MAC addresses from UPnP device descriptions:
|
||||
|
||||
```xml
|
||||
<!-- From http://192.168.1.100:8091/XD/BO5EBO5E-F00D-F00D-FEED-A81B6A536A98.xml -->
|
||||
<root xmlns="urn:schemas-upnp-org:device-1-0">
|
||||
<device>
|
||||
<friendlyName>Sound Machinery</friendlyName>
|
||||
<modelName>SoundTouch 10</modelName>
|
||||
<serialNumber>A81B6A536A98</serialNumber> <!-- MAC address here -->
|
||||
</device>
|
||||
</root>
|
||||
```
|
||||
|
||||
## ⚙️ **Automatic Setup**
|
||||
|
||||
The mapping is created automatically when the service starts:
|
||||
|
||||
1. **Directory Scan**: Service scans `data/accounts/{account}/devices/{serial}/`
|
||||
2. **DeviceInfo.xml**: Reads MAC address from each device's info file
|
||||
3. **Mapping Creation**: Creates MAC → Serial mapping in memory
|
||||
4. **Normalization**: Handles different MAC address formats automatically
|
||||
|
||||
## 🛠️ **Supported MAC Address Formats**
|
||||
|
||||
The service handles all common MAC address formats automatically:
|
||||
|
||||
| Format | Example | Status |
|
||||
|-------------|---------------------|-------------|
|
||||
| Standard | `A81B6A536A98` | ✅ Supported |
|
||||
| Lowercase | `a81b6a536a98` | ✅ Supported |
|
||||
| With Colons | `A8:1B:6A:53:6A:98` | ✅ Supported |
|
||||
| With Dashes | `A8-1B-6A-53-6A-98` | ✅ Supported |
|
||||
| Mixed Case | `a81B6a536A98` | ✅ Supported |
|
||||
| With Spaces | ` A81B6A536A98 ` | ✅ Supported |
|
||||
|
||||
## 🔧 **Troubleshooting**
|
||||
|
||||
### Problem: API requests fail with "file not found" errors
|
||||
|
||||
**Symptoms:**
|
||||
```
|
||||
GET /streaming/account/3230304/device/A81B6A536A98/presets
|
||||
→ 500 Internal Server Error
|
||||
→ Log: "open .../devices/A81B6A536A98/Presets.xml: no such file or directory"
|
||||
```
|
||||
|
||||
**Diagnosis:**
|
||||
1. Check if mapping exists:
|
||||
```bash
|
||||
# Look for device directory
|
||||
ls data/accounts/3230304/devices/
|
||||
# Should show serial numbers like: I6332527703739342000020
|
||||
```
|
||||
|
||||
2. Check DeviceInfo.xml:
|
||||
```bash
|
||||
cat data/accounts/3230304/devices/I6332527703739342000020/DeviceInfo.xml
|
||||
# Look for <macAddress> field
|
||||
```
|
||||
|
||||
**Solutions:**
|
||||
|
||||
#### Solution 1: Restart the Service
|
||||
The mapping is created at startup. Simply restart:
|
||||
```bash
|
||||
sudo systemctl restart soundtouch-service
|
||||
```
|
||||
|
||||
#### Solution 2: Check DeviceInfo.xml Format
|
||||
Ensure the MAC address is present:
|
||||
```xml
|
||||
<info deviceID="I6332527703739342000020">
|
||||
<networkInfo type="SCM">
|
||||
<macAddress>A81B6A536A98</macAddress> <!-- Must be present -->
|
||||
<ipAddress>192.168.178.35</ipAddress>
|
||||
</networkInfo>
|
||||
</info>
|
||||
```
|
||||
|
||||
#### Solution 3: Manual Device Addition
|
||||
If the device was added manually, ensure proper structure:
|
||||
```bash
|
||||
# Create device directory using serial number
|
||||
mkdir -p data/accounts/3230304/devices/I6332527703739342000020
|
||||
|
||||
# Create DeviceInfo.xml with MAC address
|
||||
cat > data/accounts/3230304/devices/I6332527703739342000020/DeviceInfo.xml << EOF
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<info deviceID="I6332527703739342000020">
|
||||
<name>My SoundTouch Device</name>
|
||||
<networkInfo type="SCM">
|
||||
<macAddress>A81B6A536A98</macAddress>
|
||||
<ipAddress>192.168.1.100</ipAddress>
|
||||
</networkInfo>
|
||||
</info>
|
||||
EOF
|
||||
```
|
||||
|
||||
### Problem: UPnP discovery not creating mappings
|
||||
|
||||
**Check UPnP accessibility:**
|
||||
```bash
|
||||
# Test UPnP endpoint directly
|
||||
curl http://192.168.1.100:8091/XD/BO5EBO5E-F00D-F00D-FEED-A81B6A536A98.xml
|
||||
|
||||
# Should return XML with <serialNumber> field
|
||||
```
|
||||
|
||||
**Enable debug logging:**
|
||||
```bash
|
||||
# Check service logs for UPnP activity
|
||||
journalctl -u soundtouch-service -f | grep UPnP
|
||||
```
|
||||
|
||||
### Problem: Case or format mismatches
|
||||
|
||||
This should be handled automatically, but you can verify:
|
||||
|
||||
**Test different formats:**
|
||||
```bash
|
||||
# All of these should work the same:
|
||||
curl http://localhost:8000/streaming/account/3230304/device/A81B6A536A98/presets
|
||||
curl http://localhost:8000/streaming/account/3230304/device/a81b6a536a98/presets
|
||||
curl http://localhost:8000/streaming/account/3230304/device/A8:1B:6A:53:6A:98/presets
|
||||
```
|
||||
|
||||
## 📊 **Monitoring and Diagnostics**
|
||||
|
||||
### Check Current Mappings
|
||||
The service logs mapping creation at startup:
|
||||
```bash
|
||||
journalctl -u soundtouch-service | grep "MAC.*serial"
|
||||
```
|
||||
|
||||
### Verify File Structure
|
||||
Ensure proper directory organization:
|
||||
```
|
||||
data/
|
||||
└── accounts/
|
||||
└── 3230304/
|
||||
└── devices/
|
||||
└── I6332527703739342000020/ # Serial number directory
|
||||
├── DeviceInfo.xml # Contains MAC address
|
||||
├── Presets.xml
|
||||
└── Sources.xml
|
||||
```
|
||||
|
||||
## 🔗 **Related Documentation**
|
||||
|
||||
- [Device Initial Setup](DEVICE-INITIAL-SETUP.md) - Setting up new devices
|
||||
- [Troubleshooting Guide](TROUBLESHOOTING.md) - General troubleshooting steps
|
||||
- [SoundTouch Service](SOUNDTOUCH-SERVICE.md) - Service configuration and management
|
||||
|
||||
## 🏗️ **Technical Implementation**
|
||||
|
||||
For developers interested in the technical details:
|
||||
|
||||
### Normalization Algorithm
|
||||
```go
|
||||
// MAC addresses are normalized by:
|
||||
// 1. Removing spaces, colons, and dashes
|
||||
// 2. Converting to uppercase
|
||||
// Examples:
|
||||
// "a8:1b:6a:53:6a:98" → "A81B6A536A98"
|
||||
// "A8-1B-6A-53-6A-98" → "A81B6A536A98"
|
||||
```
|
||||
|
||||
### Lookup Process
|
||||
```go
|
||||
// 1. Try exact match first
|
||||
// 2. If not found, try normalized version
|
||||
// 3. Return serial number for file access
|
||||
```
|
||||
|
||||
### Performance
|
||||
- **Lookup Time**: O(1) - Hash map lookup
|
||||
- **Memory Usage**: ~40 bytes per device mapping
|
||||
- **Initialization**: Scans all devices once at startup
|
||||
|
||||
## 📝 **Best Practices**
|
||||
|
||||
1. **Use Discovery**: Let UPnP discovery create mappings automatically
|
||||
2. **Consistent Format**: Store MAC addresses consistently in DeviceInfo.xml
|
||||
3. **Service Restart**: Restart service after manual device additions
|
||||
4. **Monitoring**: Check logs for mapping creation during startup
|
||||
5. **Backup**: Keep DeviceInfo.xml files backed up
|
||||
|
||||
## ⚠️ **Known Limitations**
|
||||
|
||||
- Mappings are created only at service startup
|
||||
- Manual device additions require service restart
|
||||
- MAC addresses must be present in DeviceInfo.xml
|
||||
- No automatic cleanup of stale mappings (restart required)
|
||||
@@ -0,0 +1,418 @@
|
||||
# THIS IS A PLANNED TO BE THE MIGRATION GUIDE
|
||||
|
||||
> This migration guide is not finalized, yet.
|
||||
> We're using it as an orientation for the required implementation.
|
||||
|
||||
---
|
||||
|
||||
# Complete Migration Guide - From Bose Cloud to Local SoundTouch Service
|
||||
|
||||
## Overview
|
||||
|
||||
This guide will walk you through migrating your Bose SoundTouch speakers from Bose's cloud services to AfterTouch, your own local SoundTouch service. By the end of this process, your speakers will be completely independent of Bose's servers while retaining all their functionality.
|
||||
|
||||
> **💡 Why Migrate?** Bose announced the shutdown of their SoundTouch cloud services in May 2026. This migration ensures your speakers continue working indefinitely with enhanced local control and monitoring.
|
||||
|
||||
## What You'll Need
|
||||
|
||||
### Hardware Requirements
|
||||
- **Raspberry Pi 4 or similar** (minimum: Raspberry Pi Zero 2W)
|
||||
- **MicroSD card** (16GB or larger)
|
||||
- **USB drive** (for device preparation)
|
||||
- **Network connection** for your Raspberry Pi
|
||||
|
||||
### Before You Start
|
||||
- **List all your SoundTouch devices** and their current locations
|
||||
- **Note your current presets and favorites** (they will be preserved)
|
||||
- **Ensure devices are on the same network** as your future SoundTouch service
|
||||
- **Basic computer skills** (following instructions, using a web browser)
|
||||
|
||||
### Time Estimate
|
||||
- **Setup**: 30-60 minutes for the service installation
|
||||
- **Per Device**: 10-15 minutes for each speaker migration
|
||||
- **Total**: 1-3 hours depending on number of devices
|
||||
|
||||
## Step 1: Install SoundTouch Service
|
||||
|
||||
### Option A: Raspberry Pi Installation (Recommended)
|
||||
|
||||
#### 1.1 Prepare Your Raspberry Pi
|
||||
|
||||
1. **Flash Raspberry Pi OS** to your SD card using Raspberry Pi Imager (see the raspberrypi.com documentation)
|
||||
2. **Enable SSH** during imaging or create an empty `ssh` file on the boot partition
|
||||
3. **Boot your Pi** and connect it to your network
|
||||
4. **Find your Pi's IP address** (check your router or use `ping raspberrypi.local`)
|
||||
|
||||
#### 1.2 Install SoundTouch Service
|
||||
|
||||
Connect to your Pi via SSH and run:
|
||||
|
||||
```bash
|
||||
# Download and install
|
||||
curl -sSL https://github.com/gesellix/Bose-SoundTouch/releases/latest/download/install.sh | bash
|
||||
|
||||
# Start the service
|
||||
sudo systemctl enable soundtouch-service
|
||||
sudo systemctl start soundtouch-service
|
||||
```
|
||||
|
||||
#### 1.3 Verify Installation
|
||||
|
||||
1. Open your web browser
|
||||
2. Go to `http://[PI_IP_ADDRESS]:8000` (replace with your Pi's IP)
|
||||
3. You should see the **SoundTouch Service Dashboard**
|
||||
|
||||

|
||||
*Example: SoundTouch Service main dashboard*
|
||||
|
||||
### Option B: Docker Installation
|
||||
|
||||
If you prefer Docker, run:
|
||||
|
||||
```bash
|
||||
docker run -d \
|
||||
--name soundtouch-service \
|
||||
--restart unless-stopped \
|
||||
-p 8000:8000 \
|
||||
-p 8443:8443 \
|
||||
-v soundtouch-data:/data \
|
||||
gesellix/soundtouch-service:latest
|
||||
```
|
||||
|
||||
## Step 2: Create Your Account
|
||||
|
||||
### 2.1 Initial Setup
|
||||
|
||||
1. **Open the dashboard** at `http://[SERVICE_IP]:8000`
|
||||
2. Click **"Create New Account"**
|
||||
3. **Fill in your details**:
|
||||
- Account Name: `My Home Audio`
|
||||
- Email: `your@email.com` (optional, for notifications)
|
||||
- Migration Strategy: `Gradual` (recommended)
|
||||
|
||||

|
||||
*Example: Account creation form*
|
||||
|
||||
### 2.2 Account Configuration
|
||||
|
||||
After creation, you'll see your **Account Dashboard**:
|
||||
- **Account ID**: Unique identifier (e.g., `acc_home_audio_001`)
|
||||
- **Status**: `Active - Ready for Migration`
|
||||
- **Device Count**: Initially 0
|
||||
- **Migration Status**: `Prepared`
|
||||
|
||||

|
||||
*Example: Fresh account dashboard ready for device migration*
|
||||
|
||||
### 2.3 Initial Settings
|
||||
|
||||
Once your account is created, configure the global settings:
|
||||
1. **Settings**:
|
||||
- Check **Target Domain**: Ensure it's reachable from the speaker (e.g., `soundtouch.fritz.box`).
|
||||
- **DNS Discovery**: Enable DNS discovery on port `:53`. This is crucial for the DNS hook migration method.
|
||||
2. **Devices**:
|
||||
- Go to the **"Device Discovery"** tab.
|
||||
- Click **"Scan Network"** or manually add a speaker via IP address.
|
||||
- Your devices should appear with **SSH Status**: `Enabled`.
|
||||
|
||||

|
||||
*Example: Discovered devices with remote access enabled*
|
||||
|
||||
## Step 3: Prepare Your Devices
|
||||
|
||||
> **⚠️ Important**: This step temporarily enables SSH access on your speakers. SSH will be automatically disabled after migration unless you choose to keep it enabled.
|
||||
|
||||
### 3.1 Enable Remote Services
|
||||
|
||||
For each SoundTouch device:
|
||||
|
||||
1. **Prepare a USB drive**:
|
||||
- Format as FAT32
|
||||
- Create an empty file named `remote_services` (no extension)
|
||||
- (Optional) Firmware update/reset, see [Bose SoundTouch USB Update](https://downloads.bose.com/ced/soundtouch/soundtouch_usb/index.html)
|
||||
|
||||
2. **Insert USB drive** into your SoundTouch speaker
|
||||
3. **Power cycle** the device (unplug for 10 seconds, then reconnect)
|
||||
|
||||

|
||||
*Example: USB drive setup for enabling remote services*
|
||||
|
||||
## Step 4: Discover and Register Devices
|
||||
|
||||
### 4.1 Automatic Discovery
|
||||
|
||||
The service automatically scans for SoundTouch devices every 5 minutes. To trigger immediate discovery:
|
||||
|
||||
1. **Dashboard** → **"Devices"** → **"Discover Devices"**
|
||||
2. **Wait 30-60 seconds** for scan completion
|
||||
3. **Review discovered devices** in the list
|
||||
|
||||
### 4.2 Register Devices to Your Account
|
||||
|
||||
For each discovered device:
|
||||
|
||||
1. **Click device name** in the discovery list
|
||||
2. **Verify device information**:
|
||||
- Name: `Living Room Speaker`
|
||||
- Model: `SoundTouch 30`
|
||||
- MAC Address: `A8:1B:6A:53:6A:98`
|
||||
- IP Address: `192.168.1.100`
|
||||
- Status: `Discovered - Ready for Registration`
|
||||
|
||||
3. **Click "Register to Account"**
|
||||
4. **Choose registration type**:
|
||||
- **Fresh Setup**: For new or factory-reset devices
|
||||
- **Migrate from Bose**: For devices with existing Bose account (recommended)
|
||||
|
||||

|
||||
*Example: Device registration dialog with migration options*
|
||||
|
||||
### 4.3 Device Registration Results
|
||||
|
||||
After registration, you'll see:
|
||||
- **Device Status**: `Registered - Active`
|
||||
- **Account Association**: Your account name
|
||||
- **Lifecycle State**: `Active`
|
||||
- **Data Sources**: `Mirror Primary` (initially uses Bose, falls back to local)
|
||||
|
||||
## Step 5: Migrate Individual Devices
|
||||
|
||||
### 5.1 Step 3: Data Sync
|
||||
|
||||
1. **Dashboard** → **"Devices"** → Select your device
|
||||
2. Click **"Data Sync"**
|
||||
3. This fetches configuration (presets, recents, sources) from the speaker to the SoundTouch service.
|
||||
|
||||
### 5.2 Step 4: Migration
|
||||
|
||||
Once data is synced, proceed to the migration tab for the device:
|
||||
|
||||
1. **Backup XML**: Create an off-device backup of the current configuration.
|
||||
2. **Enable Persistent Remote Service**: This ensures SSH remains available after reboots.
|
||||
- *Note*: If you see `'rw: command not found'`, you can safely ignore it.
|
||||
3. **CA Certificate Configuration**:
|
||||
- **Test with explicit CA**: Verify the speaker can communicate using the local CA.
|
||||
- **Trust CA now**: Inject the local Root CA into the speaker's trust store.
|
||||
- **Test with shared trust store**: Verify general HTTPS communication.
|
||||
4. **Migration Method**:
|
||||
- Select **"Redirect via DNS hook"**.
|
||||
- **Test DNS Redirection**: Ensure the speaker correctly resolves the service domain.
|
||||
5. **Confirm Migration**: Apply the final changes to the speaker.
|
||||
|
||||
#### Example Migration Output:
|
||||
```text
|
||||
Successfully created off-device backup of current configuration.
|
||||
Pre-flight: Write access verified.
|
||||
Resolved soundtouch.fritz.box to 192.168.1.100
|
||||
Uploaded /mnt/nv/soundtouch-service/aftertouch.resolv.conf
|
||||
/mnt/nv/rc.local already contains Aftertouch hook logic
|
||||
(rw || mount -o remount,rw /): sh: rw: command not found
|
||||
|
||||
cp /etc/udhcpc.d/50default /etc/udhcpc.d/50default.original:
|
||||
Applied patch to /etc/udhcpc.d/50default
|
||||
Verified patch on /etc/udhcpc.d/50default
|
||||
cp /opt/Bose/udhcpc.script /opt/Bose/udhcpc.script.original:
|
||||
Applied patch to /opt/Bose/udhcpc.script
|
||||
Verified patch on /opt/Bose/udhcpc.script
|
||||
CA certificate already trusted, skipping injection
|
||||
```
|
||||
|
||||
## Step 7: Complete Account Migration
|
||||
|
||||
### 7.1 Migrate All Devices
|
||||
|
||||
Repeat the migration process for each of your SoundTouch devices. You can migrate multiple devices simultaneously, but we recommend doing 1-2 at a time to monitor progress.
|
||||
|
||||
**Migration Dashboard** shows overall progress:
|
||||
- **Devices Migrated**: `2 of 4 completed`
|
||||
- **Currently Migrating**: `Living Room Speaker, Kitchen Speaker`
|
||||
- **Pending Migration**: `Bedroom Speaker, Office Speaker`
|
||||
- **Estimated Completion**: `3 days remaining`
|
||||
|
||||

|
||||
*Example: Account-wide migration progress*
|
||||
|
||||
### 7.2 Verify Complete Migration
|
||||
|
||||
When all devices are migrated:
|
||||
|
||||
1. **Account Status**: `Active - Fully Migrated`
|
||||
2. **Bose Dependency**: `None`
|
||||
3. **Local Control**: `100%`
|
||||
4. **Device Health**: All devices show `Healthy - Local Only`
|
||||
|
||||

|
||||
*Example: Completed migration dashboard*
|
||||
|
||||
## Step 8: Post-Migration Tasks
|
||||
|
||||
1. **Remove USB stick** from the speaker.
|
||||
2. **Reboot** the device to apply all changes.
|
||||
|
||||
### 8.1 Disable Remote Services (Optional)
|
||||
|
||||
For enhanced security, you can disable SSH on migrated devices. However, keeping it enabled allows for easier future maintenance or reverts.
|
||||
|
||||
### 8.2 Configure Backups
|
||||
|
||||
Set up automatic backups of your device configurations:
|
||||
|
||||
1. **Dashboard** → **"Settings"** → **"Backup"**
|
||||
2. **Enable Automatic Backups**: ✅
|
||||
3. **Backup Schedule**: `Daily at 2 AM`
|
||||
4. **Retention**: `Keep 30 days`
|
||||
5. **Export Location**: `/data/backups` or external storage
|
||||
|
||||

|
||||
*Example: Backup configuration settings*
|
||||
|
||||
### 8.3 Set Up Monitoring Alerts (Optional)
|
||||
|
||||
Configure notifications for important events:
|
||||
|
||||
1. **Dashboard** → **"Settings"** → **"Notifications"**
|
||||
2. **Email Notifications**: Enter your email
|
||||
3. **Alert Types**:
|
||||
- ✅ Device goes offline
|
||||
- ✅ Migration failures
|
||||
- ✅ Service errors
|
||||
- ✅ Daily health summary
|
||||
|
||||
## Troubleshooting Common Issues
|
||||
|
||||
### Device Not Discovered
|
||||
|
||||
**Problem**: Device doesn't appear in discovery scan
|
||||
|
||||
**Solutions**:
|
||||
1. **Check network**: Ensure device and service are on same network
|
||||
2. **Verify USB setup**: Confirm `remote_services` file was processed
|
||||
3. **Power cycle**: Unplug device for 30 seconds, reconnect
|
||||
4. **Manual add**: Dashboard → "Devices" → "Add Manually" with IP address
|
||||
|
||||
### Migration Stuck
|
||||
|
||||
**Problem**: Device stuck in "Migrating" status
|
||||
|
||||
**Solutions**:
|
||||
1. **Check device health**: Dashboard → Device → "Health Status"
|
||||
2. **Review logs**: Dashboard → Device → "View Logs"
|
||||
3. **Restart migration**: Device → "Migration" → "Restart Process"
|
||||
4. **Rollback**: Device → "Migration" → "Rollback to Bose"
|
||||
|
||||
### Presets Not Working
|
||||
|
||||
**Problem**: Saved presets don't work after migration
|
||||
|
||||
**Solutions**:
|
||||
1. **Verify sources**: Check configured sources are still available
|
||||
2. **Re-authenticate**: Re-login to music services (Spotify, etc.)
|
||||
3. **Rebuild presets**: Dashboard → Device → "Presets" → "Rebuild from Backup"
|
||||
|
||||
### Service Unreachable
|
||||
|
||||
**Problem**: Cannot access SoundTouch Service dashboard
|
||||
|
||||
**Solutions**:
|
||||
1. **Check service status**: `sudo systemctl status soundtouch-service`
|
||||
2. **Restart service**: `sudo systemctl restart soundtouch-service`
|
||||
3. **Check network**: Verify Pi is connected and accessible
|
||||
4. **Check ports**: Ensure ports 8000 and 8443 are not blocked
|
||||
|
||||
## Advanced Features
|
||||
|
||||
### Multi-Zone Management
|
||||
|
||||
After migration, your multi-zone setups work seamlessly:
|
||||
|
||||
1. **Dashboard** → **"Zones"**
|
||||
2. **Create Zone**: Select primary device and slaves
|
||||
3. **Zone Control**: Play, pause, volume control for entire zone
|
||||
4. **Individual Control**: Override individual speakers in zone
|
||||
|
||||
### Custom Sources
|
||||
|
||||
Add custom streaming sources:
|
||||
|
||||
1. **Dashboard** → **"Sources"** → **"Add Custom"**
|
||||
2. **Configure**:
|
||||
- Name: `Local Radio Station`
|
||||
- Stream URL: `http://stream.example.com:8000`
|
||||
- Image URL: `http://example.com/logo.png`
|
||||
3. **Assign to devices**: Select which devices can access this source
|
||||
|
||||
### API Access
|
||||
|
||||
For developers and advanced users:
|
||||
|
||||
- **REST API**: `http://[SERVICE_IP]:8000/api/v1/`
|
||||
- **Documentation**: `http://[SERVICE_IP]:8000/docs`
|
||||
- **WebSocket Events**: Real-time device status updates
|
||||
- **Export Data**: JSON/XML export of all device configurations
|
||||
|
||||
## Maintenance and Monitoring
|
||||
|
||||
### Daily Monitoring
|
||||
|
||||
Check your **Dashboard Summary**:
|
||||
- **All Devices Online**: ✅ Green indicators
|
||||
- **Response Times**: < 100ms average
|
||||
- **Error Rate**: < 1%
|
||||
- **Storage Usage**: Monitor disk space
|
||||
|
||||
### Weekly Tasks
|
||||
|
||||
1. **Review Health Reports**: Check weekly device health summaries
|
||||
2. **Update Service**: Check for SoundTouch service updates
|
||||
3. **Backup Verification**: Ensure backups are completing successfully
|
||||
4. **Log Review**: Check for any recurring issues or warnings
|
||||
|
||||
### Monthly Tasks
|
||||
|
||||
1. **Full System Backup**: Export complete account and device data
|
||||
2. **Performance Review**: Analyze response times and error patterns
|
||||
3. **Security Update**: Update Raspberry Pi OS and service
|
||||
4. **Capacity Planning**: Monitor storage and consider expansion
|
||||
|
||||
## Getting Help
|
||||
|
||||
### Documentation Resources
|
||||
|
||||
- **Technical Reference**: `/docs/reference/` - Detailed API and configuration docs
|
||||
- **Troubleshooting Guide**: `/docs/guides/TROUBLESHOOTING.md` - Common issues and solutions
|
||||
- **Community Forum**: GitHub Discussions for community support
|
||||
|
||||
### Diagnostic Information
|
||||
|
||||
When seeking help, provide:
|
||||
|
||||
1. **System Information**: Dashboard → "System" → "Download Diagnostic Report"
|
||||
2. **Device Logs**: Dashboard → Device → "Export Logs"
|
||||
3. **Migration History**: Dashboard → "Migration" → "Export Timeline"
|
||||
4. **Current Status**: Screenshot of main dashboard
|
||||
|
||||
### Support Channels
|
||||
|
||||
- **GitHub Issues**: Technical bugs and feature requests
|
||||
- **Community Discussions**: User questions and experiences
|
||||
- **Documentation Updates**: Corrections and improvements
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
Congratulations! 🎉 You've successfully migrated your SoundTouch speakers to local control. Your devices are now:
|
||||
|
||||
- ✅ **Independent** of Bose cloud services
|
||||
- ✅ **Fully functional** with all original features preserved
|
||||
- ✅ **Enhanced** with better monitoring and control
|
||||
- ✅ **Future-proof** against service shutdowns
|
||||
|
||||
**What's Next?**
|
||||
|
||||
- **Enjoy your music** with enhanced local control
|
||||
- **Monitor your system** through the dashboard
|
||||
- **Share your experience** with the community
|
||||
- **Explore advanced features** as you become more comfortable
|
||||
|
||||
Your SoundTouch speakers will now continue working indefinitely, regardless of external service availability. Welcome to true audio independence! 🔊
|
||||
@@ -0,0 +1,44 @@
|
||||
### Professional Migration & Safety Guide
|
||||
|
||||
Starting a migration on real hardware requires a "Safety First" approach. This guide outlines the safety features implemented in the `soundtouch-service` and provides a checklist for a successful migration.
|
||||
|
||||
#### 🛠 Technical Safety Enhancements
|
||||
|
||||
The following features are built into the `soundtouch-service` to ensure stability and easy rollbacks:
|
||||
|
||||
1. **Off-Device Backups**: Before any migration starts, the service automatically fetches the original `SoundTouchSdkPrivateCfg.xml` and `/etc/hosts` from your speaker and saves them locally in your `data/default/devices/<SERIAL>/` directory. This ensures you have a recovery path even if the speaker's filesystem becomes inaccessible.
|
||||
2. **Pre-flight Write Verification**: The migration process includes a mandatory check for SSH write access (`rw`) before attempting any modifications. This prevents "half-baked" migrations where a script might fail halfway through due to a read-only filesystem.
|
||||
3. **Automatic Safety on Sync**: Running a "Sync" in the Web UI or CLI automatically triggers an off-device backup, making it the perfect first step for any new device discovery.
|
||||
|
||||
#### 📋 Professional Migration Checklist
|
||||
|
||||
Before you proceed with the actual migration, follow these steps:
|
||||
|
||||
1. **Enable SSH Access (Prerequisite)**: This toolkit requires SSH access to your speakers, which is not enabled by default.
|
||||
- Create an empty file named `remote_services` on a USB stick.
|
||||
- Insert the USB stick into the SoundTouch speaker's **SERVICE** port.
|
||||
- Reboot the speaker (unplug and replug).
|
||||
- The speaker will now allow SSH connections as `root` with no password.
|
||||
- **Verify**: Run `ssh -oHostKeyAlgorithms=+ssh-rsa root@<SPEAKER-IP>` to confirm access. (Note: older devices may require enabling `ssh-rsa` support).
|
||||
2. **Network Isolation (Optional but Recommended)**: Ensure the device is on a stable wired connection if possible, or a dedicated 2.4GHz SSID to avoid drops during SSH operations.
|
||||
3. **Initial Discovery & Sync**:
|
||||
- Run `soundtouch-cli discover devices` to ensure connectivity.
|
||||
- Use the Web UI or CLI to "Sync" the device. This will automatically backup your presets and system configuration files to your local server.
|
||||
4. **Validate SSH Access**: Confirm the device responds to SSH without a password.
|
||||
- In the Web UI **Migration** tab, select your speaker and verify that the "SSH Connection" status shows ✅ Success.
|
||||
- This toolkit automatically handles the necessary SSH parameters (ciphers and key exchanges) required by older Bose firmware.
|
||||
5. **Migration Methods**:
|
||||
- **XML Migration (Default)**: Less invasive, only changes the application config. Best for simple redirection.
|
||||
- **Hosts Migration**: Modifies `/etc/hosts` on the device. Good for system-wide redirection of specific domains.
|
||||
- **ResolvConf Migration**: Points the device to the AfterTouch DNS server. Best for discovering unknown Bose endpoints and dynamic interception. **Note**: This method requires the DNS Discovery Server to be running on port 53. The service includes a pre-flight check to ensure the server is properly bound before allowing this migration.
|
||||
6. **Monitor Logs**: Run the `soundtouch-service` with `DEBUG` or `INFO` logging to see the step-by-step progress of the migration.
|
||||
|
||||
#### 🔄 Rollback Strategy
|
||||
|
||||
If something goes wrong or you want to return to the original Bose cloud services:
|
||||
|
||||
* **Standard Revert**: Use the "Revert Migration" button in the Web UI or the corresponding CLI command. This restores the `.original` files created on the device.
|
||||
* **Emergency Recovery**: If the device is unreachable via the UI but SSH still works, you can manually restore the files from your local `data/` directory using `scp` or the backups created on-device (`.original`).
|
||||
* **Factory Reset**: As a last resort, Bose SoundTouch devices can be factory reset (usually by holding '1' and 'Volume Down' while plugging in). This will wipe all settings and return the device to the stock firmware configuration (the firmware itself remains at the current version, but configurations are reset).
|
||||
|
||||
By using the built-in off-device backups and pre-flight checks, the risk of "bricking" or losing configuration during the transition is significantly reduced.
|
||||
@@ -0,0 +1,764 @@
|
||||
# MQTT Integration Design for SoundTouch Service
|
||||
|
||||
## Overview
|
||||
|
||||
This document outlines the design for integrating MQTT support into the existing SoundTouch service to simulate AWS IoT Core functionality. The integration will provide real-time device communication, shadow state management, and prepare for the AWS IoT service shutdown in May 2026.
|
||||
|
||||
## Current Architecture Analysis
|
||||
|
||||
### Existing Service Structure
|
||||
```
|
||||
Bose-SoundTouch/
|
||||
├── cmd/soundtouch-service/main.go # Main service entry point
|
||||
├── pkg/
|
||||
│ ├── client/ # HTTP client for devices
|
||||
│ ├── config/ # Configuration management
|
||||
│ ├── discovery/ # Device discovery (UPnP, mDNS)
|
||||
│ ├── models/ # Data structures
|
||||
│ └── service/
|
||||
│ ├── handlers/ # HTTP request handlers
|
||||
│ │ └── server.go # Main server struct
|
||||
│ ├── datastore/ # Data persistence
|
||||
│ ├── proxy/ # HTTP proxying
|
||||
│ └── [other services]
|
||||
```
|
||||
|
||||
### Key Components
|
||||
- **Server Struct**: Central HTTP handler in `pkg/service/handlers/server.go`
|
||||
- **Discovery Service**: UPnP/mDNS device discovery in `pkg/discovery/`
|
||||
- **DataStore**: Device state persistence in `pkg/service/datastore/`
|
||||
- **Device Models**: Data structures in `pkg/models/`
|
||||
|
||||
## MQTT Integration Design
|
||||
|
||||
### 1. New Package Structure
|
||||
|
||||
```
|
||||
pkg/service/mqtt/
|
||||
├── broker.go # MQTT broker implementation
|
||||
├── shadow.go # AWS IoT Shadow simulation
|
||||
├── auth.go # Certificate-based authentication
|
||||
├── topics.go # Topic routing and handlers
|
||||
├── bridge.go # HTTP ↔ MQTT state bridging
|
||||
├── config.go # MQTT configuration
|
||||
└── client.go # MQTT client utilities
|
||||
```
|
||||
|
||||
### 2. Core Components
|
||||
|
||||
#### A. MQTT Broker (`pkg/service/mqtt/broker.go`)
|
||||
```go
|
||||
package mqtt
|
||||
|
||||
import (
|
||||
"crypto/tls"
|
||||
"fmt"
|
||||
"log"
|
||||
"sync"
|
||||
|
||||
"github.com/mochi-co/mqtt/v2"
|
||||
"github.com/mochi-co/mqtt/v2/hooks/auth"
|
||||
"github.com/mochi-co/mqtt/v2/listeners"
|
||||
)
|
||||
|
||||
type Broker struct {
|
||||
server *mqtt.Server
|
||||
shadowStore *ShadowStore
|
||||
bridge *HTTPBridge
|
||||
authHook *AuthHook
|
||||
config *Config
|
||||
running bool
|
||||
mu sync.RWMutex
|
||||
}
|
||||
|
||||
type Config struct {
|
||||
Enabled bool `json:"enabled"`
|
||||
Port int `json:"port"`
|
||||
TLSEnabled bool `json:"tls_enabled"`
|
||||
CertFile string `json:"cert_file"`
|
||||
KeyFile string `json:"key_file"`
|
||||
DeviceCertPath string `json:"device_cert_path"`
|
||||
ShadowPersist bool `json:"shadow_persist"`
|
||||
}
|
||||
|
||||
func NewBroker(config *Config) (*Broker, error) {
|
||||
server := mqtt.New(nil)
|
||||
|
||||
shadowStore := NewShadowStore()
|
||||
authHook := NewAuthHook(config.DeviceCertPath)
|
||||
|
||||
return &Broker{
|
||||
server: server,
|
||||
shadowStore: shadowStore,
|
||||
authHook: authHook,
|
||||
config: config,
|
||||
}, nil
|
||||
}
|
||||
|
||||
func (b *Broker) Start() error {
|
||||
// Add TLS listener
|
||||
tlsConfig := &tls.Config{
|
||||
Certificates: []tls.Certificate{b.loadServerCert()},
|
||||
ClientAuth: tls.RequireAndVerifyClientCert,
|
||||
ClientCAs: b.loadDeviceCAs(),
|
||||
}
|
||||
|
||||
tcp := listeners.NewTCP("mqtt-tls", fmt.Sprintf(":%d", b.config.Port), &listeners.Config{
|
||||
TLSConfig: tlsConfig,
|
||||
})
|
||||
|
||||
b.server.AddListener(tcp)
|
||||
|
||||
// Add hooks
|
||||
b.server.AddHook(b.authHook, nil)
|
||||
b.server.AddHook(NewShadowHook(b.shadowStore), nil)
|
||||
|
||||
return b.server.Serve()
|
||||
}
|
||||
```
|
||||
|
||||
#### B. Shadow State Management (`pkg/service/mqtt/shadow.go`)
|
||||
```go
|
||||
package mqtt
|
||||
|
||||
import (
|
||||
"encoding/json"
|
||||
"fmt"
|
||||
"sync"
|
||||
"time"
|
||||
)
|
||||
|
||||
type ShadowStore struct {
|
||||
shadows map[string]*DeviceShadow
|
||||
mu sync.RWMutex
|
||||
}
|
||||
|
||||
type DeviceShadow struct {
|
||||
State struct {
|
||||
Desired map[string]interface{} `json:"desired"`
|
||||
Reported map[string]interface{} `json:"reported"`
|
||||
Delta map[string]interface{} `json:"delta,omitempty"`
|
||||
} `json:"state"`
|
||||
Version int `json:"version"`
|
||||
Timestamp int64 `json:"timestamp"`
|
||||
ClientToken string `json:"clientToken,omitempty"`
|
||||
}
|
||||
|
||||
func NewShadowStore() *ShadowStore {
|
||||
return &ShadowStore{
|
||||
shadows: make(map[string]*DeviceShadow),
|
||||
}
|
||||
}
|
||||
|
||||
func (s *ShadowStore) UpdateShadow(clientID string, payload []byte) (*DeviceShadow, error) {
|
||||
s.mu.Lock()
|
||||
defer s.mu.Unlock()
|
||||
|
||||
var update DeviceShadow
|
||||
if err := json.Unmarshal(payload, &update); err != nil {
|
||||
return nil, err
|
||||
}
|
||||
|
||||
shadow := s.shadows[clientID]
|
||||
if shadow == nil {
|
||||
shadow = &DeviceShadow{
|
||||
State: struct {
|
||||
Desired map[string]interface{} `json:"desired"`
|
||||
Reported map[string]interface{} `json:"reported"`
|
||||
Delta map[string]interface{} `json:"delta,omitempty"`
|
||||
}{
|
||||
Desired: make(map[string]interface{}),
|
||||
Reported: make(map[string]interface{}),
|
||||
Delta: make(map[string]interface{}),
|
||||
},
|
||||
}
|
||||
s.shadows[clientID] = shadow
|
||||
}
|
||||
|
||||
// Update reported state
|
||||
if update.State.Reported != nil {
|
||||
for key, value := range update.State.Reported {
|
||||
shadow.State.Reported[key] = value
|
||||
}
|
||||
}
|
||||
|
||||
// Update desired state
|
||||
if update.State.Desired != nil {
|
||||
for key, value := range update.State.Desired {
|
||||
shadow.State.Desired[key] = value
|
||||
}
|
||||
}
|
||||
|
||||
// Calculate delta
|
||||
shadow.calculateDelta()
|
||||
shadow.Version++
|
||||
shadow.Timestamp = time.Now().Unix()
|
||||
shadow.ClientToken = update.ClientToken
|
||||
|
||||
return shadow, nil
|
||||
}
|
||||
|
||||
func (s *DeviceShadow) calculateDelta() {
|
||||
s.State.Delta = make(map[string]interface{})
|
||||
|
||||
for key, desired := range s.State.Desired {
|
||||
if reported, exists := s.State.Reported[key]; !exists || reported != desired {
|
||||
s.State.Delta[key] = desired
|
||||
}
|
||||
}
|
||||
|
||||
if len(s.State.Delta) == 0 {
|
||||
s.State.Delta = nil
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### C. HTTP ↔ MQTT Bridge (`pkg/service/mqtt/bridge.go`)
|
||||
```go
|
||||
package mqtt
|
||||
|
||||
import (
|
||||
"encoding/json"
|
||||
"fmt"
|
||||
"log"
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/models"
|
||||
"github.com/gesellix/bose-soundtouch/pkg/service/datastore"
|
||||
)
|
||||
|
||||
type HTTPBridge struct {
|
||||
shadowStore *ShadowStore
|
||||
dataStore *datastore.DataStore
|
||||
deviceMap map[string]string // clientID -> deviceID mapping
|
||||
}
|
||||
|
||||
func NewHTTPBridge(shadowStore *ShadowStore, dataStore *datastore.DataStore) *HTTPBridge {
|
||||
return &HTTPBridge{
|
||||
shadowStore: shadowStore,
|
||||
dataStore: dataStore,
|
||||
deviceMap: make(map[string]string),
|
||||
}
|
||||
}
|
||||
|
||||
// ShadowToHTTP converts MQTT shadow updates to HTTP API calls
|
||||
func (b *HTTPBridge) ShadowToHTTP(clientID string, shadow *DeviceShadow) error {
|
||||
deviceID, exists := b.deviceMap[clientID]
|
||||
if !exists {
|
||||
log.Printf("Unknown device clientID: %s", clientID)
|
||||
return fmt.Errorf("unknown device: %s", clientID)
|
||||
}
|
||||
|
||||
// Handle power state changes
|
||||
if powerState, ok := shadow.State.Reported["powerState"].(string); ok {
|
||||
if err := b.updateDevicePower(deviceID, powerState == "ON"); err != nil {
|
||||
return fmt.Errorf("power update failed: %w", err)
|
||||
}
|
||||
}
|
||||
|
||||
// Handle volume changes
|
||||
if volume, ok := shadow.State.Reported["volume"].(float64); ok {
|
||||
if err := b.updateDeviceVolume(deviceID, int(volume)); err != nil {
|
||||
return fmt.Errorf("volume update failed: %w", err)
|
||||
}
|
||||
}
|
||||
|
||||
// Handle source changes
|
||||
if source, ok := shadow.State.Reported["source"].(string); ok {
|
||||
if err := b.updateDeviceSource(deviceID, source); err != nil {
|
||||
return fmt.Errorf("source update failed: %w", err)
|
||||
}
|
||||
}
|
||||
|
||||
return nil
|
||||
}
|
||||
|
||||
// HTTPToShadow converts HTTP device state to MQTT shadow updates
|
||||
func (b *HTTPBridge) HTTPToShadow(deviceID string, deviceInfo *models.DeviceInfo) error {
|
||||
clientID, exists := b.getClientIDForDevice(deviceID)
|
||||
if !exists {
|
||||
return nil // Device not connected via MQTT
|
||||
}
|
||||
|
||||
// Create shadow state from device info
|
||||
shadowState := map[string]interface{}{
|
||||
"deviceState": "CONNECTED",
|
||||
"deviceID": deviceInfo.DeviceID,
|
||||
"name": deviceInfo.Name,
|
||||
"type": deviceInfo.Type,
|
||||
}
|
||||
|
||||
// Add additional state if available
|
||||
if status := b.getDeviceStatus(deviceID); status != nil {
|
||||
shadowState["powerState"] = status.PowerState
|
||||
shadowState["volume"] = status.Volume
|
||||
shadowState["source"] = status.Source
|
||||
}
|
||||
|
||||
// Update shadow
|
||||
shadowUpdate := DeviceShadow{
|
||||
State: struct {
|
||||
Desired map[string]interface{} `json:"desired"`
|
||||
Reported map[string]interface{} `json:"reported"`
|
||||
Delta map[string]interface{} `json:"delta,omitempty"`
|
||||
}{
|
||||
Reported: shadowState,
|
||||
},
|
||||
}
|
||||
|
||||
payload, _ := json.Marshal(shadowUpdate)
|
||||
_, err := b.shadowStore.UpdateShadow(clientID, payload)
|
||||
return err
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Integration with Existing Server
|
||||
|
||||
#### A. Extend Server Struct (`pkg/service/handlers/server.go`)
|
||||
```go
|
||||
// Add to existing Server struct
|
||||
type Server struct {
|
||||
// ... existing fields ...
|
||||
|
||||
// New MQTT fields
|
||||
mqttBroker *mqtt.Broker
|
||||
mqttEnabled bool
|
||||
mqttConfig *mqtt.Config
|
||||
deviceClientIDs map[string]string // deviceID -> clientID mapping
|
||||
}
|
||||
|
||||
// New initialization method
|
||||
func (s *Server) initMQTTBroker(config *mqtt.Config) error {
|
||||
if !config.Enabled {
|
||||
return nil
|
||||
}
|
||||
|
||||
broker, err := mqtt.NewBroker(config)
|
||||
if err != nil {
|
||||
return fmt.Errorf("failed to create MQTT broker: %w", err)
|
||||
}
|
||||
|
||||
// Set up HTTP ↔ MQTT bridge
|
||||
bridge := mqtt.NewHTTPBridge(broker.ShadowStore(), s.ds)
|
||||
broker.SetBridge(bridge)
|
||||
|
||||
s.mqttBroker = broker
|
||||
s.mqttEnabled = true
|
||||
s.mqttConfig = config
|
||||
s.deviceClientIDs = make(map[string]string)
|
||||
|
||||
return nil
|
||||
}
|
||||
|
||||
// Start MQTT broker alongside HTTP server
|
||||
func (s *Server) StartMQTT() error {
|
||||
if !s.mqttEnabled {
|
||||
return nil
|
||||
}
|
||||
|
||||
go func() {
|
||||
if err := s.mqttBroker.Start(); err != nil {
|
||||
log.Printf("MQTT broker error: %v", err)
|
||||
}
|
||||
}()
|
||||
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
#### B. Configuration Integration (`cmd/soundtouch-service/main.go`)
|
||||
```go
|
||||
// Add to serviceConfig struct
|
||||
type serviceConfig struct {
|
||||
// ... existing fields ...
|
||||
|
||||
// New MQTT configuration fields
|
||||
mqttEnabled bool `mapstructure:"mqtt_enabled"`
|
||||
mqttPort int `mapstructure:"mqtt_port"`
|
||||
mqttTLSCert string `mapstructure:"mqtt_tls_cert"`
|
||||
mqttTLSKey string `mapstructure:"mqtt_tls_key"`
|
||||
mqttDeviceCertPath string `mapstructure:"mqtt_device_cert_path"`
|
||||
mqttShadowPersist bool `mapstructure:"mqtt_shadow_persist"`
|
||||
}
|
||||
|
||||
// Update main function to initialize MQTT
|
||||
func main() {
|
||||
// ... existing initialization ...
|
||||
|
||||
// Initialize MQTT if enabled
|
||||
if cfg.mqttEnabled {
|
||||
mqttConfig := &mqtt.Config{
|
||||
Enabled: cfg.mqttEnabled,
|
||||
Port: cfg.mqttPort,
|
||||
TLSEnabled: true,
|
||||
CertFile: cfg.mqttTLSCert,
|
||||
KeyFile: cfg.mqttTLSKey,
|
||||
DeviceCertPath: cfg.mqttDeviceCertPath,
|
||||
ShadowPersist: cfg.mqttShadowPersist,
|
||||
}
|
||||
|
||||
if err := server.InitMQTTBroker(mqttConfig); err != nil {
|
||||
log.Fatalf("Failed to initialize MQTT broker: %v", err)
|
||||
}
|
||||
|
||||
if err := server.StartMQTT(); err != nil {
|
||||
log.Fatalf("Failed to start MQTT broker: %v", err)
|
||||
}
|
||||
|
||||
log.Printf("MQTT broker started on port %d", cfg.mqttPort)
|
||||
}
|
||||
|
||||
// ... rest of existing main function ...
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Enhanced Device Discovery
|
||||
|
||||
#### A. MQTT Device Discovery (`pkg/service/mqtt/discovery.go`)
|
||||
```go
|
||||
package mqtt
|
||||
|
||||
import (
|
||||
"log"
|
||||
"time"
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/models"
|
||||
"github.com/mochi-co/mqtt/v2/packets"
|
||||
)
|
||||
|
||||
type DeviceDiscoveryHook struct {
|
||||
deviceRegistry map[string]*models.Device
|
||||
onDeviceFound func(*models.Device)
|
||||
}
|
||||
|
||||
func NewDeviceDiscoveryHook() *DeviceDiscoveryHook {
|
||||
return &DeviceDiscoveryHook{
|
||||
deviceRegistry: make(map[string]*models.Device),
|
||||
}
|
||||
}
|
||||
|
||||
func (h *DeviceDiscoveryHook) ID() string {
|
||||
return "device-discovery"
|
||||
}
|
||||
|
||||
func (h *DeviceDiscoveryHook) OnConnect(cl *packets.Client, pk packets.Packet) error {
|
||||
clientID := pk.Connect.ClientIdentifier
|
||||
|
||||
log.Printf("MQTT device connected: %s", clientID)
|
||||
|
||||
// Create device entry
|
||||
device := &models.Device{
|
||||
ID: clientID,
|
||||
ClientID: clientID,
|
||||
Name: "MQTT Device",
|
||||
LastSeen: time.Now(),
|
||||
MQTTOnline: true,
|
||||
Source: "mqtt",
|
||||
}
|
||||
|
||||
h.deviceRegistry[clientID] = device
|
||||
|
||||
if h.onDeviceFound != nil {
|
||||
h.onDeviceFound(device)
|
||||
}
|
||||
|
||||
return nil
|
||||
}
|
||||
|
||||
func (h *DeviceDiscoveryHook) OnDisconnect(cl *packets.Client, err error) {
|
||||
clientID := cl.ID
|
||||
|
||||
log.Printf("MQTT device disconnected: %s", clientID)
|
||||
|
||||
if device, exists := h.deviceRegistry[clientID]; exists {
|
||||
device.MQTTOnline = false
|
||||
device.LastSeen = time.Now()
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### B. Integration with Existing Discovery (`pkg/discovery/mqtt.go`)
|
||||
```go
|
||||
package discovery
|
||||
|
||||
import (
|
||||
"context"
|
||||
"time"
|
||||
|
||||
"github.com/gesellix/bose-soundtouch/pkg/models"
|
||||
)
|
||||
|
||||
type MQTTDiscovery struct {
|
||||
deviceRegistry map[string]*models.Device
|
||||
enabled bool
|
||||
}
|
||||
|
||||
func NewMQTTDiscovery() *MQTTDiscovery {
|
||||
return &MQTTDiscovery{
|
||||
deviceRegistry: make(map[string]*models.Device),
|
||||
enabled: true,
|
||||
}
|
||||
}
|
||||
|
||||
func (d *MQTTDiscovery) DiscoverDevices(ctx context.Context, timeout time.Duration) ([]*models.Device, error) {
|
||||
if !d.enabled {
|
||||
return []*models.Device{}, nil
|
||||
}
|
||||
|
||||
var devices []*models.Device
|
||||
for _, device := range d.deviceRegistry {
|
||||
if device.MQTTOnline {
|
||||
devices = append(devices, device)
|
||||
}
|
||||
}
|
||||
|
||||
return devices, nil
|
||||
}
|
||||
|
||||
func (d *MQTTDiscovery) AddDevice(device *models.Device) {
|
||||
d.deviceRegistry[device.ClientID] = device
|
||||
}
|
||||
|
||||
func (d *MQTTDiscovery) RemoveDevice(clientID string) {
|
||||
delete(d.deviceRegistry, clientID)
|
||||
}
|
||||
```
|
||||
|
||||
### 5. Configuration File Extensions
|
||||
|
||||
#### A. Default Configuration (`config.yaml`)
|
||||
```yaml
|
||||
# Existing configuration...
|
||||
|
||||
# MQTT Configuration
|
||||
mqtt:
|
||||
enabled: false
|
||||
port: 8883
|
||||
tls:
|
||||
cert_file: "/etc/ssl/certs/soundtouch-mqtt.crt"
|
||||
key_file: "/etc/ssl/private/soundtouch-mqtt.key"
|
||||
|
||||
# Device certificate validation
|
||||
device_certs:
|
||||
path: "/etc/soundtouch/device-certs"
|
||||
auto_load: true
|
||||
|
||||
# Shadow state management
|
||||
shadow:
|
||||
persist: true
|
||||
ttl: 86400 # 24 hours
|
||||
|
||||
# Bridge configuration
|
||||
bridge:
|
||||
enabled: true
|
||||
sync_interval: 30s
|
||||
```
|
||||
|
||||
#### B. Environment Variable Support
|
||||
```bash
|
||||
# MQTT configuration via environment variables
|
||||
SOUNDTOUCH_MQTT_ENABLED=true
|
||||
SOUNDTOUCH_MQTT_PORT=8883
|
||||
SOUNDTOUCH_MQTT_TLS_CERT=/path/to/cert.pem
|
||||
SOUNDTOUCH_MQTT_TLS_KEY=/path/to/key.pem
|
||||
SOUNDTOUCH_MQTT_DEVICE_CERT_PATH=/path/to/device/certs
|
||||
SOUNDTOUCH_MQTT_SHADOW_PERSIST=true
|
||||
```
|
||||
|
||||
### 6. API Extensions
|
||||
|
||||
#### A. MQTT Status Endpoints
|
||||
```go
|
||||
// Add to handlers
|
||||
func (s *Server) handleMQTTStatus(c *gin.Context) {
|
||||
if !s.mqttEnabled {
|
||||
c.JSON(http.StatusNotImplemented, gin.H{
|
||||
"error": "MQTT not enabled",
|
||||
})
|
||||
return
|
||||
}
|
||||
|
||||
status := gin.H{
|
||||
"enabled": s.mqttEnabled,
|
||||
"port": s.mqttConfig.Port,
|
||||
"connected_devices": len(s.deviceClientIDs),
|
||||
"shadow_count": s.mqttBroker.ShadowStore().Count(),
|
||||
}
|
||||
|
||||
c.JSON(http.StatusOK, status)
|
||||
}
|
||||
|
||||
// Device shadow endpoint
|
||||
func (s *Server) handleDeviceShadow(c *gin.Context) {
|
||||
deviceID := c.Param("deviceId")
|
||||
clientID, exists := s.deviceClientIDs[deviceID]
|
||||
if !exists {
|
||||
c.JSON(http.StatusNotFound, gin.H{
|
||||
"error": "Device not connected via MQTT",
|
||||
})
|
||||
return
|
||||
}
|
||||
|
||||
shadow := s.mqttBroker.ShadowStore().GetShadow(clientID)
|
||||
if shadow == nil {
|
||||
c.JSON(http.StatusNotFound, gin.H{
|
||||
"error": "Shadow not found",
|
||||
})
|
||||
return
|
||||
}
|
||||
|
||||
c.JSON(http.StatusOK, shadow)
|
||||
}
|
||||
```
|
||||
|
||||
### 7. Testing Strategy
|
||||
|
||||
#### A. Unit Tests
|
||||
```go
|
||||
// pkg/service/mqtt/shadow_test.go
|
||||
func TestShadowStore_UpdateShadow(t *testing.T) {
|
||||
store := NewShadowStore()
|
||||
|
||||
payload := []byte(`{
|
||||
"state": {
|
||||
"reported": {
|
||||
"powerState": "ON",
|
||||
"volume": 25
|
||||
}
|
||||
}
|
||||
}`)
|
||||
|
||||
shadow, err := store.UpdateShadow("test-client", payload)
|
||||
assert.NoError(t, err)
|
||||
assert.Equal(t, "ON", shadow.State.Reported["powerState"])
|
||||
assert.Equal(t, 25.0, shadow.State.Reported["volume"])
|
||||
assert.Equal(t, 1, shadow.Version)
|
||||
}
|
||||
```
|
||||
|
||||
#### B. Integration Tests
|
||||
```go
|
||||
// pkg/service/mqtt/integration_test.go
|
||||
func TestMQTTBrokerIntegration(t *testing.T) {
|
||||
// Start test broker
|
||||
broker := setupTestBroker(t)
|
||||
go broker.Start()
|
||||
defer broker.Stop()
|
||||
|
||||
// Connect test client
|
||||
client := mqtt.NewClient(mqtt.NewClientOptions().
|
||||
AddBroker("tls://localhost:8883").
|
||||
SetClientID("test-device"))
|
||||
|
||||
// Test shadow operations
|
||||
testShadowUpdate(t, client)
|
||||
testShadowGet(t, client)
|
||||
}
|
||||
```
|
||||
|
||||
### 8. Migration Path
|
||||
|
||||
#### A. Gradual Rollout
|
||||
1. **Phase 1**: Deploy MQTT broker alongside existing HTTP service (disabled by default)
|
||||
2. **Phase 2**: Enable MQTT for testing with specific devices
|
||||
3. **Phase 3**: Enable bidirectional HTTP ↔ MQTT bridging
|
||||
4. **Phase 4**: Full MQTT support for all discovered devices
|
||||
5. **Phase 5**: Prepare for AWS IoT shutdown (May 2026)
|
||||
|
||||
#### B. Backward Compatibility
|
||||
- All existing HTTP API endpoints continue to work
|
||||
- MQTT is purely additive functionality
|
||||
- Devices can be discovered via HTTP even with MQTT enabled
|
||||
- Configuration remains optional
|
||||
|
||||
### 9. Monitoring and Logging
|
||||
|
||||
#### A. MQTT Metrics
|
||||
```go
|
||||
type MQTTMetrics struct {
|
||||
ConnectedDevices int64
|
||||
MessagesReceived int64
|
||||
MessagesSent int64
|
||||
ShadowUpdates int64
|
||||
AuthenticationFails int64
|
||||
Uptime time.Duration
|
||||
}
|
||||
|
||||
func (b *Broker) GetMetrics() *MQTTMetrics {
|
||||
return &MQTTMetrics{
|
||||
ConnectedDevices: int64(len(b.server.Clients)),
|
||||
MessagesReceived: b.server.Stats.MessagesReceived,
|
||||
MessagesSent: b.server.Stats.MessagesSent,
|
||||
ShadowUpdates: b.shadowStore.UpdateCount(),
|
||||
AuthenticationFails: b.authHook.FailCount(),
|
||||
Uptime: time.Since(b.startTime),
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### B. Logging Integration
|
||||
```go
|
||||
import "github.com/sirupsen/logrus"
|
||||
|
||||
func (b *Broker) setupLogging() {
|
||||
log := logrus.WithFields(logrus.Fields{
|
||||
"component": "mqtt-broker",
|
||||
"port": b.config.Port,
|
||||
})
|
||||
|
||||
b.server.AddHook(&LoggingHook{logger: log}, nil)
|
||||
}
|
||||
```
|
||||
|
||||
### 10. Security Considerations
|
||||
|
||||
#### A. Certificate Validation
|
||||
- Validate device certificates against known device list
|
||||
- Implement certificate revocation checking
|
||||
- Support certificate rotation
|
||||
|
||||
#### B. Access Control
|
||||
- Restrict topic access per device certificate
|
||||
- Implement rate limiting per client
|
||||
- Monitor for unusual connection patterns
|
||||
|
||||
#### C. Data Protection
|
||||
- Encrypt shadow data at rest
|
||||
- Implement secure certificate storage
|
||||
- Audit logging for security events
|
||||
|
||||
## Implementation Timeline
|
||||
|
||||
### Week 1: Core Infrastructure
|
||||
- [ ] Create MQTT package structure
|
||||
- [ ] Implement basic MQTT broker
|
||||
- [ ] Add TLS configuration
|
||||
- [ ] Basic shadow state management
|
||||
|
||||
### Week 2: Integration & Bridging
|
||||
- [ ] Integrate with existing Server struct
|
||||
- [ ] Implement HTTP ↔ MQTT bridge
|
||||
- [ ] Device discovery integration
|
||||
- [ ] Configuration management
|
||||
|
||||
### Week 3: Testing & Polish
|
||||
- [ ] Unit test coverage
|
||||
- [ ] Integration testing
|
||||
- [ ] Documentation updates
|
||||
- [ ] Performance optimization
|
||||
|
||||
### Week 4: Deployment & Monitoring
|
||||
- [ ] Docker container updates
|
||||
- [ ] Monitoring and metrics
|
||||
- [ ] Security hardening
|
||||
- [ ] Production readiness
|
||||
|
||||
## Success Criteria
|
||||
|
||||
1. **Functional**: MQTT broker accepts device connections using extracted certificates
|
||||
2. **Compatible**: All existing HTTP functionality continues to work unchanged
|
||||
3. **Performant**: MQTT operations don't impact HTTP API performance
|
||||
4. **Secure**: Device authentication and authorization properly implemented
|
||||
5. **Observable**: Comprehensive logging and metrics for MQTT operations
|
||||
6. **Maintainable**: Clean separation of MQTT code from existing HTTP logic
|
||||
|
||||
This design provides a comprehensive path to add MQTT support while maintaining the existing architecture and ensuring smooth integration with current functionality.
|
||||
@@ -0,0 +1,69 @@
|
||||
# Raspberry Pi Installation Guide
|
||||
|
||||
This guide explains how to install the `soundtouch-service` as a persistent systemd service on a Raspberry Pi (tested on Raspberry Pi Zero 2W, 3, and 4).
|
||||
|
||||
## Automated Installer
|
||||
|
||||
We provide a specialized installer script located in the `scripts/raspberry-pi/` directory of the repository.
|
||||
|
||||
### Features
|
||||
* **Automatic start on boot**: Installs a systemd unit.
|
||||
* **Non-root operation**: Uses `AmbientCapabilities` to bind to ports 80/443 without root privileges.
|
||||
* **Arch Detection**: Automatically selects the correct binary for `armv7`, `arm64`, or `amd64`.
|
||||
* **Easy Updates**: Re-running the script updates the binary to the latest version.
|
||||
|
||||
### Installation Steps
|
||||
|
||||
1. **Download the installer**:
|
||||
```bash
|
||||
curl -fsSL -o install.sh https://raw.githubusercontent.com/gesellix/bose-soundtouch/main/scripts/raspberry-pi/install.sh
|
||||
```
|
||||
|
||||
2. **Run with sudo**:
|
||||
```bash
|
||||
sudo bash install.sh
|
||||
```
|
||||
|
||||
### Overriding Defaults
|
||||
|
||||
You can customize the installation using environment variables:
|
||||
|
||||
```bash
|
||||
sudo \
|
||||
VERSION=v0.17.0 \
|
||||
HOSTNAME_FQDN=soundtouch.local \
|
||||
HTTP_PORT=80 \
|
||||
HTTPS_PORT=443 \
|
||||
bash install.sh
|
||||
```
|
||||
|
||||
### Updating the Service
|
||||
|
||||
To update the service to a specific version, run the installer with the version as an argument:
|
||||
|
||||
```bash
|
||||
sudo bash install.sh v0.18.1
|
||||
```
|
||||
|
||||
The installer will automatically fetch the latest version of itself for that release and then update the service binary and restart it.
|
||||
|
||||
## Management
|
||||
|
||||
Once installed, use standard `systemctl` commands to manage the service:
|
||||
|
||||
```bash
|
||||
# Check status
|
||||
systemctl status soundtouch-service
|
||||
|
||||
# Follow logs
|
||||
journalctl -u soundtouch-service -f
|
||||
|
||||
# Restart
|
||||
sudo systemctl restart soundtouch-service
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
Configuration is stored in `/etc/soundtouch-service/soundtouch-service.env`. Note that settings saved via the Web UI (in `settings.json`) will take precedence over these environment variables once the service is running.
|
||||
|
||||
For more details, see the [scripts/raspberry-pi/README.md](../../scripts/raspberry-pi/README.md) in the repository.
|
||||
@@ -0,0 +1,854 @@
|
||||
# SoundTouch Service
|
||||
|
||||
The `soundtouch-service` is a comprehensive local server that emulates Bose's cloud services, enabling offline SoundTouch device operation and advanced debugging capabilities. This service is particularly valuable given Bose's announcement that cloud support will end in May 2026.
|
||||
|
||||
## Overview
|
||||
|
||||
The service provides:
|
||||
|
||||
- **🏠 Local Service Emulation**: Complete BMX (Bose Media eXchange) and Marge service implementation
|
||||
- **🔧 Device Migration**: Seamlessly migrate devices from Bose cloud to local services via XML config, `/etc/hosts`, or `/etc/resolv.conf`
|
||||
- **🔍 DNS Discovery & Interception**: Built-in DNS server to discover unknown Bose endpoints and selectively intercept cloud traffic
|
||||
- **📊 Traffic Proxying**: Inspect and log all device communications for debugging
|
||||
- **🌐 Web Management UI**: Browser-based interface for device management
|
||||
- **💾 Persistent Data**: Store device configurations, presets, and usage statistics
|
||||
- **📝 HTTP Recording**: Persist all interactions as re-playable `.http` files
|
||||
- **🔄 Endpoint Mirroring**: Asynchronously mirror local requests to Bose cloud for parity testing
|
||||
- **⚖️ Parity Logging**: Detect and record discrepancies between local and official Bose responses
|
||||
- **📥 Session Archiving**: Download entire interaction sessions as `.tar.gz` for offline analysis
|
||||
- **🔍 Auto-Discovery**: Automatically detect and configure SoundTouch devices
|
||||
- **🔒 Offline Operation**: Continue using full device functionality without internet
|
||||
- **🔗 Bose Proxy & Soundcork Fallback**: Dynamic proxying with automatic fallback to local [SoundCork](https://github.com/deborahgu/soundcork) emulation if enabled
|
||||
|
||||
## Architecture
|
||||
|
||||
The service consists of several key components:
|
||||
|
||||
### BMX Services (Bose Media eXchange)
|
||||
- **TuneIn Integration**: Direct playback of radio stations and podcasts
|
||||
- **Custom Streams**: Flexible playback of any internet radio URL via dynamic proxy
|
||||
- **Service Registry**: Media service discovery and configuration
|
||||
- **Playback Control**: Stream URL resolution and audio metadata
|
||||
|
||||
### Marge Services (Account & Device Management)
|
||||
- **Account Management**: User account simulation and device association
|
||||
- **Preset Synchronization**: Cross-device preset storage and sync
|
||||
- **Recent Items**: Playback history tracking and management
|
||||
- **Configuration Management**: Device settings and preferences
|
||||
|
||||
### Discovery & Migration
|
||||
- **Network Scanning**: UPnP/SSDP and mDNS device discovery
|
||||
- **Device Analysis**: Configuration assessment and compatibility checking
|
||||
- **Service Migration**: Automated configuration updates for local service usage
|
||||
- **Health Monitoring**: Device connectivity and service status tracking
|
||||
|
||||
## Installation
|
||||
|
||||
### Install from Source
|
||||
```bash
|
||||
go install github.com/gesellix/bose-soundtouch/cmd/soundtouch-service@latest
|
||||
```
|
||||
|
||||
### Build from Repository
|
||||
```bash
|
||||
git clone https://github.com/gesellix/bose-soundtouch.git
|
||||
cd Bose-SoundTouch
|
||||
go build -o soundtouch-service ./cmd/soundtouch-service
|
||||
```
|
||||
|
||||
### Docker Support
|
||||
|
||||
You can run the SoundTouch service using Docker or Docker Compose.
|
||||
|
||||
> **Note for macOS and Windows users**: The `--net host` option is only supported on Linux. On macOS and Windows, service discovery (mDNS, UPnP) will not work automatically within the container. You will need to manually enter your device's IP address in the management UI, and the service will communicate with it directly.
|
||||
|
||||
#### Using Docker
|
||||
|
||||
**Linux (with host networking for discovery):**
|
||||
```bash
|
||||
docker run -d \
|
||||
--name soundtouch-service \
|
||||
--network host \
|
||||
-v $(pwd)/data:/app/data \
|
||||
ghcr.io/gesellix/bose-soundtouch:latest
|
||||
```
|
||||
|
||||
**macOS / Windows (with port mapping):**
|
||||
```bash
|
||||
docker run --rm -it \
|
||||
-p 8000:8000 -p 8443:8443 \
|
||||
-v $(pwd)/data:/app/data \
|
||||
--env SERVER_URL=http://soundtouch.local:8000 \
|
||||
--env HTTPS_SERVER_URL=https://soundtouch.local:8443 \
|
||||
ghcr.io/gesellix/bose-soundtouch:latest
|
||||
```
|
||||
|
||||
> **Note**: The hostnames configured via `SERVER_URL` and `HTTPS_SERVER_URL` are automatically added as Subject Alternative Names (SAN) to the generated TLS certificate, ensuring valid SSL connections.
|
||||
|
||||
#### Using Docker Compose
|
||||
|
||||
Create a `docker-compose.yml` file:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
soundtouch-service:
|
||||
image: ghcr.io/gesellix/bose-soundtouch:latest
|
||||
container_name: soundtouch-service
|
||||
# Linux users: use host networking for device discovery
|
||||
# network_mode: host
|
||||
# macOS/Windows users: use port mapping (discovery will be manual)
|
||||
ports:
|
||||
- "8000:8000"
|
||||
- "8443:8443"
|
||||
environment:
|
||||
- PORT=8000
|
||||
- SERVER_URL=http://soundtouch.local:8000
|
||||
- HTTPS_SERVER_URL=https://soundtouch.local:8443
|
||||
- DATA_DIR=/app/data
|
||||
volumes:
|
||||
- soundtouch-data:/app/data
|
||||
restart: unless-stopped
|
||||
|
||||
volumes:
|
||||
soundtouch-data:
|
||||
```
|
||||
|
||||
And run:
|
||||
|
||||
```bash
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
## Quick Start
|
||||
|
||||
### 1. Start the Service
|
||||
|
||||
```bash
|
||||
# Start with default settings (port 8000)
|
||||
soundtouch-service
|
||||
```
|
||||
|
||||
### 2. Access the Web Interface
|
||||
|
||||
Open your browser to `http://localhost:8000` to access the management interface.
|
||||
|
||||
### 3. Discover Devices
|
||||
|
||||
The service will automatically start discovering SoundTouch devices on your network. You can also trigger manual discovery from the web UI or API.
|
||||
|
||||
### 4. Migrate Devices
|
||||
|
||||
Use the web interface or API to migrate devices from Bose cloud services to your local instance.
|
||||
|
||||
## Configuration
|
||||
|
||||
### Configuration Precedence
|
||||
|
||||
The service supports multiple ways to configure its behavior. When multiple sources provide the same setting, the following precedence rules apply (highest to lowest):
|
||||
|
||||
1. **`settings.json`**: Settings saved via the Web UI (stored in the data directory) take the highest precedence. This ensures that changes made in the browser persist across service restarts even if environment variables or flags change.
|
||||
2. **Environment Variables / CLI Flags**: If a setting is not present in `settings.json`, environment variables and flags are used.
|
||||
3. **Default Values**: If no configuration is provided, the service uses its built-in defaults.
|
||||
|
||||
> **Tip**: If you find that changes to environment variables are not taking effect, check the **Settings** tab in the Web UI or inspect the `settings.json` file in your data directory, as it might be overriding your manual configuration.
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Variable | Flag | Description | Default |
|
||||
|------------------------------------|----------------------------|---------------------------------------------------------------------------------------------------------|---------------------------|
|
||||
| `PORT` | `--port`, `-p` | HTTP port to bind the service to | `8000` |
|
||||
| `BIND_ADDR` | `--bind` | Network interface to bind to | all (ipv4 and ipv6) |
|
||||
| `DATA_DIR` | `--data-dir` | Directory for persistent data | `./data` |
|
||||
| `SERVER_URL` | `--server-url`, `-s` | External URL of this service | `http://<hostname>:8000` |
|
||||
| `HTTPS_PORT` | `--https-port` | HTTPS port to bind the service to | `8443` |
|
||||
| `HTTPS_SERVER_URL` | `--https-server-url`, `-S` | External HTTPS URL | `https://<hostname>:8443` |
|
||||
| `PYTHON_BACKEND_URL`, `TARGET_URL` | `--target-url` | URL for Python-based service components (legacy) | `http://localhost:8001` |
|
||||
| `REDACT_PROXY_LOGS` | `--redact-logs` | Redact sensitive data in proxy logs | `true` |
|
||||
| `LOG_PROXY_BODY` | `--log-bodies` | Log full request/response bodies | `false` |
|
||||
| `RECORD_INTERACTIONS` | `--record-interactions` | Record HTTP interactions to disk | `true` |
|
||||
| `DISCOVERY_INTERVAL` | `--discovery-interval` | Device discovery interval | `5m` |
|
||||
| `ENABLE_DNS_DISCOVERY` | `--dns-discovery` | Enable DNS discovery server | `false` |
|
||||
| `DNS_UPSTREAM` | `--dns-upstream` | Upstream DNS server for non-Bose queries | `8.8.8.8` |
|
||||
| `DNS_BIND_ADDR` | `--dns-bind` | Bind address for the DNS discovery server (standard port `:53` is required for `resolv.conf` migration) | `:53` |
|
||||
| `MIRROR_ENABLED` | | Enable background mirroring of specific endpoints to Bose cloud | `false` |
|
||||
| `MIRROR_ENDPOINTS` | | Comma-separated list of path patterns to mirror (e.g., `/streaming/account/*/device/*/recent`) | `[]` |
|
||||
| `INTERNAL_PATHS` | `--internal-paths` | Paths for internal requests to exclude from recording (e.g., `/setup/*`, `/web/*`) | `[]` |
|
||||
| `DISCOVERY_DISABLED` | | Disable automated device discovery | `false` |
|
||||
|
||||
### Configuration Examples
|
||||
|
||||
```bash
|
||||
# Custom port and data directory
|
||||
PORT=9000 DATA_DIR=/home/user/soundtouch soundtouch-service
|
||||
|
||||
# External server with custom URL
|
||||
SERVER_URL=https://my-soundtouch.example.com soundtouch-service --port 443
|
||||
|
||||
# Development mode with full logging
|
||||
LOG_PROXY_BODY=true REDACT_PROXY_LOGS=false soundtouch-service
|
||||
```
|
||||
|
||||
## Device Migration
|
||||
|
||||
### Understanding Migration
|
||||
|
||||
Device migration switches your SoundTouch devices from Bose's cloud services to your local service instance. This process:
|
||||
|
||||
1. **Backs up** existing device configuration
|
||||
2. **Updates** device service URLs to point to your local server
|
||||
3. **Maintains** all existing presets and settings
|
||||
4. **Enables** offline operation and advanced debugging
|
||||
|
||||
### Migration Methods
|
||||
|
||||
#### Web Interface (Recommended)
|
||||
|
||||
1. Start the service: `soundtouch-service`
|
||||
2. Open `http://localhost:8000`
|
||||
3. Wait for device discovery to complete
|
||||
4. Click "Migrate" next to each device
|
||||
5. Monitor migration status in real-time
|
||||
|
||||
#### API Migration
|
||||
|
||||
```bash
|
||||
# Get migration summary first
|
||||
curl http://localhost:8000/setup/migration-summary/192.168.1.100
|
||||
|
||||
# Perform migration
|
||||
curl -X POST http://localhost:8000/setup/migrate/192.168.1.100
|
||||
|
||||
# Verify migration status
|
||||
curl http://localhost:8000/setup/devices
|
||||
```
|
||||
|
||||
#### Advanced Migration Options
|
||||
|
||||
```bash
|
||||
# Migration with proxy fallback for original services
|
||||
curl -X POST "http://localhost:8000/setup/migrate/192.168.1.100?proxy_url=http://localhost:8000&marge=original&stats=original"
|
||||
|
||||
# Migration with custom target URL
|
||||
curl -X POST "http://localhost:8000/setup/migrate/192.168.1.100?target_url=https://my-server.com:8000"
|
||||
```
|
||||
|
||||
### Post-Migration Verification
|
||||
|
||||
After migration, verify the device is working correctly:
|
||||
|
||||
```bash
|
||||
# Check device status
|
||||
curl http://localhost:8000/setup/devices
|
||||
|
||||
# Test preset functionality
|
||||
curl "http://192.168.1.100:8090/presets"
|
||||
|
||||
# Monitor device events (if needed)
|
||||
curl "http://localhost:8000/events/192.168.1.100"
|
||||
```
|
||||
|
||||
#### ResolvConf Migration (DHCP-Aware DNS Redirection)
|
||||
|
||||
The most robust and flexible DNS-based migration method. It utilizes the device's persistent `/mnt/nv/rc.local` script to inject a priority DNS hook into the system's DHCP configuration.
|
||||
|
||||
> **Note**: This method requires the DNS Discovery Server to be bound to **port 53** on your local IP and **actually running**. Most devices do not support custom DNS ports in `/etc/resolv.conf`. If you use a custom port for testing, remember to switch back to `:53` and ensure the server has successfully bound to it (check Settings for status) before the actual migration.
|
||||
|
||||
**Advantages:**
|
||||
- **Discovery**: Automatically discover all Bose endpoints queried by the device.
|
||||
- **Dynamic Interception**: Intercept new or unknown services without further device modifications.
|
||||
- **Fail-Safe**: Falls back to the standard network DNS (provided by your router) if the Aftertouch service is unavailable.
|
||||
- **DHCP Compatible**: Preserves your router's assigned search domain and secondary DNS servers.
|
||||
- **Wildcard Support**: Seamlessly handles `*.bose.com` redirection via your local DNS server.
|
||||
- **Persistent**: Survives reboots and DHCP renewals.
|
||||
|
||||
**How it works:**
|
||||
1. **Configuration**: A custom file named `/mnt/nv/aftertouch.resolv.conf` is created on the device's persistent partition.
|
||||
2. **Boot Hook**: On every boot, `/mnt/nv/rc.local` checks if the system's DHCP scripts (`/etc/udhcpc.d/50default` or `/opt/Bose/udhcpc.script`) have been patched.
|
||||
3. **Surgical Patch**: If not patched, it injects a one-line check into the relevant DHCP scripts.
|
||||
4. **Resolution**: Whenever the device acquires a DHCP lease, the scripts now read your `aftertouch.resolv.conf` first, placing your DNS server at the top of `/etc/resolv.conf` while keeping all other DHCP-provided settings.
|
||||
|
||||
**Setup:**
|
||||
1. Enable SSH via the `remote_services` USB trick.
|
||||
2. Create `/mnt/nv/aftertouch.resolv.conf` with your server details:
|
||||
```text
|
||||
# Created by Aftertouch/SoundTouch-Service
|
||||
# Priority nameserver for Bose service redirection
|
||||
nameserver 192.168.1.XXX
|
||||
```
|
||||
3. Update `/mnt/nv/rc.local` with the idempotent patch:
|
||||
```sh
|
||||
#!/bin/sh
|
||||
# Aftertouch DNS hook: prioritizes our custom nameserver if it exists
|
||||
HOOK_MARKER="/mnt/nv/aftertouch.resolv.conf"
|
||||
if [ -f "$HOOK_MARKER" ]; then
|
||||
# Patch 50default if it exists
|
||||
TARGET_FILE="/etc/udhcpc.d/50default"
|
||||
if [ -f "$TARGET_FILE" ] && ! grep -q "$HOOK_MARKER" "$TARGET_FILE"; then
|
||||
sed -i '/echo "search \$domain"/a \ [ -f '"$HOOK_MARKER"' ] && cat '"$HOOK_MARKER"' && dns=""' "$TARGET_FILE"
|
||||
fi
|
||||
# Patch udhcpc.script if it exists (e.g. SoundTouch 10)
|
||||
TARGET_SCRIPT="/opt/Bose/udhcpc.script"
|
||||
if [ -f "$TARGET_SCRIPT" ] && ! grep -q "$HOOK_MARKER" "$TARGET_SCRIPT"; then
|
||||
sed -i '/echo "search \$search_list # \$interface" >> \$RESOLV_CONF/a \ [ -f '"$HOOK_MARKER"' ] && cat '"$HOOK_MARKER"' >> '"\$RESOLV_CONF"' && dns=""' "$TARGET_SCRIPT"
|
||||
fi
|
||||
fi
|
||||
```
|
||||
4. Make the script executable: `chmod +x /mnt/nv/rc.local`.
|
||||
5. Reboot the speaker.
|
||||
|
||||
### DNS Discovery Server
|
||||
|
||||
The SoundTouch service includes a built-in DNS server specifically designed for Bose devices.
|
||||
|
||||
#### How it Works
|
||||
When enabled, the DNS server:
|
||||
1. Receives DNS queries from migrated SoundTouch devices.
|
||||
2. **Intercepts** known Bose domains (e.g., `api.bose.com`, `streaming.bose.com`, `bmx.bose.com`) and resolves them to the AfterTouch service IP.
|
||||
3. **Logs** all other queries for discovery purposes, allowing you to identify new Bose cloud endpoints.
|
||||
4. **Forwards** unknown or non-Bose queries to the configured upstream DNS server (default: `8.8.8.8`).
|
||||
|
||||
#### Configuration
|
||||
You can enable and configure the DNS server via the Web UI or environment variables:
|
||||
- `ENABLE_DNS_DISCOVERY=true`: Turns on the DNS server.
|
||||
- `DNS_BIND_ADDR=:53`: The port to listen on (requires root privileges for port 53).
|
||||
- `DNS_UPSTREAM=1.1.1.1`: Your preferred upstream DNS provider. **Note:** Ensure this is not set to the same address as the DNS server itself (loopback or local IP) to avoid forwarding loops. The server includes built-in loop prevention, but misconfiguration will cause forwarding to fail. DNS Discovery cannot be enabled if this setting is empty.
|
||||
|
||||
#### Manual Discovery via DNS
|
||||
Even without migrating a device, you can use the DNS server to discover what a device is querying by manually setting your router's DNS or the device's DNS to point to the AfterTouch service.
|
||||
|
||||
## Endpoint Mirroring & Parity Logging
|
||||
|
||||
The SoundTouch service includes a powerful **Mirroring** feature that allows you to handle requests locally while simultaneously forwarding them to the official Bose cloud in the background. This is primarily used for maintaining long-term compatibility and verifying the accuracy of the local emulation.
|
||||
|
||||
### How Mirroring Works
|
||||
|
||||
When an endpoint is configured for mirroring:
|
||||
1. **GET Requests**: Handled locally first (Primary). The response is returned to the speaker immediately. In the background, the same request is sent to Bose.
|
||||
2. **POST/PUT/DELETE Requests**: Handled locally first. The service then synchronously (but without blocking the speaker's response) forwards the request to Bose to ensure the "official" account state stays in sync with your local changes (e.g., updating a preset).
|
||||
|
||||
### Parity Logging
|
||||
|
||||
The **Parity Logger** automatically compares the response from your local service with the one received from Bose. If it detects any discrepancies, it:
|
||||
1. Logs a warning to the console: `[PARITY] Mismatch detected for GET /...`
|
||||
2. Saves a detailed JSON report to `data/parity_mismatches/`.
|
||||
|
||||
Each report includes the full request, both response bodies, and a summary of what differed (status codes, content types, or missing/different XML tags).
|
||||
|
||||
### Configuration
|
||||
|
||||
Mirroring is configured via the **Settings** tab in the Web UI or through global settings:
|
||||
- **Mirror Enabled**: Master switch for the mirroring infrastructure.
|
||||
- **Mirror Endpoints**: A list of URL path patterns to mirror. You can use wildcards (`*`) to match variable parts like account or device IDs.
|
||||
- Example: `/streaming/account/*/device/*/recent`
|
||||
- Example: `/accounts/*/devices/*/presets/*`
|
||||
|
||||
Mirrored requests are also recorded in the **Interaction Log** under the category `upstream-mirror`, allowing you to see side-by-side exactly how our service's behavior compares to the official one.
|
||||
|
||||
## API Reference
|
||||
|
||||
### Discovery & Setup
|
||||
|
||||
#### `GET /setup/devices`
|
||||
Lists all discovered SoundTouch devices with their current status.
|
||||
|
||||
**Response:**
|
||||
```json
|
||||
[
|
||||
{
|
||||
"device_id": "08DF1F0BA325",
|
||||
"name": "Living Room Speaker",
|
||||
"ip_address": "192.168.1.100",
|
||||
"product_code": "SoundTouch 20",
|
||||
"firmware_version": "19.0.5",
|
||||
"migrated": true,
|
||||
"last_seen": "2024-01-15T10:30:00Z"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
#### `POST /setup/discover`
|
||||
Triggers immediate network device discovery.
|
||||
|
||||
#### `GET /setup/info/{deviceIP}`
|
||||
Gets detailed device information and configuration.
|
||||
|
||||
#### `GET /setup/migration-summary/{deviceIP}`
|
||||
Analyzes device configuration and provides migration preview.
|
||||
|
||||
**Response:**
|
||||
```json
|
||||
{
|
||||
"device_name": "Living Room Speaker",
|
||||
"device_model": "SoundTouch 20",
|
||||
"firmware_version": "19.0.5",
|
||||
"ssh_success": true,
|
||||
"current_config": "<?xml version=\"1.0\"?>...",
|
||||
"planned_config": "<?xml version=\"1.0\"?>...",
|
||||
"remote_services_enabled": false,
|
||||
"migration_required": true
|
||||
}
|
||||
```
|
||||
|
||||
#### `POST /setup/migrate/{deviceIP}`
|
||||
Migrates device to use local services.
|
||||
|
||||
**Query Parameters:**
|
||||
- `target_url`: Custom service URL (optional)
|
||||
- `proxy_url`: Proxy URL for fallback (optional)
|
||||
- `marge`: Set to "original" to proxy Marge requests (optional)
|
||||
- `stats`: Set to "original" to proxy stats requests (optional)
|
||||
- `sw_update`: Set to "original" to proxy update requests (optional)
|
||||
- `bmx`: Set to "original" to proxy BMX requests (optional)
|
||||
|
||||
### BMX Services (Bose Media eXchange)
|
||||
|
||||
#### `GET /bmx/registry/v1/services`
|
||||
Returns available media services for device registration.
|
||||
|
||||
#### `GET /bmx/tunein/v1/playbook/station/{stationID}`
|
||||
Provides TuneIn station playback information.
|
||||
|
||||
#### `GET /bmx/tunein/v1/podcast/{podcastID}`
|
||||
Returns podcast episode information and playback URLs.
|
||||
|
||||
### Marge Services (Account & Device Management)
|
||||
|
||||
#### `GET /marge/streaming/sourceproviders`
|
||||
Lists available music service providers.
|
||||
|
||||
#### `GET /marge/accounts/{account}/devices/any/presets`
|
||||
Returns user presets for synchronization.
|
||||
|
||||
#### `GET /marge/accounts/{account}/devices/any/recents`
|
||||
Returns recent playback items.
|
||||
|
||||
#### `PUT /marge/accounts/{account}/devices/{device}/presets/{slot}`
|
||||
Updates a specific preset slot.
|
||||
|
||||
#### `POST /marge/streaming/support/addrecent`
|
||||
Adds item to recent playback history.
|
||||
|
||||
#### `GET /marge/updates/soundtouch`
|
||||
Returns software update configuration (disabled by default).
|
||||
|
||||
### Proxy Services
|
||||
|
||||
#### `GET /proxy/{encodedURL}`
|
||||
Proxies requests to external services with logging.
|
||||
|
||||
**Example:**
|
||||
```bash
|
||||
# Proxy request to Bose services
|
||||
curl "http://localhost:8000/proxy/aHR0cHM6Ly9hcGkuc291bmR0b3VjaC5ib3NlLmNvbS8="
|
||||
```
|
||||
|
||||
### Health & Monitoring
|
||||
|
||||
#### `GET /health`
|
||||
Returns service health status.
|
||||
|
||||
#### `GET /events/{deviceID}`
|
||||
WebSocket endpoint for real-time device events.
|
||||
|
||||
#### `GET /stats/usage`
|
||||
Returns usage statistics.
|
||||
|
||||
#### `GET /stats/errors`
|
||||
Returns error statistics.
|
||||
|
||||
## Web Interface
|
||||
|
||||
### Overview
|
||||
|
||||
The web management interface provides a comprehensive dashboard for managing your SoundTouch devices:
|
||||
|
||||
**URL:** `http://localhost:8000/`
|
||||
|
||||
### Features
|
||||
|
||||
#### Device Dashboard
|
||||
- **Device Discovery**: Real-time view of discovered devices
|
||||
- **Migration Status**: Visual indicators of migration state
|
||||
- **Device Health**: Connectivity and service status monitoring
|
||||
- **Quick Actions**: One-click migration and configuration
|
||||
|
||||
#### Device Management
|
||||
- **Configuration Viewer**: Inspect current and planned device configs
|
||||
- **Migration Wizard**: Step-by-step device migration process
|
||||
- **Backup Management**: View and restore configuration backups
|
||||
- **Service Testing**: Test connectivity to local services
|
||||
|
||||
#### Monitoring & Debugging
|
||||
- **Traffic Logs**: Real-time proxy request/response logging
|
||||
- **Event Streaming**: Live device event monitoring
|
||||
- **Statistics Dashboard**: Usage and error analytics
|
||||
- **Debug Tools**: Device communication testing utilities
|
||||
|
||||
#### Interactions & Traffic Analysis
|
||||
- **Traffic Overview**: View aggregate request counts for self-handled and proxied traffic.
|
||||
- **Session Browsing**: Browse recorded interactions grouped by session.
|
||||
- **Advanced Filtering**: Filter interactions by session, category (Self/Upstream), and timestamp.
|
||||
- **Interaction Viewer**: View raw `.http` recording content directly in the browser.
|
||||
- **Session Management**: Delete individual sessions or perform bulk cleanup to keep only recent sessions.
|
||||
- **Session Download**: Download complete interaction sessions as `.tar.gz` archives for offline analysis or bug reports.
|
||||
- **DNS Discoveries**: Real-time table of all hostnames discovered via the AfterTouch DNS server, categorized by interception status (Self/Upstream).
|
||||
|
||||
### Usage Tips
|
||||
|
||||
1. **First Time Setup**: The interface will guide you through initial device discovery
|
||||
2. **Migration Monitoring**: Watch migration progress in real-time with detailed status updates
|
||||
3. **Troubleshooting**: Use the debug tools to diagnose device connectivity issues
|
||||
4. **Log Analysis**: Enable detailed logging for development and troubleshooting
|
||||
|
||||
## HTTP Interaction Recording
|
||||
|
||||
The service automatically records all HTTP interactions (both those handled locally and those proxied upstream) as `.http` files. These files are compatible with the [IntelliJ IDEA HTTP Client](https://www.jetbrains.com/help/idea/exploring-http-syntax.html).
|
||||
|
||||
### Internal Paths (Excluding Traffic)
|
||||
|
||||
To prevent internal management traffic (like the Web UI or setup API calls) from cluttering your interaction logs, you can configure **Internal Paths**. Requests matching these patterns will be processed normally but will **not** be recorded by the `RecordMiddleware`.
|
||||
|
||||
By default, we recommend adding:
|
||||
- `/setup/*`: Management API calls
|
||||
- `/web/*`: Static Web UI resources
|
||||
- `/media/*`: Icons and static media
|
||||
|
||||
You can configure these via the **Settings** tab in the Web UI or using the `--internal-paths` flag.
|
||||
|
||||
### Key Features
|
||||
|
||||
- **Session Grouping**: All interactions from a single server session are stored in a dedicated directory named `{timestamp}-{pid}`.
|
||||
- **Chronological Order**: Files are prefixed with a sequential number (e.g., `0001-`, `0002-`) to preserve the exact order of requests across the entire session.
|
||||
- **Path-Based Structure**: Recordings are organized into subdirectories based on their URL path for better discoverability.
|
||||
- **Automatic Sanitization**: Variable path segments like IP addresses, Device IDs, and Account IDs are automatically identified and replaced with placeholders (e.g., `{{ip}}`, `{{deviceId}}`). The original values are preserved as comments at the top of the recorded `.http` files for easy identification.
|
||||
- **Re-playability**: An `http-client.env.json` file is generated for each session, allowing you to re-play the recorded requests immediately in IntelliJ IDEA.
|
||||
- **Management UI**: The **5. Interactions** tab provides a built-in viewer and management tools for all recorded data.
|
||||
|
||||
### Configuration
|
||||
|
||||
#### Redaction
|
||||
|
||||
By default, the service redacts sensitive information from the recorded `.http` files, including:
|
||||
- `Authorization` headers
|
||||
- `Cookie` headers
|
||||
- `X-Bose-Token` headers
|
||||
- `X-Bose-Key` headers
|
||||
- `Proxy-Authorization` headers
|
||||
|
||||
This behavior is controlled by the `--redact-logs` flag or the `REDACT_PROXY_LOGS` environment variable.
|
||||
|
||||
#### Custom Patterns
|
||||
|
||||
The service uses regex patterns to identify variable segments in URL paths. These patterns are loaded from `data/patterns.json`. You can add custom patterns to this file to support additional variable segments:
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"name": "MyVariable",
|
||||
"regexp": "^[0-9]{5}$",
|
||||
"replacement": "{myVar}"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Variables found via these patterns will be:
|
||||
1. Used as directory names in the `interactions/` folder.
|
||||
2. Parameterized as `{{myVar}}` within the `.http` files.
|
||||
3. Added to the `http-client.env.json` file with their actual values.
|
||||
|
||||
## Persistent Data
|
||||
|
||||
### Data Directory Structure
|
||||
|
||||
By default, the service creates a `data/` directory in the current working directory:
|
||||
|
||||
```
|
||||
data/
|
||||
├── accounts/
|
||||
│ └── default/
|
||||
│ ├── devices/
|
||||
│ │ ├── {DEVICE_ID}/
|
||||
│ │ │ ├── DeviceInfo.xml
|
||||
│ │ │ └── config_backup_*.xml
|
||||
│ │ └── ...
|
||||
│ ├── Sources.xml
|
||||
│ ├── Presets.xml
|
||||
│ └── Recents.xml
|
||||
├── interactions/
|
||||
│ └── {SESSION_ID}/
|
||||
│ ├── self/
|
||||
│ │ └── {PATH}/
|
||||
│ │ └── {SEQ}-{TIME}-{METHOD}.http
|
||||
│ ├── upstream/
|
||||
│ │ └── {PATH}/
|
||||
│ │ └── {SEQ}-{TIME}-{METHOD}.http
|
||||
│ └── http-client.env.json
|
||||
├── dns/
|
||||
│ └── discoveries.json
|
||||
├── stats/
|
||||
│ ├── usage/
|
||||
│ │ └── *.json
|
||||
│ └── error/
|
||||
│ └── *.json
|
||||
└── events/
|
||||
└── device_events_*.log
|
||||
```
|
||||
|
||||
### Data Components
|
||||
|
||||
#### Device Data (`accounts/default/devices/{DEVICE_ID}/`)
|
||||
- **DeviceInfo.xml**: Device metadata and capabilities
|
||||
- **config_backup_*.xml**: Configuration backups before migration
|
||||
- **presets.xml**: Device-specific preset configurations
|
||||
|
||||
#### Account Data (`accounts/default/`)
|
||||
- **Sources.xml**: Configured music service providers
|
||||
- **Presets.xml**: Cross-device preset synchronization
|
||||
- **Recents.xml**: Recent playback history
|
||||
|
||||
#### DNS Data (`dns/`)
|
||||
- **discoveries.json**: Persisted DNS discovery logs with hostname deduplication
|
||||
|
||||
#### Statistics (`stats/`)
|
||||
- **usage/**: Device usage analytics and patterns
|
||||
- **error/**: Error logs and diagnostic information
|
||||
|
||||
#### Events (`events/`)
|
||||
- **device_events_*.log**: Device event history and debugging logs
|
||||
|
||||
#### HTTP Interactions (`interactions/`)
|
||||
- **{SESSION_ID}/**: A unique directory per server run (format: `YYYYMMDD-HHMMSS-PID`).
|
||||
- **self/**: Requests handled directly by the service.
|
||||
- **upstream/**: Requests proxied to external Bose services.
|
||||
- **{PATH}/**: Nested subdirectories reflecting the URL path (sanitized).
|
||||
- **http-client.env.json**: IntelliJ IDEA HTTP Client environment file with session variables.
|
||||
- **{SEQ}-{TIME}-{METHOD}.http**: Individual interaction recordings in standard HTTP Client format.
|
||||
|
||||
### Data Management
|
||||
|
||||
#### Backup Strategy
|
||||
```bash
|
||||
# Manual backup
|
||||
cp -r data/ backup-$(date +%Y%m%d)/
|
||||
|
||||
# Automated backup (cron example)
|
||||
0 2 * * * cp -r /path/to/data/ /backup/soundtouch-$(date +\%Y\%m\%d)/
|
||||
```
|
||||
|
||||
#### Data Migration
|
||||
```bash
|
||||
# Moving to new server
|
||||
tar czf soundtouch-data.tar.gz data/
|
||||
# Transfer to new server
|
||||
tar xzf soundtouch-data.tar.gz
|
||||
```
|
||||
|
||||
#### Cleanup
|
||||
```bash
|
||||
# Clean old event logs (older than 30 days)
|
||||
find data/events/ -name "*.log" -mtime +30 -delete
|
||||
|
||||
# Clean old statistics (older than 90 days)
|
||||
find data/stats/ -name "*.json" -mtime +90 -delete
|
||||
```
|
||||
|
||||
## API Endpoints
|
||||
|
||||
### Management UI
|
||||
- **URL**: `http://localhost:8000/` or `http://localhost:8000/web/`
|
||||
- **Description**: Browser-based guided flow for discovery, data sync, and migration.
|
||||
|
||||
### Setup API
|
||||
- `GET /setup/devices`: List all known (auto-discovered and manual) devices.
|
||||
- `POST /setup/devices`: Manually add a device by IP.
|
||||
- `POST /setup/discover`: Trigger a new network discovery scan.
|
||||
- `GET /setup/discovery-status`: Check if a scan is currently in progress.
|
||||
- `POST /setup/sync/{deviceIP}`: Fetch presets, recents, and sources from a device.
|
||||
- `GET /setup/summary/{deviceIP}`: Get a detailed migration readiness summary.
|
||||
- `POST /setup/migrate/{deviceIP}`: Migrate a device using the specified method (XML/Hosts).
|
||||
- `GET /setup/ca.crt`: Download the Root CA certificate for manual installation.
|
||||
|
||||
#### `GET /setup/interactions`
|
||||
Lists recorded interactions with optional filtering.
|
||||
|
||||
**Query Parameters:**
|
||||
- `session`: Filter by session ID (optional)
|
||||
- `category`: Filter by category (`self` or `upstream`) (optional)
|
||||
- `since`: Filter by timestamp (e.g., `2026-02-15 15:00:00`) (optional)
|
||||
|
||||
#### `GET /setup/interaction-stats`
|
||||
Returns aggregate statistics about recorded interactions across all sessions.
|
||||
|
||||
#### `GET /setup/interaction-content?file={path}`
|
||||
Returns the raw content of a specific recorded `.http` file.
|
||||
|
||||
#### `DELETE /setup/interactions/sessions/{sessionID}`
|
||||
Deletes all recordings associated with a specific session.
|
||||
|
||||
#### `DELETE /setup/interactions/sessions?keep={N}`
|
||||
Bulk cleanup: deletes all but the most recent `N` sessions.
|
||||
|
||||
### DNS Discovery API
|
||||
|
||||
#### `GET /setup/dns-discoveries`
|
||||
Returns merged in-memory and persisted DNS discoveries, sorted by last seen timestamp.
|
||||
|
||||
#### `DELETE /setup/dns-discoveries`
|
||||
Clears all recorded DNS discovery data from memory and disk.
|
||||
|
||||
### Emulated Services
|
||||
- `/bmx/registry/v1/services`: BMX service registry.
|
||||
- `/bmx/tunein/v1/*`: TuneIn radio emulation.
|
||||
- `/marge/accounts/*`: Account and device management.
|
||||
- `/marge/updates/soundtouch`: Software update emulation.
|
||||
- `/proxy/*`: Logging proxy for original Bose services.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
#### Device Not Discovered
|
||||
```bash
|
||||
# Check network connectivity
|
||||
ping 192.168.1.100
|
||||
|
||||
# Trigger manual discovery
|
||||
curl -X POST http://localhost:8000/setup/discover
|
||||
|
||||
# Check device accessibility
|
||||
curl http://192.168.1.100:8090/info
|
||||
```
|
||||
|
||||
#### Migration Failures
|
||||
```bash
|
||||
# Check SSH connectivity
|
||||
ssh-keyscan 192.168.1.100
|
||||
|
||||
# Get migration summary
|
||||
curl http://localhost:8000/setup/migration-summary/192.168.1.100
|
||||
|
||||
# Verify device configuration
|
||||
curl http://192.168.1.100:8090/info
|
||||
```
|
||||
|
||||
#### Service Connectivity Issues
|
||||
```bash
|
||||
# Test local service endpoints
|
||||
curl http://localhost:8000/health
|
||||
curl http://localhost:8000/bmx/registry/v1/services
|
||||
curl http://localhost:8000/marge/streaming/sourceproviders
|
||||
```
|
||||
|
||||
### Debug Mode
|
||||
|
||||
Enable debug logging for detailed troubleshooting:
|
||||
|
||||
```bash
|
||||
LOG_PROXY_BODY=true REDACT_PROXY_LOGS=false soundtouch-service
|
||||
```
|
||||
|
||||
### Log Analysis
|
||||
|
||||
```bash
|
||||
# Monitor service logs
|
||||
tail -f /var/log/soundtouch-service.log
|
||||
|
||||
# Analyze proxy traffic
|
||||
grep "PROXY" /var/log/soundtouch-service.log
|
||||
|
||||
# Check device events
|
||||
ls -la data/events/
|
||||
```
|
||||
|
||||
## Credits & Inspiration
|
||||
|
||||
This service implementation is based on and inspired by several excellent community projects:
|
||||
|
||||
### SoundCork
|
||||
- **Project**: [SoundCork](https://github.com/deborahgu/soundcork)
|
||||
- **Authors**: Deborah Gu and contributors
|
||||
- **Contribution**: The architecture and service emulation approach in this Go implementation is heavily based on SoundCork's pioneering Python implementation. SoundCork provided the foundation for understanding Bose's service architecture and migration strategies.
|
||||
|
||||
### ÜberBöse API
|
||||
- **Project**: [ÜberBöse API](https://github.com/julius-d/ueberboese-api)
|
||||
- **Author**: Julius D.
|
||||
- **Contribution**: Advanced API endpoint discovery and implementation details that helped make this service more complete and robust.
|
||||
|
||||
We are grateful to these projects for paving the way and providing the research foundation that made this comprehensive service implementation possible.
|
||||
|
||||
## Advanced Usage
|
||||
|
||||
### Custom Service Integration
|
||||
|
||||
```go
|
||||
// Example: Custom BMX service handler
|
||||
package main
|
||||
|
||||
import (
|
||||
"net/http"
|
||||
"github.com/go-chi/chi/v5"
|
||||
)
|
||||
|
||||
func customBMXHandler(w http.ResponseWriter, r *http.Request) {
|
||||
// Custom BMX service logic
|
||||
w.Header().Set("Content-Type", "application/json")
|
||||
w.Write([]byte(`{"custom": "service"}`))
|
||||
}
|
||||
|
||||
func main() {
|
||||
r := chi.NewRouter()
|
||||
r.Get("/custom/endpoint", customBMXHandler)
|
||||
http.ListenAndServe(":8000", r)
|
||||
}
|
||||
```
|
||||
|
||||
### Integration with Home Assistant
|
||||
|
||||
```yaml
|
||||
# configuration.yaml
|
||||
soundtouch:
|
||||
- host: 192.168.1.100
|
||||
port: 8090
|
||||
name: "Living Room Speaker"
|
||||
|
||||
rest:
|
||||
- resource: "http://localhost:8000/setup/devices"
|
||||
scan_interval: 60
|
||||
sensor:
|
||||
- name: "SoundTouch Devices"
|
||||
value_template: "{{ value_json | length }}"
|
||||
```
|
||||
|
||||
### Monitoring & Alerting
|
||||
|
||||
```bash
|
||||
# Health check script
|
||||
#!/bin/bash
|
||||
response=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:8000/health)
|
||||
if [ $response != "200" ]; then
|
||||
echo "SoundTouch service is down!" | mail -s "Alert" admin@example.com
|
||||
fi
|
||||
```
|
||||
|
||||
## Security Considerations
|
||||
|
||||
- **Network Security**: The service binds to all interfaces by default. Consider using `BIND_ADDR=127.0.0.1` for localhost-only access.
|
||||
- **SSH Access**: Migration requires SSH access to devices. Ensure your network security policies allow this.
|
||||
- **Proxy Logging**: Disable `REDACT_PROXY_LOGS` only in development environments.
|
||||
- **Data Protection**: The data directory contains device configurations and usage patterns. Secure appropriately.
|
||||
|
||||
## Performance Tuning
|
||||
|
||||
### Resource Usage
|
||||
- **Memory**: ~50MB baseline + ~5MB per discovered device
|
||||
- **CPU**: Minimal during steady state, ~10% during discovery/migration
|
||||
- **Disk**: ~1MB per device configuration + logs
|
||||
|
||||
### Scaling Considerations
|
||||
```bash
|
||||
# For many devices, increase discovery interval
|
||||
DISCOVERY_INTERVAL=10m soundtouch-service
|
||||
|
||||
# For high-traffic environments, consider reverse proxy
|
||||
nginx -> soundtouch-service instances
|
||||
```
|
||||
@@ -0,0 +1,85 @@
|
||||
### Bose Cloud Shutdown: Survival Guide for SoundTouch
|
||||
|
||||
With Bose's announcement of discontinuing cloud support for SoundTouch devices in May 2026, this project provides the necessary tools to keep your speakers fully functional using a local emulation service.
|
||||
|
||||
This guide explains how to set up the `soundtouch-service` to run your devices independently of Bose's servers.
|
||||
|
||||
---
|
||||
|
||||
### Supported Use Cases
|
||||
|
||||
1. **Local Service Emulation**: The service emulates Bose's BMX (Bose Media eXchange) and Marge services, which handle content registries, presets, recents, and software update checks.
|
||||
2. **Traffic Redirection**: Tools are provided to redirect your speakers to this local service instead of `*.bose.com`.
|
||||
3. **Offline Operation**: Once redirected, the speakers function without needing to reach Bose's servers.
|
||||
4. **Preset & Recent Management**: Captures and stores presets and "recently played" items locally.
|
||||
|
||||
---
|
||||
|
||||
### Setup Steps
|
||||
|
||||
To set up your SoundTouch system for local-only operation, follow these steps:
|
||||
|
||||
#### 1. Install and Start the Service
|
||||
Run the `soundtouch-service` on a machine that is always on (like a Raspberry Pi or a NAS) within your local network.
|
||||
|
||||
```bash
|
||||
# Install the service
|
||||
go install github.com/gesellix/bose-soundtouch/cmd/soundtouch-service@latest
|
||||
|
||||
# Start the service (defaults to http://localhost:8000)
|
||||
soundtouch-service
|
||||
```
|
||||
|
||||
#### 2. Access the Management UI
|
||||
Open your web browser and navigate to the service's web interface:
|
||||
`http://<your-server-ip>:8000/`, e.g. `http://localhost:8000/`
|
||||
|
||||
*Note: The service also supports a `/web/` path for management.*
|
||||
|
||||
#### 3. Enable SSH on Your Speakers
|
||||
To migrate your speakers, the service needs SSH access. You can enable it by:
|
||||
1. Creating an empty file named `remote_services` on a USB stick.
|
||||
2. Inserting the USB stick into the SoundTouch speaker's service port.
|
||||
3. Rebooting the speaker (unplug/replug).
|
||||
|
||||
**Verify SSH Access:**
|
||||
- Confirm the device responds to SSH without a password: `ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa root@<IP>`
|
||||
- Or use the **Migration** tab in the Web UI to see if the device shows a "✅ Success" status for SSH.
|
||||
Once enabled, you can log in as `root` (no password).
|
||||
|
||||
#### 4. Setup Through the Web UI
|
||||
The web interface handles the entire process in a guided flow. Before proceeding, we strongly recommend reviewing the [Migration & Safety Guide](MIGRATION-SAFETY.md).
|
||||
|
||||
* **Step 1: Settings**: Configure your server's IP or domain. This ensures the speakers know where to find the local services.
|
||||
* **Step 2: Devices**: The service automatically scans for SoundTouch devices on your network. If a device is not found, you can manually add its IP address.
|
||||
* **Step 3: Data Sync**: Select your device and click "Start Sync". This will automatically fetch your presets, recents, and configured sources from the speaker and store them in the local `data/` directory.
|
||||
* **Step 4: Migration**: Choose your redirection method (XML Recommended) and click "Confirm Migration". After the migration, reboot your speaker to apply the changes.
|
||||
|
||||
#### 5. Verify Your Local Data
|
||||
Once migrated, your speaker will use the data captured during the Sync step.
|
||||
* The service stores data in the `data/` directory, organized by device serial number (e.g., `data/default/devices/<SERIAL>/`).
|
||||
* **Automatic Capture**: As you use the device (changing presets, playing new music), the service continues to "learn" and update your local files.
|
||||
|
||||
---
|
||||
|
||||
### Comparison with other implementations (soundcork)
|
||||
Our implementation (`soundtouch-service`) is largely compatible with the Python-based `soundcork` project but offers several advantages:
|
||||
- **Web UI**: Integrated management interface for discovery and migration.
|
||||
- **Surgical Migration**: Uses XML-based redirection by default, which is less invasive than `/etc/hosts`.
|
||||
- **Automated SSL**: Handles Root CA injection automatically for secure communication.
|
||||
- **Proxy Support**: Can proxy requests to original Bose servers while "learning" your configuration.
|
||||
|
||||
---
|
||||
|
||||
### Alternative: DNS Redirection (No SSH)
|
||||
If you prefer not to modify your speakers via SSH, you can use a local DNS server (like Pi-hole, AdGuard Home, or Unbound) to point the following domains to your local server's IP:
|
||||
|
||||
* `bmx.bose.com`
|
||||
* `streaming.bose.com`
|
||||
* `updates.bose.com`
|
||||
* `stats.bose.com`
|
||||
* `content.api.bose.io`
|
||||
|
||||
*Note: DNS redirection for HTTPS services requires the speakers to trust your local service's SSL certificate. The SSH-based migration handles this automatically by injecting the CA.*
|
||||
|
||||
---
|
||||
@@ -817,6 +817,42 @@ Use this checklist to systematically troubleshoot issues:
|
||||
|
||||
---
|
||||
|
||||
## 🆔 **Device Identification & Mapping Issues**
|
||||
|
||||
### ❌ "File not found" errors with MAC addresses
|
||||
|
||||
**Symptoms:**
|
||||
```
|
||||
GET /streaming/account/3230304/device/A81B6A536A98/presets
|
||||
→ 500 Internal Server Error
|
||||
→ Log: "open .../devices/A81B6A536A98/Presets.xml: no such file or directory"
|
||||
```
|
||||
|
||||
**Cause:** The service uses MAC addresses in API requests but stores files using device serial numbers. A mapping system resolves MAC addresses to serial numbers automatically.
|
||||
|
||||
**Quick Solutions:**
|
||||
|
||||
1. **Restart the service** (mappings are created at startup):
|
||||
```bash
|
||||
sudo systemctl restart soundtouch-service
|
||||
```
|
||||
|
||||
2. **Check device directory structure**:
|
||||
```bash
|
||||
# Files should be stored by serial number, not MAC
|
||||
ls data/accounts/3230304/devices/
|
||||
# Should show: I6332527703739342000020/ (not A81B6A536A98/)
|
||||
```
|
||||
|
||||
3. **Verify DeviceInfo.xml contains MAC address**:
|
||||
```bash
|
||||
cat data/accounts/3230304/devices/*/DeviceInfo.xml | grep macAddress
|
||||
```
|
||||
|
||||
**For detailed diagnosis and solutions**, see: [**MAC Address Mapping Guide**](MAC-ADDRESS-MAPPING.md)
|
||||
|
||||
---
|
||||
|
||||
## 🛟 **Getting More Help**
|
||||
|
||||
### Information to Gather
|
||||
@@ -0,0 +1,90 @@
|
||||
# Images for Migration Guide
|
||||
|
||||
This directory contains images, screenshots, and diagrams referenced in the migration guide and other documentation.
|
||||
|
||||
## Required Images for Migration Guide
|
||||
|
||||
The following images need to be created to complete the migration guide:
|
||||
|
||||
### Dashboard Screenshots
|
||||
- **dashboard-home.png** - Main SoundTouch Service dashboard homepage
|
||||
- **account-creation.png** - Account creation form with fields filled
|
||||
- **account-dashboard.png** - Fresh account dashboard showing ready state
|
||||
- **device-discovery.png** - Device discovery page showing found speakers
|
||||
- **device-registration.png** - Device registration dialog with options
|
||||
- **migration-setup.png** - Migration configuration dialog
|
||||
- **migration-progress.png** - Migration progress tracker showing phases
|
||||
- **migration-health.png** - Migration health monitoring dashboard
|
||||
- **account-migration.png** - Account-wide migration progress overview
|
||||
- **migration-complete.png** - Completed migration dashboard view
|
||||
- **backup-setup.png** - Backup configuration settings page
|
||||
|
||||
### Setup and Preparation
|
||||
- **usb-remote-services.png** - USB drive setup showing file structure
|
||||
- **raspberry-pi-setup.png** - Raspberry Pi with connected cables (optional)
|
||||
|
||||
### Process Diagrams
|
||||
- **migration-flow-diagram.png** - Flow chart showing migration phases
|
||||
- **network-topology.png** - Network diagram showing Pi, router, speakers
|
||||
- **data-flow-diagram.png** - How data flows between components
|
||||
|
||||
## Image Requirements
|
||||
|
||||
### Technical Specifications
|
||||
- **Format**: PNG preferred for screenshots, SVG for diagrams
|
||||
- **Resolution**: Minimum 1200px width for screenshots
|
||||
- **File Size**: Keep under 500KB when possible for fast loading
|
||||
- **Naming**: Use descriptive kebab-case names as shown above
|
||||
|
||||
### Content Guidelines
|
||||
- **Clean Interface**: Show realistic but clean interface states
|
||||
- **Consistent Styling**: Use consistent colors and styling across images
|
||||
- **Readable Text**: Ensure all text in screenshots is legible
|
||||
- **Example Data**: Use realistic example data (Living Room Speaker, etc.)
|
||||
- **Status Indicators**: Show clear success/error states with appropriate colors
|
||||
|
||||
### Placeholder Content
|
||||
Until real screenshots are available, consider:
|
||||
- **Mockups**: Create simple mockups showing the expected interface
|
||||
- **Wireframes**: Basic wireframes indicating layout and content
|
||||
- **Diagrams**: Technical diagrams can be created immediately
|
||||
- **Text Placeholders**: Use `[Image: Description]` in documentation
|
||||
|
||||
## Creating the Images
|
||||
|
||||
### For Dashboard Screenshots
|
||||
1. Set up the enhanced SoundTouch service
|
||||
2. Create sample account and register devices
|
||||
3. Take screenshots at key points in the migration process
|
||||
4. Edit for clarity (highlight important elements, add annotations)
|
||||
|
||||
### For Diagrams
|
||||
1. Use tools like Lucidchart, draw.io, or similar
|
||||
2. Follow consistent color scheme:
|
||||
- Blue: SoundTouch Service components
|
||||
- Green: Healthy/successful states
|
||||
- Orange: Warning/in-progress states
|
||||
- Red: Error/problematic states
|
||||
- Gray: External/third-party components
|
||||
|
||||
### For Physical Setup
|
||||
1. Take photos of actual hardware setup
|
||||
2. Show USB drive preparation process
|
||||
3. Demonstrate network connections if helpful
|
||||
|
||||
## Alternative Text Requirements
|
||||
|
||||
Each image should have appropriate alt text for accessibility:
|
||||
|
||||
```markdown
|
||||

|
||||
*Caption: Additional context or explanation*
|
||||
```
|
||||
|
||||
## Future Enhancements
|
||||
|
||||
Consider adding:
|
||||
- **Video Walkthroughs**: Screen recordings of key processes
|
||||
- **Interactive Demos**: Web-based interactive guides
|
||||
- **Troubleshooting Screenshots**: Common error states and solutions
|
||||
- **Mobile Views**: How to access from mobile devices
|
||||
@@ -0,0 +1,599 @@
|
||||
# /power_on Implementation Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This guide provides detailed technical specifications for implementing `/power_on` endpoint enhancements to reduce network dependency and improve device lifecycle management in the SoundTouch service.
|
||||
|
||||
## Current /power_on Handler Analysis
|
||||
|
||||
### Existing Implementation
|
||||
Located in `pkg/service/handlers/handlers_marge.go`:
|
||||
|
||||
```go
|
||||
func (s *Server) HandleMargePowerOn(w http.ResponseWriter, r *http.Request) {
|
||||
body, err := io.ReadAll(r.Body)
|
||||
if err != nil {
|
||||
log.Printf("[Marge] Failed to read power_on body: %v", err)
|
||||
w.WriteHeader(http.StatusOK)
|
||||
return
|
||||
}
|
||||
|
||||
var req models.CustomerSupportRequest
|
||||
if err := xml.Unmarshal(body, &req); err != nil {
|
||||
log.Printf("[Marge] Failed to parse power_on body: %v", err)
|
||||
// Fallback to remote address
|
||||
if host, _, err := net.SplitHostPort(r.RemoteAddr); err == nil {
|
||||
go s.PrimeDeviceWithSpotify(host)
|
||||
}
|
||||
w.WriteHeader(http.StatusOK)
|
||||
return
|
||||
}
|
||||
|
||||
deviceID := req.Device.ID
|
||||
deviceIP := req.DiagnosticData.DeviceLandscape.IPAddress
|
||||
|
||||
log.Printf("[Marge] Device %s powered on (IP: %s)", deviceID, deviceIP)
|
||||
|
||||
if deviceIP != "" {
|
||||
go s.PrimeDeviceWithSpotify(deviceIP)
|
||||
} else {
|
||||
// Fallback to remote address
|
||||
if host, _, err := net.SplitHostPort(r.RemoteAddr); err == nil {
|
||||
go s.PrimeDeviceWithSpotify(host)
|
||||
}
|
||||
}
|
||||
|
||||
w.WriteHeader(http.StatusOK)
|
||||
}
|
||||
```
|
||||
|
||||
**Current Limitations:**
|
||||
- Only extracts basic device ID and IP
|
||||
- No device state management
|
||||
- No data persistence
|
||||
- No response payload
|
||||
- Limited to Spotify priming
|
||||
|
||||
## Enhanced Implementation Design
|
||||
|
||||
### 1. Extended Data Models
|
||||
|
||||
#### Enhanced Power-On Request Model
|
||||
```go
|
||||
// PowerOnRequest represents the enhanced power_on request structure
|
||||
type PowerOnRequest struct {
|
||||
XMLName xml.Name `xml:"device-data"`
|
||||
Device PowerOnDevice `xml:"device"`
|
||||
DiagnosticData DiagnosticData `xml:"diagnostic-data"`
|
||||
}
|
||||
|
||||
type PowerOnDevice struct {
|
||||
ID string `xml:"id,attr"`
|
||||
SerialNumber string `xml:"serialnumber"`
|
||||
FirmwareVersion string `xml:"firmware-version"`
|
||||
Product PowerOnProduct `xml:"product"`
|
||||
}
|
||||
|
||||
type PowerOnProduct struct {
|
||||
ProductCode string `xml:"product_code,attr"`
|
||||
Type string `xml:"type,attr"`
|
||||
SerialNumber string `xml:"serialnumber"`
|
||||
}
|
||||
|
||||
type DiagnosticData struct {
|
||||
DeviceLandscape DeviceLandscape `xml:"device-landscape"`
|
||||
NetworkData NetworkData `xml:"network-landscape>network-data"`
|
||||
}
|
||||
|
||||
type DeviceLandscape struct {
|
||||
RSSI string `xml:"rssi"`
|
||||
GatewayIP string `xml:"gateway-ip-address"`
|
||||
MacAddresses []string `xml:"macaddresses>macaddress"`
|
||||
IPAddress string `xml:"ip-address"`
|
||||
ConnectionType string `xml:"network-connection-type"`
|
||||
}
|
||||
```
|
||||
|
||||
#### Enhanced Response Model
|
||||
```go
|
||||
// PowerOnResponse represents the response sent back to the device
|
||||
type PowerOnResponse struct {
|
||||
XMLName xml.Name `xml:"power-on-response"`
|
||||
Status string `xml:"status"`
|
||||
DeviceID string `xml:"device-id"`
|
||||
ConfigurationUpdates []ConfigurationUpdate `xml:"configuration-updates>update,omitempty"`
|
||||
MigrationInstructions *MigrationInstruction `xml:"migration,omitempty"`
|
||||
RegistrationRequired bool `xml:"registration-required,omitempty"`
|
||||
Timestamp string `xml:"timestamp"`
|
||||
}
|
||||
|
||||
type ConfigurationUpdate struct {
|
||||
Type string `xml:"type,attr"`
|
||||
Key string `xml:"key"`
|
||||
Value string `xml:"value"`
|
||||
Priority int `xml:"priority,attr"`
|
||||
}
|
||||
|
||||
type MigrationInstruction struct {
|
||||
Method string `xml:"method,attr"`
|
||||
TargetURL string `xml:"target-url"`
|
||||
ProxyURL string `xml:"proxy-url,omitempty"`
|
||||
Options map[string]string `xml:"options>option"`
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Enhanced PowerOn Handler
|
||||
|
||||
```go
|
||||
// HandleMargePowerOnEnhanced processes power_on requests with full device lifecycle management
|
||||
func (s *Server) HandleMargePowerOnEnhanced(w http.ResponseWriter, r *http.Request) {
|
||||
startTime := time.Now()
|
||||
|
||||
// Parse the power_on request
|
||||
powerOnReq, err := s.parsePowerOnRequest(r)
|
||||
if err != nil {
|
||||
s.handlePowerOnError(w, r, "Failed to parse request", err)
|
||||
return
|
||||
}
|
||||
|
||||
// Process device information
|
||||
deviceInfo, isNewDevice, err := s.processDeviceFromPowerOn(powerOnReq)
|
||||
if err != nil {
|
||||
s.handlePowerOnError(w, r, "Failed to process device", err)
|
||||
return
|
||||
}
|
||||
|
||||
// Build response based on device state
|
||||
response := s.buildPowerOnResponse(deviceInfo, isNewDevice, powerOnReq)
|
||||
|
||||
// Log the interaction
|
||||
s.logPowerOnInteraction(deviceInfo, powerOnReq, response, startTime)
|
||||
|
||||
// Send response
|
||||
if err := s.sendPowerOnResponse(w, response); err != nil {
|
||||
log.Printf("[PowerOn] Failed to send response for device %s: %v", deviceInfo.DeviceID, err)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Device Processing Logic
|
||||
|
||||
```go
|
||||
// processDeviceFromPowerOn handles device identification and data updates
|
||||
func (s *Server) processDeviceFromPowerOn(req *PowerOnRequest) (*models.ServiceDeviceInfo, bool, error) {
|
||||
deviceMAC := req.Device.ID
|
||||
deviceIP := req.DiagnosticData.DeviceLandscape.IPAddress
|
||||
|
||||
// Try to find existing device by MAC address (primary identifier)
|
||||
existingDevice, err := s.ds.GetDeviceByMAC(deviceMAC)
|
||||
if err != nil && err != datastore.ErrDeviceNotFound {
|
||||
return nil, false, fmt.Errorf("failed to lookup device: %w", err)
|
||||
}
|
||||
|
||||
var deviceInfo *models.ServiceDeviceInfo
|
||||
isNewDevice := existingDevice == nil
|
||||
|
||||
if isNewDevice {
|
||||
// Create new device record from power_on data
|
||||
deviceInfo = s.createDeviceFromPowerOn(req)
|
||||
|
||||
// Store in datastore
|
||||
if err := s.ds.SaveDeviceInfo("", deviceMAC, deviceInfo); err != nil {
|
||||
return nil, false, fmt.Errorf("failed to save new device: %w", err)
|
||||
}
|
||||
|
||||
log.Printf("[PowerOn] New device registered: %s (IP: %s, Model: %s)",
|
||||
deviceMAC, deviceIP, deviceInfo.ProductCode)
|
||||
} else {
|
||||
// Update existing device with power_on data
|
||||
deviceInfo = existingDevice
|
||||
s.updateDeviceFromPowerOn(deviceInfo, req)
|
||||
|
||||
// Detect significant changes
|
||||
if s.hasSignificantChanges(existingDevice, deviceInfo) {
|
||||
log.Printf("[PowerOn] Device %s updated: IP %s->%s, FW %s->%s",
|
||||
deviceMAC, existingDevice.IPAddress, deviceInfo.IPAddress,
|
||||
existingDevice.FirmwareVersion, deviceInfo.FirmwareVersion)
|
||||
}
|
||||
|
||||
// Save updated device info
|
||||
if err := s.ds.SaveDeviceInfo(deviceInfo.AccountID, deviceMAC, deviceInfo); err != nil {
|
||||
return nil, false, fmt.Errorf("failed to update device: %w", err)
|
||||
}
|
||||
}
|
||||
|
||||
// Update device mappings for lookup optimization
|
||||
s.ds.UpdateDeviceMappings(*deviceInfo)
|
||||
|
||||
return deviceInfo, isNewDevice, nil
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Device Creation from Power-On Data
|
||||
|
||||
```go
|
||||
// createDeviceFromPowerOn creates a new ServiceDeviceInfo from power_on request
|
||||
func (s *Server) createDeviceFromPowerOn(req *PowerOnRequest) *models.ServiceDeviceInfo {
|
||||
now := time.Now()
|
||||
|
||||
deviceInfo := &models.ServiceDeviceInfo{
|
||||
DeviceID: req.Device.ID, // MAC address
|
||||
ProductCode: req.Device.Product.ProductCode,
|
||||
DeviceSerialNumber: req.Device.SerialNumber,
|
||||
ProductSerialNumber: req.Device.Product.SerialNumber,
|
||||
FirmwareVersion: req.Device.FirmwareVersion,
|
||||
IPAddress: req.DiagnosticData.DeviceLandscape.IPAddress,
|
||||
MacAddress: req.Device.ID, // Primary MAC
|
||||
DiscoveryMethod: "power_on",
|
||||
LastSeen: now,
|
||||
CreatedAt: now,
|
||||
UpdatedAt: now,
|
||||
}
|
||||
|
||||
// Generate default name if not provided
|
||||
if deviceInfo.Name == "" {
|
||||
deviceInfo.Name = s.generateDefaultDeviceName(deviceInfo)
|
||||
}
|
||||
|
||||
// Add power_on specific metadata
|
||||
deviceInfo.Metadata = map[string]string{
|
||||
"rssi": req.DiagnosticData.DeviceLandscape.RSSI,
|
||||
"gateway_ip": req.DiagnosticData.DeviceLandscape.GatewayIP,
|
||||
"connection_type": req.DiagnosticData.DeviceLandscape.ConnectionType,
|
||||
"power_on_count": "1",
|
||||
}
|
||||
|
||||
// Store additional MAC addresses if available
|
||||
if len(req.DiagnosticData.DeviceLandscape.MacAddresses) > 1 {
|
||||
additionalMACs := make([]string, 0, len(req.DiagnosticData.DeviceLandscape.MacAddresses)-1)
|
||||
for _, mac := range req.DiagnosticData.DeviceLandscape.MacAddresses {
|
||||
if mac != req.Device.ID {
|
||||
additionalMACs = append(additionalMACs, mac)
|
||||
}
|
||||
}
|
||||
if len(additionalMACs) > 0 {
|
||||
deviceInfo.Metadata["additional_macs"] = strings.Join(additionalMACs, ",")
|
||||
}
|
||||
}
|
||||
|
||||
return deviceInfo
|
||||
}
|
||||
```
|
||||
|
||||
### 5. Response Generation Logic
|
||||
|
||||
```go
|
||||
// buildPowerOnResponse creates appropriate response based on device state
|
||||
func (s *Server) buildPowerOnResponse(deviceInfo *models.ServiceDeviceInfo, isNewDevice bool, req *PowerOnRequest) *PowerOnResponse {
|
||||
response := &PowerOnResponse{
|
||||
Status: "ok",
|
||||
DeviceID: deviceInfo.DeviceID,
|
||||
Timestamp: time.Now().Format(time.RFC3339),
|
||||
}
|
||||
|
||||
// Handle new device registration
|
||||
if isNewDevice {
|
||||
response.RegistrationRequired = deviceInfo.AccountID == ""
|
||||
|
||||
// Add welcome configuration for new devices
|
||||
response.ConfigurationUpdates = []ConfigurationUpdate{
|
||||
{
|
||||
Type: "welcome",
|
||||
Key: "device_registered",
|
||||
Value: "true",
|
||||
Priority: 1,
|
||||
},
|
||||
}
|
||||
}
|
||||
|
||||
// Check if migration is needed
|
||||
if s.needsMigration(deviceInfo) {
|
||||
migration := s.getMigrationInstructions(deviceInfo)
|
||||
response.MigrationInstructions = migration
|
||||
|
||||
log.Printf("[PowerOn] Migration required for device %s: %s",
|
||||
deviceInfo.DeviceID, migration.Method)
|
||||
}
|
||||
|
||||
// Add any pending configuration updates
|
||||
pendingUpdates := s.getPendingConfigurationUpdates(deviceInfo)
|
||||
response.ConfigurationUpdates = append(response.ConfigurationUpdates, pendingUpdates...)
|
||||
|
||||
return response
|
||||
}
|
||||
```
|
||||
|
||||
### 6. Device Lookup Enhancements
|
||||
|
||||
#### Enhanced DataStore Methods
|
||||
```go
|
||||
// GetDeviceByMAC finds a device by MAC address across all accounts
|
||||
func (ds *DataStore) GetDeviceByMAC(macAddress string) (*models.ServiceDeviceInfo, error) {
|
||||
normalizedMAC := normalizeMAC(macAddress)
|
||||
|
||||
// Check device mappings first (for performance)
|
||||
ds.idMutex.RLock()
|
||||
deviceID, exists := ds.deviceMappings[normalizedMAC]
|
||||
ds.idMutex.RUnlock()
|
||||
|
||||
if exists {
|
||||
// Try to find device by mapped ID
|
||||
device, err := ds.findDeviceByID(deviceID)
|
||||
if err == nil {
|
||||
return device, nil
|
||||
}
|
||||
}
|
||||
|
||||
// Fallback to full scan
|
||||
devices, err := ds.ListAllDevices()
|
||||
if err != nil {
|
||||
return nil, err
|
||||
}
|
||||
|
||||
for _, device := range devices {
|
||||
if normalizeMAC(device.MacAddress) == normalizedMAC ||
|
||||
normalizeMAC(device.DeviceID) == normalizedMAC {
|
||||
return &device, nil
|
||||
}
|
||||
|
||||
// Check additional MAC addresses in metadata
|
||||
if additionalMACs, exists := device.Metadata["additional_macs"]; exists {
|
||||
for _, mac := range strings.Split(additionalMACs, ",") {
|
||||
if normalizeMAC(mac) == normalizedMAC {
|
||||
return &device, nil
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
return nil, datastore.ErrDeviceNotFound
|
||||
}
|
||||
```
|
||||
|
||||
### 7. Migration Integration
|
||||
|
||||
```go
|
||||
// needsMigration determines if device requires configuration migration
|
||||
func (s *Server) needsMigration(deviceInfo *models.ServiceDeviceInfo) bool {
|
||||
if deviceInfo.AccountID == "" {
|
||||
return false // Cannot migrate without account
|
||||
}
|
||||
|
||||
// Check if device is already migrated
|
||||
if s.sm != nil {
|
||||
summary, err := s.sm.GetMigrationSummary(deviceInfo.IPAddress, s.ServerURL, "", nil)
|
||||
if err == nil && summary.IsMigrated {
|
||||
return false
|
||||
}
|
||||
}
|
||||
|
||||
return true
|
||||
}
|
||||
|
||||
// getMigrationInstructions creates migration instructions for device
|
||||
func (s *Server) getMigrationInstructions(deviceInfo *models.ServiceDeviceInfo) *MigrationInstruction {
|
||||
return &MigrationInstruction{
|
||||
Method: "xml", // Default to XML-based migration
|
||||
TargetURL: s.ServerURL,
|
||||
Options: map[string]string{
|
||||
"marge": "true",
|
||||
"stats": "true",
|
||||
"sw_update": "true",
|
||||
},
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 8. Error Handling and Fallbacks
|
||||
|
||||
```go
|
||||
// handlePowerOnError provides graceful error handling with fallbacks
|
||||
func (s *Server) handlePowerOnError(w http.ResponseWriter, r *http.Request, message string, err error) {
|
||||
log.Printf("[PowerOn] %s: %v", message, err)
|
||||
|
||||
// Try to extract IP from request for fallback processing
|
||||
if host, _, err := net.SplitHostPort(r.RemoteAddr); err == nil {
|
||||
// Fallback to existing discovery mechanism
|
||||
go s.PrimeDeviceWithSpotify(host)
|
||||
log.Printf("[PowerOn] Falling back to legacy processing for IP %s", host)
|
||||
}
|
||||
|
||||
// Always return 200 OK to avoid device retry loops
|
||||
w.WriteHeader(http.StatusOK)
|
||||
}
|
||||
|
||||
// parsePowerOnRequest safely parses the power_on request with validation
|
||||
func (s *Server) parsePowerOnRequest(r *http.Request) (*PowerOnRequest, error) {
|
||||
body, err := io.ReadAll(r.Body)
|
||||
if err != nil {
|
||||
return nil, fmt.Errorf("failed to read request body: %w", err)
|
||||
}
|
||||
|
||||
if len(body) == 0 {
|
||||
return nil, fmt.Errorf("empty request body")
|
||||
}
|
||||
|
||||
var req PowerOnRequest
|
||||
if err := xml.Unmarshal(body, &req); err != nil {
|
||||
return nil, fmt.Errorf("failed to parse XML: %w", err)
|
||||
}
|
||||
|
||||
// Validate required fields
|
||||
if req.Device.ID == "" {
|
||||
return nil, fmt.Errorf("missing device ID")
|
||||
}
|
||||
|
||||
if req.DiagnosticData.DeviceLandscape.IPAddress == "" {
|
||||
return nil, fmt.Errorf("missing device IP address")
|
||||
}
|
||||
|
||||
return &req, nil
|
||||
}
|
||||
```
|
||||
|
||||
### 9. Logging and Monitoring
|
||||
|
||||
```go
|
||||
// logPowerOnInteraction records detailed interaction logs for debugging
|
||||
func (s *Server) logPowerOnInteraction(deviceInfo *models.ServiceDeviceInfo, req *PowerOnRequest, resp *PowerOnResponse, startTime time.Time) {
|
||||
duration := time.Since(startTime)
|
||||
|
||||
log.Printf("[PowerOn] Device: %s, IP: %s, Duration: %v, Status: %s, NewDevice: %t, Migration: %t",
|
||||
deviceInfo.DeviceID,
|
||||
req.DiagnosticData.DeviceLandscape.IPAddress,
|
||||
duration,
|
||||
resp.Status,
|
||||
resp.RegistrationRequired,
|
||||
resp.MigrationInstructions != nil)
|
||||
|
||||
// Store interaction for debugging (if enabled)
|
||||
if s.config.RecordInteractions {
|
||||
interaction := models.DeviceInteraction{
|
||||
Timestamp: startTime,
|
||||
DeviceID: deviceInfo.DeviceID,
|
||||
Type: "power_on",
|
||||
Request: req,
|
||||
Response: resp,
|
||||
Duration: duration,
|
||||
IPAddress: req.DiagnosticData.DeviceLandscape.IPAddress,
|
||||
UserAgent: r.Header.Get("User-Agent"),
|
||||
}
|
||||
|
||||
if err := s.ds.SaveInteraction(interaction); err != nil {
|
||||
log.Printf("[PowerOn] Failed to save interaction: %v", err)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 10. Configuration and Feature Flags
|
||||
|
||||
```go
|
||||
// PowerOnConfig controls behavior of enhanced power_on processing
|
||||
type PowerOnConfig struct {
|
||||
EnableEnhancedProcessing bool `json:"enable_enhanced_processing"`
|
||||
AutoMigration bool `json:"auto_migration"`
|
||||
RecordInteractions bool `json:"record_interactions"`
|
||||
DefaultResponseTimeout time.Duration `json:"default_response_timeout"`
|
||||
FallbackToLegacy bool `json:"fallback_to_legacy"`
|
||||
}
|
||||
|
||||
// loadPowerOnConfig loads configuration with defaults
|
||||
func loadPowerOnConfig() *PowerOnConfig {
|
||||
return &PowerOnConfig{
|
||||
EnableEnhancedProcessing: true,
|
||||
AutoMigration: false, // Conservative default
|
||||
RecordInteractions: false,
|
||||
DefaultResponseTimeout: 5 * time.Second,
|
||||
FallbackToLegacy: true,
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### 1. Unit Tests
|
||||
```go
|
||||
func TestHandleMargePowerOnEnhanced(t *testing.T) {
|
||||
tests := []struct {
|
||||
name string
|
||||
requestBody string
|
||||
existingDevice *models.ServiceDeviceInfo
|
||||
expectedStatus string
|
||||
expectMigration bool
|
||||
}{
|
||||
{
|
||||
name: "new_device_registration",
|
||||
requestBody: `<device-data><device id="A81B6A536A98">...</device></device-data>`,
|
||||
existingDevice: nil,
|
||||
expectedStatus: "ok",
|
||||
expectMigration: false,
|
||||
},
|
||||
{
|
||||
name: "existing_device_update",
|
||||
requestBody: `<device-data><device id="A81B6A536A98">...</device></device-data>`,
|
||||
existingDevice: &models.ServiceDeviceInfo{DeviceID: "A81B6A536A98"},
|
||||
expectedStatus: "ok",
|
||||
expectMigration: true,
|
||||
},
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
// Test implementation
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Integration Tests
|
||||
```go
|
||||
func TestPowerOnDeviceLifecycle(t *testing.T) {
|
||||
// Test complete device lifecycle through power_on events
|
||||
// 1. New device power_on
|
||||
// 2. Device registration
|
||||
// 3. Configuration changes
|
||||
// 4. Migration
|
||||
// 5. Subsequent power_on events
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Load Testing
|
||||
```go
|
||||
func BenchmarkPowerOnProcessing(b *testing.B) {
|
||||
// Benchmark power_on processing performance
|
||||
// Test concurrent device registrations
|
||||
// Measure response times
|
||||
}
|
||||
```
|
||||
|
||||
## Deployment Strategy
|
||||
|
||||
### Phase 1: Parallel Implementation
|
||||
- Implement enhanced handler alongside existing handler
|
||||
- Use feature flag to control which handler processes requests
|
||||
- Maintain full backward compatibility
|
||||
|
||||
### Phase 2: Gradual Rollout
|
||||
- Enable enhanced processing for subset of devices
|
||||
- Monitor performance and error rates
|
||||
- Collect metrics on data completeness
|
||||
|
||||
### Phase 3: Full Migration
|
||||
- Default to enhanced processing for all devices
|
||||
- Remove legacy fallbacks
|
||||
- Optimize performance based on production data
|
||||
|
||||
## Monitoring and Metrics
|
||||
|
||||
### Key Metrics to Track
|
||||
- Power-on event frequency per device
|
||||
- New device registration rate via power_on
|
||||
- Migration success rate via power_on response
|
||||
- Response time distribution
|
||||
- Error rates and types
|
||||
- Data completeness metrics
|
||||
|
||||
### Alerting Thresholds
|
||||
- Power-on processing failures > 5%
|
||||
- Average response time > 2 seconds
|
||||
- New device registration failures > 1%
|
||||
- Migration instruction delivery failures > 2%
|
||||
|
||||
## Security Considerations
|
||||
|
||||
### Input Validation
|
||||
- XML parsing security (prevent XXE attacks)
|
||||
- Device ID format validation
|
||||
- IP address validation
|
||||
- Request size limits
|
||||
|
||||
### Authentication
|
||||
- Device authentication via MAC address verification
|
||||
- Request signing (if available)
|
||||
- Rate limiting per device/IP
|
||||
|
||||
### Data Privacy
|
||||
- Sensitive data handling in diagnostic information
|
||||
- Logging data retention policies
|
||||
- Compliance with data protection regulations
|
||||
@@ -418,10 +418,10 @@ soundtouch-cli -host <discovered-ip> -bass # Verify final state
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- **[API Endpoints Overview](API-Endpoints-Overview.md)** - Complete API reference
|
||||
- **[API Endpoints Overview](API-ENDPOINTS.md)** - Complete API reference
|
||||
- **[Volume Controls](VOLUME-CONTROLS.md)** - Related audio control documentation
|
||||
- **[Client Usage Examples](../cmd/soundtouch-cli/main.go)** - CLI implementation reference
|
||||
- **[Models](../pkg/models/bass.go)** - Bass model implementation
|
||||
- **[Client Usage Examples](../../cmd/soundtouch-cli/main.go)** - CLI implementation reference
|
||||
- **[Models](../../pkg/models/bass.go)** - Bass model implementation
|
||||
|
||||
## API Compliance
|
||||
|
||||
@@ -443,4 +443,4 @@ The implementation follows the official SoundTouch API:
|
||||
**Implementation Date**: 2026-01-09
|
||||
**Status**: ✅ Complete and tested
|
||||
**Real Device Validation**: SoundTouch 10, SoundTouch 20
|
||||
**API Compliance**: Full compliance with SoundTouch Web API specification
|
||||
**API Compliance**: Full compliance with SoundTouch Web API specification
|
||||
@@ -0,0 +1,73 @@
|
||||
# Bose SoundTouch Cloud API Emulation (Marge/BMX/Stats)
|
||||
|
||||
This document describes the cloud-emulation APIs provided by the SoundTouch service. These APIs mimic the Bose cloud services (Marge, BMX, Stats) that SoundTouch devices and the SoundTouch controller application (Stockholm) interact with.
|
||||
|
||||
## Marge API (Account & Configuration)
|
||||
|
||||
Base path: `/marge`
|
||||
|
||||
### GET /streaming/sourceproviders
|
||||
Retrieves a list of available streaming source providers.
|
||||
|
||||
### GET /accounts/{accountId}/full
|
||||
Retrieves the full account configuration including sources, presets, and devices.
|
||||
|
||||
### GET /streaming/account/{accountId}/emailaddress
|
||||
Retrieves the email address associated with the account.
|
||||
|
||||
### GET /streaming/device_setting/account/{accountId}/device/{deviceId}/device_settings
|
||||
Retrieves settings for a specific device (e.g., clock format).
|
||||
|
||||
### POST /streaming/device_setting/account/{accountId}/device/{deviceId}/device_settings
|
||||
Updates settings for a specific device.
|
||||
|
||||
### POST /accounts/{accountId}/devices/{deviceId}/presets/{presetNumber}
|
||||
Updates a preset for a device.
|
||||
|
||||
### POST /accounts/{accountId}/devices/{deviceId}/recents
|
||||
Adds an item to the device's recently played history.
|
||||
|
||||
### POST /accounts/{accountId}/devices
|
||||
Adds a device to the account.
|
||||
|
||||
### DELETE /accounts/{accountId}/devices/{deviceId}
|
||||
Removes a device from the account.
|
||||
|
||||
## Customer API (Profile & Password)
|
||||
|
||||
Base path: `/customer`
|
||||
|
||||
### GET /account/{accountId}
|
||||
Retrieves the customer account profile.
|
||||
|
||||
### POST /account/{accountId}
|
||||
Updates the customer account profile.
|
||||
|
||||
### POST /account/{accountId}/password
|
||||
Changes the account password.
|
||||
|
||||
## Analytics & Stats API
|
||||
|
||||
Base path: `/v1` (App Events) or `/streaming/stats` (Device Stats)
|
||||
|
||||
### POST /v1/stapp/{deviceId}
|
||||
Endpoint called by Bose SoundTouch mobile and web applications (Stockholm) to submit event data.
|
||||
|
||||
### POST /v1/scmudc/{deviceId}
|
||||
Endpoint equivalent to `/v1/stapp/{deviceId}` sometimes used by apps or devices.
|
||||
|
||||
### POST /streaming/stats/usage
|
||||
Endpoint used by physical devices to report usage statistics.
|
||||
|
||||
### POST /streaming/stats/error
|
||||
Endpoint used by physical devices to report error statistics.
|
||||
|
||||
## BMX API (Streaming & Registry)
|
||||
|
||||
Base path: `/bmx`
|
||||
|
||||
### GET /registry/v1/services
|
||||
Retrieves the registry of available streaming services.
|
||||
|
||||
### GET /tunein/v1/playback/station/{stationID}
|
||||
Retrieves playback information for a TuneIn station.
|
||||
@@ -366,7 +366,7 @@ This implementation now provides the full preset management lifecycle:
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- [API Endpoints Overview](API-Endpoints-Overview.md) - Complete API reference
|
||||
- [API Endpoints Overview](API-ENDPOINTS.md) - Complete API reference
|
||||
- [Volume Controls](VOLUME-CONTROLS.md) - Volume management
|
||||
- [Key Controls](KEY-CONTROLS.md) - Media control commands
|
||||
- [Source Selection](SOURCE-SELECTION.md) - Audio source management
|
||||
@@ -375,4 +375,4 @@ This implementation now provides the full preset management lifecycle:
|
||||
|
||||
Preset management in the Bose SoundTouch API is **intentionally read-only** by design. The API provides excellent capabilities for analyzing and understanding preset configurations, but preset creation must be done through official channels (app or device). This is a deliberate design decision that respects user control over their personal preset configurations.
|
||||
|
||||
For most use cases, reading preset information is sufficient for building applications that work with existing user configurations. For preset creation, guide users to use the official app or device controls, which provide the proper user experience and validation.
|
||||
For most use cases, reading preset information is sufficient for building applications that work with existing user configurations. For preset creation, guide users to use the official app or device controls, which provide the proper user experience and validation.
|
||||
@@ -38,6 +38,7 @@ The Bose SoundTouch Go client provides comprehensive source selection functional
|
||||
- `IHEARTRADIO` - iHeartRadio streaming
|
||||
- `STORED_MUSIC` - Local/network stored music
|
||||
- `AIRPLAY` - Apple AirPlay (device dependent)
|
||||
- `RADIO_BROWSER` - [RadioBrowser](radio-browser.md) internet radio directory
|
||||
|
||||
## Client Library Usage
|
||||
|
||||
@@ -345,13 +346,13 @@ The implementation follows the official SoundTouch API:
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- **[API Endpoints Overview](API-Endpoints-Overview.md)** - Complete API reference
|
||||
- **[Sources](../pkg/models/sources.go)** - Source model implementation
|
||||
- **[Now Playing](../pkg/models/nowplaying.go)** - ContentItem model
|
||||
- **[Client Usage Examples](../cmd/soundtouch-cli/main.go)** - CLI implementation reference
|
||||
- **[API Endpoints Overview](API-ENDPOINTS.md)** - Complete API reference
|
||||
- **[Sources](../../pkg/models/sources.go)** - Source model implementation
|
||||
- **[Now Playing](../../pkg/models/nowplaying.go)** - ContentItem model
|
||||
- **[Client Usage Examples](../../cmd/soundtouch-cli/main.go)** - CLI implementation reference
|
||||
|
||||
---
|
||||
|
||||
**Implementation Date**: 2026-01-09
|
||||
**Status**: ✅ Complete and tested
|
||||
**Real Device Validation**: SoundTouch 10, SoundTouch 20
|
||||
**Real Device Validation**: SoundTouch 10, SoundTouch 20
|
||||
@@ -68,14 +68,14 @@ func main() {
|
||||
|
||||
client := client.NewClient(config)
|
||||
|
||||
// Play TTS at current volume
|
||||
err := client.PlayTTS("Hello, this is a test message", "YOUR_APP_KEY")
|
||||
// Play TTS at current volume (language code "EN", "DE", etc.)
|
||||
err := client.PlayTTS("Hello, this is a test message", "YOUR_APP_KEY", "EN")
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
// Play TTS at specific volume (70)
|
||||
err = client.PlayTTS("Volume test message", "YOUR_APP_KEY", 70)
|
||||
err = client.PlayTTS("Volume test message", "YOUR_APP_KEY", "EN", 70)
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
@@ -277,7 +277,7 @@ You'll need to provide your own application key. The format and generation metho
|
||||
|
||||
```go
|
||||
// Doorbell notification
|
||||
client.PlayTTS("Someone is at the front door", "home-automation-key", 80)
|
||||
client.PlayTTS("Someone is at the front door", "home-automation-key", "EN", 80)
|
||||
|
||||
// Security alert
|
||||
client.PlayURL(
|
||||
@@ -311,4 +311,4 @@ soundtouch-cli speaker url --url "https://www.soundjay.com/misc/sounds/bell-ring
|
||||
4. **URL content fails**: Ensure URL is accessible and contains valid audio
|
||||
5. **Volume not restored**: May occur if device is powered off during playback
|
||||
|
||||
For more information, see the [SoundTouch WebServices API documentation](https://github.com/thlucas1/homeassistantcomponent_soundtouchplus/wiki/SoundTouch-WebServices-API).
|
||||
For more information, see the [SoundTouch WebServices API documentation](https://github.com/thlucas1/homeassistantcomponent_soundtouchplus/wiki/SoundTouch-WebServices-API).
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user