Sonos steuern

Reinerlein · 09 Juli 2013, 18:48:10

Hi Peter,

ich habe mir die Zeilen mal angesehen. Das sieht eher unspezifisch aus. Bist du sicher, dass es nur zusammen mit dem Sonos-Modul zu dem Fehler kommt?

Sonst als allgemeine Vorgehensweise, erstmal mit 0 Modulen anfangen, und dann langsam steigern, bis der Fehler wieder auftritt :-)

Grüße Reiner

PumpkinEater · 09 Juli 2013, 19:37:22

Hallo Reiner,
die Meldungen tauchen nur auf, wenn ich die Sonos-Konfiguration in der fhem.cfg aktiviert habe. Ich werde alternativ noch mal eine Mini-fhem.cfg erstellen, in der nur die Sonos-Anteile enthalten sind.

Ansonsten funktionieren die Sonos-Module schon ganz gut, ich werde sie hauptsächlich für Sprachmeldungen nutzen. Ich hatte schon viel Spaß, als mir die Google-Tante so allerlei Blödsinn vorlesen musste ;-). Aufgefallen ist mir, dass nach etlichen Sprachansagen plötzlich Schluss war. Fhem meldete zwar weiterhin "Success", es gab aber keine Sprachausgabe mehr. Hat Google neben der Begrenzung auf 100 Zeichen auch eine obere Grenze bzgl. der Requests pro Zeit?

Auf jeden Fall schon mal vielen Dank für Deine Arbeit - Hut ab :-)

Gruß
Peter

PumpkinEater · 09 Juli 2013, 20:32:04

ich noch mal ...

Eine Mini-fhem.cfg nur mit dem SONOS-Dingen produziert auch die Fehlermeldung. Es reicht sogar nur die Zeile "define Sonos SONOS".

Ich habe mal versucht, die Meldung betreffend Zeile 2142 in fhem.pl zu debuggen:

In fhem.pl (Zeile 2142) habe ich ein "Log 1, .." eingefügt:

Code Auswählen


sub
RemoveInternalTimer($)
{
  my ($arg) = @_;
  foreach my $a (keys %intAt) {
Log 1, ">>>>".$a."<<<<   >>>>".$arg."<<<< >>>>>".$intAt{$a}{ARG}."<<<<<";
    delete($intAt{$a}) if($intAt{$a}{ARG} eq $arg);
  }
}

Dies liefert dann:

Code Auswählen


>>>>2<<<<   >>>>RINCON_000E5********1400_MR<<<< >>>>>RINCON_000E5********1400_MR<<<<<
>>>>4<<<<   >>>>RINCON_000E5********1400_MR<<<< >>>>>RINCON_000E5********1400_MR<<<<<
>>>>3<<<<   >>>>RINCON_000E5********1400_MR<<<< >>>>><<<<<
>>>>0<<<<   >>>>RINCON_000E5********1400_MR<<<< >>>>>0<<<<<
>>>>2<<<<   >>>>RINCON_000E5********1400_MR<<<< >>>>>RINCON_000E5********1400_MR<<<<<
>>>>5<<<<   >>>>RINCON_000E5********1400_MR<<<< >>>>>HASH(0x3c6**e0)<<<<<
>>>>6<<<<   >>>>RINCON_000E5********1400_MR<<<< >>>>>RINCON_000E5********1400_MR<<<<<

Der Ausdruck "$intAt{$a}{ARG}" ist also mnachmal leer, dann kommt die Fehlermeldung. Was beuetet das "{ARG}"?

Gruß
Peter

Reinerlein · 10 Juli 2013, 00:03:21

Hi Peter,

bzgl. der Fehlermeldung muss ich schauen, wenn ich wieder an einem Rechner sitze. Momentan kann ich das von hier aus nicht untersuchen...
Das scheint aber eine Anpassung im Konzept der internen Timer zu sein, die ich in meinem Modul entsprechend nachziehen muss. Kann ich aber noch nicht genau sagen...

