Fix hard privacy mode presence in supportedAttributes

[samadDotDev]

Description of Change

The cameraPrivacyMode.hardPrivacyMode was getting dropped from supportedAttributes, even on devices that report it. HardPrivacyModeOn is of optional conformance in the Matter spec on top of the PRIV feature bit that gates the soft-privacy attributes - so it can only be detected from the Camera AVSM cluster's AttributeList, not from the cluster feature map.

The build_camera_privacy_supported_attributes() was hardcoded to always return just {"softRecordingPrivacyMode", "softLivestreamPrivacyMode"}. A separate reactive path (enabled_state_factory) tried to append "hardPrivacyMode" when a live HardPrivacyModeOn report came in, but any subsequent profile/capability reconciliation (triggered by any of several unrelated feature-map attribute reports) compared current state against that hardcoded baseline, saw a mismatch, and reset supportedAttributes back down to the 2-item list, silently clobbering hardPrivacyMode again.

Fix

• Extended camera_av_stream_management_attribute_list_handler to also detect HardPrivacyModeOn presence in the reported AttributeList (same pattern already used there for StatusLightEnabled/StatusLightBrightness), and persist it via a new update_hard_privacy_mode_attribute_presence.
• build_camera_privacy_supported_attributes now takes device and conditionally includes "hardPrivacyMode" based on that persisted presence, instead of a static 2-item list.
• Since the baseline itself now reflects the device's real capabilities, reconciliation no longer clobbers a dynamically-added hardPrivacyMode entry.

Summary of Completed Tests

• Tested on a Matter Camera that had hardPrivacyMode support (privacy feature bit + presence of HardPrivacyModeOn in attributes list) but wasn't previously reflecting it in the cameraPrivacyMode:: supportedAttributes.
• Tested on a Matter Camera that supports privacy feature but doesn't support hardPrivacyMode
• Tested on a Matter camera that doesn't support privacy feature at all (so no cameraPrivacyMode in the profile).
• Added a unit test that validates the capability based on the presence of relevant attributes in Attributelist

[github-actions]

Channel deleted.

[github-actions]

matter-switch_coverage.xml

File	Coverage
All files	92%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_handlers/capability_handlers.lua	92%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_handlers/attribute_handlers.lua	81%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_handlers/event_handlers.lua	97%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/camera_utils/utils.lua	99%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/camera_utils/device_configuration.lua	96%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_utils/utils.lua	92%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_utils/device_configuration.lua	97%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/ikea_scroll/init.lua	90%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/third_reality_mk1/init.lua	93%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/ikea_scroll/scroll_utils/event_utils.lua	52%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/third_reality_garage_door/init.lua	97%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/hager/init.lua	93%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/camera_handlers/attribute_handlers.lua	96%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/camera_handlers/capability_handlers.lua	83%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/init.lua	97%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/eve_energy/init.lua	91%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/aqara_cube/init.lua	95%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/init.lua	97%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/ikea_scroll/scroll_handlers/event_handlers.lua	75%	❌

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against c66b601

[github-actions]

Test Results

   73 files    541 suites   0s ⏱️
3 264 tests 3 264 ✅ 0 💤 0 ❌
5 253 runs  5 253 ✅ 0 💤 0 ❌

Results for commit c66b601.

♻️ This comment has been updated with latest results.

[ldeora]

The fix looks good for the PRIV + HardPrivacyModeOn case, and using AttributeList as the source of truth for HardPrivacyModeOn presence is definitely the right direction.

One standards-related edge case still seems uncovered, though:

HardPrivacyModeOn does not depend on the PRIV feature. In the Matter 1.5 Camera AV Stream Management data model, the two soft privacy attributes are conditionally mandatory when PRIV is supported, while HardPrivacyModeOn has independent optional conformance.

So this is a valid combination:

PRIV feature:                 absent
SoftRecordingPrivacyMode:    absent
SoftLivestreamPrivacyMode:   absent
HardPrivacyModeOn:           present

The PR correctly detects HardPrivacyModeOn from AttributeList, but match_profile() still adds cameraPrivacyMode only when Feature.PRIVACY is present.

I think the profile decision should therefore be based on either condition:

PRIV present
OR
HardPrivacyModeOn present in AttributeList

and the capability metadata should then be built independently:

PRIV
  -> softRecordingPrivacyMode
  -> softLivestreamPrivacyMode
  -> corresponding setter commands

HardPrivacyModeOn present
  -> hardPrivacyMode

For a hard-privacy-only camera, supportedAttributes should therefore contain only:

["hardPrivacyMode"]

and the soft-privacy setter commands should not be advertised.

One smaller cleanup: now that AttributeList is authoritative for hard-privacy capability presence, I think the old enabled_state_factory() path that dynamically appends "hardPrivacyMode" to supportedAttributes can be removed. Otherwise there are still two separate paths modifying the same capability metadata. The attribute handler can simply report the enabled/disabled state, while supported capability metadata comes from AttributeList.

Other than that, the approach looks good.

[samadDotDev]

@ldeora good callouts! The commit 9fe8022 (c66b601 after rebase) should address your feedback.

[ldeora]

@ldeora good callouts! The commit 9fe8022 (c66b601 after rebase) should address your feedback.

Thanks! I reviewed it and this addresses both points I raised.

The added regression coverage for the no-"PRIV" / hard-privacy-only case looks good as well.

Looks good from my side.