Guten Morgen,
ich habe ein DOIF im perl-Modus:
{fhem_set("myHMCCU hmscript /opt/fhem/hmscript.scr Device=DISP000001 Text=\"/6 '\@p03\@t06 ".[Garage_TorNeigung]."'\"");}
Das soll bei einer Änderung des Sensors "Garage_TorNeigung" den aktuellen Zustand an ein Display übermitteln. Das hat auch eine Zeit lang gut funktioniert, aktuell zeigt das Display immer den entgegengesetzten Wert an, also "open" wenn das Tor geschlossen ist und umgekehrt. Die Fehlersuche hat Folgedes ergeben:
Auszug aus dem Log des Sensors:
2020-08-25_09:24:46 Garage_TorNeigung aesCommToDev: pending
2020-08-25_09:24:47 Garage_TorNeigung aesCommToDev: ok
2020-08-25_09:24:47 Garage_TorNeigung battery: ok
2020-08-25_09:24:47 Garage_TorNeigung commState: CMDs_done
2020-08-25_09:24:47 Garage_TorNeigung contact: open (to VCCU)
2020-08-25_09:24:47 Garage_TorNeigung open
2020-08-25_09:24:47 Garage_TorNeigung trig_aes_VCCU: ok:247
2020-08-25_09:24:47 Garage_TorNeigung trigger_cnt: 247
2020-08-25_09:25:25 Garage_TorNeigung aesCommToDev: pending
2020-08-25_09:25:26 Garage_TorNeigung aesCommToDev: ok
2020-08-25_09:25:26 Garage_TorNeigung battery: ok
2020-08-25_09:25:26 Garage_TorNeigung commState: CMDs_done
2020-08-25_09:25:26 Garage_TorNeigung contact: closed (to VCCU)
2020-08-25_09:25:26 Garage_TorNeigung closed
2020-08-25_09:25:26 Garage_TorNeigung trig_aes_VCCU: ok:248
2020-08-25_09:25:26 Garage_TorNeigung trigger_cnt: 248
Event Monitor
2020-08-25 09:24:47 HMCCU myHMCCU hmscript /opt/fhem/hmscript.scr Device=DISP000001 Text="/6 '@p03@t06 closed'"
2020-08-25 09:24:51 HMCCU myHMCCU hmscript /opt/fhem/hmscript.scr Device=DISP000001 Text="/6 '@p03@t06 open'"
2020-08-25 09:25:26 HMCCU myHMCCU hmscript /opt/fhem/hmscript.scr Device=DISP000001 Text="/6 '@p03@t06 open'"
2020-08-25 09:25:30 HMCCU myHMCCU hmscript /opt/fhem/hmscript.scr Device=DISP000001 Text="/6 '@p03@t06 closed'"
Hier ist das Tor kurz aufgemacht und wieder geschlossen worden (closed -> open, open -> closed). In den ungeraden Zeilen (Event Monitor) ist also der alte Status, unmittelbar vor der Änderung und in den geraden Zeilen der aktuelle Status, den ich eigentlich haben will, gesendet worden. Da das Display träge ist (ePaper), ist es noch am Darstellen des alten Wertes und "überhört" dabei den aktuellen Wert. Wie kann ich die ungeraden Zeilen unterdrücken, bzw. warum verhält sich mein DOIF anders, als ursprünglich? Oder "prellt" der Status des Sensors? Im CUL_HM sind in letzter Zeit viele Änderungen vorgenommen worden, so dass das nicht auszuschließen ist.
Hi,
Du musst alles zeigen, so sieht man wenig. Also list deinDoif
Dazu wäre es auch gut nicht nur dia Auswirkung im DOIF im Eventmonitor zubetrachten sondern auch die von Garage_TorNeigung.
Also der Filter im Eventmonitor Garage_TorNeigung.*|myHMCCU.*
Es wird schon so sein wie Du vermutest. Du wirst Deinen Trigger schärfer machen mussen.
Tipp: Die CUL_HM Geräte laufen bei mir alle mit event-on-change-reading .*
Gruß Otto
Hi Otto,
ein List habe ich bewusst nicht beigefügt, da im DOIF noch weitere perl-Funktionsblöcke sind, die aber mit dem von mir gezeigten nichts zu tun haben. Es sind keine DOIF-spezifischen Attribute gesetzt.
Bzgl "Garage_TorNeigung.*|myHMCCU.*": ich werde noch mit der Einstellung loggen, sobald ich wieder Zugriff auf mein FHEM habe, aber im Prinzip habe ich doch genau die Informationen zur Verfügung gestellt, nur verteilt auf 2 Code-Blöcke?
Inwiefern wird DOIF von "event-on-change-reading .*" beeinflusst? Laut CommandRef soll ein "[Garage_TorNeigung]" genau das gleiche bewirken, also nur bei Änderung triggern, und das völlig unabhängig von den Einstellungen im Device?
Muss wieder los, heute Abend sollte ich mehr Zeit haben.
Edit: ich habe hier (https://forum.fhem.de/index.php/topic,112871.msg1072542.html#msg1072542) auch schon was zu dem Thema geschrieben. Damals dachte ich, es stand im Zusammenhang mit einem anderen Fehler/Änderung in CUL_HM, mir war nicht klar, dass die Auswirkungen so krass sind. Mittlerweile kann ich erkennen, dass das Problem mit "zu oft triggern" auch bei anderen DOIFs auftritt, dadurch wird meine CCU zu oft getriggert, so dass das Funkkontigent von 36 Sek. pro Stunde im schlimmsten Fall erschöpft ist. Aber das Problem hatte ich definitiv früher nicht. Ist irgendwas an FHEM geändert worden, so dass DOIF möglicherweise grundsätzlich zu häufig triggert? Hat sonst niemand das Problem?
Also kann sein ich verstehe DOIF im Perlmodus nicht, aber wenn Du nur einen Schnipsel aus dem Ausführungsteil zeigst, kann keiner daraus ableiten warum dieser getriggert / ausgeführt wird.
Es kann doch sein: Du triggerst auf (Willi hat Husten){Dein Perl Ausführungsteil} Dein [Garage_TorNeigung] im Ausführungsteil ist ein Reading welches einfach durch den Wert ersetzt wird.
Ok gerade Deinen Link gelesen, DOIF Perl ist nichts für mich :'(
Aber dann ist es ja noch schlimmer als gedacht?!? Du triggerst auf jedes Event von [Garage_TorNeigung] - also 8 mal pro Sendung!? Oder ich versteh es immer noch nicht ??? es soll so nur auf state triggern ?
Woher kommt den zu diesem Zeitpunkt die Ausführung?
2020-08-25 09:24:51 HMCCU myHMCCU hmscript /opt/fhem/hmscript.scr Device=DISP000001 Text="/6 '@p03@t06 open'"
Gut ich sehe schon, das übersteigt meinen Horizont. Ich würde das anders lösen... mit mehr Kontrolle für mich ;)
Ob FHEM oder Perl-Modus [Garage_TorNeigung] reagiert auf alle Events von Garage_TorNeigung, wenn du nur auf den Status triggern willst, dann musst du [Garage_TorNeigung:state] angeben.
Hi Damian,
ist das kürzlich geändert worden? Oder ist die Commandref nur etwas missverständlich an dieser Stelle:
ZitatOperanden in der Bedingung und den Befehlen und im Perl-Modus
Status [<Device>⟨,<Default>⟩]
ZitatStatus werden mit [<devicename>], Readings mit [<devicename>:<readingname>], Internals mit [<devicename>:&<internal>] angegeben.
Ich hätte schwören können, dass es bei mir am Anfang ohne überflussige Trigger funktioniert hat.
Vorschlag:
attr Garage_TorNeigung event-on-change-reading .*
define einNameDeinerWahl notify Garage_TorNeigung:(open|closed) set myHMCCU hmscript /opt/fhem/hmscript.scr Device=DISP000001 Text=\"/6 '\@p03\@t06 $EVENT'\"
Praktisch ohne alles überflüssige :)
Gruß Otto
Zitat von: tndx am 25 August 2020, 20:02:49
Hi Damian,
ist das kürzlich geändert worden? Oder ist die Commandref nur etwas missverständlich an dieser Stelle:
Ich hätte schwören können, dass es bei mir am Anfang ohne überflussige Trigger funktioniert hat.
Hat auch, siehe: https://fhem.de/commandref_DE.html#DOIF_checkReadingEvent
Dann hast du wohl länger davor kein Update gemacht, siehe https://forum.fhem.de/index.php?topic=82523.0
Allerdings hatte deine Angabe [Garage_TorNeigung] immer schon auf alle Events des Devices reagiert.
Ich habe mein FHEM in Februar 2020 neu aufgesetzt, spätestens da sollte ich ja die in 2018 angekündigte Änderung drin haben müssen ???
Die DOIFs im Perl-Modus kamen erst im April-Mai 2020 dazu, die Probleme habe ich aber erst seit Mitte Juli 2020... Ich werde nicht schlau daraus, aber sei es drum. Ich habe halt die Commandref so interpretiert, dass [<devicename>]==[<devicename>:state]. Vielleicht solltest Du die Stellen in der Commandref aus meinem letzten Post etwas deutlicher formullieren.
Ansonsten sollte ich mit [<devicename>:state] erstmal weiter kommen, wenn ich die von Otto vorgeschlagenen Änderungen in meinen DOIFs nachbilde, kann ich sogar die unerwünschten Statuswerte bei Aktoren ignorieren.
Vielen Dank Euch beiden!
P.S.: Eine Sache gibt mir aber trotzdem keine Ruhe. Wenn [Garage_TorNeigung] auf alle Events triggert, warum wird dann mein DOIF deutlich seltener ausgeführt:
2020-08-25 20:07:01 HMCCU myHMCCU hmscript /opt/fhem/hmscript.scr Device=DISP000001 Text="/6 '@p03@t06 closed'"
2020-08-25 20:07:01 CUL_HM Garage_TorNeigung aesCommToDev: pending
2020-08-25 20:07:04 HMCCU myHMCCU hmscript /opt/fhem/hmscript.scr Device=DISP000001 Text="/6 '@p03@t06 open'"
2020-08-25 20:07:04 CUL_HM Garage_TorNeigung aesCommToDev: ok
2020-08-25 20:07:04 CUL_HM Garage_TorNeigung battery: ok
2020-08-25 20:07:04 CUL_HM Garage_TorNeigung commState: CMDs_done
2020-08-25 20:07:04 CUL_HM Garage_TorNeigung contact: open (to VCCU)
2020-08-25 20:07:04 CUL_HM Garage_TorNeigung open
2020-08-25 20:07:04 CUL_HM Garage_TorNeigung trig_aes_VCCU: ok:253
2020-08-25 20:07:04 CUL_HM Garage_TorNeigung trigger_cnt: 253
2020-08-25 20:07:29 HMCCU myHMCCU hmscript /opt/fhem/hmscript.scr Device=DISP000001 Text="/6 '@p03@t06 open'"
2020-08-25 20:07:29 CUL_HM Garage_TorNeigung aesCommToDev: pending
2020-08-25 20:07:33 HMCCU myHMCCU hmscript /opt/fhem/hmscript.scr Device=DISP000001 Text="/6 '@p03@t06 closed'"
2020-08-25 20:07:33 CUL_HM Garage_TorNeigung aesCommToDev: ok
2020-08-25 20:07:33 CUL_HM Garage_TorNeigung battery: ok
2020-08-25 20:07:33 CUL_HM Garage_TorNeigung commState: CMDs_done
2020-08-25 20:07:33 CUL_HM Garage_TorNeigung contact: closed (to VCCU)
2020-08-25 20:07:33 CUL_HM Garage_TorNeigung closed
2020-08-25 20:07:33 CUL_HM Garage_TorNeigung trig_aes_VCCU: ok:254
2020-08-25 20:07:33 CUL_HM Garage_TorNeigung trigger_cnt: 254
ZitatP.S.: Eine Sache gibt mir aber trotzdem keine Ruhe. Wenn [Garage_TorNeigung] auf alle Events triggert, warum wird dann mein DOIF deutlich seltener ausgeführt
Events die zu einem Eventblock gehören (erkennbar an gleicher Zeit) triggern DOIF nur einmal.
OK, das ergibt Sinn, Danke!
ZitatEvents die zu einem Eventblock gehören (erkennbar an gleicher Zeit) triggern DOIF nur einmal.
Mit gesetztem globalen Attribut mseclog werden die Blöcke offensichtlicher, s. https://wiki.fhem.de/wiki/Event#Erweiterung_des_angezeigten_Zeitstempels_um_Milisekunden ff.