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

How to actually implement an LED light in onff_light example? #101

Open
jasta opened this issue Sep 25, 2023 · 2 comments
Open

How to actually implement an LED light in onff_light example? #101

jasta opened this issue Sep 25, 2023 · 2 comments

Comments

@jasta
Copy link
Contributor

jasta commented Sep 25, 2023

I'm confused where I would add user code to actually do something with the on/off commands are received, am I missing something from the example code? It would seem that this is internally handled by OnOffCluster with no ability for me to observe changes like we see with other clusters like MediaPlaybackCluster. Perhaps we could include some simple print debugging or something when the user code would be expected to interact with a physical device to make this clearer for folks?

@ivmarkov
Copy link
Contributor

This question has popped up before, but I can't find a link to it, and yes - we should be clearer in the examples and in a future guide as to what the user is supposed to do.

The TL;DR is: OnOffCluster is just an example implementation. You are not supposed to use it in production. Roll your own.

Longer story:
A cluster is really a combination of two things, that don't necessarily need to come together, and I'm not sure we need to provide support for the second one (see below):

  • Metadata. This we should gradually implement for all clusters. The on-off cluster metadata is this one.
  • A Handler (or AsyncHandler) implementation. This you should provide by yourself. Note that a single Handler instance can handle reads/writes/commands for multiple clusters. Or even multiple endpoints. It is really up to you how you'd like to arrange it.

Also, there are multiple places where you can plug yourself in the framework - ordered in increasing level of control and decreasing level of "out of the box" experience with the lib. It is just that currently these are not well documented. As in, e.g. you can "pass" on the whole callback (a.k.a. "Handler") approach for your custom clusters, as long as you are willing to spin your own async loop and not re-use the giant future.

@ivmarkov
Copy link
Contributor

Forgot to add: for the "system" clusters which are required by the Matter spec so that e.g. your provisioning works, we obviously provide both metadata and concrete Handler implementation. However for the user clusters - the things which describe your actual devices/peripherals, I'm not convinced we need to provide "ready to use" Handlers. What would they do, after all? They still need to get some sort of "user callback", so we would end up with a Handler impl (which is already a callback), that delegates to the "real" user callback. A bit pointless, specifically for "simple" user clusters.

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

2 participants