98_DLNARenderer.pm (UPnP) (zuvor 98_DLNAClient.pm)

[KölnSolar]

Und nun der fünfte Ansatz und ich glaube der ist es. Du hast bisher noch nie beschrieben, wie Du das device nebst Attributen definierst. Ich spekuliere, dass Du es im "laufenden Betrieb" machst, also über das webinterface. Dann funktioniert aber das, zumindest für den Samsung notwendige, Attribut envPrefix "s" NICHT. Wirkt also gar nicht.

Daher auch für andere die notwendige Vorgehensweise zur Definition:

Code Auswählen Erweitern

define MasterDLNARenderer DLNARenderer
attr MasterDLNARenderer userattr acceptedUDNs defaultRoom envPrefix envNamespace ignoreUDNs
attr MasterDLNARenderer envPrefix s
attr MasterDLNARenderer defaultRoom usersepcificroom
.
.

Nun sind die 3-Systemdevices im room "hidden" angelegt und in der Regel auch die DLNA-devices per autocreate im room des Attributs defaultroom erzeugt.
Jetzt ein save der .cfg.
Dann ein shutdown/restart
Und erst jetzt ist das Attribut wirksam und es kann getestet werden.

Wenn es das wirklich war, erklär ich gerne warum das so ist.

[MichaelT]

Hallo Markus,

kurzes Feedback. Mit den 30 Sek. läuft es immer noch. Nur wenn ich eine kurze Netzwerk-Unterbrechung habe
fängt sich das renewal nicht mehr.

Code Auswählen Erweitern

2019.01.09 00:00:26.429 4: DLNARenderer: try to renew subscriptions for services, device OG_BAD_Radio
2019.01.09 00:00:26.465 5: DLNARenderer: Carp, Renewal of subscription failed with error: 412 Precondition Failed at ./FHEM/98_DLNARenderer.pm line 1333.

2019.01.09 00:00:26.493 5: DLNARenderer: Carp, Renewal of subscription failed with error: 412 Precondition Failed at ./FHEM/98_DLNARenderer.pm line 1340.

2019.01.09 00:00:26.545 5: DLNARenderer: Carp, Renewal of subscription failed with error: 412 Precondition Failed at ./FHEM/98_DLNARenderer.pm line 1347.

Würde es was bringen, nach einem Netzwerk-Problem - also hiernach

Code Auswählen Erweitern

2019.01.08 16:10:04.242 4: DLNARenderer: try to renew subscriptions for services, device OG_BAD_Radio
2019.01.08 16:10:12.198 5: DLNARenderer: Carp, Renewal of subscription failed with error: 500 Can't connect to 192.168.4.30:55390 at ./FHEM/98_DLNARenderer.pm line 1340.

2019.01.08 16:10:22.238 5: DLNARenderer: Carp, Renewal of subscription failed with error: 500 Can't connect to 192.168.4.30:55390 at ./FHEM/98_DLNARenderer.pm line 1333.

2019.01.08 16:10:32.218 5: DLNARenderer: Carp, Renewal of subscription failed with error: 500 Can't connect to 192.168.4.30:55390 at ./FHEM/98_DLNARenderer.pm line 1347.

ein DLNARenderer_removedDevice aufzurufen und zu warten bis es sich von selbst über den Discover wieder meldet.


Gruß Michael

[KölnSolar]

Hallo Michael,
Du hast Dich ja ganz schön in das Modul reingefuchst.
Das ist ein guter Denkanstoß. Ich überleg mir das so oder ähnlich reinzunehmen. Vielleicht aber eher auf den 412 zu reagieren und über einen internaltimer das  subscription neu aufzubauen.
Ich hab es nur leider immer noch nicht geschafft den timeout verwertbar auszulesen. Ich seh jetzt zwar die Information, kann Sie aber nicht aus dem ganzen Datenwust extrahieren.  Da ist Perl-OOP irgendwie ne Nummer zu hoch für mich. 
Grüße Markus

[Fhemotto]

Jetzt ein save der .cfg.
Dann ein shutdown/restart

