Erklärung zu json2nameValue / MQTT readingList Json - bestimmte Elemente filtern

Begonnen von 87insane, 07 Juli 2020, 20:09:47

Vorheriges Thema - Nächstes Thema

87insane

Wegen der CID / $4 Prüfung hatte ich in meinem Beitrag noch was an gehangen.
ZitatGinge auch mit 1-4 wenn man die uuid als Vergleich nimmt. ABER es gibt bei 1-4 ganz kurz beim verlassen einer Gruppe einen falschen Schwenk. Denk gibt es im Vergleich zur immer festen CID nicht. Deswegen würde ich lieber die CID nehmen.
Die CID ist stabiler... Hab mir das ganze über den EVENT Monitor angesehen und es ist zwar immer nur sehr kurz beim verlassen einer Gruppe aber das muss nicht sein. Bei CID ist das direkt korrekt.

Der schwere Part und da habe ich keine Idee... Nun müsste wenn = SLAVE, dieser die Daten des Masters übernehmen und in seine eigenen schreiben. Aber es werden nicht alle benötigt. Nur sowas wie state, title, track... Infos eben.
Das mit der Lautstärke ist ein wenig Tricky. Es gibt für jeden Lautsprecher innerhalb einer Gruppe eine einzel Lautstärke. Aber es gibt innerhalb einer Gruppe noch einen Master Regler. Dieser regelt die Lautstärke relativ zu allen Lautsprechern. Also Box 1 auf 25% und Box 2 auf 50% = Der Master würde auf 50% stehen. Wenn ich nun auf 60% schiebe (am Master Regler), werden auch alle Slaves um 10% angehoben. (Hoffe man versteht wie ich das meine).
Ich wollte hingehend der Readings aufräumen und den Player dem entsprechend mit aufräumen und anpassen. Das hier ist der Weg zur sauberen Gruppen Fähigkeit. Ist aber auch super MQTT/Regex Training.

Bin aber schon am weiter regexen...

Beta-User

Hmm, dann ist das mit der CID auch ok.

Was aber weiter ein Punkt bleibt: Wenn möglich, dann nur auf den eigenen Topic hören?

Was die Readings angeht: beim devStateIcon kann man ja abfragen, von welchem Device bestimmte (einzelne) Werte effektiv gelesen werden sollen; das könnte man (aus dem "TEST") auch via devspec2array abfragen bzw. bestimmen (und am besten in ein separates Reading packen). Ist halt einigermaßen kompliziert...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

