Sonos2mqtt - vielleicht hat jemand Lust mitzumachen

[87insane]

Sieht eher aus wie falsch benutztes speak...

Syntax ist
<volume><Text>
Beispiel:
50 Hallo Welt!

[kjmEjfu]

Sieht eher aus wie falsch benutztes speak...

Syntax ist
<volume><Text>
Beispiel:
50 Hallo Welt!

bei mir?
Leider nein, speak funktioniert mittlerweile einwandfrei und ohne Eintrag im Log.
Der Fehler erscheint alleine beim notify, weshalb auch immer.

[kjmEjfu]

Ich stolpere gerade noch über eine andere Frage, eher grundsätzlicher Art.

Das sonos2mqtt_speaker Template, setzt das Topic in readingList und setList ja fix.
Was spricht dagegen Attribut devicetopic zu nutzen?
Dann kann man $DEVICETOPIC nutzen und ist bei Copy&Paste fein raus, insbesondere wenn man neue Set-Befehle austauscht.

[FunkOdyssey]

@kjmEjfu
Ganz nebenbei: Du nutzt doch nun auch den sonos-polly-tts-Container, oder?
Wie sieht denn aktuell dein speak-Setter aus. Dieser dürfte doch anders aufgebaut sein, wie das speak über das TTS-Modul.

Code Auswählen Erweitern

set MQTT2_RINCON_xxxxx speak de-DE Vicki 25 Dies ist ein Test

[kjmEjfu]

@kjmEjfu
Ganz nebenbei: Du nutzt doch nun auch den sonos-polly-tts-Container, oder?
Wie sieht denn aktuell dein speak-Setter aus. Dieser dürfte doch anders aufgebaut sein, wie das speak über das TTS-Modul.

Code Auswählen Erweitern

set MQTT2_RINCON_xxxxx speak de-DE Vicki 25 Dies ist ein Test

sieht identisch aus. Habe mich dabei an die setList-Erweiterung von https://forum.fhem.de/index.php/topic,111711.msg1079176.html#msg1079176 gehalten.


Ich habe mal übrigens zwei Befehle aus dem Sonos-Modul nachgebaut (dafür muss zwingend das Attribut devicetopic gesetzt sein):

Code Auswählen Erweitern

VolumeSave:textField { my $valueold = ReadingsVal("$NAME", "volume", "00"); my ($cmd,$valuenew)=split(' ', $EVENT,2); $valuenew += $valueold;fhem "setreading $NAME volumeSave $valueold"; qq($DEVICETOPIC/control { "command": "volume", "input": $valuenew } ) }

VolumeRestore:noArg { my $value = ReadingsVal("$NAME", "volumeSave", "00"); fhem "deletereading $NAME volumeSave"; qq($DEVICETOPIC/control { "command": "volume", "input": $value } ) }

Wobei das beim Save aktuell nur der relative Teil ist. Wenn das noch jemand mit mehr Perl KnowHow gemäß "Setzt die Lautstärke auf den angegebenen Wert. Der kann eine relative Angabe mittels + oder - sein. " anpassen kann, wäre auch toll.

[87insane]

Hab auch zwei angepasste Setter, die gehen aber sauber...

Code Auswählen Erweitern

playWC:noArg {fhem("set $NAME playSound 50 musik.mp3; sleep $NAME.STOPPED; set $NAME setAVTUri 'x-sonosapi-stream:s25260?sid=254&flags=8224&sn=0'; sleep $NAME:currentTrack_TrackUri:.x-sonosapi-stream.*; set $NAME play")}
  stopWC:noArg {fhem("set $NAME stop; sleep 1; set $NAME playSound 50 musik_aus.mp3")}

In deinem notify ist jedenfalls laut LOG auch nichts gelandet und deswegen auch der "Fehler". Es wird eben was anderes erwartet als ankommt.

Da die beiden auch notify nutzen, ohne Probleme... Was genau versuchst du?

[kjmEjfu]

