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

[tagedieb]

Hallo Brice

Danke für deinen Hinweis, er bringt folgende Änderung
wenn ich "set MusikFlowK an" oder ein setze bringt keine Änderung, bei "set MusikFlowK on" ändert sich jedoch der Status im FHEM
im Log ist aber keine Eintragung, weder bei der einen, noch bei der anderen Formulierung
im event Monitor erscheint eigenartigerweise bei "set MusikFlowK on" = DLNAClient MusikFlow on
bei "set MusikFlowK an" DLNAClient MusikFlow stream:an , ebenso bei "set MusikFlow ein"  "...stream:ein"
doch der Lausprecher selbst ändert seinen "Zustand" nicht

Hallo dominik
habe gerade deinen Hinweis gelesen -
ich hatte das ganze Device gelöscht (mit delete this device) - nach dem heutigen Neuanlegen - funktioniert jedoch ein restart reibungslos - irgend etwas habe ich das letzte mal bestimmt falsch gemacht
die Ausgabe vom UPnP tester habe ich angehangen
bei der Durchführung deines Hinweises vom

Code Auswählen Erweitern

« Antwort #22 am: 18 August 2015, 19:22:20 » bekomme ich die Fehlermeldung:

Code Auswählen Erweitern

Result:There are no arguments or variable to display 
Status: Invalid arguments (0x80040208)
die Lautsärke, bei einem DLNA Stream über Windows lässt sich von FHEM aus, nicht verändern - über Windows direkt :ja 

Gruss tagedieb

[Brice]

@dominik:
Ich kann über das Dropdown-Listenfeld den vorab eingestellten Stream sowohl mit "an" als auch mit "on" starten. Egal, ob die SA310 im Standby (blaue LED an) oder im Deepstandby (blaue LED aus) ist. Nach Einrichtung hatte ich den LS zunächst nicht aus dem Offline-Modus erwecken können, da hatte ich dann mal "an" probiert. Ist jetzt aber auch schon eine Weile her....

Für die täglichen Routinen verwende ich allerdings "on", z.B.:

Code Auswählen Erweitern

sub
Wecken()
{
  fhem("set HUEDevice2 on");
  fhem("set HUEDevice2 pct 1");
  fhem("set HUEDevice2 effect colorloop");
  fhem("sleep 30");
  fhem("set MyPlayer on");
  fhem("set MyPlayer volume 15");
}


[ufo-hans]

Hallo erstmal!

Ich _glaube_ einen kleinen Fehler gefunden zu haben, wenn mehrere DLNAClients angelegt werden. In meinem Fall habe ich 3 Raspis mit mpd und upmpdcli als Renderer im Einsatz. Diese werden brav gefunden und alles funktioniert _eigentlich_...

Das Problem ist, dass die 3 Renderer mehr oder weniger zufällig irgendeinem der drei definierten Fhem Geräte zugeordnet werden.

Ich bin zwar nicht 100%ig Perl-fit, habe jetzt aber mal folgende Änderungen gemacht, womit die Verwechslung nicht mehr auftritt:

-) die globale Definition der beiden Queues gelöscht

-) in DLNAClient_Define($$)
  $hash->{SQ} = Thread::Queue->new();
  $hash->{TI} = Thread::Queue->new();
   
  my $scanQueue = $hash->{SQ};
  my $threadInput = $hash->{TI};

-) in DLNAClient_ScanDevicesThread, DLNAClient_StartScanThread, DLNAClient_Undef und DLNAClient_Set am Anfang
  my $scanQueue = $hash->{SQ};
  my $threadInput = $hash->{TI};

-) weiters noch bei Übergabe einer Stream-URL zusätzlich ein "on", damit das Device auf eingeschalten geht:
  readingsSingleUpdate($hash,"stream",$file,1);
  readingsSingleUpdate($hash,"state","on",1);

Anbei mal meine 98_DLNAClient.pm - falls jemand probieren will.

Lg, Hans.

PS: die PERL Warnung beim shutdown habe ich aber auch noch nicht wegbekommen...
PPS: Danke für dieses tolle Modul!

[ufo-hans]

PS: die PERL Warnung beim shutdown habe ich aber auch noch nicht wegbekommen...

Ist zwar wahrscheinlich hier auch verpönt - Doppelpost - aber trotzdem...

Mit einem detach() des Scanthreads ist die Fehlermeldung bei mir nun nicht mehr aufgetreten.

    $hash->{SCANTHREAD} = threads->create(\&DLNAClient_ScanDevicesThread, $hash);
    $hash->{SCANTHREAD}->detach();

Lg, Hans.

[Brice]

20150814, v1.5:
- Load last "stream" reading when switching "on"

. ..Prima, dass der zuletzt gestreamte Sender gespeichert wird...

Da ich (jetzt doch  ) unterschiedliche Anforderungen habe, welcher Musiksender bei verschiedenen Events auf den WLan-Lautsprecher gestreamt wird: wenn der Befehl "set MyPlayer <Sender URL>" vor das Kommando "set MyPlayer on" gestellt wird, funktioniert es.

Also z.B. Aktion "Bügeleisen wird eingesteckt" (als watchdog über eine Funk-Master-Slave FS20)

Code Auswählen Erweitern

FMS:on 00:00:20 FMS:off {fhem("set MyPlayer http://mp3-live.swr3.de/swr3_m.m3u",,"set MyPlayer volume 25",,"set MyPlayer on")}; setstate watchdog_MyPlayer_On defined

