Code

[Von-XS1-Nach-FHEM]

Ich bekomme noch immer eine Fehlermeldung mit diesem code, er spielt dem MP3 nicht ab mit diesem code

Irgendwie habe ich das comma oder der Abschluss falsch aber wo genau?

Code Auswählen Erweitern

Sensor_IR:on {
  if (Value("Klingel") eq "off") {
    fhem ("set Tor off"); }
"/usr/bin/mpg321 /opt/fhem/cache/templates/applaus.mp3"
}

Das hier geht zum Beispiel wohl:

Code Auswählen Erweitern

define Notify_mp3_open notify kontakt:open "/usr/bin/mpg321 /opt/fhem/cache/templates/applaus.mp3"


[Jamo]

Wie soll man Dir helfen, wenn Du die Fehlermeldung nicht postest?

[MadMax-FHEM]

Dass das mit den Anführungszeichen DIREKT funktioniert/funktionieren kann ist klar:

du bist da auf fhem-Ebene und führst dadurch ein "System-Kommando" aus...

In deinem "obegen Code" bist du in Perl...
...d.h. wie mit deinem set-Kommando musst du erst mal "nach" fhem.

EDIT: https://wiki.fhem.de/wiki/Klammerebenen

Also verm. so:

Code Auswählen Erweitern


fhem("\"/usr/bin/mpg321 /opt/fhem/cache/templates/applaus.mp3\"");


Die "Backslashes" damit die "inneren" Anführungszeichen für den Systemaufruf "escaped" werden...

EDIT: und ja, die Fehlermeldung wäre hilfreich. Und der Thread-Titel sagt ja quasi "alles"...

Gruß, Joachim

[Beta-User]

Wenn ihr schon Quotes, Systembefehle und Klammerebenen diskutiert:

- einfache kann man verwenden, um sich in diesem Fall (!) die Escapes zu sparen:

Code Auswählen Erweitern

fhem('"/usr/bin/mpg321 /opt/fhem/cache/templates/applaus.mp3"');
- Man kann auch aus Perl heraus Systembefehle aufrufen, ohne erst fhem evaluieren zu lassen, dass es sich um solche handet:
Müßte so gehen:

Code Auswählen Erweitern

qx("/usr/bin/mpg321 /opt/fhem/cache/templates/applaus.mp3");
Hat aber den Nachteil, dass das ggf. blockiert, dann das && dahinter, wir brauchen hier ja keine Rückmeldung. Sollte so gehen:

Code Auswählen Erweitern

qx("/usr/bin/mpg321 /opt/fhem/cache/templates/applaus.mp3 &&");

Was mir unklar ist: Der applaus soll immer kommen, aber das Tor nur aufgehen, wenn die "Klingel" off ist? (btw. Value sollte man zugunsten von ReadingsVal('Klingel','state','on') knicken).

[MadMax-FHEM]

Jep, in DIESEM Fall geht das

ABER: wenn dann als nächstes eine Variable ausgewertet werden soll...
...z.B.: $myMP3
...dann "steht" der TE wieder hier

Ich weiß das "escapen" ist nicht schön...

Irgendwo war ja auch mal was mit q{STRING} (glaube ich so war das)...
Bzw. qq{STRING}

Aber das ist mir zu "undurchsichtig"

Und da das "escapen" immer geht (sofern mal sich nicht "ver-escaped" ) mache ich das (meist) so...

Gut qx MIT dem & geht nat. auch...
...wird es vergessen und blockt was: tja

EDIT: zumindest ist jetzt (mehr oder weniger) alles "gesagt"... Muss sich der TE halt das für ihn passende "Konstrukt" raussuchen (oder sich mit den genannten "Stichworten" näher informieren)...

Gruß, Joachim

[betateilchen]

(btw. Value sollte man zugunsten von ReadingsVal('Klingel','state','on') knicken).

Das wäre mir komplett neu. Warum sollte man das knicken?

[MadMax-FHEM]

