cmd_1 versus cmd_2

[TobiasR]

Hallo,

ich brauche mal Hilfe.
Wieso wie lege ich fest ob eine Funktion in DOIF mit "set xyz cmd_1" oder "set xyz cmd_2" ausgeführt werden soll?

Hintergrund:
Wenn mein Klingeltaster betätigt wird, wurde bisher immer eine Telegramnachricht erzeugt.
Seit gestern ist das nicht mehr der Fall und ich habe jetzt rausgefunden dass offensichtlich seit gestern der Befehl nur noch über cmd_2 raus geht.
Aber wo lege ich das fest?

Hier die Sequenz:

Code Auswählen Erweitern

define Hofklingel DOIF (\
[K_Klingel:"^sensor:.closed$"]\
) \
(\
get WebCamHof image\
) \
(\
set Telegram sendImage @Tobias /opt/fhem/www/webcam/WebCamHof_snapshot.jpg Es hat gerade am Hoftor geklingelt\
)\
(\
set Telegram sendImage @Tobias /opt/fhem/www/webcam/WebCamHof_snapshot_2.jpg\
)\
\

setuuid Hofklingel 68960241-f33f-f1f8-4a89-1bcaf9bf4d25b116

[Prof. Dr. Peter Henning]

Welcher ist

der Befehl

?
Und was heißt "rausgehen"?
Und warum stehen in der Definition die ganzen "\", das ist ziemlich unwartbar.
Es fehlen außerdem Angaben über sonstige Attribute, z.B. Zeitverzögerungen.

LG

pah

[passibe]

Und warum stehen in der Definition die ganzen "\", das ist ziemlich unwartbar.

Das sind doch einfach nur die Zeilenumbrüche aus dem raw editor lol
Aber zur Abwechslung vielleicht mal ein Versuch, das eigentliche Problem zu lösen:

@TobiasR, cmd_2 ist der zweite Bedingungszweig (zum Begriff siehe hier).

Weil dein DOIF nur einen DOIF-Zweig und kein DOELSE enthält, fällt es, wenn die im DOIF-Zweig angegebene Bedingung unwahr ist, in ein "internes" bzw. unsichtbares DOELSE zurück. Das ist das cmd_2, was du siehst.

Dazu aus dem Wiki:

Ein DOIF mit nur einem Bedingungszweig enthält ein internes DOELSE, d.h. bei unwahrer Bedingung und vorhandenem Auslöser findet ein Statuswechsel auf cmd_2 statt.

Die von dir in der Klammer angegebenen Kommandos (get WebCamHof, set Telegram, set Telegram) sind cmd 1.1, 1.2 und 1.3, nicht etwa cmd_1, cmd_2 und cmd_3. Also nochmal: Bei cmd_n bezeichnet n immer den Bedingungszweig.

Im Prinzip heißt das hier einfach, dass deine Bedingung [K_Klingel:"^sensor:.closed$"] nicht wahr wird. Du triggerst also nicht auf das richtige Event. Wieso das bis jetzt funktioniert hat, keine Ahnung. Irgendwas muss sich da geändert haben. Schau nochmal im Eventmonitor, ob tatsächlich auch dieses Event von K_Klingel ankommt, wenn jemand klingelt, bzw. arbeite der Übersichtlichkeit halber vielleicht sowieso lieber einfach mit setmagic und eq statt mit regex, also: [K_Klingel:sensor] eq "closed".

[TomLee]

Das sind doch einfach nur die Zeilenumbrüche aus dem raw editor lol

Es ist ein Auszug aus der fhem.cfg.

[passibe]

Stimmt, wegen setuuid. Aber ändert nichts

[Per]

Das interne DOELSE zieht nicht, weil es keinen Trigger gibt, dessen Bedienung unwahr ist. Es gibt nur einen Event Trigger und der ist immer wahr, wenn er auslöst.

[Prof. Dr. Peter Henning]

Es ist ein Auszug aus der fhem.cfg.

   
Leute, das ist klar - aber das muss man hier nicht posten. Wie fett müssen wir den Button "Raw definition" denn machen, damit er benutzt wird?

LG

pah

[Prof. Dr. Peter Henning]

Aber zur Abwechslung vielleicht mal ein Versuch, das eigentliche Problem zu lösen:
@TobiasR, cmd_2 ist der zweite Bedingungszweig

Aber ganz sicher nicht so, wie der TE es gepostet hat - nämlich als "set xyz cmd_1/2". Darum muss der TE doch bitte etwas stringenter in seinen Angaben sein, sonst weiß kein Mensch, wie er ihm helfen soll.

LG

pah

[TomLee]

Einmal noch OT.

Es ist ein Auszug aus der fhem.cfg.

   
Leute, das ist klar - aber das muss man hier nicht posten. Wie fett müssen wir den Button "Raw definition" denn machen, damit er benutzt wird?

LG

pah

"Raw definition" ist ein Wert einer Kombi.-/Auswahlliste der default gar nicht zu sehen ist.

"Copy for forum.fhem.de" ist nur fett, weil es ein Link ist.

Verstehe die Argumentation nicht ...

[TobiasR]

Und warum stehen in der Definition die ganzen "\", das ist ziemlich unwartbar.

Das sind doch einfach nur die Zeilenumbrüche aus dem raw editor lol
Aber zur Abwechslung vielleicht mal ein Versuch, das eigentliche Problem zu lösen:

@TobiasR, cmd_2 ist der zweite Bedingungszweig (zum Begriff siehe hier).

Weil dein DOIF nur einen DOIF-Zweig und kein DOELSE enthält, fällt es, wenn die im DOIF-Zweig angegebene Bedingung unwahr ist, in ein "internes" bzw. unsichtbares DOELSE zurück. Das ist das cmd_2, was du siehst.

Dazu aus dem Wiki:

Ein DOIF mit nur einem Bedingungszweig enthält ein internes DOELSE, d.h. bei unwahrer Bedingung und vorhandenem Auslöser findet ein Statuswechsel auf cmd_2 statt.

Die von dir in der Klammer angegebenen Kommandos (get WebCamHof, set Telegram, set Telegram) sind cmd 1.1, 1.2 und 1.3, nicht etwa cmd_1, cmd_2 und cmd_3. Also nochmal: Bei cmd_n bezeichnet n immer den Bedingungszweig.

Im Prinzip heißt das hier einfach, dass deine Bedingung [K_Klingel:"^sensor:.closed$"] nicht wahr wird. Du triggerst also nicht auf das richtige Event. Wieso das bis jetzt funktioniert hat, keine Ahnung. Irgendwas muss sich da geändert haben. Schau nochmal im Eventmonitor, ob tatsächlich auch dieses Event von K_Klingel ankommt, wenn jemand klingelt, bzw. arbeite der Übersichtlichkeit halber vielleicht sowieso lieber einfach mit setmagic und eq statt mit regex, also: [K_Klingel:sensor] eq "closed".

Vielen Dank für deine Unterstützung. Wundert mich, ich habe das schon seit 5 Jahren so laufen.
Ich muss da noch mal einsteigen. Mit deiner Erklärung bekomme ich das jetzt aber hin

[passibe]

Das interne DOELSE zieht nicht, weil es keinen Trigger gibt, dessen Bedienung unwahr ist. Es gibt nur einen Event Trigger und der ist immer wahr, wenn er auslöst.

Ne, teste das mal. Das geht schon in DOELSE (oder woher sonst soll cmd_2 kommen?). Glaube das liegt daran, dass das Event mit K_Klingel: gematched wird und dann halt nur die Regex falsch ist -> zack, DOELSE.