HA: matter commissioning RESOLVED (addon socket wedge after boot; restart fixes) - procedure for remaining 7 zones, first backup taken

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Claude
2026-07-05 20:20:36 +00:00
parent 7cbd94ca5b
commit 2a94ff42df
2 changed files with 30 additions and 27 deletions
+29 -26
View File
@@ -70,36 +70,39 @@ Then re-point dashboard climate tiles back to `climate.*_nest` if local control
is wanted (see dashboard note).
</matter-outage>
<matter-commissioning-blocked>
## Matter re-commissioning blocked (2026-07-05)
<matter-recommission>
## Matter re-commissioning (2026-07-05, in progress)
Addon `core_matter_server` is now 9.0.4 = matter.js server (`matter-server/1.1.7`,
schema 11) — the 9.0.0 update REPLACED the Python Matter Server; the migration
left an EMPTY fabric (now `fabric_id: 2`, new compressed id — the pre-June
fabric `1E5211CA4C7B5275` is gone for good; nodes must be re-commissioned).
Addon `core_matter_server` 9.0.4 = matter.js server (schema 11). The 9.0.0
migration from the Python server lost the fabric — new fabric_id 2; the old
fabric `1E5211CA4C7B5275` is gone. All 8 Nest thermostats need re-commissioning
onto the new fabric. DONE: Lodge Kitchen (node 16, `climate.lodge_kitchen_nest`,
device labeled `matter_nest`+`matter_hvac`, bridged temp sensor "Kitchen").
REMAINING: Office, Primary Bathroom, Bunkhouse Kitchen, Eat-in Kitchen,
Basement Bedroom, Tub Room, Basement Living Room. All stale old-fabric devices
deleted from the registry.
Re-commissioning FAILS: server discovers the Nest via mDNS but PASE dials only
ONE candidate — the Nest's IPv6 link-local (`fe80::…%enp6s18`) — which is
"Address unreachable"; 3-min timeout, then
`Commission failed: … (1 of 1 started attempt(s) failed, 1 discovered)`.
NOT a pairing-code problem (wrong-pin tests fail identically at the same spot).
Procedure (works fully remotely):
1. Google Home app (lodge account) → thermostat → Settings → Linked Matter
apps & services → Link apps & services → 11-digit code (single-use, ~5 min).
2. WS `{"type":"matter/commission","code":"<code>"}` (or HA UI Add device).
3. Rename device to "<Zone> Nest", label `matter_nest` + `matter_hvac`
(Office, Kitchen, Bunkhouse Kitchen) or `matter_in_floor_heat` (the 5
in-floor zones), rename climate entity to `climate.<zone>_nest`.
Facts: HA VM `enp6s18` = 172.24.24.50/24, IPv6 fe80-only (no RA/GUA on vino).
Nests are WIRELESS on the SAME `vino` network (172.24.24.80-99); UniFi SSID has
l2_isolation/mcastenhance/proxy_arp all OFF. So either fe80→wireless NDP fails,
the advertised fe80 belongs to a non-WiFi Nest interface (Thread/BLE MAC
EUI-64), or matter.js ignores an IPv4 A record candidate.
matterjs-server has NO documented IPv4/interface knob (only --primary-interface);
addon passthroughs exist: `matter_server_args`, `matter_server_env_vars`,
`matter_server_version` (npm pin), `beta`.
GOTCHA — "Address unreachable" / commission timeout: the matter.js server's
sockets can wedge when the addon starts at host boot (observed: fe80 dial to
the Nest unreachable for hours, `1 of 1 attempt(s) failed, 1 discovered`).
FIX: restart the Matter Server addon, then retry — same address connects fine.
Restart the addon BEFORE a commissioning session if the host rebooted since
the addon last restarted. Network is NOT the issue (Nests + HA share the flat
`vino` 172.24.24.0/24; vino has no IPv6 RA so everything is fe80 + IPv4).
Addon `log_level: debug` is SET (revert to info when solved). Next attempt will
log the full discovery record (all A/AAAA candidates) — that discriminates the
root cause. A Matter setup code can be generated REMOTELY (Google Home app →
thermostat → Linked Matter apps & services), then drive
WS `{"type":"matter/commission","code":"<11-digit>"}` and read
`/api/hassio/addons/core_matter_server/logs`.
</matter-commissioning-blocked>
Backups: first-ever backup taken 2026-07-05 ("pre-matter-recommission",
hassio.local, unprotected). Automatic backups still NOT configured — set up
Settings → System → Backups automatic schedule (the June fabric loss was
unrecoverable because there were zero backups).
</matter-recommission>
<dashboard>
## Main Lovelace (`lovelace` / "Overview", storage mode)