Zu den Durchsagen:
Wenn Google nichts mehr liefert, dann sollte von dort eigentlich ein Fehlercode zurückkommen (sowas wie bei einer zulangen Nachricht, dort kommt dann ein 404er Fehler oder so). Du könntest mal checken, ob die Dateien immer noch sauber abgelegt werden..
Außerdem könnte ich mir wieder mal ein Problem bei den Threads vorstellen. Für jede dieser Durchsagen starte ich einen davon, der dann die Überwachung übernimmt, ob die Durchsage fertig ist, und den Ur-Zustand anschließend wiederherstellt. Das müsste man per Top beobachten können...

Ich denke da kommt erst Abhilfe mit meiner kompletten Umstrukturierung. Da versuche ich das anders zu trennen... mal schauen, ob das so klappt...

Grüße Reiner

PumpkinEater · 10 Juli 2013, 06:40:30

Hallo Reiner,
die Soundfiles werden immer erzeugt - also keine Google-Begrenzung, sondern wie Du schon erwähnt hast, vermutlich ein Problem mit den Threads. Wenn keine Sprachausgaben mehr kommen, hilft meistens ein Restart von fhem. Ich werde mal auf Deine Umstrukturierung warten.

Gruß
Peter

FHEM-Freak · 13 August 2013, 10:00:05

Zitat von: FHEM-Freak schrieb am Sa, 01 Juni 2013 19:24Hallo,

Bin gerade dabei den Sonos Play3 in mein FHEM einzubinden.
Mein Problem ist der Qnap, da Perl am Qnap keine Threads unterstützt.
Fehler "This Perl not built to support threads"
Mal schauen ob ich mir ein Perl am Qnap selbst kompilieren kann.
Werde mich melden falls ich weiterkomme.

Zitat von: det. schrieb am Sa, 01 Juni 2013 23:03hallo,
kauf Dir einen RPI, nimm den nur für SONOS und häng den über FHEM2FHEM an das FHEM auf dem Qnap. Hast Du weniger Probleme und schnelleren Erfolg.

Habe die Sache mit dem Qnap aufgegeben.
Bin komplett mit Fhem auf einen RPI umgezogen.

Sonos Play 3 läuft perfekt.
Tolle Arbeit des Entwicklers.
Danke dafür.

Einzige Problem ist das editieren der fhem.cfg wie hier beschrieben.
Link

Gibt es dafür schon eine Lösung ?

m.zielinski · 13 August 2013, 10:41:07

Zitat von: Reinerlein schrieb am So, 23 Juni 2013 22:34Also, ich habe nun meine Sonos Landschaft um 2 Player erweitert, und kann die Stillstände bei dem Sonos-Modul leider auch bestätigen. Leider habe ich aber noch keine Lösung, vermute aber ein Problem bei der massenhaften Verarbeitung der Titel und sonstiger Aktualisierungsinformationen. Das muss ja alles über die Telnet-Schnittstelle verarbeitet werden...
Ich werde da also in nächster Zeit (nach meinem Urlaub) tiefer in die Analyse einsteigen, und hoffentlich das Problem eingrenzen können.

Hallo Reiner,

Gibt es schon ein Update zu dem Thema?

Ich habe deswegen erstmal die Sonos unterstützung bei mir wieder ganz raus genommen, da mir mehrmals das ganze fhem eingefroren war.
Aber mir wäre es sehr wichtig zumindest eines der Sonos Geräte zu steuern (play, pause, Lautstärke und Song/Playlistauswahl) - die Benachrichtigungs-Funktionen sind mir erst mal zweitrangig dabei.

Ich möchte einen FHem-6fach Schalter als Steuerung für ein Sonos im Kinderzimmer nutzen - meine Tochter soll dafür aber kein Handy/Tablet o.ä. bekommen.. Und da baue ich auf dein Modul...

