Sonos2mqtt - vielleicht hat jemand Lust mitzumachen

[Otto123]

Den Einwand mit Readings gerade ziehen verstehe ich adHoc nicht 
Der Code im Devstateicon ist dafür (ich weiß es gar nicht mehr genau) - das die Texte nicht doppelt und dreifach erscheinen. Aber das ist so eine bunte Mischung:

Sender, Title, Album, Interpret, Du hörst ... Das sind doch auch Infos die so von Sonos geliefert werden. Und an der Stelle frage ich wieder: Muss man in FHEM wirklich die APP perfekt nachbauen? Oder will man einfach automatisieren.

Sonos2mqtt würde ich so betrachten: der ist nicht für die Gestaltung der Readings in FHEM zuständig

[87insane]

Wenn Du nur diese Einrichtung machst, gibt es kein Cover.
Wenn Du das DevstateIcon nach hier einrichtest - Kommt sofort das Albumcover (wenn es denn existiert). Das DevStateIcon stammt im wesentlichen von Dir. Bei mir funktioniert es so.
Was anderes kann ich ohne Details nicht nachvollziehen. Aber: Alles baut streng auf einer Einrichtung mit den Templates auf und dem MQTT2_Server mit autocreate simpel auf!

Hey hey.. Ich habe das wohl schonmal gesehen Spaß bei Seite.. Irgendwann wurde der Teil mit dem Bild angepasst. Das war der Moment wo ich wenig Zeit hatte. Leider weiß ich nun nicht warum das nun so willkürlich ist. Ggf. S2 vs S1? Die Links selber kann ich im Browser direkt öffnen, wenn ich sie aus dem entsprechendem Uri Reading kopiere....

[Mitch]

Kurzes Feedback: bei mir läuft es nun super stabil und ohne Probleme (inkl. Coverbilder, Speak und abspielen von MP3s).
Das schöne, mein fhem ist seit dem löschen des Sonos Moduls etwas performanter geworden.

[Beta-User]

@Beta-user
Du meinst das Geräte Icon? Da läuft folgender Prozess ab - für jeden Player - beim ersten Anlegen also für xx Geräte quasi parallel:
- über den node sonos2mqtt Dienst werden erweiterte Informationen vom Player angefragt.
- Der Player antwortet 'irgendwann' - insofern läuft der Folgeprozess für jeden Player "irgendwann"
- Aus den Information wird eine URL gebaut und ein XML heruntergeladen. Das wird analysiert und eine ICON Url gebaut.
- das Icon wird lokal geladen, in das Attribute des Players eingetragen.
- damit die neuen Icons sichtbar werden muss rereadicon getriggert werden, das wird so verzögert, das es nur einmal passiert wenn alle Player fertig sind.
- alles habe ich versucht ohne blockieren von FHEM zu machen

Das klingt im wesentlichen ok, wobei die regex mit dem Plus (in der Namens-Ermittlung) evtl. nicht optimal ist (ich bin da erst heute morgen wieder bei einem anderen meiner notify drüber gestolpert... ); evtl. ginge es "einfacher", wenn man den JSON (schon in der bridge?) prüft und dann - sofern IPAddress enthalten ist - das ganze als sub aufruft (oder eben den IP-Inhalten eine Sonderbehandlung im DEVICE gibt). Ggf. müßte/könnte man dann auch checken, ob bzw. welche Aktion überhaupt noch erforderlich ist?

Rein von der Entwicklung her gibt es das Basistemplate und das "comfort" - ja man kann alles in einem machen. Dann auch noch noch das devstateicon.
Aber spätestens hier will ich das alles in eine Utils packen.

Rückmeldungen die zu Fehlerbehebung/Entwicklungen geführt haben gab es bisher von einer (knappen?) Hand voll User. Das ist alles sicher noch nicht perfekt.

Na ja, über mangelnden Zuspuch kannst du dich bei dem Projekt nicht beklagen, oder? 

