FHEM - Anwendungen > Multimedia

Neuentw. Modulpaket zu UPnP: Controller, Device, DLNA(Renderer-Ersatz)

(1/24) > >>

KölnSolar:
Ausgehend von der Fragestellung
--- Zitat von: https://forum.fhem.de/index.php/topic,114457.msg1087213.html#msg1087213 ---UPnP - Simple Service Discovery Protocol (SSDP) als Basismodul
--- Ende Zitat ---
hat sich ergeben, dass der Fragesteller gerne ein Modul hätte, mit welchem sich ein upnp-device in FHEM anlegen lässt. Durch meine Kenntnis(u. nicht völlige Zufriedenheit) mit dem DLNARenderer habe ich als Ziele für eine Neuentwicklung definiert:

1. FHEM-Modulpaket, welches sowohl Controllerfunktionen, als auch Devicefunktion bereitstellt
2. das Thema UPnP in/mit FHEM für user transparenter zu machen. Also quasi einen sniffer bereitzustellen u. wesentliche Funktionen von UPnP in einem Modul umzusetzen
3. wir haben ein paar Module, die das fremde Perlpaket perlupnp (SONOS,DLNARenderer,entertainTV) oder Net::UPnP(YAMAHA_MC) nutzen. Ein gleichzeitiger Einsatz der nutzenden Module ist nicht möglich.
4. Zumindest das Paket perlupnp blockiert FHEM. Daher eine sinnvolle "Entzerrung" von "technischer" UPnP-Funktionalität u. anwenderspezifischen Funktionalitäten in separate Module.
5. Neue Funktionalität(z.B. DLNA-Control von Mediaservern(SONOS hat das glaub ich eingebaut) oder weitere actions des services RenderingControl.......)

Der Weg zum Ziel:
- es gibt kein Perl-Paket, welches umfassend und non-blocking UPnP unterstützt--> das Paket perlupnp hat noch die umfassendste Funktionalität, ist aber blockierend-->perlupnp nutzen;evtl. später non-blocking "umbauen"
- Das physische Modul UPNPController(Physisch bedeutet in FHEM ein device, welches sich in der einen Richtung um die Kommunikation mit der physischen Hardware kümmert, und in der anderen die Kommunikation zu einem logischen Modul, welches die Anwenderfunktionaltät liefert) ist entstanden, um die technischen Kernfunktionalitäten von UPnP in FHEM abzubilden
- Ebenso das Modul UPNPDevice, um in FHEM ein UPnP-device anzulegen.
- Ein 1. logisches Modul, DLNAController, welches in einem 1. Schritt dem Anwender in Verbindung mit UPNPController die selbe Funktionalität wie der DLNARenderer bietet

Die einzelnen Module des aktuellen Entwicklungsstands und ggfs. "Zubehör" findet Ihr unter folgenden Posts attached.
Da ich selber nur eine begrenzte Anzahl von devices habe, seid bitte vorsichtig in der Nutzung. Möglichst in einer Testumgebung, aber zumindest immer darauf gefasst, dass FHEM abstürzt oder looped !!! Alles ist bisher in einem Betastatus mit Fokus auf technische Funktionalität(ohne freezes, Abstürze.... ;))

Modulbeschreibungen u. Quellcode:
UPNPController - Basismodul (notwendig für logische Module wie DLNAController)
UPNPDevice - UPnP-device in FHEM(Basismodul nicht notwendig;keine user-Funktionalität)
DLNAController - logisches Modul für DLNA; to control Renderer-devices; Basismodul mandatory


KölnSolar:
UPNPController

Das Herz des Modulpakets. Es öffnet 3 Ports für die UPnP-Kommunikation mit dem lokalen Netzwerk. Der Searchport wird mit dem vom User definierten device verbunden.
Bei der Definition werden 2 weitere FHEM-devices automatisch für die beiden anderen Ports angelegt. Sie heißen "UPNPSocket-"userdevicename"-"PortNo(Portno.=1900,random) und liegen im room=hidden. Diese beiden devices sollten niemals von user-Seite verändert werden. Abstürze sind sonst vorprogrammiert !!!!

