Wo kommen die Events her?

[patlabor]

Hallo zusammen,

bin gerade mal wieder etwas am "rumspielen" mit meiner fhem Installation. Dabei habe ich festgestellt das mein Eventlog im Sekundentakt vollgespammt wird:

Code Auswählen Erweitern

2019-10-05 22:48:08.464 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:08.492 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:08.525 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:08.564 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:08.604 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:08.639 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:08.678 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:08.712 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:08.748 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:08.772 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:08.803 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:08.825 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:08.853 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:08.881 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:08.914 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:08.943 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:08.975 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:09.003 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:09.037 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:09.066 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:09.102 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:09.130 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:09.163 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:09.191 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:09.225 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:09.253 Global global DEFINED atTmp_awoken_rr_viktor_home
2019-10-05 22:48:09.286 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:09.315 Global global DEFINED atTmp_awoken_rr_viktor_home

Das geht unaufhörlich und scheinbar schon wochenlang so. Vermutlich ist deshalb mein fhem gelegentlich so schreiend langsam und besonders gesund für die SD-Karte kann das auch nicht sein.

Nur wie bekomme ich raus wo das herkommt?  Bewusst habe ich das nicht definiert. Ein list atTmp_awoken_rr_viktor_home meldet mir nur das ich das Gerät bitte zuerst anlegen soll. Auch bei eine Suche nach dem passenden Gerät in der fhem.cfg habe ich nichts gefunden.

Ich habe ein Homemode laufen der nach 10 Minuten awoken automatisch auf home setzt und für rr_patrick und rr_viktor jeweils ein doif das bei bestimmten Voraussetzungen den Bewohner auf asleep bzw. home setzt.

Leider habe ich nicht die geringste Ahnung, was genau diese Einträge auslöst. Ich weiß nicht mal genau ob es am HOMEMODE oder an den doifs liegt.
Gibt es eine Möglichkeit dem ganzen auf die Schliche zu kommen

[binford6000]

Ich habe ein Homemode laufen der nach 10 Minuten awoken automatisch auf home setzt und für rr_patrick und rr_viktor jeweils ein doif das bei bestimmten Voraussetzungen den Bewohner auf asleep bzw. home setzt.

Warum machst du das mit einem DOIF?

Leider habe ich nicht die geringste Ahnung, was genau diese Einträge auslöst. Ich weiß nicht mal genau ob es am HOMEMODE oder an den doifs liegt. Gibt es eine Möglichkeit dem ganzen auf die Schliche zu kommen

Vermutlich an beidem. HOMEMODE legt ja nur einmal ein temporäres at an um von awoken auf home zu stellen. Am besten du erledigst alles
über HOEMMODE. Dazu gibts ja auch jede Menge Beispiele im WIKI. Dann brauchst du keine ats, notifies und doifs mehr. (Oder weniger  )

VG Sebastian

[patlabor]

Warum machst du das mit einem DOIF?

Ehrlich gesagt, weil ich noch keine andre Möglichkeit gefunden habe und die abfragen zu realisieren.
Homemode habe ich mir bis her nur oberflächlich angeschaut, und und etwas überweltigt davon. Bisher habe ich nur ansatzweise durchschaut was es mit den ganzen Attributen auf sich hat und was man damit machen kann.
Doif dagegen erscheint mir recht logisch und ich verstehe es grundlegend.

Die Bedingungen für die doifs sind zumindes bei Viktor (mein Sohn) recht kompliziert.
Ich erfasse mit einem Türsensor zusammen mit einem Bewegungsmelder und HOMEZONE ob jemand im Raum ist, mit dem Bewegunsmelder zusätzlich die Helligkeit im Raum. Ausserdem erfasse ich ob das Licht und/oder der TV an ist.
Viktor gilt als schlafend, wenn TV und Licht aus sind, die Helligkeit unter einem bestimmten Schwellenwert ist (also entweder die Rolläden zu sind, oder es ist schon dunkel), und die HOMEZONE auf occupied steht. Ach ja, und grundsätzlich zuhause muss er natürlich auch sein. Realisiert habe ich das so:

