When I first tested the Aqara Camera Hub G350 with SmartThings earlier this year, the result was rather disappointing.
The G350 was one of the first consumer cameras to support the new Matter camera specification, and probably one of the first Matter cameras anyone in the SmartThings Community had actually tried. At the time it felt very much like an early implementation: streaming initially did not work properly, large parts of the camera were not exposed through Matter, and some advertised features simply failed.
A few months and several firmware versions later, things look very different.
I have now tested the G350 again with firmware 4.5.70, inspected its Matter implementation in detail, and used it to test and improve the official SmartThings Matter camera support. And, somewhat to my own surprise, I am now rather impressed with how far this has come.
From a basic Matter camera to a fairly complete one
The older 4.5.20/4.5.21 firmware already exposed a proper Matter Camera endpoint, Camera AV Stream Management, WebRTC infrastructure, two-way audio and Night Vision. But most of the features that actually distinguish the G350 from a fixed camera were not represented through Matter.
Streaming itself was also initially broken and was fixed with the development firmware 4.5.22.
Firmware 4.5.70, which reports Matter 1.5.1, is a much bigger step forward:
| Function | Firmware 4.5.21 | Firmware 4.5.70 |
|---|---|---|
| Matter Camera endpoint |  |
|
| WebRTC live view | initially broken | |
| Two-way audio | |
|
| Snapshot | advertised, but broken | in SmartThings |
| Vision occupancy |  / not exposed |
|
| Matter Privacy | |
|
| Mechanical pan | |
|
| Mechanical tilt | |
|
| Mechanical zoom | |
|
| Mechanical presets | |
|
| Push AV transport | not verified | |
| TLS transport infrastructure | not verified | |
| Zone Management | |
|
| Standard AV/AI analysis | |
|
| Local Storage | |
|
| Dual-lens Matter model | |
|
So this is not just SmartThings learning to interpret the existing camera better. Aqara has substantially expanded the Matter implementation itself.
For reference, my earlier firmware findings are documented here:
- Aqara forum: Firmware feedback — Aqara Camera Hub G350 Matter implementation
- SmartThings Community: development firmware 4.5.22 and working Matter streaming
Privacy is probably the most important addition
The G350 now exposes all three standard Matter camera privacy states:
SoftRecordingPrivacyModeEnabled
SoftLivestreamPrivacyModeEnabled
HardPrivacyModeOn
The first two are writable. The third represents the hard/physical privacy state and is read-only.
This is particularly interesting on the G350 because its native privacy mode physically closes the camera shutter.
During testing, SmartThings could enable and disable both soft privacy modes through standard Matter writes, while the camera correctly reported its hard privacy state. No Aqara-specific command was required.
That is exactly what Matter is supposed to achieve: an important manufacturer feature becoming available to other ecosystems through a standard interface.
PTZ is now properly represented too
The earlier firmware exposed none of the G350’s motorized camera controls.
4.5.70 now implements Matter’s CameraAvSettingsUserLevelManagement cluster with:
| PTZ feature | G350 |
|---|---|
| Mechanical Pan | |
| Mechanical Tilt | |
| Mechanical Zoom | |
| Mechanical Presets | |
| Digital PTZ | |
The camera reports its current position, movement limits, presets and movement state, and supports all five standard mechanical PTZ commands:
MPTZSetPosition
MPTZRelativeMove
MPTZMoveToPreset
MPTZSavePreset
MPTZRemovePreset
I tested absolute movement, relative movement and moving to a saved preset on the real camera. The commands succeeded, the camera moved, and it correctly reported MOVING, the updated position and finally IDLE.
So PTZ has gone from completely absent in Matter to a surprisingly complete implementation.
SmartThings already had much of the necessary code
One thing I had not expected when I started looking into this: the official SmartThings matter-switch driver already contains a fairly extensive generic Matter camera implementation.
It knows about WebRTC, snapshots, Push AV clips, stream configuration, PTZ, Night Vision, privacy, microphone and speaker controls, zones, local storage, motion detection and more.
The problem is not that SmartThings has no Matter camera support. The problem is more subtle: parts of the current implementation make assumptions that do not necessarily hold for a real Matter 1.5 camera with selectively implemented optional features.
The G350 turned out to be a very good device for finding those assumptions.
Current upstream camera implementation:
Official driver versus the modified driver
These are the most important differences:
| Area | Current official driver | Modified driver |
|---|---|---|
| Feature detection | Mainly FeatureMap-driven | FeatureMap + AttributeList + AcceptedCommandList |
| Initialization | Subscription begins before all camera metadata is known | Metadata first, then capability/profile setup, then long-lived subscription |
| Main camera switch | |
Privacy master switch |
| Dashboard on/off | |
|
| Detailed privacy controls | |
|
| Hard privacy | Read-only | Read-only |
| PTZ metadata | Can become available late | Initialized deterministically |
MovementState |
Not subscribed | Subscribed |
| Single-axis PTZ | Sends cached values for all axes | Sends only the requested coordinate |
| Digital PTZ assumptions | Too broad in places | Based on actual device support |
| Speaker mapping | Wrong feature check in one path | Correct SPEAKER mapping |
| Audio volume | Raw/normalized edge cases | Correct Matter ↔ SmartThings scaling |
audioRecording |
Changes SmartThings state only | Not exposed without a real Matter operation |
| Video FPS | Can advertise 120 fps while allocator caps at 60 | Advertisement and allocation are consistent |
| Subscription filtering | Broad feature-derived subscription | Metadata-aware; one NightVisionIllum leak still remains to fix |
| Profile initialization | Can repeat while metadata arrives | Controlled metadata-first reconciliation |
Importantly, none of these changes is Aqara-specific.
The modified driver still uses the standard Matter Camera device type and standard Matter clusters. The G350 simply exposed the shortcomings.
A normal camera on/off switch
One of the most useful changes is also one of the simplest.
The stock Matter camera profile has no normal switch capability on the main camera component. It exposes the individual privacy controls, but there is no straightforward equivalent of turning the camera on or off.
The modified driver maps the normal SmartThings switch to Matter privacy:
Switch OFF
→ SoftRecordingPrivacyModeEnabled = true
→ SoftLivestreamPrivacyModeEnabled = true
Switch ON
→ SoftRecordingPrivacyModeEnabled = false
→ SoftLivestreamPrivacyModeEnabled = false
HardPrivacyModeOn remains read-only.
The detailed cameraPrivacyMode capability is retained as well, so no Matter state is hidden or discarded.
After adding the switch to the dashboard presentation too, the G350 finally behaves like a normal SmartThings camera: it can be switched directly from the device tile and used in routines.
Metadata also affects the SmartThings UI
One of the stranger findings was that the SmartThings profile already contained the PTZ capability, but the actual PTZ controls did not appear in the app.
That changed once the driver initialized the supported PTZ attributes early and reliably:
pan
panRange
tilt
tiltRange
zoom
zoomRange
presets
maxPresets
After that, the full PTZ controls appeared in Samsung’s camera plugin without changing the profile itself.
The plugin is undocumented, so I cannot say exactly how it decides which UI to render. But apparently having the capability in the profile is not always enough; the runtime metadata matters as well.
There is still one UI oddity: before the full PTZ controls appeared, the app showed a preset-oriented interface. With the full PTZ metadata available, that preset UI disappears, although Matter preset support itself still works.
I also tried SmartThings’ separate cameraPreset capability. It did not produce an additional preset interface and actually made opening the camera less reliable, so that experiment was reverted.
At the moment this looks more like a camera-plugin presentation limitation than a Matter problem.
Why AttributeList matters
The G350 is also a good example of why FeatureMap alone is not enough.
It supports NightVision, for example, but not the optional NightVisionIllum. It supports mechanical PTZ but no Digital PTZ.
The stock driver nevertheless subscribes to some optional attributes because the broader feature is present. It also advertised perStreamViewports for the G350 even though the camera has no Digital PTZ.
The rule I have adopted is:
FeatureMap tells us which feature families exist. AttributeList and AcceptedCommandList tell us what this particular device actually implements.
That makes the driver less dependent on assumptions about how a camera “should” implement an optional Matter feature.
A few smaller driver issues
The G350 also exposed several less visible problems.
SmartThings represents audio volume as 0–100%, while Matter can use a different raw range. The stock driver handles the basic conversion, but volumeUp and volumeDown mix normalized SmartThings values with raw Matter limits, and startup ordering can briefly normalize a value before the real min/max limits are known.
The modified driver retains the raw value and recalculates it once the actual range is available. Speaker and microphone levels from 0 to 100% were tested successfully on the real G350.
Another example is audioRecording. The official handler currently contains:
-- TODO: Allocate audio stream if it doesn't exist
and only updates the SmartThings capability state. Since it does not actually change anything on the camera, I chose not to expose it.
There is also a video inconsistency: the stock driver can advertise 120-fps resolutions from the camera metadata while its own stream allocator caps streams at 60 fps. The modified driver keeps the advertised and usable values consistent.
What actually works today?
This is probably the most important comparison with my original report:
| Function | Tested on G350 |
|---|---|
| WebRTC live video | |
| Full-duplex talkback | |
| Motion / vision occupancy | |
| Image capture | |
| Push AV video clips | |
| Speaker volume | |
| Microphone volume | |
| Night Vision OFF / ON / AUTO | |
| Soft recording privacy | |
| Soft livestream privacy | |
| Hard privacy feedback | |
| Main camera/privacy switch | |
| Dashboard switch | |
| Absolute PTZ | |
| Relative PTZ | |
| PTZ movement state | |
| Move to preset | |
This is no longer just a list of features that the G350 claims to support. Most of them have now been exercised against the actual hardware.
One snapshot caveat remains: image capture through SmartThings works, but I have not yet repeated the exact low-level SnapshotStreamAllocate → CaptureSnapshot test that failed with INVALID_COMMAND on 4.5.21. So I would not yet claim that the exact historical protocol defect has been independently reproduced and proven fixed.
Functionally, however, SmartThings can now take pictures.
Not everything is there yet
Matter still exposes only part of what the G350 can do natively.
| G350 function / Matter concept | Current status |
|---|---|
| Zone Management | |
| Chime | |
| Standard AV Analysis / AI events | |
| Local Storage feature | |
| HDR | |
| Image Control | |
| Digital PTZ | |
| Separate Night Vision illuminator | |
| Dual-lens Matter representation | |
The last item is particularly relevant for the G350: Matter currently sees one Camera endpoint rather than the full dual-camera architecture of the native Aqara implementation.
So Matter still does not replace the Aqara app feature-for-feature. But that is not really the point yet.
The important change is that many fundamental camera functions are now available through standard Matter interfaces.
One useful troubleshooting discovery
During testing, both WebRTC streaming and Push AV clips suddenly stopped working.
Rolling the driver back did not help. Restarting the hub did not help. Restarting the phone did not help.
Power-cycling the G350 itself immediately fixed both, with both the older and newer driver.
Interestingly, Camera AV stream allocation had continued to work while the actual transport failed. So the G350’s WebRTC/Push-AV subsystem can apparently get stuck independently of its normal Matter AV state.
Worth remembering if a G350 suddenly stops streaming.
There are still a couple of things to clean up
The modified driver is not completely finished either.
One subscription problem remains: although the camera explicitly says that NightVisionIllum is not implemented, it can still end up in the final subscription request. The feature detection itself is correct; the remaining bug is in how the final subscription paths are constructed.
I have also seen the G350 include identical attribute paths twice in a single Matter REPORT_DATA. This still happened after a cold camera restart and with only one visible driver subscription, so I am currently treating it as a device/runtime issue rather than hiding the duplicates in the Lua driver.
The overall change
Perhaps the easiest summary is this:
| Layer | Earlier | Now |
|---|---|---|
| Aqara firmware | Basic Matter camera | Rich Matter 1.5.1 implementation |
| Streaming | Initially broken | Working WebRTC |
| Privacy | Missing | Full standard Matter privacy |
| PTZ | Missing | Pan, tilt, zoom, presets |
| SmartThings driver | Broad but assumption-heavy | More metadata-driven |
| SmartThings UI | Very basic | Main switch + full PTZ |
| Testing | Mostly protocol inspection | Most major functions hardware-tested |
| Vendor-specific code | Seemed likely necessary | Almost none required |
That last point is probably what impresses me most.
What we have ended up with is not really an Aqara G350 driver. Most of the changes are generic fixes to SmartThings’ Matter camera handling.
A few months ago, the G350 felt like hardware whose Matter implementation was far behind its actual capabilities. Today, privacy, mechanical PTZ, presets, Night Vision, occupancy, image capture, WebRTC, two-way audio and Push AV clips all work through standard Matter mechanisms.
There is still work to do—on the Aqara firmware, the SmartThings driver and especially the camera plugin—but my impression has changed considerably.
For something that felt barely ready as a Matter camera a few months ago, this is a pretty impressive improvement.
