Wenn beim Dummy "testDummy" den Wert 0 setze, wird folgendes DOIF nicht ausgeführt obwohl das Event vorhanden ist.
Bei Werten ungleich 0 jedoch funktioniert es.
DOIF ([testDummy:state]) (setreading $SELF dummyValue $EVENT)
Welchen Verständnisfehler habe ich denn hier?
Zitat von: chunter1 am 29 Oktober 2021, 21:14:28
Wenn beim Dummy "testDummy" den Wert 0 setze, wird folgendes DOIF nicht ausgeführt obwohl das Event vorhanden ist.
Bei Werten ungleich 0 jedoch funktioniert es.
DOIF ([testDummy:state]) (setreading $SELF dummyValue $EVENT)
Welchen Verständnisfehler habe ich denn hier?
([testDummy:state]) entspricht ([testDummy:state] !=0), daher ist es bei 0 nicht wahr
Versteh ich noch nicht ganz.
In der FHEM Doku steht beim DOIF:
ZitatBei Angaben der Art [<Device>:<Reading>] wird das Modul getriggert, wenn ein Ereignis zum angegebenen Device und Reading kommt.
Demnach müsste das DOIF doch unabhängig vom Wert immer auf das Event hin triggern?
Zitat von: chunter1 am 29 Oktober 2021, 21:54:12
Versteh ich noch nicht ganz.
In der FHEM Doku steht:
Demnach müsste das DOIF doch unabhängig vom Wert immer auf das Event hin triggern?
es wird ja getriggert und dennoch ist die Bedingung falsch ;)
Du kannst reine Event-Trigger nutzen:
([testDummy:""])
Zitat von: Damian am 29 Oktober 2021, 22:03:35
es wird ja getriggert und dennoch ist die Bedingung falsch ;)
Du kannst reine Event-Trigger nutzen:
([testDummy:""])
Danke! Jetzt funktionierts.
Jetzt muss ich alle DOIFs neu durchdenken. :-\
Ich fürchte auch, dass das vielen Leuten hier ebenfalls nicht bewusst ist.
Zitat von: chunter1 am 29 Oktober 2021, 22:10:51
Danke! Jetzt funktionierts.
Jetzt muss ich alle DOIFs neu durchdenken. :-\
Ich fürchte auch, dass das vielen Leuten hier ebenfalls nicht bewusst ist.
ja, siehe https://forum.fhem.de/index.php/topic,123549.msg1181320.html#msg1181320
Könnte er auch Folgendes schreiben?
DOIF ([testDummy:state] != "") (setreading $SELF dummyValue $EVENT)
Nicht zu empfehlen. Es sind alles Perleigenarten.
Strings werden nicht mit !=, sondern mit ne (not equal) verglichen, sonst gibt es eine Warnung.
Wenn state immer einen Wert beinhaltet, dann sollte
DOIF ([testDummy:state] ne "") ..
auch funktionieren.
Zitat von: Damian am 29 Oktober 2021, 22:48:20
Wenn state immer einen Wert beinhaltet, dann sollte
DOIF ([testDummy:state] ne "") ..
auch funktionieren.
So meinte ich es eigentlich auch.
Ich nutze in letzter Zeit oft nur das Triggern unabhängig vom Wert, war mir aber immer unsicher ob der Sinnhaftigkeit. Wahrscheinlich muss ich nur mal warm werden mit den Regex Event Triggern.
Also z. B
DOIF ([testDummy:state] =~ "on|off")
Zitat von: FHEMAN am 29 Oktober 2021, 22:59:31
So meinte ich es eigentlich auch.
Ich nutze in letzter Zeit oft nur das Triggern unabhängig vom Wert, war mir aber immer unsicher ob der Sinnhaftigkeit. Wahrscheinlich muss ich nur mal warm werden mit den Regex Event Triggern.
Also z. B
DOIF ([testDummy:state] =~ "on|off")
Das ist zwar ein RegEx-Vergleich aber es ist kein reiner Ereignistrigger, sondern Abfrage eine Readings (Zustands)
Ein Ereignistrigger ist beim DOIF ja nur wahr oder falsch, da muss man nichts vergleichen:
hier also z. B.
DOIF ([testDummy:"on|off"])
Zitat von: Damian am 29 Oktober 2021, 23:30:06
Das ist zwar ein RegEx-Vergleich aber es ist kein reiner Ereignistrigger, sondern Abfrage eine Readings (Zustands)
Ja, ich bin mit den Eventtriggern immer noch zurückhaltend, wegen der vielen Möglichkeiten und damit Fehleranfälligkeit.
Macht es im Modul insbesondere aus Performancesicht einen Unterschied, welchen Trigger ich wähle? Oder wird sowieso jedes Event ausgewertet und komplexere Regex Konstruktionen sind dann eben aufwendiger auszuwerten?
Also ob
DOIF ([testDummy:"on|off"]) oder
DOIF ([testDummy:state] =~ "on|off") ?
(Annahme: attr testDummy event-on-change-reading state)
Die Performance/Performanceverbrauch ist vergleichbar. Es ist einfach Frage der Anwendung:
Wenn du zwei Dinge mit UND sinnvoll verknüpfen willst, dann ist ein Trigger mit Readingauswertung (Zustand) der richtige Weg. Bei ODER ist es oft andersherum.
Bsp.:
DOIF ([testDummy:"on|off"] and [testDummy2:"on|off"] )
ist nicht sinnvoll, da beide Ereignisse nicht gleichzeitig triggern können, also kann diese Bedingung niemals wahr werden.
alternativ:
DOIF ([testDummy:state] =~ "on|off" and [testDummy2:state] =~ "on|off" )
Ich hätte noch eine Frage zu den events und readings.
Angenommen mein device "testDummy" besitzt zwei readings (readingA und readingB) welche zu unterschiedlichen Zeitpunkten ein event auslösen.
Wie müsste das DOIF aussehen das nur auf das Event mit readingA reagiert?
Zitat von: chunter1 am 30 Oktober 2021, 21:48:06
Ich hätte noch eine Frage zu den events und readings.
Angenommen mein device "testDummy" besitzt zwei readings (readingA und readingB) welche zu unterschiedlichen Zeitpunkten ein event auslösen.
Wie müsste das DOIF aussehen das nur auf das Event mit readingA reagiert?
Das Reading ist ja ein Teil des Events, also:
[testDummy:"^readingA"]
das bedeutet Even von testDummy, das Event beginnt mit readingA, der Rest ist egal.
ist hier aber genau erklärt: https://fhem.de/commandref_DE.html#DOIF_Ereignissteuerung_ueber_Auswertung_von_Events