English is currently available.
Zigbee, Thread & Matter DISCUSSION
I flashed a Matter light example on an ESP32 and try to add it with a phone by scanning the QR code from the serial log. The phone finds the device over Bluetooth, shows a warning about an uncertified device, then fails after about a minute with a generic "cannot add accessory" message. The Wi-Fi password is correct.
What are the steps of Matter commissioning, and at which of them do development devices usually fail?
Commissioning has distinct stages, and the device log tells you which one you reached. First, discovery: the device advertises over Bluetooth LE with a 12-bit discriminator so the phone can pick the right one. Second, PASE: a secure session is established from the setup passcode in the QR code. Third, attestation: the phone checks the device's attestation certificate chain and certification declaration. Fourth, the phone installs operational credentials (a node certificate for its fabric) and sends the Wi-Fi or Thread network credentials. Fifth, the device joins that network, is found again through DNS-SD on the IP network, and a new certificate-based session (CASE) is set up.
Commissioning is only complete after that last step. A failure after about a minute is typical of stage five.
Stage five fails when the phone and the device cannot find each other on the IP network. Matter relies on IPv6 link-local addressing and multicast DNS, so check the following: the ESP32 joins a 2.4 GHz network, since it has no 5 GHz radio; the phone is on the same layer-2 network, not a guest network or a separate VLAN; the access point does not have client isolation turned on; and multicast is not being filtered between wireless clients.
The device log shows it obtaining an address and advertising an operational service. If that appears and the phone still gives up, the multicast path between them is the suspect.
The warning about an uncertified device comes from stage three and is expected. Example firmware uses test credentials: a test vendor ID (0xFFF1 to 0xFFF4), a test attestation certificate, and the default setup values of passcode 20202021 and discriminator 3840. Phone ecosystems treat those as development devices. Some let you continue after the warning; others accept test devices only when your account is set up for development with a matching vendor and product ID, so check the developer documentation of the ecosystem you are pairing with.
Since every example shares the same passcode and discriminator, power off other development boards nearby while commissioning, or the phone may talk to the wrong one.
Two device-side details cause a lot of repeated failures. A half-finished attempt can leave stored state behind. The device arms a fail-safe timer during commissioning and should roll back when it expires, but during development it is quicker to erase the flash or do a factory reset before each new attempt. And the commissioning window is only open for a limited time after boot, 15 minutes by default in the SDK, after which the device stops advertising until it is reset or the window is reopened.
Firmware size matters too. A Matter build with Bluetooth and Wi-Fi is well over 1 MB, so use a module with at least 4 MB of flash and a partition table that fits the application, and watch the free heap during commissioning, when BLE, Wi-Fi and the cryptography all run at once.
To debug methodically, take the phone out of the loop. The Matter SDK includes a command-line controller, chip-tool, that runs on a Linux machine or a Raspberry Pi and prints every step of commissioning. If pairing works there over the same Wi-Fi network, the firmware and network are fine and the remaining issue is the phone ecosystem's handling of test devices. If it fails there too, the log shows the exact stage and error.
On chip variants: the original ESP32, the C3 and the S3 do Matter over Wi-Fi with Bluetooth LE commissioning. The ESP32-H2 has an 802.15.4 radio for Matter over Thread and needs a Thread border router on the network. The ESP32-C6 has both radios.
