-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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.
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
[Darwin] Adding more metrics to capture BLE during setup #32793
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -64,6 +64,13 @@ | |
{ | ||
MTR_LOG_DEFAULT("DeviceControllerDelegate status updated: %d", status); | ||
|
||
// If pairing failed, PASE failed. However, since OnPairingComplete(failure_code) might not be invoked in all cases, mark | ||
// end of PASE with timeout as assumed failure. If OnPairingComplete is invoked, the right error code will be updated in | ||
// the end event | ||
if (status == chip::Controller::DevicePairingDelegate::Status::SecurePairingFailed) { | ||
MATTER_LOG_METRIC_END(kMetricSetupPASESession, CHIP_ERROR_TIMEOUT); | ||
} | ||
|
||
id<MTRDeviceControllerDelegate> strongDelegate = mDelegate; | ||
MTRDeviceController * strongController = mController; | ||
if (strongDelegate && mQueue && strongController) { | ||
|
@@ -73,12 +80,21 @@ | |
[strongDelegate controller:strongController statusUpdate:commissioningStatus]; | ||
}); | ||
} | ||
|
||
// If PASE session setup fails and the client implements the delegate that accepts metrics, invoke the delegate | ||
// to mark end of commissioning request. | ||
// Since OnPairingComplete(failure_code) might not be invoked in all cases, use this opportunity to inform of failed commissioning | ||
// and default the error to timeout since that is best guess in this layer. | ||
if (status == chip::Controller::DevicePairingDelegate::Status::SecurePairingFailed && [strongDelegate respondsToSelector:@selector(controller:commissioningComplete:nodeID:metrics:)]) { | ||
OnCommissioningComplete(mDeviceNodeId, CHIP_ERROR_TIMEOUT); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But if the API consumer tries to set up a new PASE session while the old setup is in progress, what happens? That will clobber This really needs an actual sound model for how this stuff works, so we don't get stuck with behavior clients expect that is broken and we can't change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yup, but I am not sure how to fix this without changing the C++ layer. Ideally, if the callbacks can be fixed to pass on the NodeId, it will eliminate this issue There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, one option is to set this only if we successfully kick off an async pairing operation, right? As in, don't set this until the call into the C++ returns success. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But in that case, the callback above won't be invoked and clobbering the NodeId for the latest one should be fine. Right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So the situation is:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah I see, I can fix it in next iteration |
||
} | ||
} | ||
} | ||
|
||
void MTRDeviceControllerDelegateBridge::OnPairingComplete(CHIP_ERROR error) | ||
{ | ||
MTR_LOG_DEFAULT("DeviceControllerDelegate Pairing complete. Status %s", chip::ErrorStr(error)); | ||
MATTER_LOG_METRIC_END(kMetricSetupPASESession, error); | ||
woody-apple marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
id<MTRDeviceControllerDelegate> strongDelegate = mDelegate; | ||
MTRDeviceController * strongController = mController; | ||
|
@@ -129,6 +145,7 @@ | |
|
||
// Always collect the metrics to avoid unbounded growth of the stats in the collector | ||
MTRMetrics * metrics = [[MTRMetricsCollector sharedInstance] metricSnapshot:TRUE]; | ||
MTR_LOG_INFO("Device commissioning complete with metrics %@", metrics); | ||
|
||
if ([strongDelegate respondsToSelector:@selector(controller:commissioningComplete:nodeID:)] || | ||
[strongDelegate respondsToSelector:@selector(controller:commissioningComplete:nodeID:metrics:)]) { | ||
|
@@ -158,6 +175,11 @@ | |
} | ||
} | ||
|
||
void MTRDeviceControllerDelegateBridge::SetDeviceNodeID(chip::NodeId deviceNodeId) | ||
{ | ||
mDeviceNodeId = deviceNodeId; | ||
} | ||
|
||
@implementation MTRProductIdentity | ||
|
||
- (instancetype)initWithVendorID:(NSNumber *)vendorID productID:(NSNumber *)productID | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be documented clearly in the APIs. Given what the documentation says right now, API consumers will absolutely not expect a commissioningComplete callback here.