Moin,
ich steh gerade auf dem Schlauch, vielleicht kann jemand helfen ?
Ich möchte bei einem Kanal eines HM-MOD-Em-8 die eventFilterTime nutzen und habe das Register dazu testweise auf 600 Sekunden gesetzt. Sinn der Sache ist, dass der Kanal nach einem gesendeten Eingangssignal anschließend für 600 Sekunden nicht mehr sendet, auch wenn weitere Signale an TA1 kommen. Also eine Kanalsperre für 600 Sekunden.
Ist das Funktionsprinzip so richtig ?
In der Praxis (bei mir) sind keine Einflüssen des Registers eventFilterTime auf die Funktion erkennbar. Jeder Eingangsimpuls an TA1 wird gesendet.
List vom Device
DEF 31313F
HMLAN1_MSGCNT 126
HMLAN1_RAWMSG E31313F,0000,19FFE443,FF,FFD4,26A24131313F123ABC0119C8
HMLAN1_RSSI -44
HMLAN1_TIME 2018-01-21 02:07:25
HMLAN2_MSGCNT 68
HMLAN2_RAWMSG E31313F,0000,1A43BC2C,FF,FFA0,26A24131313F123ABC0119C8
HMLAN2_RSSI -96
HMLAN2_TIME 2018-01-21 02:07:26
IODev HMLAN1
LASTInputDev HMLAN2
MSGCNT 194
NAME HM_31313F
NOTIFYDEV global
NR 855
NTFY_ORDER 50-HM_31313F
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_31313F_Btn_01
channel_02 HM_31313F_Btn_02
channel_03 HM_31313F_Btn_03
channel_04 HM_31313F_Btn_04
channel_05 HM_31313F_Btn_05
channel_06 HM_31313F_Btn_06
channel_07 HM_31313F_Btn_07
channel_08 HM_31313F_Btn_08
lastMsg No:26 - t:41 s:31313F d:123ABC 0119C8
protCmdDel 5
protLastRcv 2018-01-21 02:07:26
protNack 1 last_at:2018-01-21 02:01:58
protSnd 121 last_at:2018-01-21 02:07:25
protState CMDs_done
rssi_at_HMLAN1 cnt:126 max:-39 min:-57 avg:-42.11 lst:-44
rssi_at_HMLAN2 lst:-96 avg:-96.97 min:-104 max:-92 cnt:68
READINGS:
2018-01-21 02:03:53 CommandAccepted yes
2018-01-21 02:03:52 D-firmware 1.0
2018-01-21 02:03:52 D-serialNr LEQ1114385
2018-01-21 02:03:56 PairedTo 0x123ABC
2018-01-21 01:54:20 R-ledMode on
2018-01-21 01:54:20 R-localResDis off
2018-01-21 01:54:20 R-lowBatLimitBA2 0 V
2018-01-21 01:54:20 R-pairCentral 0x123ABC
2018-01-21 01:54:20 R-transmDevTryMax 3
2018-01-21 02:03:56 RegL_00. 02:01 05:40 0A:12 0B:3A 0C:BC 12:00 14:03 18:00 00:00
2018-01-21 01:54:04 alive yes
2018-01-21 02:07:25 battery ok
2018-01-21 01:54:04 powerOn 2018-01-21 01:54:04
2018-01-21 01:54:04 recentStateType info
2018-01-21 02:07:25 state CMDs_done
List vom Kanal
DEF 31313F01
NAME HM_31313F_Btn_01
NOTIFYDEV global
NR 858
NTFY_ORDER 50-HM_31313F_Btn_01
STATE 0
TYPE CUL_HM
chanNo 01
device HM_31313F
Helper:
DBLOG:
state:
logdb:
TIME 1516496845.98898
VALUE open
READINGS:
2018-01-21 02:03:53 R-eventFilterTime 600 s
2018-01-21 01:54:21 R-longPress 0.4 s
2018-01-21 01:54:21 R-msgScPosA closed
2018-01-21 01:54:21 R-sign off
2018-01-21 01:54:21 R-transmitTryMax 3
2018-01-21 01:54:21 R-triggerMode sensor
2018-01-21 02:03:56 RegL_01. 04:10 08:00 20:60 23:8A 30:03 92:21 00:00
2018-01-21 02:07:25 contact open (to vccu)
2018-01-21 02:07:25 state open
2018-01-21 02:07:25 trigger_cnt 25
helper:
peerIDsRaw ,00000000
regLst ,1,4p
expert:
def 1
det 1
raw 1
tpl 1
role:
chn 1
shadowReg:
tmpl:
Attributes:
DbLogInclude state
comment Testdevice
devStateIcon 100:weather_rain_heavy@blue 0:weather_sun@red .*:message_attention@red
event-on-update-reading state
eventMap closed:100 open:0
expert 251_anything
group HM-MOD-Em-8
model HM-MOD-Em-8
peerIDs 00000000,
room Test
subType threeStateSensor
Entweder stmmt meine Theorie nicht oder ich mach nen Fehler ... :'(
Moin und schon mal Danke für Eure Hilfe !
Bernd
es fällt mir gerade hochnotpeinlich auf, dass ich hier falsch lag. eventFilterTime ignoriert eigentlich alle kurzfristigen Änderungen am Eingang außer sie sind dann letztlich für diese Zeit stabil?
Weitere Meinungen?
Schade...
ich hatte gehofft, mit den Infos aus dem "PIR-Thread" ein altes, offenes Problem elegant lösen zu können.
Allesdings, bei einer eingestellten Filterzeit von 600 Sekunden kommen meine kurzen Trigger (< 1 Sekunde) durch ? Die müssten dann doch als "Störimpuls" ignoriert werden - oder geht es bei der Filterei um die Flankensteilheit am Input (dann wäre die zulässige Range allerdings viel zu groß). Sorry für die blöden Fragen, aber ich nix Ahnung - leider.
Ist der HM-MOD-Em-8 einigermaßen erforscht oder gibt es noch viele weiße Flecken ? Vielleicht muss man den Filter noch zusätzlich einschalten oder er funktioniert nur in einem anderen Mode ?
Bernd
Du beziehst Dich auf diesen Thread (https://forum.fhem.de/index.php/topic,72186.0.html)?
Oder welchen?`
Ich habe jetzt mein übriges EM-8 rausgekramt und mit eventFilterTime herumprobiert. Es hat - egal ob es die Aussendung verzögern oder weitere Aussendugen unterbinden soll - schlicht null Effekt. Ich habe die Firmware 1.0, wie Du.
Kann das nochmal jemand anderes bestätigen oder dementieren? oldman aus dem o.g. Thread liefert mir hoffentlich Infos betreffs Firmware 1.1
Übrigens besitzt das Register "stabFltTime" beim Modul HM-MOD-EM-8bit im Datenkanal so oder so die gewünschte Eigenschaft, dort kann man sie auch konfigurieren, siehe Wiki-Artikel (https://wiki.fhem.de/wiki/HM-MOD-EM-8bit_3-Kanal-Sendemodul_mit_8-Bit-Datenkanal). Die Infos dort sind aber theoretisch und nicht wirklich verifiziert, aber zumindest so laut Doc von eQ3. Im Artikel unter Modus 5 und 7 beschrieben.
Nachtrag:
Das meine Kellerfenster überwachende EM-8 steht auf eventFilterTime 5s. Da kann ich im 2-Sekunden-Takt das Fenster auf- und zumachen und jedes Änderung wird umgehend gemeldet. Und dort ist Firmware 1.1 aktiv.
Da ist was faul.
Übrigens: Bei meinem Neigungssensor HM-SEC-TIS funktioniert das einwandfrei. Seit ich dort 4 Sekunden eingestellt habe, bekomme ich keine Statusänderungen mehr wenn der Ball gegen das Garagentor donnert und alles vibriert.
ZitatDu beziehst Dich auf diesen Thread?
Oder welchen?`
Ja, dadurch bin ich erst wieder darauf gekommen. Ich hatte das Problem für mich schon vor einiger Zeit beerdigt und nun noch einmal probiert.
Test mit FW 1.1 (wie Du schon geschrieben hast) bei mir auch negativ. D.h. keine erkennbaren Auswirkungen von eventFilterTime.
Siehst Du irgendwie ne Chance ?
Ich denke ich werde mal bei den Nachbarn nach deren Erfahrungen fragen und eine Anfrage an ELV schicken.
Martin könnte vielleicht auch nochmal drübersehen. Setzen und Auslesen lässt sich das Register ja klaglos, aber das wäre nicht das erste Mal, wenn das nicht sauber in der Firmware umgesetzt ist. Die scheinen die Module eh outgesourct zu haben, so lausig wie die laufen. Der Bug mit der Laufzeit beim Re-8 ist bis heute nicht gefixt. Wenn sie dann noch den Batteriesparmodus ausschaltbar machen könnten (Device benötigt keinen Burst), wäre das Modul ja ein Renner.
Aber das ist eine andere Baustelle.
Danke, dass Du Dich darum kümmern willst !
Wenn ich helfen kann, sag Bescheid. Ich habe bloss überhaupt keine Ahnung vom Kommunikationsprotokoll und den anderen Internas. Bin mehr auf der Anwendungsebene aktiv, aber lerne gern dazu.
Moin
Bernd