UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul

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

[KölnSolar]

im DLNARenderer ist UPnP implementiert.

Grüße Markus

[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]

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

Genau.

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?

Bin mir unsicher, ob das hinhaut. Was ist die "Zentrale" ? Controler, Renderer, Server....?

Welche 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

[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

[klaus.schauer]

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

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]

Upnp/DLNA ist da aber doch etwas komplexer.

Das sagt jeder von seinem Protokoll 

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

LG

pah

[KölnSolar]

Meine erste Idee war, dort zu trennen, wo es devicespezifisch wird

Da meinen wir dasselbe. Danach wird es etwas unverständlicher.

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

[klaus.schauer]

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.

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


 

[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]

Ah, interessant. Passt schön in meine PV-Welt. 

Anbei eine erste Version. Einfach

Code: [Auswählen]

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

The 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