Sonos steuern

Begonnen von Will, 05 Januar 2013, 15:51:12

Vorheriges Thema - Nächstes Thema

Reinerlein

Hallo Ingolf,

im Prinzip ist alles OK, die Angaben beim Define werden nicht an den SubProzess übertragen, sondern beeinflussen das Zeit- und Warteverhalten des Fhem-Moduls bzgl. des SubProzesses.

Die Angaben beim SubProzess beziehen sich auf den Anfangs-Verbosewert (kann ja zu Laufzeit geändert werden) und ob Millisekunden in der Logausgabe erfolgrn sollen. Diese Informationen werden in Fhem definiert und hier verwendet...

Wie du siehst, ist die 12 z.B. der Wert, der die Wartezeit für den Start des SubProzesses angibt. Hier also 12 Sekunden. Je nach Hardware kann ein kleinerer oder größerer Wert besser sein... Standardmäßig (wenn nicht von dir angegeben) wird hier 8 verwendet, was einen guten Wert für einen Raspberry Pi darstellt.

Die 30 ist das Intervall in Sekunden, in dem überprüft wird, ob ein Sonosplayer noch erreichbar ist.

Die 5 ist eine Wartezeit, bevor überhaupt versucht wird, einen SubProzess zu starten. Diese ist vor allem beim Restart von Fhem wichtig, da der verwendetet Port vielleicht zu langsam vom Betriebssystem wieder freigegeben wird.
Hier gibt man im Normalfall nur etwas an, wenn es Probleme gibt...

Und wenn du einen Normalen Betrieb des Moduls hast (also Fhem und SubModul auf demselben Rechner und automatisch gestartet), dann gib keine IP-Adresse an, sondern localhost wie im Beispiel.
Im einfachsten Fall gibst du einfach gar nichts an, sondern nur

define Sonos SONOS


Bedenke bei der Namensvergabe des Sonos-Devices (bei dir SonosServer), das das die Vorlage für die Namensvergabe der Sonosplayer-Devices ist. Da hieße dann einer z.B. "SonosServer_Wohnzimmer". Natürlich kann man das alles in Fhem auch nachträglich ändern, ist aber Arbeit...

Grüße
Reiner

JoeALLb

Ich möchte automatisch eine Gruppe bilden, wenn sich ein player mit einem Radiosender einschaltet, der auf einem anderen Player schon läuft.
Die Zeitverzögerung ist ja kaum auszuhalten.
Hat jemand dafür schon eine Lösung? Mir fehlt gerade der richtige Anknüpfungspunkt.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

oli82

#2387
Guten Morgen justme1968.

Leider bekomme ich den "Odd number of elements" Fehler nicht weg.
Deine vorgeschlagene Änderung an der http.pm habe ich zwar durchgeführt, aber im Log erhalte ich immer noch munter
Odd number of elements in hash assignment at /usr/share/perl5/IO/Socket/IP.pm line 328, <$client> line 4..

Kann ich das loggen dieses Fehlers irgendwie unterbinden?

Danke,
Oli

Edit:
Hab es jetzt erstmal mit dem Vorschlag von dev0 gelöst: http://forum.fhem.de/index.php/topic,47758.msg394364.html#msg394364

Nobby1805

FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

oli82

Danke Nobby1805.
Den Beitrag habe ich leider erst nach dem absenden gesehen.

Capeghost

@ JoeALLb:

Ich hatte auch schon mal versucht, das Problem zu lösen, habe aber keine Lösung gefunden, die mich voll zufrieden gestellt hat.
Was auf jeden Fall geklappt hat, war das gruppieren:

define di_Merge_Sonos_Bad_with_Sonos_Esszimmer DOIF ([Sonos_Esszimmer:transportState] eq "PLAYING" and [Sonos_Bad:transportState] eq "PLAYING" and [Sonos_Bad:currentSender] eq [Sonos_Esszimmer:currentSender])  (set Sonos_Esszimmer AddMember Sonos_Bad)

