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

[samadDotDev]

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.

2. 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.

3. 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]

Channel deleted.

[github-actions]

Test Results

   72 files  ±  0    502 suites  +7   0s ⏱️ ±0s
2 761 tests + 47  2 761 ✅ + 47  0 💤 ±0  0 ❌ ±0 
4 695 runs  +105  4 695 ✅ +105  0 💤 ±0  0 ❌ ±0 

Results for commit ff3cdb0. ± Comparison against base commit 09cb31c.

♻️ This comment has been updated with latest results.

[github-actions]

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/switch_utils/utils.lua	92%	✅
/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/switch_utils/embedded_cluster_utils.lua	38%	❌
/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/attribute_handlers.lua	83%	❌
/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/device_configuration.lua	94%	✅
/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/aqara_cube/init.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/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/camera/init.lua	97%	✅
/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/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%	✅

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against ff3cdb0

[ctowns]

LGTM! Excellent unit tests, and thank you for including all the real device test cases in the top comment!

[nickolas-deboom]

LGTM!

[cjswedes]

Please squash commits in the future. Now we have to cherry pick 5 commits instead of 1 to beta this week and prod next week.

[samadDotDev]

Please squash commits in the future. Now we have to cherry pick 5 commits instead of 1 to beta this week and prod next week.

My bad, I have been getting used to of leaving the logical changes with other contributors in separate commits in hub-core, but definitely something I'll keep in mind for this repo since we seem to be cherry-picking instead of pulling the branch here.

[cjswedes]

No worries, typically I am heavily in favor more commits for independent changes, but this repo is an exception atm