Oder "Bettfertig" (als Notify über eine FRITZ!DECT200, wenn MediaCenter über eine FS20 S8 Fernbedienung ausgeschaltet wird)

Code Auswählen Erweitern

DECT200_3:set_off.* {
if ($hour >=21)
{
  {fhem("set MyPlayer http://streams.harmonyfm.de/harmonyfm/mp3/livestream.m3u")};
  {fhem("set MyPlayer on")};
  {fhem("set MyPlayer volume 20")};
  {fhem("set HUEDevice2 on")};
  {fhem("set HUEDevice2 pct 10")};
  {fhem("set HUEDevice2 effect colorloop")};
}
}

Super

[dominik]

@ufo-hans:
Vielen Dank Hans für die beiden Änderungen! Perfekt

Habe deine Änderungen in die neue Version integriert...zu finden im 1. Post + noch ein paar Änderungen...

[Christian S.]

Hallo Dominik,

immer wenn ich den DLNAClient definiere zeigt mir WhatsApp (yowsup) STATE Disconnected an. Hast du eine Idee warum?

Grüße
Christian

[dominik]

Hallo Dominik,

immer wenn ich den DLNAClient definiere zeigt mir WhatsApp (yowsup) STATE Disconnected an. Hast du eine Idee warum?

Grüße
Christian

Hi Christian,
ich verwende leider kein WhatsApp in Zusammenspiel mit fhem. Was meinst du mit STATE Disconnected? Den State von WhatsApp? Kommt eine Meldung im Log (verbose 5)?

Gruß,
Dominik

[marvin78]

Hallo Dominik,

immer wenn ich den DLNAClient definiere zeigt mir WhatsApp (yowsup) STATE Disconnected an. Hast du eine Idee warum?

Grüße
Christian

ich würde einmal in beiden Modulen verbose auf 5 stellen und dann schauen, was im Log passiert.

[Christian S.]

bei beiden Modulen verbose 5 zeigt Logfile  folgendes:

2015.12.02 22:00:55 2: WhatsApp: starting yoswup-cli: /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup
2015.12.02 22:00:55 3: WhatsApp: sending /disconnect
2015.12.02 22:00:55 3: WhatsApp: Disconnected
2015.12.02 22:00:55 3: WhatsApp: read: end of file reached while sysread
2015.12.02 22:00:59 1: in DELETED
2015.12.02 22:00:59 1: in DELETED
2015.12.02 22:00:59 1: in DELETED
2015.12.02 22:00:59 1: in DELETED
2015.12.02 22:01:05 5: DLNAClient: start Thread with http://mp3-live.swr3.de/swr3_m.m3u
2015.12.02 22:01:05 1: in DEFINED
2015.12.02 22:01:05 1: in DEFINED
2015.12.02 22:01:05 1: in DEFINED
2015.12.02 22:01:05 1: in DEFINED
2015.12.02 22:01:05 2: WhatsApp: starting yoswup-cli: /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup
2015.12.02 22:01:05 3: WhatsApp: sending /disconnect
2015.12.02 22:01:05 3: WhatsApp: Disconnected
2015.12.02 22:01:05 3: WhatsApp: read: end of file reached while sysread

[dominik]

Der Fehler tritt sofort nach dem define auf? Die Log Meldung "start Thread..." kommt nämlich erst wenn man on drückt oder einen stream zuweist.

Ohne DLNAClient kommt dieser Fehler sicher nicht?

[Christian S.]

Wenn ich define eingebe kommt sofort die Fehlermeldung:

2015.12.03 19:15:39 2: WhatsApp: starting yoswup-cli: /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup
2015.12.03 19:15:39 3: WhatsApp: sending /disconnect
2015.12.03 19:15:39 3: WhatsApp: Disconnected
2015.12.03 19:15:39 3: WhatsApp: read: end of file reached while sysread

Ich hatte gestern mal zwischendurch auf on gedrückt und deshalb die Meldung im Log. Wenn ich den DLNAClient aus der fhem.cfg lösche bekomme ich die Fehlermeldung nicht.

Gruß
Christian

[Christian S.]

Wenn ich den DLNAClient definiere und Fhem neustarte (shutdown restart) ist Fhem nicht mehr erreichbar. Ich muss dann immer den NUC neustarten (sudo reboot).

[dominik]

Ich hab leider keine Idee dazu...aber habe gesehen, dass im WhatsApp Modul Forum scheinbar paar Leute den ähnliche Fehler haben. Zumindest wenn man mit Google nach "WhatsApp: read: end of file reached while sysread" sucht. Vielleicht hat dort noch jemand paar Ideen.

[Brockmann]

Diese Probleme mit Yowsup sind nicht ungewöhnlich. Dass das ursächlich mit DLNA zu tun hat, kann ich nicht glauben. Denn die ganzen Leute mit diesen Problemen im Yowsup-Thread haben sicher nicht alle DLNA im Einsatz.
Bei mir waren Yowsup und DLNAClient ins zwei getrennten FHEM-Instanzen, aber immerhin auf demselben Rechner, insofern wäre ein Zusammenhang nicht ganz auszuschließen. Ist aber sicher eher ein Thema für den Yowsup-Thread. Wenn sich der Zusammenhang mit einem anderen Modul zuverlässig reproduzieren lässt, wäre das für die aber sicher eine wertvolle Information.

Überwiegend off-topic: Ich verwende für FHEM mittlerweile Telegram statt Whatsapp, läuft stabil und störungsfrei ganz ohne Gefrickel. Und beisst sich offenbar auch nicht mit DLNA.