Handover der TP25-Session + TP29 (Anwesenheitserkennung) angelegt

Uebergabedokument nach dem Muster des TP6-Handovers, das sich bewaehrt hat. Sein
Wert liegt in zwei Dingen, die eine frische Session nicht selbst herausfinden
kann: die offene Config-Transaktion mit Frist, und die acht Messfallen, die in
dieser Session je einen Fehlbefund produziert haben.

Der Statusstand: TP6 gemessen und nachrangig, TP25 auf dem kritischen Pfad, und
auf crs326-core ist TEST-ether3-trunk-ap1-sideboard offen (Frist 2026-09-04) --
die Compliance ist deshalb absichtlich nicht 92/92.

Inhaltlich neu ist die Umdeutung des Abend-Befunds. Nach dem ap1-Umzug ans
Sideboard verlieren die Schlafraeume rund 20 dB und fallen auf ap2/2,4 GHz
zurueck. Laut Christophs Massangaben liegen sie aber 2 bzw. 4 m Luftlinie von
ap1, waehrend ap2 4-6 m entfernt ist und zwei zusaetzliche Mauern dazwischen hat.
Ein Client, der so am ferneren AP klebt, hat kein Abdeckungs-, sondern ein
Steering-Problem -- und damit ist das die erste Stelle im Haus, an der Fund E
(signal-range-Boden) wirklich das richtige Werkzeug ist. Auf der Terrasse waere
er falsch gewesen, weil es dort keine Alternative gibt. Der Test dafuer steht im
Handover und ist die naechste Messung.

Ebenfalls korrigiert: der Platz, an dem das Telefon auf der Terrasse
normalerweise steht, ist mit -46 bis -66 dBm gut. Der Dead Spot ist der Teil
dahinter.

TP29 haelt Christophs Idee fest, Anwesenheit ueber BLE (Shellys), WLAN und
mmWave-Radar zu erkennen, um ohne Komfortverlust zu heizen. Der Entwurfsgedanke
sind die komplementaeren Schwaechen der drei Quellen -- BLE braucht ein
getragenes Geraet, WLAN erkennt nur Menschen mit Telefon, Radar auch die
stillsitzende Person, kostet aber einen Sensor je Raum. Nicht auf dem kritischen
Pfad.

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

docs/teilprojekte.md

@@ -64,7 +64,13 @@ ab jetzt bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
 
 </details>
 
-**Nächster Schritt (Stand 2026-08-21): TP25 — die WLAN-Übergaben, nicht CAKE.**
+**Nächster Schritt (Stand 2026-08-21 abends): TP25 — Steering-Test in den Schlafräumen.**
+> 📋 **Einstieg: [`handoff-tp25-session-20260821.md`](handoff-tp25-session-20260821.md)** — dort steht
+> der verifizierte Ist-Stand, die Messfallen und der nächste Test.
+> ⚠️ **Auf `crs326-core` ist eine Config-Transaktion OFFEN** (`TEST-ether3-trunk-ap1-sideboard`,
+> Frist 2026-09-04): ap1 hängt testweise am Sideboard, `ether3` wurde dafür zum Trunk. Die Compliance
+> ist deshalb **absichtlich** nicht 92/92 — `python3 nautobot/gc-transaktion.py status`.
+> 🆕 **TP29** (Anwesenheitserkennung fürs Energiesparen) ist als Idee angelegt, nicht auf dem Pfad.
 > 📌 **Die TP6-Prämisse ist am 2026-08-20/21 gemessen** (Runbook §5): formal Fall B (+28…+47 ms unter
 > Dauer-Upload), aber im Videocall **nicht wahrnehmbar** — kein einziger Problem-Klick über sechs
 > Lastphasen. Laut war stattdessen der Funk: **Sticky Client + Band-Ping-Pong, zwölf Wechsel in neun
@@ -1244,6 +1250,18 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 > grenzt an Terrasse, Arbeitszimmer und Treppe, kostet **keinen neuen AP** und erfüllt damit die
 > User-Randbedingung; zu klären ist die Verkabelung (ap2 hängt an `crs326-branch ether24`).
 > **(3)** dritter AP erst, wenn beides nicht reicht.
