Sonos2mqtt - vielleicht hat jemand Lust mitzumachen

[Otto123]

Irgendwie und jedes Protokoll geht eben nicht!
Schau doch was Sonos in der App an lesbaren Freigaben unterstützt - aus meiner Sicht nur SMB (1.0)

Man schickt ja nicht die Datei zu Sonos man sendet Sonos die Info wo er die Datei lesen kann.

Da geht aus meiner Sicht nur HTTP oder SMB.

Ob FTP geht habe ich nie probiert - ist aber für mich auch bäh. Würde ich also gar nicht versuchen.

Was auch geht ist ein "DLNA Befehl" - aber das ist anders als das notify was sonos2mqtt kann. Das beendet das aktuelle Play vom Player, wirft ihn aus der Gruppe, gibt den Titel wieder und dann ist Schluss. Also auch unbrauchbar, ganz davon abgesehen das ich nicht weiß wie.

Es gibt damit aus meiner Sicht zwei gangbare Lösungen:
TTS von Stephan (mit Bier ) oder Text2Speech und SMB Share.

Und Windows Protokoll hin und her, das ist mittlerweile in der Linux Community lange angekommen. Das wird seit Jahren intensiv entwickelt und untersucht - ich weiß nicht ob sich so viele mit der Sicherheit und Zuverlässigkeit bei DLNA beschäftigen. Peinlich ist, das Sonos es nicht schafft eine aktuelle Version zu unterstützen 

[87insane]

Stimme im Großen zu...!

Aber HTTP ist doch schon super. Nur lesbar und sonst nix. Naja ich finde gut das er das anbietet aber wenn man es selber bauen kann, dann will ich vorher scheitern 

[kjmEjfu]

Es gibt damit aus meiner Sicht zwei gangbare Lösungen:
TTS von Stephan (mit Bier ) oder Text2Speech und SMB Share.

Aber die Variante von Stephan gibt es doch für einen selbst: https://github.com/svrooij/node-sonos-tts-polly#run-your-own-server (sogar als Docker-Container)

[Otto123]

Ja ich weiß - mein Lapsus: es gibt 1.a und 1.b

[87insane]

Habs hinbekommen mit dem Aktuell halten des Stati bei (aktuell) allen RINCON_ Geräten. (Baue noch einen besseren filter. Bitte gern auch [umsetzbare] ideen)
Ohne großen Hick Hack mit Arrays (die ich im übrigen hasse wie sonst was. Brauche echt mal jemand der mir das gut und in meiner Sprache erklärt).

Nun triggert der Master in einer Gruppe den State von allen rincon_ geeäten. So brauch man kein F5 oder so mehr drücken!
Was noch kommt:
- Icons müssen angepasst werden damit der Slave nicht auch z.B. VolUp anzeigt obwohl es nur am Master passiert
- Wenn ich das mit dem Slider hin bekomme, wird es einen sauberen Gruppen Vol Slider geben
- Es wird noch ein leave Group Button hinzu kommen. Brauchte ich immer wieder und ist praktisch
- ich überlege ein automatisches Auswahlmenü zu erstellen für joingroup. Das sollte machbar und relativ einfach sein.

Anbei das devStateIcon:

Code: [Auswählen]

{
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 = ReadingsVal($name,"enqueuedMetadata_UpnpClass","FEHLER") ne "object.item.audioItem.audioBroadcast"
? "$show Aktueller Track: $currentTrack<br>Nächster Track: $nextTrack"
: "$show Radio: $currentTrack";}

