Matter camera: audioRecording capability is exposed but its command handler only changes local SmartThings state

[ldeora]

Summary

The camera subdriver can dynamically expose the SmartThings audioRecording capability for cameras with AVSM Audio + Push AV Stream Transport.

However, its command handler currently does not perform any Matter write, command, stream allocation or Push AV operation. It only emits the requested SmartThings capability state locally.

This creates a control that appears to succeed in SmartThings while doing nothing to the camera.

Environment / verification

Verified against SmartThingsCommunity/SmartThingsEdgeDrivers main at commit
60bbf2716412fdf04fd59f967bdd37be6995d664 (2026-08-12).

Real-device validation used:

• Aqara Camera Hub G350
• VID/PID: 0x115F / 0x3013
• firmware: 4.5.70 / 4005070
• reported Matter SpecificationVersion: 1.5.1
• Camera device type: 0x0142
• Camera endpoint in this device: endpoint 2

The proposed changes are generic Matter-camera changes. No Aqara VID/PID fingerprint or proprietary Aqara cluster handling is required.

Current behavior

The dynamic profile enables audioRecording when Audio and Push AV are present:

• camera_utils/device_configuration.lua around lines 220-233

The capability is initialized locally to "enabled" when unset:

• camera_utils/device_configuration.lua around lines 340-351

The command handler is explicitly unfinished:

• camera_handlers/capability_handlers.lua lines 133-137

function CameraCapabilityHandlers.handle_audio_recording(driver, device, cmd)
  -- TODO: Allocate audio stream if it doesn't exist
  local component = device.profile.components[cmd.component]
  device:emit_component_event(
    component,
    capabilities.audioRecording.audioRecording(cmd.args.state)
  )
end

and it is registered as a normal command handler:

• src/sub_drivers/camera/init.lua lines 168-174

Reproduction

1. Use a Matter camera with:
   • AVSM Audio;
   • Push AV Stream Transport.
2. Let the dynamic profile expose audioRecording.
3. Execute setAudioRecording.
4. Observe driver traffic.

Current behavior:

• SmartThings capability state changes;
• no Matter attribute write is sent;
• no Matter command is invoked;
• no audio stream / Push AV operation is performed.

Expected behavior

A control shown as functional in SmartThings should either perform the corresponding device operation or not be exposed.

Suggested resolution

Short-term / safest

Do not dynamically enable audioRecording until its Matter behavior is implemented.

Remove it from:

• dynamic managed_capability_map;
• dynamic profile selection;
• capability initialization;
• command-handler registration.

The optional capability declaration can remain in profiles/camera.yml if SmartThings wants to keep the profile vocabulary ready for a future implementation.

Alternative

Implement the actual intended Matter/Push AV behavior and update the capability state only from device/transport state.

The current local-only state mutation should not remain.

G350 evidence

The G350 exposes AVSM Audio and Push AV Transport, so the stock dynamic profile qualifies it for audioRecording.

In the original SmartThings device JSON, audioRecording was present but had no useful device-backed state.

The test driver stopped dynamically exposing/registering this non-functional control, while the camera's actual audio features continued to work:

• two-way talk remained available;
• speaker and microphone capabilities remained available;
• WebRTC remained operational.

Affected files

• src/sub_drivers/camera/camera_utils/device_configuration.lua
• src/sub_drivers/camera/camera_handlers/capability_handlers.lua
• src/sub_drivers/camera/init.lua
• src/test/test_matter_camera.lua

Optional depending on desired cleanup:

• profiles/camera.yml

Suggested regression coverage

If the short-term removal is used:

1. Audio + Push AV camera must not dynamically enable audioRecording.
2. audioRecording.setAudioRecording must not be registered by the camera subdriver.
3. WebRTC/talkback and microphone/speaker capabilities must remain unchanged.

If a real implementation is added instead, tests should verify an actual Matter operation rather than only a local capability event.