Habe ich in den letzten Tagen bestimmt schon gefühlte 100 mal ausgeführt.
Gerade nach dem Test mit dem löschen von allem, und dann wurden die neuen Geräte angelegt, es erscheint das "?" unter Save.
Also Save, und zur Sicherheit "shutdown/restart".
Habe gerade nochmals sicherheitshalber "Save" ,"shutdown/restart" ausgeführt.

ein Vierter: meine damalige Version ? Da hatte ich ja extra für Dich meinen Sohn bestohlen und die Version ging doch bei uns beiden.  Evtl. ohne die Anpassung der Controlpoint.pm ?

Mit. 
Kannst du mir deine Controlpoint.pm unter ( /opt/fhem/FHEM/lib/UPnP) mal geben, zum Vergleich ?
Vielleicht ist da doch  der ,,berühmte Haken"/ Bit/Funktion anders, die unbewusst gemacht wurden.
Vielleicht bei mir: ,,Ich sehe den Wald vor lauter Bäumen nicht" 
Ich denke nun in alle Richtungen, deshalb hab ich auch mal den Pfad mit angegeben.

ein Dritter: mich nervt das subscription Fehlverhalten. Bis jetzt außer verplemperter Zeit aber noch ohne Erfolg.  Vielleicht bringt das ja was, wenn gelöst. Zumindest dann Rückmeldungen des N/G an FHEM.

Ich guck mir das in Ruhe an und bastele mir wieder extensives Logging.

Eventuell könntest du das wieder einbauen siehe:
https://forum.fhem.de/index.php/topic,39706.msg798029.html#msg798029
Hat aber Zeit.
Bin dann leider erst einmal 2 Wochen beruflich unterwegs und kann ab Freitag nichts testen.

Danke


[Edit]

Code Auswählen Erweitern

2019.01.09 17:12:01 1: PERL WARNING: Loading device description failed with error: 500 Can't connect to 192.168.178.2:49000 (Network is unreachable) (Location: http://192.168.178.2:49000/configd.xml) at ./FHEM/98_DLNARenderer.pm line 269

Werde langsam blöde.
Habe hier einen Eintrag im Log gefunden (und vor 2 Tagen)von einer IP die definitiv nicht in meinem Netzwerk sein kann. Habe nur feste IPs, Neuanmeldung Wlan nicht erlaubt. Mein Bereich 192.168.155.xxx.
Aber das soll dich eigentlich erst mal nicht beschäftigen.
Sorry, Mein Problem

[Ajuba]

Den lästigen Access Point konnte ich endlich ruhig stellen durch Einschränkung auf eine IP

Code Auswählen Erweitern

attr dlnadevices usedonlyIPs 192.168.1.204
Als ich im Anschluss noch andere IPs hinzufügte konnte ich aber nicht erreichen, dass diese gefunden und Geräte angelegt wurden. Auch nicht durch Neustart. Kann oder muss man den DLNARenderder neu anstoßen?
Solange ich noch weitere IPs eingetragen hatte, bekam ich beim Versuch eine Lautstärke zu setzen die Meldung, dass DLNARenderer damit beschäftigt sei Geräte zu suchen. Erst als ich die weiteren IPs wieder löschte war das weg.

Bei den Versuchen einen Lautsprecher zu steuern bekomme ich immer die "succeed" Meldungen obwohl sich am Lautsprecher gar nichts tut.
Kurz darauf kamen auch die 2 Fehlermeldungen, die andauern.

Code Auswählen Erweitern

2019.01.09 20:14:27 4: DLNARenderer: Update reading mute with 0
2019.01.09 20:14:27 4: DLNARenderer: Update reading volume with 24
2019.01.09 20:14:42 5: DLNARenderer: RenderingControl: urn:schemas-upnp-org:service:RenderingControl:1 found. OK.
2019.01.09 20:14:43 5: DLNARenderer: RenderingControl, SetVolume(0,Master,3) succeed.
2019.01.09 20:17:46 5: DLNARenderer: RenderingControl: urn:schemas-upnp-org:service:RenderingControl:1 found. OK.
2019.01.09 20:17:46 5: DLNARenderer: RenderingControl, SetMute(0,Master,1) succeed.
2019.01.09 20:17:56 5: DLNARenderer: RenderingControl: urn:schemas-upnp-org:service:RenderingControl:1 found. OK.
2019.01.09 20:17:56 5: DLNARenderer: RenderingControl, SetVolume(0,Master,8) succeed.
2019.01.09 20:19:26 4: DLNARenderer: try to renew subscriptions for services, device DLNA_b88687269248
2019.01.09 20:19:26 5: DLNARenderer: Carp, Renewal of subscription failed with error: 412 Precondition Failed at ./FHEM/98_DLNARenderer.pm line 1333.

