docs 📄 TP7.2: HA↔Sonos static-host binding + VLAN1/GUEST-Discovery

HA-Sonos waren unavailable: HA hängt auf VLAN1 (10.40.41.105), nicht VLAN20,
und die Sonos-Integration ist SSDP-abhängig (quert VLAN nicht) — frühere
"HA nutzt mDNS/self-healing"-Notiz war falsch.

Fix: static hosts: + advertise_addr in configuration.yaml (discovery-unabhängig,
advertise_addr fixt UPnP-Callbacks trotz Multi-Homing). Zusätzlich VLAN1/GUEST-
Erreichbarkeit: mdns-repeat-ifaces +vlan90,bridge; forward vlan90↔vlan40 (ganzes
MEDIA) + input 5353 vlan90. Flacher-Repeater-Leak bewusst.

- teilprojekte.md: neues TP7.2, TP5/TP7-Regeln nachgezogen
- sonos-inventar.md: HA-Abschnitt korrigiert (SSDP + static hosts)
- tp7-mdns.md: superseding Update-Block (neue Repeater-Ifaces, GUEST-Forward)

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

docs/teilprojekte.md

@@ -162,6 +162,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   - `forward accept vlan10↔vlan40` — TP5: MAIN↔MEDIA (AirPlay/Sonos)
   - `forward accept vlan20↔vlan40` — TP5: INFRA↔MEDIA (HA↔Sonos)
   - `input accept udp/5353 vlan10/vlan20/vlan30/vlan40` — mDNS-Repeater (TP7-Anschluss)
+  - `forward accept vlan90↔vlan40` + `input accept udp/5353 vlan90` — **GUEST→MEDIA (Sonos/Cast), permanent** (TP7.2, 2026-07-03)
   - **WAN-Input-Seal komplett** (TP10-seal-est/inv/dhcp/icmp/lan/wandrop + WG-Hub UDP/51821 accept)
 - ⏳ **Offen:** Deny-by-default am Ende von `forward` (aktuell noch permissiv nach fasttrack); UNTRUSTED/GUEST auf Internet-only pinnen; MGMT isolieren; IoT→INFRA-Whitelist bauen.
 - **IoT→INFRA-Rückmeldung (deine Frage):** IoT darf **aktiv** zu INFRA-Diensten initiieren — Firewall-Allow IoT→INFRA NUR auf **MQTT (1883/8883), HA-API, InfluxDB (8086)** o.ä.; Antworten via established/related; IoT→MAIN bleibt deny. So pusht ein Sensor Daten an HA/MQTT/Influx, ohne dass IoT „frei" ist.
@@ -173,8 +174,8 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - Abh.: TP4.
 
 ### TP7 — Media-Discovery (mDNS) für VLAN 40 ▸ ✅ FERTIG (2026-07-02) — `docs/tp7-mdns.md`
-- ✅ **Built-in mDNS-Repeater** aktiv: `/ip/dns set mdns-repeat-ifaces=vlan10,vlan20,vlan40,vlan30` (RouterOS 7.23.1).
-  MAIN↔MEDIA + INFRA↔MEDIA (für HA) + IOT dazugenommen. Reversibel (Feld leeren).
+- ✅ **Built-in mDNS-Repeater** aktiv: `/ip/dns set mdns-repeat-ifaces=vlan10,vlan20,vlan40,vlan30,vlan90,bridge`
+  (RouterOS 7.23.1; `vlan90`+`bridge`=VLAN-1 seit TP7.2 2026-07-03). MAIN/INFRA/IOT/GUEST/VLAN1 ↔ MEDIA. Reversibel (Feld leeren).
   Realbestand: MAIN=iOS-Client + MacBook, INFRA=Home Assistant, MEDIA=10× Sonos (siehe `docs/sonos-inventar.md`).
 - ✅ **Funktional durchgetestet (2026-07-02):** iOS-Sonos-App (vlan10) **und** Home Assistant (vlan20) finden die
   9 online-Sonos per `_sonos._tcp.local.` (Bonjour) automatisch. Household nicht mehr gesplittet.
