Hallo zusammen,
eigentlich funktioniert mein FHEM mit Homematic ganz gut...
Verwende mittlerweile 43 Geräte für eine Alarmanlage und Lichtsteuerung.
Gelegentlich steht im LOG:
CUL_HM FL.EG.gong attack:1129A083322BFA8002010108:1129A083322BFA800101FF22000000000000000000.
Das FL.EG.gong ist der Funkgong (HM-OU-CFM-PL).
HMLAN Adapter sind zwei Stück im Einsatz.
Wie kann ich raus kriegen, woher diese Meldung kommt ?
mfg
Klaus
Bei mir kommt das bei einem 4-Kanalswitch wenn ich mehr als 2Switche auf einmal schalte.
Gesendet von meinem GT-I9295
Scheint wohl so zu sein, wenn das Gerät mehrere Dinge erledigen soll, dass sich dann irgendwas überholt ...
Kann man das Attack prüfen abschalten ?
ZitatHMLAN Adapter sind zwei Stück im Einsatz.
hast du sie mit vccu im einsatz? wenn ja, wie sieht IOgrp vom device aus? und wenn kein prefferd io, wie sehen die rssi beim device aus?
ZitatKann man das Attack prüfen abschalten ?
warum?
Zitat von: frank am 17 Februar 2015, 11:31:04
hast du sie mit vccu im einsatz? wenn ja, wie sieht IOgrp vom device aus? und wenn kein prefferd io, wie sehen die rssi beim device aus?
Hallo Frank,
das sind die Werte:
rssi_HMLAN1 avg:-62.86 min:-72 max:-53 lst:-59 cnt:90
rssi_at_HMLAN1 avg:-65.27 min:-75 max:-55 lst:-61 cnt:143
rssi_at_HMLAN2 avg:-71.34 min:-78 max:-68 lst:-71 cnt:137
IOgrp vccu:HMLAN1
Ich dachte, wenn es zu den Attack Meldungen kommt, welche evtl. keine sind, dann schalte ich einfach diese Funktion ab ..
ZitatIch dachte, wenn es zu den Attack Meldungen kommt, welche evtl. keine sind, dann schalte ich einfach diese Funktion ab ..
du möchtest also ein "sauberes" log. meine meinung ist da eher, lieber das im log lassen und die funktionen/messagehandling verbessern.
deine werte und einstellungen sehen schlüssig aus. du müsstest für martin eventuell mal raw-messages sniffen. irgendwann gab es mal einen thread, ich glaube mit franky08, da gab es ein ähnliches problem mit einer statusanzeige. da wurde, wenn ich mich richtig erinnere, zuviel auf einmal gesetzt/gesendet.
Richtig :)
Passiert bei mir, wenn ich den Server neu starte und sämtliche Stati neu eingelesen werden. In diesem Moment ist meist einer, von den zwei HMLAN IO´s noch nicht connectet und vccu meldet attack. Stört aber nicht, ist ja nur ein Logeintrag ;)
VG
Frank
Ich habe probiert folgenden Code zeitlich zu entzerren, ist mir aber nicht gelungen...
define FL.UG.tk.pr.open watchdog FL.UG.tk.pr:open 00:00:30 FL.UG.tk.pr:closed {if(ReadingsVal('Wetterstation','temperature','') < 15) {fhem('define FL.UG.tk.pr.timer at +*{12}00:00:15 set FL.EG.gong.mp3 playTone 3,3 ;; set FL.EG.gong.led led orangeS 150')}}; trigger FL.UG.tk.pr.open .
Hat jemand einen Tipp ?
Scheint so, das beim gleichzeitigen playTone und led orangeS ab und zu einem attack kommt..
Das problem im ersten fall ist die lange serie 000 am ende. Die message ist nicht die erwartete.
Warum die 000 angehaengt werden ist unklar.. macht evtl dein io
Zitat von: martinp876 am 19 Februar 2015, 19:55:09
Das problem im ersten fall ist die lange serie 000 am ende. Die message ist nicht die erwartete.
Warum die 000 angehaengt werden ist unklar.. macht evtl dein io
Hm, als IO habe ich zwei HMLAN Adapter ..
Kann ich den Fehler irgendwie einkreisen ?
logge einmal eine Sequenz und schicke sie. Natürlich mit einem solchen Event.
haben die beiden HMLAN die gleiche ID? Verwendet du eine vccu
Zitat von: martinp876 am 21 Februar 2015, 09:41:47
logge einmal eine Sequenz und schicke sie. Natürlich mit einem solchen Event.
haben die beiden HMLAN die gleiche ID? Verwendet du eine vccu
HMLAN haben gleiche ID.
VCCU ist im Einsatz, siehe oben.
Ich werde mal versuchen die Fhelersituation nachzustellen ...
Also sniffen kann ich mir sparen...
Fehler tritt immer dann auf, wenn unmittelbar nach der LED der GONG oder umgekehrt angesprochen wird.
Nachdem ich einen sleep 1 zwischen den Kommandos eingebaut habe, tuts ohne attack ..
Guckst Du:
.... set FL.EG.gong.led led greenL 255 ;;;; sleep 1 ;;;; set FL.EG.gong.mp3 playTone 09 ....
ZitatGuckst Du:
.... set FL.EG.gong.led led greenL 255 ;;;; sleep 1 ;;;; set FL.EG.gong.mp3 playTone 09 ..
seh nix.... habe das Device nicht.
Hallo,
habe auch das Problem mit attack-Logeinträgen seit letzte Woche ich einen Homemtic-Rauchmelder durch einen neuen Bosch Ferion OW ersetzt habe.
Der Neue wurde mittels autocreate angelegt und gepairt. Funktioniert alles tadellos bis auf die attack-Meldungen, die das Protokoll zumüllen.
Die restlichen Homematic-RM funktionieren weiterhin wie gewohnt. So recht gibt es für das Problem keine Lösung, habe mit event-on-change-reading
und event-min-intervall versucht, die Meldungen zu unterdrücken. Ohne Erfolg. Vccu und IODev Einträge geprüft. Kein Erfolg.
Lösung auf die harte Tour, die Zeile:
Log3 $mh{dstN},2,"CUL_HM $mh{dstN} attack:$mh{dstH}->{helper}{cSnd}:".$tm
aus 10_CUL_HM entfernen. Dann ist Ruhe mit den Log-einträgen. Komisch ist nur, das die Rauchmelder baugleich sind und auch die gleiche FW 1.1 besitzen.
Logge die messages des RM und Teile die hmids in deinem system mit. Welche ID wird den als attack angezeigt?
Evtl sind die devices nur fwaehnlich
Auszug aus altem Log:
Die ID 1EBF55 gehört mir nicht.
Daemon with PID 24005 started!
2016.01.22 02:00:00 3: System Neustart HM-USB-Adapter
2016.01.22 02:00:00 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
2016.01.22 02:00:00 1: HMLAN_Parse: hmusb new condition disconnected
2016.01.22 02:00:01 1: 127.0.0.1:1234 reappeared (hmusb)
2016.01.22 02:00:01 1: HMLAN_Parse: hmusb new condition init
2016.01.22 02:00:02 1: HMLAN_Parse: hmusb new condition ok
2016.01.22 02:10:16 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 02:10:17 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 02:10:19 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 02:10:20 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 02:10:20 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 02:40:22 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 02:40:22 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 03:10:28 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 03:10:29 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 03:40:34 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 03:40:36 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 03:40:36 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 03:40:37 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 04:10:40 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 04:10:40 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
2016.01.22 04:10:41 2: CUL_HM RM_232E02 attack:,011EBF07340289010E:11EBF55340289010E
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ein List vom RM_232E02 und von eimem HM-RM . Seriennummer entfernt.,
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Internals:
CFGFN /opt/fhem/FHEM/HOMEMATIC_Komponenten.cfg
DEF 340289
IODev hmusb
LASTInputDev hmusb
MSGCNT 215
NAME RM_232E02
NR 347
NTFY_ORDER 50-RM_232E02
STATE off
TYPE CUL_HM
hmusb_MSGCNT 215
hmusb_RAWMSG E1EBF55,0000,0861BCDC,FF,FFA5,55B0011EBF55340289010E
hmusb_RSSI -91
hmusb_TIME 2016-01-23 08:46:37
lastMsg No:03 - t:10 s:340289 d:1EBF07 0601010051
peerList self01,
protCmdDel 1
protErrIoAttack 213 last_at:2016-01-23 08:46:37
protErrIoId_1EBF55 213 last_at:2016-01-23 08:46:37
protLastRcv 2016-01-22 08:41:19
protResnd 1 last_at:2016-01-22 08:11:16
protResndFail 1 last_at:2016-01-22 08:11:22
protSnd 3 last_at:2016-01-22 08:41:19
protState CMDs_done
rssi_at_hmusb avg:-82 min:-82 max:-82 lst:-82 cnt:2
rssi_hmusb avg:-81 min:-81 max:-81 lst:-81 cnt:1
sdTeam sdLead
Readings:
2016-01-22 08:10:50 Activity alive
2016-01-21 17:44:56 CommandAccepted yes
2016-01-21 17:43:22 D-firmware 1.1
2016-01-21 17:43:22 D-serialNr LBO0180056
2016-01-21 17:48:45 PairedTo 0x1EBF07
2016-01-21 17:43:26 R-pairCentral 0x1EBF07
2016-01-21 17:48:45 RegL_00: 02:01 0A:1E 0B:BF 0C:07 00:00
2016-01-22 08:41:19 battery ok
2016-01-21 17:47:36 eventNo 0C
2016-01-22 08:41:19 level 1
2016-01-22 08:10:50 peerList self01,
2016-01-21 17:48:39 powerOn 2016-01-21 17:48:39
2016-01-22 08:41:19 recentStateType info
2016-01-23 08:46:37 sabotageAttackId_ErrIoId_1EBF55 cnt:213
2016-01-22 07:11:17 sabotageAttack_ErrIoAttack cnt 58
2016-01-23 08:46:37 sabotageAttack_ErrIoAttack cnt 213
2016-01-21 17:47:36 smoke_detect none
2016-01-22 08:41:19 state off
2016-01-21 20:04:35 teamCall from RM_232E02:8
Helper:
HM_CMDNR 3
cSnd 011EBF07340289010E,011EBF07340289010E
fkt sdLead
mId 0042
rxType 2
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +340289,00,00,00
nextSend 1453448479.57343
prefIO
rxt 0
vccu
p:
340289
00
00
00
Mrssi:
mNo 03
Io:
hmusb -80
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO hmusb
flg A
ts 1453448479.50234
ack:
HASH(0x2b97fb8)
0380021EBF0734028900
Rssi:
At_hmusb:
avg -82
cnt 2
lst -82
max -82
min -82
Hmusb:
avg -81
cnt 1
lst -81
max -81
min -81
Attributes:
IODev hmusb
actCycle 028:00
actStatus alive
alias RM_Z0
autoReadReg 4_reqStatus
devStateIcon off:RM_on dead:RM_off set_test:RM_T set_alarmOff:RM_on set_alarmOn:RM_AT MISSIN.*:RM_off RESPON.*:RM_off smoke-Alarm:RM_A smoke_detect:RM_A
expert 2_full
firmware 1.1
fp_Alarm 240,370,0,
group Rauchmelder
model HM-SEC-SD
msgRepeat 1
peerIDs 00000000,34028901,
room Alarm
serialNr ??????????
subType smokeDetector
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
und hier von einem HM-RM:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Internals:
CFGFN /opt/fhem/FHEM/HOMEMATIC_Komponenten.cfg
DEF 2A55E5
IODev hmusb
LASTInputDev hmusb
MSGCNT 3
NAME RM_2A55E5
NR 332
NTFY_ORDER 50-RM_2A55E5
STATE off
TYPE CUL_HM
hmusb_MSGCNT 3
hmusb_RAWMSG E2A55E5,0000,031B13EB,FF,FFA8,02A0102A55E51EBF070601010059
hmusb_RSSI -88
hmusb_TIME 2016-01-22 08:11:19
lastMsg No:02 - t:10 s:2A55E5 d:1EBF07 0601010059
peerList self01,
protLastRcv 2016-01-22 08:11:19
protResnd 1 last_at:2016-01-22 08:11:16
protSnd 3 last_at:2016-01-22 08:11:19
protState CMDs_done
rssi_at_hmusb avg:-89.33 min:-90 max:-88 lst:-88 cnt:3
rssi_hmusb avg:-89.5 min:-90 max:-89 lst:-89 cnt:2
sdTeam sdLead
Readings:
2016-01-22 08:10:51 Activity alive
2015-12-11 19:59:03 CommandAccepted yes
2015-12-11 15:20:43 D-firmware 1.1
2015-12-11 15:20:43 D-serialNr LEQ0228825
2015-12-11 20:25:29 PairedTo 0x1EBF07
2015-12-10 18:28:41 R-pairCentral 0x1EBF07
2015-12-11 20:25:29 RegL_00: 02:01 0A:1E 0B:BF 0C:07 00:00
2016-01-22 08:11:19 battery ok
2016-01-19 19:26:19 eventNo 0C
2016-01-22 08:11:19 level 1
2016-01-22 08:10:50 peerList self01,
2016-01-22 08:11:19 recentStateType info
2016-01-19 19:26:19 smoke_detect none
2016-01-22 08:11:19 state off
2015-12-11 20:10:15 teamCall from RM_2A55E5:1
Helper:
HM_CMDNR 2
cSnd ,011EBF072A55E5010E
fkt sdLead
mId 0042
rxType 2
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +2A55E5,00,00,00
nextSend 1453446679.48006
prefIO
rxt 0
vccu
p:
2A55E5
00
00
00
Mrssi:
mNo 02
Io:
hmusb -86
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO hmusb
flg A
ts 1453446679.38461
ack:
HASH(0x2b96ed0)
0280021EBF072A55E500
Rssi:
At_hmusb:
avg -89.3333333333333
cnt 3
lst -88
max -88
min -90
Hmusb:
avg -89.5
cnt 2
lst -89
max -89
min -90
Attributes:
IODev hmusb
actCycle 028:00
actStatus alive
alias RM_Z7
autoReadReg 4_reqStatus
devStateIcon off:RM_on dead:RM_off set_test:RM_T set_alarmOff:RM_on set_alarmOn:RM_AT MISSIN.*:RM_off RESPON.*:RM_off smoke-Alarm:RM_A smoke_detect:RM_A
expert 2_full
firmware 1.1
fp_Alarm 80,225,1,
group Rauchmelder
model HM-SEC-SD
msgRepeat 1
peerIDs 00000000,2A55E501,
room Alarm
serialNr ???????????
subType smokeDetector
webCmd teamCall:alarmOff:alarmOn
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Das verhalten ist..... Zumindest neu für mich. Kannst du doch einmal sniffen wie unter sniffen beschrieben?