Gruß,
Michael

Reinerlein · 13 August 2013, 18:07:38

Hi Michael,

ich bin dabei, da das ganze aber eine doch erhebliche Konzept-Anpassung ist, bin ich da noch etwas beschäftigt.

Ich muss dich (und natürlich auch die anderen hier) also leider noch etwas vertrösten, aber immerhin ist der Sommer bald vorbei, sodass ich allg. mehr Zeit haben werde, an diesem Modul weiterzustricken :-)

Grüße Reiner

Elektrolurch · 16 August 2013, 15:48:24

Hallo Rainer,

erst einmal: tolles Projekt.
Leider fahre ich seit ca. zwei Monaten fhem auf meiner FB7390 und bin kräftig beim entwickeln.
Leider scheint ja das sonos-Modul dort nicht zu laufen.
Ich hätte gerne etwas ganz einfaches: Ich möchte einen Sound auf einem der Sonos-Player im Haus abspielen, z.B. Sirene oder Hundegebell.
So etwas müsste doch auch ohne das Multithreading gehen?
Ich bin mit dem UPNP Thema nicht so bewandert, dass ich das programmieren könnte. Die Sonos-Player haben bei mir im Netzwerk feste Adressen.
Kannst Du mir da ev. Mit einigen Tipps weiterhelfen?
Das wäre super. Leider habe ich dazu im Forum nichts gefunden. Das Thema UPNP wurde erst vor einigen Tagen hier im Forum wieder aufgenommen, da erschien es mir allerdings so, dass Dein Super-Sonos Projekt nicht bekannt war....
Also, schon mal Danke.

Elektrolurch

Reinerlein · 16 August 2013, 17:23:24

Hallo Elektrolurch,

bevor ich das FHEM-Modul begonnen hatte, hatte ich ein bestehendes PHP-Modul etwas erweitert.

Finden kannst du das ganze unter http://www.ip-symcon.de/forum/threads/7676-PHP-Sonos-%28Klasse-zum-Ansteuern-einzelner-Player%29/page23 Artikel 221 und 222.
Das ist dann eine vereinfachte Nutzungsmöglichkeit für die dort sowieso veröffentlichte PHPSonos-Klasse. Dort kann man auch Titeländerungen mitbekommen (exemplarisch implementiert). Das hat mir damals mein FHEM getriggert, damit dieses meinen Verstärker zu dem Sonos-Player anschaltet.

Vielleicht reicht dir das ja erstmal.

Ansonsten kann ich dir nur zum Thema UPnP sagen, dass die Sonos Geräte sehr speziell in Bezug auf UPnP programmiert wurden. Mit einem normalen UPnP-Steuerprogramm wirst du die nicht vernünftig/einfach beeinflußen können, genauso wie andersherum mein Modul für andere, per UPnP steuerbare Geräte, nicht sinnvoll einsetzbar sein dürfte.

Desweiteren hat man bei UPnP immer das Thread-Problem. Nur kurz im Groben das Konzept dazu:
- Man registriert einen UPnP-Listener und fordert das Computer-Netz im Allgemeinen per Broadcast auf sich zu melden.
- Es melden sich die einzelnen Player, zu denen man dann jeweils eine Referenz erhält (und sich merkt).
- Mithilfe dieser Referenzen kann man die Player steuern, oder sich für weitere Events registrieren.
- Wenn man jetzt auf die Idee kommt, den Start-Listener zu beenden, hat man das Problem, dass die einzelnen Player-Referenz-Platzhalter nicht mehr funktionieren (bzw. ungültig werden).
- Wenn man jetzt also noch mit einer anderen Stelle der Software (z.B. FHEM o.ä.) was steuern möchte, bzw. die Ergebnisse auswerten möchte, dann kommt man um eben mind. einen weiteren Thread nicht drumherum.

Ich bin aber auf einem guten Wege, das Konzept jetzt sauber zu bekommen. Nur bin ich halt noch auf dem Weg :-)