2019.01.09 20:19:26 5: DLNARenderer: Carp, Renewal of subscription failed with error: 412 Precondition Failed at ./FHEM/98_DLNARenderer.pm line 1340.


Mit Wireshark habe ich mal versucht beim Lautsprecher 192.168.1.204 mitzulauschen aber da kam eigentlich gar nichts an. Auch nicht als ich ihn mit der App bediente.  Wahrscheinlich ich habe falsch gesucht.
Gibt's einen kurzen Tip worauf ich da achten soll?

[KölnSolar]

Habe gerade nochmals sicherheitshalber  "shutdown/restart" ausgeführt

Mist  Ich hätte wetten können...

Kannst du mir deine Controlpoint.pm unter ( /opt/fhem/FHEM/lib/UPnP) mal geben, zum Vergleich ?

Nein. Ich denke, dass ich morgen eine neue Version einstelle. Dann wird das über ein Attribut gesteuert. In der Controlpoint ist das seit heute schon offiziell.

Eventuell könntest du das wieder einbauen siehe:

Das ist noch immer drin.  Sicherheitshalber gucke ich morgen aber genau.

Habe hier einen Eintrag im Log gefunden (und vor 2 Tagen)von einer IP die definitiv nicht in meinem Netzwerk sein kann.

Das ist dann ähnlich Ajubas AP.  Komisch, dass das auch noch der Port vom N/G ist 

Als ich im Anschluss noch andere IPs hinzufügte konnte ich aber nicht erreichen, dass diese gefunden und Geräte angelegt wurden. Auch nicht durch Neustart. Kann oder muss man den DLNARenderder neu anstoßen?

Dann erklär ich mal die allgemeine Funktionsweise in Ergänzung zu o.g.

Das "master device" ist der Controlpoint. Das setzt EINMALIG bei dessen Definition einen Search-Request ab, auf den dann alle Geräte, die online sind, auf dem mitgegebenen Port (System-DLNARenderer-device Nr. 1) antworten können(und das in der Regel auch tun). Danach erfolgt NIE wieder ein "search". Bei dem define des masters werden die "Eigenschaften" für die Dauer der FHEM-Session UNVERÄNDERBAR festgeschrieben.
Warum werden trotzdem neue Geräte erkannt ? Weil auch jedes device bei Ein-,Ausschalten eine Broadcast-message sendet, nach dem Motto: Hallo hier bin ich bzw. ich bin dann mal weg. (Funktioniert natürlich nicht, wenn man, wie ich, hart per Funksteckdose abschaltet  ) Diese Nachrichten werden an Port 1900 "verschickt". Das ist dann beim Modul das System-device Nr. 2. Nachteilig dabei ist, dass auch nicht DLNA-UPnP-Geräte solche messages auf Port 1900 schicken, z.B. Access Points... 
Bliebe noch System-device Nr. 3. Hier macht das Modul einen eigenen Port auf, teilt dem device mit, dass es auf diesem Port lauscht, um Mitteilungen über Zustandsveränderungen am device zu erfahren. Das ist dann der subscription-process. Dabei wird auch vereinbart wie lange diese Vereinbarung Gültigkeit hat. Diese muss dann natürlich auch immer wieder erneuert werden, renewal halt. Über diesen Weg bekommen wir dann permanente Informationen für Readings-Aktualisierung, events in FHEM(wenn es denn funktioniert).
Dieser DLNA-Standard ist schon eine feine Sache. Das Problem ist nur, dass die Hersteller den Standard unterschiedlich interpretieren.

