UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul

[klaus.schauer]

Der Neustart-Fehler ist mit der zusätzlichen Abfrage weg. Die DLNAManager Devices sind nach dem Neustart einige Zeit "offline". Das passt doch, oder so?

[KölnSolar]

Ja, eigentlich schon. Aber ich muss sowieso mal alles gedanklich durchspielen und dann weitere Prüfungen etc. einbauen. So ist z.B. im Augenblick alles über die IP "verbunden". Erst dachte ich, machen wir ja in vielen Modulen so. Und bei mir ist das kein Problem, weil ich zwar DHCP nutze, aber dann dem DHCP sage, dass eine MAC immer dieselbe IP zu bekommen hat. Es gibt aber bestimmt auch andere Fälle u. wenn die IP sich ändert, bricht das fragile Konstrukt zusammen.  Manche devices sind vermutlich auch im Port variabel. 

Aber im Augenblick kommt es mir auf die Kernfunktionalitäten an. Ich bin schon auf Werbetour, dass zukünftig UPnP nur noch über UPNPController läuft. 

[klaus.schauer]

Die Namen der Module sind nicht für Funktion relevant; sind aber für's Verständnis nicht ganz unwichtig. Wie wäre es etwas so:

- UPNPController >> UPNPIO: Wäre passender, weil das Modul doch die Basis für DLNAManager (DLNAController) und UPNPDevice (UPNPManager) ist, oder?
- DLNAManager >> DLNAController: War je eh klar.
- UPNPDevice >> UPNPManager (>> UPNPDevice): Weil es eben die Funktion des UPnP-Managers hat. Ob es dahinter so etwas wie UPNPDevices geben muss, wird sich noch zeigen.

Oder habe ich die Funktionsaufteilung noch nicht verstanden?

[KölnSolar]

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).

[klaus.schauer]

Inzwischen habe ich einen UPnP-Controller und ein UPnP-Device auf getrennten Fhem-Installationen laufen. Das UPnP-Device mit der SEMP-Konfiguration wird vom UPnP-Controller entsprechend angezeigt. Nun erste Erkenntnisse aus meinen Tests:

1. Ruft man die SEMP URL "location" auf, so wird der Inhalt der xlm-Datei angezeigt, danach blockiert Fhem, auf dem das UPnP-Device läuft, 40 s oder mehr. Dann kommt die Fehlermeldung

Code Auswählen Erweitern


2021.03.01 19:31:54 3: UPNPDevice: handleOnce failed, Can't call method "uri" on an undefined value at FHEM/lib/UPnP/DeviceManager.pm line 782.

2. Das Attribut "file" zieht irgendwie nicht. Im Modulcode sehe ich nicht, warum das so ist. Erst wenn man in sub UPNPDevice_setupDevice die Standardeinstellung

Code Auswählen Erweitern


my $file = AttrVal($name,"file","/opt/fhem/description.xml"); #SEMPdevice.xml

selbst anpasst, wird dies übernommen.
3. Wie soll ermöglichst werden, dass man auf einer Fhem-Installation mehrere UPnP-Devices parallel definiert? Mehrere UPNPDevice kann ich derzeit zwar definieren, diese laufen aber nicht. Das scheitert ja schon daran, dass man für jedes UPnP-Devices ein sep. UPnP-Beschreibungsdokument angeben können müsste. Oder sollen mehrere UPnP-Devices in einem XML-Beschreibungsdokument eingetragen werden?
4. Wie und an welcher Stelle soll in dem Konstrukt insbesondere z. B. der SEMP-spezifische Code abgebildet werden? Soll es das vorliegende Modul UPNPDevice um diese Funktionen angereichert werden oder wird das Modul UPNPDevice noch ausgebaut, sodass die mehrere SUB-Devices sich dem Modul UPNPDevice bedienen können?
5. Gibt es in bestehenden Modulen ein brauchbares Programmbeispiel für einen WEB-Server, der für das SEMP-Device benötigt wird? Bei den anderen von mir betreuten Modulen gab es dafür noch keinen Bedarf. Für mich wäre deshalb ein Beispiel hilfreich.

[KölnSolar]

1. Ruft man die SEMP URL "location" auf, so wird der Inhalt der xlm-Datei angezeigt, danach blockiert Fhem, auf dem das UPnP-Device läuft, 40 s oder mehr. Dann kommt die Fehlermeldung

Bei mir nicht, wenn

UPnP-Controller und ein UPnP-Device auf getrennten Fhem-Installationen laufen

oder meinst Du mit

Ruft man die SEMP URL "location" auf

im Browser ?

2. Das Attribut "file" zieht irgendwie nicht.

Ja, das schrieb ich ja. Keine Ahnung wo es da hakt. Ich kümmere mich...

Oder sollen mehrere UPnP-Devices in einem XML-Beschreibungsdokument eingetragen werden?