@@ -197,6 +198,27 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - **Alternative (verworfen):** macOS-Client temporär in VLAN 40 hängen (unpraktikabel für Alltagsnutzung).
 - Abh.: TP7 ✅. Kein Blocker für TP5-Deny-by-default.
 
+### TP7.2 — HA↔Sonos static-host binding + VLAN1/GUEST-Discovery ▸ ✅ FERTIG (2026-07-03) — `docs/sonos-inventar.md`
+- **Root Cause (widerlegt frühere Doku):** HA-`media_player.*`-Sonos alle `unavailable`. HA sitzt **nicht** auf
+  VLAN 20, sondern noch auf `10.40.41.105` (VLAN-1-Transfernetz, IP-Migration steht aus). Der mDNS-Repeater
+  deckte VLAN 1 **nicht** ab, und die HA-Sonos-Integration ist **SSDP-abhängig** (`manifest dependencies:[ssdp]`,
+  soco 0.31.1) → quert die VLAN-Grenze nicht. Die alten „HA nutzt mDNS/zeroconf, fixed 2026-07-02"-Notizen waren falsch.
+- ✅ **HA-Fix (discovery-unabhängig):** `sonos: media_player: hosts:` mit allen 11 Sonos-IPs + `advertise_addr: 10.40.41.105`
+  in `configuration.yaml` (Backup `.bak-sonos-20260703`). `advertise_addr` fixt die UPnP-Event-Callbacks trotz
+  HA-Multi-Homing (`.105`/`172.16.0.18`/docker). Core-Restart → alle 6 Online-Zonen `idle/playing` (Wohnzimmer-Push
+  verifiziert = Callbacks OK). Terrasse `.198` offline = kein Entity (kommt beim Einschalten). Kurzes Flapping direkt
+  nach Restart = Settling, danach stabil.
+- ✅ **Nebeneffekt:** mit `bridge` im Repeater (s.u.) meldet HA jetzt „Automatic discovery is working, hosts not needed"
+  — die statischen Hosts sind also Redundanz (Gürtel+Hosenträger), bleiben aber als Absicherung.
+- ✅ **VLAN 1 (temp) + GUEST (perm) Discovery/Reach (User-Wunsch 2026-07-03):**
+  - mDNS-Repeater erweitert → `mdns-repeat-ifaces=vlan10,vlan20,vlan40,vlan30,vlan90,bridge` (VLAN-1-untagged=`bridge`).
+  - Firewall: `input accept udp/5353 vlan90` + `forward accept vlan90↔vlan40` (ganzes MEDIA, beide Richtungen; User-Wahl).
+    VLAN 1/`bridge` brauchte nichts (schon via `TP10-seal-lan` + permissiver Forward).
+  - **Bewusst in Kauf:** flacher Repeater → Guests sehen auch MAIN/INFRA/IOT-mDNS-Announcements (Discovery-Leak;
+    echte Verbindungen regelt TP5-Deny-by-default).
+- **Offen/später:** HA→VLAN 20 (IP-Migration nach Omada-PVID-Fix) → dann nur `advertise_addr` auf neue IP; macOS-Desktop-App
+  weiter via SSDP-Reflector TP7.1. Abh.: TP7 ✅, TP5-Holes ✅.
+
 ### TP8 — Identity & Access-Control ▸ research-gated
 - **RADIUS = FreeRADIUS auf der NAS** (✏️ User-Manager v5 kann **KEIN LDAP** → openldap nur via FreeRADIUS anbindbar).
 - **EAP-TLS (Zert) je Gerät + dynamische VLAN-Zuweisung** (RADIUS-Attribut `Tunnel-Private-Group-ID`). **Einfachste Heim-Alternative:** pro VLAN eine SSID mit **WPA3-PSK** (kein RADIUS) — Abwägung Komfort vs. Admin-Aufwand.