UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul

Begonnen von klaus.schauer, 23 September 2020, 20:19:55

Vorheriges Thema - Nächstes Thema

klaus.schauer

Für die Implementierung einer neuen Gateway-Funktion fragt die Gegenstelle Gateway-Parameter und Gateway-Status per Simple Service Discovery Protocol (SSDP) ab. Ist UPnP in Fhem bereits als Routine verfügbar oder wie könnte der Dienst bereitgestellt werden?

amenomade

Ich glaube, das SONOS Modul implementiert UPnP. Aber wahrscheinlich nur zum Zweck des Moduls.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

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

klaus.schauer

DLNARenderer ist, soweit ich das bisher verstehe, ein SSDP-Client, der auf Meldungen eines SSDP-Dienstes (controlled device) hört. Benötigt wird aber die Funktion eines controlled devices, der Advertisement-Meldungen (Notify M-Search) sendet.   

klaus.schauer

Soweit ich das sehe, verwenden das Modul 00_SONOS und 98_DLNARenderer das Perl Paket UPnP http://perlupnp.sourceforge.net/ als Basis. Die Teilpakete Common.pm und ControlPoint.pm sind leicht modifiziert in /FHEM/lib/UPnP abgelegt. Da ich UPnP Devicemanager-Funktionen suche, wäre eine Erweiterung um das Modul DeviceManger.pm aus diesem Paket ein möglicher Weg.

Ich frage mich allerdings, ob es sinnvoll ist, nur für mein Vorhaben wieder eine spezielle Lösung zu bauen. Kommen sich die Module nicht in die Quere, wenn man in Fhem mehrere UPnP-Devices über die Module 00_SONOS und 98_DLNARenderer und ggf. ein weiteres parallel betreibt. Schließlich müssen alle Pakete den SSDP-Verkehr über den IP-Port 1900 monitoren bzw. darüber senden. Wäre es deshalb nicht notwendig, diese Kommunikation in ein zentrales SSDP/UPnP-Modul zu kapseln oder sogar in den zentralen Fhem-Loop einzubauen und über DevIO-Funktionen zugänglich zu machen?

Weiterhin war ich überrascht, dass die Module 00_SONOS und 98_DLNARenderer die Logik für die ControlPoint sockets in eigene select-loops legen, die dann als Coprozesse laufen, siehe z. B. Fragestellung zur Optimierung in https://forum.fhem.de/index.php/topic,117623.0.html. Im Perl Paket UPnP http://perlupnp.sourceforge.net/ gibt es hierfür entsprechende Methoden handle, search_X. Welche Gründe gibt es für dieses Vorgehen?

KölnSolar

ZitatIch frage mich allerdings, ob es sinnvoll ist, nur für mein Vorhaben wieder eine spezielle Lösung zu bauen. Kommen sich die Module nicht in die Quere, wenn man in Fhem mehrere UPnP-Devices über die Module 00_SONOS und 98_DLNARenderer und ggf. ein weiteres parallel betreibt. Schließlich müssen alle Pakete den SSDP-Verkehr über den IP-Port 1900 monitoren
Genau.
ZitatWäre es deshalb nicht notwendig, diese Kommunikation in ein zentrales SSDP/UPnP-Modul zu kapseln oder sogar in den zentralen Fhem-Loop einzubauen und über DevIO-Funktionen zugänglich zu machen?
Bin mir unsicher, ob das hinhaut. Was ist die "Zentrale" ? Controler, Renderer, Server....?
ZitatWelche Gründe gibt es für dieses Vorgehen?
Ich vermute historisch. Ich bin da auch gerade mal wieder drüber gestolpert. Im DLNARenderer kommen die Broadcastmessages auf 1900 an, die dann als "unsinnig" wieder verworfen werden.
Wir sollten auf jeden Fall darüber nachdenken, ob mittlerweile vielleicht mehr Standardperl einsetzbar ist...

Wenn ich es so richtig verstehe, nutzt der  98_DLNARenderer es so: als controler bekannt machen, search (einmalig ? u. exclude per IP u. UDN), subscription+renewal(callback-Funktion), discover(callback-Funktion),mit Select-Loop von FHEM u. dann das playing .  Die services werden (meines Erachtens redundant) im Modul konkret auf die Bedürfnisse eines Audio-devices abgefragt.

Ein FHEM-Controler müsste meines Erachtens das selbe machen. Die generierten devices ein Attribut über den Typ bekommen(automatisch ?) und  die events mitgeteilt bekommen. Die Services(z. B. playing) als set-Funktion umgesetzt werden. Klassisches 2-stufiges Modul ? :-\

