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

Handling local vs network actions #14

Closed
jonsmirl opened this issue Jul 31, 2022 · 1 comment
Closed

Handling local vs network actions #14

jonsmirl opened this issue Jul 31, 2022 · 1 comment

Comments

@jonsmirl
Copy link
Contributor

In the light demo toggling the bulb is handled locally.

    attribute::get_val(attribute, &val);
    val.val.b = !val.val.b;
    attribute::update(endpoint_id, cluster_id, attribute_id, &val);

In the light-switch demo toggling the bulb is handled via the network

    uint32_t command_id = OnOff::Commands::Toggle::Id;

    g_cluster_id = cluster_id;
    g_command_id = command_id;
    lock::chip_stack_lock(portMAX_DELAY);
    client::cluster_update(endpoint_id, cluster_id);
    lock::chip_stack_unlock();

So how do I implement the use-case described in this issue?
project-chip/connectedhomeip#21243

You can't just do both actions because the toggle will happen twice, once locally and again when it arrives via the group.

So I see two options, which one is better and how do I implement it?

  1. Keep track of whether the dimmer has been bound to a group. If it has been bound use the network, if not use a local action.

  2. Somehow construct a loopback binding when not bound to a group, then always use a network action.

@jonsmirl
Copy link
Contributor Author

I made this issue on CHIP
project-chip/connectedhomeip#21470

Can you please help push it with them so that they don't ignore it?

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

No branches or pull requests

1 participant