Hallo,
ich habe einen Funk-Schalterschnittstelle 3fach (Unterputzmontage) für meine Klingel eingesetzt. Dabei triggere ich auf Events um den Gong dann durch einen Aktor zu schalten.
Mein Notify sieht wie folgt aus:
Haustuere_Gong_Schalter.Haustuere_Gong_Schalter_Sw_01.Short set Aktor_NodOn2 on-for-timer 0.1;set Pushover msg title="Haustüre" message="Es hat geklingelt!";set Arlo_Eingang snapshot
Das Problem ist, dass bei einem kurzen Drücken unregelmässig aber meistens zweimal der Event Haustuere_Gong_Schalter Haustuere_Gong_Schalter_Sw_01 Short ausgelöst wird und somit das notify auch zweimal ausgeführt wird.
2 Fragen stellen sich mir:
- Kann ich den Event auf jeden fall innerhalb einer Zeit (z.b. 1 Sekunde) nur einmal ausführen lassen? Also das Zweimal unterbinden?
- Wenn ich am Event nichts ändern kann, kann ich das Notify so ändern, dass es nur auf einen Event innerhalb einer Sekunde auslöst...
Danke für Eure Hilfe..
Lg c
Es könnte mit event-on-change-reading am "sendenden/Event erzeugenden" Device gehen...
Nur ein Event bei Änderung...
Oder man kann auch per Attribut beim Notify dieses für eine gewisse Zeit "tot" schalten...
disabledAfterTrigger beim Notify...
Gruß, Joachim
Hallo in Schweiz :)
falsche Schnittstelle?
Der HM-PBI-4-FM ist für die Klingel (Push Button). Der SWI ist ein Switch Interface, der ist für Schalter. Der liefert trigger beim Schließen und beim Öffnen ;)
Gruß Otto
zeige doch mal bitte die Events aus dem Eventmonitor
und b. ein list von device und Kanal
das Teil schickt definitiv 2 Events einmal geschlossen und geoffnet , aber ohne Zustand.
ui, das ging ja schnell.. Herzlichen Dank für die Antworten..
Zitat von: fhem-hm-knecht am 24 Juni 2019, 22:23:04
das Teil schickt definitiv 2 Events einmal geschlossen und geoffnet , aber ohne Zustand.
here we go:
2019-06-24 22:25:09 CUL_HM Haustuere_Gong_Schalter battery: ok
2019-06-24 22:25:09 CUL_HM Haustuere_Gong_Schalter Haustuere_Gong_Schalter_Sw_01 Short
2019-06-24 22:25:09 CUL_HM Haustuere_Gong_Schalter_Sw_01 Short 1_103 (to broadcast)
2019-06-24 22:25:09 CUL_HM Haustuere_Gong_Schalter_Sw_01 trigger: Short_103
2019-06-24 22:25:09 CUL_HM Haustuere_Gong_Schalter_Sw_01 trigger_cnt: 103
2019-06-24 22:25:09 CUL_HM Haustuere_Gong_Schalter battery: ok
2019-06-24 22:25:09 CUL_HM Haustuere_Gong_Schalter Haustuere_Gong_Schalter_Sw_01 Short
2019-06-24 22:25:09 CUL_HM Haustuere_Gong_Schalter_Sw_01 Short 1_104 (to broadcast)
2019-06-24 22:25:09 CUL_HM Haustuere_Gong_Schalter_Sw_01 trigger: Short_104
2019-06-24 22:25:09 CUL_HM Haustuere_Gong_Schalter_Sw_01 trigger_cnt: 104Zitat von: Otto123 am 24 Juni 2019, 22:16:53
falsche Schnittstelle?
Der HM-PBI-4-FM ist für die Klingel (Push Button). Der SWI ist ein Switch Interface, der ist für Schalter. Der liefert trigger beim Schließen und beim Öffnen ;)
Hallo Otto, mein FHEM Gott.. sag sowas nicht... Als Laie kommt man mit diesen Taster, Schalter, Schalterschnittstelle etc nicht mehr draus... muss ich mir nun wirklich dieses Teil besorgen. Wenn es doch ein öffnen und schliessen liefert, wieso sieht man es dann nicht im Event?
Zitat von: MadMax-FHEM am 24 Juni 2019, 21:59:17
Oder man kann auch per Attribut beim Notify dieses für eine gewisse Zeit "tot" schalten...
disabledAfterTrigger beim Notify...
das könnte die Lösung sein. Kann ich erst morgen testen, sonst bring ich meine Frau um den Schlaff... nix gut ;)
Zitat von: choetzu am 24 Juni 2019, 22:33:29
Als Laie kommt man mit diesen Taster, Schalter, Schalterschnittstelle etc nicht mehr draus... muss ich mir nun wirklich dieses Teil besorgen. Wenn es doch ein öffnen und schliessen liefert, wieso sieht man es dann nicht im Event?
Es gibt sogar einen dedizierten Türklingelsensor (https://www.elv.de/homematic-funk-klingelsignalsensor-bausatz.html) genau für diesen Zweck. Bausatz ist hier übrigens eine schamlose Übertreibung.
Zitat von: Christoph Morrison am 24 Juni 2019, 22:37:54
Es gibt sogar einen dedizierten Türklingelsensor (https://www.elv.de/homematic-funk-klingelsignalsensor-bausatz.html) genau für diesen Zweck. Bausatz ist hier übrigens eine schamlose Übertreibung.
Ok, ich oute mich jetzt als Depp (erneut):) Den hab ich mir als erstes gekauft und für meine vehältnisse gut zusammengelötet. Ausser blöd blinken, tut das Teil grad gar nix... und ich weiss echt nicht was ich falsch gemacht habe,, drum bin ich auf eine Alternative umgestiegen... da steh ich nun..;)
Es gibt auch noch den SCI. Ich weiß die Erklärung von EQ3 dazu ist ziemlich grottig. ::)
Pfriemler hatte das schon mal gut zusammengefasst:
https://forum.fhem.de/index.php/topic,72489.msg641113.html#msg641113
Ja, sehr gut erklärt. Das hilft. Ich hoffe nun auf disabledAfterTrigger. Staunen wir mal morgen, was passiert..
Zitat von: choetzu am 24 Juni 2019, 22:47:14
Ok, ich oute mich jetzt als Depp (erneut):) Den hab ich mir als erstes gekauft und für meine vehältnisse gut zusammengelötet. Ausser blöd blinken, tut das Teil grad gar nix... und ich weiss echt nicht was ich falsch gemacht habe,, drum bin ich auf eine Alternative umgestiegen... da steh ich nun..;)
Hast du einen CUL!?
Ich hatte mit dem Ding auch Probleme, als ich noch einen nanoCUL hatte...
...mit der "Timing-FW" ging es dann.
Letztendlich bin ich aber jetzt komplett (inkl. Testsysteme) auf "richtige" HM-IOs umgestiegen...
Gruß, Joachim
du könntest das notify auch auf das reading trigger_count triggern lassen und auf gerade oder ungerade reagieren.
ist das device überhaupt schon gepairt?
zeig doch mal ein list, wie schon gesagt wurde.
ich vermute auch einen cul als io.
um franks Idee (reading trigger_count triggern lassen und auf gerade oder ungerade reagieren. ) aufzugreifen. Lösung mit Division modulo 2:
attr Haustuere_Gong_Schalter_Sw_01 userReadings push:trigger_cnt.* {ReadingsNum($name,"trigger_cnt","") % 2}
und das notify auf Haustuere_Gong_Schalter_Sw_01:push:.1oder Haustuere_Gong_Schalter_Sw_01:push:.0
Hallo
Danke für die Hilfe. Ich habe mal mein notify mit eine disabledAfterTrigger (2 Sek) gestellt. Heute hats 3mal geklingelt, und es funktionierte. Aber aufgrund Eurer Kommentare habe ich noch etwas recherchiert. Komischerweise ist mein Device noch nicht gepaired. Saublöd, nun muss ich alles wieder aufschrauben und den Pairknopf drücken. Mach ich morgen. Komisch nur, dass es auch ohne pairen geht.
Ich habe CUL_HM und LGW (2ter Raspi) installiert meine HM Geräte (ca 12) laufen sonst sehr stabil.
Deas UserReadings hab ich mal gemacht, Otto und Frank.
Zuerst muss ich mal pairen ;)
CUL_MSGCNT 24
CUL_RAWMSG A0B8384405F1ECD000000017E::-60:CUL
CUL_RSSI -60
CUL_TIME 2019-06-25 21:57:29
DEF 5F1ECD
FUUID 5d013907-f33f-8001-b15b-af5e0bb09580e7c4
IODev LGW_Gateway
LASTInputDev LGW_Gateway
LGW_Gateway_MSGCNT 17
LGW_Gateway_RAWMSG 0500005A8284405F1ECD000000017D
LGW_Gateway_RSSI -90
LGW_Gateway_TIME 2019-06-25 21:57:30
MSGCNT 41
NAME Haustuere_Gong_Schalter
NOTIFYDEV global
NR 642
NTFY_ORDER 50-Tuerklingel_Schalter
STATE Haustuere_Gong_Schalter_Sw_01 Short
TYPE CUL_HM
chanNo 01
channel_01 Haustuere_Gong_Schalter_Sw_01
channel_02 Haustuere_Gong_Schalter_Sw_02
channel_03 Haustuere_Gong_Schalter_Sw_03
lastMsg No:82 - t:40 s:5F1ECD d:000000 017D
protLastRcv 2019-06-25 21:57:30
protRcv 27 last_at:2019-06-25 21:57:30
rssi_at_CUL cnt:24 min:-66 max:-58.5 avg:-61.72 lst:-60
rssi_at_LGW_Gateway cnt:17 min:-90 max:-81 avg:-85.05 lst:-90
Helper:
DBLOG:
battery:
Logging:
TIME 1561492650.19602
VALUE ok
state:
Logging:
TIME 1561492650.19602
VALUE Haustuere_Gong_Schalter_Sw_01 Short
READINGS:
2019-06-12 19:59:42 D-firmware 1.3
2019-06-12 19:59:42 D-serialNr OEQ0692542
2019-06-12 19:59:44 PairedTo 0x000000
2019-06-12 19:49:07 R-pairCentral 0x000000
2019-06-25 21:57:30 battery ok
2019-06-25 21:57:30 state Haustuere_Gong_Schalter_Sw_01 Short
helper:
HM_CMDNR 130
mId 0046
peerFriend
peerOpt -:swi
regLst 0
rxType 4
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5F1ECD,00,00,00
nextSend 1561492650.27719
prefIO
rxt 0
vccu
p:
5F1ECD
00
00
00
mRssi:
mNo 82
io:
CUL:
-60
LGW_Gateway:
-88
-88
prt:
bErr 0
sProc 0
q:
qReqConf 00
qReqStat
role:
dev 1
rssi:
at_CUL:
avg -61.7291666666667
cnt 24
lst -60
max -58.5
min -66
at_LGW_Gateway:
avg -85.0588235294118
cnt 17
lst -90
max -81
min -90
tmpl:
Attributes:
IODev LGW_Gateway
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.3
model HM-SWI-3-FM
room CUL_HM
serialNr OEQ0692542
subType swi
ich würde den cul als "attr IODev" setzen, da der funk deutlich besser ist. aber möglichst mit der tsculfw flashen.
ausserdem solltest du mit zwei io auf alle fälle eine vccu definieren. eventuell ist das auch der grund für die pairingprobleme gewesen.
der frühe Vogel fängt den Wurm... Habe heute früh kurz gepaired... Jetzt sollte es gut aussehen. VCCU hab ich bereits, damit habe ich auch gepaired... Was denkt ihr?
Zitat von: frank am 25 Juni 2019, 22:55:47
aber möglichst mit der tsculfw flashen.
tsculfw flashen? Hmm, da muss ich mich mal schlau machen, das lese ich zum ersten Mal..
Und das UserReading "push" ist nun auch installiert. Heute Abend wechsle ich noch den notify. Herzlichen Dank Euch allen... Das ist richtig gut..
Internals:
CUL_MSGCNT 39
CUL_RAWMSG A0B8784405F1ECD0000000180::-60.5:CUL
CUL_RSSI -60.5
CUL_TIME 2019-06-26 07:20:25
DEF 5F1ECD
FUUID 5d013907-f33f-8001-b15b-af5e0bb09580e7c4
IODev CUL
LASTInputDev CUL
LGW_Gateway_MSGCNT 26
LGW_Gateway_RAWMSG 05010058B0A0105F1ECD0123450100000000
LGW_Gateway_RSSI -88
LGW_Gateway_TIME 2019-06-26 07:17:44
MSGCNT 65
NAME Haustuere_Gong_Schalter
NOTIFYDEV global
NR 642
NTFY_ORDER 50-Tuerklingel_Schalter
STATE Haustuere_Gong_Schalter_Sw_01 Short
TYPE CUL_HM
chanNo 01
channel_01 Haustuere_Gong_Schalter_Sw_01
channel_02 Haustuere_Gong_Schalter_Sw_02
channel_03 Haustuere_Gong_Schalter_Sw_03
lastMsg No:87 - t:40 s:5F1ECD d:000000 0180
protLastRcv 2019-06-26 07:20:25
protRcv 42 last_at:2019-06-26 07:20:25
protSnd 19 last_at:2019-06-26 07:17:44
protState CMDs_done
rssi_at_CUL cnt:39 min:-69.5 max:-53 avg:-59.75 lst:-60.5
rssi_at_LGW_Gateway cnt:26 min:-90 max:-81 avg:-85.84 lst:-88
Helper:
DBLOG:
D-firmware:
Logging:
TIME 1561526263.53168
VALUE 1.3
D-serialNr:
Logging:
TIME 1561526263.53168
VALUE OEQ0692542
R-pairCentral:
Logging:
TIME 1561526236.64105
VALUE 0x012345
battery:
Logging:
TIME 1561526425.12683
VALUE ok
state:
Logging:
TIME 1561526425.12683
VALUE Haustuere_Gong_Schalter_Sw_01 Short
READINGS:
2019-06-26 07:17:16 CommandAccepted yes
2019-06-26 07:17:43 D-firmware 1.3
2019-06-26 07:17:43 D-serialNr OEQ0692542
2019-06-26 07:17:43 PairedTo 0x012345
2019-06-26 07:17:16 R-pairCentral 0x012345
2019-06-26 07:17:43 RegL_00. 00:00 02:01 0A:01 0B:23 0C:45
2019-06-26 07:20:25 battery ok
2019-06-26 07:20:25 state Haustuere_Gong_Schalter_Sw_01 Short
helper:
HM_CMDNR 135
cSnd 010123455F1ECD0203,010123455F1ECD0303
mId 0046
peerFriend
peerOpt -:swi
regLst 0,4p
rxType 4
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5F1ECD,00,00,00
nextSend 1561526425.21097
prefIO
rxt 0
vccu
p:
5F1ECD
00
00
00
mRssi:
mNo 87
io:
CUL:
-56.5
-56.5
LGW_Gateway:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
rssi:
at_CUL:
avg -59.7564102564103
cnt 39
lst -60.5
max -53
min -69.5
at_LGW_Gateway:
avg -85.8461538461539
cnt 26
lst -88
max -81
min -90
shadowReg:
tmpl:
Attributes:
IODev CUL
IOgrp VCCU:CUL
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.3
model HM-SWI-3-FM
room CUL_HM
serialNr OEQ0692542
subType swi
webCmd getConfig:clear msgEvents
nun ist auch attr IOgrp vorhanden, wodurch die vccu das io bestimmt.
die existenz vielleicht mal bei allen devices kontrollieren; zb mit "get hminfo param -d IOgrp".
tsculfw:
https://forum.fhem.de/index.php/topic,24436.0.html (https://forum.fhem.de/index.php/topic,24436.0.html)
Zitat von: frank am 26 Juni 2019, 09:01:31
nun ist auch attr IOgrp vorhanden, wodurch die vccu das io bestimmt.
die existenz vielleicht mal bei allen devices kontrollieren; zb mit "get hminfo param -d IOgrp".
tsculfw:
https://forum.fhem.de/index.php/topic,24436.0.html (https://forum.fhem.de/index.php/topic,24436.0.html)
Super, danke. Der hminfo check war gut: überall VCCU
Beim tsculfw werd ich nicht schlau. es verfeinert den timestamp. Doch wofür genau verstehe ich nicht. Hmm