Das Modul nutzt das Paket perlupnp, welches wir tw. bereits in FHEM/lib/UPnP liegen haben.

Das device wird ohne weitere Parameter definiert, z.B.
--- Code: ---define UPNP_Controller UPNPController
--- Ende Code ---

Mit der Definition wird ein search-request im lokalen Netzwerk mit searchterm=ssdp:all gesendet. Dies bewirkt, dass sämtliche eingehenden UPnP-Notify-messages akzeptiert/verarbeitet werden. Dies passiert aber erst dann, wenn sich ein device gem. UPnP-Standard irgendwann periodisch meldet. Soll heißen, es dauert bis alle devices erstmalig erkannt wurden. Etwas beschleunigen kann man es, indem man z.B. den set-Befehl searchterm mit dem Parameter upnp:rootdevice ausführt. Damit werden alle Rootdevices aufgefordert sich sofort zu melden(tun aber nicht alle). Die searchterms werden zwar nur einmalig gesendet, allerdings wird jede (periodisch) eingehende message eines devices gegen die searchterms geprüft. Daher fiel auch die Wahl auf ssdp:all als initialem searchterm. Wer das beenden möchte kann den stopSearch-Befehl mit dem Parameter des searchterms benutzen. Mit etwas UPnP-Know-How können auch andere searchterms z.B. für bekannte services benutzt werden.

Die gefundenen devices werden als readings angelegt. Dabei wird jedes device durch den readingname IP_Port repräsentiert. Attribute des devices werden 1:1 übernommen u. als readings mit entsprechender Bezeichnung angelegt. Die Services eines devices werden mit devicereadingname-zs-service angelegt. Evtl. vorhandene children mit devicereadingname-zz. Die Syntax mit z hat keine Bedeutung u. dient nur der Sortierung. Bei einer FritzBox lässt sich so z.B. die Hierarchie von devices u. services gut erkennen. Mit verbose=5 sollte umfangreich gelogged werden, so dass man quasi eine Dokumentation der im Netzwerk vorhandenen UPnP-devices erhält. Manche physische devices haben mehrere logische UPnP-devices. Werden sie unter demselben Port angesprochen, so erfolgt eine entsprechende Durchnummerierung IP_Port_x.

Die weitere Funktionalität ist subscribe/unsubscribe. Dahinter steckt, dass der Controller sich bei dem device bzw. service anmeldet u. zukünftig mit events versorgt werden möchte, das device also Statusmeldungen aussendet, die dann im Controller empfangen u. verarbeitet werden. Die subscription muss periodisch erneuert werden(renewal). Das macht das Modul automatisch. Als Parameter für den subscribe/unsubscribe-Befehl ist der vollständige readingname des services einzutragen. Am einfachsten per Copy&Paste.

Das service-reading hat folgende Inhalte:
ohne Aktion   - urn des services
subscribe:      - subscribed (nach set subscribe)
                     - subscription committed, timeout x(nach erfolgreicher subscription)
                      - SID, leasetime, property (nach event)
                      - subscription failed (im Fehlerfall)
                      - subscribed but offline (nach Abmeldung durch das device)
unsubscribe: - unsubscribed

Jedes device hat genau ein zusätzliches presence-reading, welches durch das Modul erzeugt wird. Grundsätzlich anhand der alive/byebye Meldungen eines devices. Ein Sonderfall ist, dass das device z.B. Stromausfall kein byebye aussenden konnte. Dann verbleibt der presence-Status "online". Wurde ein service des devices subscribed, dann wird beim nächsten renewal-Versuch der subscription(also bis zu 30min. !) in den offline-Status versetzt.

