90 lines
5.5 KiB
Markdown
90 lines
5.5 KiB
Markdown
# Ü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
|