Sonos als Ersatz für Klingel und als Ansage für diverse Stati

[selfarian]

Hallo zusammen,

ich hatte bis vor kurzem nur ein (IKEA) Sonos, da waren meine Probleme noch einfach zu bewältigen, mittlerweile habe ich drei und da wird es etwas komplexer und ich wüsste gerne, ob das auch einfacher geht.
Und zwar: Ich nutze einen HM-Funktaster als Klingel, dieser löst über ein notify den folgenden Code aus:

Code Auswählen Erweitern

  my $azlasturi = ReadingsVal('sonos_Arbeitszimmer', 'currentTrackURI', 0);
  my $azlastvolume = ReadingsVal('sonos_Arbeitszimmer', 'Volume', 10);
  fhem("set sonos_Arbeitszimmer PlayURI \\\\fileserver\\Musik\\fhem\\klingel.mp3");
  fhem("set sonos_Arbeitszimmer Volume 30");
  sleep(10);
  fhem("set sonos_Arbeitszimmer PlayURI \\\\fileserver\\Musik\\fhem\\klingel.mp3");
  sleep(3);
  fhem("set sonos_Arbeitszimmer Volume $azlastvolume");
  fhem("set sonos_Arbeitszimmer PlayURI $azlasturi");

Warum so kompliziert? - Vermutlich weil wir zu 99% über die Antenne Bayern App Radio hören und Sonos, anstelle nach Speak und PlayURI wieder zum Radio zurückzukehren, einfach die mp3 in Dauerschleife abspielt.
Daher ziehe ich mir die Track URI und  die Volume und starte es anschließend wieder an. In der Momentanen Konstellation führt das natürlich auch leider dazu, dass er auch anfängt Musik zu spielen, wenn er vorher gar nicht an war. Ich könnte das jetzt alles mit dem o.g. Snippet machen und es einfach drei Mal kopieren, aber ich denke oder hoffe es gibt auch eine einfachere Variante

Da ich jetzt drei Sonos habe, würde ich gerne das o.g. für alle drei ausführen und natürlich auch (ggf. über das Reading State?) nur dann wieder zur Ursprungsplaylist zurückkehren, wenn es vorher bereits an war.
In diesem Zusammenhang auch generell die Frage, ob es eine Art Broadcast oder so gibt, dass die o.g. Wav auf allen im Netzwerk befindlichen Sonos einmalig (!) abgespielt wird. Analog dazu wäre auch statt Play ein Speak ganz gut.

Ein weiteres Problem habe ich mit dem Notify der Klingel. Ich habe hier das Attribut "disabledAfterTrigger" mit 10 gesetzt und würde jetzt erwarten, dass, wenn jemand 5 Mal die Klingel drückt, er das erste Mal getriggert wird und dann erst wieder nach 10 Sekunden. Allerdings triggert er den Notify dann 5 Mal, was wiederum zu einer Dauerschleife meiner klingel.mp3 führt und auch die "lasturi" überschreibt.

Vielen Dank schon einmal für Eure Ideen!

[MadMax-FHEM]

Ohje!

Also:

1. Dein Konstrukt mit den sleep WIE DU ES HAST blockiert!!!

2. ist verm. dein notify "zu ungenau" und wird "gleichzeitig" schon mal angetriggert, BEVOR das disableAfterTrigger wirkt ODER es hat eben mit dem Blockieren deiner sleep zu tun
EDIT: da wäre ein Auszug aus dem Eventmonitor deiner Klingel und ein list des notify hilfreich...

Also erst mal so umbauen:

fhem("set Device cmd1; sleep 30; set Device cmd2; sleep 10; set Device cmd3")

Wichtig: nach dem sleep muss ein fhem-cmd kommen, sonst blockiert es.

Wenn du mehrere Sonos "gleichzeitig" behandeln willst, dann kannst du entweder eine fixe Liste erstellen und die "durchnudeln" oder per devSpec dir die "passenden" Geräte "holen" und "durchnudeln"...

