Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert "[controller] Move callbacks to CommandResponseStatus since timing related issue is resolved." #7276

Merged
merged 1 commit into from
Jun 1, 2021
Merged

Revert "[controller] Move callbacks to CommandResponseStatus since timing related issue is resolved." #7276

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 11 additions & 6 deletions src/controller/CHIPDeviceController.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1459,15 +1459,17 @@ CHIP_ERROR DeviceControllerInteractionModelDelegate::CommandResponseStatus(
const uint32_t aProtocolId, const uint16_t aProtocolCode, chip::EndpointId aEndpointId, const chip::ClusterId aClusterId,
chip::CommandId aCommandId, uint8_t aCommandIndex)
{
// #6308, #6559: Invoking success Callbacks in `CommandResponseProcessed` is not desired, but this is used to met current
// requirement of current callback framework that we should be able to send another command once ResponseCallback is called. By
// resolving #6308, the app can wait for the right event, and by #6559 the app can send command in a now command sender.
VerifyOrReturnError(aProtocolCode != 0, CHIP_NO_ERROR);

// Generally IM has more detailed errors than ember library, here we always use the, the actual handling of the
// commands should implement full IMDelegate.
// #6308 By implement app side IM delegate, we should be able to accept detailed error codes.
// Note: The IMDefaultResponseCallback is a bridge to the old CallbackMgr before IM is landed, so it still accepts EmberAfStatus
// instead of IM status code.
IMDefaultResponseCallback(apCommandSender,
(aProtocolCode == 0 && aGeneralCode == Protocols::SecureChannel::GeneralStatusCode::kSuccess)
? EMBER_ZCL_STATUS_SUCCESS
: EMBER_ZCL_STATUS_FAILURE);
IMDefaultResponseCallback(apCommandSender, EMBER_ZCL_STATUS_FAILURE);

return CHIP_NO_ERROR;
}
Expand Down Expand Up @@ -1500,8 +1502,11 @@ CHIP_ERROR DeviceControllerInteractionModelDelegate::CommandResponseError(const

CHIP_ERROR DeviceControllerInteractionModelDelegate::CommandResponseProcessed(const app::CommandSender * apCommandSender)
{
// No thing is needed in this case. The success callback is called in CommandResponseStatus, and failure callback is called in
// CommandResponseStatus, CommandResponseProtocolError and CommandResponseError.
// #6308, #6559: Invoking Callbacks in `CommandResponseProcessed` is not desired, but this is used to met current requirement of
// current callback framework that we should be able to send another command once ResponseCallback is called.
// By resolving #6308, the app can wait for the right event, and by #6559 the app can send command in a now command sender.
IMDefaultResponseCallback(apCommandSender, EMBER_ZCL_STATUS_SUCCESS);

return CHIP_NO_ERROR;
}
void BasicSuccess(void * context, uint16_t val)
Expand Down