Hallo Zusammen,
ich weiß, FHEM ist nicht multithreading fähig, aber vielleicht hat trotzdem jemand eine Lösung für mich.
Aktuell verwende ich z.B. das Alarm Modul welches mir bei Auslösung einen Alarmton über Sonos-Lautsprechern ausgeben als auch meine LED-Leisten blinken lassen soll.
Leider fängt das blinken kurz an, dann kommt die 30 sekündige Signalausgabe über Sonos und dann geht das blinken weiter.
######## LEDController - roter Alarm ############
sub
alarmSystemLEDControllerRedAlert() {
my $fhemAlarmCommand = "";
for (my $i=0; $i<10; $i++) {
$fhemAlarmCommand .= "set LEDController RGB FF0000 0.5; sleep 0.7; set LEDController off; sleep 0.3; "
}
fhem($fhemAlarmCommand);
}
Wie macht ihr das?
VG, Thomas
sub RedAlert() {
fhem "set allHueDevices bri 254 : hue 0 : sat 254; sleep 0.5; set allHueDevices off; set allHueDevices alert lselect; set TYPE=AMADDevice:FILTER=deviceState=online notifySndFile RedAlert.mp3; sleep 15; set allHueDevices bri 254 : hue 0 : sat 254; set allHueDevices off; set allHueDevices alert lselect";
}
Ich habe ein ähnliches Problem: verschiedene Ursachen führen zu einer Sprachausgabe - das klappt nicht immer, wenn mehrere Ereignisse fast zeitgleich eintreffen. Meine Idee: nicht direkt die Sprachausgabe ansteuern, sondern die Textnummer in eine Liste schreiben und eine eigenständige Routine liest ein Element nach dem anderen aus und wartet auch immer bis der vorherige Text beendet ist (im einfachsten Fall durch die maximale Textlänge bestimmt eine feste Zeit). Bei leerer Liste wird dann alle n Sekunden gepollt. Wenn ich mal wieder Zeit habe, werde ich mich damit beschäftigen (jetzt muss ich erst einmal von einem Raspberry auf den anderen umziehen und dabei möglichst nur kurze zeit die Automatisierung außer Kraft setzen...)
Kann es sein dass das HUE alert in einem eigenen Thread läuft?
So ähnlich. Es läuft in der Hue Bridge.
Wäre es sinnvoll und möglich, ein zweites FHEM auf dem gleichen Pi laufen zu lassen und dann mit FHEM2FHEM zu arbeiten um für gewisse Ausführungen einen eigenen Thread zu erzeugen oder gibt's da noch eine bessere Lösung?
VG, Thomas
Ich habe mir mal Deine Sub angeschaut. Auf den ersten Blick hast Du es genau richtig gemacht. Du hast FHEM sleep verwendet und lediglich innerhalb der Schleife den FHEM Befehl zusammen gesetzt. Eigentlich sollte da gar nichts blockieren. Was hast Du denn für Lichter?
Ja, mich wundert es auch dass es blockiert, da ich ja das sleep nicht als extra Funktion in der Schleife habe.
Ich verwende das Modul WifiLight und habe da so einen 15 Euro WLAN-LED-Controller dran hängen.
An sich funktioniert es auch ganz gut. Nur sobald ich noch die Sonosausgabe mit dazu nehme, hängt mein FHEM komplett und ich kann dann für die 30 Sekunden auch nichts mehr in der Weboberfläche machen.
VG, Thomas
Ok, heißt also einzeln geht es super. nur mit einer weiteren ausgabe ist es blockierend?
Und wenn Du mal Deine Alarmroutine ohne Sonos im Skript machst und Sonos über die Weboberfläche aktivierst?
Wie genau läuft denn Sonos da mit rein? Auch über die Schleife? Vielleicht ist das zu viel.
ZitatOk, heißt also einzeln geht es super. nur mit einer weiteren ausgabe ist es blockierend?
Genau. Ich bin gerade auf Arbeit und muss heute Abend nochmal weiter testen.
Die Befehle werden vom Alarm Modul aus gesteuert. Du kannst dort mehrere Aktoren definieren und hinterlegst dort dann hintern einem Aktor den Befehl.
Ich vermute fast, dass es irgendwie mit "set Sonos_Wohnzimmer PlayURI $filename" zu tun hat. Denn es wird alles zur selben Zeit aufegrufen, das Licht geht an, dann spielt Sonos das 30 sekündige Alarm file ab und dann geht das wilde Geblinke los, was dann aber eher hastig wirkt, als müsse die Blinkfunktion jetzt was aufholen. ;D
VG, Thomas
Vielleicht das Sonos irgendwie in Deine Routine mit einbauen. So als aller erstes
sub
alarmSystemLEDControllerRedAlert() {
my $fhemAlarmCommand = "set Sonos blabla; ";
for (my $i=0; $i<10; $i++) {
$fhemAlarmCommand .= "set LEDController RGB FF0000 0.5; sleep 0.7; set LEDController off; sleep 0.3; "
}
fhem($fhemAlarmCommand);
}
Ist aber nur schlecht geraten. Test the Rest ;D
ZitatVielleicht das Sonos irgendwie in Deine Routine mit einbauen. So als aller erstes
Das hatte ich auch schon versucht gehabt. Brachte jedoch leider auch nichts. Deshalb habe ich noch nicht ganz raus, woran das genau scheitert.
Cool wäre, wenn FHEM in zukünftigen Versionen Multithreading unterstützen würde.
Evtl. dahingehend dass man zu einem FHEM command einen parameter mit angeben kann, der mitgibt ob es im Hauptthread ausgeführt werden soll oder im Parallelthread.
Problem wird dann wahrscheinlich nur sein, das Ganze wieder threadsafe hinzubekommen. Gerade wenn man mit dem Nebenthread auf Geräte des Hauptthreads zugreifen möchte.
Ich bin leider auch kein Perl Guru.
So,
ich habe das jetzt nochmal mit mehrerend Variationen getestet. Das Problem scheint der Aufruf der URI über Sonos zu sein. Sobald ich diesen Befehl drin habe, hängt das Licht und der FHEM Prozess rennt auf 100% bis die Audiodatei fertig ist.
Wenn ich Sonos rausnehme und stattdessen eine Nervige "Alarm Alarm Alarm ...." übers AMAD Device mache, läuft alles parallel wie es sein soll und der FHEM Prozess taumelt bei 26% umher.
Evtl. muss ich statt des Alarms über Sonos, dann doch eine Videobotschaft über meinen TV ausgeben. ;D
Hast du das aktuelle Sonos Modul welches gerade in einem separaten Thread besprochen wird? Kann mich entsinnen das da einiges geändert wurde.
Nein, ich war auf eine alte Version vom Juli zurück gegangen, in der Hoffnung dass diese keine Probleme mehr macht, da sie im Haus meiner Eltern ohne Probleme läuft.
Sonos scheint hier blockierend zu arbeiten. Das ist schon bisschen ätzend.
Du könntest Deinen Befehl in eine Blocking.pm Routine schicken, aber das ist ziemlich viel Aufwand für das bisschen Alarm ;D
ZitatDu könntest Deinen Befehl in eine Blocking.pm Routine schicken, aber das ist ziemlich viel Aufwand für das bisschen Alarm ;D
Ohje... ist das so kompliziert wie es klingt? Der Alarm über die Sonos Boxen klingt nämlich schon verdammt geil.
Es ist ein bisschen Aufwand. Sagen wir es so. Immerhin musst Du 3 Subroutinen erstellen und dann Blocking.pm implementieren
https://wiki.fhem.de/wiki/Blocking_Call
Würde dann aber nur den Sonos Sound als set Befehl absetzen. Ich kann Dir aber nicht mal sagen ob das überhaupt geht. Soweit ich das verstanden habe soll ja der Fork abgekapselt vom eigentlichen Hauptprozess sein. Keine Ahnung ob man da dann set Befehle absenden kann die auch funktionieren. Müsste man halt testen und schauen.
Oder Du versuchst mal raus zu finden wieso das ganze blockiert. Kann mir nicht vorstellen das das gewollt ist.
Guten Morgen.
Habe es jetzt nochmal mit einer deutlich längeren Audio-Datei probiert. Anscheinend läuft FHEM direkt nach dem Absetzen des set PlayURI oder set PlayURITemp für ca. 30 Sekunden auf 100%. Danach werden dann etwas ruckelig die anderen Befehle abgearbeitet, während die Audio-Datei weiter läuft und FHEM sich dann wieder normalisiert hat.
Evtl. muss ich mal schauen ob ich Intents für die Sonos-App finde, damit ich das notfalls über AMAD und Automagic starten kann.
VG, Thomas
Zitat von: ToM_ToM am 06 September 2017, 07:48:39
Guten Morgen.
Habe es jetzt nochmal mit einer deutlich längeren Audio-Datei probiert. Anscheinend läuft FHEM direkt nach dem Absetzen des set PlayURI oder set PlayURITemp für ca. 30 Sekunden auf 100%. Danach werden dann etwas ruckelig die anderen Befehle abgearbeitet, während die Audio-Datei weiter läuft und FHEM sich dann wieder normalisiert hat.
Evtl. muss ich mal schauen ob ich Intents für die Sonos-App finde, damit ich das notfalls über AMAD und Automagic starten kann.
VG, Thomas
Und wie sieht es mit der neusten Version des Sonos Modules aus? Lief das bei Dir gar nicht?
ZitatUnd wie sieht es mit der neusten Version des Sonos Modules aus? Lief das bei Dir gar nicht?[/quote
Doch, ich bin seit gestern wieder auf die neueste Version gewechselt und jetzt läuft alles wieder. Aber das Problem mit der Alarmanlage bleibt dennoch bestehen.
Zitat von: ToM_ToM am 06 September 2017, 08:04:13
ZitatUnd wie sieht es mit der neusten Version des Sonos Modules aus? Lief das bei Dir gar nicht?[/quote
Doch, ich bin seit gestern wieder auf die neueste Version gewechselt und jetzt läuft alles wieder. Aber das Problem mit der Alarmanlage bleibt dennoch bestehen.
Ich kann bei Gelegenheit mal schauen wie sich set Befehle in einem Forkprozess verhalten.
Das klingt interessant. :)
Ich habe jetzt nochmal paar grundsätzliche Tests mit Sonos und CPU-Last durchgeführt.
Sobald ich nur auf Play drücke, geht die CPU-Last auf 100% hoch. Dabei ist es egal ob es sich um einen Radiostream oder einen lokalen Stream handelt.
Wahrscheinlich verarbeitet das Sonos-Modul nach einem Play zu viele Befehle...? ???
VG, Thomas
Ich würde auf jeden Fall mal im Sonos Thread nachfragen. Eventuell ist es nur bei Dir und Du hast Hoffnung. An sonsten, wenn es ein generelles Problem ist würde ich ein zweites FHEM nehmen nur für Sonos.
Kann ich das zweite FHEM auf den gleichen Pi laufen lassen?