EDIT: hier ein Beispiel für das GoogleCast-Modul https://forum.fhem.de/index.php/topic,121170.msg1158109.html#msg1158109 (EDIT: da noch mit "fixer Liste" weil ich eben nicht auf allen eine Ausgabe wollte, sondern nur auf den beiden   /  Wenn du es auf allen willst, dann ginge, wie erwähnt, auch devspec2array). Prinzip sollte aber bleiben. Ob es auch für deine Sonos ein Event gibt, das das Ende der Ansage "meldet" (wie bei den GoogleCasts) musst du rausfinden. Ist halt schöner wie einfach eine bestimmte Zeit warten. Außer nat. es geht (wie in deinem Fall) nur um GENAU DIESE Ansage, wo (in etwa) bekannt ist wie lange die dauert... Statt "nur" die aktuelle Lautstärke als Reading "zwischenzuspeichern" kannst du nat. auch am jeweiligen Device die "PlayUrl" hinterlegen. Selber Befehl (setreading) aber nat. anderes Reading und Inhalt

Gruß, Joachim

[selfarian]

Hallo MadMax,

danke für deine Tipps, jetzt wo du das mit dem Blockieren schreibst, fällt mir ein, das ich das auch schon zigmal gelesen habe Ist jetzt umgebaut.
Ich werde das mit der Klingel asap testen und posten, muss nur etwas warten, sonst bringt mich meine Frau um, wenn ich dauernd klingle
Der Code sieht auch sehr brauchbar aus, danke Dir!

Hier schon einmal das list vom Notify:

Code Auswählen Erweitern

nternals:
   DEF        eg.fl.taster.klingel:Long.*|eg.fl.taster.klingel:Short.* {Klingel}
   FUUID      5c5428b6-f33f-5998-487d-9fc8fabbc8911bfd
   NAME       ntfy.all.klingel
   NOTIFYDEV  eg.fl.taster.klingel
   NR         130
   NTFY_ORDER 50-ntfy.all.klingel
   REGEXP     eg.fl.taster.klingel:Long.*|eg.fl.taster.klingel:Short.*
   STATE      2021-05-26 16:21:18
   TRIGGERTIME 1622038878.86545
   TYPE       notify
   READINGS:
     2021-05-15 06:19:27   state           active
Attributes:
   disabledAfterTrigger 10

[MadMax-FHEM]

Jaja, lass dir Zeit.

Ich denke es werden in Abfolge mehrere Events kommen, die passen, ergo wird auch mehrfach getriggert...
Also meine (schwere) Vermutung.

Mehr, wenn du die Auszüge aus dem Eventmonitor hast.

Aber um die zu kriegen brauchst du doch nur das notify deaktivieren, klingeln und wieder aktivieren?
Also dann sollte es ja nicht "klingeln"...

Zuverlässiger wäre es an sich aber, wenn du generell einen Homematic Funkgong "peeren" würdest.
Weil dann die Klingel auch funktioniert, wenn dein fhem grad mal "hängt" (siehe "sleep"   ) oder "abgeraucht" sein sollte...
Auch ist es dann mit deutlich geringerer Verzögerung, weil eben das Funktelegramm direkt an den Funkgong geht und der dann "sofort" reagiert...
Ich kopple (wo möglich/wichtig) solche Dinge direkt...
D.h. ich bleibe da "innerhalb eines Systems" (Beispiel Heizung, Licht [da wo wichtig] usw.)...

Nur als zusätzlichen Hinweis, falls du dich mal wunderst, wenn Freunde erzählen, dass du nicht zuhause warst, weil auf Klingeln niemand geöffnet hat

Gruß, Joachim

[selfarian]

Hallo Joachim,

ok, daran hab ich nicht gedacht hier der Eventmonitor. Ich habe jetzt mehrfach gedrückt:

Code Auswählen Erweitern

