opened und closed Events

[birdy]

Ich habe bei mir eine Fenster-Überwachung eingerichtet welche auf den Max ShutterContact basiert. Diese hat auch lange Zeit problemlos funktioniert, bis vor kurzem.
Das Problem, die ShutterKontakte erzeugen neuerdings viel zu viele Events. Jedes Mal wenn  MAXLAN gepolled wird, werden für alle Fenster Events erzeugt.
Ich möchte nur Event wenn die Fenster geöffnet oder geschlossen werden. Also wenn sich der Status ändert.

Zwei der unzähligen Events:

Code Auswählen Erweitern

2020-06-11 08:23:57 MAX DuscheFenster opened

Code Auswählen Erweitern

2020-06-11 08:26:27 MAX BadFenster closed

List:

Code Auswählen Erweitern

Internals:
   DEF        ShutterContact 112636
   FUUID      5d0d514e-f33f-f4b3-63dc-f1c8470551885df4
   IODev      MaxLan
   LASTInputDev cmax
   MSGCNT     2620
   MaxLan_MSGCNT 2562
   MaxLan_TIME 2020-06-11 08:44:33
   NAME       DuscheFenster
   NR         132
   NTFY_ORDER 50-DuscheFenster
   STATE      opened
   SVN        22023
   TYPE       MAX
   addr       112636
   cmax_MSGCNT 58
   cmax_TIME  2020-06-11 09:01:54
   devtype    4
   type       ShutterContact
   READINGS:
     2020-06-11 08:44:33   MAXLAN_error    0
     2020-06-11 08:44:33   MAXLAN_errorInCommand
     2020-06-11 08:44:33   MAXLAN_initialized 1
     2020-06-11 08:44:33   MAXLAN_isAnswer 0
     2020-06-11 08:44:33   MAXLAN_valid    1
     2020-06-11 09:01:54   RSSI            -65.5
     2020-06-11 08:44:32   SerialNr        LEQ1484571
     2020-06-11 09:01:54   battery         ok
     2020-06-11 09:01:54   batteryState    ok
     2020-06-11 08:44:32   firmware        1.0
     2020-04-19 22:53:55   groupid         4
     2020-06-11 09:01:54   onoff           1
     2020-06-11 09:01:54   peerIDs         11a187,162966
     2020-06-11 09:01:54   peerList        DuscheRad,MaxLan
     2020-06-11 09:01:54   rferror         0
     2020-06-11 09:01:54   state           opened
     2020-06-11 08:44:32   testresult      0
     2020-06-11 08:06:21   windowOpen      0
   helper:
     io:
       maxcube:
         raw        Z0BDB06301126361629660012
         rssi       -65.5
         time       1591858914.39847
Attributes:
   DeviceType Fenster
   IODev      MaxLan
   T_winCloseTime 2020-06-11 01:01:39
   T_winOpenLastMsg n/a
   T_winOpenMsgCnt n/a
   T_winOpenTime 2020-06-11 09:01:54
   devStateIcon closed:fts_window_roof opened:fts_window_roof_open_2@red
   model      ShutterContact
   room       MAX
   userattr   winOpenName winOpenType:Dachfenster,Fenster,Türe,Klappe winOpenMsgTime winOpenMaxMsg T_winOpenLastMsg T_winOpenTime T_winCloseTime T_winOpenMsgCnt
   winOpenMaxMsg 999
   winOpenMsgTime n/a
   winOpenName Dusche
   winOpenType Dachfenster


Die bisherigen ,,event-on-change-reading" Definitionen funktionieren seit kurzem nicht mehr.
Auch habe ich einiges ausprobiert. Ich habe es nicht geschafft eine funktionierende  ,,event-on-change-reading" Definition hin zu bekommen 

Neben den Original Cube den Ich mit MAXLAN betreibe (polling) habe ich auch noch einen zum CUL geflashten Cube im Einsatz den ich mit CUL_MAX betreibe (nur horchen).