Letztendlich steht u. fällt das mit der dann doch stellenweise proprietären Umsetzung von upnp. Samsung scheint da ja so ein böser Kandidat zu sein. :'(
Ich hätte relativ schnell ein "Controler-Modul" aus dem 98_DLNARenderer gebaut, welches "originär" funktioniert. Fraglich, ob die devices funktionieren.  :-\
Grüße Markus
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

Prof. Dr. Peter Henning

Es gibt gerade eine neue Entwicklung, die auch auf Pakete im Netz lauscht. Ist inzwischen sehr komfortabel in Bezug auf das Anlegen von Devices.

https://forum.fhem.de/index.php/topic,117309.0.html

LG

pah

KölnSolar

Upnp/DLNA ist da aber doch etwas komplexer. ;) Nur IO::Socket::Multicast nutzen reicht da nicht.
Aber auch in dem Fall stellt sich die Frage der 2-Stufigkeit: Allgemeines FHEM-Multicast-Modul, welches die empfangenen Nachrichten an das neue Shelly_Modul weiterreicht.
Grüße Markus
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

klaus.schauer

Zitat von: KölnSolar am 10 Januar 2021, 13:56:49
Bin mir unsicher, ob das hinhaut. Was ist die "Zentrale" ? Controler, Renderer, Server....?

Wenn ich es so richtig verstehe, nutzt der  98_DLNARenderer es so: als controler bekannt machen, search (einmalig ? u. exclude per IP u. UDN), subscription+renewal(callback-Funktion), discover(callback-Funktion),mit Select-Loop von FHEM u. dann das playing .  Die services werden (meines Erachtens redundant) im Modul konkret auf die Bedürfnisse eines Audio-devices abgefragt.

Ein FHEM-Controler müsste meines Erachtens das selbe machen. Die generierten devices ein Attribut über den Typ bekommen(automatisch ?) und  die events mitgeteilt bekommen. Die Services(z. B. playing) als set-Funktion umgesetzt werden. Klassisches 2-stufiges Modul ? :-\

Meine erste Idee war, dort zu trennen, wo es devicespezifisch wird sowohl für den Controler aus auch den Server, abhängig von der Deviceart im URN: und ggf. zusätzlich von Modell. D. h. das UPnP-Modul kommuniziert mit einem oder mehreren Controler- und Server-Modulen, die dann auch Spezialitäten behandeln können. Sodass z. B. ein UPnP M-SEARCH an das Modul dispatcht wird, das das Device mit der entsprechenden UUID: hält oder das die entsprechende Deviceart bedienen könnte und dann dessen Rückmeldungen in Feldern NT: und USN: entsprechend verarbeitet werden. Dann wären mehrere gerätespezifische Module parallel betreibbar, müsste man sich "nur noch" um die Nutzdaten kümmern und hätte dafür einen Satz von Routinen nach Fhem-Art angelehnt an die Methoden im Perl Paket UPnP http://perlupnp.sourceforge.net/.

Zitat von: KölnSolar am 10 Januar 2021, 13:56:49
Letztendlich steht u. fällt das mit der dann doch stellenweise proprietären Umsetzung von upnp. Samsung scheint da ja so ein böser Kandidat zu sein. :'(
Ich hätte relativ schnell ein "Controler-Modul" aus dem 98_DLNARenderer gebaut, welches "originär" funktioniert. Fraglich, ob die devices funktionieren.  :-\
Grüße Markus
Wie weit dies generisch machbar ist, dazu fehlt mir derzeit leider noch das notwendige Detailwissen. Ich vermute aber auch, dass man da gerätespezifisch einiges investieren müsste. Der Funktionsumfang des 98_DLNARenderer-Moduls scheint z. B. bei einem Technisat DIGITRADIO 143 CD sehr überschaubar zu sein. Die Lautstärke kann man wohl einstellen. Aber schon der aktuelle Wert wird nicht richtig angezeigt. Das wars dann irgendwie, oder ich mache was falsch.

Prof. Dr. Peter Henning

ZitatUpnp/DLNA ist da aber doch etwas komplexer.
Das sagt jeder von seinem Protokoll  ;D

Im Ernst: Mit immer mehr Devices, die via UDP oder IP kommunizieren, sollte man "Endeckungsroutinen" vereinheitlichen.

LG

pah

KölnSolar

