feat(midea): subnet-directed discovery + manual add-by-IP (TP1-Folgefixes)

[CallMeTechie]

Midea: Discovery für Multi-Homed-Hosts + „Per IP hinzufügen" (Folge-Fixes zu TP1)

Reaktion auf einen realen Befund: Cloud-Konto verbunden, aber „Geräte entdecken" findet die Anlage nicht, obwohl sie im Heimnetz hängt. Ursache: Der GateControl-Host ist ein Multi-Homed-VPN-Gateway (WireGuard + Docker-Interfaces, network_mode: host); ein einzelner globaler 255.255.255.255-Broadcast verlässt nur eine Schnittstelle und verfehlt das LAN/WLAN-Subnetz der Anlage.

Fix 1 — Subnetz-gerichtete Discovery (mideaLan.js)

discover() sendet die Probe jetzt zusätzlich an die subnetz-gerichtete Broadcast-Adresse jeder nicht-internen IPv4-Schnittstelle (z. B. 192.168.1.255), nicht nur global. Neuer reiner Helfer computeBroadcast(address, netmask) ((o & m) | (~m & 0xff) pro Oktett, null bei malformed) + subnetBroadcasts(). Pro-Send-Callback isoliert Fehler eines einzelnen Ziels, damit ein Interface, das Directed-Broadcast ablehnt, nicht die gesamte Discovery abbricht. Ziele dedupliziert. Unit-getestet (un-skip-guarded, inkl. Trailing-Dot/Out-of-Range → null).

Fix 2 — „Manuell hinzufügen (per IP)" auf /midea (3 Themes)

Wenn Discovery nicht durchkommt, lässt sich ein Gerät jetzt direkt über seine LAN-IP einbinden — die Schlüssel holt GateControl weiterhin aus dem verbundenen Cloud-Konto. Neues Formular (IP, optional Name, optionales Cloud-Geräte-Dropdown): Cloud-Gerät gewählt → {ip, sn} (V3, Token aus Cloud); keins → {ip} (V2). Nutzt den bestehenden, bereits admin-only + lizenz-gegateten POST /api/v1/midea/devices. Cloud-Dropdown XSS-sicher per DOM-API befüllt; i18n DE/EN (midea.manual.*).

Tests

Volle midea-Suite grün (41 Tests, 39 pass / 2 Live-Skip / 0 fail); Render-Guard GET /midea bestätigt alle 3 Templates. Review (sonnet) „Approved"; 2 Minor-Polish-Findings (computeBroadcast-Kontrakt, Select-Pattern) eingearbeitet.

🤖 Generated with Claude Code