Support DPS feature by HunsupJung · Pull Request #2750 · SmartThingsCommunity/SmartThingsEdgeDrivers

HunsupJung · 2026-02-03T11:26:42Z

Type of Change

WWST Certification Request
- If this is your first time contributing code:
  - I have reviewed the README.md file
  - I have reviewed the CODE_OF_CONDUCT.md file
  - I have signed the CLA
- I plan on entering a WWST Certification Request or have entered a request through the WWST Certification console at developer.smartthings.com
Bug fix
New feature
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

Summary of Completed Tests

Signed-off-by: Hunsup Jung <hunsup.jung@samsung.com>

github-actions · 2026-02-03T11:27:15Z

Duplicate profile check: Warning - duplicate profiles detected.
lock-modular-embedded-unlatch.yml == lock-modular.yml

github-actions · 2026-02-03T11:27:47Z

Invitation URL:
https://bestow-regional.api.smartthings.com/invite/r3MyN7GY1W2p

github-actions · 2026-02-03T11:29:06Z

Test Results

72 files 489 suites 0s ⏱️
2 681 tests 2 680 ✅ 0 💤 1 ❌
4 529 runs 4 528 ✅ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit 8843cef.

♻️ This comment has been updated with latest results.

github-actions · 2026-02-03T11:29:08Z

File	Coverage
All files	`72%`	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/init.lua	`92%`	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/lazy_load_subdriver.lua	`57%`	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/lock_utils.lua	`98%`	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/new-matter-lock/can_handle.lua	`90%`	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/new-matter-lock/init.lua	`64%`	❌

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against 8843cef

drivers/SmartThings/matter-lock/src/new-matter-lock/init.lua

Signed-off-by: Hunsup Jung <hunsup.jung@samsung.com>

tpmanley · 2026-02-05T19:44:06Z

@HunsupJung can you look at the unit test failure and also add new unit tests for the DPS functionality?

tpmanley · 2026-02-06T17:04:30Z

drivers/SmartThings/matter-lock/src/new-matter-lock/init.lua

+    [DoorStateEnum.DOOR_UNSPECIFIED_ERROR] = doorState.unspecifiedError,
+    [DoorStateEnum.DOOR_AJAR] = doorState.ajar
+  }
+  device:emit_event(DOOR_STATE_MAP[ib.data.value]())


DoorState is a nullable attribute so you should check for nil here

tpmanley · 2026-02-06T17:06:16Z

drivers/SmartThings/matter-lock/src/new-matter-lock/init.lua

        local clus_has_feature = function(feature_bitmap)
          return DoorLock.are_features_supported(feature_bitmap, ep_cluster.feature_map)
        end
+        if clus_has_feature(DoorLock.types.Feature.DOOR_POSITION_SENSOR) then


I know that at least some locks will set the DOOR_POSITION_SENSOR feature flag by default even if a door sensor is not configured. They will report NULL for the DoorState attribute until one has been configured. So I think we should check DoorState and the DPS flag and if they are non-NULL and the flag is set then we can say doorState is supported on this lock.

@tpmanley
I am sorry for the late reply and thank you for the review.

Do you mean to read DoorLock cluster's AttributeList and set the flag if there is DoorState attribute?

No problem @HunsupJung . I mean reading the DoorState attribute to confirm it's a non-null value.

@tpmanley
How about setting to unspecifiedError with logging when DoorState attribute is nil?
I think It's not easy to change profile when device start sending the normal value for DoorState after continuously sending nil value.

I think you can do something similar to #2828 by setting a field like profiling_data.DOOR_STATE_NON_NULL when the DoorState attribute is reported as a non-null value. When that field changes from not being set to being set, then that will trigger the re-profile.

@hcarter-775 @nickolas-deboom
Could you review it?

Since we wouldn't include the capability by default, Hunsup is right that we'd need to do a read, which would probably be fine. However, to avoid the problem of reads failing I think we could just add DoorState as a subscribed attribute in device_init with add_subscribed_attribute, and then if we get a non-null value reported back, then do what Tom suggested within door_state_handler with some logic like this to re-profile the device:

if ib.data.value ~= nil and device:get_latest_state("main", capabilities.doorState.ID, capabilities.doorState.supportedDoorStates.NAME) == nil then device:set_field(profiling_data.DOOR_STATE_NON_NULL, true) match_profile(driver, device) end

Then within match_profile, check for the presence of the profiling_data.DOOR_STATE_NON_NULL as the basis for including doorState in the profile.

Actually, since it's not a mandatory attribute, maybe create a new separate field rather than putting this field within profiling_data, otherwise locks that don't support DPS would be blocked here.

Here is my recomendation:

Using my PR here as a blueprint,

we should update this table:

local profiling_data = { BATTERY_SUPPORT = "__BATTERY_SUPPORT", ENABLE_DOOR_STATE = "__ENABLE_DOOR_STATE" }

Then, in device_init:

