Sonos2mqtt - vielleicht hat jemand Lust mitzumachen

[Otto123]

Oben ging's mal drum, dass mehrere Devices mit einer bestimmten Namenskonvention adressiert werden, von daher war das etwas anderes, aber so in der Richtung kann man die Anregung auch verstehen.

Ich habe jetzt etwas rumprobiert, nachgedacht und versucht die notify so "scharf" wie möglich und so allgemein wie nötig zu triggern.
Die Benennung der MQTT2_ Devices ist hartcodiert hat Rudi mal gesagt: MQTT2_<CID>
Da die CID von den Playern vorgegeben wird, ist doch die initiale Benennung auch vorgegeben?! Oder sehe ich das falsch?

Ich würde ungern auf MQTT2_.* triggern. Beim DEFINE ist das noch relativ selten, aber beim abfragen der danach folgenden ZoneInfos fällt mir nix so richtig ein.
Der Fall oben von Andre ist doch eigentlich ein Fehler der so gar nicht auftreten kann - oder?

Gruß Otto

[Beta-User]

Ich habe jetzt etwas rumprobiert, nachgedacht und versucht die notify so "scharf" wie möglich und so allgemein wie nötig zu triggern.
Die Benennung der MQTT2_ Devices ist hartcodiert hat Rudi mal gesagt: MQTT2_<CID>
Da die CID von den Playern vorgegeben wird, ist doch die initiale Benennung auch vorgegeben?! Oder sehe ich das falsch?

Ich würde ungern auf MQTT2_.* triggern. Beim DEFINE ist das noch relativ selten, aber beim abfragen der danach folgenden ZoneInfos fällt mir nix so richtig ein.

Ähm, sorry, wenn ich da alles in einen Topf geworfen hatte: Mir ging es v.a. darum, im laufenden Betrieb nicht Namen zu verwenden, die veränderlich sind (devStateIcon, tendenziell auch attrTemplate-Anweisungen). Die "defined"-notify sind da etwas anderes, da kann man schon den (erst mal vorgegebenen) Namen verwenden. (Ob das insgesamt Sinn macht, ist eine andere (Geschmacks-)Frage).

Ohne das intensiver geprüft zu haben, tendiere ich aber weiter dazu, insgesamt eher über eine devspec mit "RINCON_"-Matching zu gehen; man muß damit rechnen, dass "irgendwer" auch automatisch Devices bei autocreate umbenennt und dann 4 Sekunden schon wieder eine Ewigkeit sind...
(k.A., warum "man" sowas macht, aber es gibt nichts, was es nicht gibt.)

