BridgedDeviceBasicInformation Cluster

Cluster ID: 0x0039  |  Endpoint: Bridged sub-device's Endpoint (Endpoint 1+)

BridgedDeviceBasicInformation is a subset version of BasicInformation (0x0028), specifically for describing non-native devices connected to the Matter network through a Bridge — such as Zigbee temperature sensors, Z-Wave door locks, Bluetooth light bulbs, etc. These devices lack native Matter capabilities; the Bridge acts as their proxy to expose them as Matter nodes.

Compared to BasicInformation, it removes several root-node-only attributes (such as DataModelRevision, Location, CapabilityMinima), retains information meaningful for sub-devices (vendor, version, serial number, etc.), and emphasizes the Reachable attribute and ReachableChanged event — the core mechanism for bridging scenarios.

Bridge Architecture Concept

A Matter Bridge is a special Matter device: it is itself a native Matter node (BasicInformation on Endpoint 0), while simultaneously "mapping" the multiple non-Matter sub-devices it manages to different Endpoints. Each sub-device's Endpoint hosts a BridgedDeviceBasicInformation Cluster, rather than BasicInformation.

For example, a Zigbee gateway bridging 3 sensors appears in the Matter network as:

  • Endpoint 0: Bridge itself — BasicInformation (gateway info)
  • Endpoint 1: Temperature Sensor — BridgedDeviceBasicInformation
  • Endpoint 2: Humidity Sensor — BridgedDeviceBasicInformation
  • Endpoint 3: Contact Sensor — BridgedDeviceBasicInformation

Attribute Overview

BridgedDeviceBasicInformation has 17 attributes, a subset of BasicInformation. Organized into five groups:

ID Name Type Group Description
0x01 VendorName string Vendor Information Sub-device vendor name
0x02 VendorID vendor-id Vendor Information Sub-device vendor ID
0x03 ProductName string Vendor Information Sub-device product name
0x04 ProductID uint16 Vendor Information Sub-device product ID
0x05 NodeLabel string Product Information User-defined device name (writable)
0x0B ManufacturingDate string Product Information Manufacturing date (ISO 8601 format)
0x0C PartNumber string Product Information Part number
0x0D ProductURL string Product Information Product page URL
0x0E ProductLabel string Product Information Product label (user-facing short name)
0x0F SerialNumber string Product Information Serial number
0x12 UniqueID string Product Information Device unique identifier
0x07 HardwareVersion uint16 Version Information Hardware version number
0x08 HardwareVersionString string Version Information Hardware version string
0x09 SoftwareVersion uint32 Version Information Software version number
0x0A SoftwareVersionString string Version Information Software version string
0x11 Reachable bool Device Status Whether the sub-device is currently reachable (core attribute)
0x14 ProductAppearance struct Product Appearance Product appearance description (finish + color)
Differences from BasicInformation

BridgedDeviceBasicInformation is a strict subset of BasicInformation, removing the following attributes:

  • DataModelRevision (0x00) — Bridged sub-devices don't directly participate in data model version negotiation
  • Location (0x06) — Sub-device location is managed centrally by the Bridge
  • LocalConfigDisabled (0x10) — Sub-devices have no Matter local configuration concept
  • CapabilityMinima (0x13) — Sub-devices don't directly handle CASE Sessions and Subscriptions
  • SpecificationVersion (0x15) — Sub-devices don't declare Matter specification versions
  • MaxPathsPerInvoke (0x16) — Sub-devices don't directly handle Invoke requests

These "root-node-level" attributes are only meaningful on the Bridge's own Endpoint 0 (BasicInformation).

Vendor Information (0x01 – 0x04)

Original vendor and product identification of the sub-device. Note that vendor information here describes the bridged sub-device itself, not the Bridge gateway. For example, if an Aqara gateway bridges a Philips Hue light bulb, the VendorName here should be "Philips" not "Aqara".

