Sonos2mqtt - vielleicht hat jemand Lust mitzumachen

[TomLee]

Wenn ich nun statt dem Reading currentTrack_Title das Reading currentTitle füllen wollen würde, wie müsste man das umbauen?

Nix umbauen, umbenennen, mit dem Attribut jsonMap

Code Auswählen Erweitern

attr <devicename> jsonMap currentTrack_Title:currentTitle

[Beta-User]

Nix umbauen, umbenennen, mit dem Attribut jsonMap

Code Auswählen Erweitern

attr <devicename> jsonMap currentTrack_Title:currentTitle

Genau...

Aus gegebenem Anlass an anderer Stelle: Machen hier ggf. auch filter-Elemente Sinn? (Notfalls könnte man die zum Testen über ein userattr "dazumischen")

[kjmEjfu]

Ich habe nochmal an dem Userreading für die Quelle gebastelt.

Code Auswählen Erweitern

currentMediaSource:currentTrack_TrackUri.* { my $val = ReadingsVal($name,"currentTrack_TrackUri","none"); $val =~ /:([^:][a-zA-Z]*)/; my %rets = ("none" => "unknown","spotify" => "Spotify","tunein" => "TuneIn","catalog" => "Amazon"); return $rets{$1}; }

Berücksichtigt wird dabei aktuell:

currentTrack_TrackUri
===
x-sonosapi-stream:tunein:5191?sid=303&flags=8224&sn=11 -> TuneIn
x-sonos-spotify:spotify:track:..... -> Spotify
x-sonosapi-hls-static:catalog/tracks/B01M4FSMCA/?.... -> Amazon

[Beta-User]

  ... geht doch...!

Klasse!

Bin aber nach einem Blick in die https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV#Readings nicht sicher, ob es nicht "currentMedia" oder "channel"heißen sollte...

Tipp noch:Es sollte berücksichtigt werden, dass es evtl. zwar ein $1, aber keinen match gibt. Das vermeidet Log-Einträge wg. "uninitialized value":

Code Auswählen Erweitern

currentMediaSource:currentTrack_TrackUri.* { my $val = ReadingsVal($name,"currentTrack_TrackUri","none"); $val =~ /:([^:][a-zA-Z]*)/; my %rets = ("none" => "unknown","spotify" => "Spotify","tunein" => "TuneIn","catalog" => "Amazon"); return $rets{$1} if $rets{$1}; }

[FunkOdyssey]

Das macht Spaß mit euch.
Ich stelle nur kurz eine Frage und ihr erarbeitet die Lösung. 
Wirklich vielen Dank.

[kjmEjfu]

Bin aber nach einem Blick in die https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV#Readings nicht sicher, ob es nicht "currentMedia" oder "channel"heißen sollte...

currentMedia würde ich ausschließen, da steht als Erklärung "kann alles sein: Datei vom Filesystem, Stream aus dem Internet, m3u-URL oder was auch immer". Würde dort eher reinschreiben, was wir in aktuell in currentTrack_TrackUri haben.
Beim channel steht oben bei den Befehlen zu "Schaltet auf einen absoluten Sender- oder Programmspeicherplatz (Nicht zu verwechseln mit input)". Dort wird eine Zahl von 0 - 9999 erwartet. Von daher würde ich mal vermuten, dass Reading sollte dazu passen.

Tipp noch:Es sollte berücksichtigt werden, dass es evtl. zwar ein $1, aber keinen match gibt. Das vermeidet Log-Einträge wg. "uninitialized value":

danke

[FunkOdyssey]

Ich muss euch noch etwas fragen.
Der aktuelle Stand ist doch, dass man nach dem get sonosbridge Favorites den Code aus dem Wiki zum Verteilen der Favoriten an die Player manuell ausführen muss, oder? Oder müsste ich das in einem notify noch unterbringen?

Darf ich fragen, ob die Wiedergabe (playFav) einer Spotify-Liste aus dem Sonos-Favoriten bei euch funktioniert?
Bei mir startet nur die ursprüngliche Wiedergabeliste.

