Closed konistehrad closed 7 months ago
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.
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
29dec53
) 99.81% compared to head (7e07877
) 99.81%. Report is 2 commits behind head on dev.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
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.