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.

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

kkasperczyk-no
Copy link
Owner

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.

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;
Copy link
Collaborator

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.

Copy link
Owner Author

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.

Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants