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:
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!
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
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 :D
Der Code sieht auch sehr brauchbar aus, danke Dir!
Hier schon einmal das list vom Notify:
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
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
Hallo Joachim,
ok, daran hab ich nicht gedacht ;) hier der Eventmonitor. Ich habe jetzt mehrfach gedrückt:
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 :D
Gruß,
Alex
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
Zitat von: selfarian am 31 Mai 2021, 10:34:17
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
Wenn das notify nur auf dieses Event:
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:
eg.fl.taster.klingel:Long.*|eg.fl.taster.klingel:Short.*
reagiert das notify doch auf alle Events mit
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:
eg.fl.taster:eg.fl.taster.klingel:.Long|eg.fl.taster:eg.fl.taster.klingel:.Short
Zitat von: TomLee am 01 Juni 2021, 12:02:58
Wenn das notify nur auf dieses Event:
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:
eg.fl.taster.klingel:Long.*|eg.fl.taster.klingel:Short.*
reagiert das notify doch auf alle Events mit
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
Man kann bei den Tastern mMn entweder:
auf den state Event im Hauptdevice!
eg.fl.taster:eg.fl.taster.klingel.Short
oder auf den state Event im Channeldevice
eg.fl.taster.klingel:Short.*
oder auf das Reading Event im Channel
eg.fl.taster.klingel:trigger:.Short_.*
triggern.
Erst einmal Danke an alle für die Unterstützung und Antworten!
Zitat von: MadMax-FHEM am 01 Juni 2021, 11:48:17
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 :)
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
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! :)
Zitat von: selfarian am 01 Juni 2021, 16:18:56
Also wäre ein CUL die bessere Wahl? ;)
Ja genau! ;) ;) ;)
Nein, auf keinen Fall!
Zitat von: selfarian am 01 Juni 2021, 16:18:56
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
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.
Mal in den Eventmonitor schauen während einer Ansage, vielleicht ist was zu erkennen...
Wenn nicht, dann eben mit sleeps (aber "die richtigen Sleeps" ;) ), musst du halt dann (pro Ansage) "rausmessen...
Mein verlinkter Ansatz (GoogleCast) ist halt quasi "generisch" bzgl. Ansagenlänge...
...ist ja kein MUSS, nur ein (schönes) Kann ;)
Wenn du nur eine und immer dieselbe Ansage hast, dann ist das ja eigentlich (fast) unnötig...
Gruß, Joachim
Ja, hab gerade mal analysiert... wird nicht einfach ;) muss wohl irgendwie über die Länge laufen... mal sehen. Für die Klingel brauche ich es ja nicht :)
Du könntest ja "Wörter zählen", also die zu sprechende Nachricht mit split bei "Space" trennen und dann die Anzahl der "gesplitteten" Teile (=Wörter) "zählen" und für jedes Wort einfach "ein paar Sekunden" angeben... ;)
Nicht schön aber flexibel...
...also falls sich nichts besseres findet.
Gruß, Joachim
Ja, so ungefähr habe ich auch gerade gedacht ;) Irgendwie die Länge "messen". Auf ein paar Sekunden hin oder her kommt es ja nicht an :)
Wozu musst Du wissen wann es vorbei ist?
Eventmonitor beobachten und die Events rauspicken?
Zitat von: Otto123 am 02 Juni 2021, 17:46:42
Wozu musst Du wissen wann es vorbei ist?
Eventmonitor beobachten und die Events rauspicken?
Damit er die ursprüngliche "Musik" wieder laufen lassen kann (und die Lautstärke zurückstellen kann)...
...das macht das verwendete Modul wohl nicht selbsttätig nach einer Ansage?
Ja, Eventmonitor hatte ich auch schon zu geraten... 8)
Aber: isch abe gar keine Sonos ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 02 Juni 2021, 18:19:27
Damit er die ursprüngliche "Musik" wieder laufen lassen kann (und die Lautstärke zurückstellen kann)...
...das macht das verwendete Modul wohl nicht selbsttätig nach einer Ansage?
Doch ;)
Zitat von: MadMax-FHEM am 02 Juni 2021, 18:19:27
Damit er die ursprüngliche "Musik" wieder laufen lassen kann (und die Lautstärke zurückstellen kann)...
...das macht das verwendete Modul wohl nicht selbsttätig nach einer Ansage?
Doch, mit playUriTemp macht er genau das...
Ah, ok.
Dann war der ganze Thread-Mittelteil "für die Katz" ;)
Und da ich immer noch kein Sonos habe: habe ich auch immer noch keine Ahnung was das Modul kann... ;)
Aber Hauptsache geholft... :)
Gruß, Joachim
Zitat von: MadMax-FHEM am 02 Juni 2021, 20:03:27
Dann war der ganze Thread-Mittelteil "für die Katz" ;)
niemals :) ;D
Man kann herausfinden ob die Sprachdurchsage zuende ist, mit einer sequence, die auf folgende 2 events , also auf den Anfang und das ende der Sprachdurchsage triggered:
defmod Sonos_sprach_sequence2 sequence Sonos_Flur:currentAlbum:.Sprachdurchsagen 180 Sonos_Flur:currentAlbum:.
Alternativ über ein sleep solange warten, bis die Sprachansage vorbei ist, wobei die länge des sleep folgend berechnet werdeln kann:
my $laenge = int(length($text)/10)+3;