Knicken ist hier vielleicht ähnlich "hart" wie über "escapen" zu "lästern"

Aber ich nutze auch generell ReadingsVal bzw. ReadingsNum...
...weil das halt dann "immer" funktioniert...
...und immer ähnlich/gleich "aussieht"/"läuft"...

Ansonsten muss man halt schauen, dass Value nur auf state geht...
EDIT: korrigiert... Und damit ist die "Verwirrung" schon "perfekt"
Ansonsten muss man halt schauen, dass Value nur auf STATE geht...
...gab schon einige Threads wo genau dieses "Verständnis" das "Problem" war...

Gruß, Joachim

[betateilchen]

Ansonsten muss man halt schauen, dass Value nur auf state geht...

Das ist schonmal falsch.

Value(<device>) liefert den Inhalt de Internal STATE oder "" (default falls das Internal nicht existiert) zurück.

ReadingsVal(<device>,'state',<default>) liefert den Inhalt des Reading state (oder einen default-Wert) zurück.

Da beide Funktionen also völlig unterschiedliche Aufgaben haben, ist der Rat, das Eine durch das Andere zu ersetzen, für mich komplett kontraproduktiv. Beide Funktionen sind notwendig und haben ihre Daseinsberechtigung. Man muss sich eben nur im Klaren darüber sein, wann man welche Funktion benutzt. Insbesondere, da im Reading state und im Internal STATE unterschiedliche Werte durchaus stehen können.

Richtig wäre allenfalls eine Aussage wie "Man kann Value(<device>) durch InternalVal(<device>,'STATE',<default>) ersetzen. Was durchaus Sinn machen kann, wenn man gerne einen anderen default-Wert als "" bekommen möchte.

[KernSani]

Knicken ist hier vielleicht ähnlich "hart" wie über "escapen" zu "lästern"

Aber ich nutze auch generell ReadingsVal bzw. ReadingsNum...
...weil das halt dann "immer" funktioniert...
...und immer ähnlich/gleich "aussieht"/"läuft"...

Ansonsten muss man halt schauen, dass Value nur auf state geht...
...gab schon einige Threads wo genau dieses "Verständnis" das "Problem" war...

Gruß, Joachim

Und da haben wir's schon: Value geht auf das internal STATE

Edit:betateilchen war schneller

Kurz, weil mobil....

[CoolTux]

Das ist schonmal falsch.

Value(<device>) liefert den Inhalt de Internal STATE oder "" (default falls das Internal nicht existiert) zurück.

ReadingsVal(<device>,'state',<default>) liefert den Inhalt des Reading state (oder einen default-Wert) zurück.

Da beide Funktionen also völlig unterschiedliche Aufgaben haben, ist der Rat, das Eine durch das Andere zu ersetzen, für mich komplett kontraproduktiv. Beide Funktionen sind notwendig und haben ihre Daseinsberechtigung. Man muss sich eben nur im Klaren darüber sein, wann man welche Funktion benutzt. Insbesondere, da im Reading state und im Internal STATE unterschiedliche Werte durchaus stehen können.

Richtig wäre allenfalls eine Aussage wie "Man kann Value(<device>) durch InternalVal(<device>,'STATE',<default>) ersetzen. Was durchaus Sinn machen kann, wenn man gerne einen anderen default-Wert als "" bekommen möchte.

Damit hast Du Dir die Frage nach dem knicken ein bisschen selbst beantwortet.
Der Inhalt von Value kann einer sein mit dem man nicht rechnet. Allein schon wegen stateFormat. Wenn man das Monate später setzt und nicht mehr weiß das man da mal ein Value verwendet hat wundert man sich.

[MadMax-FHEM]

Das ist schonmal falsch.

Value(<device>) liefert den Inhalt de Internal STATE oder "" (default falls das Internal nicht existiert) zurück.

Jaja, sorry!

Aber: da ich das nicht nutze (jaja, keine "Ausrede"   )...

Hab's korrigiert...
...aber drum gibt's ja die "Verwirrung"...