2021-06-01 09:29:47 CUL_HM eg.fl.taster battery: ok
2021-06-01 09:29:47 CUL_HM eg.fl.taster eg.fl.taster.klingel Short
2021-06-01 09:29:47 CUL_HM eg.fl.taster.klingel Short 1_193 (to broadcast)
2021-06-01 09:29:47 CUL_HM eg.fl.taster.klingel trigger: Short_193
2021-06-01 09:29:47 CUL_HM eg.fl.taster.klingel trigger_cnt: 193
2021-06-01 09:29:47 CUL_HM eg.fl.taster battery: ok
2021-06-01 09:29:47 CUL_HM eg.fl.taster eg.fl.taster.klingel Short
2021-06-01 09:29:47 CUL_HM eg.fl.taster.klingel Short 1_194 (to broadcast)
2021-06-01 09:29:47 CUL_HM eg.fl.taster.klingel trigger: Short_194
2021-06-01 09:29:47 CUL_HM eg.fl.taster.klingel trigger_cnt: 194
2021-06-01 09:29:47 CUL_HM eg.fl.taster battery: ok
2021-06-01 09:29:47 CUL_HM eg.fl.taster eg.fl.taster.klingel Short
2021-06-01 09:29:47 CUL_HM eg.fl.taster.klingel Short 1_195 (to broadcast)
2021-06-01 09:29:47 CUL_HM eg.fl.taster.klingel trigger: Short_195
2021-06-01 09:29:47 CUL_HM eg.fl.taster.klingel trigger_cnt: 195
2021-06-01 09:29:48 CUL_HM eg.fl.taster battery: ok
2021-06-01 09:29:48 CUL_HM eg.fl.taster eg.fl.taster.klingel Short
2021-06-01 09:29:48 CUL_HM eg.fl.taster.klingel Short 1_196 (to broadcast)
2021-06-01 09:29:48 CUL_HM eg.fl.taster.klingel trigger: Short_196
2021-06-01 09:29:48 CUL_HM eg.fl.taster.klingel trigger_cnt: 196
2021-06-01 09:29:48 CUL_HM eg.fl.taster battery: ok
2021-06-01 09:29:48 CUL_HM eg.fl.taster eg.fl.taster.klingel Short
2021-06-01 09:29:48 CUL_HM eg.fl.taster.klingel Short 1_197 (to broadcast)
2021-06-01 09:29:48 CUL_HM eg.fl.taster.klingel trigger: Short_197
2021-06-01 09:29:48 CUL_HM eg.fl.taster.klingel trigger_cnt: 197
2021-06-01 09:29:48 CUL_HM eg.fl.taster battery: ok
2021-06-01 09:29:48 CUL_HM eg.fl.taster eg.fl.taster.klingel Short
2021-06-01 09:29:48 CUL_HM eg.fl.taster.klingel Short 1_198 (to broadcast)
2021-06-01 09:29:48 CUL_HM eg.fl.taster.klingel trigger: Short_198
2021-06-01 09:29:48 CUL_HM eg.fl.taster.klingel trigger_cnt: 198
2021-06-01 09:29:49 CUL_HM eg.fl.taster battery: ok
2021-06-01 09:29:49 CUL_HM eg.fl.taster eg.fl.taster.klingel Short
2021-06-01 09:29:49 CUL_HM eg.fl.taster.klingel Short 1_199 (to broadcast)
2021-06-01 09:29:49 CUL_HM eg.fl.taster.klingel trigger: Short_199
2021-06-01 09:29:49 CUL_HM eg.fl.taster.klingel trigger_cnt: 199
2021-06-01 09:29:49 CUL_HM eg.fl.taster battery: ok
2021-06-01 09:29:49 CUL_HM eg.fl.taster eg.fl.taster.klingel Short
2021-06-01 09:29:49 CUL_HM eg.fl.taster.klingel Short 1_200 (to broadcast)
2021-06-01 09:29:49 CUL_HM eg.fl.taster.klingel trigger: Short_200
2021-06-01 09:29:49 CUL_HM eg.fl.taster.klingel trigger_cnt: 200
2021-06-01 09:29:49 CUL_HM eg.fl.taster battery: ok
2021-06-01 09:29:49 CUL_HM eg.fl.taster eg.fl.taster.klingel Short
2021-06-01 09:29:49 CUL_HM eg.fl.taster.klingel Short 1_201 (to broadcast)
2021-06-01 09:29:49 CUL_HM eg.fl.taster.klingel trigger: Short_201
2021-06-01 09:29:49 CUL_HM eg.fl.taster.klingel trigger_cnt: 201
2021-06-01 09:30:00 HMLAN HMLAN1 loadLvl: low

Achso, wegen der Verzögerung und dem direkten Koppeln: Ich hab auch schon häufiger darüber nachgedacht... bisher hab ich mir den Funkgong einfach gespart. Führte halt leider hier und da zu Problemen Hat aber den Vorteil, das unsere Gäste idR bescheid wissen und die Zeugen Jehowas oder so dann mit etwas Glück überhört werden

