-
Notifications
You must be signed in to change notification settings - Fork 87
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
Correct gpepIncomingMessageHandler data signature #594
Conversation
This assumes that it's the same across all versions. Of course, that's very difficult to validate given the state of EZSP documentation. However, on v8 this is absolutely correct, and I don't see a reason why it might be only v8 as opposed to everywhere else
Note that the structure was lifted wholesale from zigbee-herdsman though I was able to verify their implement was correct at the data level and also polish it up a bit for us. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## dev #594 +/- ##
==========================================
- Coverage 99.81% 99.81% -0.01%
==========================================
Files 68 68
Lines 4875 4808 -67
==========================================
- Hits 4866 4799 -67
Misses 9 9 ☔ View full report in Codecov by Sentry. |
Thanks! Here's what is in the SDK source: // A callback invoked by the ZigBee GP stack when a GPDF is received.
void ezspGpepIncomingMessageHandler(
// The status of the GPDF receive.
EmberStatus status,
// The gpdLink value of the received GPDF.
uint8_t gpdLink,
// The GPDF sequence number.
uint8_t sequenceNumber,
// The address of the source GPD.
EmberGpAddress *addr,
// The security level of the received GPDF.
EmberGpSecurityLevel gpdfSecurityLevel,
// The securityKeyType used to decrypt/authenticate the incoming GPDF.
EmberGpKeyType gpdfSecurityKeyType,
// Whether the incoming GPDF had the auto-commissioning bit set.
bool autoCommissioning,
// Bidirectional information represented in bitfields, where bit0 holds
// the rxAfterTx of incoming gpdf and bit1 holds if tx queue is available
// for outgoing gpdf.
uint8_t bidirectionalInfo,
// The security frame counter of the incoming GDPF.
uint32_t gpdSecurityFrameCounter,
// The gpdCommandId of the incoming GPDF.
uint8_t gpdCommandId,
// The received MIC of the GPDF.
uint32_t mic,
// The proxy table index of the corresponding proxy table entry to the
// incoming GPDF.
uint8_t proxyTableIndex,
// The length of the GPD command payload.
uint8_t gpdCommandPayloadLength,
// The GPD command payload.
uint8_t *gpdCommandPayload) |
Actually I’m really sorry I pressed my EFR32 into running my home net while I wait for a replacement to ship. (EZSP does bespoke GPF processing that’s out of scope for my work right now.) I’ll dig back into this ASAP but it’ll be a bit. |
This assumes that it's the same across all versions. Of course, that's very difficult to validate given the state of EZSP documentation. However, on v8 this is absolutely correct, and I don't see a reason why it might be only v8 as opposed to everywhere else. Will close #593.