2 Commits

Author	SHA1	Message	Date
ruv	6364e0f7d8	feat(adr-115): P8 — Matter bridge tree + commissioning code (38 tests, lib total 410) ... Ships the SDK-independent half of the Matter Bridge production work: ## `matter::bridge` — endpoint tree assembly `build_bridge_tree(nodes) -> BridgeTree` walks a list of `(node_id, friendly_name, [EntityKind])` tuples and produces the Matter endpoint graph the SDK will materialise: EP 0 (BridgedDevicesAggregator) EP 1 (BridgedNode for "Bedroom") EP 2 (OccupancySensor for Presence + PersonCount vendor attr) EP 3 (OccupancySensor for SomeoneSleeping) EP 4 (GenericSwitch for FallDetected) EP 5 (BridgedNode for "Living") … Key invariants enforced by tests: - `PersonCount` collapses onto Presence's endpoint as a vendor attribute, never gets its own endpoint - Biometric entities (HR/BR/pose) are skipped entirely — they never appear in the tree - Every child endpoint carries `BasicInformation` cluster - Endpoint IDs are monotonic + unique (verified by sort+dedup test) - Empty node list yields just the root aggregator - Multi-node bridges keep per-node endpoint isolation - `endpoint(id)` lookup resolves every assigned ID ## `matter::commissioning` — setup-code generation `SetupCodeInput::dev(passcode, discriminator) -> ManualPairingCode` produces the 11-digit human-readable Matter pairing code that users scan/enter into Apple Home / Google Home / HA Matter integration. Validates against Matter Core Spec §5.1.6.1 disallowed-values list (11111111, 12345678, 87654321, all-same-digit patterns, 0). Rejects oversized passcode (≥2^27) and discriminator (≥2^12). The Verhoeff check digit is computed per spec §5.1.4.1.5 — full D/P/INV tables transcribed. The check digit appended to the body is self-consistent (verified by a recompute-and-compare test). `ManualPairingCode::display_4_3_4()` returns the dashed form (`1234-567-8901`) controllers actually display. Bit-packing is a placeholder for v0.7.0 — the chunk values are hashed-then-mod into their decimal widths so the output is deterministic + input-sensitive + Verhoeff-valid, but not yet bit-perfect spec-compliant. The fully spec-compliant code (with QR base-38 payload) lands at P8b when `rs-matter` is integrated; see ADR-115 §9.10. This module gives the SDK layer a stable testable contract to build against. ## Tests - 16 cluster mapping (existing) - 11 bridge assembly (new): aggregator root, branch-per-node, PersonCount collapsing, HR/BR skip, BasicInformation cluster on every endpoint, monotonic+unique IDs, total endpoint count, lookup, multi-node isolation, empty-node list - 11 commissioning (new): dev VID/PID defaults, disallowed-passcode rejection (12 spec values), oversized-passcode rejection, oversized-discriminator rejection, canonical test vectors accepted, 11-digit code always, 4-3-4 display format, determinism, sensitivity to passcode change, sensitivity to discriminator change, Verhoeff self-consistency, invalid-input early return Total lib tests: **410 passed**, 0 failed, 1 properly ignored. Refs #776, PR #778. Co-Authored-By: claude-flow <ruv@ruv.net>	2026-05-23 14:36:10 -04:00
ruv	a7467f5470	feat(adr-115): P7 — Matter cluster + device-type mapping (HA-FABRIC scaffolding, 16 tests) ... Ships the **Matter cluster + device-type mapping table** as pure Rust types independent of any specific Matter SDK. SDK choice between `matter-rs` and chip-tool FFI per ADR-115 §9.10 lands in P8 once spike-validated against real controllers; this commit gives the SDK work a stable mapping target to build against. ## What this lands - `matter::clusters` module: - Spec-defined constants: `CLUSTER_OCCUPANCY_SENSING` (0x0406), `CLUSTER_SWITCH` (0x003B), `CLUSTER_BOOLEAN_STATE` (0x0045), `CLUSTER_BRIDGED_DEVICE_BASIC_INFORMATION` (0x0039), `DEVICE_TYPE_OCCUPANCY_SENSOR` (0x0107), `DEVICE_TYPE_GENERIC_SWITCH` (0x000F), `DEVICE_TYPE_AGGREGATOR` (0x000E), `DEVICE_TYPE_BRIDGED_NODE` (0x0013), `VENDOR_ATTR_PERSON_COUNT` (0xFFF1_0001), `EVENT_SWITCH_MULTI_PRESS_COMPLETE` (0x06). Values transcribed from Matter Core Spec 1.3 §A.1 + Device Library 1.3. - `matter_mapping(EntityKind) -> Option<MatterClusterMapping>` — single source of truth implementing ADR §3.11.1: * Presence / zones / sleeping / room-active / meeting / bathroom → OccupancySensing on OccupancySensor endpoints * Fall / bed-exit / multi-room → Switch.MultiPressComplete events on GenericSwitch endpoints * Distress / elderly-anomaly / no-movement → BooleanState (NOT occupancy — keeps controllers from binding motion-light scenes to safety alerts) * Person count → vendor-extension attribute on shared OccupancySensor * Fall-risk score → vendor attribute on BridgedNode endpoint * HR / BR / pose / motion-level / motion-energy / presence-score / RSSI → explicit `None` (no Matter cluster represents them, stay MQTT-only per §3.11.4) - `entity_on_matter` + `next_endpoint` helpers. ## Tests (16/16 pass, lib total now 388) - per-entity mapping correctness for every category (occupancy / switch event / boolean state / vendor extension / explicitly None) - distinction between presence (OccupancySensing) and distress (BooleanState) — critical so controllers don't bind motion scenes to safety alerts - `someone_sleeping` lives on its own occupancy endpoint (NOT shared with raw presence) so controllers can wire scenes independently - biometric channels (HR / BR / pose) explicitly verified to have `None` mapping — they NEVER reach Matter - exhaustiveness canary: every `EntityKind` variant hit so adding a new variant fails the test until the matter table is updated - spec-ID sanity: cluster IDs match Matter 1.3 published values ## Why scaffolding-first Per maintainer decision principle (§9): preserve clean protocols, avoid fake semantics, ship MQTT first, validate Matter second. This module locks in the cluster mapping table now so when P8 wires `rs-matter` (or chip-tool FFI fallback), the wire surface is already defined and tested — only the SDK calls change, not the protocol contract. P8 (Matter Bridge production using matter-rs) and P9 (multi-controller validation against Apple Home / Google Home / HA) remain on the v0.7.1 docket per §9.10. Refs #776, PR #778. Co-Authored-By: claude-flow <ruv@ruv.net>	2026-05-23 14:30:32 -04:00