Von der Tendenz her würde ich eher in so eine (NICHT fertig) Richtung gehen:
sonos/RINCON_([0-9A-Z]+):.* { $EVENT =~ m,.*name.:.([^"]+)...groupName.:.([^"]+)...coordinatorUuid.:.([^"]+).*currentTrack.:..(Album.:.([^"]+)...Artist.:.([^"]+)...AlbumArtUri.:.([^"]+)...Title.:.([^"]+)...UpnpClass.:.([^"]+)...Duration.:.([^"]+))?(Artist.:.([^"]+).*Title.:.([^"]+))?,; my $CID = InternalVal($NAME,"CID",""); $1 eq $2 ? {"TEST"=>"SINGLE - $13 $6 $8"} : $CID ne $3 ? {"TEST"=>"SLAVE","TEST2"=>"$13 $5 $7"} : {"TEST"=>"MASTER"} }

So konnte ich Track Daten usw abfangen vom Master auch in den Slaves. Müsste ich nur noch A) original Reading überschreiben oder B) neue dafür anlegen lassen...

Das meinstest du mit:
ZitatWas aber weiter ein Punkt bleibt: Wenn möglich, dann nur auf den eigenen Topic hören?
nehme ich mal an. Ist die Frage wie man in Gruppen sonst an die Daten kommt...? Ich könnte mir das nun komplett zusammen Regexen und mal vorstellen wie ich das so meine.... Ist leider ein sehr spezieller Fall mit den JSONs....

Bei Radio sehen die so aus:
{"uuid":"RINCON_7828CAF427B201400","name":"Wohnzimmer","groupName":"Wohnzimmer + 1","coordinatorUuid":"RINCON_7828CAF427B201400","mute":{"Master":false,"LF":false,"RF":false},"ts":1594288723969,"currentTrack":{"Artist":"SURF MESA","AlbumArtUri":"http://192.168.20.70:1400/getaa?s=1&u=x-sonosapi-stream:s167727%3fsid%3d254%26flags%3d8224%26sn%3d0","Title":"ILY (I LOVE YOU BABY) (TOPIC REMIX)","UpnpClass":"object.item.audioItem.musicTrack","ItemId":"-1","ParentId":"-1","TrackUri":"x-sonosapi-stream:s167727?sid=254&flags=8224&sn=0","ProtocolInfo":"sonos.com-http:*:audio/mpeg:*"},"enqueuedMetadata":{"Title":"I Love 2 Dance","UpnpClass":"object.item.audioItem.audioBroadcast","ItemId":"-1","ParentId":"-1"},"transportState":"PLAYING","playmode":"NORMAL"}


Bei z.B. Album basierter Wiedergabe (Spotify) so:
{"uuid":"RINCON_7828CAF427B201400","name":"Wohnzimmer","groupName":"Wohnzimmer + 1","coordinatorUuid":"RINCON_7828CAF427B201400","mute":{"Master":false,"LF":false,"RF":false},"ts":1594287882462,"currentTrack":{"Album":"No!","Artist":"CID","AlbumArtUri":"http://192.168.20.70:1400/getaa?s=1&u=x-sonos-spotify:spotify:track:0VPTpC1ZLQRoz1n06mksVZ%3fsid%3d9%26flags%3d8224%26sn%3d3","Title":"No!","UpnpClass":"object.item.audioItem.musicTrack","Duration":"0:03:11","ItemId":"-1","ParentId":"-1","TrackUri":"x-sonos-spotify:spotify:track:0VPTpC1ZLQRoz1n06mksVZ?sid=9&flags=8224&sn=3","ProtocolInfo":"sonos.com-spotify:*:audio/x-spotify:*"},"enqueuedMetadata":{"Artist":"Spotify","AlbumArtUri":"https://i.scdn.co/image/ab67706f00000002470dd505fcf08e4693db9b24","Title":"Dance Party","UpnpClass":"object.container.playlistContainer#playlistItem","ItemId":"0006002cspotify%3aplaylist%3a37i9dQZF1DXaXB8fQg7xif","ParentId":"spotify%3aview%3aginger-genre-affinity%5b0%5d"},"nextTrack":{"Album":"Turn Me On (feat. Vula)","Artist":"Riton","AlbumArtUri":"http://192.168.20.70:1400/getaa?s=1&u=x-sonos-spotify:spotify:track:0qaWEvPkts34WF68r8Dzx9%3fsid%3d9%26flags%3d8224%26sn%3d3","Title":"Turn Me On (feat. Vula)","UpnpClass":"object.item.audioItem.musicTrack","Duration":"0:03:28","ItemId":"-1","ParentId":"-1","TrackUri":"x-sonos-spotify:spotify:track:0qaWEvPkts34WF68r8Dzx9?sid=9&flags=8224&sn=3","ProtocolInfo":"sonos.com-spotify:*:audio/x-spotify:*"},"transportState":"PAUSED_PLAYBACK","playmode":"NORMAL"}


Das muss man schon genau gucken. Bin aktuell bei $13...

Beta-User

Hmmm, alsooooo:

- Wenn du tatsächlich alle Topic-branches abbonieren mußt, um auf die "passenden" Daten zu kommen, _vermute_ ich, dass da irgendwo noch eine Lücke ist mit Infos, die ggf. von einem dritten Gerät kommen; die Bedingung $1 eq $2 müßte dann auch zutreffen, aber der JSON gar nichts mit dem aktuellen Gerät zu tun haben => dieser Fall wäre noch zu verwerfen.

- Im Moment _glaube ich_, dass es zielführend wäre, dann nur noch den generalisierten Topic zu abonnieren und ggf. (teilweise) mit unterschiedlichen (dynamischen) Präfixen zu arbeiten. Dann können wir via jsonMap (nur) den Teil rauszufiltern, der uns wirklich interessiert - und brauchen dabei dann uU. effektiv gar nicht mehr nach der Quelle zu unterscheiden (oder brauchen wir z.B. die Angabe des MASTER für irgendwas, z.B. Kommandos? Hatte verstanden: eigentlich eher nicht?). Pseudo-Code (ohne Korrektur von obigem):
sonos/RINCON_([0-9A-Z]+):.* { $EVENT =~ m,name.:.([^"]+)...groupName.:.([^"]+)...coordinatorUuid.:.([^"]+),; my $CID = InternalVal($NAME,"CID",""); $1 eq $2 ? json2nameValue($EVENT,'SINGLE_',$JSONMAP) : $CID ne $3 ? json2nameValue($EVENT,'SLAVE_',$JSONMAP) : json2nameValue($EVENT,'MASTER_',$JSONMAP) }

Dann sollte es möglich sein, jeweils den Teil via jsonMap rauszupicken (und auf das passende Effektiv-Reading zu mappen), der gebraucht wird...?

(Was mir als Bausteinchen fehlt, ist ein Gefühl dafür, welche Daten ggf. wie noch ankommen, wenn so ein Teil unter der Kontrolle eines anderen steht; kommen dann noch (flasche) Infos zum angeblich laufenden Track usw?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

1) Gegen CID zusätzlich prüfen?

2) Kommandos in einer Gruppe: play/pause (geht an jedem Player), track weiter/track zurück (geht nur am Master), lauter/leiser (geht an jedem player aber auch am Master (spezielle Erklärung dazu war oben). Ist leider spezieller.

3) Das Bausteinchen: Wenn ein Player einem Master untergeordnet ist, bekommt er auf seinem Zeig KEINE Infos mehr. Also bleibt in diesem Player alles wie es war. Dann steht im Reading für Track einfach iwas altes drin, was vorher mal drin war. Genau das ist ja das Problem, warum ein Slave in diesem Moment die Daten vom Master bekommen sollte. Aber in meinen Augen eben gefiltert. Nicht alles ist überhaupt notwendig. Ich würde die Readings hier wirklich so halten, wie sie auch gebraucht werden. Der JSON String enthält auch ein wenig, was man nicht bruacht....
Deswegen würde ich das A) So von der Bridge entscheiden lassen oder B) in jedem Player so als Reading hinterlegen.
Findest du es wirklich sinnig über json2nameValue zu gehen? Dann hat man wieder x Readings und einige aktuell und andere nicht. Ich würde mit der Variante immer die gleichen nutzen und überschreiben...Aber ggf. übersehe ich den Vorteil deiner Variante...  ???

Beta-User

Ad 1: Vermutlich. Wobei das ohne den konkreten MQTT-Verkehr zu kennen eben eher eine Schätzung ist... Btw.: ich _glaube_ es wäre zielführend, statt auf die CID das Attribut devicetopic zu "nutzen" (ist eigentlich eher ein Mißbrauch...) und das entsprechend zu füllen. Das ist ggf. etwas transparenter (aber leider auch nicht deutlich einfacher)?
Ad 2: Klingt einerseits kompliziert. Aber wenn ich das andererseits mal etwas genereller ansehe:
a) wir kennen/können kennen die uuid des Masters und wir wissen auch, wann wir ggf. die Steuerungselemente für Gruppenbedienung benötigen würden?
b) wir wissen auch, über welchen Topic wir die an den Master gerichteten Befehle absetzen müssten (ganz ohne den Namen ermitteln zu müssen ;) ). Allerdings ist der nicht statisch, sondern wäre eben je nach aktuellem Master (mit Perl) zusammenzubasteln. Ergo fehlen eigentlich nur ein paar weitere setList-Einträge...?