Code Auswählen Erweitern

defmod di_viktor_asleep DOIF ([20:00-10:00] and [zo_viktor] eq "present" and [presence_tv_viktor] eq "absent" and [ms_viktor:illuminance] < 30 and [li_viktor] eq "off" and [rr_viktor:presence] eq "present")\
(set rr_viktor asleep) \
DOELSEIF \
([rr_viktor:presence] eq "present") (set rr_viktor state home)
attr di_viktor_asleep DbLogExclude .*
attr di_viktor_asleep checkall all
attr di_viktor_asleep room Logik,Viktor

Eigentlich sollte diese doif doch nicht 3 mal in der Sekunde auslösen.
Gerne lasse ich mir jedoch einen Tip geben wie ich sowas in HOMEMODE realisiere, oder wo mein Denkfehler ist, das dieses DOIF mich dermassen mit event vollspamt.

Das DOIF für mich (Patrick) ist viel einfacher realisiert, Unter meinem Bett habe ich einen Ultraschall Entfernungsmesser. Sobald die Distanz Boden <> Lattenrost unter eine bestimmte schwelle sinkt, weis ich es ist jemand im Bett. Dann wartet das DOIF 10 minuten und stellt mich auf asleep. Dazu dann noch eine kleine Abfrage ob ich nicht gerade awoken bin (kommt vor wenn ich nachts mal raus muß und dann wieder ins Bett gehe), dann wird direkt ohne Wartezeit auf asleep geschaltet.

Code Auswählen Erweitern

defmod do_schalf_patrick DOIF ([presence_bett_patrick:presence] == 1 and [rr_patrick] eq "awoken")(set rr_patrick state asleep)\
DOELSEIF\
([presence_bett_patrick:presence] == 1) (set rr_patrick state asleep)\
DOELSE\
(set rr_patrick state awoken)
attr do_schalf_patrick DbLogExclude .*
attr do_schalf_patrick alias DOIF: Patrick schlafen nach 10 min im Bett
attr do_schalf_patrick room Logik
attr do_schalf_patrick wait 0:600:10

[amenomade]

Code Auswählen Erweitern

defmod di_viktor_asleep DOIF ([20:00-10:00] and [zo_viktor] eq "present" and [presence_tv_viktor] eq "absent" and [ms_viktor:illuminance] < 30 and [li_viktor] eq "off" and [rr_viktor:presence] eq "present")\
(set rr_viktor asleep) \
DOELSEIF \
([rr_viktor:presence] eq "present") (set rr_viktor state home)
attr di_viktor_asleep checkall all


Eigentlich sollte diese doif doch nicht 3 mal in der Sekunde auslösen.

Wenn irgendein der triggernden Devices regelmässig auslöst, schon

[patlabor]

wenn irgendein der triggernden Devices regelmässig auslöst, schon

Das verstehe ich dann nicht ganz. Ich dachte DOIF kann nur schalten wenn es zwischenzeitlich einen anderen Bedingungszweig ausgeführt hat.
Das einzige was sich regelmässig meldet ist der Bewegungsmelder und von dem wird ja nur die Helligkeit abgeragt
Wenn es dann einmal dunkel ist, das Licht und TV ausbleibt und die Tür zubleibt, ändert sich ja nichts, und solange sich nicht eine der o.g. Bedingungen ändert, wird der 2. Zweig ja nie ausgeführt. Ohne checkall all würde der 2. Zweig doch nur ausgeführt wenn sich rr_viktor:presence ändert.
Ein do allways wurde doch bewirken das Zweig 1 wiederholt ausgeführt wird, auch wenn zwischenzeitlich nicht Zweig 2 eingetreten ist.
Zumindest habe ich das so verstanden.

[Prof. Dr. Peter Henning]

Ich dachte DOIF kann nur schalten wenn es zwischenzeitlich einen anderen Bedingungszweig ausgeführt hat.

Das ist Unsinn, und das steht auch nirgendwo in der Dokumentation.

LG

pah