Grüße Reiner

crazystone · 19 August 2013, 20:58:03

Hallo Reinerlein,

ich hatte, wie von Elektrolurch erwähnt, kürzlich in der Wunschliste das Thema UPnP angesprochen, siehe

Link

da sich niemand erinnern konnte, dass schon mal jemand eine UPnP Steuerung angefangen hat. Jetzt lese ich hier hochgespannt, dass Du diese schon für einen SONOS umgesetzt hast? Oder habe ich da etwas falsch verstanden?

betateilchen hat sich der Sache angenommen und ich bin sicher, er kann einiges von Deinen Erfahrungen profitieren. Könntest Du Dich mit ihm in Verbindung setzen oder auch zu dem anderen Thread beitragen?

Vielen Dank!
Thorsten

Reinerlein · 19 August 2013, 23:14:49

Hallo Thorsten,

ich kann gerne bei Problemen hilfreich zur Seite stehen. Ich habe den von dir genannten Thread mal kurz durchflogen (ist ja zum Glück noch nicht soo lang :-).
Ich verwende die Perl-UPnP-Library http://perlupnp.sourceforge.net/. Die Entscheidung war gefallen, da die andere Library (http://search.cpan.org/~skonno/Net-UPnP-1.4.2/) in meinen Tests nicht so erfolgreich war.
Ich möchte hier aber bitte betonen, dass ich sehr speziell auf Sonos hin getestet und entwickelt habe, und es sicherlich andere gibt, die das auch anders hinbekommen können (wie immer, man kann einfach nicht alles, und hat bestimmte Vorlieben und Arbeitsverfahren :-). Besonders die Thematik Threads Ja oder Nein kann sehr kontrovers diskutiert werden. Ich finde sie gut, da sie das Leben im Normalfall einfacher machen :-)

Meine Erfahrung mit dem Sonos bestätigen die Aussagen, die allg. bzgl. UPnP gemacht wurden:
Es gibt einen Grundschatz an Fähigkeiten, und UPnP hilft da auch eine ganze Menge, da sich das System mittels dieses Standards selbst beschreiben kann, und somit keine weitere Schnittstellendokumentation notwendig wäre.
Das gilt aber nur für die Zugriffswege und Prozeduren (inkl. Parametern u.ä.); Allerdings nicht für die Inhalte der Parameter, die man den Aufrufen mitgeben muss (Die Prozedurnamen sind dagegen meist noch sehr sprechend). Dort wird es meiner Erfahrung nach bei den meisten Herstellern sehr speziell.

Ich bin mit meinem Sonos-Modul sehr weit fortgeschritten. Auch wenn ich gerade einen Konzeptwechsel durchführe, so gilt das eher der Thread-Problematik. Ich bekomme es einfach nicht sauber hin, Threads direkt aus FHEM heraus zu starten und auch wieder sauber einzufangen. Da scheint der große FHEM-Overhead, der beim Thread-Erzeugen ja immer mit kopiert wird, für Probleme zu sorgen.
Mein jetziges Konzept sieht eine Abkapselung der UPnP-Funktionalität in einen eigenen Prozess vor, wo dann auch wieder sauber mit Threads hantiert werden kann.
Das sieht schon ganz gut aus, ich muss aber noch einige Zeit investieren.
Mein Modul hat mittlerweile ca. 215kB Größe erreicht (ohne die notwendigen Zusatzmodule), und kann wirklich nicht mehr klein und harmlos genannt werden.

Aber zum Thema selbst nochmal:
Ich glaube, dass es schwierig werden wird, ein wirklich allgemeines Modul für "alle" UPnP-Clients/Server zu enwickeln. Es gibt für jedes Gerät einfach zu viele Besonderheiten, die extra berücksichtigt werden müssen.
Ich persönlich habe viele Stunden mit dem Intel Device Spy verbracht, und habe unzählige Aufrufe der Sonos-Prozeduren durchgeführt, bis ich endlich die korrekten Parameter in der korrekten Kodierung und der korrekten Reihenfolge raushatte. So manches habe ich mittels Wireshark in meinem Netz mitgeschnitten, wenn ich mit dem Original-Controller einen Aufruf durchgeführt habe.