Gruß,
Alex

[MadMax-FHEM]

Hm, ok, sollte eigentlich nicht "zu oft" triggern.
EDIT: ich sehe potentiell 2 Trigger pro "Knopfdruck" (wenn ich mich nicht verschaut hab)...
Bzw. sind halt keine "Long" zu sehen

Wie hast du das notify "erzeugt"?

Durch den EventMonitor erzeugen lassen?

Evtl. ist/war es dann u.U. doch durch deine "Blockierungen".
Welches IO hast du für Homematic?

Vielleicht hat das "gesammelt" und dann in einer Flut an das notify weitergegeben...

Schon mal mit dem "non-blocking-Umbau" getestet?

Für eine andere Anwendung (ich verlasse die Wohnung) merke ich mir, ob meine Echos Musik gespielt haben...
...wenn ich zurück komme und es war so, wird die wieder gestartet, sonst nat. nicht

Geht genauso wie mit der Lautstärke.
Als die "Abfragen" (ReadingsVal) und dann eben IM DEVICE (Echo bei mir, Sonos bei dir) speichern (setreading, z.B. setreading SonosDevice1 wasPalying yes/no oder auch die Play-Url: wenn eine Url, dann wurde die gespielt, ansonsten eben "none" o.ä. Kommt halt drauf an was man da beim Sonos so "abfragen" kann etc.)...
Und dann eben wieder Abfragen (diesmal den "gespeicherten Wert", eben "wasPlaying" o.ä.)...

Also so wie es im Beispiel mit den GoogleCasts bzgl. Lautstärke gemacht ist.
Vorteil des "speicherns" im Device (per setreading): man kann es auch von "anderer Stelle" abfragen.
Also so wie in meinem Fall im notify was auf das Ende der Durchsage reagiert...

Weil wie schon geschrieben: ein sleep ist halt immer gleich lang. Für "statische" Ansagen ist das verm. ok. Aber bei flexiblen Ansagen ist anders nat. besser/schöner...

Kommt aber halt drauf an, was das Modul/Device so an Infos/Events liefert...

Gruß, Joachim

[Otto123]

Da ich jetzt drei Sonos habe, würde ich gerne das o.g. für alle drei ausführen und natürlich auch (ggf. über das Reading State?) nur dann wieder zur Ursprungsplaylist zurückkehren, wenn es vorher bereits an war.

Hi,

es gibt auch den Befehl playUriTemp - der unterbricht ein laufendes Programm.

Ich habe die Sonos Anbindung zusätzlich per MQTT gemacht, da gibt es einen Befehl notifyall - der spielt eine Nachricht auf allen Speakern gleichzeitig und kehrt dann zum Programm zurück.

Wenn also MQTT was für dich ist kannst Du damit spielen, geht auch minimal invasiv parallel zum Sonos Modul. Schau im MQTT Board.

Gruß Otto

[TomLee]

Wenn das notify nur auf dieses Event:

Code Auswählen Erweitern

2021-06-01 09:29:47 CUL_HM eg.fl.taster eg.fl.taster.klingel Short
reagieren soll, sollte das Suchmuster dann nicht ohne dem .* am Ende definiert werden ?

So:

Code Auswählen Erweitern

eg.fl.taster.klingel:Long.*|eg.fl.taster.klingel:Short.*
reagiert das notify doch auf alle Events mit

Code Auswählen Erweitern

eg.fl.taster.klingel Short 1_19x

?

Denke nix anderes kommt dabei raus wenn man es mit dem Eventmonitor erstellen lässt.

edit:
Doch, der Name des auslösenden Device sollte noch ergänzt werden mit einem durch den Eventmonitor erstellten notify:

Code Auswählen Erweitern

eg.fl.taster:eg.fl.taster.klingel:.Long|eg.fl.taster:eg.fl.taster.klingel:.Short

[MadMax-FHEM]

Wenn das notify nur auf dieses Event:

Code Auswählen Erweitern

2021-06-01 09:29:47 CUL_HM eg.fl.taster eg.fl.taster.klingel Short
reagieren soll, sollte das Suchmuster dann nicht ohne dem .* am Ende definiert werden ?

So:

Code Auswählen Erweitern

eg.fl.taster.klingel:Long.*|eg.fl.taster.klingel:Short.*
reagiert das notify doch auf alle Events mit