Ad 3: Dass der "normale Zweig" dann "stumm" ist, ist erst mal gut (wobei ich glaube, dass es einfacher wäre, alles über das regex-Topic zu empfangen).
Zum Rest: Meine Idee mit json2nameValue() und den Präfixen war ja nicht unbedingt, mehr Readings zu erzeugen, sondern ggf. via jsonMap genau den Teil rauszufischen, der uns interessiert und dann damit die "normalen" Readings zu überschreiben (und den Rest eben mit :0 zu verwerfen). Das mag sogar etwas mehr Auswerteaufwand bzw. Programmschritte im Hintergrund erfordern, ist aber mMn. am Ende für den User deutlich transparenter (da "Standardfunktion") als ein Perl-regex-Bandwurm, und v.a.: er ist nicht ganz so statisch, man kann leichter was dran ändern und ist nicht direkt aufgeschmissen, wenn sich an der Struktur des JSON je mal was ändern sollte...
(Evtl. sollte man den Präfix noch als Parameter schreiben, den man vorneweg ermittelt?)

Falls es an mehreren Stellen viel und in der "one-liner-notation" unübersichtliches Perl werden wird: evtl. sollte man da eine eigene myUtils mit ausliefern?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

2
a) Ja
b) Finde es nicht schlimm wenn die Steuerung so ist wie sie ist. Dennoch macht ein "weiter" Knopf auch in jedem Raum Sinn. Kann man drüber nachdenken.

3
Muss ich mir ansehen... Bei Perl weiß ich besser was ich mache als bei JasonMap usw. Lesen..lesen...Habe aber eine Vermutung wie du das meinen könntest.
Ich hatte doch mal den Verkehr des Zweiges rein geworfen? Einmal als Radio und einmal mit z.B. Spotify. Ich weiß nicht welche Möglichkeiten es noch gibt aber laut definition sollte es nur diese beiden Formen geben auf dem Zweig.
Die Präfix lasse ich mal als unbeantwortet.. Sehe (noch?) keinen Sinn drin. Das kann sich aber noch ändern ;)