Sicherlich, wenn man sich auf Play/Pause/Vorwärts/Rückwärts beschränkt, geht es meist. Aber schon bei der Lautstärke z.B. fährt Sonos seine eigene Locke; die per UPnP-AV vorgegebenen Prozeduren sind zwar da (müssen sie ja auch, um dem Standard zu entsprechen), haben aber keine Funktion. Das wird über andere Prozeduren durchgeführt, die eben nicht Bestandteil des -AV-Standards sind, sondern einfach zusätzlich definiert wurden.

Soweit erstmal. Bei Fragen einfach an mich :-)

Grüße Reiner

crazystone · 20 August 2013, 07:04:28

Hallo Reiner,

Vielen Dank für Deine Bereitschaft zu helfen. Ich denke du bist schon genau auf dem Weg, den ich versucht habe anzuregen und ich fände es super, wenn du mit betateilchen in Kontakt treten würdest zu dem Stand den du schon hast. Leider kann man hier im Forum ja niemanden auf cc setzen :-)

Mir ging es genau darum, ein Modul zu haben, dass den UPnP Standard sauber implementiert und nur genau das abdeckt. Von der Erkennung der Geräte und Auflistung der Contents bis hin zu einfachen Control Point Funktionen ("spiele A auf B ab", Play, Pause, Stop). Wenn dann einige Geräte das nicht sauber implementieren, muss man schauen, ob man ggf. mit Zusatzmodulen speziell für diese Geräte diesem Zustand Rechnung tragen kann. Dafür wären dann sicher zusätzliche Customizing Funktionen hilfreich, mit denen Parameter oder Command Strings an das UPnP device gesendet werden können, eine Art Test und Entwicklungsumgebung für UPnP Integration.

Ich wäre dir schon sehr dankbar, wenn ich (und andere) die reine UPnP Standard Implementierung mal testen könnte, nicht mit der Erwartung, dass dann sofort alles funktioniert.

Kannst du mit deinem Modul schon sagen, welche Perl-Module erforderlich waren? Ich muss nämlich schauen, ob die auf der FB7390 alle drauf sind bzw. ggf. dann den Kampf mit dem AVM Support anfangen, dass die mal nachinstalliert werden, zumindest in einer Laborversion.

Viele Grüße
Thorsten

betateilchen · 20 August 2013, 16:24:28

Zitat von: crazystone schrieb am Di, 20 August 2013 07:04Kannst du mit deinem Modul schon sagen, welche Perl-Module erforderlich waren?

Das steht doch klipp und klar im Beitrag VOR Deinem. Ich verwende übrigens genau die andere Library, weil die SF-Lösung bei mir nicht funktioniert hat.

Und hör bitte auf, die Leute hier kreuzweise durch die Threads zu verkuppeln, das bringt nix.

crazystone · 20 August 2013, 22:32:09

Hallo Reiner,

ich habe mir den Intel-Device Spy mal angeschaut bzw. die ganze Tool-Suite. Das ist ja schon ziemlich umfänglich, was es da alles an Test-Tools gibt. Das sollte genügen, um diverse Device Simulationen zu testen bzw. auch den einzelnen Geräten auf die Spur zu kommen. Danke für den Link. Ich werde also schon mal einen meiner UPnP Player (Philips NP2900) damit testen, ob die Grundfunktionen da UPnP Standard konform funktionieren. Mit dem mitglieferten Sniffer sollte man dann ja die Sequenzen sehen und nachimplentieren können, wenn das UPnP Modul in FHEM mal läuft, richtig?

Viele Grüße
Thorsten