I’m working on a Matter 1.6 video doorbell and I think I’ve hit a platform-side limitation in how SmartThings hands out the clip upload location. Posting here first in case I’ve misread something.
Symptom
Same device, same fabric, same session — the only difference is who starts the recording:
| Recording started by | Result |
|---|---|
| SmartThings app |  uploads, appears in the app, plays fine |
| Button press on the device |  every object rejected with HTTP 404 |
PUT <upload-url>/session_5/index.mpd
HTTP/2 404
{"requestId":"<redacted>","error":{"code":"ClipRecordNotFound", ... }}
What’s on the wire
T+0s ModifyPushTransport URL = .../matter/clips/<clip-uuid-A>/
T+1s ManuallyTriggerTransport → uploads session_N/… ✅ playable
T+65s ModifyPushTransport URL = .../matter/clips/<clip-uuid-B>/ ← brand new uuid
T+66s ManuallyTriggerTransport → uploads session_N+1/… ✅ playable
A fresh clip UUID is issued about one second before each recording. A camera that triggers itself can’t participate in that — it only has the URL currently stored in its transport, i.e. the previously-issued UUID. That UUID accepted an earlier session successfully, but returns 404 ClipRecordNotFound for the next one. Each clip record appears to be consumed after a single upload session.
In Matter the upload URL is meant to be a long-lived publishing point accepting many recordings, with the device distinguishing them via an incrementing session_N path. A one-shot URL per recording replaces that with a mechanism only the cloud can drive, which structurally rules out device-initiated recording.
[details=“Spec references”]
§11.7.1.2 — the URL is a static, multi-session publishing point:
The first component of the POST_URL is a static value called the publishing_point_URL. […] Any publishing_point_URL issued to a Matter device SHALL allow for one or more Sessions.
§11.7.1.8.1 — the receiver learns of a new recording from the upload itself, so no pre-registration is expected:
…the attribute
typeset to the value “dynamic” indicates the start of a new CMAF Session. […]typeset to the value “static” indicates the end.
§11.7.7.1.1 — device-initiated triggers are explicitly in scope:
This could be a ManuallyTriggerTransport command or an internally triggered command such as a physical button press.
§11.7.7.5 even defines a dedicated activation reason: 3 DoorbellPressed.
[/details]
Not device-specific
From the Matter Alpha first-look at the Aqara G350 on SmartThings (March 2026):
“A record-on-motion switch is visible in the settings, but it does not function with the G350 at this stage.”
A certified, shipping camera and a launch partner — so this likely isn’t something a camera vendor can fix on their side.
On motion, so I don’t misattribute it
Motion has prerequisites that are not SmartThings’ fault, and I got this wrong at first: a discrete motion sensor SHALL be a child endpoint of the camera endpoint (Device Library §16.1.4) — mine wasn’t, my bug. Separately, the camera sub-driver currently only inspects the camera endpoint’s own clusters and doesn’t descend to a 0x0107 child; PR #2590 (support-additional-camera-device-types) looks like it moves in the right direction.
Once both are sorted, motion uploads through the same data plane as the button press, so I’d expect the same 404. That upload-URL behaviour is the part I can’t work around from the device side.
What would fix it
- A durable
TransportOptions.URLaccepting multiplesession_Nprefixes for the life of the transport, instead of a per-recording clip id - The transport left allocated and Active between recordings
- The clip record created lazily on
session_<N>/index.mpdwithtype="dynamic", keyed on the session number in the path, and closed on thetype="static"manifest - Subscribing to
PushTransportBegin/PushTransportEndso the cloud learns a device-initiated recording happened
ManuallyTriggerTransport would keep working exactly as today.
Questions
- Has anyone got device-initiated clips (button or motion) working with any Matter camera on SmartThings? Happy to be wrong about this.
- Is device-initiated recording planned, or is app-initiated the intended path for now? The record-on-motion switch exists in the UI, which makes it look like it should work.
- Is there a better channel than the forum? This isn’t an Edge driver problem, so the drivers repo didn’t seem right.
Happy to share full HTTP-level logs and the x-st-correlation ids for the failing requests if that’s useful.