Hab aber leider keine Idee wie ich die zweite Prüfung darein bekomme ...
$2 eq $3
? {"grouping"=>"SINGLE"}
: $CID ne $4
? {"grouping"=>"SLAVE"}
: {"grouping"=>"MASTER"} }

Normal würde ich jetzt prüfen ob $2 eq $3 & $CID eq $1 ist. Aber geht ja mit ternary nicht... soweit ich weiß. Hat da wer eine Idee? :)

Beta-User

ad 2: Da unterhalten wir uns über Optionen, ist m.E. einfach "nice to have" und weil wir's halt können :P ...

ad 3: Was die Prüfung angeht, müßte eigentlich als erste Prüfung das hier funktionieren:
$2 eq $3 && $CID eq $1
Aber: irgendwie meint mein Bauchgefühl, dass das nicht hinreichend ist, um "den dritten Mann" außen vor zu lassen? *

Das mit jsonMap und dem Ignorieren bestimmter Werte wird evtl. klarer, wenn du dir z.B. mal das tasmota_3socketUSB_split (oder einen anderen aktuellen mehrkanalignen Tasmota) ansiehst? Wenn du das mal nachgespielt hast, wirst du es easy finden ;) .

Betr. die payloads usw.: es ist für mich sehr schwierig, immer die jeweils passende Info rauszufischen, selbst wenn sie irgendwo steht. Und selbst wenn hier der payload in verschiedenen Varianten stehen sollte, kann ich immer noch nicht ohne weiteres wissen, über welchen Topic das kam und in welchem Kontext (master/slave/single). Hier war es master, aber über welchen Topic? Vermutlich den eigenen...? Und wie sieht das zugehörige Slave-Gerät message-mäßig aus? (ad *: das ist vermutlich auch hier unser eigentliches Thema, nicht der Master... Ich würde also TOPIC+PAYLOAD von Messages benötigen, die an einen Slave und ein nicht beteiligtes drittes Gerät gehen.) Ich gehe davon aus, dass irgendwas kommen müßte, wenn man am Slave die Lautstärke ändert?

Zwischenzeitlich ist das aber vermutlich nicht mehr so dringlich, denn zum einen sind die Bausteinchen jetzt mAn. alle bekannt, ich denke auch, die richtige Richtung empfohlen zu haben mit dem jsonMap, der Rest ist sowieso zusammenbauen und (v.a.) testen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

2) ok.. Damit kann ich leben :)

https://github.com/svrooij/sonos2mqtt/issues/110#issuecomment-652288934

Nur Master und Single haben Payloads. Slaves bekommen nur noch Antwort auf zugelassene Aktionen, wie z.B. volume. Ansonsten bekommen die Slaves nichts mehr ab dem Moment wo sie einem Master / einer Gruppe angehören.

Hmmm.. cool, geht also doch so einfach "&&"... Teste mal ob es Seitenwind gibt...

Teste das alles mal und gebe Feedback.

Beta-User

Was den Link angeht: Danke, das ist dahingehend aufschlussreich, dass wir das wohl bis dahin richtig verstanden haben.
Zitat von: 87insane am 09 Juli 2020, 15:53:03
Nur Master und Single haben Payloads. Slaves bekommen nur noch Antwort auf zugelassene Aktionen, wie z.B. volume. Ansonsten bekommen die Slaves nichts mehr ab dem Moment wo sie einem Master / einer Gruppe angehören.
Was hier noch fehlt: Welche Infos kommen dann? Wenn es an der Stelle wieder "ich schicke alles" (aber mit teils veralteten Werten) ist, dann haben wir eine Aufgabe, wenn es nur "Differenzmeldung" ist, ist es easy, denn die können wir einfach "durchwinken" (im Sinne von normal verarbeiten)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

ZitatWas hier noch fehlt: Welche Infos kommen dann? Wenn es an der Stelle wieder "ich schicke alles" (aber mit teils veralteten Werten) ist, dann haben wir eine Aufgabe, wenn es nur "Differenzmeldung" ist, ist es easy, denn die können wir einfach "durchwinken" (im Sinne von normal verarbeiten)...
Keine Infos mehr... Die Slaves bekommen erst wieder in Ihrem Zeig eine Info wenn Sie die Gruppe verlassen. Solange ist das Gerät wie tot. Nur wenn Befehle angetriggert werden (die am Slave gehen), dann kommen auch genau diese Infos zurück. z.B. Volume.