Da ich eine ausgeklügelte Überwachung implementiert habe, und einige Fenster (Türen) überwache ist das Ganze etwas ärgerlich.
Bin für jeden Rat dankbar

[jhohmann]

Ich führe gerade mit Wzut eine Diskussion genau darüber hier: https://forum.fhem.de/index.php/topic,106577.msg1062844.html#msg1062844
Zur Ablösung hat mir geholfen, dass ich bei den Fenstern nicht mehr auf state oder in der Perl auf Value("Fenstername") reagiere, sondern das Reading onoff abfrage.
Die notifys horchen auf

Code Auswählen Erweitern

Arbeit_Fenster:onoff:..* {.
Die Watchdog auf

Code Auswählen Erweitern

Arbeit_Fenster:onoff.*1 00:12:00 Arbeit_Fenster:onoff.*0
Und im Perl-Code

Code Auswählen Erweitern

ReadingsNum("Wohn_Fenster", "onoff", undef)
Damit stört mich zumindest in der Reaktion das andere Verhalten der Fensterkontakte nicht.

[Otto123]

Ich habe keine Ahnung von MAX aber

event-on-change-reading state

Sollte es tun.

Oder kommen im state mehr als diese beiden Zustände? Dann musst Du die vorher rausfiltern und ein neues Reading machen. (ungetestet)

Code Auswählen Erweitern

userReadings nstate state:(opened|closed) {ReadingsVal($name,"state","")}

Gruß Otto

[birdy]

Merkwürdig...
Von gerstern auf Heute habe ich mir mit diesem Problem die halbe Nacht um die Ohren geschlagen.
Heute kurz nachdem ich meinen Betrag hier geschirben habe funktioniert es wieder...
Mann kann nicht immer alles verstehen.

Euch allen trotzden vielen Dank für die super schnellen Rückmeldungen.

[Wzut]

Ich habe keine Ahnung von MAX aber

aber dazulernen darfst du trotzdem
Bei den MAX Geräten ist historisch bedingt das state Reading eine Kombination aus diversen Readings, hängt aber auch noch etwas vom jeweiligen Typ ab.
Daher ist es IMHO immer wesentlich sinnvoller die Readings direkt abzufragen als sich großartig state durch Filter passend zu machen.

ReadingsNum("Wohn_Fenster", "onoff", undef)

mach das bitte nicht , sondern entweder  ReadingsNum("Wohn_Fenster", "onoff", 0) oder ReadingsNum("Wohn_Fenster", "onoff", 1)

 

[birdy]

Es ist doch wie verhext.
Nachdem es kurz funktioniert hat, habe ich dasselbe Problem erneut...........

Also ich triggere meinen Programm Code welcher in 99_myUtils.pm lieg mittels Notify's. Meines Wissens kann ich mit einem  Notify nur auf Events reagieren. Solche welche auch im Event Monitor ersichtlich sind.  (Bitte korrigieren wenn ich falsch liege)

Wenn das Fenster geschlossen ist, taucht jedes mall wenn ge-polled wird die folgende Meldung auf:

Code Auswählen Erweitern

2020-06-12 17:50:20 MAX DuscheFenster closed

Und wenn es offen ist:

Code Auswählen Erweitern

2020-06-12 17:55:20 MAX DuscheFenster opened

Sorry aber leider verstehe ich nicht, was Ihr hier von onoff schreibt.
Lässt sich das wirklich auf die oben aufgeführten Events anwenden? Und falls ja, wie?

Das die Events bei jeden Polling erscheinen ist ja grundsätzlich klar. Was ich aber nicht verstehe warum sich die nicht mit event-on-change-reading  einschränken lassen. Bzw. ein sehr unzuverlässiges Verhalten auslöst.

@Otto: Dachte auch        event-on-change-reading state     würde funktionieren , tut es aber nicht zuverlässig. 
Ich hatte auch schon       event-on-change-reading .*              versucht....

Es macht den Anschein als würde es funktionieren wenn   event-on-change-reading   für ein, zwei Fenster definiert wird.
Sobald ich dies für die weiteren Fenster setze, ist es dann Plötzlich vorbei. Und dann funktioniert es plötzlich für alle Fenster nicht mehr   

Wo genau werden die Events abgefeuert bzw. die event-on-change-reading  berücksichtigt damit sie eben NICHT abgefeuert werden.
Kann es sein dass da nur eine bestimmte Anzahl berücksichtigt werden können?

Das Ganze hat bis vor kurzem über Jahre zuverlässig funktioniert. Da muss sich irgendwo ein Bug eingeschlichen haben.

[Wzut]

Ich fang mal hinten an :
die vermutliche Lösung steht hier -> https://forum.fhem.de/index.php/topic,106577.msg1063282.html#msg1063282
aber ohne positives Feedback checke ich das nicht ein.

event-on-change-reading auf state ist in diesem Fall nutzlos, da MAXLAN und CUL_MAX state wechselseitig mit verschiedenen Werten beschreiben.

onoff : schau dir mal deine Readings an , die FKs haben ein Reading onoff das den Wert 0 oder 1 haben kann.
Wertet man dieses aus statt state ist das Problem auch behoben.

[birdy]

Danke Wzut

Ich habe es ausprobiert, das Ergebnis:
https://forum.fhem.de/index.php/topic,106577.msg1063808.html#msg1063808

[Wzut]

Zeig mir doch bitte mal ein list von einem deiner FKs und dem dazu passenden notify das ihn auswertet.

[birdy]

Zur Ausgangslage, das Neuste 10_MAX.pm (von Gestern) habe ich noch nicht eigespielt. 

Hier ist mal der eine Fensterkonkat.

Code Auswählen Erweitern

Internals:
   DEF        ShutterContact 112636
   FUUID      5d0d514e-f33f-f4b3-63dc-f1c8470551885df4
   IODev      MaxLan
   LASTInputDev MaxLan
   MSGCNT     1021
   MaxLan_MSGCNT 999
   MaxLan_TIME 2020-06-13 11:42:01
   NAME       DuscheFenster
   NR         132
   NTFY_ORDER 50-DuscheFenster
   STATE      opened
   SVN        22023
   TYPE       MAX
   addr       112636
   cmax_MSGCNT 22
   cmax_TIME  2020-06-13 11:38:16
   devtype    4
   type       ShutterContact
   READINGS:
     2020-06-13 11:42:01   MAXLAN_error    0
     2020-06-13 11:42:01   MAXLAN_errorInCommand
     2020-06-13 11:42:01   MAXLAN_initialized 1
     2020-06-13 11:42:01   MAXLAN_isAnswer 0
     2020-06-13 11:42:01   MAXLAN_valid    1
     2020-06-13 11:38:16   RSSI            -65
     2020-06-13 11:42:01   SerialNr        LEQ1484571
     2020-06-13 11:42:01   battery         ok
     2020-06-13 11:42:01   batteryState    ok
     2020-06-13 11:42:01   firmware        1.0
     2020-04-19 22:53:55   groupid         4
     2020-06-13 11:42:01   onoff           1
     2020-06-13 11:42:01   peerIDs         11a187,162966
     2020-06-13 11:42:01   peerList        DuscheRad,MaxLan
     2020-06-13 11:42:01   rferror         0
     2020-06-13 11:42:01   state           opened
     2020-06-13 11:42:01   testresult      0
     2020-06-13 10:14:31   windowOpen      0
   helper:
     io:
       maxcube:
         raw        Z0BE906301126361629660012
         rssi       -65
         time       1592041096.18726
Attributes:
   DeviceType Fenster
   IODev      MaxLan
   T_winCloseTime 2020-06-13 10:14:31
   T_winOpenLastMsg n/a
   T_winOpenMsgCnt n/a
   T_winOpenTime 2020-06-13 11:42:01
   devStateIcon closed:fts_window_roof opened:fts_window_roof_open_2@red
   event-on-change-reading state
   model      ShutterContact
   room       MAX
   userattr   winOpenName winOpenType:Dachfenster,Fenster,Türe,Klappe winOpenMsgTime winOpenMaxMsg T_winOpenLastMsg T_winOpenTime T_winCloseTime T_winOpenMsgCnt
   winOpenMaxMsg 999
   winOpenMsgTime n/a
   winOpenName Dusche
   winOpenType Dachfenster


Der Notify für die Fenster:

Code Auswählen Erweitern

Internals:
   DEF        .*:(open|opened|tilted) {winOpenStart($NAME)}
   FUUID      5d0d514d-f33f-f4b3-12d9-1f199e9e24dc8ef5
   NAME       winOpen.OpenNotify
   NR         53
   NTFY_ORDER 50-winOpen.OpenNotify
   REGEXP     .*:(open|opened|tilted)
   STATE      2020-06-13 11:47:03
   TRIGGERTIME 1592041623.28176
   TYPE       notify
   READINGS:
     2020-06-12 21:51:56   state           active
Attributes:

Und

Code Auswählen Erweitern

Internals:
   DEF        .*:closed {winOpenStop($NAME)}
   FUUID      5d0d514d-f33f-f4b3-147b-1be6d33f1b5241fc
   NAME       winOpen.CloseNotify
   NR         54
   NTFY_ORDER 50-winOpen.CloseNotify
   REGEXP     .*:closed
   STATE      2020-06-13 11:47:03
   TRIGGERTIME 1592041623.51092
   TYPE       notify
   READINGS:
     2020-06-12 21:51:56   state           active
Attributes:

Ok, die notify's sind möglicherweise nicht optimal definiert. Aber....

• Die haben so jahrelang problemlos funktioniert.
• Die werden ja nicht durch Events von falschen Devices getriggert, sondern durch überzählige Events der richtigen Devices.
• Ich habe am meiner Konfiguration nichts geändert, ausser ein Update auf Buster und das gelegentliche Einspielen der regulären FHEM Updates

Natürlich könnte ich in der vom Notify getigerten Sub alles abfangen und ausprogrammieren. Status ermitteln, mit den abgespeicherten Werten des letzten Aufrufes vergleichen bei einem Unterschied weiter auslösen. Aber das kann meiner Ansicht nach nicht die Lösung sein.
Ich wäre froh wenn ich mein bisheriges Konzept wieder zum Laufen bringen würde.

Gruss birdy

[Wzut]

Zur Ausgangslage, das Neuste 10_MAX.pm (von Gestern) habe ich noch nicht eigespielt. 

--snipp ---

   DEF        .*:(open|opened|tilted) {winOpenStart($NAME)}
   DEF        .*:closed {winOpenStop($NAME)}

--snipp ---
Die haben so jahrelang problemlos funktioniert

a. es gibt keine Version von gestern, die letzte im svn ist vom 24. Mai

b.

Code Auswählen Erweitern

DEF        .*:onoff:1 {winOpenStart($NAME)}
DEF        .*:onoff:0 {winOpenStop($NAME)}

diese beiden kleinen Änderungen würden vermutlich deine Probleme sofort lösen, zumindest war es bei dem anderen User so.
Und wie im anderen Thread geschrieben habe, vor Mitte Juli werd ich nicht dazu kommen das bei mir 1:1 nachzustellen.
Allerdings fragst du noch gekippt ab, hast du noch andere FKs ausser MAX die alle drei Stellungen erfassen ?

c.
Sicherhat das jahrelang funktioniert, an den MAX Modulen wurde ja auch jahrelang nichts geändert. Die Entwicklung der jetzigen Version hat sich auch von November 2019 bis April diesen Jahres hingezogen, eben weil ich weil ich so viel geändert habe und etliche Neuerungen eingebaut habe. Das jetzige Verhalten ist unschön und ich bin mir auch relativ sicher die Ursache zu finden wenn ich mal passende verbose 5 Logs vor mir habe.

Edit : siehe https://forum.fhem.de/index.php/topic,106577.msg1064073.html#msg1064073

[birdy]

a. es gibt keine Version von gestern, die letzte im svn ist vom 24. Mai

Also mein letztes FHEM Update ist von 07.Juni. Dass bei mir von gestern auf Heute ein neues  Update für  10_MAX.pm aufgeführt wird, hat evtl. damit zu tun, dass ich die 10_MAX.pm gestern von von Hand angepasst habe.

b.

Code Auswählen Erweitern

DEF        .*:onoff:1 {winOpenStart($NAME)}
DEF        .*:onoff:0 {winOpenStop($NAME)}

Werde ich gerne ausprobieren.

Allerdings fragst du noch gekippt ab, hast du noch andere FKs ausser MAX die alle drei Stellungen erfassen ?

Nein habe ich nicht. Macht kein Sinn gekippt abzufragen, da hast Du natürlich Recht. (werde ich löschen)

Sicherhat das jahrelang funktioniert, an den MAX Modulen wurde ja auch jahrelang nichts geändert. Die Entwicklung der jetzigen Version hat sich auch von November 2019 bis April diesen Jahres hingezogen, eben weil ich weil ich so viel geändert habe und etliche Neuerungen eingebaut habe.

Da hast Du natürlich Recht. Ich finde es super toll dass Du dich dem angenommen hast. Das schätze ich sehr.

Das jetzige Verhalten ist unschön und ich bin mir auch relativ sicher die Ursache zu finden wenn ich mal passende verbose 5 Logs vor mir habe.

Wie kann ich Dir helfen. Brauchst Du ein Log von welchen Device?

[Wzut]

Werde ich gerne ausprobieren.
---snipp ---
Brauchst Du ein Log von welchen Device?

Denk aber daran dann auch deine event-on-change-reading state aufzubohren -> state,onoff oder nur onoff oder .*
Ich denke ich habe gestern bei mir gesehen was ich suchte, daher das Update

[birdy]

Hall Wzut

Heute Morgen habe ich ein FHEM Update durchgeführt.

Wie es aussieht funktionieren meine alten Notify wieder (konnte aber noch nicht ausgiebig testen).

Code Auswählen Erweitern

defmod <name> notify .*:(open|opened) {winOpenStart($NAME)}
defmod <name> notify .*:closed {winOpenStop($NAME)}

Die von Dir vorgeschlagenen...

Code Auswählen Erweitern

DEF        .*:onoff:1 {winOpenStart($NAME)}
DEF        .*:onoff:0 {winOpenStop($NAME)}
habe ich leider nicht zum Laufen gebracht.  Aber egal,  für mich sieht es momentan ganz gut aus.
Ich werde das Ganz noch etwas beobachten, und schauen wie sich das Ganze anstellt.

Bin total glücklich, vielen Dank für die tolle Arbeit.

[Hanso]

eine kleine Auffrischung des Themas:
MAX-Fensterkontakte senden durchaus hin und wieder "opened (rf error)" oder "closed (rf error)".
Übrigens, Thermostate auch.

Code Auswählen Erweitern

2020-01-06_11:35:46 WZ_Thermostat_Rechts 1.0 °C (rf error)

Habe das in meinen Logs überprüft.
Ich bin mir allerdings nicht sicher, ob das evtl. im Zustand des (fehlerhaften) Assoziierens
der Kontakte mit den Thermostaten passiert war. Ich erinnere mich an solch ein Verhalten
in der Vergangenheit.
Daher habe ich mein notify bei fensterkontakten so gewählt

Code Auswählen Erweitern

define Notify_1 notify [A-Z]+_Fensterkontakt.*:(opened.*|closed.*) {mySetShutterState("$NAME", "$EVENT");;}
und in mySetShutterState() in 99_myUtils.pm

Code Auswählen Erweitern

    $state =~ s/(.*)\(rf error\)/$1/; # ggf. "(rf error)" entfernen

um $state entsprechend zu 'säubern'.

Ist das evtl. old State und durch die Einführung des readings rferror überflüssig geworden?

Gruß
Hans