-
Notifications
You must be signed in to change notification settings - Fork 0
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
[nrfconnect] Added recovering CASE session for the light switch #65
base: master
Are you sure you want to change the base?
Conversation
There isn't CASE recovery mechanism, so after resetting lighting device, the light switch is not able to communicate with it, as it holds out of date CASE session. Added releasing CASE session in case invoke command failure due to timeout reason. After that new session is established and command retransmitted. CASE session is recovered only once per failure to prevent multiple tries in case comunnication is seriously broken.
private: | ||
static void OnOffProcessCommand(chip::CommandId, const EmberBindingTableEntry &, chip::DeviceProxy *, void *); | ||
static void LevelControlProcessCommand(chip::CommandId, const EmberBindingTableEntry &, chip::DeviceProxy *, void *); | ||
static void LightSwitchChangedHandler(const EmberBindingTableEntry &, chip::DeviceProxy *, void *); | ||
static void InitInternal(intptr_t); | ||
|
||
bool mCaseSessionRecovered = false; |
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.
Move to BindingData
? You won't need to clean this state on each transactions then.
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.
But binding data are related to the specific cluster and command, so it will not work if somebody send different commands one by one. I believe we should store this flag for a specific node ID, but for now we support only one node ID for unicast traffic, so I didn't care much about it.
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.
Ok, but now if there are two simultaneous commands sent and the CASE is lost, won't the second one be simply ignored? Anyway, probably it would require more work to make such scenarios work correctly, so nevermind.
There isn't CASE recovery mechanism, so after resetting lighting
device, the light switch is not able to communicate with it,
as it holds out of date CASE session.
Added releasing CASE session in case invoke command failure due
to timeout reason. After that new session is established and command
retransmitted. CASE session is recovered only once per failure to
prevent multiple tries in case comunnication is seriously broken.