[patlabor]

Dann verstehe ich das hier aber total falsch:

Im FHEM-Modus arbeitet das Modul mit Zuständen, indem es den eigenen Status auswertet. Die Ausführung erfolgt standardmäßig nur ein mal, bis ein anderer DOIF-Zweig und damit eine Ändernung des eigenen Status erfolgt. Das bedeutet, dass ein mehrmaliges Drücken der Fernbedienung auf "on" nur einmal "set garage on" ausführt. Die nächste mögliche Ausführung ist "set garage off", wenn Fernbedienung "off" liefert.
Wünscht man eine Ausführung des gleichen Befehls mehrfach nacheinander bei jedem Trigger, unabhängig davon welchen Status das DOIF-Modul hat, weil z. B. Garage nicht nur über die Fernbedienung geschaltet wird, dann muss man das per "do always"-Attribut angeben

Steht so zumindest in der commandref, und das fehlen von "do always" hat mir bei meinen Anfängen mit DOIF sehr viel Kopfschmerzen bereitet.

[amenomade]

Mach einfach ein "list di_viktor_asleep" und eine Sekunde (oder mehr) danach, wieder ein "list di_viktor_asleep".
Dann wirst Du sehen, ob er was gemacht hat und warum.

[Damian]

Das verstehe ich dann nicht ganz. Ich dachte DOIF kann nur schalten wenn es zwischenzeitlich einen anderen Bedingungszweig ausgeführt hat.
Das einzige was sich regelmässig meldet ist der Bewegungsmelder und von dem wird ja nur die Helligkeit abgeragt
Wenn es dann einmal dunkel ist, das Licht und TV ausbleibt und die Tür zubleibt, ändert sich ja nichts, und solange sich nicht eine der o.g. Bedingungen ändert, wird der 2. Zweig ja nie ausgeführt. Ohne checkall all würde der 2. Zweig doch nur ausgeführt wenn sich rr_viktor:presence ändert.
Ein do allways wurde doch bewirken das Zweig 1 wiederholt ausgeführt wird, auch wenn zwischenzeitlich nicht Zweig 2 eingetreten ist.
Zumindest habe ich das so verstanden.

Das hast du richtig verstanden. Ohne das do always Attribut wird der gleiche Zweig nicht wiederholt. Ich sehe in deiner DOIF-Definition kein Define. Woher weißt du, dass die Meldungen von dieser DOIF-Definition kommen?

[patlabor]

Mach einfach ein "list di_viktor_asleep" und eine Sekunde (oder mehr) danach, wieder ein "list di_viktor_asleep".
Dann wirst Du sehen, ob er was gemacht hat und warum.

Da werde ich dann leider mit Seitenweise Text zugeschmissen, der mir nicht wirklich was sagt, aber soweit ich das überblicken kann eigentlich beidemal gleich ist.

ch sehe in deiner DOIF-Definition kein Define. Woher weißt du, dass die Meldungen von dieser DOIF-Definition kommen?

das define fehlt wohl, weil ich das ganze per Raw definition aus fhem herauskopiert habe, anstatt dem defmod steht eigentlich define bei mir.
Wissen das es von dem DOIF kommt tue ich nicht. Das ist bisher nur ein Verdacht, ich habe nicht die geringste Ahnung wo es herkommt. allerdings gibt es nur die beiden DOIFs und den HOMEMODE der etwas mit awoken bzw. asleep macht

[Damian]

Da werde ich dann leider mit Seitenweise Text zugeschmissen, der mir nicht wirklich was sagt, aber soweit ich das überblicken kann eigentlich beidemal gleich ist.

das define fehlt wohl, weil ich das ganze per Raw definition aus fhem herauskopiert habe, anstatt dem defmod steht eigentlich define bei mir.
Wissen das es von dem DOIF kommt tue ich nicht. Das ist bisher nur ein Verdacht, ich habe nicht die geringste Ahnung wo es herkommt. allerdings gibt es nur die beiden DOIFs und den HOMEMODE der etwas mit awoken bzw. asleep macht

