Sonos2mqtt - vielleicht hat jemand Lust mitzumachen

[Otto123]

Das ist sicher ne andere Nummer...

Auslagern kann auch bedeuten: Template weiter pflegen und die config nicht angucken

[Beta-User]

Es wäre vermutlich schon möglich, den Code von SONOSPLAYER aufzubohren und aus dem einen weiteren Client für die MQTT2_IO's zu bauen. Die Frage ist aber dann, wie das im Ergebnis dann leicht gepflegt werden kann.
Nach meinen Erfahrungen mit einem "eigenen" MQTT-Modul (für MiLight) und auch der jüngsten Rückmeldung von pah bzgl. des rooba-Dinges würde ich meinen, dass eine relativ offene Lösung bestehend aus einem "einfachen" MQTT2_DEVICE + myUtils-Code die einfacher zu pflegende Variante ist. Hat zwar den Nachteil, dass es relativ offen ist und ein User auch schon mal "Mist" bauen kann, wenn er Attribute löscht, aber via attrTemplate+myUtils-contrib-Code ist das dann recht einfach und standardisiert behebbar.


@(v.a.) Otto:
Falls du mit myUtils-Code einsteigen willst, würde ich dir dringend ans Herz legen, das ganze dann gleich in ein package einzubetten, Vorlage wäre dann https://svn.fhem.de/trac/browser/trunk/fhem/contrib/AttrTemplate/99_attrT_ZWave_Utils.pm.
Eventuell wäre es auch eine gute Idee, die gesamte JSON-Verarbeitung ebenfalls über eine myUtils-Funktion abzubilden. Ich bin da zwar selbst (effektiv&getestet) noch nicht besonders weit vorgedrungen, aber gedanklich schwebt mir sowas vor wie "milight_to_shutter2()" aus https://github.com/rejoe2/FHEM/blob/master/99_myUtils_MiLight.pm. Die (Beispiel-)Funktion (konkret: milight_to_shutter2($name,$EVENT)) sollte dann statt json2NameValue() die Payload entgegennehmen und gleich intern die passenden Readings "machen" und die Timer anschubsen, die derzeit über das notify laufen...
(Den Beispielcode sollte ich mal dringend testen, das ist bisher nur graue Theorie und war low prio.)

[kjmEjfu]

Es wäre vermutlich schon möglich, den Code von SONOSPLAYER aufzubohren und aus dem einen weiteren Client für die MQTT2_IO's zu bauen. Die Frage ist aber dann, wie das im Ergebnis dann leicht gepflegt werden kann.
Nach meinen Erfahrungen mit einem "eigenen" MQTT-Modul (für MiLight) und auch der jüngsten Rückmeldung von pah bzgl. des rooba-Dinges würde ich meinen, dass eine relativ offene Lösung bestehend aus einem "einfachen" MQTT2_DEVICE + myUtils-Code die einfacher zu pflegende Variante ist. Hat zwar den Nachteil, dass es relativ offen ist und ein User auch schon mal "Mist" bauen kann, wenn er Attribute löscht, aber via attrTemplate+myUtils-contrib-Code ist das dann recht einfach und standardisiert behebbar.

meine Idee bzgl. aufbohren war, dass man die ganzen Funktionen aus SONOSPLAYER "einfach" weiter nutzen muss. So würde man ja (mindestens) einen Teil nachbauen und damit teilweise auch doppelten Code erzeugen. Finde ich nicht so elegant.
Warum ist mir wichtig, dass die Befehle vom SONOSPLAYER weitgehend vorhanden sind? Weil dann der Umstieg sehr viel leichter ausfällt. Bestehende Automatismen müssen nicht angefasst werden, man legt nur die neuen Devices an, löscht die alten und benennt die neuen um.

Aber ich gestehe, ich habe die Diskussion zu MiLight und Roomba nicht verfolgt.

[Beta-User]

Na ja, ziemlich vorne in diesem Thread hatte ich mal mit dem Hinweis rumgenervt, dass doch bitte die setter- und Reading-Namen möglichst der Developer-Guide entsprechen sollten. Wenn das eingehalten ist (und auch der SONOSPLAYER-Code das beachtet hatte!), sollte man von der Bediener-Seite her eigentlich ziemlich nahe beieinander sein.
Was den im Hintergrund laufenden Code angeht, habe ich aber zugegebenermaßen keine Idee, was man da ggf. auf einfache Weise recyceln könnte. Meine Vermutung: sehr wenig, denn effektiv dürfte das meiste des funktionalen Codes (in Richtung der Sonos-Hardware) in dem sonos2mqtt-Code "gedoppelt" sein, MQTT2_DEVICE ist "eigentlich nur" die Benutzerschnittstelle...