elsif (ReadingsVal($name,"name","0") ne $groupname) {
$show = "$show
Master: $sgroupname";}

} else {
if ($name eq $uuidtoname) {
if (ReadingsVal($name,"name","0") ne $groupname) {
fhem("trigger .*:FILTER=uuid=RINCON_.* state");
}
$show = "<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($playpic)."</a>";
} else {
$show = "<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>"
}
Da ich im Ausland bin und sehr schlechten Empfang ist das nur grob getestet.


EDIT: Code nochmal angepasst. Es war ein Fehler drin, der dafür sorgte das im Kreis getriggert wurde. Ist nun behoben...

[Otto123]

@Beta-User
Eigentlich eine allgemeinere Frage, aber da der use-case erstmal hier ist: Ist es legitim auf die Art ein Template zu machen welches eine setList erweitert? Oder erschlägst Du mich für die Idee? Oder ist das besser gelöst und ich habe es nicht gefunden?

Der Code ist jetzt reduziert auf das Minimum - aber ich würde dort gern weiter machen: Gerade jetzt im Aufbau/Entwicklung wäre es mir lieb die Templates etwas modular zu machen. Am Ende dann eines was alle Fälle abdeckt (eventuell den Player erkennt usw). Du musst das so nie einchecken
Funktionieren tut es

Code: [Auswählen]

#
name:sonos2mqtt_speakCommand1
{\
  my $nn='DEVICE';\
  my @arr=split("\n",AttrVal($nn,'setList',''));\
  push @arr , q(  speak:textField { my $tts="SonosTTS";my $payload = $EVENT;$payload =~ s/$EVTPART0 $EVTPART1 //g; fhem("setreading $tts Player $NAME;setreading $tts volume $EVTPART1;set $tts tts $payload");"{}"});\
  my $newVal=join "\n",@arr;\
  $newVal=~s/;/;;/g;\
  fhem("attr $nn setList $newVal")\
}

[Beta-User]

Na ja, in die Richtung funktionieren schon einige der attrTemplate, nur eben meistens weniger bezogen auf die Erweiterung eines Attributs...

Ein paar Anmerkungen:
- Da ist ein bestimmter Name "SonosTTS" hartvercoded, der nicht in allen Installationen so vorhanden sein muß. Wenn es z.B. via devspec machbar ist, ein bestimmtes Device zu ermitteln, ist es mMn. besser, daraus eine par:-Zeile abzuleiten (=> die Sprachsteuerungstemplates machen das z.B. so);
- Der Perl-Code macht da ein paar Transformationen, die mir "suspekt" sind, v.a. das mit dem Verdoppeln der ";" - das wirkt sich ja auch auf alle vorhandenen Einträge aus. Zu viele (paarige) SeMiCoLoN sind zwar in der Regel unschädlich, aber nötig ist das nur, weil der neue Eintrag nicht gleich "richtig" geschrieben wurde, oder?
- Ob man erst splittet und dann wieder join macht oder (ungetestet) ein schlichtes concat, beginnend mit "\n  ", ist eine Philosophiefrage. Ich würde es eher einfach halten, wenn's geht...

[87insane]

Parallel zu dem Thread kämpfe ich mit der Extraktion der JSONs für die ReadingList: https://forum.fhem.de/index.php/topic,112737.msg1070639.html#msg1070639

@Otto123: Eine Veränderung der setList bringt doch ein "Save" mit sich oder kann man das "ausblenden"?
Für mich ist eine klickbare Option, die mir eine Struktur-Änderung in FHEM mit bringt, nicht so dolle. Ich bin noch einer von den verrückten, da darf auf dem iPhone/Androiden (um die Diskussion dazu zu unterdrücken einfach beides) auf keinen Fall eine 1 oder so auf dem Bildschirm sein... Das wäre so zu sagen eine unerledigte Aufgabe :-P

Aber um das zu betonen. Sehr schön das du dich so in die Sprachsteuerung hängst! Danke! Finde es gut das hier wirklich Modular abgearbeitet werden. Auch wenn es keine Reihenfolge gibt, macht hier jeder eine schöne Ecke und das ist super!

Versuche aktuell devStateIcon kleiner zu bekommen und auch sinniger. Dazu aber die readingList auch endlich mal sauber zu machen.... Lerne gerade aber dadurch auch wieder einige neue Dinge kennen und bin damit natürlich erstmal am kämpfen....

[Otto123]

Ich weiß SonosTTS hart vercoded. Ich würde da die komplette Einrichtung reinpacken. Und ehrlich an der Stelle erstelle ich eine extra Instanz dafür, ob die jeder per C&P erzeugt oder ich gleich Fakten mit Namen mache? Aber mal sehen.

Das mit den Arrays: Ja erscheint kompliziert, kommt daher, dass ich ursprünglich komplizierter gedacht habe. Aber ein concat wird auch nicht kürzer

Das mit den Semikolons:
BTW: Da ist mir attrTemplate an sich noch suspekt. Es hat den Syntax wie Raw Def (Zeilenenden) aber die Semikolon müssen im Code direkt nicht verdoppelt werden.
Anders beim perl Code im fhem("attr...") Befehl, der wandert in den Interpreter/Parser und da müssen sie verdoppelt werden. Ich lese ja die setList aus, ergänze und schreibe zurück. Das bedeutet im vorhandenem (ausgelesenem) und neuen Code müssen die semikolon verdoppelt werden.

@insane set attrTemplate ... an sich bringt ein rotes Fragezeichen mit sich, also ist alles konsequent

[87insane]

achso...du meinst einmalig und nicht immer wieder...

[Otto123]

Hallo Mitstreiter,

Nach dem es etwas ruhig geworden ist, würde ich gern mal einen Stand erzeugen, der irgendwie an den Mann gebracht werden kann.
Das jetzige Template für die speaker und line_in_speaker gefällt mir nicht. Es erzeugt vor allem bezüglich des devStateIcon einen "komischen Stand"
Da wir mit dem devStateicon noch beim entwickeln sind würde ich dies einfach erstmal weglassen.
Mein Idee wären ein paar inkrementelle Templates die man irgendwann nochmal revidieren kann.

Vorschlag:

• das Template linein_speaker löschen.
• bridge bleibt wie sie ist
• Template speaker durch dieses ersetzen:

Code: [Auswählen]

name:sonos2mqtt_speaker
desc:A basic sonos2mqtt speaker device
filter:TYPE=MQTT2_DEVICE
order:M_05b
par:BASE_TOPIC;base topic set in configuration.yaml of the sonos2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^\/:]+)[\/].+, ? $1 : undef }
par:DEV_ID;techname of the device ;{ AttrVal("DEVICE","readingList","") =~ m,[^\/]+[\/](RINCON_[0-9A-Z]+):.*, ? $1 : undef }
par:ALIAS;friendly name as set in sonos gadget itself;{ ReadingsVal("DEVICE","name","unknown") }
par:DEVNAME;friendly name, used for topic in lowercase;{ lc(ReadingsVal("DEVICE","name","unknown")) }
par:ICON;ICON as set, defaults to audio_volume_low;{ AttrVal("DEVICE","icon","audio_volume_low") }
attr DEVICE icon ICON
attr DEVICE jsonMap volume_Master:volume mute_Master:mute transportState:state
attr DEVICE readingList\
  BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE setList\
  stop:noArg BASE_TOPIC/DEV_ID/control { "command": "stop" }\
  play:noArg BASE_TOPIC/DEV_ID/control { "command": "play" }\
  pause:noArg BASE_TOPIC/DEV_ID/control { "command": "pause" }\
  toggle:noArg BASE_TOPIC/DEV_ID/control { "command": "toggle" }\
  volumeup:noArg BASE_TOPIC/DEV_ID/control { "command": "volumeup" }\
  volumedown:noArg BASE_TOPIC/DEV_ID/control { "command": "volumedown" }\
  volume:slider,0,1,100 BASE_TOPIC/DEV_ID/control { "command": "volume", "input": $EVTPART1 }\
  mute:on,off { my $value = $EVTPART1 eq "on" ? "mute" : "unmute"; qq(BASE_TOPIC/DEV_ID/control { "command": "$value" } ) }\
  next:noArg BASE_TOPIC/DEV_ID/control { "command": "next" }\
  previous:noArg BASE_TOPIC/DEV_ID/control { "command": "previous" }\
  joinGroup:textField BASE_TOPIC/DEV_ID/control { "command": "joingroup",  "input": "$EVTPART1"}\
  leaveGroup:noArg { my $value = ReadingsVal("DEV_ID","groupName","all"); qq(BASE_TOPIC/DEV_ID/control { "command": "leavegroup",  "input": "$value" } ) }\
  setAVTUri:textField BASE_TOPIC/DEV_ID/control { "command": "setavtransporturi",  "input": "$EVTPART1"}\
  playUri:textField {fhem("set $NAME setAVTUri $EVTPART1; sleep 1; set $NAME play")}\
  switchtoqueue:noArg BASE_TOPIC/DEV_ID/control { "command": "switchtoqueue" }\
  notify:textField BASE_TOPIC/DEV_ID/control { "command":"notify","input":{"trackUri":"$EVTPART2","onlyWhenPlaying":false,"timeout":10,"volume":$EVTPART1,"delayMs":700}}\
  x_raw_payload:textField { my $payload = $EVENT;$payload =~ s/$EVTPART0 //g; qq(BASE_TOPIC/DEV_ID/control $payload)}
attr DEVICE model sonos2mqtt_speaker
attr DEVICE alias ALIAS
Die alte Idee, dass die drei switchto_xx irgendwie "zusammen" gehören, ist mMn falsch.

• switchtoqueue gehört zu jedem Speaker
• switchtotv gehört zu den Geräten mit spdif Eingang (Soundbars)
• switchtoline gehört zu den Geräten mit analogem Eingang (Play5)

Mein Ziel, Player abfragen und MQTT2_ Device weiter konfigurieren.

Den Typ und die Ausstattung kann man abfragen, da bin ich gerade dabei. Dieses Kommando über x_raw_payload liefert u.a. IPAdresse zurück.

Code: [Auswählen]

{
  "command": "adv-command",
  "input": {
    "cmd": "GetZoneInfo",
    "reply": "ZoneInfo"
  }
}Über http://IPAdresse:1400/xml/device_description.xml bekommt man ein Konfigurations Dokument. Dort kann man weitere Dinge abfragen. Vielleicht geht das aber auch direkt über sonos2mqtt adv Kommandos.

Das devStateIcon könnte man jetzt auch mal mit einem vertretbaren Stand als Zusatz Template veröffentlichen. Vielleicht auch eine 99_mySonos.pm ausliefern?
Das Speak Kommando würde ich derzeit auch über einen Zusatz Template oder Anleitung machen. Da gibt es ja sowieso unterschiedliche Ansätze.

Die Basis: Bridge und Device - ist eigentlich auf einem guten Stand. Das würd ich gern "rausbringen". Beide habe ich jetzt relativ umfassend getestet.
Das Grundsetup ist auch klar, das kann man in wenigen Sätzen beschreiben (Gerüst).

• nodejs installieren
• sonos2mqtt installieren
• Bridge in FHEM definieren und mit Template konfigurieren
• sonos2mqtt starten und Device anlegen, danach mit Templates konfigurieren
• Nach Bedarf Sprachausgabe
• Nach Bedarf weitere Konfig

Den Rest kann man noch ein wenig entwickeln und verschönern.

Gruß Otto

[Beta-User]

Vorab:
Das sieht durchdacht aus, ich schiebe ins svn, was ihr mir zuruft (=> demnächst kommt dann also dieser Vorschlag als nächste Iteration).

Die Erweiterungen ggf. über addon-Templates zu machen, finde ich zielführend, gibt sicher mehrere Varianten, wie man das umsetzen könnte.

myUtils zu verwenden, dürfte angesichts der Komplexität diverser Codes (zu devStateIcon etc.) angebracht sein. Mir stellt sich dann nur die Frage, ob das dann gleich in ein eigenes package wandern sollte. Meine Tendenz: ja.

Was "switchto..." angeht: Es wird der input gewechselt, oder? Das spräche für mich dafür, das auch so zu benennen, dann aber eben nur die Auswahl anzubieten, die jeweils vorhanden ist, also "input:queue,lineIn" bzw. "input:queue,spdif" (wording ungeprüft). Aber auch da gilt: Ihr entscheidet.

[partly OT1]
Mir fehlt immer noch die Info, was ein sich abmeldender Speaker an JSON wohin sendet, also wenn er unter einen Master geht (https://forum.fhem.de/index.php/topic,112737.msg1071556.html#msg1071556).

[OT2]
Was Doku (Wiki) angeht, wird es insgesamt lustig und Zeit für...
- Das hier sprengt dann vermutlich auch den Rahmen der "Praxisbeispiele", es wäre dann aber demnächst an der Zeit, dazu eine "Baustelle" aufzumachen und (ähnlich ebus) aus den Praxisbeispielen raus zu verlinken? (Freiwillige?!?)
- OpenMQTTGateway erfreut sich auch einer zunehmenden Beliebtheit, mit dem stub in "MQTT" bin ich aber auch nicht glücklich. Eigentlich sollte man damit ähnlich verfahren (werde ich wohl bei Gelegenheit übernehmen, falls sich niemand vordrängt; da habe ich wenigstens Hardware...)
- tasmota2zigbee ist auch so eine neue Lösung, die wir irgendwie koordiniert unterbringen sollte, bevor es jemand "igendwohin" tut (ohne deutlich darauf hinzuweisen, dass das eine Lösung für max. 13 (?) Geräte ist). Habe aber weder Veranlassung noch große Lust, dazu Hardware zu verstöpseln und das auszutesten (template-mäßig dürfte das (hoffentlich) eine eher kleine Übung werden).

[Otto123]

Was "switchto..." angeht: Es wird der input gewechselt, oder? Das spräche für mich dafür, das auch so zu benennen, dann aber eben nur die Auswahl anzubieten, die jeweils vorhanden ist, also "input:queue,lineIn" bzw. "input:queue,spdif" (wording ungeprüft). Aber auch da gilt: Ihr entscheidet.

Ja das ist ein Argument ich habe vielleicht zu simpel gedacht.
Ich liefere einen Vorschlag
die Zeile mit switchtoqueue raus und die rein ?

Code: [Auswählen]

  input:Queue { my $value = $EVTPART1 eq "TV" ? "tv" : $EVTPART1 eq "Line_In" ? "line" : "queue"; qq(BASE_TOPIC/DEV_ID/control { "command": "switchto$value" } ) }\
Wäre quasi die Vorbereitung zur Erweiterung auf Queue,TV usw.

BTW: Line_In ist komplizierter - da kann man jeden Line_In jedem Player zuweisen. Bei TV geht das nicht!

[Beta-User]

Hab's jetzt mal so eingecheckt (mit der neuen Queue-Fassung).

Das mit line_in habe ich noch nicht verstanden. Bedeutet das, dass jeder Player seinen analogen Input an einen anderen Player weiterleiten kann?
Ansonsten wäre die Frage, ob man das "2. Ding" als "external_Source" (Arbeitstitel) kennzeichnet und dann anhand eines Readings entscheidet, ob man das dann in dem Perl-Code als line_in oder spdif interpretiert? (Setzt halt voraus, dass wir erkennen können, mit welchem Model wir es zu tun haben. Ggf. könnte man dazu aber auch ein userAttribut generieren (mit Perl?) und das dann auswerten?)

[TomLee]

Du pochst darauf sich an die DevelopmentGuidelinesAV zu halten und änderst jetzt volumeUp/Down wieder auf Kleinschreibung, bewusst ?