Grundsätzlich glaube ich, dass es - auch für die Helfer! - einfacher wird, wenn man mal das mit myUtils aufgegleist hat. Der Code selbst ist zwar etwas schwieriger zu verstehen, wenn er "versteckt" ist, aber man kann einfacher "Klone" (einzelner Teile) des Codes erstellen und die dann separat Testen, und das zudem, ohne jedesmal die Konfiguration anzufassen.
In myUtils mit den Hashes rumzumosten, ist halt "etwas abstrakt", aber man gewöhnt sich irgendwann dran. Ging jedenfalls mir so. Zu Beginn war es sehr schwierig, bis mal eines der Beispiele funktioniert hat, aber dann war "das Eis gebrochen"...

[Otto123]

Nein, ich kann und will mich nicht beklagen, aber das Feedback zum letzten Stand ging erst in den letzten Tagen so richtig los. Dabei wurden ja auch ein paar Dinge verbessert gefixt - das ist genau ok! Jetzt kann man mal weiter denken
Du meinst weil das MQTT2_RINCON_[A-Z0-9]+ auf beliebig viele Stellen matched? Ja das kann ich eingrenzen Oder weil es kein NOTIFYDEV gibt? Aber wie bekomm ich das da besser? Mit 17 Punkten - aber ist das wirklich besser?

Zur Performance:
Ich erinnere mich noch gut an meinen Start mit FHEM. Nachdem ich nach einer Anfangsphase SONOS definiert habe, gab es einen "Ruck" im System RAM und CPU Auslastung.

[Beta-User]

Das mit dem NOTIFYDEV war das Thema (wobei ich mir grade nicht sicher bin; das ist doch "hinten", Auslöser ist global, das könnte also doch passen ).

Wie gesagt (falls es überhaut ein "NOTIFYDEV-performance-Problem" gibt...): ich meine, man könnte ggf. direkt auf das notify verzichten, wenn man den JSON (bzw. nach etwas "Sacken lassen" besser direkt den Hash) gleich am Device abgreift (die Abfrage müßte dann wohl aus dem "player-template" kommen) und dann dort die weiteren Schritte veranlasst. Ist aber ggf. in der Tat aufwändiger als das notify mit NOTIFYDEV, wenn ich mir's recht überlege .

[Otto123]

Naja diese regExp gibt es ja in beiden notify. Ja das zweite will ich auch irgendwie "einsparen" / anders wegpacken. Aber das erste folgt meiner Philosophie: Es kommt ein Player (autocreate) und wird konfiguriert. Da möchte ich nicht drauf verzichten.

[kjmEjfu]

Den Einwand mit Readings gerade ziehen verstehe ich adHoc nicht 
Der Code im Devstateicon ist dafür (ich weiß es gar nicht mehr genau) - das die Texte nicht doppelt und dreifach erscheinen. Aber das ist so eine bunte Mischung:

Sender, Title, Album, Interpret, Du hörst ... Das sind doch auch Infos die so von Sonos geliefert werden. Und an der Stelle frage ich wieder: Muss man in FHEM wirklich die APP perfekt nachbauen? Oder will man einfach automatisieren.

Sonos2mqtt würde ich so betrachten: der ist nicht für die Gestaltung der Readings in FHEM zuständig

Ich will die App nicht nachbauen, Himmel!
Aus meiner Sicht unterstützen wir aktuell - für mich - ausreichend Funktionen.

Worauf ich hinaus wollte, wir bauen hier im devStateIcon extra eine Behandlung für currentTrack_Title, weil dort abhängig von der Quelle auch Quatsch drin stehen kann. Wäre aber doch eigentlich sinnvoller, wenn man direkt beim Befüllen des Readings dafür sorgt, dass nicht sowas wie "x-sonosapi-stream" drin steht.
Aber, uns das meinte ich wegen sonos2mqtt, eigentlich sollte sowas gar nicht erst im entsprechenden Topic stehen, sondern der sonos2mqtt müsste das schon bereinigen. So dass man davon ausgehen könnte, das im entsprechenden Topic auch der echte Titel steht - und nicht irgendwelche Urls o.ä.

