# Ü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