[Beta-User]

currentMedia würde ich ausschließen, da steht als Erklärung "kann alles sein: Datei vom Filesystem, Stream aus dem Internet, m3u-URL oder was auch immer". Würde dort eher reinschreiben, was wir in aktuell in currentTrack_TrackUri haben.

Schließe mich tendenziell der Meinung an, dass in jsonMap auch "currentTrack_TrackUricurrentMedia" stehen sollte...

Beim channel steht oben bei den Befehlen zu "Schaltet auf einen absoluten Sender- oder Programmspeicherplatz (Nicht zu verwechseln mit input)". Dort wird eine Zahl von 0 - 9999 erwartet. Von daher würde ich mal vermuten, dass Reading sollte dazu passen.

Auch richtig mit dem nummerischen Hinweis...
Vielleicht sollte man (= einer von euch, vielleicht ein "getroffender" ...) das Thema "Erweiterung der Readings in "DevelopmentGuidelinesAV" mal schlicht an anderer Stelle aufgreifen... (bei "Anwendungen/Multimedia"?), denn in der Zwischenzeit gibt es vermutlich eine Reihe weiterer "Spezialfälle", die man ggf. allgemeingültiger Lösen könnte.
Nach kurzem Blick auf meinen Yamaha käme z.B. dann "currentStation" in Frage - aber auch das ist nur ein oberflächlicher Eindruck...

[kjmEjfu]

Ich habe mal angefangen Readings gemäß AV Guideline anzupassen.

Erstmal meine drei Userreadings:

Code Auswählen Erweitern

shuffle:playmode.* { if (ReadingsVal($name,"playmode","NORMAL") =~ m/SHUFFLE/) {return "on"} else {return "off"}; },
repeat:playmode.* { my $val = ReadingsVal($name,"playmode","none"); my %rets = ("none" => "unknown","NORMAL" => "off","SHUFFLE" => "off","REPEAT_ALL" => "all","SHUFFLE_NOREPEAT" => "off","SHUFFLE_REPEAT_ONE" => "off"); return $rets{$val} if $rets{$val}; },
currentMediaSource:currentTrack_TrackUri.* { my $val = ReadingsVal($name,"currentTrack_TrackUri","none"); $val =~ /:([^:][a-zA-Z]*)/; my %rets = ("none" => "unknown","spotify" => "Spotify","tunein" => "TuneIn","catalog" => "Amazon"); return $rets{$1} if $rets{$1}; },

mute -> liefert aktuell false/true -> müsste sein off/on. Ist innerhalb von $DEVICETOPIC im JSON hinterlegt als "mute":{"Master":false,"LF":false,"RF":false} -> wie umschreiben?
Mein Ansatz war im readingList den ersten Eintrag umzuändern zu:

Code Auswählen Erweitern