Ich kämpfe gerade noch damit, zu zu ordnen wenn Single, dann nimm auch nur deine Daten und nicht die, des anderen Single, wenn er auf einmal was macht...

Beta-User

Zitat von: 87insane am 09 Juli 2020, 17:24:05
Keine Infos mehr... Die Slaves bekommen erst wieder in Ihrem Zeig eine Info wenn Sie die Gruppe verlassen. Solange ist das Gerät wie tot. Nur wenn Befehle angetriggert werden (die am Slave gehen), dann kommen auch genau diese Infos zurück. z.B. Volume.
Das klingt gut!

ZitatIch kämpfe gerade noch damit, zu zu ordnen wenn Single, dann nimm auch nur deine Daten und nicht die, des anderen Single, wenn er auf einmal was macht...
Ungetestete Idee: Wenn es (nur) den anderen betrifft, kommt die eigene "RINCON" in der payload auch nicht vor? Dann sollte sich das mit einer "Vorabregex" checken lassen?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

ZitatDas klingt gut!
Bisher ärgert es mich nur!

ZitatUngetestete Idee: Wenn es (nur) den anderen betrifft, kommt die eigene "RINCON" in der payload auch nicht vor? Dann sollte sich das mit einer "Vorabregex" checken lassen?
Schwierig ist es für mich das so hin zu bekommen das:
Wenn Single dann eigene Readings, wenn Slave dann die Readings des Masters und wenn Master, die eigenen Readings. Ich hatte bisher auch nur eine Master/Slave "Erkennung". Single hast du neu hinzugefügt und die Idee ist gut. Die Umsetzung fällt mir aber schwer.
Wie meinst du das mit der Regex in dem Fall? Meinst du IN json2nameValue??

Beta-User

Also, meine bisherige Interpretation:

- Wenn Slave, kommen nur noch eingeschränkte Infos an den "eigenen" Topic. Die könn(t)en wir direkt mit json2nameValue($EVENT,'',$JSONMAP) verarbeiten (vorsichtshalber mit $JSONMAP, brauchen wir vermutlich nicht).

- Wenn Master, kommen die Readings über denselben Topic, oder? Dann sollten wir die ebenfalls direkt mit json2nameValue($EVENT,'',$JSONMAP) verarbeiten können.

- Wenn Slave, kommen die Readings über einen anderen Topic, aber die Payload enthält irgendwo "unseren" Rincon? Wissen wir dann, wo, also in welchem JSON-Element? Mein Vorschlag war, einfach den ganzen JSON via regex zu parsen, und dann entweder "nichts" zu machen, oder eben bei einem match den Rest (=vorhandenen Code) anzuhängen. ABER: wenn das vorherige paßt, dann aber nur noch für den betreffenden "logischen Ast", der Rest ist ja schon erledigt, und dann nur hier effektiv mit dem/den passende/n Präfix(en) zu arbeiten.

(Im Prinzip stelle ich dieselbe Frage (was wann über welchen Topic an payload kommt) mal wieder in einem neuen Gewand...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

87insane

Wenn Slave: An den eigenen Topic kommen nur noch Infos wenn aus dem eigenen Topic auch etwas wie z.B. Lautstärke....(schrieb ich ja auch schon).

Wenn Master: Hier kommen dann weiterhin über seinen Topic die Infos.

Wenn Slave: Kommen die Readings garnicht mehr...siehe oben. Sie sollten dann aber vom Master kommen, damit man in dem Player auch den wirklichen Status hat. Man erkennt in der Payload nur wer der Master einer Gruppe ist. Man erkennt nicht wer genau die Mitglieder sind. "groupName Wohnzimmer + 2". Die Mitglieder selber erkennen nur wem sie angehören, da der Gruppenname auch immer den MASTER am Anfang des Namens hat und das eben die coordinator ID bei Gruppen beitritt bekannt gegeben wird. Es gibt also keine Auflistung der Slave RINCONs in der Payload. Die Slaves kennen sich untereinander demnach gar nicht. Nur der Master kennt beide Partner.

Ich bekomme es nicht hin, das mit dem rL Eintrag, nicht die Single sich immer was falsches schnappen.
Alle Player sind Single. Ich starte im WZ die Musik, mit der aktuellen Regel werden dann alle Single zu Slave außer dem, der wirklich spielt. Also übernehmen alle die Infos des spielenden. Ist natürlich quark denn in echt spielt ja nur WZ und nicht auch noch Küche usw. ...Der Kopf qualmt