Und warum schreibe ich das alles ? Ihr wollt ja nur das Modul nutzen. Es ist schon wichtig zu verstehen, was da passiert, dass, im Gegensatz zu anderen Modulen, eben einerseits NUR beim define Eigenschaften quasi UNABÄNDERLICH festgelegt werden, andererseits Festlegungen getroffen werden, mit denen nicht JEDES device einer Installation klar kommt. Das sind dann zumindest die Attribute envPrefix und ein Attribut, das Ihr noch kennenlernt: envNamespace. Ich brauche bei mir beides, damit DLNA meines Samsung TV funktioniert. Zufällig kommt auch der FritzRepeater damit klar. Andere devices habe(OK, jeder hat wohl Win-Mediaplayer)/brauche ich nicht. Für mich prima. Wer aber für unterschiedliche devices unterschiedliche Ausprägungen der Attribute benötigt, hat keine Chance diese in einem System zu realisieren.  Und wenn Ihr halbwegs das Konzept verstanden habt, wisst Ihr auch, dass es je physischem device genau VIER FHEM-devices gibt, die für die Funktionsweise ineinandergreifen. Folglich kann nun jeder für sein Problem überlegen, WANN es zeitlich auftritt und für welche der 4 devices LOGs mit verbose=5 zur Fremd-Analyse einzustellen sind.

In der nächsten Version kommt wie gesagt ein weiteres Attribut, das dann die manuelle Anpassung der Controlpoint überflüssig macht. Auch habe ich die Namensvergabe der Systemdevices etwas verändert. Die werden dann nicht mehr über den Filedescriptor unterscheidbar, sondern über den verwendeten Port. Dadurch wird dann neben der einmaligen define-Festlegung ein defmod/modify möglich. Aber auch nur vorsichtig einzusetzen, da Filedescriptoren (noch) nicht geschlossen werden, neue Ports geöffnet werden, vorher eröffnete offen bleiben, System-device Nr. 3 nicht gelöscht wird....

Und vielleicht nutzt ja jemand die ausführlichen Erläuterungen, um einen Wiki-Beitrag zu beginnen.....

Markus

Edit:

Andererseits und außerdem, wenn das nur einmalig geschieht, sind dann nicht alle nachträglich eingegebenen eingrenzenden Attribute eher sinnlos?

Bei diesen Attributen sollte die Abgrenzung funktionieren. Aber eher die ...IP anstatt ...UDN, eher accept... als ignore..., weil das device sonst schon längst angelegt wurde, Attribute aber nur für die Zukunft ihre Wirkung entfalten.
Zu Deinem konkreten Fall: Du weißt ja jetzt, dass ein search nur einmalig ausgeführt wird. Wie schafft man es bei hinzufügen zu acceptedIPs trotzdem ein neues device zu bekommen ?
Bevor wir über meine Art der Motivation zur Mitwirkung diskutieren die Lösung: physisches device ab- u. wieder einschalten.

[Ajuba]

Das "master device" ist der Controlpoint. Das setzt EINMALIG bei dessen Definition einen Search-Request ab, auf den dann alle
ich schreibe noch weiter..

Ohne deine weitere Erklärung abzuwarten...
Sowas hab ich mir schon gedacht.
Dann wundere ich mich warum bei einem über die Kommandozeile eingegebenen "Set Volume Befehl" der DLNARenderer meldet, dass er damit beschäftigt sei Geräte zu suchen. Nebenbei bemerkt, wenn man es innerhalb des Geräts einfach mit der "Set" Taste probiert bekommt man das gar nicht mit.

Andererseits und außerdem, wenn das nur einmalig geschieht, sind dann nicht alle nachträglich eingegebenen eingrenzenden Attribute eher sinnlos?


Zu fremden IPs noch etwas:
Bei meinen gestrigen hilflosen Wireshark-Versuchen habe ich einige IPs gesehen wo ich mir dachte, wo zur Hölle kommen die denn her?
Kann das normal sein, dass Geräte mit IPs sprechen oder es zumindest versuchen die man gar nicht glaubt zu haben?
Vielleicht ist das aber vollkommen falsch verstandener Blödsinn weil ich mich noch nicht auskenne.

[KölnSolar]