Und eine große Diskussion zu MiLight (oder Roomba) gab es gar nicht. Es war nur in beiden Fällen so, dass die betreffenden "Entwickler" (das mit den Anführungszeichen gilt mir selber) in beiden Fällen direkt auf MQTT2_DEVICE gesetzt haben, nachdem das Umsetzen des Projekts "über ein paar Attribute" in beiden Fällen sehr viel einfacher ging wie das harte Codieren der speziell erforderlichen Routinen im Code (auf der bestehenden Codebasis von - im Prinzip - MQTT_DEVICE bzw. MQTT_DEVICE+MQTT).
Die weitergehenden Hinweise an @Otto sind eher eine interne Diskussion bzw. Anregung...

[kjmEjfu]

Wisst ihr zufällig, ob ich aus einer .pm heraus fremde Devices anpassen kann?
Also könnte eine 99_sonos2mqtt.pm die Set-/Get-Liste von 10_MQTT2_DEVICE.pm erweitern? Dann könnte man für MQTT2_DEVICE bei dem model=sonos2mqtt_speaker erfüllt ist, Funktionen erweitern, ohne dass der User seine setList anfassen muss.
Versteht ihr was ich meine?

[Otto123]

Versteht ihr was ich meine?

Nee 

[Beta-User]

Ich glaube es erahnen zu können, wie du das meinst und bin aus mehreren Gründen skeptisch (aber "möglich" wäre es, nur wird das ganze dann m.E. unwartbar...).

Vermutlich hast du das Problem, dass du einen "nicht-MQTT-Befehl" absetzen willst?
Sowas gibt es auch, (mindestens) zu finden in OpenMQTTGateway_BT_scanner (setter deleteReadings).

Grundsätzlich würde ich empfehlen, "halbwegs" innerhalb des Systems zu bleiben, MQTT2_DEVICE ist ausreichend flexibel, und auch als Helfer kann man dann leichter erkennen, wenn bzw. wo irgendwo ggf. der Hase im Pfeffer liegt.

[kjmEjfu]

Vermutlich hast du das Problem, dass du einen "nicht-MQTT-Befehl" absetzen willst?
Sowas gibt es auch, (mindestens) zu finden in OpenMQTTGateway_BT_scanner (setter deleteReadings).

Grundsätzlich würde ich empfehlen, "halbwegs" innerhalb des Systems zu bleiben, MQTT2_DEVICE ist ausreichend flexibel, und auch als Helfer kann man dann leichter erkennen, wenn bzw. wo irgendwo ggf. der Hase im Pfeffer liegt.

Nee

Ich versuch es anderes zu erklären
In 10_MQTT2_DEVICE.pm sind die Standard-Set Befehle für ein MQTT2-DEVICE definiert. Wir erweitern diese aktuell über SetList.
Diese Erweiterung würde ich gerne in eine 99_Sonos2mqtt.pm auslagern.
Aber nicht so, dass man diese selber händisch in der Art

Code Auswählen Erweitern

VolumeSave:textField {sonos2mqtt(VolumeSave,$EVENT)}
wieder im SetList eintragen muss. Sondern so, dass ein MQTT2-Device, welches model=sonos2mqtt_speaker gesetzt hat, um die Set-Befehle aus 99_Sonos2mqtt.pm erweitert wird, ohne die SetList anfassen zu müssen.

Also diesen https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Set Teil des Device Moduls zu erweitern.
Es sollen schon weiterhin MQTT-Befehle abgesetzt werden.

Ich weiß nicht, wie ich es sonst erklären soll 

[Beta-User]

Ebend. Du müßtest die SetFn austauschen. Geht zwar, ist aber unwartbar.

Du kannst aber das setList-Attribut doch auch automatisiert auswerten und ggf. dann eben erweitern. Ist zwar auch nicht trivial, aber m.E. eindeutig besser, als am Modulcode (am Autor vorbei) was rumzufrickeln.

[kjmEjfu]

Du kannst aber das setList-Attribut doch auch automatisiert auswerten und ggf. dann eben erweitern. Ist zwar auch nicht trivial, aber m.E. eindeutig besser, als am Modulcode (am Autor vorbei) was rumzufrickeln.

Also grundsätzlich würde Klassen erweitern jetzt nicht rumfickeln nennen, aber mag durchaus sein, dass in FHEM nicht vernünftig geht.


Dann habe ich noch zwei Userreadings gebastelt:

Code Auswählen Erweitern

Shuffle { if (ReadingsVal($name,"playmode","NORMAL") =~ m/SHUFFLE/) {return 1} else {return 0} ;},
Repeat { if (ReadingsVal($name,"playmode","NORMAL") =~ m/REPEAT/) {return 1} else {return 0} ;}

Zusätzlich neues für die SetListe:

Code Auswählen Erweitern

