Türklingel Meldung nicht ausgegeben (fhempy googlecast, castnow)

Begonnen von Carsten K., 12 Januar 2022, 10:36:44

Vorheriges Thema - Nächstes Thema

Carsten K.

Hallo Ihr Wissenden,

Folgender geplanter Ablauf:

  • Türklingel extern wird gedrückt (Sensor/Notify funktioniert)
  • im Notify:

    • Klingelsound auf Mi Spartspeaker abspielen (via system() mit castnow; funktioniert)
    • Text "es klingelt" wiedergeben (via Modul fhempy googlecast auf demselben Mi Smartspeaker; funktioniert NICHT)
Im Einzeltest funktioniert die Textausgabe.
Ein weiterer Befehl nach der Textausgabe wird abgearbeitet.

sub testSpeak()
{
  my $mesg = "es klingelt";
  my $fName = "/opt/fhem/sounds/doorbell_10.mp3";
  system (castnow "$fName" --address 192.168.178.102 --quiet);
  fhem "msg audio $mesg"; # keine Ausgabe
  fhem "msg push $mesg"; # Wird ausgegeben
}

Ich vermute, dass das Ausgabegerät (Mi Smartspeaker) noch irgendwie blockiert ist - aber das ist geraten...
Ein "sleep 5 ;" for fhem "msg audio $mesg"; hat nichts gebracht.
Zusätzlich zu system() habe ich es auch mit Backticks `cmd` und qx ausprobiert - keine Verbesserung...

Vielleicht hat jemand eine Idee?

Grüße,
Carsten
NUC FHEM on Debian, CC1101-USB-Lite 868MHz;
HM_HM_CC_RT_DN, HM-LC-SW1-PL2, HM_HM_TC_IT_WM_W_EU, HM-SEC-SC-2, HM-ES-TX-WM
FRITZ!DECT 200
Philips TV (Android), VuDuo2, VU Ultimo4k

Beta-User

Zitat von: Carsten K. am 12 Januar 2022, 10:36:44
Ich vermute, dass das Ausgabegerät (Mi Smartspeaker) noch irgendwie blockiert ist - aber das ist geraten...
...darauf würde ich auch tippen, und dazu die Frage stellen, wie du das konkret mit dem "sleep" gemacht hattest.

Tendenziell würde ich mal testweise diese Zeile in den Raum werfen:
fhem("msg push $mesg; sleep 5;; msg audio $mesg");
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

TomLee

Ich vermute das der Systemaufruf nicht klappt weil der "Inhalt" in Quotes stehen muss und dazu auch was im Log steht.

Versuch mal so:

system ("castnow $fName --address 192.168.178.102 --quiet &");

Beta-User

Zitat von: TomLee am 12 Januar 2022, 12:39:58
Ich vermute das der Systemaufruf nicht klappt weil der "Inhalt" in Quotes stehen muss und dazu auch was im Log steht.
Angeblich klappt das, gewundert hat mich das auch. Allerdings kommen mir dann die inneren Quotes "komisch" vor, tendenziell würde ich tippen, dass man die weglassen kann/sollte oder den string mit "qq" zusammenbauen "muss" (effektiverweise)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

TomLee

Ja, ich wollte die Quotes um die Variable noch wegnehmen, aber dann vergessen weil ich so vertieft in was anderem war.

Mein Fragezeichen ist das &, das ist doch nötig sonst ist der Systemaufruf doch blockierend, oder ?

Otto123

Zitat von: TomLee am 12 Januar 2022, 12:39:58
Ich vermute das der Systemaufruf nicht klappt weil der "Inhalt" in Quotes stehen muss und dazu auch was im Log steht.

Versuch mal so:

system ("castnow "$fName" --address 192.168.178.102 --quiet &");
Da müsste man wieder die inneren Quotes schützen :) \"$fname\" falls castnow diesen Namen wirklich in Quotes braucht. Oder andere nehmen  - oder wie Beta-User sagt qq nehmen :)

Und mit dem & am Ende ist generell gut, aber hier eventuell wieder Kontra weil dann castnow und msg auf dem gleichen Ausgabegerät parallel will.

Aber Carsten sagt, der Aufruf geht. Mir fiel noch ein man könnte die Reihenfolge tauschen udn sehen was passiert. Also erst msg und dann castnow.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Carsten K.

#6
Vielen Dank für die tollen Impulse.
Ich habe dadurch noch ein paar Varianten ausprobiert.
Abschließend hänge ich wieder an der Vermutung, dass sich der "castnow" System-Befehl (egal, ob über "system()" oder "qx()" oder Backticks) mit dem nächsten Befehl der letztlich auf's gleiche Gerät geht, beißt.

Aktuell habe diese Kombination als funktionierend gefunden:
system ("castnow $fName --address 192.168.178.102 --quiet");
system ("sleep 1 && perl /opt/fhem/fhem.pl 7072 \"msg audio $mesg\" &");

Durch die 2 system() Befehle konnte ich die FHEM-Oberfläche aus dem Spiel nehmen.
Falls der Vorschlag kommt "Hänge beide Befehler hintereinander": Habe ich probiert; funktioniert im OS, aber nicht aus FHEM heraus.
Es ist alles andere als sauber - aber ich habe ein Ergebnis ;)

Vielen Dank noch mal...
Carsten

p.s. ich denke darüber nach die beiden mp3-Dateien (der Text des 2. Befehls ist statisch) aneinanderzuhängen - dann hätte ich nur noch 1 system() Aufruf.
NUC FHEM on Debian, CC1101-USB-Lite 868MHz;
HM_HM_CC_RT_DN, HM-LC-SW1-PL2, HM_HM_TC_IT_WM_W_EU, HM-SEC-SC-2, HM-ES-TX-WM
FRITZ!DECT 200
Philips TV (Android), VuDuo2, VU Ultimo4k

TomLee

ZitatFalls der Vorschlag kommt "Hänge beide Befehler hintereinander": Habe ich probiert; funktioniert im OS

Wenn das so ist warum schreibst dann nicht alles in ein Bash-Script und rufst in FHEM nur das auf ?

Carsten K.

Zitat von: TomLee am 12 Januar 2022, 16:57:21
Wenn das so ist warum schreibst dann nicht alles in ein Bash-Script und rufst in FHEM nur das auf ?
Da hast Du recht, das ist geschickter - danke dafür
NUC FHEM on Debian, CC1101-USB-Lite 868MHz;
HM_HM_CC_RT_DN, HM-LC-SW1-PL2, HM_HM_TC_IT_WM_W_EU, HM-SEC-SC-2, HM-ES-TX-WM
FRITZ!DECT 200
Philips TV (Android), VuDuo2, VU Ultimo4k