Session 2026-08-23 uebergabebereit + access-list von Grund auf erklaert

Uebergabe docs/handoff-20260823-session.md: was die Session war (Doku-Split Punkt F
fertig, dann Shelly-/Funkmigration), womit die naechste anfangen sollte (TP17.3 --
einziger offener Punkt mit spuerbarem Alltagsschaden, von uns verursacht, blockiert
TP17.1), und die Zahlen, die niemand neu erheben muss.

Neu: docs/wifi-access-list-erklaert.md auf Christophs Wunsch ("keine ahnung von tuten
und blasen"). Von Null: was die Liste ist, wo sie unter CAPsMAN lebt, wann sie greift,
was eine Regel matchen kann -- und der eine Satz, der alle Ueberraschungen erklaert:
eine Regel kann nur nein sagen, sie kann kein Geraet irgendwo hinschicken. Dazu die
drei Anwendungsfaelle im Projekt (Signal-Boden, Messen, PSK-Wechsel ohne Flag-Day),
die Governance seit der ComplianceRule und fuenf Merkregeln aus echten Fehlgriffen.

Ausserdem: ein Duplikat von TP17.3 entfernt, das ich beim Anlegen uebersehen hatte --
der Abschnitt existierte bereits und war deutlich gruendlicher (Phasenanschnitt-
Hypothese, Gegenprobe s12, stale eco-Politik, restart_required-Fund). Die
ausfuehrliche Fassung bleibt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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

docs/wifi-access-list-erklaert.md

@@ -0,0 +1,92 @@
+# Die WLAN-`access-list` — von Grund auf erklärt
+
+> **Warum es dieses Dokument gibt:** die `access-list` taucht in diesem Projekt an drei Stellen auf
+> (TP25 Fund E, der Mess-Pin `tp25-pin-s22.sh`, der gescheiterte DTU-Versuch vom 2026-08-23) — und sie
+> ist genau das Werkzeug, mit dem man sich still ins Knie schießt, wenn man ihr Wesen nicht kennt.
+> Stand 2026-08-23.
+
+## In einem Satz
+
+Die `access-list` ist eine **Türsteher-Liste am WLAN**: für jeden Client, der sich anmelden will, geht
+sie von oben nach unten durch und entscheidet **ja oder nein** — pro AP, pro Funkschnittstelle, pro
+Gerät.
+
+## Wo sie lebt
+
+`/interface wifi access-list` — und bei uns **auf dem Manager `crs326-core`**, nicht auf den APs.
+Unter CAPsMAN besitzen ap1/ap2 ihre Radios nicht; sie fragen den Manager. *(Dieselbe Regel wie bei der
+Registration-Table: der Manager führt die Tabellen.)*
+
+## Der eine Satz, den man wirklich verstehen muss
+
+> 🔴 **Eine `access-list`-Regel kann einem Gerät nur „nein" sagen. Sie kann es nicht irgendwo
+> hinschicken.**
+
+Das klingt trivial und ist die Quelle fast aller Überraschungen. Wer einen Client „auf ap2 umziehen"
+will, verbietet ihm in Wahrheit **ap1** — und hofft, dass er von selbst zu ap2 geht. Ob er das tut,
+entscheidet **das Gerät**, nicht der Router:
+
+| Gerätetyp | Reaktion auf ein `reject` |
+|---|---|
+| Telefon, Laptop | sucht sofort einen anderen AP → der Umzug klappt |
+| einfaches IoT-Gerät | hängt am gespeicherten AP fest, versucht es weiter — **oder gibt ganz auf** |
+
+**Am 2026-08-23 live erlebt:** der PV-Wechselrichter wurde auf ap1 abgewiesen, ging **nicht** zu ap2,
+und kam auch nach dem Entfernen der Sperre nicht zurück. Er musste über die Hersteller-App neu
+provisioniert werden. Zehn Minuten Ausfall der PV-Telemetrie. **Ein „nein" an ein Gerät ohne
+Suchlogik ist ein Abschalten.**
+
+## Wann sie greift
+
+**Nur im Moment der Anmeldung** (Association) — nicht laufend. Zwei Folgen:
+- Eine neue Regel wirft bestehende Verbindungen **nicht automatisch** raus … *außer* RouterOS wertet
+  sie neu aus, was es bei Änderungen an der Liste tut: im Log steht dann
+  `disconnected, access-list changed`.
+- Wer eine Regel testet, muss den Client **einmal trennen**, sonst misst er den alten Zustand.
+
+## Was eine Regel matchen kann
+
+| Feld | Bedeutung |
+|---|---|
+| `mac-address` | genau ein Gerät |
+| `interface` | ein bestimmtes Radio bzw. eine bestimmte SSID (bei uns `cap-wifiN` / `cap-wifiN-virtualM`) |
+| `signal-range` | **nur Clients innerhalb dieses dBm-Fensters** — das Werkzeug gegen klebende Clients |
+| `time` | Uhrzeit/Wochentag |
+
+Und als Aktion im Kern: **`accept`** oder **`reject`**. Dazu kommt eine Besonderheit, die
+kein Verbot ist, sondern eine Ausnahme: eine Regel kann einem einzelnen Gerät ein **eigenes
+WLAN-Passwort** zuweisen (`passphrase`) — der Trick, mit dem sich ein PSK-Wechsel ohne Stichtag machen
+lässt (neues Passwort aufs Profil, Altgeräte übergangsweise per MAC mit dem alten weiter).
+
+## Die drei Dinge, für die wir sie brauchen
+
+1. **Signal-Boden gegen klebende Clients** (TP25 „Fund E"). Ein Client, der bei −85 dBm an einem
+   fernen AP klebt, obwohl zwei Meter weiter ein besserer steht, wird mit einem `signal-range`-Fenster
+   frühzeitig abgewiesen — er sucht sich dann den stärkeren. ⚠️ **Wirkt nur, wenn es einen besseren AP
+   gibt.** Auf der Terrasse gab es keinen; dort hätte ein Boden die Lage *verschlechtert*.
+2. **Messen** (`tp25-pin-s22.sh`): ein Testgerät gezielt auf **einen** AP zwingen, um den Gegen-AP zu
+   vermessen. Genau hierfür ist sie gebaut — Testgeräte haben Suchlogik.
+3. **PSK-Wechsel ohne Flag-Day** (s. `passphrase` oben) — vorgemerkt für die Rotation.
+
+## Governance in diesem Projekt
+
+Seit **2026-08-23** steht `/interface wifi access-list` unter der ComplianceRule `wifi-access-list`.
+Das heißt: **jeder Eintrag erzeugt Drift** und gehört als Transaktion geführt
+(`nautobot/gc-transaktion.py begin …`), sonst sieht ein Versuch aus wie ein Versehen.
+Der Soll-Zustand ist **leer**.
+
+## Merkregeln, jede aus einem echten Fehlgriff
+
+- 🔴 **`reject` ist kein Umzug, sondern ein Rausschmiss.** Vorher fragen: *kann und will dieses Gerät
+  woanders hin?*
+- 🔴 **Signalstärke ist kein Nachweis für Assoziationsfähigkeit.** „Der andere AP hört ihn mit −59 dBm"
+  belegt einen Funkpfad — nicht, dass das Gerät dort hingeht.
+- 🔴 **Ein abgewiesener Verbindungsversuch ist in Ping-Daten nicht von einem Funkloch zu
+  unterscheiden**, und der Manager protokolliert ihn auf `info`-Ebene **gar nicht**. Wer mit einem Pin
+  misst, braucht eine eigene Alarmierung für „Gerät hängt nirgends".
+- 🔴 **Die `cap-wifiN`-Nummern sind nicht stabil** — sie werden in der Reihenfolge vergeben, in der
+  sich die CAPs anmelden. Eine Regel, die auf `cap-wifi4` zeigt, kann nach einem AP-Neustart ein
+  anderes Radio meinen. **Vor jedem Eingriff die Zuordnung über `radio-mac` neu bestimmen.**
+  ⚠️ Besonders relevant, sobald die zwei neuen APs dazukommen: dann wird neu durchnummeriert.
+- ⚠️ **Für den PV-Wechselrichter ist die Liste gesperrtes Gebiet** — nicht wegen des Kanals, sondern
+  weil er nach einem `reject` aufgibt und einen Vor-Ort-Einsatz braucht.