Nein, das ist nicht der Plan, sondern mehrere devices mit jeweils eigener location.
(hab ich aber noch nicht ausprobiert. Wird daran scheitern, dass Port 4004 nicht mehrfach nutzbar ist)

4. Wie und an welcher Stelle soll in dem Konstrukt insbesondere z. B. der SEMP-spezifische Code abgebildet werden? Soll es das vorliegende Modul UPNPDevice um diese Funktionen angereichert werden oder wird das Modul UPNPDevice noch ausgebaut, sodass die mehrere SUB-Devices sich dem Modul UPNPDevice bedienen können?

Der UPnP-Part für SEMP ist meines Erachtens in der vorliegenden Version erledigt. Alles weitere müsste in ein eigenes Modul. Dieses Modul würde dann das UPNPDevice per set über "start" u. "stop" steuern, um dem SHM die Bereitschaft anzuzeigen.

5. Gibt es in bestehenden Modulen ein brauchbares Programmbeispiel für einen WEB-Server, der für das SEMP-Device benötigt wird? Bei den anderen von mir betreuten Modulen gab es dafür noch keinen Bedarf. Für mich wäre deshalb ein Beispiel hilfreich.

Ich kenne keins.  Ich würd mal per grep in den Source-Codes nach LWP, Net::http... suchen. Vielleicht lässt sich auch aus FHEMWEB oder MQTT was Server ableiten. 

[klaus.schauer]

Bei mir nicht, wenn oder meinst Du mit im Browser ?

Genau, der Fehler tritt auf, wenn man die XML im Browser aufruft.

Oder sollen mehrere UPnP-Devices in einem XML-Beschreibungsdokument eingetragen werden?
Nein, das ist nicht der Plan, sondern mehrere devices mit jeweils eigener location.

Sollte das denn derzeit schon gehen? Wenn ja, wie? Dann müsste ich doch irgendwie die Devices mit mehrfachen "file"-Attributen definieren und per getrennter "set"-Befehle starten und stoppen können.

Der UPnP-Part für SEMP ist meines Erachtens in der vorliegenden Version erledigt. Alles weitere müsste in ein eigenes Modul. Dieses Modul würde dann das UPNPDevice per set über "start" u. "stop" steuern, um dem SHM die Bereitschaft anzuzeigen.

Das kann man sicherlich als Einstieg so machen und wird wahrscheinlich funktionieren. Irgendwie widerstebt mir dieses Konstrukt aber als endgültige Lösung. Wie soll ein Anwender das verstehen, der einfach nur Devices damit steuern will. Aber erst einmal eins nach dem anderen.

[KölnSolar]

Wie soll ein Anwender das verstehen, der einfach nur Devices damit steuern will

Der kriegt ja nichts davon mit. Der upnp-Kram sind nur prerequesites, die einmalig installiert werden müssen(ginge theoretisch auch im Hintergrund. Ich meine aber, der User sollte es "bewusst" installieren.)
Der User nutzt nur das SEMP-Modul/device. start/stop des UPNPDevices im Gleichklang mit dem disable-Attribut ?

Sollte das denn derzeit schon gehen? Wenn ja, wie? Dann müsste ich doch irgendwie die Devices mit mehrfachen "file"-Attributen definieren und per getrennter "set"-Befehle starten und stoppen können.

Du kannst doch zig devices anlegen, z.B. SEMP1, SEMP2...
Was natürlich erst funktioniert, wenn ich den Fehler beseitigt habe. Ist glaub das ist ein Anfängerfehler  Ich bau dann auch gleich die notwendigen Maßnahmen bei Änderung/Löschung der file/path Attribute ein. Dauert dann wohl Richtung Wochenende.

Genau, der Fehler tritt auf, wenn man die XML im Browser aufruft

Tatsache. Aber kein freeze bei mir. Und dann verschmerzbar.

Edit: Wenn Du nichts anderes findest, kannst Dir ja mal die Serverfunktionsweise von Port 4004 in DeviceManager.pm ansehen.

[klaus.schauer]

Du kannst doch zig devices anlegen, z.B. SEMP1, SEMP2... Was natürlich erst funktioniert, wenn ich den Fehler beseitigt habe. Ist glaub das ist ein Anfängerfehler 

Ist mir eben auch eingefallen... Die Attribute sind zum Ausführungszeitpunkt noch nicht eingelesen.

Wenn Du nichts anderes findest, kannst Dir ja mal die Serverfunktionsweise von Port 4004 in DeviceManager.pm ansehen.

Genau, hat ja u. U. ähnliche Anforderungen zu erfüllen.

[KölnSolar]

Du kannst doch zig devices anlegen, z.B. SEMP1, SEMP2...

