Frequently Asked Questions

Matter is a unified application-layer standard for the smart home, published by the Connectivity Standards Alliance (CSA). A Matter-certified device can be controlled directly by Apple, Google, Amazon, Samsung and other platforms, so vendors no longer need a separate integration for each one.

Matter only defines what a device can do, how it interacts and how it is secured; transport uses existing IP networks: Thread, Wi-Fi or Ethernet. Bluetooth is used only at commissioning time to deliver setup data, never for everyday control.

A device (Node) is split into functional units (Endpoints); each endpoint is made of feature groups (Clusters), which contain state values (Attributes) and actions (Commands). For example: "the lock state attribute of the Door Lock cluster on endpoint 1".

A device type is a checklist of clusters a device must have. Declaring Door Lock (0x000A) means implementing the Door Lock and Identify clusters. The device type only sets the minimum; optional capabilities depend on the clusters themselves.

Yes. A Matter device can join several Fabrics (trust domains) at once, holding a separate certificate for each platform. The specification requires devices to support at least 5 fabrics.

No, it is 4 bytes in full: the upper 2 bytes are a vendor prefix and the lower 2 bytes are the number. Standard clusters use the prefix 0x0000, which is normally omitted, so Door Lock 0x0000_0101 is written 0x0101 and looks like two bytes.

Each kind of ID has its own numbering. 0x0101 is Door Lock as a cluster but Dimmable Light as a device type. Before looking a number up, check which field it appears in.

Yes, it is the same number in a different format. chip-tool logs usually print hex, while Home Assistant diagnostics use decimal (e.g. 1/257/0 means endpoint 1, cluster 257, attribute 0). The ID lookup accepts both.

A vendor-specific cluster ID carries the vendor ID as its prefix (e.g. 0x1234_FC00), with the number in the 0xFC00–0xFFFE range. It is not part of the Matter standard, so only the vendor's own documentation defines it.

Read DeviceTypeList from the Descriptor cluster (0x001D) on each endpoint. Read PartsList on endpoint 0 first to get every endpoint number, then go through them. A lock's endpoint 1 typically returns "Door Lock 0x000A + Power Source 0x0011".

Read the Descriptor ServerList to see which clusters exist, then three global attributes on each cluster: FeatureMap (enabled optional features), AcceptedCommandList (accepted commands) and AttributeList (implemented attributes).

Yes. A wildcard read returns every attribute at once, e.g. chip-tool any read-by-id 0xFFFFFFFF 0xFFFFFFFF <node-id> 0xFFFF. Home Assistant's diagnostics download contains the same result and can be pasted straight into the JSON Parser.

A device type only fixes the mandatory part. Two devices both declaring Door Lock may differ: one supports fingerprints and user management, the other only PIN codes. The difference shows up in the Door Lock cluster's FeatureMap.

All in the BasicInformation cluster (0x0028) on endpoint 0: VendorName / VendorID, ProductName / ProductID, SoftwareVersionString, SerialNumber and more. This cluster exists only on endpoint 0.

Wi-Fi and Ethernet devices don't; they just join the home router. Thread devices need a Thread border router (built into HomePod mini, Apple TV, Nest Hub and many other speakers and hubs) to connect the Thread network to the home IP network. That said, the Apple, Google and Amazon apps generally require one of their own hubs (a speaker or TV box) to run automations and remote access.

Battery-powered, low-traffic devices (sensors, locks, buttons) suit Thread: low power and a stable mesh. High-traffic devices such as cameras and appliances suit Wi-Fi, and small mains-powered devices like lights and plugs work well either way. At the Matter layer they are identical.

Scan the QR code or enter the setup code → find the device over Bluetooth and set up an encrypted session → issue it a certificate and add it to a Fabric → send it the Wi-Fi or Thread credentials → the device comes online and can be read and controlled.

They sit at different layers: Zigbee is a full stack from radio to application, Matter only an application layer. The fair comparison is "full Zigbee" vs "Matter + Thread": the same radio, but different on IP, vendor gateways and joining several platforms at once.

Yes, through a hub that supports Matter bridging (e.g. the Philips Hue Bridge or Aqara M2 / M3). The hub "translates" each child device into a Bridged Node (device type 0x0013) that every platform can control.

HomeKit is Apple's own smart home protocol and only works in the Apple ecosystem. Apple is one of Matter's main backers and Apple Home supports Matter devices natively, so new products usually just implement Matter.

Matter clusters come straight from Zigbee's ZCL cluster library, and both are maintained by the same organisation (CSA). On/Off 0x0006, Level Control 0x0008, Color Control 0x0300, Door Lock 0x0101 and others are unchanged.

Paste it into the JSON Parser. It translates cluster, attribute and command numbers into names and explains key status values. For a whole-device raw dump it also builds a device profile and labels where each item came from.

All platforms go through the Descriptor cluster: DescriptorCluster in connectedhomeip on Android, MTRBaseClusterDescriptor on iOS, and on the Web matterjs-server node data already contains every attribute. Sample code for all three is in the SDK Guides.

The latest specification is 1.6 (June 2026); the ecosystem mainstream is 1.4 to 1.5, and the widest deployment is 1.3 to 1.4. Products usually target what the major platforms already support, moving up only when they need newer device types such as cameras or energy management.