ESP32 Matter device advertises fine over BLE but commissioning fails every time — stale QR code after a firmware rebuild?

Yes — that's almost certainly your problem, and it's a really common one on esp-matter once you start rebuilding firmware after the first flash.

The QR code and the 11-digit manual pairing code both encode the same three values: discriminator, passcode (the SPAKE2+ setup PIN), and a product identification pair (VID/PID). These aren't discovered dynamically at commissioning time — they're baked into the firmware's onboarding payload, either from CONFIG_CHIP_DEVICE_DISCRIMINATOR / CONFIG_CHIP_DEVICE_SPAKE2_PASSCODE in your sdkconfig, or from the factory partition if you're using esp-matter's factory data provider. The commissioner (Apple Home in your case) reads the QR code once, extracts those values, and uses the discriminator to filter which BLE advertisement to connect to and the passcode to verify the PASE session (the SPAKE2+ key exchange that establishes the initial secure channel before any cluster data is exchanged).

Here's the part that bites people: esp-matter's default sdkconfig in a lot of example projects has CONFIG_CHIP_DEVICE_GENERATE_RANDOM_DISCRIMINATOR (or an equivalent random-passcode default) enabled unless you've explicitly pinned fixed values. If that's set, every clean build generates a new discriminator and/or passcode, even if you only changed unrelated application code like your endpoint definitions. Your two-week-old printed QR code now encodes a discriminator/passcode pair that doesn't match what's actually running on the chip. Apple Home connects to a BLE advertisement matching the old discriminator if one happens to still be broadcast, or — more likely in your case — finds no matching discriminator, falls back to a slower discovery path, eventually connects to the actual device, and then fails PASE because the passcode doesn't match. That failure mode looks exactly like what you're describing: gets partway through, then silently drops with a generic error instead of a clear "wrong code" message.

Fix, two parts:

1. Pin fixed values for development so this stops happening on every rebuild:

CONFIG_CHIP_DEVICE_GENERATE_RANDOM_DISCRIMINATOR=n
CONFIG_CHIP_DEVICE_DISCRIMINATOR=0xF00
CONFIG_CHIP_DEVICE_GENERATE_RANDOM_PASSCODE=n
CONFIG_CHIP_DEVICE_SPAKE2_PASSCODE=20202021

(Those are the common esp-matter example defaults — don't ship a production unit with a shared example passcode, but they're fine for dev boards.)

2. Regenerate the QR code and manual pairing code to match whatever discriminator/passcode you land on, using the chip-tool payload generate-qrcode command (or the online QR generator in the Matter SDK tools) — don't reuse a printed sticker across firmware revisions unless you've confirmed the values are pinned and unchanged.

Once the values are pinned, you only need to regenerate the code once per project, not per build — that's the whole point of fixing them. For the conceptual side of what's actually happening during commissioning (QR code → BLE discovery → PASE → network credentials → CASE), see what is Matter? — the commissioning section covers the full sequence this bug interrupts partway through.