Skip to content

Matter Camera: Fix bugs related to profile matching and re-init of capabilites#2887

Open
samadDotDev wants to merge 2 commits intomainfrom
matter-cam/re-init-feature-change
Open

Matter Camera: Fix bugs related to profile matching and re-init of capabilites#2887
samadDotDev wants to merge 2 commits intomainfrom
matter-cam/re-init-feature-change

Conversation

@samadDotDev
Copy link
Copy Markdown
Contributor

@samadDotDev samadDotDev commented Apr 9, 2026

Type of Change

  • Bug fix
  • Refactor

Checklist

  • I have performed a self-review of my code
  • I have commented my code in hard-to-understand areas
  • I have verified my changes by testing with a device or have communicated a plan for testing
  • I am adding new behavior, such as adding a sub-driver, and have added and run new unit tests to cover the new behavior

Description of Change

I started with a fix to feature-map change, which if occurred on a SW update and didn't result in a profile change won't re-init or update any capability attributes (such as supportedFeatures) that should be updated on such changes.

In a specific example, I observed one of the cameras getting updated for its watermark/OSD bits in feature map of AVSM cluster, and despite the SW update (which triggered the infoChanged handler with SW version diff), the videoStreamSettings::supportedFeatures wasn't updated to reflect the changes in watermark/OSD support.

While addressing this issue I noticed that this was applicable to other capabilities and features as well, so I refactored that a bit. There were a few more issues that I addressed as part of this PR since they were tightly linked with the new changes to observe these diffs:

  1. Added subscription to feature map attribute of 3 clusters we track features of (AVSM, AVSUL, ZoneManagement), just so if the feature map changes without a SW version bump (which can technically occur until the formal enforcement of fixed-quality attributes, and bump of ConfigurationVersion from spec) then we still reflect those changes in profile and/or relevant supported features of capabilities.
  • Unlike AttributesList, I believe we aren't tracking FeatureMap global attribute for clusters in the Lua libs, so this is defined as a const until then. This was also surfaced in the recent interest of Door Lock TF in subscribing to feature map changes.
  1. Refactored how to re-init capabilities based on profile changes and/or other changes (like of feature map and attributes list) that may not result in a profile update. Only selective capabilities are updated/re-initialized based on last state (only if there is a diff), and the "reset" of last state is accounted for cases of re-enablement of a capability (imagine populating supportedFeature of a capability, disabling it in profile, re-enabling it - we'd want to re-upsert the supportedFeature even if there is no diff in that case)
  • This also addresses a bug where an event could unintentionally get emitted (and potentially mark an offline device as online) for capabilities in a profile that we don't control (enable/disable) such as vision.clipAnalysis - it will result in an infoChanged with profile diff that'd previously call the re-init of all capabilities.
  1. Status light and light brightness are now tracked based on the AttributesList handler. This was handled previously too, but wasn't tracked, so there was a bug where this could be reset (removing the status led components from profile) if you receive the AttributesList first and then another event occurred which would re-match the profile from various paths (as that re-match was defaulting to false for all spots outside of AttributesList handler). We can't rely (yet) on the attributes list within device's object (unlike feature map) due to this being potentially empty, hence it is tracked based on last report received for this attribute, and then used in any future re-matches from any path.

Summary of Completed Tests

  • Added unit tests covering some of the behavior additions/updates
  • Performed functional testing with a camera, specifically looking out for following combinations:
    • Driver update on existing camera
    • Hub reboot / driver restart on offline camera
    • Hub reboot / driver restart on online camera
    • SW update of existing camera
    • Device object update without relevant diffs (unrelated changes in infoChanged) of existing camera
    • Onboarding a new camera

@github-actions
Copy link
Copy Markdown

github-actions bot commented Apr 9, 2026

@github-actions
Copy link
Copy Markdown

github-actions bot commented Apr 9, 2026

Test Results

   72 files  ±0    495 suites  ±0   0s ⏱️ ±0s
2 716 tests +2  2 716 ✅ +2  0 💤 ±0  0 ❌ ±0 
4 592 runs  +2  4 592 ✅ +2  0 💤 ±0  0 ❌ ±0 

Results for commit 1094ae3. ± Comparison against base commit 09cb31c.

@github-actions
Copy link
Copy Markdown

github-actions bot commented Apr 9, 2026

File Coverage
All files 92%
/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/camera/init.lua 97%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/aqara_cube/init.lua 96%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_handlers/attribute_handlers.lua 84%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_handlers/capability_handlers.lua 90%
/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 98%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/camera_utils/device_configuration.lua 90%
/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/embedded_cluster_utils.lua 38%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/switch_utils/device_configuration.lua 96%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/camera/camera_handlers/capability_handlers.lua 82%
/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/ikea_scroll/init.lua 89%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/third_reality_mk1/init.lua 95%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/ikea_scroll/scroll_handlers/event_handlers.lua 93%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/init.lua 97%

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against 1094ae3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant