Folgende Erkenntnisse konnte ich beim erstellen des Players machen und helfen hier vermutlich weiter...
Es gibt folgende interessante Readings:
groupName beinhaltet den Playernamen. Wenn es aber eine Gruppe ist, steht dort MASTER + x(Anzahl) - Beispiel Wohnzimmer + 2
coordinatorUuid beinhaltet z.B. RINCON_7828CAF427B201400 (Ist die eigene wenn es keine Gruppe ist. In einer Gruppe steht da RINCON_1A2B3C... ID des Masters)
uuid beinhaltet z.B. RINCON_7828CAF427B201400 - (Ist immer die eigene ID)
name beinhaltet z.B. Wohnzimmer (Ist der Playername)
1. Ja - Sehe ich auch so! Nervt jetzt schon...
2. a)
aa)
Woher weiß ich ob ein Player in einer Gruppe ist? Wenn name != groupName [if (ReadingsVal($name,"name","0") ne (ReadingsVal($name,"groupName","0")] [Wohnzimmer != Wohnzimmer + 2]
Hier könnte man auch $name mit dem dem Reading coordinatorUuid (natürlich dann mit MQTT2_ vor gesetzt) vergleichen. [my $uuidtoname = "MQTT2_".ReadingsVal($name,"coordinatorUuid","0");]. Finde ich aber schlecht. Zu unflexibel, wenn einer doch mal ein rename macht.
bb1)
Woher weiß ich wer Master ist (lesbar für den Benutzer)? gorupName nach dem ersten Leerzeichen splitten [my $sgroupname = (split(" ",ReadingsVal($name,"groupName","")))[0];] [Wohnzimmer + 2 = Wohnzimmer]
bb2)
Woher weiß ich wer Master ist (um Daten zu übernehmen)? Gerät mit dem Reading uuid und dem Inhalt aus coordinatorUuid (des Slaves) suchen [.*:FILTER=uuid=coordinatorUuid]
cc) [benenne ich das jetzt mal]
Thema Payload. Hier kommen wir wohl nie weiter... Ich stelle die Frage echt oft aber eine gute Antwort gab es noch nicht. Wie fangen wir diesen Verkehr am besten ab. Verbose @all finde ich keine Option! Hier wäre eine grundlegende Logging Definition gut. So das man immer wieder, einfach mal so..... Was ist aktuell "best practice"?
Info zu 2. a): Mit der Art und Weise würden auch mehrere Gruppen erkannt werden und die Slaves sauber zugeordnet.
b)
Ich denke das eigentlich alle Fragen an sich durch 2. a) beantworten werden konnten und das sogar flexibel.
An sich (
https://github.com/svrooij/sonos2mqtt/issues/110#issuecomment-652288934) sollte dies die weiteren beantworten.
Also haben wir nur ein + in allen Playern auf den Zweig und WENN = GRUPPE [aa)], DANN nimm die Daten vom MASTER [bb2)]
So läuft das ca auch im devStateIcon ab. Wundere mich das du das so nicht gecheckt hast. Immerhin kann ich das alles (und das sage ich gerne), größten Teils von Dir
Wie dem auch seie... Ich helfe gerne weiter um den Zweig als Essenz zu erarbeiten. Denn dann, kann ich den Player (in meinen Augen) nahezu komplett fertig stellen. Dazu würden Die Gruppen auch logisch angezeigt usw.
ABER ich überlege auch noch eine weitere Ansicht zu bauen. Ich denke nicht jeder hat alle Player in jedem Raum (FHEM). Also wäre ein Slave in einem Raum ungünstig so wie es aktuell ist. Ich müsste also A) bestimmte set´s auf dem Master ausführen lassen.
Oder B) Für Gruppen ggf. eine separate ReadingsGroup. Aber das finde ich wieder unschön....
Oder C) Ideen @all?
Info: Liegt daran, das z.B. next oder previous auf dem Slave / Child nicht ausgeführt werden können. Play/Pause/Stop gilt an allen Playern in einer Gruppe. Deswegen blende ich die beiden Button auf den Slaves auch aus. Zudem gibt es noch einen Unterschied zwischen der Player Lautstärke und der Gruppenlautstärke. Sieht man auch in der App immer ganz schön. Wenn z.B.
Wohnzimmer Lautstärke 50%
Arbeitszimmer Lautstärke 30%
und man dann an der Gruppen-Lautstärke dreht, gehen die einzelnen Player mit Ihrer eigenen Lautstärke mit. Also es bleibt harmonisch und nicht alle Player sind identisch der Gruppenlautstärke. In meinem Player geht aktuell nur die Lautstärke des jeweiligem Players. Da ich das eigentlich auch nur zur Automatisierung nutze aber es auch schön haben will, steigere ich mich da auch so rein. Wir reden hier ja auch nicht gerade über ein Mini-Projekt... Mal sehen wo wir in 4 Wochen stehen
