Ich hab gestern noch ein wenig gelesen. Dabei ist mir dann klar geworden, dass pah gar nicht soooo falsch lag. Ich hab ständig durch die DLNA-Brille geguckt.

Da ist natürlich auch ne Menge Interaktion dabei. Bei anderen "device-types" u. "servcices" ist das vermutlich gar nicht so wild. "Nur" um ein M-Search auszuführen müsste tatsächlich der multicast-Ansatz genügen.
Hilft aber am Ende dann doch nicht weiter.
Weiterhin war ich überrascht, dass die Module 00_SONOS und 98_DLNARenderer die Logik für die ControlPoint sockets in eigene select-loops legen
Ich vermute, dass das Verhalten blockierend ist und deshalb notwendigerweise in der FHEM-Loop verarbeitet wird.
Folglich werde ich mal ein "UPNP_Controlpoint" erstellen(Kopie v. 98_DLNARenderer), welches
- alleinig auf Port 1900 lauscht--> ReadFn zur Verarbeitung per handleOnce u. den beiden Callback-Funktionen für discovery u. subscriptions
- exclude/include UDN/IP
- M-Search requests stellt(nur bei Initialisierung, evtl. noch per set-Befehl)
- attributgesteuert für "device-types"; ohne Attribut werden alle devices u. services im Netz ermittelt
- readings: friendly-name, UDN, IP, device-type, services je device
- autocreate-Attribut um "client" devices in FHEM automatisch anzulegen
- set subsription Befehl(also Verwaltung der subscriptions, aber initialer "Anstoß" aus dem client-Modul)
Und dann schauen wir mal, was sich da so alles im lokalen Netzwerk tummelt.
Wie ist denn der device-type Deines devices für das Du SSDP-Unterstützung suchst ? Services ?
Wunder Dich nicht, dass ich einiges schreibe. Dient dann der Doku

, die ich sonst gerne vernachlässige.
Grüße Markus