Phänomen bei der Auswertung von Readings

Begonnen von PatrickR, 21 Juni 2019, 21:09:09

Vorheriges Thema - Nächstes Thema

PatrickR

Mahlzeit!

Ich verwende folgendes DOIF:

defmod D_P_Wohnung__HA.FensterTueren__alert DOIF ([EG.FL.Eingangstuer] eq "closed") ()\
DOELSEIF ([$SELF:cmd] == 1 and [HA.FensterTueren] ne "closed" and [P_Wohnung] eq "absent") ({\
fhem(sprintf('set Pushover_pr_jr msg "Fenster & Türen" "Status: %s" "" 0 ""',"[HA.FensterTueren]"));; \
})
attr D_P_Wohnung__HA.FensterTueren__alert cmdState waiting for absent and open windows|notified and waiting for main door|waiting for main door
attr D_P_Wohnung__HA.FensterTueren__alert event-on-change-reading .*
attr D_P_Wohnung__HA.FensterTueren__alert wait 0:120

Ziel ist, nach 120 Sekunden Abwesenheit und bei offenen Fenstern eine Pushnachricht zu versenden. Das Ganze soll jedoch nur ausgelöst werden, wenn nach der letzten Auslösung die Eingangstür geschlossen wurde.

Das funktioniert sehr gut. Nun hatte ich allerdings zweimal das Phänomen, dass in der Pushnachricht als Status "closed" stand, was wegen der entsprechenden Bedingung eigentlich nie passieren dürfte. Wechselt der Status zwischen der Prüfung der Bedingung und dem sprintf-Befehl oder was übersehe ich?

Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

amenomade

[HA.FensterTueren] "open" => wechsel auf cmd_2 => timer 120 Sek und dann Nachricht
Wenn inzwischen [HA.FensterTueren] "closed", passiert erstmal nichts, da keine andere Bedingung wahr ist. Timer läuft weiter, und am Ende der 120 Sekunden  kriegst Du die Nachricht.

Wenn Du in diesem Fall die Nachricht nicht empfangen möchstest, musst Du eine andere Bedingung haben, die das Wechseln des Zustands erlaubt.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

PatrickR

Hi!

Zitat von: amenomade am 21 Juni 2019, 21:27:16
Wenn Du in diesem Fall die Nachricht nicht empfangen möchstest, musst Du eine andere Bedingung haben, die das Wechseln des Zustands erlaubt.
Danke für die Anregung. Habe nun ein leeres DOELSE eingebaut.

Ich ging bislang davon aus, dass es bei DOIF immer ein implizites, leeres DOELSE gibt. Andernfalls würden DOIFs mit nur einem Fall nur einmal schalten.

Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

Ellert

Zitat von: PatrickR am 22 Juni 2019, 13:54:44
Andernfalls würden DOIFs mit nur einem Fall nur einmal schalten.
Deshalb gibt es in nur genau diesem Fall ein implizites, leeres DOELSE.