Move lockAlarm configuration to do_configure#2763
Conversation
Signed-off-by: HunsupJung <hunsup.jung@samsung.com>
|
Invitation URL: |
Test Results 71 files 485 suites 0s ⏱️ For more details on these failures, see this check. Results for commit c5127c3. |
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against c5127c3 |
| 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.
2 participants
Type of Change
Checklist
Description of Change
Summary of Completed Tests