How Matter actually works

Fabric: why the same light exists three times#

A fabric is a security domain. It has a 64-bit fabric ID and a root certificate authority, and every controller inside it trusts certificates issued by that authority. Apple Home is one fabric. Google Home is another. Home Assistant is another. They do not talk to each other, and they never see each other's credentials.

When you share a device across ecosystems, you are not creating a link between them. You are commissioning the device a second time, onto a second fabric, with a second set of credentials. The device now stores two of everything: two root certificates, two operational certificates, two access control lists. Sharing a Matter device across ecosystems walks through the flow.

Devices are required to support at least 5 fabrics. That is a floor, not a target, and many devices ship with exactly five slots. Apple Home can consume a slot per iCloud Keychain-synced administrator, so a household with several Apple accounts burns through them faster than the owner expects.

Matter 1.6 promoted Joint Fabric from provisional to certifiable, which replaces this model with one shared fabric that several administrators co-manage, using one slot per device no matter how many controllers you own. Nobody has shipped it to consumers as of September 2026.

Node: one device, several identities#

A node is an addressable device on a fabric, identified by a 64-bit node ID. The same physical bulb on three fabrics has three identities and one data model. The identities are per fabric. The capabilities are not.

That explains two things people find surprising:

• Renaming a device in one app does not rename it anywhere else. Names live in the controller, not in the device.
• Removing a device from one app does not remove it from the others, and should not.

It also explains why every controller shows the same capability set. The features come from the device's data model, which is shared. If a light is missing an effect in Apple Home, it is missing everywhere, because the effect was never in the model.

Endpoint: endpoint 0 is always the root#

A node is divided into endpoints, and an endpoint is a feature set.

Endpoint 0 is always the root node. It is not the light or the plug. It holds the infrastructure clusters: the descriptor (what this device is), basic information (vendor, product, serial, firmware version), access control, operational credentials, network commissioning, group key management and diagnostics. Application endpoints are numbered from 1.

So a simple bulb has endpoint 0 plus endpoint 1. A three-socket smart power strip has endpoint 0 plus three application endpoints, which is why it appears as three separate switches rather than one device with three buttons. A bridge exposes an aggregator endpoint whose parts list points at one bridged endpoint per downstream device, which is why 40 Zigbee bulbs behind a hub arrive as 40 things and not one.

Cluster, attribute, command, event#

A cluster is a group of related functionality. A device type is a named set of mandatory and optional clusters bound to an endpoint, which is what "dimmable light" or "door lock" actually means in Matter.

Inside a cluster there are three kinds of thing:

This is the answer to the most common complaint about Matter. Your color bulb is "on, off, dim, color" because those are the clusters the lighting device type defines. Govee's flame effect, Nanoleaf's scenes and Hue's entertainment mode are not attributes in any Matter cluster, so there is nowhere in the protocol to put them. They are not hidden by your controller. They do not exist on the Matter side of the device. Smart lighting that stays compatible covers the buying consequences, and what Matter still cannot do has the same story for vacuums, cameras and appliances.

The same logic explains why a robot vacuum shows start and stop and nothing else, and why a certified appliance can look like a dumb switch in one app and a rich control panel in another. The device model is fixed; what the controller renders is not. Which device types Matter supports sorts this out category by category.

The interaction model: four verbs#

Everything a controller does is one of four interactions:

1. Read an attribute. "What is the brightness right now?"
2. Write an attribute. "Set the heating setpoint to 68."
3. Invoke a command. "Toggle."
4. Subscribe to attributes or events.

Subscriptions are the one worth understanding, because they explain latency. A subscription is server-push: the device agrees to report changes, and the controller and device negotiate a minimum and maximum interval. The minimum stops a flickering sensor from flooding the network. The maximum is a heartbeat, so the controller can tell the difference between "nothing changed" and "this device is gone".

Two symptoms fall straight out of that:

• A battery sensor's temperature in the app is minutes old. It is reporting on its negotiated schedule, not continuously. That is deliberate, and it is why the coin cell lasts. Sensors: motion, contact, temperature, leak covers the reporting interval trade.
• A device goes "unresponsive" and then comes back on its own. The controller missed the maximum-interval heartbeat and marked it unreachable. The radio path recovered and the next report cleared it. If it happens on Thread devices repeatedly, the cause is usually the network, not Matter: see Thread devices dropping or split networks.

Groups, multicast and the popcorn effect#

You turn on eight ceiling lights and they come on one after another over two seconds. That is the popcorn effect, and it has a specific cause: the controller sent eight separate unicast commands, one per device, and each one took its own trip through the network.

Matter has two answers.

Group commands use IPv6 multicast. Devices are given a shared group ID and a group key, and one multicast message reaches all of them at once. There is no acknowledgement, which is the trade: it is fast and it is fire-and-forget.

Wildcard paths let a single read, write or invoke address many endpoints in one action instead of enumerating them. This is the standard fix for the popcorn effect, and it is why the same eight bulbs can be instant on one controller and staggered on another with identical hardware. The difference is what the controller does, not what the bulbs do.

Command batching arrived as a specification feature in Matter 1.3, and scenes became a standard feature in the same release, so some of this depends on which version your controller actually implements. Every Matter version has the dates.

Timed transactions, and why locks feel deliberate#

Locks and other sensitive operations use timed transactions. The controller announces an intent with a maximum timeout, then sends the actual command inside that window. If the window expires, the command is rejected. This defeats replay attacks, where a captured command is re-sent later to open a door.

The visible consequence is small but real: sensitive commands have an extra round trip, so a lock feels a fraction slower than a light on the same network. That is the protocol doing its job. Smart locks and the Aliro standard covers what else is different about lock support.

Ghost devices, and the fabric slot that never came back#

This is the failure that costs people the most time.

When you delete a device in a controller's interface, the controller is supposed to send a remove-fabric command to the device, which erases that fabric's credentials and frees the slot. In practice that command is not reliably sent. The controller removes its own record, the device keeps the credentials, and you are left with an orphaned fabric slot that nothing can see and only a factory reset clears.

Do that a few times on a device with five slots and commissioning starts failing with no explanation, because there is no slot left. Home Assistant ships a "manage fabrics" interface for exactly this reason: it lets you see and remove fabric entries from the device side. Most consumer apps do not expose anything comparable.

The order of operations that avoids the whole problem:

1. Remove the device from every secondary ecosystem first.
2. Remove it from the ecosystem that originally commissioned it last.
3. Factory reset the device before re-pairing it anywhere, even if it looks clean.

Removing and re-pairing devices cleanly has the per-platform detail, and Matter pairing fails treats slot exhaustion as one of the named causes.

Symptom to mechanism, in one table#