ID Name Type Description
0x01 VendorName string Human-readable sub-device vendor name, max 32 characters. E.g. "Philips", "IKEA"
0x02 VendorID vendor-id Sub-device vendor number. If the original device isn't a Matter device (e.g. Zigbee), the Bridge may use a vendor-mapped value
0x03 ProductName string Sub-device product name, max 32 characters. E.g. "Temperature Sensor"
0x04 ProductID uint16 Sub-device product number, mapped from original protocol information by the Bridge
How the Bridge Populates Vendor Information

For Zigbee devices, the Bridge typically maps from the Zigbee Basic Cluster's ManufacturerName and ModelIdentifier to Matter's VendorName and ProductName. For Z-Wave devices, it maps from Manufacturer ID and Product Type ID. The mapping logic is implemented by the Bridge vendor; different gateways may map differently.

↑ Back to Attributes

Product Information (0x05, 0x0B – 0x0F, 0x12)

Detailed product information for the sub-device. Most of these attributes are optional; the Bridge will do its best to extract and populate them from the original protocol. NodeLabel is the only writable attribute.

ID Name Type Description
0x05 NodeLabel string User-defined device name, max 32 characters. Writable — this is the attribute modified when users rename a bridged sub-device in the App
0x0B ManufacturingDate string Manufacturing date, ISO 8601 format. Optional — many low-power sub-devices don't provide this information
0x0C PartNumber string Vendor's internal part/model number, max 32 characters. E.g. a Zigbee device's Model Identifier
0x0D ProductURL string Product page URL, max 256 characters. Optional
0x0E ProductLabel string User-facing product short name, max 64 characters. Suitable for display in App lists
0x0F SerialNumber string Sub-device serial number, max 32 characters. Bridge will populate if the original device has one
0x12 UniqueID string Sub-device globally unique identifier, max 32 characters. Bridge typically generates from the original device's IEEE address or similar unique ID
UniqueID Is Especially Important for Bridged Devices

When the Bridge restarts or a sub-device rejoins, the Controller needs to identify "this is still the same device". UniqueID provides this stability — even if a sub-device's Endpoint number changes after a Bridge restart, the Controller can still match to the same physical device via UniqueID, preserving automation rules and room assignments.

↑ Back to Attributes

Version Information (0x07 – 0x0A)

Sub-device hardware and software version information. If the sub-device supports OTA (upgrade via original protocol), these version numbers reflect its current state.

ID Name Type Description
0x07 HardwareVersion uint16 Sub-device hardware version numeric code
0x08 HardwareVersionString string Human-readable hardware version, 1–64 characters
0x09 SoftwareVersion uint32 Sub-device firmware version numeric code
0x0A SoftwareVersionString string Human-readable firmware version, 1–64 characters, e.g. "v1.2.1"

↑ Back to Attributes

Device Status (0x11)

The most critical attribute in bridging scenarios — the sub-device's online status.

ID Name Type Description
0x11 Reachable bool Whether the Bridge can communicate normally with the sub-device. true = sub-device online and responding normally; false = sub-device offline, signal lost, battery depleted, or otherwise unreachable
Reachable — The Core Mechanism for Bridging

Reachable is the most important attribute in BridgedDeviceBasicInformation, and the key difference from BasicInformation.

For devices directly connected to the Matter network, "online status" is determined by the Matter protocol stack's communication layer — receiving a reply means online. But bridged devices are different: Matter communication between Controller and Bridge may be perfectly normal, while the Zigbee/Z-Wave/Bluetooth link between Bridge and sub-device may have been disconnected.

Reachable precisely reflects the status of the second half of the link (Bridge ↔ sub-device). When a sub-device goes offline:

  1. Bridge sets Reachable to false
  2. Bridge triggers the ReachableChanged event
  3. Controllers subscribed to this event (e.g. phone App) can immediately mark the device as offline in the UI
  4. When the sub-device comes back online, the process reverses — Reachable returns to true, triggering the event again

