diff --git a/docs/matter-pairing-infra-ssid-runbook.md b/docs/matter-pairing-infra-ssid-runbook.md index 5819de3..b554855 100644 --- a/docs/matter-pairing-infra-ssid-runbook.md +++ b/docs/matter-pairing-infra-ssid-runbook.md @@ -5,25 +5,28 @@ OpenThread-Border-Router auf **demselben L2-Link** sitzen. Dann wirbt der OTBR d *und* Route in den Thread-OMR-Prefix per RA, iOS wertet beides aus — und die fehlende IPv6-Route zwischen VLAN10 und VLAN20 (**TP12.1**) wird gar nicht erst berührt. -**Status:** 🟠 vorbereitet 2026-08-22, **nicht deployt** — s. Blocker. +**Status:** ✅ **einmal durchgespielt am 2026-08-22** (TIMMERFLOTTE angelernt, danach zurückgebaut). +Dies ist ab jetzt **der Standardweg** für jedes neue Thread-Gerät, nicht der Plan B. -> **Erst prüfen, ob dieses Runbook überhaupt nötig ist.** Seit 2026-08-22 läuft der Matter-Server mit -> `ble_proxy: true` (`BLE is enabled (proxy mode)`). Wenn HA eine **connectable** BLE-Quelle hat, -> kommissioniert HA selbst und das Telefon wird nicht gebraucht. Shelly-BLE-Proxies sind -> **Advertisement-Scanner ohne GATT** und reichen dafür vermutlich nicht; ein ESP32 als -> ESPHome-BT-Proxy (`active: true`) reicht. **Dieses Runbook ist der Plan B.** +> **Warum es keinen bequemeren Weg gibt.** Der Matter-Server läuft seit 2026-08-22 mit +> `ble_proxy: true` (`BLE is enabled (proxy mode)`, Handshake steht). Damit könnte **HA selbst** +> kommissionieren und das Telefon wäre raus — es fehlt nur eine **connectable** BLE-Quelle. +> Die Shellys sind es nicht: gemessen `slots: 0, free: 0` auf allen dreien, also reine +> Advertisement-Scanner ohne GATT. Ein ESP32 als ESPHome-BT-Proxy wäre die Lösung, ist aber per +> **User-Entscheid 2026-08-22 abgelehnt**. Bleibt dieses Runbook — oder TP12.1 wirklich bauen. + +> ✅ **Was seit dem ersten Durchlauf leichter ist:** `cfg-infra`, `dp-infra` und `sec-infra` bleiben +> auf User-Wunsch dauerhaft am Manager stehen (inaktiv, in keiner `provisioning`-Zeile). Der Change +> ist deshalb wirklich nur noch das Hinzufügen von `cfg-infra` zu zwei Slave-Listen. --- -## 🔴 Blocker: eine offene Transaktion je Gerät +## ~~🔴 Blocker: eine offene Transaktion je Gerät~~ — erledigt 2026-08-22 -Auf `crs326-core` ist **`TEST-ether3-trunk-ap1-sideboard`** offen (Scope `bridge-vlan`, Frist 2026-09-04, -TP25-Standorttest). `gc-transaktion.py begin` verweigert deshalb eine zweite Akte auf demselben Gerät -(Regel 3). Vor dem Deploy also **eines von beiden**: - -- die ether3-Akte `commit`en oder `rollback`en — sie gehört TP25, das ist Christophs Entscheidung; **oder** -- bewusst ohne Transaktion deployen — dann ist es **undokumentierter Drift**, genau das, was - `docs/transaktionen/README.md` abschaffen wollte. Nicht empfohlen. +Die ether3-Akte wurde am 2026-08-22 zurückgerollt, `crs326-core` ist transaktionsfrei — der Blocker +besteht nicht mehr. **Er kann jederzeit wiederkommen:** Regel 3 erlaubt genau *eine* offene Akte je +Gerät. Steht beim nächsten Mal etwas anderes auf `crs326-core` offen, muss das erst geschlossen werden. +`gc-transaktion.py status` sagt es in einer Zeile. ## Vorbedingungen (alle live geprüft 2026-08-22 ✅) diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 237590a..e71147b 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -658,7 +658,26 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". 2026.06, hier 2026.8.3). Dann kommissioniert **HA selbst** über seinen Bluetooth-Stack; das Telefon ist raus und die VLAN-Grenze wird nie berührt. Braucht eine **connectable** BLE-Quelle — Shelly-Proxies sind reine Advertisement-Scanner (kein GATT), ein **ESP32 als ESPHome-BT-Proxy** (`active: true`) reicht. - Der **ESPHome Device Builder ist bereits installiert**. Damit wird TP12.1 für Matter **optional**. + Der **ESPHome Device Builder ist bereits installiert**. Damit wäre TP12.1 für Matter **optional**. + 🔴 **User-Entscheid 2026-08-22: ESP32 wird NICHT angeschafft.** Damit bleibt `ble_proxy` zwar an + (schadet nicht, kostet nichts), ist aber **wirkungslos** — HA hat keine connectable BLE-Quelle und + wird auch keine bekommen. **Konsequenz, die man beim nächsten Thread-Gerät kennen muss:** der Weg ist + dann wieder die temporäre `-infra`-SSID nach dem Runbook. Die ist inzwischen ein Zweizeiler, weil + `cfg-infra`/`dp-infra`/`sec-infra` am Manager stehen bleiben — aber sie ist jedes Mal ein + Config-Change am Core plus eine Transaktion. Wer das dauerhaft loswerden will, muss **TP12.1 bauen** + (v6-Firewall zuerst); ein dritter Weg ist damit nicht mehr vorgesehen. + +- 🔎 **Nebenbefund 2026-08-22, gehört zur Thread-Gesundheit, NICHT zu IPv6:** drei Matter-Knoten + flappen dauerhaft — **`@1:a` („Diele OG/Treppenauge")**, **`@1:f`** und **`@1:10`**. Muster im + Matter-Server-Log: `IpServiceStatus … Resolving (address is unreachable)`, dann + `offline grace period expired, marking unavailable`, im Abstand von 15–30 Minuten, über Stunden. + Die übrigen ~20 Knoten sind stabil, es ist also **kein** Border-Router- oder Fabric-Problem. + ⚠️ **Vor einer Diagnose die Sonderlage von heute abziehen:** der OTBR ist am 2026-08-22 um 17:33 + neu gestartet (Knoten fielen kurzzeitig von OMR `fd92:…` auf Mesh-Local `fd66:…` zurück), und ap1 + war zwischenzeitlich vom Netz. Erst nachsehen, ob das Flappen **danach** noch besteht — sonst + diagnostiziert man das Nachbeben eines Umbaus. Erste Verdachtsrichtungen, wenn es bleibt: + Thread-Routing/Parent-Wechsel dieser drei Knoten, schwache Funkstrecke zum nächsten Router-Knoten, + oder eine ICD-/Sleepy-End-Device-Eigenheit dieser Geräteklasse. - **Abh.:** hängt an nichts. **Blockiert nichts** — außer künftige Thread-Geräte, solange weder `ble_proxy` noch die `-infra`-SSID steht. Reihenfolge innerhalb des TP ist zwingend: **v6-Firewall nachbauen → dann erst Adressen vergeben.** Gehört unter TP12 (Gesamtkonzept 3 Standorte),