+> **(F) 2026-08-21 abends, Raumkarte 2 — ap1 versetzt ans Sideboard (`core ether3`).** Das OG gewinnt
+> (Diele OG −50 ⌀ über 5,5 min mit 0 % Verlust, Technik OG −44), die **Schlafräume verlieren**:
+> Schlafzimmer von −61 (ap1/5 GHz) auf **−83 (ap2/2,4 GHz)**, Kinderzimmer von −53 auf −75, Bad −83 mit
+> 31 % Verlust. 🔴 **Und genau das ist vermutlich KEIN Abdeckungsproblem:** laut User liegen Schlaf- und
+> Kinderzimmer **2 bzw. 4 m Luftlinie von ap1**, während ap2 4–6 m entfernt ist und zwei zusätzliche
+> Mauern dazwischen hat. Ein Client, der so am ferneren AP klebt, ist ein **Steering**-Fall — und damit
+> die erste Stelle im Haus, an der **Fund E (`signal-range`-Boden) wirklich hilft**, weil es hier eine
+> bessere Alternative gibt. **Test steht aus** (Handover §5). Korrektur zur Terrasse: der Platz, an dem
+> das Telefon normalerweise steht, ist mit **−46…−66 dBm gut**; schlecht ist der Teil dahinter.
+> 📋 **Übergabe: [`handoff-tp25-session-20260821.md`](handoff-tp25-session-20260821.md).**
+> ⚠️ **Auf `crs326-core` ist eine Config-Transaktion OFFEN** (`TEST-ether3-trunk-ap1-sideboard`, Scope
+> `bridge-vlan`, Frist 2026-09-04) — die Compliance ist deshalb **absichtlich** nicht 92/92.
 > **Und das passiert TROTZ aktivem 802.11k/v und FT** — live geprüft: `st-main` mit `rrm=yes`/`wnm=yes`,
 > `ft-over-ds=yes`. Die Merkregel `ref_ft_is_not_roaming` („11k/v fehlen") ist damit **historisch**.
 > **Reihenfolge der Maßnahmen** (Doku §6, respektiert die User-Randbedingung „kein neuer AP, solange
@@ -1837,3 +1855,30 @@ TP22 · TP-R · **TP3.2** (08-17) · **TP5** (08-18) · **TP7.1** (08-18) · **T
 7. **Foundation (2026-07-14):** **TP15** (MikroTik-Switching / Omada-WLAN, 2× CRS326 bestellt) ∥ **TP20 (Platform-Postgres, single-site replication-ready)** → **TP21 (Nautobot Golden Config)** ∥ **TP20.1 (Vaultwarden→PG + 2-Site-HA)**. TP20 hängt an **TP18 ①** (Garage-Bucket für pgBackRest).
 
 </details>
+
+---
+
+### TP29 — Anwesenheitserkennung fürs Energiesparen ▸ 💡 **IDEE, noch nicht auf dem kritischen Pfad** (angelegt 2026-08-21)
+> **User-Formulierung (2026-08-21):** „Personen im Haus orten mit BT (Shellys), WiFi und Radar. So
+> kommen wir dem Ziel der Energieersparnis ohne Komfortverlust groß näher."
+
+- **Ziel:** raumgenaue Anwesenheit als Eingangssignal für Heizung und Licht — sparen, **ohne** den
+  typischen Komfortverlust („erst kalt, dann warm, wenn jemand da ist").
+- 🔎 **Der Entwurfsgedanke sind die komplementären Schwächen der drei Quellen** — keine trägt allein:
+  | Quelle | erkennt | erkennt **nicht** |
+  |---|---|---|
+  | **BLE über die Shellys** | grobe Zonen, billig, überall vorhanden | Menschen ohne getragenes Gerät; Raumgrenzen unscharf |
+  | **WLAN** (Registration-Table am Manager: Gerät, AP, Signal) | wer mit Telefon da ist, inkl. AP-Zuordnung | Menschen ohne Telefon; Raum nur so genau wie die AP-Abdeckung |
+  | **mmWave-Radar** | auch die **stillsitzende Person ohne Gerät** | braucht einen Sensor **je Raum** |
+- ✅ **Was schon steht:** Shellys vollständig auf VLAN30 (TP17 ✅), HA produktiv — und mit
+  [`docs/tp6-monitor-core.sh`](tp6-monitor-core.sh) existiert seit TP25 bereits ein Sammler, der die
+  WLAN-Präsenzdaten am Manager mitschreibt (Gerät → AP → Signal, im Sekundentakt).
+- ❓ **Offene Fragen für die erste Session:** Datenpfad ins HA (MQTT oder REST?) · Firewall-Regeln für
+  neue Sensorik (**TP5 ist deny-by-default**, jeder neue Dienst über eine VLAN-Grenze braucht eine
+  Regel) · Aufbewahrung und Privatsphäre der Ortsdaten · ob Radar-Sensoren auf `dirtyvader-iot` laufen
+  oder eigene Segmentierung brauchen.
+- **Abgrenzung:** TP25 **misst** den Funk, TP29 **nutzt** ihn als Sensor — dieselbe Datenquelle,
+  anderes Ziel. Die Raumkarten aus TP25 sind für TP29 direkt verwertbar: sie sagen, wie genau die
+  WLAN-Quelle einen Raum überhaupt auflösen kann.
+- **Abh.:** keine harten. Profitiert von TP25 (Abdeckung/AP-Zuordnung) und TP11 (Monitoring), wenn es
+  dahin kommt. **Kein Blocker für irgendetwas.**