#10
ZitatMeine erste Idee war, dort zu trennen, wo es devicespezifisch wird
Da meinen wir dasselbe. Danach wird es etwas unverständlicher. :-[
ZitatPerl Paket UPnP http://perlupnp.sourceforge.net/.
Das paket kenn ich ja recht gut. ABER  von 2004  ???
Vielleicht sollten wir dann eher auf Net-UPnP umschwenken. Ist wesentlich aktueller und cpan auch offizieller.

Erst einmal nur den Controller-Part. Damit könnte man ein get search realisieren. die gefundenen devices als readings. Was mir jetzt schon fehlt: include/exclude IP/UDN. Muss dann ins Modul. Und dann müsste man checken, wie das Modul auf SSDP broadcast-messages bzgl. add/remove(on/off) reagiert.

Was meinst Du ?

Grüße Markus
Edit: mal tiefer ins paket geschnüffelt: scheint upnp nicht komplett umzusetzen. event-steuerung konnte ich auch nicht entdecken. :'(
Edit2: Im Forum u. FHEM recherchiert: Net-UPnP wird in YAMAHA_MC u. DLNAClient(Vorgänger des DLNARenderer) benutzt. Immer wieder Hinweise auf unzureichende DLNA/Upnp-Umsetzung. :'( Dann also doch perlupnp ? :-\ Ich mach mal ein "Controler"-modul aus dem DLNARenderer mit der genannten Funktionalität.
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

klaus.schauer

#11
Mich wundert auch, dass Perl-Module für UPnP so selten, alt oder unvollständig sind. Gibt wohl wenig Bedarf dafür. Dass Du dich der Sache annehmen will, ist eine gute Nachricht. Danke. Vielleicht kann ich im weiteren Verlauf auch etwas dazu beitragen. Augenblicklich fehlt mir noch das tiefergehende Wissen zu den Protokollen.

KölnSolar

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.
ZitatWeiterhin 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 8), die ich sonst gerne vernachlässige.
Grüße Markus


 


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

klaus.schauer

Ich sehe Bedarf für ein Modul für das Simple Energy Management Protokoll (SEMP), das es dem Home Manager von SMA ermöglicht Geräte in Abhängigkeit von eigener Energieproduktion, Ladezustand von Energiespeichern, Energiepreis und der aktuellen und der prognostizierten Energiebilanz zu steuern.

Fhem müsste dafür per UPnP-Server als Gateway mit einer Anzahl von virtuellen Aktor-Devices agieren. Dabei propagiert sich das Gateway über SSDP. Die Steuerung erfolgt dann über HTTP-Sequenzen. Ob und in welchem Umfang die HTTP-Sequenzen im UPnP-Funktionsumfang abgedeckt sind, ist mir noch nicht klar.

Siehe https://www.photovoltaikforum.com/core/attachment/37918-20141026-short-introduction-semp-sma-pdf/. Die Beschreibung der SEMP-Schnittstelle findet man unter https://www.sma.de/produkte/sma-developer.html.

KölnSolar

#14
Ah, interessant. Passt schön in meine PV-Welt.  ;)

Anbei eine erste Version. Einfach define UPNP_Controller UPNPController Es sind die ersten 3 Punkte umgesetzt: lauschen auf 1900, M-SEARCH(initial u. per set mit searchterm(ssdp:all, upnp:rootdevice......), add(also Reaktion auf ein notify eines devices), Einschränkung über IP/UDN.


Achtung, kann sich leicht blockierend verhalten !
Nach einiger Zeit solltest Du sämtliche devices mit ihren services(..._s_....) u. children(...._c_....) in Deinem LAN als readings erhalten. Bei mir wurden gefunden: Fritte, Frittenverstärker, IPCAM, TV, 2*miniDLNA, WindowsMediaPlayer auf dem PC. Interessant war, dass die Fritte mehrfach auftaucht: unterschiedliche services=unterschiedliche devices UND die Anzeige erfolgt mit verkürzter UDN. Im Falle der Fritte ist das falsch, will heißen die Einträge werden überschrieben.

Bin gespannt ob Dein Sunny-Homemanager und Dein Technissat gefunden wird und welche services die mitbringen.

Grüße Markus
Edit: hier u. hier findest Du ein paar ergänzende Informationen zu Installation, Funktionsweise ... des DLNARenderers. Das UPNPControlpoint verhält sich gleich.
Edit2: Ah, verstehe. Du brauchst
ZitatThe concatenation of the contents "semp:server" and "semp:basePath" ("<semp:server><semp:basePath>")
results in the BaseURL. It is used by the EM as a prefix for the creation of request URLs
Du brauchst die location. Ueber die URI kommst Du dann an die benötigten Daten für die BaseURL. Hab die Location als zusätzliches reading eingebaut.

Edit: test version removed
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