↑ Back to Attributes

Product Appearance (0x14)

Physical appearance of the sub-device.

ID Name Type Description
0x14 ProductAppearance struct Physical appearance description, including finish and color (see struct and enum descriptions below)

ProductAppearance Struct

Describes the sub-device's physical appearance. Apps can use this for device icon color schemes.

Field Type Description
Finish ProductFinishEnum Product surface finish (see enum below)
PrimaryColor ColorEnum Product primary color (see enum below). Nullable — null when not applicable

ProductFinishEnum (Surface Finish)

0
Other Other
1
Matte Matte
2
Satin Satin
3
Polished Polished
4
Rugged Rugged (industrial)
5
Fabric Fabric

ColorEnum (Product Color)

0
Black Black
1
Navy Navy
2
Green Green
3
Teal Teal
4
Maroon Maroon
5
Purple Purple
6
Olive Olive
7
Gray Gray
8
Blue Blue
9
Lime Lime
10
Aqua Aqua
11
Red Red
12
Fuchsia Fuchsia
13
Yellow Yellow
14
White White
15
Nickel Nickel
16
Chrome Chrome
17
Brass Brass
18
Copper Copper
19
Silver Silver
20
Gold Gold

↑ Back to Attributes

Command

BridgedDeviceBasicInformation does not define any Commands.

Why No Commands?

Unlike early versions of BasicInformation (which had an optional MfgSpecificPing, since removed), BridgedDeviceBasicInformation is purely an informational Cluster. All control operations on sub-devices (on/off, dimming, reading sensors, etc.) are done through their respective functional Clusters, not through the basic information Cluster. To check if a sub-device is online, simply read the Reachable attribute.

Events

BridgedDeviceBasicInformation defines 4 events to notify Controllers of sub-device lifecycle and reachable status changes.

ID Name Priority Description
0x00 StartUp Critical Sub-device startup complete. Carries the SoftwareVersion field; Controller can use this to detect if firmware was upgraded while offline
0x01 ShutDown Critical Sub-device is shutting down. No additional fields
0x02 Leave Info Sub-device removed from Bridge (unpaired / unbound). No additional fields
0x03 ReachableChanged Info Sub-device reachable status has changed. Carries the ReachableNewValue (bool) field, indicating the new status after the change
ReachableChanged — A Must-Watch Event for Bridged Devices

ReachableChanged is the most critical event in BridgedDeviceBasicInformation, and is unique to this Cluster (BasicInformation does not have this event).

Typical trigger scenarios:

  • Zigbee sub-device battery depleted → Bridge detects communication timeout → triggers ReachableChanged(false)
  • Z-Wave door lock signal recovered → Bridge receives response again → triggers ReachableChanged(true)
  • Bluetooth light bulb moved out of Bridge's Bluetooth range → triggers ReachableChanged(false)

App development tip: Subscribe to ReachableChanged events on all bridged sub-device Endpoints. Update device list online status icons immediately upon receiving events. Do not rely on polling the Reachable attribute — event-driven is more timely and resource-efficient.

Example Data

Read result of a BridgedDeviceBasicInformation Cluster from a temperature sensor connected via Zigbee Bridge:

{
  // --- Vendor Information ---
  "0x1": "Aqara",                // VendorName
  "0x2": 4447,                   // VendorID = 0x115F（Aqara）
  "0x3": "Temperature Sensor",   // ProductName
  "0x4": 514,                    // ProductID = 0x0202

  // --- Product Information ---
  "0x5": "Living Room Thermometer",          // NodeLabel (user-defined name)
  "0xB": "2024-08-20",           // ManufacturingDate
  "0xC": "WSDCGQ11LM",          // PartNumber
  "0xD": "https://www.aqara.com/sensor",  // ProductURL
  "0xE": "Aqara Temp Sensor",   // ProductLabel
  "0xF": "AQ20240820T001",      // SerialNumber
  "0x12": "aqara-wsdcgq11lm-001",  // UniqueID

  // --- Version Information ---
  "0x7": 2,                      // HardwareVersion = 2
  "0x8": "v2.0",                 // HardwareVersionString
  "0x9": 3,                      // SoftwareVersion = 3
  "0xA": "v1.2.1",               // SoftwareVersionString

  // --- Device Status ---
  "0x11": true,                  // Reachable = true (currently reachable)

  // --- Product Appearance ---
  "0x14": {                      // ProductAppearance
    "Finish": 1,                 // Matte
    "PrimaryColor": 14           // White
  }
}
Typical Flow for Reading Bridged Device Information

After discovering a Bridge device, the App needs to enumerate all bridged sub-devices and retrieve their information:

  1. Read the PartsList from the Descriptor Cluster on Bridge's Endpoint 0 to get the list of all sub-device Endpoints
  2. For each sub-device Endpoint, read BridgedDeviceBasicInformation:
    • ProductName (0x03) + NodeLabel (0x05) as the device display name
    • Reachable (0x11) to determine online status
    • SoftwareVersionString (0x0A) to display firmware version
  3. Subscribe to ReachableChanged events on each sub-device Endpoint
  4. Note: reads target the sub-device's Endpoint (e.g. 1, 2, 3), not Endpoint 0

Usage Scenarios

Scenario 1: Zigbee Gateway Bridging Multiple Sub-devices

A common Matter Bridge scenario: a Zigbee gateway (e.g. Aqara Hub M2) managing multiple Zigbee sub-devices simultaneously, exposing them to Apple Home / Google Home / Amazon Alexa via the Matter protocol.

Endpoint Device Type Cluster VendorName ProductName Reachable
0 Bridge (gateway itself) BasicInformation Aqara Hub M2 —
1 Temperature Sensor BridgedDeviceBasicInfo Aqara Temp Sensor true
2 Contact Sensor BridgedDeviceBasicInfo Aqara Door Sensor true
3 Smart Plug BridgedDeviceBasicInfo IKEA TRADFRI Plug false

Note that Endpoint 3's Reachable is false — this means the IKEA smart plug is currently unreachable (possibly due to signal issues or power loss). The App should mark it as offline in the device list.

Scenario 2: Reachable Status Monitoring

The App needs to track bridged sub-device online status in real-time for accurate UI feedback and reliable automation execution.

Monitoring Flow
  1. Initialization: After connecting to the Bridge, read Reachable attributes on all sub-device Endpoints to establish the initial online status table
  2. Subscribe: Subscribe to ReachableChanged events on each sub-device Endpoint
  3. Respond: Upon receiving a ReachableChanged event:
    • If ReachableNewValue = false: grey out device list, disable control buttons, notify user
    • If ReachableNewValue = true: restore device icon, enable control buttons
  4. Automation: Before executing automations involving bridged devices, first check Reachable, to avoid timeouts from sending commands to unreachable devices

Scenario 3: Device Identification and Deduplication

After a Bridge restart or firmware upgrade, sub-device Endpoint numbers may change. The App needs to correctly identify "this is still the same device" to avoid duplicates or lost user configurations.

Identification Strategy

Recommended device identification priority:

  1. UniqueID (0x12) (highest priority): Globally unique and unchanged after Bridge restart. Bridge typically uses the sub-device's Zigbee IEEE address (e.g. 00:15:8d:00:02:3a:4b:5c) or Z-Wave DSK to generate it
  2. SerialNumber (0x0F): Can serve as a secondary identifier if the sub-device provides a serial number
  3. VendorID + ProductID: Can only identify product models, not distinguish between different devices of the same model. When used with Endpoint numbers, note that Endpoints may change after Bridge restart

Best practice: Use UniqueID as the primary key for storing device information. When re-enumerating sub-devices after a Bridge restart, match existing records using UniqueID, correctly restoring room assignments, device names, and automation rules even if Endpoint numbers changed.