Übergabe — Session 2026-08-23

Einstieg für die nächste Session: diese Datei, dann 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` (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.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:

reject ist kein Umzug, sondern ein Rausschmiss. Wohin das Gerät geht, entscheidet das Gerät.
Signalstärke ist kein Nachweis für Assoziationsfähigkeit.
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 — 34 abgeschlossene TPs
tp17.1-shelly-gen4-funkmigration-runbook.md — Bestand, Firmware-Lage, Funkbild, UART, DTU
wifi-access-list-erklaert.md — von Grund auf, auf Christophs Wunsch

5.5 KiB Raw Blame History Unescape Escape