Und nun die neue Version:
für Samsung TVs(u. FritzRepeater) ist das setzen des neuen Attributs envNamespace auf <undef> notwendig(incl. Klammern).
Noch wichtiger: update von FHEM, damit die seit gestern offiziell geänderte Controlpoint.pm vorhanden ist.
Und am besten nach der Definition des Attributs ein shutdown/restart.

weitere Änderungen:
- Systemdevicenames enden nicht mehr mit dem Filedescriptor, sondern mit dem Port
- für den Fehlerfall des renewals der subscription den internaltimer entfernt; Hinweis des manuellen ab-/abschaltens des devices zur Wiedererkennung
- renewal auf 30 min. erhöht
- Anpassungen des Debug-Loggings
- Neustart des Controlpoints per defmod am master device müsste funktionieren; bleibt aber mit Vorsicht zu genießen

@Michael: das renewal der subscription ist abgesehen vom Intervall kaum verändert, vermutlich taucht bei Dir der alte Fehler auf: Dann die Zeiten des internal timer wieder reduzieren. Eine Automatik bei Netzwerkausfall war auf die schnelle nicht machbar. Ich hab daher erst einmal nur ein Logging eingebaut, damit ich sicher bin an der richtigen Stelle im Modul einzugreifen. Bitte dann neue Logs, wenn der Fehler auftritt.

Grüße Markus

[Fhemotto]

Hallo Marus

Nach Update, Parameter setzen, Save, Reboot, unverändert keine Reaktion.

Werde, wie geschrieben, erst in 2 Wochen weiter testen können.
Werde dann erst mal nach der unbekannten Ip im Netzwerk weiter suchen.

Anmerkung zum neuen Modul:
Modul-Commandref

    envNamespace        Use EnvNamespace for Controlpoint definition. e.g define "" for Samsung devices to work properly

Hier sollte eigentlich ,, Attributs envNamespace auf <undef> notwendig(incl. Klammern)" stehen.

Code Auswählen Erweitern

2019.01.01 00:59:25 3: DLNARenderer: handleOnce failed, junk ' ' after XML element

kommt weiterhin zyklisch

Frage. Kann man das Logs irgendwie erweitern das man die tatsächliche IP sieht und nicht nur ,,uuid"?
Denke immer noch das hier was falsches angesprochen wird.

[Edit]
Und Danke für die Beschreibung Post:665, Habe es zu spät bemerkt ,, wegen ,, ... schreibe weiter"

[KölnSolar]

Kann man das Log irgendwie erweitern das man die tatsächliche IP sieht und nicht nur ,,uuid"?

It depends. Es kommt auf das konkrete Logging an, da das Modul ja völlig unterschiedlich durchlaufen wird. Bei "Reaktionen" auf eingehende messages wird sofort vom Modul in das Controlpoint gesprungen. Die message selber wird erst dort gelesen, ggfs. wird eine der callback-Funktionen des Moduls aufgerufen. Im Fehlerfall kommt nur die Fehlermessage zurück.

Bei einem set-Befehl kann ich alle bekannten Informationen loggen. Hier bleibt aber das, was in der Controlpoint passiert, eine Black box. succeed heißt leider succeed, weil kein Fehler vom Controlpoint kommt. 

Wir machen das anders. Wenn du wieder einsatzbereit bist, schickst Du mir eine PN und ich beschreibe Dir eine einfache Modifikation, die Dir fürchterlich viele und unformatiert Daten liefert, die Du analysieren kannst.


Edit: Ich hab obige Funktions-Beschreibung etwas anders aufbereitet in meine SamsungDoku gepackt.

[Fhemotto]

Ja, Danke

[frank]

Und nun die neue Version:
für Samsung TVs(u. FritzRepeater) ist das setzen des neuen Attributs envNamespace auf <undef> notwendig(incl. Klammern).
Noch wichtiger: update von FHEM, damit die seit gestern offiziell geänderte Controlpoint.pm vorhanden ist.
Und am besten nach der Definition des Attributs ein shutdown/restart.

hi,

ich habe gerade v2.0.7Patch3 vom 98_DLNARenderer.pm und die neue ControlPoint.pm installiert, um mit meinem samsung H5373 zu testen.