Code Auswählen Erweitern

eg.fl.taster.klingel Short 1_19x

?

Denke nix anderes kommt dabei raus wenn man es mit dem Eventmonitor erstellen lässt.

Naja auf "alle", es sind ja (soweit ich das jetzt überblickt habe) nur 2 "potentielle" Events pro Knopfdruck...
...eigentlich sollte nur einer davon tatsächlich passen...

Bzw. die genannte Flut ist dadurch wohl eher nicht zu erklären...

Aber klar: je genauer desto besser!

Gruß, Joachim

[Otto123]

Man kann bei den Tastern mMn entweder:
auf den state Event im Hauptdevice!

Code Auswählen Erweitern

eg.fl.taster:eg.fl.taster.klingel.Short
oder auf den state Event im Channeldevice

Code Auswählen Erweitern

eg.fl.taster.klingel:Short.*
oder auf das Reading Event im Channel

Code Auswählen Erweitern

eg.fl.taster.klingel:trigger:.Short_.*
triggern.

[selfarian]

Erst einmal Danke an alle für die Unterstützung und Antworten!

Bzw. sind halt keine "Long" zu sehen
Wie hast du das notify "erzeugt"?
Durch den EventMonitor erzeugen lassen?
Evtl. ist/war es dann u.U. doch durch deine "Blockierungen".
Welches IO hast du für Homematic?

Bezüglich Long: Long kommt nur wenn man den Taster länger drückt, ich hatte hin und wieder "Gäste" die einfach lange auf den Knopf drücken und damit es da auch klingelt..
Den Notify habe ich selbst gebastelt.

Ich habe jetzt den Verdacht, dass es an der Blockierung liegt. Ich hatte eben ~3 Mal schnell geklingelt, da ging nur die Musik aus und es kam nix, dann habe ich es mit etwas mehr Abstand (<1 Sekunde) gemacht und trotz dem, dass ich zweimal gedrückt habe, kam die Ansage nur 2x, also so wie gewollt...

IO ist ein HM-LAN, schon etwas älter

Werde in einer Ruhigen Minute nochmal testen

[MadMax-FHEM]

Naja, der HMLAN könnte Funktelegramme schon "puffern"...

Und dann eben weitergeben, wenn fhem wieder kann/mag
(weil die notwendige ACKs für Pakete kann der HMLAN ja selbst/unabhängig von fhem)

Bei einem CUL wäre es eher "ungewöhnlich", da der wirklich "nur" Sende-/Empfangsmodul ist und alle Nachrichten nur in fhem "verstanden" werden und auch ACKs etc. von fhem kommen müssen...
Wenn fhem "hängt" geht nix, dann ist höchstens der Sensor/Aktor etc. "beleidigt"...

Viel Spaß beim Experimentieren, Joachim

[selfarian]

Also wäre ein CUL die bessere Wahl?

Bin ja am Überlegen, ob ich nicht irgendwann was neues brauche, weil ja immer mehr Homematic IP kommt, hab mich da aber noch nicht weiter belesen.

Danke!

[MadMax-FHEM]

Also wäre ein CUL die bessere Wahl?

Ja genau!

Nein, auf keinen Fall!

Bin ja am Überlegen, ob ich nicht irgendwann was neues brauche, weil ja immer mehr Homematic IP kommt, hab mich da aber noch nicht weiter belesen.

Naja bei Homeatic IP kommst du an einer CCUx (CCU1, CCU2, CCU3) nicht vorbei.
Kannst du als HW von ELV kaufen oder auch auf Basis vorhandener HW "selbst machen": piVccu (nicht verwechseln mit vccu!!!!), debMatic, RaspberryMatic, ...

Hier jetzt nicht ausführlicher, gibt gefühlt eine Mio Threads zu dem Thema...

Gruß, Joachim

[selfarian]

Also gute Neuigkeiten:

Danke noch einmal an Euch alle, weitere Tests haben ergeben, dass es wirklich an meinen sleeps lag

Das einzige was ich jetzt noch nicht rausgefunden habe, wie ich beim Sonos rausfinde, wenn die Ansage vorbei ist. Er zeigt immer vor der Ansage ein "Wird gestartet..." aber am Ende sind die entsprechenden Readings dann leider nur leer.