Nix für ungut...

Gruß, Joachim

[betateilchen]

Damit hast Du Dir die Frage nach dem knicken ein bisschen selbst beantwortet.

Kein Stück. Die Abfrage eines Internals so pauschal durch die Abfrage eines Readings ersetzen zu wollen (und das auch noch zu empfehlen!) ist für ich völlig absurd.

Der Inhalt von Value kann einer sein mit dem man nicht rechnet. Allein schon wegen stateFormat. Wenn man das Monate später setzt und nicht mehr weiß das man da mal ein Value verwendet hat wundert man sich.

Genau deshalb hatte ich ganz klar geschrieben:

Beide Funktionen sind notwendig und haben ihre Daseinsberechtigung. Man muss sich eben nur im Klaren darüber sein, wann man welche Funktion benutzt. Insbesondere, da im Reading state und im Internal STATE unterschiedliche Werte durchaus stehen können.

[Beta-User]

OK, wir sind am Kern des Pudels: Value() ist dringend verdächtig, für Verwirrung zu sorgen . Deswegen sollte man diese Funktion nur dann nutzen, wenn man weiß, was man will. Was aber die meisten User _glauben_ abzufragen, ist das, was ich mit "zugunsten" genannt hatte. Denn das _wollen_ sie in der Regel wissen. Nur eine eher verschwindende Minderheit will _tatsächlich das_ haben, was Value() liefert, und sind dann irritiert, weil irgendwann irgendwas nicht mehr so funktioniert, wie sie _glauben_, dass es funktioniert...

Deswegen sollte man Einsteigern nur zwei von den drei Funktionen nahebringen, nämlich die zwei "exakteren".
[Nachtrag]
3 = ReadingsVal(), InternalVal() und Value()! Wer nur garantiert Zahlenwerte will, kann sowieso keine dieser drei verwenden (exakter: ohne Nachbearbeitung der Rückgabe...).
[/Nachtrag]

Ich hätte das vielleicht deutlicher schreiben können, aber letztendlich erfüllt der Post den erhofften Zweck mehr als voll, wenn wir mal wieder darüber Klarheit geschaffen haben .

Wer noch was zu Quotes (und q/qq) wissen will, kann hier reinsehen:
https://www.perlmonks.org/?node_id=401006

[betateilchen]

[Nachtrag]
ReadingsVal(), InternalVal() und Value()! Wer nur garantiert Zahlenwerte will, kann sowieso keine dieser drei verwenden (exakter: ohne Nachbearbeitung der Rückgabe...).
[/Nachtrag]

Du hast in Deiner Liste noch AttrVal() vergessen, da gilt das nämlich auch

Wenn es nur um angehängte Einheiten geht, muss man die Rückgabe nicht kompliziert nachbearbeiten, es reicht völlig, zum Funktionsergebnis einfach 0 aufzuaddieren.

Code Auswählen Erweitern

my $v = Value(<device>)+0;

Die eventuell im Log auftauchende Warnung, dass man gerade versucht, mit alphanumerischen Werten zu rechnen,  kann man getrost ignorieren. Denn genau das tut man ja ganz bewußt.

[Beta-User]

Jein. Es geht weniger um die Frage, wie die Syntax aufgebaut ist, sondern eher darum, wie was (meistens...) zusammenhängt.
In der Regel wird STATE aus state abgeleitet, beides hat also mehr oder weniger direkt viel miteinander zu tun, und nur diese drei greifen (meistens) direkt oder indirekt auf "state" zu. Genauer gesagt ist es _meistens_ deckungsgleich, was rauskommt (vorausgesetzt, der Wert existiert...), weswegen es gerade zu der Verwechslung 'Value() fragt "state" ab' kommt.
Wieso fehlt also deiner Meinung nach AttrVal() in "meiner" Liste?
Das einzige Attribut, das mir grade so einfällt, ist stateFormat, aber dessen AttrVal-Rückgabe steht irgendwie nur sehr bedingt in der Reihe...