Bindings - Specifying Cluster Should be Optional

[jvmahon]

@Luxni

First, let me say that I love this new binding feature and thanks for the work implementing it.

Now, a minor issue ... in the current beta Python Matter server 8.1.0 Beta 0, three parameters (node ID, Endpoint ID, and Cluster ID) must currently be specified to create a binding.

Per the Matter Core Specification Version 1.4.1, Section 9.6.5.1, I believe that the "Cluster ID" is an optional parameter and, if omitted, the binding would be to all eligible clusters on the endpoint.

Note that the example in Section 9.6.6.1 of the Matter core Spec. shows omission of cluster for a "group" target, but based on the specs., I think the cluster is also omit-able for a non-group node / endpoint target.

Not 100% sure I'm correct here, but flagging this so it can be checked.

Thanks.

[Luxni]

I'm very glad that you raised questions after reading the document.

If you have read the PR I submitted, you will find that at the very beginning, I thought the same way as you.

Here, I'll first present the conclusion: This is the result obtained after testing.

The development of the story should be like this：
Me: hi, my friend, could you please test my new feature for me?
Friend: I'm very glad to help you, my friend.
A few days later.
Friend: I found a strange phenomenon. Some devices need to add a cluster to be bound successfully.

This sentence once again brought me back to the ocean of documents.

Finally, well.........................

let's turn our attention to Section 9.6.6.1.
In this example, it actually introduces two binding methods:

1. cluster binding.
2. group binding.

It should be said like this:
If you are performing group binding, then node, cluster and endpoint can be ignored.
If you are performing cluster binding, you should set node, cluster and endpoint, while group can be ignored.

[Apollon77]

In fact not fully correct. :-)

Here is how I read the spec:

Group and Endpoint fields are mutually exclusive, because when you define a group than the group definition already incudes the endpoint , so that's "derived from the group". So either Group OR endpoint are set. The nodeid is needed when the endpoint is set. So far so good.

Cluster is Optional by definition. When it is set then it needs to match with an existing client cluster on that list (Description cluster "ClientList"):

A binding SHALL only be created with the Cluster field if the indicated client cluster exists on the endpoint.

The specification underspecifies the case "cluster field not set" but the one example in 9.6.6.1. Binding Attribute lets assume that omitting the cluster field allows the binding source to control "all clusters in the clientList of that endpoint". And this would also make sense and be consistent.

So for a fully correct implementation (lets ignore groups for now):

• Read "clientList" of descriptor cluster of the target endpoint
• Allow user to select one of these clusters as "cluster" for the binding to generate and have one option "all" which is simply omitting the field to generate a "all these clusters" binding.

The main problem with bindings these days is that noone knows what exactly do the "Client devices" really support in doing, unless they documented it.

[jvmahon]

By the way, the only devices I am aware of with binding support are the Inovelli White Series products (which each have endpoint 2 as a 0x0104 class Dimmer Switch device) . Are there others that you've seen? I've been beta testing their firmware (they are in the process of preparing some updates), so if you've seen issues with those, message me and I'll raise with them.

[jvmahon]

Here is how I read the spec:

I'm reading the spec. the same way, though I'd say the spec has multiple ways of being read! In the end, I suppose the real "definitive" source is what the current public SDK (1.4.2) actually implements.

In any case, having to fully specify each cluster for an endpoint isn't difficult - it just takes more space in the binding table.

[Apollon77]

Do you have the reference place for the spec regarding "cluster field empty vs not"?

I think the ubisys Zigbee hub also exposed some clients, but need to check deeper

[jvmahon]

Do you have the reference place for the spec regarding "cluster field empty vs not"?

In the Matter 1.4.1 Core Specification, Section 9.6.5.1 shows the following table for the TargetStruct type (which is the binding target structure). Based on the Conformance column of that table, if the target is an endpoint, you must Specify the Node and Endpoint, but Cluster is optional. If the target is a group ("!Endpoint" conformance), you must specify the Group, but not the Node or Endpoint, and Cluster is, once again, optional.

[Apollon77]

Yes, so if you can not define the cluster then leave it empty. My question was just refering to your "having to fully specify each cluster for an endpoint" ... you don't need to. If you just need to access one cluster then easy. If it is multiple then leave it out. it is in fact always limited by the "cluster client" definition in the descriptor cluster

[Apollon77]

SO yes in my eyes the cluster should be optional field and allowed to leave empty.