allerdings finde ich das attr envNamespace / envPrefix nicht. muss ich das erst im userattr vom master device hinzufügen?

Code Auswählen Erweitern

Internals:
   NAME       dlna
   NR         642
   STATE      initialized
   TYPE       DLNARenderer
   UDN        0
   VERSION    v2.0.7Patch_3
   .attraggr:
   .attrminint:
   READINGS:
     2019-01-11 14:39:27   state           initialized
   helper:
     caskeid    0
     caskeidClients
Attributes:
   defaultRoom 09_Media
   room       09_Media
   userattr   acceptedUDNs defaultRoom ignoreUDNs

laut commanddref ist es ja für das master device.

master device only

    defaultRoom
    Define default room for automatic device creation.

    envPrefix
    Use prefix for Controlpoint definition. e.g define "s" for Samsung devices

    envNamespace
    Use EnvNamespace for Controlpoint definition. e.g define "" for Samsung devices to work properly

    acceptedUDNs
    Define list (comma or blank separated) of UDNs which should be accepted by automatic device creation.
    It is important that uuid: is also part of the UDN and must be included.

    ignoreUDNs
    Define list (comma or blank separated) of UDNs which should be excluded from automatic device creation.
    It is important that uuid: is also part of the UDN and must be included.

    ignoredIPs
    Define list (comma or blank separated) of IPs which should be ignored by Controlpoint.

    usedonlyIPs
    Define list (comma or blank separated) of IPs which should be used by Controlpoint.

wenn es aber im master device angesiedelt ist und mit envNamespace=<undev> "nur" für samsungTV nötig ist, benötige ich dann mehrere master devices für unterschiedlich zu behandelnde gerätegruppen?

bisher funktioniert der DLNARenderer, wie vorher. also im prinzip als "listener", da ich nichts aktiv setzen kann.

[frank]

ok, nach dem löschen aller devices und neu definieren des master devices sind die attribute vorhanden.
nach dem setzen der attribute und fhem restart wird jetzt allerdings meine squeezebox boom nicht mehr gefunden.

mehrere master definieren macht ja irgendwie auch kein sinn, oder?

dafür kann ich jetzt den tv auch steuern. prima und danke. 

[KölnSolar]

Hi frank,

wenn es aber im master device angesiedelt ist und mit envNamespace=<undev> "nur" für samsungTV nötig ist, benötige ich dann mehrere master devices für unterschiedlich zu behandelnde gerätegruppen

Du hast es einerseits richtig erkannt, andererseits geht nur ein master device, da mehrere gemeinsam auf port 1900 lauschen müssten. Da Du ja etwas bewanderter als andere bist, könntest Du es aber trotzdem mit mehreren mastern probieren. Wenn es nicht zum absoluten Chaos(gar Absturz, Dauerblockade) kommt, müsste es bis auf Neuerkennung im laufenden Betrieb funktionieren. Ich würd auf jeden Fall (edit:versuchen) mit usedonlyIPs arbeiten. 
In meiner SamsungDoku hab ich die Hintergründe des Moduls etwas erläutert.

Viel Erfolg und gerne Rückmeldung
Markus

[MichaelT]

Und nun die neue Version:

...

@Michael: das renewal der subscription ist abgesehen vom Intervall kaum verändert, vermutlich taucht bei Dir der alte Fehler auf: Dann die Zeiten des internal timer wieder reduzieren. Eine Automatik bei Netzwerkausfall war auf die schnelle nicht machbar. Ich hab daher erst einmal nur ein Logging eingebaut, damit ich sicher bin an der richtigen Stelle im Modul einzugreifen. Bitte dann neue Logs, wenn der Fehler auftritt.

Grüße Markus

Hallo Markus,

habe mal das Modul in Betrieb genommen. Wie du befürchtet hast, musste ich wieder auf 30 Sek. gehen. Dann läuft es.
Das Logging ist wie erwartet. renewal ... usw.

Ach ja, danke für deine super Erklärung weiter oben, war für mich sehr hilfreich.
Evtl. frickel ich auch mal ein bisschen am Modul rum. Aber perl ist für c++ lastige Menschen eher ungewöhnlich.

Danke und schönes WE.
Gruß Michael