dachte ich. Der Notification- u. der Device-Port können leider nicht mehrfach belegt werden.
Da Du bisher der einzige Nutzer bist(u. ich befürchte bleiben wirst), schlage ich vor, dass wir die Anzahl der devices(sofern überhaupt nötig) über das descrption file steuern. D'accord ?
Ich probier es jetzt mal aus....
Grüße Markus

[klaus.schauer]

Na ja die SMA Home Manager sind ja nicht ganz so selten. Da wird schon noch der eine oder andere Gefallen an der Steuerung von Fhem-Devices darüber finden.

Sicher, wenn man mehrere Devices über ein UPnP-Definitionsfile publizieren kann, ist das doch ein gangbarer Weg. Aber warum muss es denn unterschiedliche Ports geben? Reicht es nicht auf einem Port unterschiedliche UPnP-Definitionsfiles anzugeben. Bei der Fritz!Box gibt es

Code Auswählen Erweitern


http://192.168.x.y:49000/l2tpv3.xml
http://192.168.x.y:49000/igd2desc.xml
http://192.168.x.y:49000/MediaServerDevDesc.xml

Diese Beschreibungsfiles werden ja unabhängig voneinander publiziert, wenn ich z. B. den MediaServer ein- / oder ausschalte.

[KölnSolar]

Ich kriegs nicht hin. Absturz mit deep recursion u. out of memory.  . JETZT hab ich aber die "Ebenen" richtig verstanden
DeviceManager
   NotificationPort -> Advertisement
   SSDP-listen-Port 1900
   Registration of each device
   Device(s)
      description -> location
      http-server (device-port)
      start, stop, advertise

Eigentlich müsste man es also auch als 2 stufiges Modul aufbauen. 

Da wird schon noch der eine oder andere Gefallen an der Steuerung von Fhem-Devices darüber finden.

Ja, schon, User, aber nicht Module/devices.

Aber warum muss es denn unterschiedliche Ports geben?

Frag den perlupnp-Entwickler.  Ich hab mir echt einen abgebrochen. UPNP-specification studiert.... Ich sehe keinen Fehler

Code Auswählen Erweitern

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
<deviceType>urn:domain-name:device:deviceType:ver</deviceType>
<friendlyName>this is just a test device</friendlyName>
<manufacturer>FHEM</manufacturer>
<modelName>FHEM UPNP SEMP device</modelName>
<UDN>uuid:fc655837-3054-4670-b1d2-4c7e8aeada08</UDN>
<serviceList>
</serviceList>
<semp:X_SEMPSERVICE
xmlns:semp="urn:schemas-simple-energy-management-protocol:service-1-0">
<semp:server>http://IP[:port]</semp:server>
<semp:basePath>/SEMP</semp:basePath>
<semp:transport>HTTP/Pull</semp:transport>
<semp:exchangeFormat>XML</semp:exchangeFormat>
<semp:wsVersion>x.y.z</semp:wsVersion>
</semp:X_SEMPSERVICE>
<deviceList>
<device>
<deviceType>urn:domain-name:device:deviceType:2</deviceType>
<friendlyName>this is just a 2nd test device</friendlyName>
<manufacturer>FHEM</manufacturer>
<modelName>FHEM UPNP SEMP device 2</modelName>
<UDN>uuid:fc655837-3054-4670-b1d1-4c7e8aeada08</UDN>
<serviceList>
</serviceList>
</device>
</deviceList>
</device>
</root>

[klaus.schauer]

Aufgeschoben ist nicht aufgehoben. In der Zwischenzeit habe ich mit hin und wieder an dem Grundkonzept für das SEMP-Device weitergearbeitet; auch zur Umstellung auf ein zweistufiges Modulmodel.

Jetzt nehmen meine PV-Anlagen Pläne Fahrt auf. Den SMA Sunny Home Manager habe ich schon.

Stehen geblieben waren wir insbesondere bei den Blockaden des Fhem-Prozesses, sobald man die in "location" hinterlegte Adresse, wie http://192.168.6.46:4004/opt/fhem/description.xml aufruft. Zwei Testsysteme zeigen ein identisches Verhalten. Auf den beiden Systemen laufen nur die UPNPDevice Prozesse. Wechselwirkungen mit dem UPNPController können es deshalb nicht sein.

Wie könnte man die Fehler eingrenzen und beheben? Sofern das nicht in den Griff zu bekommen ist, kann man sich die weitere Arbeit zum SEMP erst einmal sparen.

[KölnSolar]

Uih, doch noch Interesse. Mir schwante es bei Deiner Kommunikation mit Rudi zu PEN.

Stehen geblieben waren wir insbesondere bei den Blockaden des Fhem-Prozesses

Da muss ich mich jetzt erst einmal wieder einfuchsen und ein SEMP-device anlegen.

Grüße Markus

[klaus.schauer]

Da muss ich mich jetzt erst einmal wieder einfuchsen und ein SEMP-device anlegen.

Das wäre schön, danke.