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:
2020-06-11 08:23:57 MAX DuscheFenster opened
2020-06-11 08:26:27 MAX BadFenster closed
List:
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
Ich führe gerade mit Wzut eine Diskussion genau darüber hier: https://forum.fhem.de/index.php/topic,106577.msg1062844.html#msg1062844 (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 Arbeit_Fenster:onoff:..* {.
Die Watchdog auf Arbeit_Fenster:onoff.*1 00:12:00 Arbeit_Fenster:onoff.*0
Und im Perl-Code ReadingsNum("Wohn_Fenster", "onoff", undef)
Damit stört mich zumindest in der Reaktion das andere Verhalten der Fensterkontakte nicht.
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)
userReadings nstate state:(opened|closed) {ReadingsVal($name,"state","")}
Gruß Otto
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.
Zitat von: Otto123 am 11 Juni 2020, 09:54:44
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.
Zitat von: jhohmann am 11 Juni 2020, 09:52:42
ReadingsNum("Wohn_Fenster", "onoff", undef)
mach das bitte nicht , sondern entweder ReadingsNum("Wohn_Fenster", "onoff", 0) oder ReadingsNum("Wohn_Fenster", "onoff", 1)
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:
2020-06-12 17:50:20 MAX DuscheFenster closed
Und wenn es offen ist:
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.
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.
Danke Wzut
Ich habe es ausprobiert, das Ergebnis:
https://forum.fhem.de/index.php/topic,106577.msg1063808.html#msg1063808
(https://forum.fhem.de/index.php/topic,106577.msg1063808.html#msg1063808)
Zeig mir doch bitte mal ein list von einem deiner FKs und dem dazu passenden notify das ihn auswertet.
Zur Ausgangslage, das Neuste 10_MAX.pm (von Gestern) habe ich noch nicht eigespielt.
Hier ist mal der eine Fensterkonkat.
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:
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
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
Zitat von: birdy am 13 Juni 2020, 12:58:13
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.
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
Zitat von: Wzut am 13 Juni 2020, 13:54:10
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.
Zitat von: Wzut am 13 Juni 2020, 13:54:10
b.
DEF .*:onoff:1 {winOpenStart($NAME)}
DEF .*:onoff:0 {winOpenStop($NAME)}
Werde ich gerne ausprobieren.
Zitat von: Wzut am 13 Juni 2020, 13:54:10
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)
Zitat von: Wzut am 13 Juni 2020, 13:54:10
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.
Zitat von: Wzut am 13 Juni 2020, 13:54:10
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?
Zitat von: birdy am 13 Juni 2020, 22:15:42
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
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).
defmod <name> notify .*:(open|opened) {winOpenStart($NAME)}
defmod <name> notify .*:closed {winOpenStop($NAME)}
Die von Dir vorgeschlagenen...
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.
eine kleine Auffrischung des Themas:
MAX-Fensterkontakte senden durchaus hin und wieder "opened (rf error)" oder "closed (rf error)".
Übrigens, Thermostate auch.
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
define Notify_1 notify [A-Z]+_Fensterkontakt.*:(opened.*|closed.*) {mySetShutterState("$NAME", "$EVENT");;}
und in mySetShutterState() in 99_myUtils.pm
$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
Zitat von: Hanso am 10 August 2020, 16:07:38
Ist das evtl. old State und durch die Einführung des readings rferror überflüssig geworden?
Ich verstehe weder die Frage noch den Aufwand den du da betreibst. Wie ich oben bereits schrieb würde ich kein notify/DOIF auf state los lassen sondern immer die entsprechenden Readings nutzen. Im Fall von offen/zu ist das onoff und bei Funkproblemen rferror.
nun, dann will ich es dir erklären:
rferror taucht als Reading das erste Mal im Nov 2019 im Log auf - siehe hier.
2019-11-29_14:39:16 AZ_Fensterkontakt_Links rferror: 0
Davor musste man den Übertragungsstatus aus state ableiten - siehe Log-Beispiel
2016-01-01_09:57:26 AZ_Fensterkontakt_Balkon opened (rf error)
Insofern war und ist meine Auswertung eines Übertragungsfehlers nach alter Art = 'old state'.
Funktioniert aber noch und das ist gut so, weil ich meine Perl-Funktionen nach einem Update eigentlich nicht
unbedingt 'anfassen' möchte.
Gruß
Hans
axo hättest du statt 'old state' old school geschrieben wäre der Groschen sofort gefallen :)