(Das Einrichten der Clients könnte man dann übrigens auch als "Erweiterung" an das Anwenden des Bridge-Templates hängen, dann bräuchte man evtl. kein notify, oder interpretiere ich da was rein; es scheint ja eine Art "presentation"-Option für den sonos2mqtt-Dienst zu geben oder man wertet die subscriptions aus?

Der Fall oben von Andre ist doch eigentlich ein Fehler der so gar nicht auftreten kann - oder?

Ohne jetzt nochmal den ganzen Thread durchgegangen zu sein vermute ich, dass er schlicht und einfach kein "bridge"-Gerät angelegt hat?

[Otto123]

(Das Einrichten der Clients könnte man dann übrigens auch als "Erweiterung" an das Anwenden des Bridge-Templates hängen, dann bräuchte man evtl. kein notify, oder interpretiere ich da was rein; es scheint ja eine Art "presentation"-Option für den sonos2mqtt-Dienst zu geben oder man wertet die subscriptions aus?

Direkt im Template geht es nicht, denn die Sache ist ja zeitlich ein Ablauf:

• Bridge eingerichtet und arbeitsfähig
• der sonos2mqtt wird gestartet oder ein neuer Player kommt (wird eingeschaltet/hinzugefügt)
• hier vergeht Zeit bis alle Player da sind. Bei mir bis zu 4 sec . Konfiguriert man jeden Player wie er kommt kann man das Template in kurzer Zeit anwenden ca. 1sec
• autocreate define MQTT2_RINCON....
• allgemeines Template für den Speaker anwenden
• Zoneinfo über sonos2mqtt abfragen
• hier vergeht Zeit bis 2 sec
• Player im Detail je nach seinen Fähigkeiten "fertig" konfigurieren (Input, icon, ...)

Klar könnte man FHEM auch für ein paar Sekunden beim Setup blockieren (kann man nicht!) man kann alternativ dasitzen und warten und schauen und klicken. 

Mit den beiden notify funktioniert das Setup der Player voll automatisch - auch wenn man sich zu Weihnachten eine Erweiterung kauft!

Aber man kann die notify im Bridge Template einfach ins System werfen

[Beta-User]

In attrTemplate hast du auch die Option, Perl-Commands abzusetzen (einschl. fhem("sleep2;;...")), von daher: geht nicht, gibt's nicht, man könnte damit auch zeitlich Abläufe (nachlaufend zu publish-Anweisungen an das IO) realisieren....

Aber mir ging es weniger um das/die notify, sondern eher um sowas:

Code Auswählen Erweitern

my $uuidtoname = "MQTT2_".ReadingsVal($name,'coordinatorUuid','0');;\Hier sollte man entweder die coordinatorUuid in ein eigenes Attribut (des "Zieldevices") packen (userattr oder devicetopic?) und dann via devspec weiterarbeiten .

[Otto123]

Ok verstanden: devStateIcon -> Komfortbaustelle -> wenn die Grundkonfig mal stabil steht.
Ich habe noch einen Vorschlag für ein gaanz einfaches "Basic devStateIcon".

Mir geht es mit den notify primär darum: " das Setup der Player voll automatisch - auch wenn man sich zu Weihnachten eine Erweiterung kauft"

ok kann man unterschiedlicher Meinung sein. Ich würde das Angebot machen - wer alles selbst konfigurieren will, kann ja im Template abgucken.

[Otto123]

Das wäre mein Vorschlag für das Template "Bridge Comfort" (den Namen kannst Du gern ändern)

Code Auswählen Erweitern

name:sonos2mqtt_bridge_comfort
desc:The sonos2mqtt bridge including automated setup for speaker devices
filter:TYPE=MQTT2_DEVICE
order:M_05c
set DEVICE attrTemplate sonos2mqtt_bridge
define n_configSonos1 notify global:DEFINED.MQTT2_RINCON_[A-Z0-9]+ sleep 1;set $EVTPART1 attrTemplate sonos2mqtt_speaker;set $EVTPART1 x_raw_payload {"command": "adv-command","input": {"cmd":"GetZoneInfo","reply":"ZoneInfo"}}
define n_configSonos2 notify MQTT2_RINCON_[A-Z0-9]+:IPAddress:.* {\
  no warnings 'experimental::smartmatch';\
  my @tv = ("S14","S11");\
  my $url="http://$EVTPART1:1400";\
  my $xmltext = GetFileFromURL("$url/xml/device_description.xml");\
  my ($mn)=$xmltext =~ /<modelNumber>(S[0-9]+)/;\
  my ($img)=$xmltext =~ /<url>(.*)<\/url>/;\
  my $icon="Sonos2mqtt_icon-$mn";\
  my $setList=AttrVal($NAME,'setList','');\
  fhem("setreading $NAME modelNumber $mn");\
  fhem("\"wget -qO ./www/images/default/$icon.png $url$img\"");\
  fhem("attr $NAME icon $icon;sleep 4 WI;set WEB rereadicons");\
  if ($mn ~~ @tv) {$setList=~s/input:Queue \{/input:Queue,TV \{/};\
  $setList=~s/;/;;/g;\
  fhem("attr $NAME setList $setList")\
}
setreading DEVICE attrTemplateVersion 20200727
Ich bin nach wie vor der Meinung: Man sollte die Bridge als erstes "per Hand" anlegen.
Codevorschlag für die Raw Def:

Code Auswählen Erweitern

define SonosBridge MQTT2_DEVICE
attr SonosBridge IODev <Name des MQTT2 Server>
attr SonosBridge room MQTT2_DEVICE
set SonosBridge attrTemplate sonos2mqtt_bridge_comfort
Man wird nach dem Topic gefragt, den tippt man ein (sonos)
* und damit ist man fertig. 👍
Der Rest ist magic
Sobald ein Player aktiv ist, wird er angelegt und konfiguriert.

Gibt es eine Erklärung warum aus dem Template beim define die Semikolon eins zu eins in die Konfig wandern? Ich würde ja gern die Notwendigkeit für dritte Syntaxvariante verstehen. 
Zeilenende/fortsetzung
1. DEF ;
2. Raw Def ;;\
3. Template ;\

[Beta-User]

Hab's mal (fast) so eingecheckt.

Ob man die Bridge von Hand anlegt oder nicht: bin da leidenschaftslos; vermutlich wird das Ding aber automatisch angelegt, wenn man autocreate aktiv hat, MQTT2_SERVER im Einsatz und den Dienst startet . Wichtig ist halt, dass man das Template dann auch andwendet, denn sonst gibt's halt keine "speaker"-Sub-Geräte .

Zur Syntax kann ich wenig sagen, ich habe das nicht erfunden, sondern einfach die Templates "gesammelt" (und komme bekanntermaßen auch immer ins Straucheln, wenn ich ungetestet irgendwas zur Syntax sage, völlig egal, ob es als RAW oder vertemplated oder sonst wie ist ...)

[Otto123]

Danke!

...vermutlich wird das Ding aber automatisch angelegt, wenn man autocreate aktiv hat, MQTT2_SERVER im Einsatz und den Dienst startet .

Wenn "das Ding" schon da ist wird es aber nicht nochmal angelegt.
Insofern wenn man "das Ding" anlegt und dann erst den Dienst startet werden sofort die Player angelegt

Aber egal, wenn es schon da ist muss man halt das Template anwenden sonst keine Player. Ist wirklich egal und man kann auch alles zu Fuß machen (oder per Hand) 

[Beta-User]

Insofern wenn man "das Ding" anlegt und dann erst den Dienst startet werden sofort die Player angelegt

...auch nett...
Gibt es evtl. die Möglichkeit, eine Art "Präsentation" zu starten? (Z.B. ein MQTT-Command, der den Dienst neu startet?)

(Man könnte auch die vorhandene readingList als Array ausmosten und dann die einzelnen Player über eine Schleife anlegen; zumindest DEV_ID und BASE_TOPIC für die Speaker wären damit bekannt...) (duckundweg)

[andre07]

Hab es bei mir nochmal gelöscht mein mqtt2client deaktiviert und neu angelegt Player werden erzeugt auch speak funktioniert.
Das devStateIcon noch eingefügt jetzt scheint es wieder zu gehen auch die Namen der Player passen wieder.
Auf meinen Haupt Fhem läuft noch das Sonos Modul mit dem ich aber immer wieder  Probleme habe deshalb wollte ich es mal
auf meinen Test Fhem ordentlich zum laufen bekommen bevor ich es ersetzte.
Beide Systeme sind per mqtt2client (fhem2) miteinander verbunden.

[87insane]

Hey zusammen,

kümmere mich um die komfort Baustelle sobald ich wieder Zeit hab. Der Vergleich oben für myuuid war nur einer von vielen versuchen. Soweit ich das überflogen habe, habt ihr mir aber neue wege eröffnet und ich kann das alles anpassen. Devstateicon (meine variante) ist maximal beta Test aktuell. Die Richtung und Funktionen wird bleiben und noch ein wenig aufgebohrt. Nur ist das testen aller Konstellationen echt zeitaufwendig und ich muss mich darauf konzentrieren können. Aktuell hab ich ne kleine Baustelle zuhause und muss das zuerst fertig bekommen. Seid mir nicht böse.

Ggf macht es Sinn, den aktuellen status im ersten Post zu Zeigen. Dann müsste ich zb nicht 25 Beiträge lesen und wüsste direkt was passiert ist. Glaube otto123 hatte das nach seinem UL auch....

[Otto123]

Ich pflege aktuell "meinen Stand" in meinem Blog Artikel, insofern ist die erste Seite des Threads aktuell
(muss ich natürlich noch auf die heutige/morgige Neuerung anpassen - neues Template verfügbar )

Bis es eine fertige Installations-Anleitung gibt, bitte ich diesen Link zu meinem Blog zu folgen:
https://heinz-otto.blogspot.com/2020/05/sonos2mqtt-so-weit-bin-ich.html

Ich würde aber jetzt schon gern für die Grundlage einen Artikel im Wiki machen.
Hier https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele oder separat?

An dem devStateIcon kann man sicher ewig verbessern, auch hier sehe ich eigentlich einen ganz guten Stand erreicht.

@Beta-User Den Dienst neu starten, leider (weiß ich es) nicht per MQTT - aber einfach so in der FHEM Kommandozeile:

Code Auswählen Erweitern

"pm2 restart sonos2mqtt"
Mal schauen, vielleicht gibt es doch was ...
Ansonsten reicht es im laufenden Betrieb den Player einfach zu bedienen, wenn er selbst den Titel wechselt reicht es auch.

Oder meinst Du ohne autocreate?

[Beta-User]

Hier https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele oder separat?

Tendiere zu einer Mischform ähnlich wie beim EBus. Hängt aber auch davon ab, wie umfangreich das am Ende wird, aber bereits dein Mitschrieb hat ja einen "gewissen Umfang".

@Beta-User [...]
Oder meinst Du ohne autocreate?

Schon mit autocreate. Das mit dem restart war nur als Beispiel gedacht (so machen wir das bei Tasmota), es ginge z.B. auch ein "mache alle leiser" oä. (Wildcard-publish?). Aber so wichtig ist das am Ende auch nicht, das ganze ist auch so schon sehr komfortabel, und Weihnachten wird ja schließlich auch immer mal wieder ...

[Otto123]

Ich glaube auch Mischform:  die Wiki Seite hat ja schon jetzt einen leicht unübersichtlichen Umfang.
Ich mache einen Extra Artikel und den können wir in einem kurzem Überblick Abschnitt verlinken.

[Beta-User]

Vermutlich ist es das beste, einfach mal loszulegen.

Was die "Praxisbeispiele" selbst angeht, wäre es evtl. auch an der Zeit, das aufzubrechen; z.B. Tasmota hätte evtl. etwas mehr Pflege verdient (wie sind die attrTemplate aufgebaut? Warum bestimmte jsonMaps,...), OpenMQTTGateway fehlt noch bzw. ist unvollständig & am falschen Ort, ...
(Grade habe ich dazu aber nicht die große Lust und/oder durchschlagende Idee).