[Otto123]

Worauf ich hinaus wollte, wir bauen hier im devStateIcon extra eine Behandlung für currentTrack_Title, weil dort abhängig von der Quelle auch Quatsch drin stehen kann. Wäre aber doch eigentlich sinnvoller, wenn man direkt beim Befüllen des Readings dafür sorgt, dass nicht sowas wie "x-sonosapi-stream" drin steht.
Aber, uns das meinte ich wegen sonos2mqtt, eigentlich sollte sowas gar nicht erst im entsprechenden Topic stehen, sondern der sonos2mqtt müsste das schon bereinigen. So dass man davon ausgehen könnte, das im entsprechenden Topic auch der echte Titel steht - und nicht irgendwelche Urls o.ä.

Gebe ich Dir Recht. Ich bin gar nicht sicher: War das mal ein Würgaround von mir und das Problem existiert gar nicht mehr. Oder ich hatte das Problem selbst gebaut. Oder hat das Stephan mittlerweile behoben?

[kjmEjfu]

Gebe ich Dir Recht. Ich bin gar nicht sicher: War das mal ein Würgaround von mir und das Problem existiert gar nicht mehr. Oder ich hatte das Problem selbst gebaut. Oder hat das Stephan mittlerweile behoben?

Ist leider noch immer da.
Hatte das gestern auch als ich Radio (nicht über Sonos Radio) abgespielt habe, da stand im Title auch irgendeine URL-Pfadangabe.
Von daher kommt das so über MQTT rein.

[Otto123]

Es gab ja noch das Thema DevelopmentGuidelinesAV und mehrere Durchsagen - die gleichzeitig eintreffen - aber natürlich nacheinander gespielt werden sollen.
Da habe ich mal was gebastelt:
Das Volume für Durchsagen separat wählen.

Code Auswählen Erweitern

setreading SonosTTS vol 15
und dann ein zusätzlicher setter (für die DEF vom Player Device):

Code Auswählen Erweitern

sayText:textField { my $tts=ReadingsVal('SonosBridge','tts','SonosTTS');my ($cmd,$text)=split(' ', $EVENT,2);fhem("setreading $tts text ".ReadingsVal($tts,'text',' ').' '.$text.";sleep 0.4 tts;set $tts tts [$tts:text];sleep $tts:playing:.0 ;set $NAME notify [$tts:vol] [$tts:httpName];deletereading $tts text")}
Was passiert?

• Der Text wird in ein Reading vom SonosTTS Device geschrieben
• Es wird 0.4 Sekunden gewartet ob weitere Texte kommen (sleep mit id)
• jeder weitere Text innerhalb dieser zeit wird an den Text im Reading angehängt
• der Timer wird zurückgesetzt
• ist der Timer abgelaufen wird der gesamte Text aus dem Reading gelesen, gerendert und als mp3 an das Playerdevice gegeben
• der Text im Reading wird mit einem Leerzeichen gelöscht (da fiel mir keine schöne Lösung ein)

Wer Lust hat zu testen - in der Raw Def starten:

Code Auswählen Erweitern

set alias=Arbeitszimmer sayText Es
set alias=Arbeitszimmer sayText ist
set alias=Arbeitszimmer sayText lustig
set alias=Arbeitszimmer sayText Willi
set alias=Arbeitszimmer sayText lustig. Laber Rabarber.
sleep 0.2;set alias=Arbeitszimmer sayText Zu guter Letzt.

Ich weiß - es wird Zeit dafür den Code auszulagern

Ergänzung: Mir ist aufgefallen, dass längere Texte manchmal abgebrochen werden. Die mp3 Datei ist dabei komplett erzeugt.  Man muss mal irgendwie mit den Parametern des notify Befehls spielen: "timeout":10 "delayMs":700 - wenn man den timeout Wert erhöht (ich habe einfach 100 genommen) wird nicht abgebrochen und andere negative Auswirkungen konnte ich nicht feststellen.  Mir ist die genaue Wirkung nicht wirklich klar geworden. Siehe auch.

