Autor Thema: UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul  (Gelesen 4995 mal)

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1178
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #45 am: 16 Februar 2021, 18:26:12 »
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?

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5142
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #46 am: 16 Februar 2021, 18:48:25 »
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.  ;D :'( 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.  :)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1178
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #47 am: 16 Februar 2021, 19:12:14 »
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?

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5142
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #48 am: 16 Februar 2021, 20:20:35 »
Zitat
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.

Zitat
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).
« Letzte Änderung: 16 Februar 2021, 20:31:59 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1178
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #49 am: 02 März 2021, 18:04:02 »
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
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
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.



Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5142
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #50 am: 02 März 2021, 19:52:07 »
Zitat
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
Zitat
UPnP-Controller und ein UPnP-Device auf getrennten Fhem-Installationen laufen
oder meinst Du mit
Zitat
Ruft man die SEMP URL "location" auf
im Browser ?
Zitat
2. Das Attribut "file" zieht irgendwie nicht.
Ja, das schrieb ich ja. Keine Ahnung wo es da hakt. Ich kümmere mich...
Zitat
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)
Zitat
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.
Zitat
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.  :-\


RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1178
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #51 am: 02 März 2021, 20:41:40 »
Bei mir nicht, wenn oder meinst Du mit im Browser ?
Genau, der Fehler tritt auf, wenn man die XML im Browser aufruft.
Zitat
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.
Zitat
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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5142
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #52 am: 02 März 2021, 22:32:48 »
Zitat
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 ?
Zitat
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. :(
Zitat
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.
« Letzte Änderung: 02 März 2021, 23:01:55 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1178
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #53 am: 03 März 2021, 07:01:21 »
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.
Zitat
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.

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5142
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #54 am: 05 März 2021, 16:34:35 »
Zitat
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
« Letzte Änderung: 05 März 2021, 19:06:02 von KölnSolar »
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1178
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #55 am: 05 März 2021, 17:35:35 »
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
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.
« Letzte Änderung: 05 März 2021, 17:47:57 von klaus.schauer »

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5142
Antw:UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
« Antwort #56 am: 05 März 2021, 19:13:09 »
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.  :-\

Zitat
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.
Zitat
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
<?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>
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt