Welches Event triggert ?

[Bytechanger]

Hallo,

als Anfänger habe ich folgende Verständnisfrage:

Woran erkenne ich im EventMonitor, welches Ereignis triggert?

Wenn z.B. ein Fenstersensor öffnet, denn sendet er eine Reihe von Informatonen...
Und zusätzlich ist mir aufgefallen, wenn ich z.B. beim Fenstersensor nicht nur auf das "Hauptevent" also Öffnungszustand triggere, dann wird bei eingeschaltetem AES das Notify doppelt aufgerufen...

Code Auswählen Erweitern

2016-06-09 07:02:30 CUL_HM EG_FensterBuero battery: ok
2016-06-09 07:02:30 CUL_HM EG_FensterBuero contact: open (to vccu)
2016-06-09 07:02:30 CUL_HM EG_FensterBuero open
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigDst_vccu: noConfig
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigger_cnt: 35
2016-06-09 07:02:30 CUL_HM vccu aesKeyNbr: 02
2016-06-09 07:02:30 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-06-09 07:02:30 CUL_HM EG_FensterBuero aesReqTo: vccu
2016-06-09 07:02:30 CUL_HM EG_FensterBuero aesCommToDev: ok
2016-06-09 07:02:30 CUL_HM EG_FensterBuero battery: ok
2016-06-09 07:02:30 CUL_HM EG_FensterBuero contact: open (to vccu)
2016-06-09 07:02:30 CUL_HM EG_FensterBuero open
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigDst_vccu: noConfig
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trig_aes_vccu: ok:35
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigger_cnt: 35

Greets

Byte

[CoolTux]

Gar nicht. Triggern kann immer nur ein notify, DOIF, watchdog auf Basis eines Events. Du kannst aber auf alle Events die Du im Monitor siehst triggern lassen.

[Bytechanger]

JA, trigger war der falsche Ausdruck.

Ich meinte, wie erkenne ich, welches im EventMonitor aufgeführte Ereignis ausgelöst hat.
Also im o.g. Beispiel habe ich das Fenster geöffnet.

Es werden aber viele Infos angezeigt:
also:   battery: ok; trigDst_vccu: noConfig, trigger_cnt: 35, usw..

Woher weiss ich jetzt, wie ich das notify definieren muss, um im Beispiel das Öffnen zu bekommen (ja ich kenne es, ist halt nur ein Beispiel).


Greets

Byte

[CoolTux]

Du meinst Dein Notify ausgelöst hat? Das erkennst Du doch anhand Deiner gewählten RegExp

[Bytechanger]

Genau,

ich möchte ein RegEx aufbauen dass dann auf das entsprechende Ereignis lauscht.
Also ich schau mir im EventMonitor an was das Gerät so mitteilt und bau mir dann mein RegEx im Notify auf....

Ist eine grundsätzliche Frage, da ich nicht ganz durch den EventMonitor schaue.
Vermutlich habe ich da ein allgemeines Verständnisproblem.
Ich möchte sozusagen im EventMonitor "sniffen" und mir dann bei Bedarf ein RegEx bauen.
Mir ist halt nur aufgefallen, dass bei jedem Ereignis (Öffnungssensor meldet open/close) einiges mehr (Zustände) gemeldet wird und für mich der eigentliche Auslöser nicht sichtbar ist.
Also eine Unterscheidung zwischen Zustand und Auslöser der Meldung...
Auslöser im Beispiel ist das OPEN oder CLOSE und Zustand Batterie OK usw die sich nicht geändert haben...


Ich hatte hier z.B. den Fall dass ich für die Garage (Tor und Schwingtür) nur einen Öffnungssensor habe.
Jetzt bin ich hingegangen und habe den Sabotagekontakt ausgebaut und ihn auch als Öffnungssensor genommen.
Der Reagiert jetzt auf die Sabotagemeldung und setzt entsprechend einen Dummy.


Greets

Byte

[CoolTux]

Ich will Dich nicht ärgern, ich möchte das Du versuchst es selbst zu erkenne. Es kommen zu Deinem Fensterkontakt eine Menge Events

Code Auswählen Erweitern


2016-06-09 07:02:30 CUL_HM EG_FensterBuero battery: ok
2016-06-09 07:02:30 CUL_HM EG_FensterBuero contact: open (to vccu)
2016-06-09 07:02:30 CUL_HM EG_FensterBuero open
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigDst_vccu: noConfig
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigger_cnt: 35
2016-06-09 07:02:30 CUL_HM vccu aesKeyNbr: 02
2016-06-09 07:02:30 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-06-09 07:02:30 CUL_HM EG_FensterBuero aesReqTo: vccu
2016-06-09 07:02:30 CUL_HM EG_FensterBuero aesCommToDev: ok
2016-06-09 07:02:30 CUL_HM EG_FensterBuero battery: ok
2016-06-09 07:02:30 CUL_HM EG_FensterBuero contact: open (to vccu)
2016-06-09 07:02:30 CUL_HM EG_FensterBuero open
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigDst_vccu: noConfig
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trig_aes_vccu: ok:35
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigger_cnt: 35


Nun die Frage. Was genau willst Du davon weiter verarbeiten. Den Batteriestatus

Code Auswählen Erweitern


2016-06-09 07:02:30 CUL_HM EG_FensterBuero battery: ok



Den aesCommToDev Status

Code Auswählen Erweitern


