Support device telemetry events (POST /v1/scmudc/{deviceId})

[timvw]

Device trigger

Continuous — the speaker posts real-time telemetry events during any activity: power on/off, playback, volume changes, source switches, etc. Events are sent in bursts tied to speaker sessions (not continuous background polling).

Request

POST /v1/scmudc/{deviceId}
Content-Type: text/json; charset=utf-8
User-Agent: Bose_Lisa/27.0.6
Authorization: Bearer {bose_streaming_token}

{
  "envelope": {
    "monoTime": 85114714,
    "payloadProtocolVersion": "3.1",
    "payloadType": "scmudc",
    "protocolVersion": "1.0",
    "time": "2026-02-18T19:44:13+00:00",
    "uniqueId": "{deviceId}"
  },
  "payload": {
    "deviceInfo": {
      "boseID": "{accountId}",
      "deviceID": "{deviceId}",
      "deviceType": "SoundTouch 20",
      "serialNumber": "...",
      "softwareVersion": "27.0.6...",
      "systemSerialNumber": "..."
    },
    "events": [
      {
        "type": "play-state-changed",
        "data": { "play-state": "PLAY_STATE" },
        "monoTime": 85116135,
        "time": "2026-02-18T19:44:15+00:00"
      }
    ]
  }
}

Observed event types

Type	Data fields	Description
power-pressed	buttonId, origin (e.g. "gabbo")	Power button pressed
system-state-changed	system-state, full nowPlaying snapshot	Speaker turned on/off
play-item	contentItem (base64 XML), origin, preset	Started playing an item
source-state-changed	source-state (e.g. "TUNEIN")	Active source changed
play-state-changed	play-state ("BUFFERING_STATE", "PLAY_STATE")	Playback state transition
volume-change	startTime, volume-change (array of levels)	Volume level changed
art-changed	art-status, art-uri	Album art updated

The contentItem in play-item events is base64-encoded XML:

<ContentItem source="TUNEIN" type="stationurl" location="/v1/playback/station/s2398"
             sourceAccount="" isPresetable="true">
    <itemName>Station Name</itemName>
    <containerArt>https://cdn-profiles.tunein.com/.../logoq.jpg</containerArt>
</ContentItem>

Expected response

200 OK — no body required.

This is fire-and-forget telemetry. The speaker doesn't depend on the response for any functionality.

Current behavior

404 Not Found — no route defined. This generates hundreds of unnecessary log entries per speaker session.

Notes

• scmudc is in Bose's Analytics & Stats API, equivalent to POST /v1/stapp/{deviceId} used by the mobile app (see gesellix/Bose-SoundTouch CLOUD-API.md)
• The ueberboese-api also handles this endpoint — their RequestLoggingFilter specifically matches /v1/scmudc/.*
• The speaker authenticates with a Bearer token (Bose streaming token from /streaming_token)
• The real Bose server was at streamingoauth.bose.com (now returns 400 "Invalid provider")
• Also related: POST /streaming/stats/usage and POST /streaming/stats/error (device usage/error reporting)
• Traffic pattern: bursts during activity (power on → ~50-170 events in minutes), silent when idle
• Captured on SoundTouch 20, firmware 27.0.6

[gmuth]

I observed burst activity only when tinkering with configs and non Bose components like soundcork. I think under normal circumstances the device or the Bose App does not send/burst calls to events API.

[timvw]

That's a fair point. Most of the bursts I captured were during active tinkering too — power cycling, switching sources, adjusting volume. The speaker fires events for each state transition, so a busy session adds up fast.

During steady-state playback (e.g., TuneIn streaming for an hour) I'd expect minimal traffic — maybe a play-state-changed at start and an occasional art-changed. The volume of events in my captures (~50-170 per session) reflects the debugging activity.

Either way, the handler is just a 200 OK stub — purely to avoid log noise from the 404s. No processing, no storage. If someone later wants to build a local analytics dashboard from these events, the payload structure is documented here for reference.

[pahenning]

Also changes of the group status are posted here.