Matter Dynamic Controller - Multiple client endpoints on one device

I am looking to design a cloud connected matter Window Covering Controller device that can individually control a variable amount of matter Window Covering devices. How would this be achievable? I have a few ideas, but I am unsure of how this can be implemented or if it is even possible with the Matter SDK today. Please let me know which one of these makes the most sense and if it is achievable with the nRF52840 chipset.

A) A single Window Covering Controller endpoint with multiple bindings. A Matter controller application would need to bind this endpoint with every new Matter Window Covering that is commissioned and on-boarded.
 - Would this allow for the Window Covering Controller to individually control multiple Window Covering endpoints individually, or would they all be grouped together?

B) Multiple Window Covering Controller endpoints. This would require dynamic endpoints like a matter bridge, but instead of server endpoints they would be client endpoints. Each endpoint would be bound to a separate Matter Window Covering on the network using the Matter controller application.
- Are multiple client endpoints of the same type supported in the SDK?

C) A dynamic device type with a dynamic endpoint. This is vaguely defined in the matter core specification (7.15.3.4. Dynamic Device Type). It specifically calls out use of external agents like the cloud that are used to manage relationships. From what I gather it is an endpoint that can change what client clusters it contains. 
- This idea is the foggiest to me. I don't know exactly how it works or if it could even be supported by the Matter SDK at this point. Any clarity on this device type would be apreciated.

  • Hi Jonathan,

    A) A single Window Covering Controller endpoint with multiple bindings. A Matter controller application would need to bind this endpoint with every new Matter Window Covering that is commissioned and on-boarded.
     - Would this allow for the Window Covering Controller to individually control multiple Window Covering endpoints individually, or would they all be grouped together?

    The Matter Window Covering can be added to a Group, so the control would be able to groupcast the command to them. see Interaction Model Concepts  |  Matter  |  Google Home.

    B) Multiple Window Covering Controller endpoints. This would require dynamic endpoints like a matter bridge, but instead of server endpoints they would be client endpoints. Each endpoint would be bound to a separate Matter Window Covering on the network using the Matter controller application.
    - Are multiple client endpoints of the same type supported in the SDK?

    Yes, you can have the same type of endpoint and bind them with different nodes.

    C) A dynamic device type with a dynamic endpoint. This is vaguely defined in the matter core specification (7.15.3.4. Dynamic Device Type). It specifically calls out use of external agents like the cloud that are used to manage relationships. From what I gather it is an endpoint that can change what client clusters it contains. 
    - This idea is the foggiest to me. I don't know exactly how it works or if it could even be supported by the Matter SDK at this point. Any clarity on this device type would be apreciated.

    This should be supported by the Matter stack in Matter SDK, but we do not have any sample for this now. I will check with our development team to see if we have a plan to share something related.

    Best regards,

    Charlie

  • Hi Jonathan,

    For your last inquiry, here are the comment from our Matter experts:

    I agree the description is vague. It seems like it was created to justify/formalize hub devices in a Matter fabric. That is, a hub device is typically a central, client node that acts on behalf of external agents, such as a mobile app or cloud service of the ecosystem provider. Moreover, in contrast to simple devices that are supposed to be in the control of all data necessary to process Data Model requests associated with the given device type, hubs may need to resort to external entities to process certain requests, e.g. during the commissioning process.
    Interestingly, this concept doesn't seem to be used in the official SDK. The only device type in the Matter 1.0 Device Library that is marked as "Dynamic Utility" is "Aggregator" which includes a single, optional "Actions" cluster, not implemented in the SDK, either. The "Dynamic Utility" seems to contradict the following sentence from the "Dynamic Device Type" section: "A dynamic device type is an application device type".
    Are you a member of CSA? If so, I would suggest asking the spec authors for clarification on the "questions" slack channel or raising a question in Issues · project-chip/connectedhomeip (github.com)

    Best regards,
    Charlie
  • Thank you so much  
    So if we look at what is supported in the SDK today, and not necessarily what is in the specification, and wanted to develop a hub that can act on behalf of an external agent, I am thinking Option B with a small amount of proprietary communication added. What do you think of this flow?

    -Custom Matter controller application pairs/onboards the hub
    -Custom Matter controller application pairs/onboards a new Window Covering device
    -Custom Matter controller application tells the hub device there is a new Window covering (via proprietary communication)
    -Hub creates a new Window Covering Controller endpoint
    -Custom Matter controller application binds that new endpoint to the new Window Covering device

    Would this be the only way this would be achievable with the SDK today? Do you think this make the most sense?

  • Also is it possible for the hub be a matter controller? 
    Is there support in the SDK for the Nordic chipset (or any other embedded device) to be a matter controller?
    HomePod mini's and and Echo's have the ability to be controllers and I am just trying to figure if that is available to us.
    I only see a java matter controller example.

  • Hi Jonathan,

    I suggest you refer to the current Matter compatible ecosystems from Apple, IKEA, Google, Samsung, Amazon and so on. They already provide hub and matter constller apps to commission Matter smart home devices into their echo system. Smart home device developers only need to focus on their product design. 

    The hub could be OTBR+Controler like Matter over Thread: Configuring Border Router and controller on one device — nRF Connect SDK 2.2.0 documentation (nordicsemi.com). Here Nordic RCP is only used as an 802.14.5 RF interface to Thread network.

    Best regards,

    Charlie

Related