2016-06-09 07:02:30 CUL_HM EG_FensterBuero aesCommToDev: ok


Oder einfach nur ob Fenster zu oder auf ist und wie es auf ist?

Code Auswählen Erweitern


2016-06-09 07:02:30 CUL_HM EG_FensterBuero open


Code Auswählen Erweitern


define notifyFensterStatus notify CUL_HM EG_FensterBuero.open set Lautsprecheransage FENSTER IST OFFEN


[dev0]

Wenn Du im event monitor oder beim inform Befehl die regexp angibst, die auch dein notify verwendet, dann werden auch nur die events angezeigt, die auch das notify triggern würden.

[Bytechanger]

Danke für die Tipps. Fühle mich auch nicht geärgert. Möchte auch nicht nerven, möchte nur gerne alles verstehen...

Meine grundsätzliche Frage wäre, wie erkenne ich welches der Angaben sich geändert hat, also für die Nachricht verantwortlich ist.

Also im Falle von

Code Auswählen Erweitern

2016-06-09 07:02:30 CUL_HM EG_FensterBuero battery: ok
2016-06-09 07:02:30 CUL_HM EG_FensterBuero contact: open (to vccu)
2016-06-09 07:02:30 CUL_HM EG_FensterBuero open
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigDst_vccu: noConfig
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigger_cnt: 35
2016-06-09 07:02:30 CUL_HM vccu aesKeyNbr: 02
2016-06-09 07:02:30 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-06-09 07:02:30 CUL_HM EG_FensterBuero aesReqTo: vccu
2016-06-09 07:02:30 CUL_HM EG_FensterBuero aesCommToDev: ok
2016-06-09 07:02:30 CUL_HM EG_FensterBuero battery: ok
2016-06-09 07:02:30 CUL_HM EG_FensterBuero contact: open (to vccu)
2016-06-09 07:02:30 CUL_HM EG_FensterBuero open
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigDst_vccu: noConfig
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trig_aes_vccu: ok:35
2016-06-09 07:02:30 CUL_HM EG_FensterBuero trigger_cnt: 35

kommen viele Infos. Letztendlich hat sich aber nur der STATE geändert, nämlich von "closed" zu "open", battery war auch zuvor schon "ok".
Also, gibt es eine Möglichkeit, über das notify abzufragen, ob sich ein Reading geändert hat und damit für den EVENT verantwortlich war?

Und mein weiteres Problem bleibt bestehen, dass bei AES Signierung das notify immer 2x angeworfen wird (ist bei Benachrichtigungen oder Schaltvorgängen echt doof)!
Schalte ich aesCommReq auf 0, wird es nur einmal angeworfen.
Der EventMonitor bestätigt dies auch, da hier zwei mal alle Daten rein kommen -mit der gleichen trigger_cnt-. Wie kann ich verhindern, dass das notify zwei mal ausgeführt wird??


Greets

Byte

[CoolTux]

Du meinst jetzt für diese Nachricht

Code Auswählen Erweitern


set Lautsprecheransage FENSTER IST OFFEN


Oder für die Einträge im Eventmonitor?

[dev0]

event-on-change-reading verwenden.

[CoolTux]

dev0 Bitte mach langsam. Ich möchte das der TE versteht woher seine Flut kommt, was sie macht und woran er erkennt womit er arbeiten kann.
Das event-on-change-reading kommt dann noch. Erstmal muß er erkennen warum dauernd die Meldungen kommen obwohl sich ja eigentlich nichts ändert.

   

[dev0]

@CoolTux: Dann lass ich Dich mal machen

[Bytechanger]

Hi,

vielen Dank für die Hilfe.

Ich habe jetzt verstanden, dass HomeMatic immer eine Vielzahl von Infos sendet. FHEM entscheidet dann, womit es einen Event auslöst. Und im Fall von event-on-change-reading .* meldet FHEM im Notify NUR die Readings, die sich geändert haben?! Richtig?!

Man könnte also sagen, alle Homematic Geräte sollten dieses event-on-change-reading gesetzt haben, sie plaudern ja viel.
Ich bin übers Ziel hinaus geschossen, da ich es nun auch bei Dummys gesetzt hatte, die mit trigger angestoßen wurden. Da wird das Notify ja nur einmal angestoßen, da danach das Reading immer gleich bleibt! (Bei Homematic wird zusätzlich noch der Zähler erhöht, was zu einem neuen Reading führt).


Was mich noch interessiert ist der "inform" Befehl. Wie wird er richtig angewendet?
In der Doku habe ich nicht viel gefunden..


Greets

Byte

[martinp876]

Eventonchangereading: korrekt. Empfehle ich rauf und runter.
Ich habe darauf geachtet, dass trigger (also bspw button press) das reading aendern, wenn es ein neuer event ist. Da sind bspw Zähler des Device mit dabei.
Ich bin der Meinung, dass dies alle devices so machen sollten. Wenn ich einen Dummy baue wird er bei jedem neuen Ereignis ein neues event schicken.

Informationen zeigt alle trigger, nicht alle reading changes.

[Bytechanger]

Danke für die Infos.
Wie machst Du es bei dummys, wenn Du sie triggerst?
Da hab ich mir in meiner Anfangseuphorie auch auf event-on-change-reading gesetzt und einfach mit trigger push getriggert.
Das wurde aber nach dem 1.Mal natürlich ignoriert, da das Reading sich nicht geändert hat!

Greets

Byte