SleepTimer:textField { my ($cmd,$value)=split(' ', $EVENT,2); if ((lc($value) eq 'off') || ($value =~ 0)) { $value = '""' }; qq($DEVICETOPIC/control { "command": "sleep", "input": $value } ) }
Playmode:Normal,Shuffle,Repeat_All,Repeat_One,Shuffle_NoRepeat,Shuffle_Repeat_One {my ($cmd,$value)=split(' ', $EVENT,2); $value = uc($value);qq($DEVICETOPIC/control { "command": "playmode", "input": "$value" } ) }
VolumeRestore:noArg { my $value = ReadingsVal("$NAME", "VolumeStore", "00"); fhem "deletereading $NAME VolumeStore"; qq($DEVICETOPIC/control { "command": "volume", "input": $value } ) }
VolumeSave:textField { my $valueold = ReadingsVal("$NAME", "volume", "00"); my ($cmd,$value)=split(' ', $EVENT,2); if ($value =~ m/^[+-]{1}/) { $value += $valueold; }; fhem "setreading $NAME VolumeStore $valueold"; qq($DEVICETOPIC/control { "command": "volume", "input": $value } ) }

Das Löschen vom SleepTimer ist etwas unsauber in der Umsetzung, hab aber keine andere Lösung gefunden.

Btw Otto, du hattest gemeint, dass die Verwendung von $EVTPARTx eher was für Q&D sei. Das sonos2mqtt_speaker Template nutzt die durchgehend.

[Otto123]

Ja, dass war durchaus Selbstkritik
Aber ich glaube an den bisherigen Ecken ist das durchaus ok.  Es ist eher so: wenn man nicht im Hinterkopf hat, dass der $EVENT dabei einfach bei jedem Leerzeichen getrennt wird fällt man eventuell auf die Nase oder macht es sich unnötig schwer.

[kjmEjfu]

Ich habe nochmal eine grundsätzliche Frage.
Wie nah soll denn Sonos2mqtt an das "normale" Sonos kommen?

Hintergrund meiner Frage:
Sonos2mqtt schreibt z.B. Play. Das Sonos-Modul allerdings play.
Auch setzt das Modul einige (viele) Readings.

Aus meiner Sicht könnte es sinnvoll sein, wenn wir die Frage klären, damit hinterher nicht eventuell zuviel am Template umgebaut werden muss.
Sich am Modul orientieren, bringt den Vorteil, dass Umsteiger "nur" das Device austauschen müssen, dann aber bereits angelegte Automatismen problemlos weiter nutzen können. Der Nachteil wäre, dass es eventuell Flexibilität kostet und an manchen Stellen sicher etwas krampfig ist.

Was denkt ihr?

[Beta-User]

Immer noch meine 2ct: beide Varianten sollten den Developer Guide berücksichtigen! Da, wo es keine Konventionen gibt, gerne "as is" vom Modul her.Ggf. sollte optional ein neuer Modus im Modul angeregt werden...

[kjmEjfu]

Immer noch meine 2ct: beide Varianten sollten den Developer Guide berücksichtigen!

du meinst in dem Fall https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV ? Macht Sinn.
Würde aber z.B. bedeuten, dass wir das beliebte "speak" durch ein "sayText" ersetzen oder zumindest ergänzen müssen. Eine Ergänzung dann mit Vorbelegungen (Lautstärke, Sprache, Sprecher), damit

Code Auswählen Erweitern

set ''<device>'' sayText "Anruf in Abwesenheit"

auch so funktioniert.

Konkrete Frage in dem Zusammenhang, weil ich da wirklich nicht fit bin und mich jetzt erstmal länger einlesen müsste.
Wie müssten wir denn dann die ReadingList umbauen, damit z.B. der aktuelle Artist nicht in "currentTrack_Artist" landet, sondern in "currentArtist"?
Vom

Code Auswählen Erweitern

$DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }

in ReadingList müssten wir dann ja weg.

Ggf. sollte optional ein neuer Modus im Modul angeregt werden...

Jetzt verwirrst du mich.
Das war doch der Punkt, den ich gestern andiskutiert habe bzw. andiskutieren wollte  In Fall müsste doch aber 21_SONOSPLAYER.pm neue Set-Befehle an einem MQTT2_DEVICE (mit dem gesetzten Attribut model=sonos2mqtt_speaker) anlegen, eventuell auch neue Readings.
Ich hatte dich so verstanden, dass dies eher nicht wünschenswert ist.

Habe ich gerade einen Knoten im Hirn oder verstehe ich deinen Satz falsch?

Meine Idealvorstellung ist, dem Nutzer kann es egal sein, ob sein konkretes Sonosgerät, über MQTT oder nativ angesprochen wird, die Befehle (und Readings) sind immer gleich.

[Otto123]

Meine Intension war nicht irgendetwas abzulösen oder in Konkurrenz zu treten.
Der Weg über MQTT gefällt mir, da muss man schauen was man braucht, was das Hilfsmodul bietet, wie man das Ganze möglichst Userfreundlich und einfach einbindet.
Meine Intension war:

• wenig neu zu erfinden,
• vorhandene Dinge zu nutzen,
• die FHEM Guides beachten,
• keine alten Zöpfe kämmen.

Und klar geht es auch darum, was habe ich bisher genutzt und was brauche ich.