Conversation
Signed-off-by: Hunsup Jung <hunsup.jung@samsung.com>
|
Duplicate profile check: Warning - duplicate profiles detected. |
|
Invitation URL: |
Test Results 72 files 489 suites 0s ⏱️ For more details on these failures, see this check. Results for commit 8843cef. ♻️ This comment has been updated with latest results. |
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against 8843cef |
| local DOOR_STATE_MAP = { | ||
| [DoorStateEnum.DOOR_OPEN] = doorState.open, | ||
| [DoorStateEnum.DOOR_CLOSED] = doorState.closed, | ||
| [DoorStateEnum.DOOR_JAMMED] = doorState.jameed, |
| 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 madatory |
|
@HunsupJung can you look at the unit test failure and also add new unit tests for the DPS functionality? |
| [DoorStateEnum.DOOR_UNSPECIFIED_ERROR] = doorState.unspecifiedError, | ||
| [DoorStateEnum.DOOR_AJAR] = doorState.ajar | ||
| } | ||
| device:emit_event(DOOR_STATE_MAP[ib.data.value]()) |
There was a problem hiding this comment.
DoorState is a nullable attribute so you should check for nil here
| 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
No problem @HunsupJung . I mean reading the DoorState attribute to confirm it's a non-null value.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Bat feature and attributes do not change, but DPS feature and attribute can appear or disappear. (Like Nuki)
As far as I know, we must read the DoorState attribute value in device_init to confirm that the DoorState attribute value comes properly without the doorState capability included.
do you want to check the attribute value in device_init?
There was a problem hiding this comment.
@hcarter-775 @nickolas-deboom can you make a recommendation on how best to handle this?
Signed-off-by: Hunsup Jung <hunsup.jung@samsung.com>
3 participants
Type of Change
Checklist
Description of Change
Summary of Completed Tests