Über die Attribute usedonlyIPs, ignoredIPs,acceptedUDNs,ignoredUDNs lässt sich der Umfang der devices einschränken(UDN = Unique Device Name eines devices). Die Einschränkungen per UDN funktionieren nur beim define des Controllers.

Die interne Kommunikation zwischen physischem(UPNPController) und logischem Modul(z.B. DLNAController) erfolgt nach dem FHEM-typischen 2-Stufenmodell(dispatch, iowrite, assignIO)

Autocreate-Mechanismus: devices, für die ein logisches Modul existiert, werden per autocreate automatisch angelegt. Erkennung erfolgt anhand der Services.

Changelog
-----------
06.05.21
minor changes

25.04.21 version v0.0.2
new initialization after change of attributes: ignoredIPs, usedonlyIPs, envNamespace, envPrefix
(readings stay untouched)

31.03.21
some bug fixing

13.03.21
postprocessing of services SesssionManagement and SpeakerManagement(Multiroom) added
subscription process changed and optimized(new state possible: subscription committed, timeout x; meaning: device has confirmed subscription with timeout x; no event received so far)
- timeout of each device/service answer is saved
- internal timer runs each minute to check wether a subscription has to be renewed
some bug fixing

27.02.21(13 Downloads)
FHEM restart problem solved
Internal administration by unique UDN instead of IP/Port; automatically deletes no longer used IP/Port readings for devices w. changed IP/Port; 
set delreadings - delete readings - be careful in usage !!!
optimization of presence state and services readings

KölnSolar:
UPNPDevice

diese Modul ist vorerst nur wenig interessant, da es eher für andere Entwickler gedacht ist, die ein "virtuelles" UPnP-device in FHEM erstellen möchten.

zusätzliche Voraussetzungen
- die Datei DeviceManager.pm muss in den Pfad …/FHEM/lib/UPnP kopiert werden
- eine xml-Datei im fhem-Pfad(nicht fhem/FHEM !!!) ist notwendig. Im Standard ist der filename "description.xml". Per attribut file übersteuerbar. Der Pfad mit path.

Das device muss in der beschreibenden xml-Datei mit seinen Eigenschaften und Attributen gem. den UPnP-Standards beschrieben/definiert werden.
Definition für z.B. SMA SEMP

--- Code: ---define  UPNPSEMP UPNPDevice
--- Ende Code ---

Mit dem define wird ein Hilfsdevice "UPNPSocket-devicename"-"Port für den notification port im room hidden angelegt.  Dieses device sollte niemals von user-Seite verändert werden. (Möglicherweise wird zukünftig dieses Hilfsdevice entfallen und die Funktionalität direkt im device realisiert)
Für das ebenfalls durch perlupnp erzeugte socket für port 1900 wird vorerst kein device angelegt, um evtl. Konflikte zu vermeiden.
Services und somit auch subscrption und events werden vorerst nicht unterstützt, da für den bisher einzigen use case SMA SEMP nicht notwendig.

Neben der Öffnung der ports wird das device in seiner Funktion gestartet. Es sendet NOTIFY-broadcast-messages an Port 1900. Gleichzeitig wird der 30min-heartbeat(advertising) zu dessen Wiederholung gestartet.

Mit dem Modul lassen sich dann folgende Aktionen ausführen:
- start - zum starten des devices
- stop - zum stoppen des devices
- advertise - zum zusätzlichen Aussenden einer NOTIFY alive message (passiert per heartbeat periodisch alle 30min.)

ACHTUNG: Nutzt man UPNPController u. UPNPDevice gemeinsam in einer FHEM-Instanz, sollte man im UPNP-Controller tunlichst die IP ausschließen. Sonst kommt es zu fürchterlichen 20s-freezes, deren Ursache ich noch nicht ausgemacht habe.

KölnSolar:
DLNAController

benötigt ein UPNPController-device als IODev

