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:
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
Welcher ist
Zitat von: TobiasR am 11 August 2025, 11:12:22der 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
Zitat von: Prof. Dr. Peter Henning am 11 August 2025, 14:41:29Und 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 (https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF_ohne_steuernde_Attribute)).
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 (https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Angaben_im_Bedingungsteil):
ZitatEin 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".
Zitat von: passibe am 11 August 2025, 14:58:15Das sind doch einfach nur die Zeilenumbrüche aus dem raw editor lol
Es ist ein Auszug aus der fhem.cfg.
Stimmt, wegen setuuid. Aber ändert nichts :D
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.
Zitat von: TomLee am 11 August 2025, 15:00:22Es 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
Zitat von: passibe am 11 August 2025, 14:58:15Aber 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
Einmal noch OT.
Zitat von: Prof. Dr. Peter Henning am 11 August 2025, 19:47:45Zitat von: TomLee am 11 August 2025, 15:00:22Es 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 ...
Zitat von: passibe am 11 August 2025, 14:58:15Zitat von: Prof. Dr. Peter Henning am 11 August 2025, 14:41:29Und 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 (https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF_ohne_steuernde_Attribute)).
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 (https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Angaben_im_Bedingungsteil):
ZitatEin 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
Zitat von: Per am 11 August 2025, 18:55:33Das 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.
Zeig mal bitte die Bedienung, bei der in diesem Beispiel(!) "DOELSE" zum Tragen käme, egal ob virtuell oder reell.
Folgendes DOIF:
Internals:
CFGFN
DEF (
[test:"^sensor:.closed$"]
)
(
set test on
)
(
set test off
)
(
set test on
)
FUUID 689b08c1-f33f-fcd4-3de4-8b609af02fa7f0e8
MODEL FHEM
NAME beispiel
NOTIFYDEV test,global
NR 367
NTFY_ORDER 50-beispiel
STATE cmd_2
TYPE DOIF
VERSION 29460 2024-12-29 20:25:48
eventCount 6
READINGS:
2025-08-12 11:27:28 Device test
2025-08-12 11:27:28 cmd 2
2025-08-12 11:27:28 cmd_event test
2025-08-12 11:27:28 cmd_nr 2
2025-08-12 11:27:28 e_test_events sensor: cloosed
2025-08-12 11:27:03 mode enabled
2025-08-12 11:27:28 state cmd_2
Regex:
accu:
bar:
barAvg:
collect:
cond:
test:
0:
&STATE ^test$
attr:
cmdState:
wait:
waitdel:
condition:
0 ::EventDoIf('test',$hash,'^sensor:.closed$',1)
do:
0:
0 set test on
1 set test off
2 set test on
1:
helper:
NOTIFYDEV test,global
event sensor: cloosed
globalinit 1
last_timer 0
sleeptimer -1
timerdev test
timerevent sensor: cloosed
triggerDev test
DOIF_eventa:
cmd_nr: 2
cmd: 2
cmd_event: test
cmd_2
DOIF_eventas:
cmd_nr: 2
cmd: 2
cmd_event: test
state: cmd_2
timerevents:
sensor: cloosed
timereventsState:
sensor: cloosed
triggerEvents:
sensor: cloosed
triggerEventsState:
sensor: cloosed
internals:
readings:
trigger:
all test
uiState:
uiTable:
Attributes:
Wenn das ankommende Event nicht zur Regex passt (habe hier im Beispiel mit "cloosed" getriggert, statt mit "closed"), dann springt es in cmd_2. Und ich vermute, dass mit OPs DOIF genau das passiert ist, dass Event und Regex nicht zu einander passen.
Oder verstehen wir uns falsch?
Jein. Wenn es nicht passt, wird gar nicht getriggert. Also auch nicht nach DOELSE weitergereicht.
Schau doch mein list an. Was glaubst du, wie da sonst cmd_2 hingekommen ist, wenn nicht dadurch, dass es einen Trigger gab? Oder wenn du mir nicht glaubst, erstell einen dummy test, kopier die DEF aus meine list und teste es mit trigger test sensor: cloosed.
Ist es nicht so, dass der Ausdruck [test:"^sensor:.closed$"] gleichzeitig für den Trigger sorgt und die RegEx darin für den Match (cmd_1) oder Nichtmatch (cmd_2)?
Um es klarzustellen:
Bei Ereignisangaben der Art
DOIF (["^mydevice:^myreading bla"]) bei denen das Device durch eine Regex angegeben wird, gibt es keinen DOELSE-Fall, weil sonst alle anderen Events des Systems zu einem DOELSE-Fall führen würden.
Bei Angaben, bei denen das Device eindeutig angeben wird (nicht in Anführungszeichen), gibt es einen DOELSE-Fall, falls ein Event von dem angegeben Device kommt, aber der Rest der Abfrage nicht erfüllt ist.
z. B. bei Zustandsabfragen
DOIF ([mydevice:myreading] eq "bla")
bei setreading mydevice myreading bla2 weil das Reading einen anderen Inhalt hat
oder bei reinen Ereignistriggern z. B.
DOIF ([mydevice:"^myreading bla"])
bei setreading mydevice test bla
weil das Reading im Event nicht passt
Danke für die Klarstellung. Lag ich wohl "knapp daneben".