In deinem notify ist jedenfalls laut LOG auch nichts gelandet und deswegen auch der "Fehler". Es wird eben was anderes erwartet als ankommt.

Da die beiden auch notify nutzen, ohne Probleme... Was genau versuchst du?

Ich versuche das Beispiel aus dem Wiki wegen der Klingel nachzubauen (https://wiki.fhem.de/wiki/Sonos2mqtt#Spiele_feste_Sounds)

Nachdem ich jetzt den Sonos Docker neu durchgestartet habe, funktioniert es. Mysteriös.

[87insane]

Wollt schon sagen. Hab die gerade nebeneinander gelegt. Identisch. Na dann ist ja alles gut. Würde die schelle aber tatsächlich über ein mswitch/notify/doif laufen lassen. Besser als in jeden Gerät einzeln. Dazu kannst du einfach die Geräte bei Bedarf anpassen.
Bei klingeln zb 3mal Sonos und 2 mal alexa. Je nachdem was an ist.

[kjmEjfu]

es ging mir erstmal nur um die reine Funktion

Eigentlich würde ich das sonos2mqtt gerne so mit msg nutzen können wie vorher das "normale" Sonos. Denn kann ich wieder meine gewohnten Automatismen nutzen.
Hab dazu schon mal in https://forum.fhem.de/index.php/topic,39983.msg1094284.html#msg1094284 nachgefragt.

[Otto123]

Die Verwendung von $EVTPARTx ist nicht Fehlertolerant und nur für Q&D Lösungen. Wenn man das ordentlich machen will muss man $EVENT selbst behandeln und auswerten.

@87insane Ich weiß nicht ob Du das mitbekommen hattest: Aus meiner Sicht wichtiger als den kompletten Service steuern ist mMn sowas hier:

Code Auswählen Erweitern

attr SonosBridge setList PauseAll:noArg sonos/cmd/pauseall\
CheckSubscription:noArg sonos/cmd/check-subscriptions

Hatte Stephan in die letzte Version eingebaut. Mit checkSubscription wird der Neustart des Service fast obsolete.

[kjmEjfu]

Die Verwendung von $EVTPARTx ist nicht Fehlertolerant und nur für Q&D Lösungen. Wenn man das ordentlich machen will muss man $EVENT selbst behandeln und auswerten.

hab es umgebaut.

Jetzt muss ich "nur" noch schauen, wie ich erkenne, ob ein Vorzeichen dabei ist oder nicht. Aber man wächst mit seinen Aufgaben

Neue Version:

Code Auswählen Erweitern

VolumeSave:textField { my $valueold = ReadingsVal("$NAME", "volume", "00"); my ($cmd,$valuenew)=split(' ', $EVENT,2); if ($valuenew =~ m/^[+-]{1}/) { $valuenew += $valueold; }; fhem "setreading $NAME VolumeStore $valueold"; qq($DEVICETOPIC/control { "command": "volume", "input": $valuenew } ) }
VolumeRestore:noArg { my $value = ReadingsVal("$NAME", "VolumeStore", "00"); fhem "deletereading $NAME VolumeStore"; qq($DEVICETOPIC/control { "command": "volume", "input": $value } ) }

[kjmEjfu]

Zwei Fragen:

1: @Otto123 (oder jemand anderes): kannst du mir was zu https://forum.fhem.de/index.php/topic,111711.msg1094308.html#msg1094308 sagen? Ich finde tatsächlich, wenn man auf DEVICETOPIC gerade ziehen würde, erspart das später einiges an Problemen von "blinden" Copy&Paste'lern.

2: kann man den Ausbau der SetList auch irgendwie auslagern? Ich habe die Befürchtung, wenn man recht viel der coolen und sinnvollen Funktionen des normalen Sonos-Moduls nachbaut, dann wird das Attribut arg unübersichtlich und lang.

[Otto123]

Moin,
zu 1.

"blinden" Copy&Paste'lern.

die gehören eh verboten
Dadurch, das eigentlich alles per Template gesetzt wird und das andere momentan Entwicklung ist, sehe ich das erstmal nicht so als Vorteil. Mann muss ja irgendwas erstmal setzen: entweder ändert man den Namen (default) oder man setzt das attr devicetopic.

Zu 2. Um das ganze irgendwie lesbar zu machen, kann man einfach eine Perlfunktion in die 99_myUtils.pm auslagern. da steht dann in der Setlist nur noch sowas

Code Auswählen Erweitern

VolumeSave:textField {sonos2mqtt(VolumeSave,$EVENT)}Besser ist sicher eine 99_sonos2Utils.pm mit auszuliefern.

Entwicklung ...

Gruß Otto

[87insane]

@Otto123: Komplett stecke ich nicht wieder drin aber das hatte ich gelesen nur noch nicht verstanden wofür es genau ist. Aber das wird sich ja nachlesen lassen.

Was mir auffällt ist das Sprachdurchsagen mit anschließendem STOP oder PLAY echt ne Kunst sind. Je nachdem wie MQTT die Infos sendet...
Anbei mal meine Lösung. ggf. geht es ja besser

Code Auswählen Erweitern

  playWC:noArg {my $avturi="x-sonosapi-stream:s25260?sid=254&flags=8224&sn=0"; fhem("set $NAME playSound 50 musik.mp3; sleep $NAME.STOPPED; sleep $NAME.PLAYING; sleep $NAME.STOPPED; set $NAME setAVTUri $avturi; sleep $NAME:currentTrack_TrackUri:.x-sonosapi-stream.*; set $NAME play")}
  stopWC:noArg {fhem("set $NAME stop; sleep $NAME.STOPPED; set $NAME playSound 50 musik_aus.mp3")}

Besonders schlimm ist wenn man einen Radiosender hört/streamt, "Musik aus" ansagen lassen will und danach direkt einen stop will.
Dann spielt der Player gerne mal nach der Ansage einfach wieder den Stream vom Radio. Ich habe es nur so hin bekommen wie oben, um auch halbwegs schnell zu reagieren. Ein paar Antworten zuvor hatte ich bereits ein Beispiel gepostet - dieses ist aber viel zu langsam und funktioniert nicht immer. Das hier geht zumindest immer und ist halbwegs schnell. (das Transcodieren des Streams, lässt sich ja schlecht kürzen)

PS: Wer sich fragt wofür ich das nutze... Hab am WC einen Taster. Longpush macht nicht nur Licht, sondern auch Musik mit an.

EDIT: Bei aktivem event-on-change ist das Verhalten von state beim starten des streams anders.... (hier muss das sleep $NAME.STOPPED; am Anfang weg). Aber das beschleunigt den Fall nur also kann es in meinen Augen generell weg.

Code Auswählen Erweitern

playWC:noArg {my $avturi="x-sonosapi-stream:s25260?sid=254&flags=8224&sn=0"; fhem("set $NAME playSound 50 musik.mp3; sleep $NAME.STOPPED; sleep $NAME.PLAYING; sleep $NAME.STOPPED; set $NAME setAVTUri $avturi; sleep $NAME:currentTrack_TrackUri:.x-sonosapi-stream.*; set $NAME play")}

Ach ja... das Verhalten als sleep zu nehmen ist in meinen Augen etwas schöner als Zeiten. ABER ich finde keine gute oder wirkliche Doku zu den .sleep Verhalten. Kann mir das einer mal kurz nahe bringen? Danke!

Gruß,
87Insane

[kjmEjfu]

Besser ist sicher eine 99_sonos2Utils.pm mit auszuliefern.

Entwicklung ...

wobei es da vermutlich fast schon interessanter wäre, die bestehende 21_SONOSPLAYER.pm anzupassen und im Fall von model=sonos2mqtt_speaker die Befehle nicht an den Subprocess, sondern per MQTT zu schicken.