timeout: 10, // If the events don't work (to see when it stops playing) or if you turned on a stream, it will revert back after this amount of seconds.
    ...
    delayMs: 700 // Pause between commands in ms, (when sonos fails to play sort notification sounds).

[kjmEjfu]

der Text im Reading wird mit einem Leerzeichen gelöscht (da fiel mir keine schöne Lösung ein)

spricht etwas dagegen das Reading einfach zu löschen? Wäre doch eine saubere Lösung. Wobei ich das Reading, weil es ein temporäres ist, vorne um einen "_" o.ä. ergänzen würde.
Alternativ überlege ich gerade, ob man für diese Funktionalität nicht leichter ein DOIF (mit set_exec) nutzen könnte. Aber dann muss man natürlich wieder ein weiteres Gerät anlegen, auch doof.


Grundsätzliche Frage: für Speak gibt es aktuell ja zwei Variante. Entweder die über Text2Speech oder die über sonos-tts-polly. Macht es Sinn, wenn wir da ein Attribut für zur Verfügung stellen, damit der Anweder darüber auswählen kann, welche Variante er nutzt? Denn darüber würde sich ja unterscheiden, ob man den Payload an ein Text2Speech schickt (und dann per notify weiter) oder den Payload auf sonos/cmd/speak ablegt.
Und ja, dann sind wir wieder beim beliebten Thema auslagern

[Otto123]

Man kann das Reading auch löschen, mein gedanklicher Entwicklungsweg war etwas im ZickZack deswegen ...
Im Normalfall sieht man es nicht, klar kann man da einen Zusatz nehmen.

DOIF - nein bitte nicht!  - aber kann ja jeder machen wie er will

Der Anwender kann ja nicht wirklich Speak "wählen" - er muss sich was "einrichten" und das mehr oder weniger aufwendig. Aber klar der Zugriff auf den "MP3 Server sollte ich noch konfigurierbar machen.
sonos/cmd/speak ist doch der Spezialfall "An Alle" - aber ich habe mich mit der integrierten Variante auch noch nicht wirklich beschäftigt.

[kjmEjfu]

Der Anwender kann ja nicht wirklich Speak "wählen" - er muss sich was "einrichten" und das mehr oder weniger aufwendig. Aber klar der Zugriff auf den "MP3 Server sollte ich noch konfigurierbar machen.
sonos/cmd/speak ist doch der Spezialfall "An Alle" - aber ich habe mich mit der integrierten Variante auch noch nicht wirklich beschäftigt.

Ja, du hast Recht. Ich habe falsch geschaut.

Der Speak, wenn man das sonos-tts-polly nutzt, ist derzeit so hinterlegt:

Code Auswählen Erweitern

speak:textField { my (undef, $lang, $voice, $volume, @text) = split(/ /, $EVENT); sprintf($DEVICETOPIC.'/control {"command":"speak","input":{"lang": "%s", "name":"%s", "volume":%s, "text": "%s","delayMs":700}}', $lang, $voice, $volume, join(" ", @text))}

Vorschlag: wir führen folgende Attribute ein:

- SpeakMethod:FHEMtts,SonosPolly
- SpeakTTSDevice (wäre dann nur im FHEMtts-Fall zu setzen)

Dann könnten wir zwischen den beiden unterscheiden und den Aufruf entsprechend wählen.


Wegen Auslagern wäre es toll, wenn jemand mit Erfahrung einen Rumpf vorschlägt. Wenn ich da was bastele, dann ist das vor allem viel Copy&Paste (ohne es im Detail zu verstehen) und auf Scripting-Niveau.

[Otto123]

Ich habe mal den Code oben noch editiert und etwas verbessert

auf Scripting-Niveau.

Da bilden wir schonmal ein Team
Also ich habe schon ein paar Gedanken, ich muss mich jetzt erstmal der Martinsgans widmen. Ich bringe das dann mal "zu Papier"