Beim Eintritt des Ereignisses setzt der Player kurz aus, und danach laufen beide in einer Gruppe weiter.
Ich hätte sie dann aber gerne auch beim Ausschalten eines Gerätes automatisch wieder entkoppelt bekommen, damit das andere weiter läuft. Dafür habe ich aber keine Lösung gefunden. Vielleicht hilft Dir ja der erste Schritt erstmal weiter.

Gruß

Capeghost

JoeALLb

Zitat von: Capeghost am 27 Januar 2016, 22:02:30
define di_Merge_Sonos_Bad_with_Sonos_Esszimmer DOIF ([Sonos_Esszimmer:transportState] eq "PLAYING" and [Sonos_Bad:transportState] eq "PLAYING" and [Sonos_Bad:currentSender] eq [Sonos_Esszimmer:currentSender])  (set Sonos_Esszimmer AddMember Sonos_Bad)

Hallo Capeghost,

danke für die Zeilen: Nun, so in etwa war mein Ansatz auch, das problem ist, dass ich eigentlich alle Kombinationen von Geräten prüfen möchte, und auch, ob es schon eine Gruppe gibt.
Ich bräuchte also sowas wie eine FOR-Schleife im DOIF.
Wenn irgend ein Sender SWR3 einschaltet, soll geprüft werden, ob es schon eine Gruppe gibt, die SWR3 spielt, dann soll de rneue Player dort hinzu gefügt werden. Wenn es keine Gruppe gibt, soll noch auf einen einzelnen Player geprüft werden.

Dein Szenario für das ausschalten bräuchte ich nicht.... da ich eigentlich immer alle gleichzeitig ausschalte.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

m0urs

Ich habe basierend auf den Vorschlägen hier mal bei mir auch eine entsprechende Funktion implementiert, die prüft ob beim Aktivieren eines Players ein anderer Player in der Wohnung bereits das gleiche Programm abspielt. Wenn ja, wird der neue Player automatisch zu diesem Player hinzu gruppiert.

Ich verwende dazu folgende Funktion in 99_myUtils.pm:

sub SONOS_GroupWithExistingPlayer($) {

    my $newPlayer = shift;
    my $groupedWith = "";

    if    ( ($newPlayer ne "SONOS_Wohnzimmer") && (ReadingsVal("SONOS_Wohnzimmer","currentTrackURI","") eq ReadingsVal($newPlayer,"currentTrackURI","")) && (ReadingsVal("SONOS_Wohnzimmer","transportState","") eq "PLAYING") )
          { fhem("set SONOS_Wohnzimmer AddMember ".$newPlayer); $groupedWith="SONOS_Wohnzimmer";   }
    elsif ( ($newPlayer ne "SONOS_Michael") && (ReadingsVal("SONOS_Michael","currentTrackURI","") eq ReadingsVal($newPlayer,"currentTrackURI","")) && (ReadingsVal("SONOS_Michael","transportState","") eq "PLAYING") )
          { fhem("set SONOS_Michael AddMember ".$newPlayer); $groupedWith="SONOS_Michael"; }
    elsif ( ($newPlayer ne "SONOS_Sabine") && (ReadingsVal("SONOS_Sabine","currentTrackURI","") eq ReadingsVal($newPlayer,"currentTrackURI","")) && (ReadingsVal("SONOS_Sabine","transportState","") eq "PLAYING") )
          { fhem("set SONOS_Sabine AddMember ".$newPlayer); $groupedWith="SONOS_Sabine"; }
    elsif ( ($newPlayer ne "SONOS_Schlafzimmer") && (ReadingsVal("SONOS_Schlafzimmer","currentTrackURI","") eq ReadingsVal($newPlayer,"currentTrackURI","")) && (ReadingsVal("SONOS_Schlafzimmer","transportState","") eq "PLAYING") )
          { fhem("set SONOS_Schlafzimmer AddMember ".$newPlayer); $groupedWith="SONOS_Schlafzimmer"; }
    elsif ( ($newPlayer ne "SONOS_Kueche") && (ReadingsVal("SONOS_Kueche","currentTrackURI","") eq ReadingsVal($newPlayer,"currentTrackURI","")) && (ReadingsVal("SONOS_Kueche","transportState","") eq "PLAYING") )
          { fhem("set SONOS_Kueche AddMember ".$newPlayer); $groupedWith="SONOS_Kueche"; }
    elsif ( ($newPlayer ne "SONOS_Bad") && (ReadingsVal("SONOS_Bad","currentTrackURI","") eq ReadingsVal($newPlayer,"currentTrackURI","")) && (ReadingsVal("SONOS_Bad","transportState","") eq "PLAYING") )
          { fhem("set SONOS_Bad AddMember ".$newPlayer); $groupedWith="SONOS_Bad"; }
    else {$groupedWith="keinem Player"}

  return($groupedWith);



Das ginge eleganter, wenn ich eine Schleife über alle meine registrierten Player hinbekommen hätte ;-) Aber es ist ja eine überschaubare Anzahl ...

