Sonos2mqtt - vielleicht hat jemand Lust mitzumachen

[Otto123]

Hi 87insane,

ich habe jetzt etwas gebraucht bis dein Player lief, ich musste ja ein paar Änderungen nacharbeiten
Das devStateIcon find ich gut
Was für mich noch etwas zweifelhaft ist, ist der rote/grüne Punkt für die Bridge im Player - aber vielleicht bin ich nur skeptisch

Was für mich etwas unnatürlich ist, ist das Volume mute Icon im set Befehl. Mich verwirrt es: man muss das Icon drücken, das ändert sich und nichts passiert - klar das macht er erst nach dem drücken von set.
Ich glaube  hier wäre die Auswahl mit Wort oder Zahl besser.

Danke für die Arbeit!
Ich mach jetzt mal mein Testsystem platt und schau mir den aktuellen Stand vom scratch an

Gruß Otto

[87insane]

Hey zusammen,

Was für mich etwas unnatürlich ist, ist das Volume mute Icon im set Befehl. Mich verwirrt es: man muss das Icon drücken, das ändert sich und nichts passiert - klar das macht er erst nach dem drücken von set.
Ich glaube  hier wäre die Auswahl mit Wort oder Zahl besser.

Finde ich auch... Habs so gelassen, da ich nicht genau weiß was Beta-User vor hat damit ....

ich habe jetzt etwas gebraucht bis dein Player lief, ich musste ja ein paar Änderungen nacharbeiten

Was denn? Vermutlich alles andere bis auf devStateIcon was hier in den Seiten unter ging?

Was für mich noch etwas zweifelhaft ist, ist der rote/grüne Punkt für die Bridge im Player

Habe die Bridge in hidden liegen. Würde also (warum auch immer) die Bridge spinnen, sehe ich sofort was Sache ist:
grün: alles toll (Dienst läuft und es wurden Player gefunden)
gelb: Dienst läuft aber KEINE Player gefunden
rot: Dienst aus

Hab auch schon was neues gebaut (devStateIcon):

Code Auswählen Erweitern

{
my $groupname = ReadingsVal($name,"groupName","0");
my $sgroupname = (split(" ",ReadingsVal($name,"groupName","")))[0];
my $uuidtoname = "MQTT2_".ReadingsVal($name,"coordinatorUuid","0");
my $vol = ReadingsVal($name,"volume","");
my $img = ReadingsVal($name,"currentTrack_AlbumArtUri","");
my $trim30 = sub { return length($_[0]) < 29 ? $_[0] : substr($_[0],0,25).'...'; };
my $mystate = $name eq $uuidtoname ? ReadingsVal($name,"state","FEHLER") : ReadingsVal($uuidtoname,"state","");
my $amp = ReadingsVal($name,"bridgeConnected","0") eq "0"
? "rot"
: ReadingsVal($name,"bridgeConnected","0") eq "1"
? "gelb"
: "gruen";
my $playpic = $mystate eq "PLAYING"
? 'rc_PAUSE@red'
: $mystate eq "PAUSED_PLAYBACK"
? 'rc_PLAY@green'
: $mystate eq "STOPPED"
? 'rc_PLAY@green'
: $mystate eq "TRANSITIONING"
? 'rc_PLAY@blue'
: $mystate eq "set_next"
? 'rc_NEXT@blue'
: $mystate eq "set_previous"
? 'rc_PREVIOUS@blue'
: $mystate eq "set_volumeUp"
? 'rc_VOLUP@blue'
: $mystate eq "set_volumeDown"
? 'rc_VOLDOWN@blue'
: $mystate eq "set_mute"
? 'rc_MUTE@blue'
: $mystate;
my $mutecmd = ReadingsVal($name,"mute","0") eq "false"
? "true"
: "false";
my $mutepic = ReadingsVal($name,"mute","0") eq "false"
? 'rc_MUTE'
: 'rc_VOLUP';
my $show = "FEHLER";
my $currentTrack = $mystate eq "TRANSITIONING"
? "Puffern..."
: $trim30->(ReadingsVal($name,"currentTrack_Artist","FEHLER"))." - ".$trim30->(ReadingsVal($name,"currentTrack_Title","FEHLER"));
my $nextTrack = $trim30->(ReadingsVal($name,"nextTrack_Artist","FEHLER"))." - ".$trim30->(ReadingsVal($name,"nextTrack_Title","FEHLER"));
my $previouspic = 'rc_PREVIOUS';
my $nextpic = 'rc_NEXT';
my $voldownpic = 'rc_VOLDOWN';
my $voluppic = 'rc_VOLUP';

if (ReadingsVal($name,"bridgeConnected","0") ne "2") {
$show = " ".FW_makeImage("rc_BLANK")." ";}

elsif (($mystate eq "PLAYING")
|| ($mystate eq "TRANSITIONING" )
|| ($mystate eq "set_next" )
|| ($mystate eq "set_previous" )
|| ($mystate eq "set_volumeUp" )
|| ($mystate eq "set_volumeDown" )
|| ($mystate eq "set_mute" )) {

my $shownp = ReadingsVal($name,"name","0") eq $sgroupname ? "<a href=\"/fhem?cmd.dummy=set $name previous&XHR=1\">".FW_makeImage($previouspic)."</a>
<a href=\"/fhem?cmd.dummy=set $name next&XHR=1\">".FW_makeImage($nextpic)."</a>" : "";

$show = "<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($playpic)."</a>
<a href=\"/fhem?cmd.dummy=set $name volumeDown&XHR=1\">".FW_makeImage($voldownpic)."</a>
$shownp
<a href=\"/fhem?cmd.dummy=set $name volumeUp&XHR=1\">".FW_makeImage($voluppic)."</a>
&nbsp;&nbsp;&nbsp;&nbsp;
<a href=\"/fhem?cmd.dummy=set $name mute $mutecmd&XHR=1\">".FW_makeImage($mutepic)."</a><br>";

if (ReadingsVal($name,"name","0") eq $sgroupname) {
$show = "$show
Aktueller Track: $currentTrack<br>
Nächster Track: $nextTrack";}

elsif (ReadingsVal($name,"name","0") ne $groupname) {
$show = "$show
Master: $sgroupname";}
}
else {
$show = $name eq $uuidtoname
? "<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($playpic)."</a>"
: "<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($playpic)."</a><br>Master: $sgroupname";}

"<div>
<table>
  <tr>
    <td><div style='display: inline-block; margin-right: 5px; border: 1px solid lightgray; height: 4.00em; width: 4.00em; background-image: url($img);background-size: contain;'></div>
</td>
    <td>".FW_makeImage("10px-kreis-".$amp)."
$show</td>
   </tr>
</table>
</div>"
}

Das hier kann auch den Status von Gruppen-Playern abbilden. Solange es keine Ideen gibt für das sonos2mqtt Modul habe ich keine besseren...
Nun geht er hin und:

Code Auswählen Erweitern

my $mystate = $name eq $uuidtoname ? ReadingsVal($name,"state","FEHLER") : ReadingsVal($uuidtoname,"state","");
liest den State im Gruppenmodus vom Master und im normalem Modus von sich selber. An sich finde ich das ok aber man muss leider F5 / aktualisieren anklicken damit der passive Player auch korrekt angezeigt wird. (vermutlich wegen longpoll usw?)

PS: Nicht meckern wegen dem Code. Da wir ja immer weiter testen, mache ich den nicht jedes mal neu und sauber. Sauber machen können wir bei Fertigstellung. Gerade jetzt mit den Gruppen, würde ich ein wenig anders machen. Ich brauche noch jemanden der Dolby oder Stereo Paare testen kann. Das verhält sich wieder anders als normale Gruppen.

Wenn das hier alles sauber und zufriedenstellend läuft, mache ich auch eine saubere Erklärung. Ich mag es selber nicht immer x Seiten zu lesen um diese eine Zeile noch zu finden...

[Beta-User]

Hey zusammen,
Finde ich auch... Habs so gelassen, da ich nicht genau weiß was Beta-User vor hat damit ....

Da ich "blind" bin (bzw. diese Geräte nicht habe und vermutlich auch nicht anschaffen werde, ich habe rechtzeitig in paar Kabel verlegt ), dürft ihr das machen, wie ihr wollt.
Falls es da um webCmd und igendwelche sich (hoffentlich) abwechselnden Icons ging, war meine Intention v.a. klarzustellen, dass es bereits entsprechende Funktionalitäten gibt und man nicht unbedingt das Rad neu erfinden muß. Wenn's anders (besser) geht, ist mir das auch recht .

[Otto123]

Falls es da um webCmd und igendwelche sich (hoffentlich) abwechselnden Icons ging, war meine Intention v.a. klarzustellen, dass es bereits entsprechende Funktionalitäten gibt und man nicht unbedingt das Rad neu erfinden muß. Wenn's anders (besser) geht, ist mir das auch recht .

Das ist auch absolut hilfreich sowas zu sehen - kann man eigentlich zwei Parameter/widgets in der setList hintereinander machen? Wenn Du das aus dem Ärmel schüttelst für slider und ne checkbox

Was denn? Vermutlich alles andere bis auf devStateIcon was hier in den Seiten unter ging?

genau

[Otto123]

Ich brauche noch jemanden der Dolby oder Stereo Paare testen kann. Das verhält sich wieder anders als normale Gruppen.

Wie meinst Du das? Ich habe eine 5.1 Kombi aus Playbase Sub und 2x Sonos1 - im Gegensatz zum classic Sonos Modul und analog zur Player App sehe ich die Mitglieder aber gar nicht. Und das finde ich gut so.

Ok - vielleicht weiß ich was Du meinst. Ich bekomme das devStateIcon 10 mal angezeigt 🥴

[87insane]

Da ich "blind" bin (bzw. diese Geräte nicht habe und vermutlich auch nicht anschaffen werde, ich habe rechtzeitig in paar Kabel verlegt ), dürft ihr das machen, wie ihr wollt.

Nach der Antwort von Stephan, denke ich macht ein spezieller Eintrag (wenn das geht) in Readingslist Sinn.
Aktuell sieht der gemeinte Eintrag so aus:

Code Auswählen Erweitern

sonos/RINCON_7828CAF427B201400:.* { json2nameValue($EVENT,'',$JSONMAP) }

Könnte man diesen anpassen wie z.B. announce bei Shelly? ( Du bist ggf. blind aber kannst sicher helfen )
Er müsste gucken ob uuid != coordinatorUuid.
Wenn uuid und coordinatorUuid gleich sind, soll er das tun: sonos/RINCON_7828CAF427B201400:.* { json2nameValue($EVENT,'',$JSONMAP) }
Wenn unterschiedlich, das: sonos/%coordinatorUuid%:.* { json2nameValue($EVENT,'',$JSONMAP) }

Im einzel Modus ist uuid == coordinatorUuid.
Im Gruppenmodus ist uuid != coordinatorUuid. In coordinatorUuid steht immer sowas wie: RINCON_7828CAF4289001400 (also perfekt um einen variablen Readingslist-Eintrag zu erzeugen, wenn das geht.
Mit einem solchen Eintrag könnte ich den Player weiter bauen und das Aktualisierung Problem wäre weg.

Ggf geht es auch nur mit einem Abo gegen alles (sonos/+:.) und dann muss gefiltert werden.
Am Ende soll er selber erkennen - Bin ich Master? Wenn ja dann nimm meinen RINCON Pfad und sonst den, des Masters. Der Name des Masters ist immer im Reading DEVICE coordinatorUuid (in jedem Player DEVICE).

Hatte an sowas gedacht:
sonos/+:.* { $EVENT =~ m,.* VERGLEICH, ? { json2nameValue($EVENT,'',$JSONMAP) } : undef }
(nur in funktionierend).

[Beta-User]

Harte Nüsse habt ihr hier zu knacken...

Zwei Widgets für einen setList-Eintrag geht afaik nicht, man müßte ggf. zwei setter daraus machen und eben dann nur via devStateIcon etc. anzeigen, was jeweils Sinn macht...

Was das rausfiltern bestimmter Messages auf Basis der Analyse von Topic und Message angeht: müßte gehen, ist aber ziemlich aufwändig. Am ehesten in diese Richtung geht das, was bei OpenMQTTGateway_BT_gtag (und drumrum) stattfindet; da ist jedenfalls u.a. auch "wildcards@Topic" umgesetzt. Evtl. müßte man dann gleich noch den gemappten Hash auf Aktualisierung nachbearbeiten (6channel_ethernet_board_6input_split). Das aber erst mal nur als erste Gedanken dazu, das ganze ist "höhere Schule", und irgendwie riecht es eher nach myUtils...

(Das announce bei Shelly ist übrigens ein gutes Stichwort: Da ist zum einen der Teil der Suche durch Event drin, zum anderen kann das vermutlich aus den shelly-templates wieder raus, weil announce seit einigen fw-Versionen wieder auch auf das Device geht, oder? Teil 2 ist hier aber OT, bitte ggf. im anderen Thread antworten).

[Wuppi68]

Ok - vielleicht weiß ich was Du meinst. Ich bekomme das devStateIcon 10 mal angezeigt 🥴

na dann sei mal froh, dass Sonos noch kein 7.1.4 kann ***duckundganzschnellverkrümel***

[87insane]

Wie meinst Du das? Ich habe eine 5.1 Kombi aus Playbase Sub und 2x Sonos1 - im Gegensatz zum classic Sonos Modul und analog zur Player App sehe ich die Mitglieder aber gar nicht. Und das finde ich gut so.

Ok - vielleicht weiß ich was Du meinst. Ich bekomme das devStateIcon 10 mal angezeigt 🥴

Das ist gut! Erstmal. Dann brauchen wir das nicht beachten. Allerdings geht in die Richtung laut Sonos und Stephans Doku mehr. Ich würde mir die auch nicht einzeln anzeigen lassen wollen. Aber man kann die Einstellungen bis ins Detail anpassen. Das würde ich ggf noch mit Anzeigen lassen. Also bei Dolby wie laut welcher Kanal ist und die Möglichkeit bieten alle einzeln in master zu steuern zb. Aber das können wir dann ja beruhigt nach hinten schieben.

Aso...überlesen...
Stateformat löschen, dann ist es nur einmal.

[Otto123]

Aso...überlesen...
Stateformat löschen, dann ist es nur einmal.

Eh komm so einfach

Ich glaub man muss die derzeitigen Templates überarbeiten

Ich sag mal: gefällt mir besser als classic.
Was noch etwas stört ist der nächste Track, der passt nicht beim Radio

Und: Man muss nicht alles machen was geht. Ich brauch das Ding primär zum automatisieren, für schön und "alles was geht" gibt es doch die App. Die muss man nicht nachbauen.

[Otto123]

In dieser Datei http://192.168.56.222:1400/xml/device_description.xml stehen weitere Infos zum Player.
Dort steht auch die Adresse vom Icon zum Player drin und man könnte es direkt laden
http://192.168.56.222:1400/img/icon-S14.png

Nur so zum Nachdenken

[87insane]

Was noch etwas stört ist der nächste Track, der passt nicht beim Radio

sehe da kein Problem.. bekomme ich weg.

In dieser Datei http://192.168.56.222:1400/xml/device_description.xml stehen weitere Infos zum Player.
Dort steht auch die Adresse vom Icon zum Player drin und man könnte es direkt laden
http://192.168.56.222:1400/img/icon-S14.png

Worauf bezogen?

Ich glaub man muss die derzeitigen Templates überarbeiten

Warum? Normal ist das nur wenn man ein Gerät immer wieder ändert. Da ich aktuell viel dran rum spiele habe ich auch noch kein Template gebaut. Würde zuerst einen Player fertig haben wollen an dem ich nicht jeden Tag bastel....

@Beta-User: Ich weiß du zeigst den Leuten gerne wo sie nachlesen können... Ich bastel auch immer gerne alles Mögliche und lese x Dinge. In diesem speziellen Fall, macht es ggf. Sinn, wenn du direkt (blind) mit einsteigst? An sich weiß du ja was gemeint ist und bevor ich wieder 6 Stunden wegen suchen verliere...Wäre super genial, wenn du bei der Idee mit dem Readingslist-Eintrag hilfst. Ggf. gibt es auch noch eine bessere Idee?

Eh komm so einfach

Hab ja schon viele Stunden damit verbringen dürfen. Als ich das, das erste mal hatte, habe ich locker 4 Stunden gebraucht um den Zusammenhang zu bemerken^^.
Ist eben auch sehr speziell diese Art von devStateIcon. An sich schon fast ein Modul.

[Otto123]

Bezogen auf den Sonos Player
IP des Players
http://192.168.56.222
Port
:1400
XML
/xml/device_description.xml
dort steht dann die relative URL zum Icon.

[87insane]

Meinst du mit "Icon" = "Album Cover / Track Cover usw?

Wenn Ja:
Zu dem Thema denke ich eh noch nach. Wenn du von extern versuchen würdest deine FHEM Seite auf zu rufen, werden sich Personen wundern. Denn natürlich werden interne IP Adresse aus einem externen Netz nicht angezeigt /aufgelöst. Und somit würden die Bilder nicht erscheinen können.
Am liebsten hätte ich die Netz Quelle von SONOS.


Ach ja...danke für das schöner als classic

[Beta-User]

@Beta-User: Ich weiß du zeigst den Leuten gerne wo sie nachlesen können... Ich bastel auch immer gerne alles Mögliche und lese x Dinge. In diesem speziellen Fall, macht es ggf. Sinn, wenn du direkt (blind) mit einsteigst? An sich weiß du ja was gemeint ist [...]

Ja, hmm, also:

Das Problem fängt damit an, dass ich das hier irgendwie interpretieren muß, und leider keinen Schimmer habe, wie der MQTT-Verkehr (v.a. die konkreten Payloads) aussieht:

Nach der Antwort von Stephan, denke ich macht ein spezieller Eintrag (wenn das geht) in Readingslist Sinn.
Aktuell sieht der gemeinte Eintrag so aus:

Code Auswählen Erweitern

sonos/RINCON_7828CAF427B201400:.* { json2nameValue($EVENT,'',$JSONMAP) }

Könnte man diesen anpassen wie z.B. announce bei Shelly? ( Du bist ggf. blind aber kannst sicher helfen )
Er müsste gucken ob uuid != coordinatorUuid.
Wenn uuid und coordinatorUuid gleich sind, soll er das tun: sonos/RINCON_7828CAF427B201400:.* { json2nameValue($EVENT,'',$JSONMAP) }
Wenn unterschiedlich, das: sonos/%coordinatorUuid%:.* { json2nameValue($EVENT,'',$JSONMAP) }

Im einzel Modus ist uuid == coordinatorUuid.
Im Gruppenmodus ist uuid != coordinatorUuid. In coordinatorUuid steht immer sowas wie: RINCON_7828CAF4289001400 (also perfekt um einen variablen Readingslist-Eintrag zu erzeugen, wenn das geht.

Daher könnte man jetzt hergehen, und dem Blinden den ganzen MQTT-Verkehr zum Fraß/zur Analyse und zum "selber-Testen" vor die Füße werfen. Ist mir im Moment ehrlich gesagt zu komplex.

Oder wir nähern uns der Sache eher mit Bruchstücken:
1. Feststellung: wenn wir das "on the fly" anpassen wollten, müßten wir jedes Mal Attribute ändern. Ginge, ist aber mAn. unschön.
2. Feststellung: Wenn wir das vermeiden wollen, brauchen wir
a) eine Möglichkeit um festzustellen, ob wir aa) solo bzw. der Master sind oder bb) unter einem anderen Master stehen. Dafür würde ich ein Reading (an jedem Gerät) generieren, das man im Weiteren auch dann auswerten kann; Inhalt vermutlich 0 (autonom) oder die ID des Masters. Sollte anhand des shelly-announce-Beispiels leistbar sein? Ansonsten bräuchte ich die dazu passenden "verdaubaren" Infos zum MQTT-Verkehr/Payload...
b) wir müssen dann beide Zweige abonnieren, also den "wildcard"-Zweig und den "normalen RINCON", und dann erst prüfen, ob wir eingehende Messages auf dem Zweig überhaupt auswerten dürfen (dann werden die auf dem speziellen RINCON kommenden Infos auch grundsätzlich verworfen (?) oder nur bestimmte??? ). Ggf. kann man an ein "master_"-Präfix (?) denken, falls man das auseinanderhalten muß; ; Präfix-Bestimmung ginge ggf. auch dynamisch, wir sind da auf der Perl-Ebene... Dann müßte aber das JSONMAPPING auch passen, was schwierig ist, wenn es zu individualisiert ist).

Sorry, aber das ist auch für mich von hier aus eine einzige Blackbox, ohne Zuarbeit des einen oder anderen Bauteils oder gemeinsame Weiterentwicklung wird das nicht gehen...