Die Namen der Module sind nicht für Funktion relevant; sind aber für's Verständnis nicht ganz unwichtig.
Sehe ich auch so. Bei UPnP herrscht irgendwie ein ziemliches durcheinander mit den Begriffen. Das Perlupnp mit UPnP::DeviceManager tut sein übriges dazu. Ich hab ne Menge gelesen. Sich an die UPnP-Spezifikation zu halten, finde ich da noch am sinnvollsten.
Demnach ist der Controller ein device, welches in meinen Augen als Steuergerät zu verstehen ist. Nimmt man DLNA, das auf UPnP aufsetzt, so "verbindet" der Controller Mediaserver(z.B. miniDLNA) mit Renderern(z.B. TV). Ein TV kann aber auch Controllerfunktionalität haben, dann nennt man es wohl DLNAPlayer. FHEM sehe ich daher prinzipiell als Controller an, so "schiebt" mein DLNAController ein file auf den DLNARenderer(TV). Was wir bisher nicht als allgemeine Funktionalität in FHEM haben, ist die "Verwaltung" eines DLNAServers: Liste der files, Suchfunktion....Das ließe sich auch am UPNPController "andocken".
Dein SEMP-Gateway sehe ich vergleichbar zu DLNA als zu "steuerndes" device. Der SHM ist der Controller. Wenn wir das Gateway in FHEM abbilden, so ist es ein "Enddevice", welches dem Controller events liefert oder durch den Controller gesteuert werden kann. Warum der Autor von perlupnp das Modul DeviceManager genannt hat ist mir ein Rätsel. Gemanaged wird da ja gar nichts(bei Deinem Gateway ist das was anderes, aber diese Funktionalität kommt ja auf die andere Seite des Gateways).
Betrachtet man es technisch, dann hat ein Controller keine xml-description(location), kein device, keinen service, es kann nichts bei ihm subscribed werden. Umgekehrt hat das device eine location, services, die von anderen subscribed werden können und actions über die es gesteuert werden kann. Selber subscribed es nicht und steuert auch nichts.
weil das Modul doch die Basis für DLNAManager (DLNAController) und UPNPDevice (UPNPManager) ist, oder?
Nein. UPNPDevice ist völlig unabhängig vom Controller. Es besteht keinerlei informationstechnische Verbindung zwischen diesen beiden Module(ist so natürlich auch nicht ganz richtig, weil es noch das Modul Common.pm gibt, welches beide Module benutzen). Entweder wendet man das eine an oder das andere.
Ich denke es wird vielleicht klarer, wenn Du Dir anguckst, was "unser" SEMP-device macht. Es broadcastet im Netzwerk nur, dass es vorhanden ist, oder meldet sich ggfs. per byebye ab.
Der Controller nimmt die broadcast-messages an und bei Interesse wird subscribed(beim SEMP-device aber nicht, da es gar keine services hat). Das SEMP-device ist also vergleichbar, den devices, die der Controller sonst noch so findet. Bei mir die miniDLNA-Server, die Windows-Mediaplayer, meine Samsung-TVs, eine IP-CAM, die Fritte, ein Frittenverstärker. Bei Dir sind es Router, NAS, Radio.
Klarer oder anderer Meinung ?
Edit: Weil Bilder mehr als mein Geschwafel sagen, guck mal
hierDas FHEM-SEMPGateway, TV.... liegen rechts, Controller liegen links. In FHEM besteht ein Controller aus dem physischen(technische Basis=UPNPController) UND logischen Modul(servicespezifisch; z.B. DLNAController).
