Binding Cluster

Cluster ID: 0x001E | Endpoint: Functional endpoint (e.g. Endpoint 1) | Role: Client-side configuration (no commands; configured via Write Attribute)

Binding is the Cluster in Matter that defines the "wiring relationships" between devices. The core problem it solves is: When a device sends a command, who should receive it?

For example: you have a smart switch and a smart light bulb. When the switch is pressed, how does it know which light to control? The answer is Binding -- write the light bulb's address into the switch's Binding attribute, and the switch now "knows" this light.

Core Concept: Binding Is a Client-Side Configuration

Binding is configured on the command sender (Client), not on the command receiver (Server). For example, in a switch-controls-light scenario: Binding is written on the switch, not on the light bulb.

Think of Binding as a "contact list" -- the switch's contact list has the light bulb's address, so when the button is pressed, it sends an OnOff command to the address in the contact list. The light bulb itself does not need to know who is controlling it.

No Commands, Only Attribute Writes

Binding Cluster has no commands at all. All configuration is done via Write Attribute operations -- directly writing to the Binding attribute. This means every write is a full replacement of the entire binding list, not an append. When modifying bindings, first read the current list, make changes, then write the entire list back.

Attributes

Binding Cluster has only one attribute, and it is mandatory.

ID	Name	Type	Access	Description
`0x00`	Binding	list<TargetStruct>	Read/Write	Binding target list

Binding (Binding Target List)

A list of TargetStruct entries, where each entry describes a binding target. The device sends commands to the addresses in this list. An empty list means no targets are bound.

Writing is a full replacement -- the newly written list completely overwrites the old one. If you only want to add one binding, you need to first read the existing list, append the new entry, then write the entire list back.

TargetStruct Fields

ID	Field	Type	Required	Description
`0`	Node	node-id	Optional	Target Node ID (used for unicast binding)
`1`	Group	group-id	Optional	Target Group ID (used for multicast binding)
`2`	Endpoint	endpoint-no	Optional	Target Endpoint (used together with Node for unicast binding)
`3`	Cluster	cluster-id	Optional	Which Cluster on the target to bind to
`254`	FabricIndex	fabric-idx	Yes	The Fabric this binding belongs to

Unicast vs Multicast: Choose One

Each TargetStruct is either a unicast binding (specifying Node + Endpoint), or a multicast binding (specifying Group). Both cannot appear in the same entry.

Unicast: Controls a specific Endpoint on a specific device, e.g. "this switch controls the bedroom bedside lamp"
Multicast: Controls all devices in a group, e.g. "this switch controls all lights in the living room"

The Cluster field is optional -- omitting it means binding to all Clusters on the target, while specifying it means binding only to a specific Cluster (e.g. only OnOff, not LevelControl).

↑ Back to Attributes

Example Data

Read the Binding List

{
  // Read the binding list
  "attributeRequests": [{
    "endpointId": 1,
    "clusterId": "0x001E",
    "attributeId": "0x00"          // Binding
  }]
}

Unicast Binding (Switch → Light Bulb)

Bind the switch (Endpoint 1) to the light bulb (Endpoint 1) on Node 2 for the OnOff Cluster:

{
  // Unicast binding: Switch → Light Bulb
  // Write to the Binding attribute on Endpoint 1
  "writeRequests": [{
    "attributePath": {
      "endpointId": 1,
      "clusterId": "0x001E",
      "attributeId": "0x00"        // Binding
    },
    "dataVersion": 0,
    "data": [
      {
        "0": 2,                    // Node = 2 (target light bulb's Node ID)
        "2": 1,                    // Endpoint = 1 (target light bulb's functional endpoint)
        "3": "0x0006",             // Cluster = OnOff (bind to OnOff Cluster)
        "254": 1                   // FabricIndex = 1
      }
    ]
  }]
}

Multicast Binding (Switch → Light Group)

Bind the switch to Group 1, so all lights in the group respond when the switch is pressed:

{
  // Multicast binding: Switch → a group of lights
  "writeRequests": [{
    "attributePath": {
      "endpointId": 1,
      "clusterId": "0x001E",
      "attributeId": "0x00"        // Binding
    },
    "dataVersion": 0,
    "data": [
      {
        "1": 1,                    // Group = 1 (target Group ID)
        "3": "0x0006",             // Cluster = OnOff (bind to OnOff Cluster)
        "254": 1                   // FabricIndex = 1
      }
    ]
  }]
}

Multiple Bindings (One Switch Controls Multiple Targets)

The same switch simultaneously bound to two lights and one group -- each entry in the list is an independent binding target:

{
  // Multiple bindings: one switch controls multiple targets
  "writeRequests": [{
    "attributePath": {
      "endpointId": 1,
      "clusterId": "0x001E",
      "attributeId": "0x00"
    },
    "dataVersion": 0,
    "data": [
      {
        "0": 2, "2": 1, "3": "0x0006",   // Light A (Node 2, Endpoint 1, OnOff)
        "254": 1
      },
      {
        "0": 3, "2": 1, "3": "0x0006",   // Light B (Node 3, Endpoint 1, OnOff)
        "254": 1
      },
      {
        "1": 1, "3": "0x0006",            // Group 1 (all living room lights)
        "254": 1
      }
    ]
  }]
}

Common Scenarios

Scenario 1: Switch Controls a Light Bulb (Unicast Binding)

The most classic Binding scenario. A wall switch controls a specific light.

Both the switch and the light bulb have been commissioned into the same Fabric
Confirm the light bulb's Node ID (e.g. 2) and functional Endpoint (e.g. Endpoint 1)
Write the Binding attribute on the switch's Endpoint 1, adding a record with Node=2, Endpoint=1, Cluster=0x0006(OnOff)
Press the switch → the switch automatically sends an OnOff Toggle command to Node 2 / Endpoint 1 → the light bulb responds

This process does not require a Hub or cloud relay -- the switch and light bulb communicate directly within the local Fabric.

Scenario 2: Switch Controls a Group of Lights (Multicast Binding)

The living room has 3 lights, and the user wants one switch to control them all simultaneously.

First use the Groups Cluster to add all 3 lights to the same group (e.g. Group ID = 1)
Write a record with Group=1, Cluster=0x0006 in the switch's Binding attribute
Press the switch → the switch sends a multicast OnOff command to Group 1 → all 3 lights respond simultaneously

Multicast is more efficient than sending individual unicast commands, with lower latency -- all lights respond almost simultaneously.

Scenario 3: Multiple Bindings (One Switch Controls Multiple Different Targets)

A scene switch needs to control different types of devices simultaneously.

Write multiple records in the Binding list, each pointing to a different target
Unicast and multicast can be mixed -- for example, one entry pointing to a bedroom light (unicast) and another to a living room light group (multicast)
When the switch is pressed, the device iterates through the Binding list and sends a command to each target

Note: With multiple bindings, all targets receive the same command. If you need to send different commands to different devices (e.g. turn on lights while turning off the AC), you should use automation rules instead of Binding.

Developer Advice

Typical workflow for managing Bindings in an App:

First read the current Binding list (Read Attribute)
Display the bound target devices in the App UI
User adds or removes binding targets
Write the modified complete list back (Write Attribute) -- note this is a full replacement

When writing, you must provide the correct FabricIndex, typically obtained from the current connection's Fabric information. Binding entries from other Fabrics are not affected by write operations -- each Fabric can only manage its own bindings.