Matter, from the controller's side

Every other protocol the controller speaks works the same way: open a connection to the device when asked, exchange a few bytes, close it. Matter cannot work that way, and the reasons are Matter's rather than ours.

A controller is an identity

A Matter device does not answer to whoever is on the network. It answers to the controllers whose certificates it holds, and it holds them from the moment it was commissioned. That set of certificates is a fabric. The controller is not a program that knows how to talk Matter; it is the identity the devices trust, and that identity has to live in exactly one place.

It also has to stay up. A Matter controller subscribes to every device's attributes and keeps them current, so a light's state is something the light reported, not something the controller last asked for. A process that dies loses its subscriptions. So on an Opichy controller the Matter side runs as a supervised service with a restart policy and a state directory, and the capability layer talks to it over a loopback socket that nothing else can reach. Anyone who could reach that socket would own the fabric, which is why it is bound to the controller alone.

Measured, never echoed

Before the first real device, the controller was proven against a test node the server can fabricate for itself: a virtual plug with on/off, brightness and power. One result from that test is worth keeping. Sending off came back with "state": "on". The command succeeded, the read-back reported what the node said, and a fake device never changes. That is the read-back working, not failing.

This is the rule the whole capability model is built on. A Matter node with an OnOff cluster appears as a Switch; one with LevelControl as Illumination; both are measured, because the value comes from the device's own report through the subscription and never from an echo of the command we sent. When the controller says a light is on, a light said so.

Commissioning: the textbook ceremony and the ones that happen

The textbook is Bluetooth: the controller holds the Wi‑Fi credentials, you scan the code on the device, and the device learns the network from the controller. It works, with three things nobody puts on the box.

• Range is short. A bulb across the house never reached the radio at all, while a phone held beside it paired instantly. The same bulb next to the controller came in strong. The ceremony wants the device within a metre or two; after it, the credentials live in the device and it can go back to its fixture.
• The onboard radio shares an antenna. On a Raspberry Pi, Wi‑Fi and Bluetooth share one antenna, and a Bluetooth LE connection does not survive the sharing while Wi‑Fi is associated. It connects and dies inside a second, which looks exactly like a wrong code. The controller now drops its Wi‑Fi uplink for the ceremony and brings it back afterwards, whatever the outcome. A USB Bluetooth dongle removes the problem entirely, and the controller prefers one when it is present, chosen by identity rather than by whichever adapter enumerated first.
• Credentials must persist. Some controllers keep the Wi‑Fi credentials in memory and forget them on restart, which surfaces mid‑ceremony with a bulb in pairing mode and a window running. Ours records them once, with tight permissions, and refuses to start a ceremony without them.

Some hardware never advertises Matter over Bluetooth from a factory reset at all; it only offers the vendor's own onboarding. For those, two other ceremonies work, and both use the network instead of the radio:

1. A code from the vendor app. Onboard the device in its own app, then ask the app for a Matter setup code. Commission with that code over IP within the window the app opens. Note that the request to open the window often travels through the vendor's cloud, so a device network that blocks vendor domains will show a countdown for a window that never opens.
2. Sharing from another ecosystem. Matter is multi‑fabric. A device already owned by a phone ecosystem can issue a one‑time pairing code, and the controller joins as a second fabric without the phone losing anything.

What it recovers

A lot of hardware that is closed over its native protocol is Matter‑certified. Each of those devices becomes a local device the moment it is commissioned into the controller's fabric instead of, or as well as, the vendor's app. No cloud in the loop, no account, no app update that changes the rules.

What Matter does not recover is Thread. Thread devices need an 802.15.4 radio and a border router, and no software makes a radio exist. The controller image will support one when a supported radio is attached.

The fabric is the crown jewels

The fabric's state directory is the fabric. There is no recovering a commissioned device from a lost credential store: each one has to be factory‑reset and commissioned again, one at a time, with the device in hand. The controller image treats that directory as part of the backup set from the first device onward, and so should you.