Weiterhin benutze ich folgendes Notify, das erkennt wenn ein Player in the Status "PLAYING" wechselt und dann obige Funktion aufruft:

define xx.pruefe_sonos_gruppierung notify (SONOS_[a-zA-Z]+:transportState.*PLAYING) {\
\
   log 1,"SONOS Player aktiviert: ".$NAME." Status:".$EVENT;;\
   my $groupedWith=SONOS_GroupWithExistingPlayer($NAME);;\
   return($NAME." wurde mit ".$groupedWith." gruppiert");;\
}


Erste Tests waren soweit erfolgreich.

Ein kleines Problem habe ich noch: Im obigen NOTIFY gibt es keinen Logeintrag, sprich der "log"-Befehl scheint einfach ignoriert zu werden. Was mache ich denn da falsch?

Ralli

Falsch ist log. Denn es muss Log heißen ;).
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

m0urs

Zitat von: Ralli am 29 Januar 2016, 17:38:03
Falsch ist log. Denn es muss Log heißen ;).

Oops ... Ja, jetzt gehts auch :-) Danke!

Frank S.

Moin.

Vor einiger Zeit hatte ich die Frage schon einmal gestellt. Ich bekomme im Logfile immer wieder Fehlermeldungen wie folgende:

Loading device description failed with error: 500 Can't connect to 10.211.55.13:2869 (timeout) at ./FHEM/00_SONOS.pm line 3721 thread 1

Nun habe ich mit dem Attribut ignoreIPs mehrere betroffen IPs ausgefiltert.

attr Sonos ignoredIPs 10.211.55.13,10.211.55.17,192.168.178.24,192.168.178.45

Diese werden auch ignoriert. Aber bei der IP 10.211.55.13 funktioniert es nicht.

Diese taucht im Logfile auf, wenn ich ein Windows 7 HomePremium auf einer Virtuellen Maschine "Parallels Desktop" starte.

Gibt es bei virtuellen Maschinen etwas zu beachten?

Schöne Grüße
Frank S.

dev0

Ich vermute(!), dass irgendein upnp/dlna service in der VM läuft, der das verursacht. Bei mir gibt etwas Ähnliches: sobald ich in einer meiner W7 Enterprise TestVMs den Windows Explorer starte, dann stopt die Wiedergabe aller Sonosplayer ;-) Das hat aber nicht mit dem Sonos Modul zu tun und ich kann damit leben ;)

Frank S.

Moin.

Danke für die Info. Mich stört es im Prinzip auch nicht. Nur das Logfile wird aber nach einiger Zeit unübersichtlich. Daher ist die Möglichkeit bestimmt IPs zu ignorieren sehr gut. Nur hier scheint es nicht zu funktionieren.

Schöne Grüße
Frank

Benni

Du kannst ja auch anstatt mal das, noch relativ neue Attribut usedonlyIPs verwenden.
Dort kannst du die IPs eintragen die verwendet werden sollen, sprich die deiner Sonos-Geräte.
Ist quasi das Gegenstück zu ignoredIPs. Seither habe ich jedenfalls deutlich weniger Probleme mit meinen Sonos-Playern.  8)

Frank S.

Moin.

Danke für die Idee und den Hinweis. Das war die Lösung. nun kommen auch keine Meldungen mehr, wenn ich die virtuelle Maschine nutze.

Schöne Grüße
Frank