Commissioning & HA Setup
Get a flashed W41H1 into Home Assistant over Matter, with no cloud. Commissioning is local
(BLE + Wi-Fi) and runs through python-matter-server on your Home Assistant host (commonly a
Raspberry Pi).
Depth: reverse-engineering/docs/02-matter-local-control.md.
Credentials (CSA test defaults)
The firmware ships the standard Matter test credentials: dev-only, uncertified. The values below are the repo’s default test creds; if you change the credentials in your build, your pairing code and QR differ.
| Field | Value |
|---|---|
| Manual pairing code | 3497-011-2332 (34970112332), your build’s pairing code |
| Discriminator | 3840 (0x0F00) |
| Passcode | 20202021 |
| VID / PID | 0xFFF1 / 0x8001 |

Default test-credential QR (pairing 3497-011-2332). Your build’s QR differs if you change credentials.
Open the pairing window
On the A/C remote, press the “Horizon Airflow” (swing) button 6 times → the buzzer beeps and the display shows “77”. The module clears its stored SSID/password, re-enters pairing, and opens the Matter commissioning window. (Wired-remote alternative: “Sleep” 8 times.) The Matter interface is un-commissioned/dormant from the factory, so a fresh reset guarantees an open window. See the doc for the firmware evidence.
Commission into Home Assistant
- Run
python-matter-serveron the LAN (e.g.ghcr.io/home-assistant-libs/python-matter-server, host-networked, D-Bus mounted for BLE). It runs on your Home Assistant host (commonly a Raspberry Pi), not localhost. - Enable test-net DCL. The device uses test attestation certs, so a default server rejects it
(
AttestationVerificationfailure). Start the server with--enable-test-net-dclso it trusts the CSA Test PAA roots. - HA → Settings → Devices & Services → Matter → point at the server (
ws://<host>:5580/ws). - Add device → enter
34970112332(or scan the QR). Accept the “uncertified device” warning. - Commissioning uses BLE, so the controller must be in Bluetooth range of the A/C.
python-matter-server assigns each commissioned unit its own node ID. Note yours after commissioning
(it is what later read_attribute / update_node calls target). If you commission a second unit it
gets its own separate node ID.
Cross-VLAN mDNS gotcha
Matter operational discovery and transport are IPv6-only; discovery is mDNS, and neither
crosses VLANs by default. If the A/C is on an isolated IoT VLAN and your Home Assistant host is on a
different VLAN, the node commissions but then goes available=False. CASE can’t reach it. A
router/AP mDNS reflector typically does not reflect IPv6 mDNS across VLANs, so that isn’t the
fix.
Working fix: put the controller on the A/C’s L2 (dual-home the host onto the A/C’s VLAN):
- On the host’s switch port, add the A/C VLAN tagged (keep the host’s own VLAN native/untagged).
- Add a persistent IPv6-only VLAN sub-interface via NetworkManager (no
dhclient, it hangs on a sub-iface). Substitute your interface name and the A/C’s VLAN ID foreth0/4:nmcli con add type vlan con-name iot4 dev eth0 id 4 \ ipv4.method disabled ipv6.method auto ipv6.addr-gen-mode eui64 \ connection.autoconnect yes nmcli con up iot4→
eth0.4gets a SLAAC address on the A/C’s VLAN, survives reboot. docker restart matter-serverso CHIP’s mDNS resolver binds the sub-interface. The node becomesavailable=Truewithin ~15 s.
Trust direction stays correct: the A/C is isolated on IoT; only the Matter controller reaches in.
Re-interview after a structure-changing OTA
HA builds entities from the node structure at setup and caches it. After an OTA that adds or removes
endpoints/clusters, the new entities don’t appear until a node re-interview. ota-release.sh
flash auto-calls interview_node on success; if entities still lag, reload the Matter integration
(Settings → Devices & Services → Matter → ⋮ → Reload). See OTA Updates.