Du kannst in deinem DOIF Logs einbauen z. B. für den ersten Teil (set rr_viktor asleep, {Log3 "di_viktor_asleep",1,"$DEVICE, cmd1"}) und entsprechend für den zweiten Teil. $DEVICE sagt dir, wer das Modul getriggert hat.

[amenomade]

Da werde ich dann leider mit Seitenweise Text zugeschmissen, der mir nicht wirklich was sagt, aber soweit ich das überblicken kann eigentlich beidemal gleich ist.

Das können aber einige hier... Wenn aber wirklich nichts geändert wurde, insb. die Readings und deren Timestamps, dann ist es nicht das Problem

das define fehlt wohl, weil ich das ganze per Raw definition aus fhem herauskopiert habe, anstatt dem defmod steht eigentlich define bei mir.

Es handelt aber nicht um ein define von di_viktor_asleep sondern von atTmp_awoken_rr_viktor_home und atTmp_awoken_rr_patrick_home

2019-10-05 22:48:08.464 Global global DEFINED atTmp_awoken_rr_patrick_home
2019-10-05 22:48:08.492 Global global DEFINED atTmp_awoken_rr_viktor_home

Ich vermute, die werden irgendwie vom HOMEMODE Device kreiert. Z.B. durch HomeAutoAwoken
Und so ein at, das den Status vom Resident automatisch setzt, könnte wiederum dein DOIF doch triggern...
Ohne mehr von deiner Konfiguration zu wissen, ist es schwierig zu raten

[amenomade]

Also, hab ein bisschen mit HOMEMODE rumgespielt.

Wenn ich attr HomeCMDmode-awoken-resident und attr HomeAutoAwoken definiere, und dann "set rr_Jo state awoken" setze, kriege ich im Eventmonitor

Code Auswählen Erweitern

2019-10-06 22:50:55 Global global DEFINED atTmp_awoken_rr_Jo_home


Und noch eine Anmerkung: DOIF unterbindet die Selbsttriggerung. Wenn ein Zweig "set xxx aa" macht, triggert es eine Bedingung [xxx:aa] nicht.
ABER: wenn über ein Modul wie HOMEMODE xxx durch temporäre at(s) manipuliert wird, kann DOIF es nicht wissen. Deswegen habe ich hieroben geschrieben: "könnte wiederum dein DOIF doch triggern"

Irgendwie hast Du vermutlich eine endlose Schleife gebaut. Mit oder ohne das DOIF, das weiss ich nicht. Aber das kannst Du selbst festellen: das DOIF auf disable setzen, und dann wirst Du im Eventmonitor sehen, ob es immer noch zugemüllt wird.

[patlabor]

Irgendwie hast Du vermutlich eine endlose Schleife gebaut. Mit oder ohne das DOIF, das weiss ich nicht. Aber das kannst Du selbst festellen: das DOIF auf disable setzen, und dann wirst Du im Eventmonitor sehen, ob es immer noch zugemüllt wird.

Habe jetzt versuchsweise die beiden DOIFs deaktiviert, und fhem mal gut eine Stunde laufen lassen, in der Hoffnung, das vielleicht  ein "Backlog" vorhanden ist, der noch abgearbeitet werde will. Aber leider ohne Erfolg, die DOIFs sind deaktiviert und die Einträge erscheinen immernoch am laufenden Band im Log. Dann kommt ja eigentlich nur noch der HOMEMODE in Frage. Dort habe ich aber ausser ein HomeAutoAwoken 10 nichts drin was irgend etwas mit den Residents macht.

NACHTRAG:
Scheinbar liegt es doch an den DOIFs. Ich habe jetzt während sie deaktiviert waren, fhem einmal neugestartet, und schon sind die Meldungen im Log verstummt.
Auf der einen Seite super, weil jetzt weis ich wo das Problem war, aber auch ziemlich übel, weil ich jetzt keine Ahnung habe, wie ich die Schlaferkennung anders hin bekomme

[amenomade]

Was kommt in "Probably associated with" im rr_patrick oder rr_victor Device?