Initial import from bf-network-r6.opencode — opencode migration

docs/handoff-20260823-session.md

@@ -0,0 +1,89 @@
+# Übergabe — Session 2026-08-23
+
+> **Einstieg für die nächste Session:** diese Datei, dann [`teilprojekte.md`](teilprojekte.md).
+> **Zustand am Netz: unverändert.** Alles, was angefasst wurde, ist zurückgerollt; keine offenen
+> Transaktionen auf `crs326-core`, `access-list` leer, PV liefert.
+
+## Was diese Session war — und was sie wurde
+
+Begonnen als **Doku-Session (Punkt F: `teilprojekte.md` aufteilen)**. Das ist **fertig**. Danach hat
+Christoph den Faden zur Shelly-/Funkmigration aufgemacht, und daraus wurde der größere Teil des Tages.
+
+| | |
+|---|---|
+| ✅ **Doku-Split** | 2217 → 790 Zeilen Hauptdatei + [`teilprojekte-archiv.md`](teilprojekte-archiv.md) (34 abgeschlossene TPs). **Damit ist `doku-cleanup-session.md` A–F komplett** — die Akte kann zu. |
+| ✅ **TP17.1 aktiviert** | Shelly Gen4 raus aus dem WLAN. Entscheidungsreif, nicht gestartet — [Runbook](tp17.1-shelly-gen4-funkmigration-runbook.md). |
+| ✅ **TP17.3 angelegt** | Die Shelly-Regression (Blinken/Doppelklick). **Leithypothese steht, Test ist formuliert.** |
+| ✅ **Funkbild erhoben** | Alle 2,4-GHz-Netze vermessen, Nachbarschaft gescannt. |
+| ✅ **DTU vollständig geklärt** | Inkl. eines Fehlschlags mit 10 min PV-Ausfall — s.u. |
+| ✅ **PSK-Entscheid** | Rotation bleibt, wird **nach** TP17.1 gemacht. Historie bleibt, kein filter-repo. |
+
+## 🔴 Womit die nächste Session anfangen sollte
+
+**TP17.3 — die Shelly-Regression.** Es ist der einzige offene Punkt mit **spürbarem Alltagsschaden**,
+er ist **von uns verursacht**, und er **blockiert TP17.1** (an Geräten, die spinnen, fängt man keine
+Funkmigration an). Der diskriminierende Test steht fertig im TP: `eco_mode` auf `s23` abschalten, AP
+zunächst an lassen, dann AP aus. Klein, reversibel, ein Gerät.
+
+⚠️ **Vorher lesen, nicht überspringen:** der aktivierte AP auf `s23` ist **Christophs Workaround**,
+kein Rückstand. Ich hatte ihn am selben Tag fälschlich als „vergessenen Anker" gemeldet. **Nicht
+abschalten, bevor die Ursache behoben ist.**
+
+## Danach, ohne Rangfolge
+
+- **5-GHz-Umfeldscan**, bevor die **zwei neuen APs** eingebaut werden — 2,4 GHz ist vermessen, 5 GHz
+  nicht, und dort werden die neuen APs geplant. DFS ist von Christoph freigegeben.
+- **Anker-Sweep über alle Shellys** (`WiFi.GetConfig` → `ap.enable`): bei `s23` ist ein AP an, die
+  übrigen 21 sind **nie gegengeprüft** worden. Read-only, eine Minute. *(Ergebnis mit TP17.3 abgleichen
+  — ein aktiver AP kann ein Workaround sein.)*
+- **TP17.1 Schritt 0**: die Entscheidung Zigbee (heute verfügbar, Hersteller-Firmware) vs. Thread
+  (Dritt-Firmware, Garantie weg) vs. warten. Gehört Christoph, nicht dem Umsetzenden.
+- **TP25 Fund F** (5:05-Takt bei IoT) und die Entscheidung **5 GHz auf 20 MHz**.
+- **PSK-Rotation** — nachgelagert hinter TP17.1, Vorarbeit steht im Follow-up.
+
+## Der Fehlschlag des Tages, damit ihn niemand wiederholt
+
+**Auftrag:** den nicht abschaltbaren DTU-AP von ch1 wegbekommen, indem der Client per `access-list` an
+ap2 gebunden wird. **Ergebnis:** der Wechselrichter flog von ap1, kam bei ap2 **nie** an, und auch nach
+dem Rollback nicht zurück — **10 Minuten ohne PV-Telemetrie**, behoben erst durch Christophs
+Re-Provisionierung über die S-Miles-App.
+
+Die Auflösung kam aus dem Gerät selbst (`get-config` über Port 10081, read-only):
+**`channel_select = 0`** — es gibt **keine** feste Kanalwahl. **Nicht der Kanal ist starr, sondern die
+AP-Bindung:** das Gerät sucht keinen anderen AP, es gibt auf.
+
+Drei Merkregeln daraus, alle jetzt in [`wifi-access-list-erklaert.md`](wifi-access-list-erklaert.md):
+1. **`reject` ist kein Umzug, sondern ein Rausschmiss.** Wohin das Gerät geht, entscheidet das Gerät.
+2. **Signalstärke ist kein Nachweis für Assoziationsfähigkeit.**
+3. **Für den PV-Wechselrichter ist die `access-list` gesperrtes Gebiet** — ein `reject` kostet dort
+   einen Vor-Ort-Einsatz.
+
+✅ **Was dabei trotzdem gewonnen wurde:** ap1s Kanal umzulegen **würde** wirken — der DTU folgt, ohne
+je abgewiesen zu werden. Das ist der risikoarme Weg und fällt beim Kanalplan für die neuen APs an.
+
+## Zahlen, die man nicht neu erheben muss
+
+**Funkbild 2,4 GHz** (alles live am 2026-08-23):
+
+| Netz | Kanal | Geräte |
+|---|---|---|
+| WLAN ap1 / ap2 | **1** / **11** | 26 der 27 Clients hängen auf `dirtyvader-iot` |
+| Thread (OTBR) | **15** | ~30 Matter-Knoten |
+| ZHA | **20** | **52** Geräte, SONOFF Dongle-M über `socket://10.40.30.137:6638` |
+| Z2M (`z2m25`) | **25** | 15 Geräte, Sonoff Dongle Plus |
+| Homematic/HmIP | **868 MHz** | 37 Geräte — außerhalb dieser Rechnung |
+
+- **Nachbarschaft ist leise:** kein Fremdnetz über −81 dBm. Die lautesten Störer sind die eigenen —
+  der DTU-AP (ch1, −59) und der Shelly-`s23`-AP (ch11, −51).
+- **ZHA ch20 grenzt an WLAN ch11**, aber `PHY_CCA_FAIL_COUNT = 4` sagt: es beißt nicht. **ZHA bleibt
+  auf 20.** Ein Wechsel auf 18 wäre valide, hat aber keinen Anlass — und **müsste von 52 Geräten
+  mitgemacht werden**.
+- **Shelly-Bestand:** 22 von 26 erreichbar — **12 Gen4**, 8 Gen3, 2 Gen2, alle Firmware `2.0.0`.
+  Nur `s4 kueche_mikrowelle` ist offline (RSSI −93 hinter Metall).
+- **Compliance:** 104/104, 0 Drifts, 26 Rules × 4 Geräte (live geprüft).
+
+## Neue Dokumente aus dieser Session
+
+- [`teilprojekte-archiv.md`](teilprojekte-archiv.md) — 34 abgeschlossene TPs
+- [`tp17.1-shelly-gen4-funkmigration-runbook.md`](tp17.1-shelly-gen4-funkmigration-runbook.md) — Bestand, Firmware-Lage, Funkbild, UART, DTU
+- [`wifi-access-list-erklaert.md`](wifi-access-list-erklaert.md) — **von Grund auf**, auf Christophs Wunsch