Sonos Widget für smartVISU
Funktionen:
- Volume, mute, play, pause, stop, next title, previous titel, shuffle, repeat, loudness
- Auswahl von Playlisten und Radiostationen
- Popup für Bass, Treble, Balance und Lautstärke der Nachbar-Player
- Anzeige und setzen der Trackposition
- Gruppieren der Player
- Alle Mitglieder einer Gruppe können den Master steuern
Update 0.90
- Playlisten und Radiostationen werden automatisch erkannt (Danke an [user=raman]raman[/user] für seinen Beitrag (https://forum.fhem.de/index.php/topic,54768.0.html))
- Ein Player-Widget für alle Räume (Auswahl des Raums über Selectmenu in der Titelleiste)
- Presence Symbol
Update 0.91
- Selectmenu/Playlists bugfix
Download:
https://github.com/ddtlabs/smartvisu-widgets (https://github.com/ddtlabs/smartvisu-widgets)
Hallo und Vielen Dank für dieses tolle Widget,
ich hab versucht das Sonos-Widget mit Selectmenü in meine Seite einzubauen.
Habe alles nach der Anleitung integriert.Das Selectmenü wird angezeigt aber es kommt kein Player im Block.
auch wenn ich das Beispiel von Github direkt in meine Seite kopiere.
Das Widget allein ohne Selectmenü funktioniert ohne Probleme.
Braucht es noch andere Voraussetzungen außer Smartvisu 2.8 ???
Zitat von: Keule_09 am 24 September 2016, 23:15:33
Braucht es noch andere Voraussetzungen außer Smartvisu 2.8 ???
Nein, das damalige sv 2.8 reicht aus.
Spontan fallen mir 3 mögliche Ursachen ein:
- Du hast irgendetwas nicht korrekt umgesetzt/konfiguriert. Beispielsweise das GAD/Item "mm_Sonos_XYZ.svIsVisible".
- Das Beispiel auf Github ist unvollständig/fehlerhaft. Unwahrscheinlich, sonst hätte sich schon früher jemand gemeldet.
- Du benutzt die aktuellste smartVISU 2.8 Version und dort hat sich das Verhalten des Widgets "status.collapse" geändert. Die aktuelle sv 2.8 Version ist z.Z. 116 Commits weiter als die getestete sv 2.8 Version. Um das auszuschießen könntest Du den SV 2.8 Fork aus meinem Repository (https://github.com/ddtlabs/smartvisu) testen.
Hallo dev0,
ich habe im Repository von MartinGleiss für den Treiber io_fhem.js ein paar kleine Änderungen
als Pull Request eingereicht, die auch übernommen worden sind, da bei mir der Treiber so nicht
funktioniert hat.
Ich habe dein sonos-widget mal getestet. Bei mir funktioniert es mit den Änderungen im Treiber,
auch "status.collapse".
Nur im ddtlabs_sonos.selectmenu muss folgende Zeile geändert werden:
var playlists = response[0].split(';;');
in
var playlists = response[0].toString().explode(';;');
Die Änderung sollte sich auch nicht auf die Nutzung mit einer älteren SV-Version auswirken.
Gruß
raman
@raman: Danke fürs Testen mit der aktuellen 2.8er smartVISU Version und den Fix. Ältere 2.8 smartVISU Versionen funktionieren mit dem Fix weiterhin, wie Du schon geschrieben hattest. Die Änderungen habe ich eingecheckt.
Bitte. Bin eh gerade dabei alle widgets zu testen, die ich verwende, bevor ich entgültig auf die
neuste SV-Version umsteige.
Ist jetzt nicht die eleganteste und wahrscheinlich auch nicht die performanteste Lösung,
da der String mit den Sendern oder der Playlist mehrfach verarbeitet werden muss.
Weißt du, ob es möglich ist, das ganze aus fhem über fronthem an SV gleich als
Array zu übergeben? Das wäre wahrscheinlich schneller.
Auf Javascript-Seite werde ich keine große Hilfe sein, aber vielleicht können wir das zusammen optimieren.
z.Z. schicken wir eine Liste mit ";;" als Trenner an sv. Wie sollte deiner Ansicht nach der String bzw. das Array formatiert sein, damit es in js effektiver zu verarbeiten wäre?
Ich dachte, wenn man eine Liste, die in eckige Klammern gesetzt wird, an SV übergibt als Array interpretiert wird.
Ist leider nicht so!
Dafür müsste man wahrscheinlich den Treiber io_fhem.js anpassen (oder ich übersehe einfach die passende Funktion).
Also ist die jetzige Lösung den ich momentan am besten, sie funktioniert und ist mit allen SV-Versionen kompatibel.
Zitat von: dev0 am 25 September 2016, 07:24:48
- Du benutzt die aktuellste smartVISU 2.8 Version und dort hat sich das Verhalten des Widgets "status.collapse" geändert. Die aktuelle sv 2.8 Version ist z.Z. 116 Commits weiter als die getestete sv 2.8 Version. Um das auszuschießen könntest Du den SV 2.8 Fork aus meinem Repository (https://github.com/ddtlabs/smartvisu) testen.
Danke für deine Hilfe es lag an der Smartvisuversion.
Hab jetzt alles auf den aktuellsten Stand gebracht und es funktioniert :) :) :)
Hallo dev0,
Um das Thema nochmal aufzugreifen:
Nachdem ich mich mal mit UZSU näher beschäftigt habe, ist mir die Idee kekommen,
dass man die Daten für die Listen der Titel und Radiosender ja auch als json schicken
könnte. Hätte den Vorteil, dass sich das auf Javascript-Seite relativ einfach ohne
Umwandlung verarbeiten lässt.
Gruß
raman
Können wir machen. Im Konverter ist das schnell erledigt. (Vielleicht müssen wir das ganze json_encode noch in ein eval packen, damit FHEM nicht stirbt, wenn etwas schief läuft, das habe ich auf die Schnelle jetzt nicht getestet.)
if ($param->{cmd} eq 'send')
{
use JSON;
$param->{gadval} = encode_json \%{eval( $event )};
$param->{gad} = $gad;
$param->{gads} = [];
main::Log 5, $cName . "device: $device, reading: $reading, gadval: $param->{gadval}";
return undef;
}
Dann haben wir einen JSON String, der so aufgebaut ist:
{
"SQ:14": {
"Title":"Mixed",
"Cover":"http://10.68.30.70:1400/getaa?u=x-file-cifs%3a%2f%2fds01%2fSonos%2fAlbums%2fA%2fACDC%2fHighway%20To%20Hell%2f04-Touch%20Too%20Much.mp3&v=142"
},
"SQ:7": {
"Title":"New-Soul",
"Cover":"http://10.68.30.70:1400/getaa?u=x-file-cifs%3a%2f%2fds01%2fSonos%2fSingles%2fN%2fNatasha%20Bedingfield%20-%20Soulmate.mp3&v=142"
}
}
Jetzt könnte man zusätzlich noch die Cover vor den Listeneinträgen anzeigen, siehe hier (http://jqueryui.com/selectmenu/#custom_render). Haste Lust das mal auszuprobieren?
Ich habs mal kurz getestet und geschaut was in SV ankommt.
Wenn ich den JSON String in der Form, wie du ihn angegeben hast, schicke,
dann wir er nicht als Objekt, sondern als String "durchgereicht".
Wenn man was in der Form sendet,
{"list":[{"title":"Title1","cover":"http://....."},{"title":"Title2","cover":"http://...."}]}
dann kommt im Sonos-Widget ein Objekt an, das man in einer for-Schleife leicht auswerten kann.
Erwartet der FHEM-Treiber in SV ein bestimmtes Format?
Das mit den Covern ist eine gute Idee, aber bei mir werden die auf der Beispielseite in Firefox nicht angezeigt, in Chrome
aber schon. Mal sehen, ob es eine Möglichkeit gibt, die alle Browser abdeckt.
Evtl. lässt sich für die Zukunft sowas wie ein Coverflow realisieren.
Ich habe den JSON Output entsprechend angepasst und auf Github in den neuen developer branch (https://github.com/ddtlabs/smartvisu-widgets/tree/developer/sonos) gelegt. Mit dem Treiber hat das mMn nichts zu tun, ich vermute, dass deine for Schleife einfach nur ein Array statt mehrerer Objekte erwartet.
Die UI Demo Seite wird bei mir auch mit FF (Mac,Linux,Win) korrekt angezeigt. Hast Du eventuell das Ausführen von JavaScript von den Domänen jqueryui.com oder code.jquery.com nicht zugelassen?
Das mit Firefox lag nicht an den Einstellungen. Nachdem ich den Cache geleert habe,
wird die Seite richtig dargestellt.
Ich hab jetzt noch Probleme mit den Umlauten bzw. allgemein mit den Sonderzeichen.
Die werden in SV nicht richtig dargestellt
Kann es sein, dass encode_json ein UTF8-Format erwartet und das ausgelesene
Sonos-Reading ein anderes Format besitzt?
Mit dem selectmenu und den Covers muss ich bei Zeiten mal näher auseinandersetzen,
um vlt. eine Lösung ohne Nutzung von jqUI zu finden.
Zitat von: raman am 15 Oktober 2016, 17:34:32
Ich hab jetzt noch Probleme mit den Umlauten bzw. allgemein mit den Sonderzeichen.
Die werden in SV nicht richtig dargestellt
Kann es sein, dass encode_json ein UTF8-Format erwartet und das ausgelesene
Sonos-Reading ein anderes Format besitzt?
Vorab gesagt: mit der Thematik kenne ich mich auch nicht aus. Es gab aber schon Threads zu diesem Thema:
- https://forum.fhem.de/index.php/topic,54196.0.html
- https://forum.fhem.de/index.php/topic,55421.msg470680.html#msg470680
Ich
glaube, dass die Kodierung vom Sonos Modul schon i.o. ist, es funktioniert ja auch, wenn der String nicht in json gewandelt wird.
Man könnte versuchen den string $event zu kodieren bevor er in den hash %h geschrieben wird.
utf8::encode($event) if(utf8::is_utf8($event));
oder
utf8::downgrade($event) if(utf8::is_utf8($event));
Ist aber eher geraten, habe im Moment auch keine Möglichkeit das zu testen.
Sonst jemand eine Idee dazu?
ist eine Welt für sich ...
werden die Zeichen als *ein* falsches zeicher oder als *zwei* falsche dargestellt ?
vg
joerg
Wenn man das ganze als String an SV schickt, dann geht es.
Wenn ich aber die Einträge aus dem Sonos-Reading in json encodieren will, dann bekomme ich in FHEM z.B. folgende Meldung:
ipc fronthem:127.0.0.1:48533 (ws): ws ipc decoding error malformed UTF-8 character in JSON string, at character offset 810 (before "\x{fffd}fentliches R...")
Mit einer Encodierung in UTF8 von $event funktioniert das Encodieren in json jetzt.
wenns läuft - nicht mehr anfassen.
Hab in dieser Ecke (UTF8) Nächte verbracht ... . :)
Aktueller Stand ist folgender:
Der geänderte Code für "send" im Converter mit Sortierung:
if ($param->{cmd} eq 'send')
{
use Encode qw(encode);
use JSON;
$event = encode("utf8", $event);
my %evt = %{eval( $event )};
my $msg = "";
my $i = 1;
foreach my $key ( sort {lc $evt{$a}{"Title"} cmp lc $evt{$b}{"Title"}} keys %evt )
{
$msg .= '{"title":"' . $evt{$key}{"Title"} . '","cover":"' . $evt{$key}{"Cover"} . '"}' . ($i == keys(%evt) ? "" : ",");
$i++;
}
$param->{gadval} = decode_json('[' . $msg . ']');
main::Log3 undef, 4, $cName . "device: $device, reading: $reading, gadval: $param->{gadval}";
$param->{gad} = $gad;
$param->{gads} = [];
return undef;
}
Und die Änderungen auf der SV-Seite in "update":
'update': function (event, response) {
if ($(this).val() == undefined) {
$(this).find('option').remove().end();
var newOption = "<option value='" + $(this).attr('data-label') + "'>" + $(this).attr('data-label') + "</option>";
$(this).append(newOption).selectmenu('refresh');
if (response[0] instanceof Array) {
for (var i = 0; i < response[0].length; i++) {
var newOption = "<option value='" + response[0][i].title + "'>" + response[0][i].title + "</option>";
$(this).append(newOption).selectmenu('refresh');
}
}
}
},
Die Cover-Infos werden mitgeschickt, aber noch nicht genutzt. Da bin ich noch auf der Suche nach einer geeigneten Lösung!
Das Laden der Listen in SV scheint so etwas schneller zu gehen. Kann mich aber auch täuschen.
Damit das alles funktioniert, braucht es eine kleine Änderung im aktuellen io_fhem Treiber (Version 1.12) aus dem
Martin-Gleiss Repository in Zeile 261:
- 261: io.callUpdateHandler(this, value.list instanceof Array ? values : [values]);
+ 261: io.callUpdateHandler(this, typeof value === "string" ? [values] : values);
Die Änderung hat keine Auswirkung auf das UZSU-Widget. Da SV für die an dieser Stelle gesendeten Daten ein Array
bzw. Json-Objekt erwartet und keinen String, kann das so nicht nur für "value.list" (UZSU-Daten) geprüft werden.
Zwei Sachen gefallen mir daran nicht:
1. Die $event Konvertierung:
Du baust manuell einen flachen JSON String zusammen, den Du dann wieder dekodierst um letztendlich dieses Format zu bekommen:
[
{
'cover' => 'http://192.168.30.94:1400/getaa....',
'title' => 'The School of Rock'
},
{
'cover' => 'http://192.168.30.94:1400/getaa....',
'title' => 'WDR2 Rheinland 88.4 (Pop)'
}
]
Verstehe ich nicht. Was soll dieses Format widerspiegeln?
Hashes in einem Array? Dazu müßten die eckigen Klammern rund sein ;)
Kann man das nicht mit einem Standardformat (JSON, hash, ...) lösen ohne den io_fhem.js Treiber anpassen zu müssen? Das angesprochene UZSU Widget übergibt z.B. JSON, wenn ich das richtig in Erinnerung habe.
Da sind wir auch schon beim 2. Thema, dass ich ansprechen möchte: der io_fhem.js Treiber. Dazu erstelle ich gleich einen neuen Thread... Link (https://forum.fhem.de/index.php/topic,59363.0.html)
Ich habe mich am Widget "status.log" orientiert und das Format, wie es
dort erwartet wird "nachgebaut". Um leichter Änderungen machen zu können,
um verschiedene Formate zu testen, hab ich das ganze als String zusammengebaut
Das ganze ist ja nur ein Teil der gesamten Nachricht wie sie an SV geschickt wird.
Ein anderes Format ist sicher auch möglich, dann muss halt javascript angepasst werden.
Das sollte so mit dem "ürsrünglichen" Treiber aus dem clean Install kompatibel sein.
Ich habe gerade den anderen Thread gelesen. Nur um Verwechslungen vorzubeugen.
Ich habe außer Ähnlichkeiten im Nickname nix mit dem besagten User zu tun.
Die Änderung war nur ein Vorschlag von mir, um das ganze trotz der Patches
in der neuen Version "lauffähig" zu machen.
Mit dem Original-Treiber funktioniert das Senden von json-Objekten ja.
Zitat von: raman am 21 Oktober 2016, 19:07:29
Ich habe außer Ähnlichkeiten im Nickname nix mit dem besagten User zu tun.
OK
Zitat von: raman am 21 Oktober 2016, 19:07:29
Die Änderung war nur ein Vorschlag von mir, um das ganze trotz der Patches
in der neuen Version "lauffähig" zu machen.
Mit dem Original-Treiber funktioniert das Senden von json-Objekten ja.
Ich schaue mir das die Tage mal genauer an. Würde aber vorher gerne auf sv 2.8 final umstellen.
Hallo.
Habe nun endlich mal Zeit gehabt um das Widget auf die aktuelle version zu aktualisieren.
Leider klappt bei mir das Laden der Play- und Radiolisten nicht.
Der Log meldet mir:
error doing $result = fronthem::SonosLists($param); Can't use an undefined value as a HASH reference at /opt/fhem/FHEM/99_fronthemSonosUtils.pm line 946.
Wie kann ich den Fehler beheben?
Habe die aktuelle SV 2.8.
Gruß und Danke,
Oli
In der Zeile wird das Playlist Reading per eval in einen Hash geschrieben. Vermutung: Das Reading gibt es nicht, vertippt beim Readingnamen, ...
Danke für die schnelle Rückmeldung. Nachdem ich die passenden Readings gefüllt hatte, lief das Widget wie erwartet.
Gruß Oli
ich habe das Widget mal mit der aktuellen Develop-Version von Smartvisu und dem darin enthaltenen neuen jQuery Mobile 1.4.5 getestet. Hier stimmt dann das Layout nicht mehr. D.h. die verschiedenen Buttons und Elemente sind verschoben bzw. in der Zeile verrutscht.
Kannst du das Widget an jQuery Mobile 1.4.5 anpassen oder ist das viel Arbeit?
Gruß, Sascha