$DEVICETOPIC:.* { $EVENT =~ s/"mute":\{"Master":true/"mute":\{"Master":on/g; $EVENT =~ s/"mute":\{"Master":false/"mute":\{"Master":off/g; json2nameValue($EVENT,'',$JSONMAP)}
Aber wenig überraschend funktioniert das nicht


Bin dann noch über folgende Punkte gestolpert:

presence -> present|absent -> physischer Status! Wird irgendwo hinterlegt, ob eine Box nicht erreichbar ist? Zu beachten: "Auch das presence reading sollte nur dann aktualisiert werden wenn sich der Status geändert hat um am timestamp sehen zu können wann das war. event-on-change-reading ist hierzu nicht ausreichend weil nur das Event unterdrückt wird der Timestamp sich aber trotzdem ändert."
power -> on/off -> logischer Status, nicht physischer! Frage: da die Boxen logisch immer eingeschaltet sind, auf on lassen und off wenn presence=absent?
input -> soll eigentlich die Inputquelle (z.B. LineIn) darstellen. Derzeit Zahlenwert. Welcher? Wieso?
output -> "HeadphoneConnected" steht in sonos/status/name_or_uuid_of_speaker/renderingcontrol -> wird derzeit nicht in readingList betrachtet.

Dann ist mir noch aufgefallen, dass wir sonos/status/name_or_uuid_of_speaker/avtransport derzeit noch komplett ignorieren. Es bringt aber z.B. so Infos wie Track Duration oder Anzahl der Items in der Playlist (https://svrooij.io/sonos2mqtt/topics.html#avtransport-message).

[Otto123]

Uih jetzt kommt wieder Fahrt auf

playFav: Das war mehr oder weniger ein Experiment um die Favoriten (Radioliste) überhaupt irgendwie zu haben. Ich war eigentlich der Meinung, die sollte bei der Bridge bleiben und nicht verteilt werden. Ist doch ein zentrales Ding?

mute: Ja kann sein, da waren wir auch schon mal bei on/off letztlich liefert das System true / false und man muss true / false setzen. Ich habe dann Kurzerhand die Sache "verkürzt" (und nicht zweimal umgewandelt). Aber ja können wir wieder anders machen. Ich suche mal den Code (der steht hier noch irgendwo im Thread).

presence ist aus meiner Sicht ein unsägliches Thema (Sonos Modul) ich würde da erstmal wenig nachdenken. Die Bridge händelt die Infrastruktur ganz vernünftig. Ich war dafür den Player zu erzeugen und zu löschen wenn er nicht da ist - da ging ein Aufschrei durch die Reihen! Aber genau das funktioniert!
input liefert Zahlen? Wo jetzt? Die Sache mit dem Input ist bei Sonos nicht so einfach. Da habe ich gedacht, wusste des Development Guide nichts davon 
output wurde bisher nicht betrachtet. Aber Achtung, nicht das wir zu viele Baustellen aufreißen. Schnell sind ein paar Seiten Thread gefüllt und keiner hat einen Zwischenboden eingezogen und dokumentiert
avtransport liefert ein Haufen zusätzliche Infos und bläht das Device auf. Wie schon gesagt, eigentlich gibt es die Sonos App zum angucken. Man kann sich endlos in in der letzten Kleinigkeit und "abgerundeten Ecken" beim Albumcover vertrödeln.

Muss man wirklich alles nachbauen?

[kjmEjfu]

Uih jetzt kommt wieder Fahrt auf

ich habe etwas Zeit Deshalb kann ich etwas an euren coolen Ergebnissen basteln.

playFav: Das war mehr oder weniger ein Experiment um die Favoriten (Radioliste) überhaupt irgendwie zu haben. Ich war eigentlich der Meinung, die sollte bei der Bridge bleiben und nicht verteilt werden. Ist doch ein zentrales Ding?

Finde ich persönlich gut.
Funktioniert auch ganz gut bei mir.

mute: Ja kann sein, da waren wir auch schon mal bei on/off letztlich liefert das System true / false und man muss true / false setzen. Ich habe dann Kurzerhand die Sache "verkürzt" (und nicht zweimal umgewandelt). Aber ja können wir wieder anders machen. Ich suche mal den Code (der steht hier noch irgendwo im Thread).

Danke

presence ist aus meiner Sicht ein unsägliches Thema (Sonos Modul) ich würde da erstmal wenig nachdenken. Die Bridge händelt die Infrastruktur ganz vernünftig. Ich war dafür den Player zu erzeugen und zu löschen wenn er nicht da ist - da ging ein Aufschrei durch die Reihen! Aber genau das funktioniert!

Also bei sonos2mqtt habe ich bisher keine Aussetzer, funktioniert gut. Außer das das Reading connected in der Bridge immer mal auf 0 statt 2 steht. Da hilft dann leider nur ein Restart vom Dockercontainer.
Aber hinterlegt sonos2mqtt irgendwo den Status der einzelnen Speaker? Es gibt ja Leute, die ihre Speaker aus diversen Gründen mal stromlos machen. In dem Fall wäre es natürlich gut, wenn dies irgendwo vermerkt ist.

input liefert Zahlen? Wo jetzt? Die Sache mit dem Input ist bei Sonos nicht so einfach. Da habe ich gedacht, wusste des Development Guide nichts davon 

Also ich habe in jedem Player ein Reading "input" und da stehen bei mir aus irgendwelchen Gründen Zahlen drin, z.B. 15.
Wenn ich mir in der Guideline die Beispiele für den Set-Befehle zu Input anschaue "z.B. hdmi[1-n] | av[1-n] | usb | airplay | server [1-n]", dann gibt es bei den normalen Speakern eher wenig Auswahl. Die Frage ist nur, was dann passt

output wurde bisher nicht betrachtet. Aber Achtung, nicht das wir zu viele Baustellen aufreißen. Schnell sind ein paar Seiten Thread gefüllt und keiner hat einen Zwischenboden eingezogen und dokumentiert

Die Erweiterung für HeadphoneConnected dürfte recht einfach sein.
Ich habe allerdings nur Play 1 und 5, keine Playbar. Die dürfte vermutlich nochmal anderen Output haben.

avtransport liefert ein Haufen zusätzliche Infos und bläht das Device auf. Wie schon gesagt, eigentlich gibt es die Sonos App zum angucken. Man kann sich endlos in in der letzten Kleinigkeit und "abgerundeten Ecken" beim Albumcover vertrödeln.

Wir müssen ja nicht alles zur Verfügung stellen. Aber gerade Tracklänge, Länge der Playlist und aktuelle Position in der Playlist könnte schon interessant sein.
Warum? Ich habe z.B. einen Speaker im Gästezimmer stehen. Allerdings möchte ich nicht jeden Gast in meinem WLAN haben (im Gäste-WLAN schon), wodurch die App nicht genutzt werden kann. Allerdings kann ich auf einem Tablet mit dem Gäste das eine und andere fürs Gästezimmer konfigurieren können, eine gewisse Grundfunktionalität zur Verfügung stellen.

Muss man wirklich alles nachbauen?

Nein, ich wollte ja nur fragen

Den Fokus würde ich auch darauf setzen einen guten Stand zu erreichen, der auch zur AV Developer Guideline passt. Was aber schwierig ist, weil der nicht bis ans Ende durchgedacht ist. Deshalb fällt es so schwer einige Readings richtig zu setzen.

msgSchema für Audio per msg fände ich noch sehr wichtig (aber rein aus persönlichem Anlass), nur habe ich da derzeit so gar keine Idee.

[Otto123]

Das mit mute ist eigentlich simpel:

Code Auswählen Erweitern

mute:on,off { my $value = $EVTPART1 eq "on" ? "mute" : "unmute"; qq(BASE_TOPIC/DEV_ID/control { "command": "$value" } ) }\
presence: sonso2mtt hat den Befehl checkSubscription, der kümmert sich um die Erkennung der Infrastruktur ohne Neustart

Code Auswählen Erweitern

CheckSubscription:noArg sonos/cmd/check-subscriptionsder muss noch ins Template.
Wenn jemand seine Player ausschaltet, dann macht er das mit FHEM, dann weiß er doch das sie aus sind
Die App löscht den Player wenn er nicht da ist. Wäre auch konsequent in FHEM machbar. Der Player wird ja automatisch wieder erzeugt. Also wenn man das konsequent "nachbauen" will.

Das Reading Input habe ich nicht, Da muss ich nochmal schauen.

[kjmEjfu]

Das mit mute ist eigentlich simpel:

Code Auswählen Erweitern

mute:on,off { my $value = $EVTPART1 eq "on" ? "mute" : "unmute"; qq(BASE_TOPIC/DEV_ID/control { "command": "$value" } ) }\

das ist aber set, ich bin noch beim Reading schreiben

[Otto123]

Moin,
Missverständnis
genau, das war ja auch der Grund es einfach so zu lassen. Im übrigen würde ich mute_LF usw. einfach weglassen und nur mute betrachten.

kann man das im jsonMap mit behandeln?

Gruß Otto

[TomLee]

kann man das im jsonMap mit behandeln?

Ja, mit der Angabe 0.

https://forum.fhem.de/index.php/topic,111711.msg1066412/topicseen.html#msg1066412