Zusätzlich sind die Perlpakete ◾SOAP::Lite, ◾LWP::Simple, ◾XML::Simple, ◾XML::Parser::Lite, ◾LWP::UserAgent zu installieren in Debian mit

--- Code: ---sudo apt-get install libsoap-lite-perl libparse-http-useragent-perl liblwp-protocol-https-perl
--- Ende Code ---
(Wer bereits SONOS oder DLNARenderer einsetzt hat auch diese Pakete bereits installiert)
Edit: Neues Perlpaket notwendig: sudo apt-get install libxml-libxml-perl (XML::LibXML)

devices werden über das UPNPController-Modul per autocreate automatisch angelegt. devicename entspricht dem dortigen readingname. room entspricht dem room für neue devices.
(eine manuelle Anlage eines devices ist weder notwendig, noch empfohlen !!!)

Bisher hat das Modul die Funktionalität des DLNARenderers. Multiroom(caskeid) ist mangels Hardware nicht richtig implementiert. Tester sind gerne gesehen.

Unterstützt werden also ein Teil des services RenderingControl(mute,volume) u. AVTransport(Abspielen einer Medienkonserve)

Das Modul selber blockiert nicht im Gegensatz zum DLNARenderer. Wohl aber noch der UPNPController. Dort ist bisher lediglich das blockierende Verhalten beim subscription-renewal(genau wie in meiner inoffiziellen Version des DLNARenderers) beseitigt. Infos über freezes bitte melden. Ich selber habe keine nennenswerten freezes in meinem Produktivsystem.

Attached die aktuelle Version. Die heißt aber noch DLNAManager. Diesen Namen wollte ich im Ursprung vergeben, glaube aber mittlerweile, dass DLNAController besser ist.

Changelog
-----------
06.05.21
new method to parse xml-events
installation of package libxml required: sudo apt-get install libxml-libxml-perl
UPNPController version of same date required

31.03.21(11 downloads)
some bug fixing

13.03.21
Multiroom support added; should be the same functionality as known by DLNARenderer
automatic subscription of DLNA services after definition
extensive tests with WindowsMediaplayer(more details about functionality)
some bug fixing

27.02.21(13 Downloads)
FHEM restart problem solved
Modulname changed as proposed
unique UDN as define parameter(you shouldn't care, since define will be done by autocreate)

KölnSolar:
Bisher habt Ihr das DLNARenderer-Modul genutzt. Ein Umstieg ist relativ einfach. Sollte vorerst sicherheitshalber(obwohl es bei mir produktiv läuft) in einem Testsystem vollzogen werden.

Download der beiden Module aus Post #1 u. #3 in Euer Modulverzeichnis. Am besten löscht Ihr dann zuerst alle DLNARenderer-devices. Insbesondere das Master-device u. die 3 Socketdevices im room hidden. Dann legt Ihr mit
--- Code: ---define EuerDevicename UPNPController
--- Ende Code ---
das neue Masterdevice an. Insbesondere für Samsung-devices mit den selben Attributen wie bei DLNARenderer. Sinnvoll ist nach der vollständigen Definition ein save/shutdown/restart. Nach einer Weile seht Ihr im device EuerDevicename eine Übersicht aller UPnP-devices in Eurem Netzwerk nach IP/Port sortiert. Im room hidden findet Ihr 2 socket-"Hilfsdevices".

DLNA-devices wurden per autocreate(sofern wie bei den meisten Installationen aktiviert)automatisch im room des autocreate-Attributs device_room mit
--- Code: ---define DLNA_UDNdesDevices DLNAController UDNdesDevices IP_Port
--- Ende Code ---
angelegt. Nun nur noch die Attribute(wie zuvor) ergänzen u. Ihr könnt das device wie gehabt nutzen.

SamsungAV-Nutzer müssen in SamsungAV-devices zusätzlich noch den DLNARenderer-devicename durch DLNA_UDNdesDevices ersetzen.

Thats it.

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln