Guten Morgen Zusammen,
ich verstehe noch nicht warum ein Doif bei mir immer doppelt auslöst... Ich habe einen Bewegungsmelder (open/close) und will je nach Uhrzeit eine Meldung auslösen.
bekomme aber bei Bewegung UND Rückfall (auf close) nach Bewegung (nach 30 Sek) die gleiche Meldung..
Hier meine Doif Definition:
define test DOIF
( ([Sensor] eq "open") and ([Residents] eq "absent") ) ( set Telegram message 1 )
DOELSEIF
( ([Sensor] eq "open") and [18:30-07:00] ) ( set Telegram message 2)
DOELSEIF
( ([Sensor] eq "open") ) ( set Telegram silentmsg 3 )
DOELSE
( set test initialize)
Ich habe das DOELSE eingebaut um etwas zu haben was den Rückfall auffängt..
habe kein attr DO definiert
Hi,
1. Bitte Eventmonitor aufmachen und dort schauen wie die Events aussehen!
Im list des DOIF sieht man eventuell Fehler!
Sowas ist Mist -> (Sensor]
Gruß Otto
Hallo Otto,
danke für Deine Nachricht... könntest Du mir bzgl. des Mists helfen? wenn Du den Namen "Sensor" meinst, ja der ist gekürzt (auch nachfolgend), damits leserlich wird...(war zumindest der Plan)
ich hoffe ich habe nun alle Events die hier dazugehören rausgepickt:
Zitat
2019-01-03 09:49:02 ZWave Sensor_M1 alarm: HomeSecurity: Motion Detection - Unknown Location
2019-01-03 09:49:02 TelegramBot Telegram silentmsg Sensor_M1_3
2019-01-03 09:49:02 DOIF Sensor_M1.Doif.Telegram cmd_nr: 3
2019-01-03 09:49:02 DOIF Sensor_M1.Doif.Telegram cmd: 3
2019-01-03 09:49:02 DOIF Sensor_M1.Doif.Telegram cmd_event: Sensor_M1
2019-01-03 09:49:02 DOIF Sensor_M1.Doif.Telegram cmd_3
2019-01-03 09:49:02 ZWave Sensor_M1 open
2019-01-03 09:49:02 ZWave Sensor_M1 reportedState: open
2019-01-03 09:49:02 ZWave Sensor_M1 open
2019-01-03 09:49:02 ZWave Sensor_M1 reportedState: open
2019-01-03 09:49:03 TelegramBot Telegram sentMsgResult: SUCCESS
2019-01-03 09:49:08 DOIF Sensor_M1.Doif.Telegram mode: enabled
2019-01-03 09:49:08 DOIF Sensor_M1.Doif.Telegram initialize
2019-01-03 09:49:08 DOIF Sensor_M1.Doif.Telegram cmd_nr: 4
2019-01-03 09:49:08 DOIF Sensor_M1.Doif.Telegram cmd: 4
2019-01-03 09:49:08 DOIF Sensor_M1.Doif.Telegram cmd_event: Residents
2019-01-03 09:49:08 DOIF Sensor_M1.Doif.Telegram cmd_4
2019-01-03 09:49:42 TelegramBot Telegram silentmsg Sensor_M1_3
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_nr: 3
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd: 3
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_event: Sensor_M1
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_3
2019-01-03 09:49:42 ZWave Sensor_M1 alarm: HomeSecurity: Event cleared: Motion Detection - Unknown Location, arg 0108
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram mode: enabled
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram initialize
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_nr: 4
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd: 4
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_event: Sensor_M1
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_4
2019-01-03 09:49:42 ZWave Sensor_M1 closed
2019-01-03 09:49:42 ZWave Sensor_M1 reportedState: closed
2019-01-03 09:49:42 ZWave Sensor_M1 closed
2019-01-03 09:49:42 ZWave Sensor_M1 reportedState: closed
2019-01-03 09:49:43 TelegramBot Telegram sentMsgResult: SUCCESS
Mist ist das hier (Sensor]
Das sollte so aussehen ([Sensor] ...
Wenn Du mit gekürzt gefaked meinst - das solltest Du lassen. Es wird nicht leserlich es wird nur faul ...
Zwei Events - alles richtig mit deinem DOIF ;D
2019-01-03 09:49:02 ZWave Sensor_M1 open
2019-01-03 09:49:02 ZWave Sensor_M1 reportedState: open
2019-01-03 09:49:02 ZWave Sensor_M1 open
2019-01-03 09:49:02 ZWave Sensor_M1 reportedState: open
Hast Du beim ZWave Sensor_M1 event-on-change-reading gesetzt?
attr ZWave Sensor_M1 event-on-change-reading .*
Das würde doppelte Events verhindern. Oder meinst Du was anderes?
Den dritten Zweig halte ich für problematisch ... Kann aber gehen wenn es richtig geschrieben ist.
Er fällt auf 4 wegen deinem DOELSE und dann beim close wieder auf 3.
Gruß Otto
Hallo Otto,
danke für Deine Hilfe! das (Sensor] entstand durch das Kürzen des Sensor-Namens im Original ist alles gut. (sorry! hab ich oben jetzt auch ausgebessert)
Die Zwei Events habe ich gesehen (sind mir auch unklar), aber die lösen aber nicht die Telegram-Nachricht aus. (m.M. nach weil kein "Do always" gesetzt ist)
Telegramm-Nachrichten: Da geht eine um 09:49:02 raus, als der Sensor auf "open" geht und eine um 09:49:42 als er zurück auf "close" geht... das ist es was ich nicht verstehe...
Das event-on-reading habe ich noch nicht gesetzt, aber hast Du zum open/close eine Idee?
Und ja es soll immer eine Nachricht kommen, wenn der Sensor eine Bewegung meldet, nur die Nachricht soll sich unterscheiden.
das DOELSE sollte das Rücksetzen in einen neutralen Status auslösen, wenn der Sensor auf "close" geht und damit eigentlich keine Bedingung erfüllt ist
Du musst ein ECHTES list in beiden Zuständen machen. Also wenn open und wenn closed - vielleicht sieht man da was passiert.
Gruß Otto
ok, mach ich - nur zur Sicherheit:
list doif_name und dann die rund zwei Seiten Text hier reinkopieren? (->anfänger<-)
in Codetags - die # Taste über dem :-X
:D
ok, also mal Lists der beiden Zustände:
closed
Internals:
DEF (
([OG_Flur_Sensor_M1] eq "open") and
([Residents] eq "absent")
)
( set TelegramBot message ALARM - OG_Flur1 - both absent)
DOELSEIF
(
([OG_Flur_Sensor_M1] eq "open") and
[18:30-07:00]
)
( set TelegramBot message OG_Flur2 sleeptime)
DOELSEIF
(
([OG_Flur_Sensor_M1] eq "open")
)
( set TelegramBot silentmsg OG_Flur3 silent)
DOELSE
( set OG_Flur_Sensor_M1.Doif.Telegram initialize)
MODEL FHEM
NAME OG_Flur_Sensor_M1.Doif.Telegram
NR 312
NTFY_ORDER 50-OG_Flur_Sensor_M1.Doif.Telegram
STATE cmd_4
TYPE DOIF
READINGS:
2019-01-03 11:15:46 Device Residents
2019-01-03 09:49:42 cmd 4
2019-01-03 09:49:42 cmd_event OG_Flur_Sensor_M1
2019-01-03 09:49:42 cmd_nr 4
2019-01-03 10:42:46 e_OG_Flur_Sensor_M1_STATE closed
2019-01-03 11:15:46 e_Residents_STATE home
2019-01-03 09:49:42 mode enabled
2019-01-03 09:49:42 state cmd_4
2019-01-03 07:00:00 timer_01_c02 03.01.2019 18:30:00
2019-01-03 07:00:00 timer_02_c02 04.01.2019 07:00:00
Regex:
attr:
cmdState:
wait:
waitdel:
condition:
0 (::InternalDoIf($hash,'OG_Flur_Sensor_M1','STATE') eq "open") and (::InternalDoIf($hash,'Residents','STATE') eq "absent")
1 (::InternalDoIf($hash,'OG_Flur_Sensor_M1','STATE') eq "open") and ::DOIF_time($hash,0,1,$wday,$hms)
2 (::InternalDoIf($hash,'OG_Flur_Sensor_M1','STATE') eq "open")
days:
devices:
0 OG_Flur_Sensor_M1 Residents
1 OG_Flur_Sensor_M1
2 OG_Flur_Sensor_M1
all OG_Flur_Sensor_M1 Residents
do:
0:
0 set TelegramBot message ALARM - OG_Flur1 - both absent
1:
0 set TelegramBot message OG_Flur2 sleeptime
2:
0 set TelegramBot silentmsg OG_Flur3 silent
3:
0 set OG_Flur_Sensor_M1.Doif.Telegram initialize
helper:
event durTimerPresence_cr: 253,durTimerPresence: 04:12:59
globalinit 1
last_timer 2
sleeptimer -1
timerdev Residents
timerevent durTimerPresence_cr: 253,durTimerPresence: 04:12:59
triggerDev Residents
DOIF_eventas:
cmd_nr: 4
cmd: 4
cmd_event: OG_Flur_Sensor_M1
state: cmd_4
timerevents:
durTimerPresence_cr: 253
durTimerPresence: 04:12:59
timereventsState:
durTimerPresence_cr: 253
durTimerPresence: 04:12:59
triggerEvents:
durTimerPresence_cr: 253
durTimerPresence: 04:12:59
triggerEventsState:
durTimerPresence_cr: 253
durTimerPresence: 04:12:59
internals:
0 OG_Flur_Sensor_M1:STATE Residents:STATE
1 OG_Flur_Sensor_M1:STATE
2 OG_Flur_Sensor_M1:STATE
all OG_Flur_Sensor_M1:STATE Residents:STATE
interval:
0 -1
1 0
intervalfunc:
itimer:
localtime:
0 1546536600
1 1546581600
perlblock:
readings:
realtime:
0 18:30:00
1 07:00:00
time:
0 18:30:00
1 07:00:00
timeCond:
0 1
1 1
timer:
0 0
1 0
timers:
1 0 1
trigger:
triggertime:
1546536600:
localtime 1546536600
hash:
1546581600:
localtime 1546581600
hash:
uiState:
uiTable:
Attributes:
room OG_Flur
und
open
Internals:
DEF (
([OG_Flur_Sensor_M1] eq "open") and
([Residents] eq "absent")
)
( set TelegramBot message ALARM - OG_Flur1 - both absent )
DOELSEIF
(
([OG_Flur_Sensor_M1] eq "open") and
[18:30-07:00]
)
( set TelegramBot message OG_Flur2 sleeptime)
DOELSEIF
(
([OG_Flur_Sensor_M1] eq "open")
)
( set TelegramBot silentmsg OG_Flur3 silent)
DOELSE
( set OG_Flur_Sensor_M1.Doif.Telegram initialize)
MODEL FHEM
NAME OG_Flur_Sensor_M1.Doif.Telegram
NR 312
NTFY_ORDER 50-OG_Flur_Sensor_M1.Doif.Telegram
STATE cmd_4
TYPE DOIF
READINGS:
2019-01-03 11:17:48 Device Residents
2019-01-03 11:17:48 cmd 4
2019-01-03 11:17:48 cmd_event Residents
2019-01-03 11:17:48 cmd_nr 4
2019-01-03 11:17:36 e_OG_Flur_Sensor_M1_STATE open
2019-01-03 11:17:48 e_Residents_STATE home
2019-01-03 11:17:48 mode enabled
2019-01-03 11:17:48 state cmd_4
2019-01-03 07:00:00 timer_01_c02 03.01.2019 18:30:00
2019-01-03 07:00:00 timer_02_c02 04.01.2019 07:00:00
Regex:
attr:
cmdState:
wait:
waitdel:
condition:
0 (::InternalDoIf($hash,'OG_Flur_Sensor_M1','STATE') eq "open") and (::InternalDoIf($hash,'Residents','STATE') eq "absent")
1 (::InternalDoIf($hash,'OG_Flur_Sensor_M1','STATE') eq "open") and ::DOIF_time($hash,0,1,$wday,$hms)
2 (::InternalDoIf($hash,'OG_Flur_Sensor_M1','STATE') eq "open")
days:
devices:
0 OG_Flur_Sensor_M1 Residents
1 OG_Flur_Sensor_M1
2 OG_Flur_Sensor_M1
all OG_Flur_Sensor_M1 Residents
do:
0:
0 set TelegramBot message ALARM - OG_Flur1 - both absent
1:
0 set TelegramBot message OG_Flur2 sleeptime
2:
0 set TelegramBot silentmsg OG_Flur3 silent
3:
0 set OG_Flur_Sensor_M1.Doif.Telegram initialize
helper:
event durTimerPresence_cr: 255,durTimerPresence: 04:15:01
globalinit 1
last_timer 2
sleeptimer -1
timerdev Residents
timerevent durTimerPresence_cr: 255,durTimerPresence: 04:15:01
triggerDev Residents
DOIF_eventas:
cmd_nr: 4
cmd: 4
cmd_event: Residents
state: cmd_4
timerevents:
durTimerPresence_cr: 255
durTimerPresence: 04:15:01
timereventsState:
durTimerPresence_cr: 255
durTimerPresence: 04:15:01
triggerEvents:
durTimerPresence_cr: 255
durTimerPresence: 04:15:01
triggerEventsState:
durTimerPresence_cr: 255
durTimerPresence: 04:15:01
internals:
0 OG_Flur_Sensor_M1:STATE Residents:STATE
1 OG_Flur_Sensor_M1:STATE
2 OG_Flur_Sensor_M1:STATE
all OG_Flur_Sensor_M1:STATE Residents:STATE
interval:
0 -1
1 0
intervalfunc:
itimer:
localtime:
0 1546536600
1 1546581600
perlblock:
readings:
realtime:
0 18:30:00
1 07:00:00
time:
0 18:30:00
1 07:00:00
timeCond:
0 1
1 1
timer:
0 0
1 0
timers:
1 0 1
trigger:
triggertime:
1546536600:
localtime 1546536600
hash:
1546581600:
localtime 1546581600
hash:
uiState:
uiTable:
Attributes:
room OG_Flur
Hm ... das DOIF ist so noch sehr unvollständig. Es reagiert bspw. auch wenn der SENSOR "open" ist und die Startzeit erreicht ist oder der Status der Residents sich ändert. Vor die Nebenbedingungen gehört also noch ein ? - denn der Trigger soll ja der Sensor sein und bei den anderen interessiert doch nur der Status zur Laufzeit. Also [?Residents] eq "absent" und "[?18:30-07:00]".
Dann - nicht wundern - m.W. landen die Events auch in umgekehrter Reihenfolge im Log - zuerst die des DOIF, dann die des Sensors:
2019-01-03 09:49:42 TelegramBot Telegram silentmsg Sensor_M1_3
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_nr: 3
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd: 3
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_event: Sensor_M1
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_3
2019-01-03 09:49:42 ZWave Sensor_M1 alarm: HomeSecurity: Event cleared: Motion Detection - Unknown Location, arg 0108
Ich denke also, "Sensor_M1" hat das Event "alarm" geworfen. Das triggert das DOIF erneut, was ja 09:48:08 bereits in State 4 gekippt war. Da der state von "Sensor_M1" nun noch "open" ist, greift wieder Zweig 3.
Jetzt erst meldet Sensor_M1 als zweites Event (logische Folge nach Event cleared) ein "closed":
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_nr: 4
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd: 4
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_event: Sensor_M1
2019-01-03 09:49:42 DOIF Sensor_M1.Doif.Telegram cmd_4
2019-01-03 09:49:42 ZWave Sensor_M1 closed
2019-01-03 09:49:42 ZWave Sensor_M1 reportedState: closed
2019-01-03 09:49:42 ZWave Sensor_M1 closed
2019-01-03 09:49:42 ZWave Sensor_M1 reportedState: closed
woraufhin das DOIF nach state 4 kippt, ohne eine Meldung natürlich.
Die erst 09:49:43 eintreffende SUCCESS vom Telebot bezieht sich auf die vorige Aussendung um 09:49:42.
Abhilfe: frage [SENSOR_M1:state] ab - so wird nur auf Events getriggert, die "state" betreffen (alarm müsste also ignoriert werden)
oder stelle auf eventbasierte Meldung um: [SENSOR_M1:"open"].
Bin da aber selbst noch unerfahren (never touch working DOIFs und meine sind sehr alt :D) ...
Hallo Pfriemler,
danke für Deine Unterstützung! -ich habe jetzt mal die Fragezeichen hinzugefügt- und das scheint es schon gewesen zu sein..
Da unterliege ich wohl noch einem Denkfehler - ich dachte wenn ich mit "AND" zwei Bedinungen verknüpfe, müssen auch beide erfüllt sein, damit der Zweig ausgelöst wird.
Also z.B. "open und presence" => dann Zweig 1, oder "open und Zeitfenster" dann Zweig 2...
Hat ja eigentlich auch geklappt weil die entsprechende Meldung kam, aber halt zweimal...
Kannst Du mir (wirklich Anfänger) nochmal erklären, warum das "?" den Unterschied macht?
ZitatKannst Du mir (wirklich Anfänger) nochmal erklären, warum das "?" den Unterscheid macht?
Das DOIF wird normalerweise (also ohne ?) bei jedem Event getriggert und rennt von oben nach unten und überprüft alle Bedingungen.
Ist ein Zweig erfüllt bleibt es dort stehen.
Aber schon der nächste Event macht das gleiche Spiel.
Steht vor der Bedingung ein ? führt der Event der zu diesem Gerät erzeugt wird nicht dazu das DOIF zu triggern, sondern diese Bedingung wird beim Triggerlauf nur abgefragt.
Es ist insgesamt nicht so ganz einfach die Unterschiede zu verstehen, zumal wie Pfriemler ja auch vorgeschlagen hat, noch auf direkte Events getriggert werden kann.
- Bedingung [Sensor] eq "open" -> jeder Event im Gerät Sensor triggert das DOIF und es wird gefragt ob Sensor (STATE) open ist.
- Bedingung [Sensor:state] eq "open" -> jeder Event von state im Gerät Sensor triggert das DOIF und es wird gefragt ob Sensor (state) open ist (beachte den Unterschied!)
- Bedingung [Sensor:"open"] -> Das DOIF wird getriggert wenn der Event vom Gerät Sensor mit dem Inhalt "open" kommt und diese Bedingung wird war.
- Bedingung [?Sensor] eq "open" -> Das DOIF wird durch Sensor nicht getriggert sondern bei einem anderen Trigger wird der Zustand von STATE im Gerät Sensor abgefragt.
Ich hoffe das war jetzt alles richtig. Bezüglich 2. bin ich mir bezüglich "Event von state" nicht ganz sicher.
Gruß Otto
ok, danke....
ich werd das wohl an einem anderen Beispiel bei mir mal durchspielen müssen und noch mehr ausprobieren...
Dann aber nicht immer extra das Stockwerk wechseln ;-)
Danke Euch für die Unterstützung & Erklärungen!
Vielleicht noch als kleiner Hinweis: Es ist immer sinnvoll sich gegenseitig ausschließende Zweige zu bauen. In deinem DOIF können beispielsweise die ersten 3 Bedingungen alle wahr sein. Je nachdem in welchem state sich das DOIF befindet kann dann das Verhalten schwer nachvollziehbar sein, also:
1. DOIF ist in Cmd4, du bist abwesend und es ist nach 18:30
2. "open" wird gemeldet, DOIF triggert im ersten Zweig, ist also in Cmd1
3. "open" wird nochmal getriggert (bevor close o.ä. kam), Cmd1 wird nicht ausgelöst, da kein do always gesetzt ist, sondern Cmd2 wird ausgelöst
...
In deinem Beispiel ist das vielleicht nicht so wild, generell würde ich das aber bei der DOIF-Definition berücksichtigen.
Deine Anwesenheit sendet offenbar auch immer wieder den gleichen Event. Auch hier ist eventuell ein event-on-change-reading angesagt. Bewirkt in Deinem Fall sicher das Gleiche wie das ? davor.
Gruß Otto
Zitat von: Otto123 am 03 Januar 2019, 13:12:55
Ich hoffe das war jetzt alles richtig. Bezüglich 2. bin ich mir bezüglich "Event von state" nicht ganz sicher.
Immerhin wären wir schon zu zweit :)
Zitat von: KernSani am 03 Januar 2019, 13:52:02
Vielleicht noch als kleiner Hinweis: Es ist immer sinnvoll sich gegenseitig ausschließende Zweige zu bauen. In deinem DOIF können beispielsweise die ersten 3 Bedingungen alle wahr sein. Je nachdem in welchem state sich das DOIF befindet kann dann das Verhalten schwer nachvollziehbar sein, also:
1. DOIF ist in Cmd4, du bist abwesend und es ist nach 18:30
2. "open" wird gemeldet, DOIF triggert im ersten Zweig, ist also in Cmd1
3. "open" wird nochmal getriggert (bevor close o.ä. kam), Cmd1 wird nicht ausgelöst, da kein do always gesetzt ist, sondern Cmd2 wird ausgelöst
...
In deinem Beispiel ist das vielleicht nicht so wild, generell würde ich das aber bei der DOIF-Definition berücksichtigen.
Nö, das DOIF hier wechselt nicht den Zustand, nur weil ein Zweig schon erfüllt ist. Die erste Bedingung bleibt bei weiteren Triggern erfüllt und damit behält das DOIF seinen Zustand auch einfach - nur der Ausführungsteil wird nicht erneut ausgeführt, wenn es kein "do always"gibt.
Die Reihenfolge ist schon so ok, wenn die Bedingungen gut erfüllt sind. Erste Nebenbedingung ist hier "nicht anwesend" - dann immer Meldung 1, egal welche Uhrzeit. Ist einer anwesend, dann nur von 18:30 bis 7 Uhr Meldung 2. In allen anderen Fällen 3. Und in jedem Fall nur einmal, wenn es zwischendurch keine anderen Trigger gibt.
Ansonsten hat KernSani aber schon recht: Vor allem beim reinen Triggern auf das Event "open" wird es keine vernünftige Reaktion auf "closed" mehr geben. Statt das DOIF zu reinitialisieren könnte der vierte Zweig auch einfach auf "closed" getriggert werden, ohne einen Ausführungsteil. Auch damit ist das DOIF bereit für eine erneute Auslösung per "open".
Zitat von: Otto123 am 03 Januar 2019, 13:59:37
Deine Anwesenheit sendet offenbar auch immer wieder den gleichen Event. Auch hier ist eventuell ein event-on-change-reading angesagt. Bewirkt in Deinem Fall sicher das Gleiche wie das ? davor.
Einspruch. Ohne Fragezeichen würde der erste (oder ein anderer) Zweig getriggert werden, wenn Sensor open ist (etwa schon länger oder durch wiederholte Auslösung) und sich der Status von Residence ändert. Ähnliche Effekte könnten beim Erreichen der Zeitgrenzen auftreten. Bei einem Bewegungssensor eher weniger relevant, weil der sicher öfter auf "no motion" rsp. "closed" wechselt, aber bei einem Fenstersensor wäre das bei dauerhaft offenem Fenster schon relevanter. Oder vielleicht gerade beabsichtigt, wenn es bei offenem Fenster zu Hause 18:30 Uhr wird.