Best Practice for (multiple) ModeSelect Clusters (CON-1602)

[jzwyssig]

I am using the Mode Select Cluster in our product and have successfully completed Matter certification with it.

However, I am wondering how to handle multiple Mode Select Clusters. Currently, each Mode Select Cluster has a description, supported modes and optional tag lists. A mode should serve a single purpose, for example, an input mode where I can select between a latching switch and a momentary push button.

But what if I need another mode that is completely different? For instance, consider dimming curves: A, B, and C. I would like to have a separate Mode Select Cluster for this, as each cluster can only be used once per endpoint, correct?

Questions:

• Can you confirm that each cluster can only be used once per endpoint (single instance)?
• What is the best practice for implementing multiple Mode Select Clusters? Using another endpoint would imply adding another device, which I want to avoid. It seems that custom attributes in a custom cluster is the best solution. Although, I prefer mode select because it is in the spec.

[jadhavrohit924]

Can you confirm that each cluster can only be used once per endpoint (single instance)?

Yes, each cluster can only be used once per endpoint.

What is the best practice for implementing multiple Mode Select Clusters? Using another endpoint would imply adding another device, which I want to avoid

If you don’t want to use another endpoint, you can implement another delegate of mode selects, which will have a different dataset, and set the default delegate for that endpoint. However, I would suggest using a different endpoint since you can use only one of the delegates (dataset) at a time per endpoint, and both modes serve completely different use cases.

[jonsmirl]

This is the difference between Mode Select and the Mode Base Cluster. The Mode Base Cluster is used to derive multiple mode selects on the same endpoint. The problem here is that the spec does not provide a general way of deriving off from the Mode Base Cluster. The people writing the spec can derive off from it, but you can't do that without defining custom clusters. And if you define custom clusters they won't work in the Google/Apple/Amazon apps.

So you can do this, but it will only be accessible to a custom controller app.

[jzwyssig]

Thank you, @jadhavrohit924 and @jonsmirl, for your input!

As @jonsmirl mentioned, the Mode Base Cluster serves just a template and needs to be implemented like a custom cluster. I’ve already extended my clusters with custom attributes and commands and for some attributes, I've created a custom cluster. Everything works fine and I appreciate the flexibility Matter offers, but I think the Mode Select cluster could have been designed better.

Instead of requiring custom implementations, it would have been more useful if Matter allowed defining lists inside the cluster. This way, we could create multiple collections of descriptions and enum values independently, making things more flexible and structured.

I dislike that the current Mode Select Cluster is limited to a single selection. Initially, we tried using bit fields inside the uint8_t enum (e.g., Bit 0 for InputModes, Bits 1 and 2 for other fields, etc.), but this quickly led to too many combinations and, therefore, an impractical solution. I think currently only Home Assistant supports the Mode Select Cluster, but because the cluster should serve only one purpose, it is very limiting.

In the specification, they provide a good example, but they don't explicitly mention the need for different endpoints for that.

1.8.6.2. Description Attribute
This attribute describes the purpose of the server, in readable text.
For example, a coffee machine may have a Mode Select cluster for the amount of milk to add, and
another Mode Select cluster for the amount of sugar to add. In this case, the first instance can have
the description Milk and the second instance can have the description Sugar. This allows the user to
tell the purpose of each of the instances.

[jonsmirl]

There is a technique which would have made Matter much more flexible but I was unable to convince the people writing the spec to consider it.

It is the scheme used by Microsoft MSCOM. With MSCOM you don't have a giant spec describing all of the objects. Instead each object sends a zipped copy of its IDL when you access it. This IDL language consists of basic programming constructs like lists, booleans, ranges, etc. You then combine those primitives into larger objects (devices). This is just an overview and I left out many details, but the basic concept of MSCOM is that it is self-describing and doesn't need a spec except for the primitives.

A model like that drastically changes how Matter would work. There would never be releases. Instead you just release new UUIDs marking common collections of primitives (like Lightbulb1, Lightbulb2, ..). If you understand that UUID you can make an optimized display. But if you don't understand the UUID you can still generate a display because everyone is required to support those primitives like list, boolean, etc.

Now there is no such thing as a custom cluster (assuming you don't create new primitives) there are only optimized or non-optimized displays. If you understand the device UUID you make the optimized display, if not you use the primitives to build a non-optimized one. Keep considering this.. what if there was a scripting language for making the display for each UUID? Hmm... could the devices also send that scripting code? Then the phone apps could dynamically generate optimized displays because the devices would tell them how to.

[jzwyssig]

That sounds very interesting, @jonsmirl. I’m not familiar with MSCOM, but a self-describing system would have made Matter much more flexible. I guess they had to adopt most of Zigbee’s spec and included some ideas of Apple's HomeKit.

I would have already been happy with a simple Options Cluster, where manufacturers could define a few settings using basic primitives with localized keys as titles. It would make it much easier for applications to display device-specific options in a settings window.

However, it is what it is!