Move lockAlarm configuration to do_configure#2763
Conversation
Signed-off-by: HunsupJung <hunsup.jung@samsung.com>
|
Invitation URL: |
Test Results 72 files 489 suites 0s ⏱️ Results for commit 3706fb2. ♻️ This comment has been updated with latest results. |
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against 3706fb2 |
| end | ||
| end | ||
| device:subscribe() | ||
| device:emit_event(capabilities.lockAlarm.alarm.clear({state_change = true})) |
There was a problem hiding this comment.
I think we should leave this here, since the call_with_delay may have some unforeseen race-y conditions.
To avoid double emitting events, we could add an
if device:get_latest_state("main", capabilities.lockAlarm.ID, capabilities.lockAlarm.supportedAlarmValues.NAME) == nil then
check to ensure the same call wasn't done earlier? However, double calling these events in this context doesn't seem like a big issue to me
| device.thread:call_with_delay(5, function() | ||
| device:emit_event(capabilities.lockAlarm.alarm.clear({state_change = true})) | ||
| device:emit_event(capabilities.lockAlarm.supportedAlarmValues({"unableToLockTheDoor"}, {visibility = {displayed = false}})) -- lockJammed is mandatory | ||
| end) |
There was a problem hiding this comment.
I don't think the call_with_delay should be required here. We could put an if device:supports_capability(capabilities.lockAlarm) then gate if we are trying to ensure the device has this before emitting an event.
There was a problem hiding this comment.
When I tested it without call_with_delay, I could see the following log.
2026-03-06_05:36:55.892 | W | broker | <Matter Lock (c32ca1d6)> Attempted to generate event for d079b3f0-a761-4e01-886a-24fc0fd34154.main but it does not support capability lockAlarm
it seems to take time to change the profile after device:try_update_metadata({profile = profile_name})
Signed-off-by: HunsupJung <hunsup.jung@samsung.com>
2 participants
Type of Change
Checklist
Description of Change
Summary of Completed Tests