local function device_init(driver, device) device:set_component_to_endpoint_fn(component_to_endpoint) if #device:get_endpoints(clusters.DoorLock.ID, {feature_bitmap = clusters.DoorLock.types.Feature.DOOR_POSITION_SENSOR}) == 0 and device:supports_capability(capabilities.doorState) == false then device:set_field(profiling_data.ENABLE_DOOR_STATE, false, {persist = true}) else device:add_subscribed_attribute(clusters.DoorLock.attributes.DoorState) end ... rest of function ... end

Next, in door_state_handler:

local function door_state_handler(driver, device, ib, response) if ib.data.value == nil then -- early return on nil data. Also, if ENABLE_DOOR_STATE is unset, set it to false and attempt profile matching. if device:get_field(profiling_data.ENABLE_DOOR_STATE) == nil then device:set_field(profiling_data.ENABLE_DOOR_STATE, false) match_profile(driver, device) end return elseif device:supports_capability(capabilities.doorState) == false then -- if a non-nil report comes in and the doorState capability is unsupported, set ENABLE_DOOR_STATE to true and attempt profile matching. device:set_field(profiling_data.ENABLE_DOOR_STATE, true) match_profile(driver, device) return end ... rest of function ... end

Finally, in do_configure, we can remove this section:

if clus_has_feature(DoorLock.types.Feature.DOOR_POSITION_SENSOR) then table.insert(main_component_capabilities, capabilities.doorState.ID) device.thread:call_with_delay(5, function(t) device:emit_event(capabilities.doorState.supportedDoorStates({"open", "closed"}, {visibility = {displayed = false}})) -- open and closed are mandatory end) end

and we can replace it with the following logic:

... rest of code ... if device:get_field(profiling_data.DOOR_STATE_ENABLED) or device:supports_capability(capabilities.doorState) then table.insert(main_component_capabilities, capabilities.doorState.ID) end ... rest of code ...

probably over by the BATTERY_SUPPORT logic.

This ensures that whether the DOOR_POSITION_SENSOR flag is set and whether the DoorState is populated, the profiling will occur as expected. It also ensures that if the doorState capability is ever set, it will never be unset. Finally, it ensures that if the DOOR_POSITION_SENSOR is ever enabled during the device's lifetime, we will re-attempt a device profile matching (at least on driver restart).

Also, to ensure that any re-profiling works as expected, we should generally add gating like this for all modular capability insertions:

if clus_has_feature(DoorLock.types.Feature.USER) or device:supports_capability(capabilities.lockUsers) then table.insert(main_component_capabilities, capabilities.lockUsers.ID) end

to ensure that if an optional capability is already supported, we continue to enable it.

Signed-off-by: Hunsup Jung <hunsup.jung@samsung.com>

hcarter-775 · 2026-03-12T17:57:10Z

drivers/SmartThings/matter-lock/src/new-matter-lock/init.lua

+          device.thread:call_with_delay(5, function(t)
+            device:emit_event(capabilities.doorState.supportedDoorStates({"open", "closed"}, {visibility = {displayed = false}})) -- open and closed are mandatory
+          end)


I think we should handle this in infoChanged, gated behind a profile change, since this has the possibility of failing (if a profile change does not occur in <5 seconds)

Similar to the discussion here: #2763

Support DPS feature

e201ff7

Signed-off-by: Hunsup Jung <hunsup.jung@samsung.com>

HunsupJung requested a review from hcarter-775 February 3, 2026 11:26

HunsupJung requested a review from nickolas-deboom February 3, 2026 11:27

ldeora reviewed Feb 3, 2026

View reviewed changes

drivers/SmartThings/matter-lock/src/new-matter-lock/init.lua Outdated Show resolved Hide resolved

ldeora reviewed Feb 3, 2026

View reviewed changes

drivers/SmartThings/matter-lock/src/new-matter-lock/init.lua Outdated Show resolved Hide resolved

Fix typo

6d1d895

Signed-off-by: Hunsup Jung <hunsup.jung@samsung.com>

tpmanley reviewed Feb 6, 2026

View reviewed changes

HunsupJung and others added 2 commits March 7, 2026 13:38

Merge branch 'main' into feature/doorlock-dps-feature

b7db8b3

Add nil checking and test unit for DPS

8843cef

Signed-off-by: Hunsup Jung <hunsup.jung@samsung.com>

HunsupJung requested a review from tpmanley March 9, 2026 06:20

hcarter-775 reviewed Mar 12, 2026

View reviewed changes

Conversation

HunsupJung commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Type of Change

Checklist

Description of Change

Summary of Completed Tests

Uh oh!

github-actions bot commented Feb 3, 2026

Uh oh!

github-actions bot commented Feb 3, 2026

Uh oh!

github-actions bot commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

github-actions bot commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tpmanley commented Feb 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hcarter-775 Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

HunsupJung commented Feb 3, 2026 •

edited

Loading

github-actions bot commented Feb 3, 2026 •

edited

Loading

github-actions bot commented Feb 3, 2026 •

edited

Loading

hcarter-775 Mar 12, 2026 •

edited

Loading