[gelöst] DOIF triggert nicht bei Wert gleich 0

[chunter1]

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.

Code Auswählen Erweitern

DOIF ([testDummy:state]) (setreading $SELF dummyValue $EVENT)

Welchen Verständnisfehler habe ich denn hier?

[Damian]

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.

Code Auswählen Erweitern

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

[chunter1]

Versteh ich noch nicht ganz.
In der FHEM Doku steht beim DOIF:

Bei 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?

[Damian]

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:""])

[chunter1]

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.

[Damian]

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

[FHEMAN]

Könnte er auch Folgendes schreiben?

Code Auswählen Erweitern


DOIF ([testDummy:state] != "") (setreading $SELF dummyValue $EVENT)


[Damian]

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.

[FHEMAN]

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")

[Damian]

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"])

[FHEMAN]

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)

[Damian]

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.:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

DOIF ([testDummy:state] =~ "on|off" and [testDummy2:state] =~ "on|off" )

[chunter1]

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?

[Damian]

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