Hallo, ich bekomme seit einiger Zeit eine
2014.09.03 07:56:04 2: CUL_HM 16_LED attack:11123ABC1D481F800B02:11123ABC1D481F800B01.
2014.09.03 07:56:05 2: CUL_HM 16_LED attack:11123ABC1D481F800B01:11123ABC1D481F800B02.
Meldung.
Ein list 16_LED zeigt:
Internals:
DEF 1D481F
HMLAN1_MSGCNT 869
HMLAN1_RAWMSG E1D481F,0000,1174B4CD,FF,FFD5,5680021D481F123ABC010E010026A6559A65
HMLAN1_RSSI -43
HMLAN1_TIME 2014-09-03 08:54:30
IODev hmusb
LASTInputDev hmusb
MSGCNT 1808
NAME 16_LED
NR 284
STATE CMDs_done
TYPE CUL_HM
channel_01 16_LED_1
channel_02 16_LED_2
channel_03 16_LED_3
channel_04 16_LED_4
channel_05 16_LED_5
channel_06 16_LED_6
channel_07 16_LED_7
channel_08 16_LED_8
channel_09 16_LED_9
channel_0A 16_LED_10
channel_0B 16_LED_11
channel_0C 16_LED_12
channel_0D 16_LED_13
channel_0E 16_LED_14
channel_0F 16_LED_15
channel_10 LED_Fenster_KinderZi
hmusb_MSGCNT 939
hmusb_RAWMSG R3A4B0D40,0001,088A60FF,FF,FFD6,5680021D481F123ABC010E010026A6559A65
hmusb_RSSI -42
hmusb_TIME 2014-09-03 08:54:30
lastMsg No:56 - t:02 s:1D481F d:123ABC 010E010026A6559A65
protErrIoAttack 14 last_at:2014-09-03 07:56:05
protLastRcv 2014-09-03 08:54:30
protResnd 27 last_at:2014-09-03 07:56:03
protSnd 906 last_at:2014-09-03 08:54:29
protState CMDs_done
rssi_at_HMLAN1 avg:-47.91 min:-58 max:-40 lst:-43 cnt:869
rssi_at_hmusb avg:-41.48 min:-45 max:-36 lst:-42 cnt:939
rssi_hmusb avg:-37.66 min:-42 max:-32 lst:-38 cnt:782
CHANGETIME:
Readings:
2014-09-03 06:41:04 CommandAccepted yes
2014-06-26 13:34:11 D-firmware 1.1
2014-06-26 13:34:11 D-serialNr JEQ0218923
2014-09-03 06:41:07 PairedTo 0x123ABC
2014-09-03 06:41:07 R-brightness 1
2014-06-26 13:37:39 R-energyOpt 0 s
2014-09-02 06:39:03 R-localResDis off
2014-09-02 06:39:03 R-pairCentral 0x123ABC
2014-09-03 06:41:07 RegL_00: 02:01 04:01 08:00 0A:12 0B:3A 0C:BC 18:00 00:00
2014-09-03 08:54:30 color A6559A65
2014-07-03 14:06:17 powerOn -
2014-07-03 14:06:18 recentStateType ack
2014-09-03 07:56:05 sabotageAttack ErrIoAttack cnt:14
2014-09-03 08:54:30 state CMDs_done
Helper:
cSnd 11123ABC1D481F800E01
mId 006D
rxType 1
Io:
newChn +1D481F,00,01,00
nextSend 1409727270.7494
prefIO
rxt 0
vccu vccu
p:
1D481F
00
01
00
Mrssi:
mNo 56
Io:
HMLAN1 -43
hmusb -40
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_hmlan1:
avg -47.9194476409666
cnt 869
lst -43
max -40
min -58
At_hmusb:
avg -41.4802981895634
cnt 939
lst -42
max -36
min -45
Hmusb:
avg -37.6662404092071
cnt 782
lst -38
max -32
min -42
Shadowreg:
Attributes:
DbLogExclude .*
IODev hmusb
IOgrp vccu
autoReadReg 5_readMissing
event-on-update-reading .*
expert 2_full
firmware 1.1
fp_Plots 50,100
model HM-OU-LED16
room Wohnzimmer
serialNr JEQ0218923
subType outputUnit
webCmd getConfig
Kann das mit einem vorher stattgefundenen disconnect vom HMLAN zusammenhängen? HMLAN1 und hmusb sind in einer vccu mit gleicher hmID.
2014.09.03 07:46:02 1: 192.168.2.222:1000 disconnected, waiting to reappear (HMLAN1)
2014.09.03 07:46:02 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.09.03 07:46:02 1: 192.168.2.222:1000 reappeared (HMLAN1)
2014.09.03 07:46:02 1: HMLAN_Parse: HMLAN1 new condition init
2014.09.03 07:46:02 1: HMLAN_Parse: HMLAN1 new condition ok
2014.09.03 07:50:00 3: WS3600(Msg): myWS1080 Read started
2014.09.03 07:52:22 3: CUL_HM set 16_LED_11 led red
2014.09.03 07:52:26 3: CUL_HM set 16_LED_11 led green
2014.09.03 07:55:00 3: WS3600(Msg): myWS1080 Read started
2014.09.03 07:55:57 3: CUL_HM set 16_LED_11 led red
2014.09.03 07:56:03 3: CUL_HM set 16_LED_11 led green
2014.09.03 07:56:03 3: CUL_HM set 16_LED_11 led red
2014.09.03 07:56:03 3: CUL_HM set 16_LED_11 led green
2014.09.03 07:56:03 3: CUL_HM set 16_LED_11 led red
2014.09.03 07:56:03 3: CUL_HM set 16_LED_11 led green
2014.09.03 07:56:04 3: CUL_HM set 16_LED_11 led red
2014.09.03 07:56:04 2: CUL_HM 16_LED attack:11123ABC1D481F800B02:11123ABC1D481F800B01.
2014.09.03 07:56:05 2: CUL_HM 16_LED attack:11123ABC1D481F800B01:11123ABC1D481F800B02.
Hat Martin da einen Tipp?
VG
Frank
Hat Martin keinen Tipp?
Im gesamten Umkreis gibt es auch keinen Nachbarn, der fhem oder Homematic nutzt.
Mmh seltsam :o
VG
Frank
Leider stimmt die Aussage nicht, dass die attack Meldung nach einem disconnect kommt, habe eben im Log gesehen das es auch ohne disconnect auftritt
2014.09.04 00:00:59 3: CUL_HM set Badlicht on-for-timer 600
2014.09.04 00:00:59 2: CUL_HM 16_LED attack:11123ABC1D481F800A01:11123ABC1D481F800F01.
VG
Frank
Hatte ich so ähnlich bei einem Wandthermostaten. Pair mal versuchsweise neu, bei mir war es dann weg.
Danke für den Tipp, pairing vergessen, hatte ich schon einmal mit einem Schaltaktor. Versuch ich morgen mal.
VG
Frank
Dieser Log kommt, wenn eine schalt oder config message empfangen wird (kein trigger!) die nicht von FHEM gesendet wurde.
gesendet wurde zuletzt 11123ABC1D481F800A01 (so im FHEM speicher). gesehen wurde 11123ABC1D481F800F01.
Es wurde zuletzt an Kanal 10 gesendet, empfangen wurde, dass kanal 15 gesetzt wurde.
Entweder sendet eine andere Quelle mit der gleichen ID... oder es gibt ein Scenario, in dem dies passieren kann, das ich nicht kenne.
kannst du einmal rohmessags loggen und sagen, ob du ein kommando auslöst?
Hallo Martin, da ich mittels vccu 3 IO devices definiert habe, wird das loggen der Rohmessages bestimmt ziemlich unübersichtlich werden.
Die Meldung tritt mehr oder weniger spontan auf, ich poste mal aus dem Log um zu sehen welche Events vorher stattfanden.
2014.09.04 19:30:58 1: 192.168.2.222:1000 disconnected, waiting to reappear (HMLAN1)
2014.09.04 19:30:58 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.09.04 19:30:59 1: 192.168.2.222:1000 reappeared (HMLAN1)
2014.09.04 19:30:59 1: HMLAN_Parse: HMLAN1 new condition init
2014.09.04 19:31:00 3: CUL_HM set Stehlampe on
2014.09.04 19:31:00 1: HMLAN_Parse: HMLAN1 new condition ok
2014.09.04 19:31:00 3: CUL_HM set Kueche_Unterschrank on
2014.09.04 19:31:00 3: CUL_HM set 16_LED_4 led green
2014.09.04 19:35:00 3: WS3600(Msg): myWS1080 Read started
2014.09.04 19:40:00 3: WS3600(Msg): myWS1080 Read started
2014.09.04 19:41:43 3: CUL_HM set 16_LED_6 led green
2014.09.04 19:41:49 3: get Kalender_Frank summary 1jrd41sculejucuhbn2v2snom4googlecom : Gelbersack_morgen
2014.09.04 19:45:00 3: WS3600(Msg): myWS1080 Read started
2014.09.04 19:48:53 2: ENIGMA2 set Dreambox volume 10
2014.09.04 19:49:07 3: CUL_HM set Flurlicht on
2014.09.04 19:49:07 3: CUL_HM set 16_LED_7 led green
2014.09.04 19:49:45 3: CUL_HM set 16_LED ilum 0 0
2014.09.04 19:49:45 2: CUL_HM 16_LED attack:01123ABC1D481F00080400:01123ABC1D481F00050000000000.
2014.09.04 19:49:49 3: CUL_HM set 16_LED getConfig
2014.09.04 19:50:00 3: WS3600(Msg): myWS1080 Read started
2014.09.04 19:51:01 2: ENIGMA2 set Dreambox volume 75
2014.09.04 19:52:40 0: Server shutdown
2014.09.04 19:54:01 1: Including fhem.cfg
2014.09.04 19:54:01 3: Connecting to database SQLite:dbname=/opt/fhem/fhem.db with user
2014.09.04 19:54:02 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established for pid 2076
2014.09.04 19:54:02 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established
2014.09.04 19:54:02 3: telnetPort: port 7072 opened
2014.09.04 19:54:03 3: WEB: port 8083 opened
2014.09.04 19:54:03 3: WEBphone: port 8084 opened
2014.09.04 19:54:03 3: WEBtablet: port 8085 opened
2014.09.04 19:54:03 3: WEBtablet2: port 8086 opened
2014.09.04 19:54:03 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.09.04 19:54:03 3: Opening HMLAN1 device 192.168.2.222:1000
2014.09.04 19:54:03 3: HMLAN1 device opened
2014.09.04 19:54:03 1: HMLAN_Parse: HMLAN1 new condition init
2014.09.04 19:54:03 1: HMLAN_Parse: HMLAN2 new condition disconnected
2014.09.04 19:54:03 3: Opening HMLAN2 device 192.168.2.223:1000
2014.09.04 19:54:03 3: HMLAN2 device opened
2014.09.04 19:54:03 1: HMLAN_Parse: HMLAN2 new condition init
2014.09.04 19:54:03 1: HMLAN_Parse: hmusb new condition disconnected
2014.09.04 19:54:03 3: Opening hmusb device 127.0.0.1:1234
2014.09.04 19:54:03 3: hmusb device opened
2014.09.04 19:54:03 1: HMLAN_Parse: hmusb new condition init
2014.09.04 19:54:06 2: VIERA: defined with host: 192.168.2.20 and interval: 30
2014.09.04 19:54:09 3: Opening FB7390 device 192.168.2.1:1012
2014.09.04 19:54:09 3: FB7390 device opened
2014.09.04 19:54:11 3: FHEM2FHEM opening ds1 at 192.168.2.30:7072
2014.09.04 19:54:11 3: FHEM2FHEM device opened (ds1)
2014.09.04 19:54:12 2: Heizungen_Sommer: no reading yet for Temperatur_Garten temperature
2014.09.04 19:55:08 3: WS3600(Msg): myWS1080 initialized, setting callback timer to 20:00:00(+ 300 s)
2014.09.04 19:55:11 1: Including ./log/fhem.save
2014.09.04 19:55:12 2: SecurityCheck: WEBtablet,WEBtablet2 has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2014.09.04 19:55:12 0: Server started with 490 defined entities (version $Id: fhem.pl 6498 2014-09-01 19:24:40Z rudolfkoenig $, os linux, user fhem, pid 2076)
2014.09.04 19:55:12 3: CUL_HM set 16_LED_5 led green
2014.09.04 19:55:14 3: CUL_HM set Kueche_Heizung_ClimRT_tr controlManu off
2014.09.04 19:55:14 3: CUL_HM set Flur_Heizung_Clima controlManu off
2014.09.04 19:55:14 3: CUL_HM set Bad_Heizung_ClimRT_tr controlManu off
2014.09.04 19:55:14 3: CUL_HM set Kinderzimmer_Heizung_links_ClimRT_tr controlManu off
2014.09.04 19:55:14 3: CUL_HM set Kinderzimmer_Heizung_rechts_ClimRT_tr controlManu off
2014.09.04 19:55:14 3: CUL_HM set SZ_Heizung_links_ClimRT_tr controlManu off
2014.09.04 19:55:14 3: CUL_HM set SZ_Heizung_rechts_ClimRT_tr controlManu off
2014.09.04 19:55:15 3: CUL_HM set 16_LED_6 led green
2014.09.04 19:55:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.09.04 19:55:15 3: CUL_HM set Herdlicht off
2014.09.04 19:55:15 1: HMLAN_Parse: HMLAN2 new condition ok
2014.09.04 19:55:15 1: HMLAN_Parse: hmusb new condition ok
2014.09.04 19:55:16 3: CUL_HM set 16_LED_2 led red
2014.09.04 19:55:16 3: Device BM_WZ added to ActionDetector with 000:20 time
2014.09.04 19:55:16 3: Device Bad_Heizung added to ActionDetector with 000:10 time
2014.09.04 19:55:16 3: Device Diff_Sensor_WZ added to ActionDetector with 012:00 time
2014.09.04 19:55:16 3: Device Diff_Temp_Sensor added to ActionDetector with 000:10 time
2014.09.04 19:55:16 3: Device Fenster_Bad added to ActionDetector with 048:00 time
2014.09.04 19:55:16 3: Device Fenster_KiZi_links added to ActionDetector with 048:00 time
2014.09.04 19:55:16 3: Device Fenster_Kueche added to ActionDetector with 048:00 time
2014.09.04 19:55:16 3: Device Flur_Heizung added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device Heizung_WZ_links added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device Heizung_WZ_rechts added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device IR_Sensor added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device Kinderzimmer_Heizung_links added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device Kinderzimmer_Heizung_rechts added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device Klima_Switch added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device Kueche_Heizung added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device Leistungsmesser_Tablet added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device SZ_Heizung_links added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device SZ_Heizung_rechts added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device Schalter_Tuer added to ActionDetector with 028:00 time
2014.09.04 19:55:17 3: Device Schalter_Tuer_WZ added to ActionDetector with 048:00 time
2014.09.04 19:55:17 3: Device Schalter_Wohnungstuer added to ActionDetector with 028:00 time
2014.09.04 19:55:17 3: Device THSensor added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device TH_Sensor_Bad added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device TH_Sensor_HZ added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device TH_Sensor_KinderZi added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device TH_Sensor_WZ added to ActionDetector with 000:10 time
2014.09.04 19:55:17 3: Device Temperatur_Garten added to ActionDetector with 000:10 time
2014.09.04 19:55:19 3: CUL_HM set 16_LED statusRequest
2014.09.04 19:55:20 3: CUL_HM set 4_Kanal_Platine_Kanal_1 statusRequest
2014.09.04 19:55:21 3: CUL_HM set Aquarium statusRequest
2014.09.04 19:55:21 3: CUL_HM set 16_LED_8 led red
2014.09.04 19:55:22 3: CUL_HM set Badlicht statusRequest
2014.09.04 19:55:23 3: CUL_HM set Flurlicht statusRequest
2014.09.04 19:55:24 3: CUL_HM set Herdlicht statusRequest
2014.09.04 19:55:25 3: CUL_HM set Klima_Schalter statusRequest
2014.09.04 19:55:26 3: CUL_HM set Kueche_Unterschrank statusRequest
2014.09.04 19:55:27 3: CUL_HM set Ladegeraet statusRequest
2014.09.04 19:55:27 3: CUL_HM set 16_LED_12 led red
2014.09.04 19:55:28 3: CUL_HM set Ladegeraet_Tablet statusRequest
2014.09.04 19:55:29 3: CUL_HM set Licht_Wohnungstuer statusRequest
2014.09.04 19:55:30 3: CUL_HM set Radio statusRequest
2014.09.04 19:55:31 3: CUL_HM set Licht_SZ statusRequest
2014.09.04 19:55:31 3: CUL_HM set 16_LED_9 led red
2014.09.04 19:55:32 3: CUL_HM set Stehlampe statusRequest
2014.09.04 19:55:32 3: CUL_HM set Kueche_Unterschrank on
2014.09.04 19:55:32 3: CUL_HM set 16_LED_4 led green
2014.09.04 19:55:33 3: CUL_HM set UV_Lampe statusRequest
2014.09.04 19:55:34 3: CUL_HM set Verstaerker statusRequest
2014.09.04 19:55:34 3: CUL_HM set 16_LED_15 led green
2014.09.04 19:56:41 1: 192.168.2.30:7072 disconnected, waiting to reappear
2014.09.04 19:56:46 1: FHEM2FHEM 192.168.2.30:7072 reappeared (ds1)
2014.09.04 20:00:00 3: WS3600(Msg): myWS1080 Read started
2014.09.04 20:05:00 3: WS3600(Msg): myWS1080 Read started
2014.09.04 20:10:00 3: WS3600(Msg): myWS1080 Read started
2014.09.04 20:12:22 3: CUL_HM set Herdlicht on
2014.09.04 20:12:22 3: CUL_HM set 16_LED_2 led green
2014.09.04 20:12:33 3: CUL_HM set Herdlicht off
2014.09.04 20:12:33 3: CUL_HM set 16_LED_2 led red
2014.09.04 20:15:00 3: WS3600(Msg): myWS1080 Read started
2014.09.04 20:20:00 3: WS3600(Msg): myWS1080 Read started
2014.09.04 20:20:59 3: CUL_HM set 16_LED_11 led red
2014.09.04 20:20:59 3: CUL_HM set 16_LED_11 led green
2014.09.04 20:20:59 3: CUL_HM set 16_LED_11 led red
2014.09.04 20:21:00 3: CUL_HM set 16_LED_11 led green
2014.09.04 20:21:00 3: CUL_HM set 16_LED_11 led red
2014.09.04 20:21:00 3: CUL_HM set 16_LED_11 led green
2014.09.04 20:21:00 2: CUL_HM 16_LED attack:11123ABC1D481F800B02:11123ABC1D481F800B01.
2014.09.04 20:21:03 3: CUL_HM set 16_LED_13 led red
2014.09.04 20:21:03 3: CUL_HM set Licht_Wohnungstuer on-for-timer 60
2014.09.04 20:21:03 2: CUL_HM 16_LED attack:11123ABC1D481F800B02:11123ABC1D481F800B01.
2014.09.04 20:21:07 3: CUL_HM set 16_LED_13 led green
Wenn du die Rohmessages brauchst, dann logge ich nochmals mit, wenn ja, dann von allen 3 IO Devices?
Ich hatte heute Mittag mal Rohmessages vom hmusb geloggt, ob da etwas brauchbares dabei ist kann ich aber nicht sagen (die attack Meldung ist dabei)
2014.09.04 13:36:18 0: HMLAN_Parse: hmusb V:03C7 sNo:JEQ0700806 d:1EBDD2 O:123ABC t:00019DEA IDcnt:0002
2014.09.04 13:36:18 0: HMLAN_Parse: hmusb R:E2A4F5D stat:0000 t:00019EFE d:FF r:FFD2 m:11 845E 2A4F5D 000000 80726F000000000008D5FC
2014.09.04 13:36:18 0: HMLAN_Parse: hmusb R:R40734AC9 stat:0002 t:00000000 d:FF r:7FFF m:CC 8002 123ABC 249978 01013700
2014.09.04 13:36:18 0: HMLAN_Parse: hmusb R:E206AA2 stat:0000 t:0001AAEB d:FF r:FFCC m:72 8670 206AA2 000000 00E639
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb R:E20BD8B stat:0000 t:0001AB52 d:FF r:FFC4 m:2A 8653 20BD8B 000000 004100E64200E943FFFD440003
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb R:R407358EF stat:0002 t:00000000 d:FF r:7FFF m:CC 8002 123ABC 249978 01013700
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb R:E1A4F71 stat:0000 t:0001B21A d:FF r:FFC9 m:E1 8410 1A4F71 123ABC 06015A00
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb R:E2225D5 stat:0000 t:0001B87C d:FF r:FFCB m:3C 8610 2225D5 000000 0A24E60C0069
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb R:R407368AF stat:0001 t:0001BF46 d:FF r:FFD9 m:01 8002 1D481F 123ABC 0105020024A6659A65
2014.09.04 13:36:19 0: HMLAN_Send: hmusb S:+1D481F,00,01,00
2014.09.04 13:36:19 0: HMLAN_Send: hmusb S:S40736DAB stat: 00 t:00000000 d:01 r:40736DAB m:04 A001 123ABC 1D481F 010E
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb R:R407368C0 stat:0008 t:00000000 d:FF r:7FFF m:02 A112 123ABC 2221D0
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb no ACK from 2221D0
2014.09.04 13:36:19 1: 192.168.2.222:1000 disconnected, waiting to reappear (HMLAN1)
2014.09.04 13:36:19 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb R:R40736B61 stat:0008 t:00000000 d:FF r:7FFF m:03 A112 123ABC 22389B
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb no ACK from 22389B
2014.09.04 13:36:19 1: 192.168.2.222:1000 reappeared (HMLAN1)
2014.09.04 13:36:19 1: HMLAN_Parse: HMLAN1 new condition init
2014.09.04 13:36:19 2: CUL_HM 16_LED attack:01123ABC1D481F010E:11123ABC1D481F800502.
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb R:E123ABC stat:0000 t:0001C440 d:FF r:FFCF m:99 8112 123ABC 000000
2014.09.04 13:36:19 1: HMLAN_Parse: HMLAN1 new condition ok
2014.09.04 13:36:19 0: HMLAN_Delay: hmusb 1D481F
2014.09.04 13:36:19 3: CUL_HM set 4_Kanal_Platine_Kanal_2 statusRequest
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb R:E1D481F stat:0000 t:0001C481 d:FF r:FFD9 m:04 A010 1D481F 123ABC 0601010024A6659A65
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb R:R40736DAB stat:0001 t:0001C486 d:FF r:FFD9 m:04 A010 1D481F 123ABC 0601010024A6659A65
2014.09.04 13:36:19 0: HMLAN_SdDly: hmusb 1D481F
2014.09.04 13:36:19 0: HMLAN_Send: hmusb S:+1D481F,00,01,00
2014.09.04 13:36:19 0: HMLAN_Send: hmusb S:S40736F21 stat: 00 t:00000000 d:01 r:40736F21 m:05 A001 123ABC 1D481F 020E
2014.09.04 13:36:19 0: HMLAN_Parse: hmusb R:E123ABC stat:0000 t:0001C53F d:FF r:FFD0 m:08 A112 123ABC 223338
2014.09.04 13:36:20 0: HMLAN_Parse: hmusb R:E123ABC stat:0000 t:0001C61B d:FF r:FFD0 m:09 A112 123ABC 222575
2014.09.04 13:36:20 0: HMLAN_Delay: hmusb 1D481F
2014.09.04 13:36:20 0: HMLAN_Parse: hmusb R:E1D481F stat:0000 t:0001C68C d:FF r:FFD9 m:05 A010 1D481F 123ABC 0602010022A6659A65
2014.09.04 13:36:20 0: HMLAN_Parse: hmusb R:E123ABC stat:0000 t:0001C6CE d:FF r:FFCF m:08 A112 123ABC 223338
2014.09.04 13:36:20 0: HMLAN_Parse: hmusb R:R40736F21 stat:0001 t:0001C691 d:FF r:FFD9 m:05 A010 1D481F 123ABC 0602010022A6659A65
2014.09.04 13:36:20 0: HMLAN_SdDly: hmusb 1D481F
2014.09.04 13:36:20 0: HMLAN_Send: hmusb S:+1D481F,00,01,00
2014.09.04 13:36:20 0: HMLAN_Send: hmusb S:S40737101 stat: 00 t:00000000 d:01 r:40737101 m:06 A001 123ABC 1D481F 030E
2014.09.04 13:36:20 0: HMLAN_Parse: hmusb R:E123ABC stat:0000 t:0001C721 d:FF r:FFCF m:0A A112 123ABC 2225D5
2014.09.04 13:36:20 0: HMLAN_Parse: hmusb R:E123ABC stat:0000 t:0001C7AA d:FF r:FFCF m:09 A112 123ABC 222575
2014.09.04 13:36:20 0: HMLAN_Parse: hmusb R:E123ABC stat:0000 t:0001C7E9 d:FF r:FFCE m:0A A112 123ABC 2225D5
2014.09.04 13:36:20 0: HMLAN_Delay: hmusb 1D481F
2014.09.04 13:36:20 3: CUL_HM set 4_Kanal_Platine_Kanal_3 statusRequest
VG
Frank
Hallo Martin, ich denke, dass ich die Meldung wahrscheinlich selber provoziert habe. In der IOList von vccu waren keine Trennzeichen gesetzt. Also nicht hmusb,HMLAN1,HMLAN2 sondern hmusb HMLAN1 HMLAN2. Dadurch, dass die IOList nicht OK war, hat vccu wahrscheinlich die 2 anderen IO Devices nicht gekannt und mit attack geantwortet.
Sehe morgen früh nochmal im Log nach, ob es jetzt noch auftritt.
P.S. Dazu kommt das Problem der dauernd auftretenden kurzen disconnects
VG
Frank
Habe den hmusb jetzt aus der vccu genommen und als IO Devices nur noch HMLAN1 und HMLAN2 und das System läuft wesentlich stabiler.
VG
Frank
Zitatdas System läuft wesentlich stabiler.
das kann eventuell auch mit der korrektur des IOList zu tun haben.
gruss frank
Ich beobachte das ganze, hat mir bis eben ein Haufen unknown devices eingebracht, die gerne hmusb als IO device hätten.
VG
Frank
Die Meldung taucht immer noch auf, meist nach einem shutdown restart, logge jetzt mal die Rohmessages und führe einen Neustart durch.
VG
Frank
Hier die Rohmessages von HMLAN1 und HMLAN2
Wenn ich in Code Tags speichern will bekomme ich von der Forensoft einen Datenbankfehler!
Hat jemand schon was rausfinden können? Zeitweise reagiert fhem mit einiger Verspätung weil die IO devices im disconnect sind. Woran das liegt, habe ich bis jetzt nicht eingrenzen können. Habe apptime laufen und poste morgen mal das Ergebnis.
VG
Frank
hier das Ergebnis von apptime:
name function max count total average maxDly
tmr-WS3600_Read HASH(0x260aa50) 59336 120 7086973 59058.11 1863 HASH(myWS1080)
HMLAN1 HMLAN_Ready 3005 245 6661 27.19 0 HASH(HMLAN1)
tmr-Calendar_Wakeup HASH(0x26ba610) 2374 11 19656 1786.91 6 HASH(Kalender_Frank)
tmr-VIERA_GetStatus HASH(0x21a8a88) 2057 1034 1474746 1426.25 59579 HASH(TV)
HMLAN1 HMLAN_Read 848 10511 605205 57.58 0 HASH(HMLAN1)
FHEMWEB:192.168.2.61:54875 FW_Read 717 1 717 717.00 0 HASH(FHEMWEB:192.168.2.61:54875)
FHEMWEB:192.168.2.61:54874 FW_Read 699 2 789 394.50 0 HASH(FHEMWEB:192.168.2.61:54874)
Heizungen_Sommer THRESHOLD_Notify 558 34150 1313 0.04 0 HASH(Heizungen_Sommer); HASH(Temperatur_Garten)
HMLAN2 HMLAN_Read 516 10401 28756 2.76 0 HASH(HMLAN2)
myWS1080_notify17 notify_Exec 330 120 16774 139.78 0 HASH(myWS1080_notify17); HASH(myWS1080)
tmr-Calendar_Wakeup HASH(0x25e4918) 292 2 557 278.50 1644 HASH(Ferien)
Heizungswerte2 readingsGroup_Notify 271 34150 182070 5.33 0 HASH(Heizungswerte2); HASH(Kinderzimmer_Heizung_rechts_ClimRT_tr)
myWS1080_notify11 notify_Exec 266 120 11459 95.49 0 HASH(myWS1080_notify11); HASH(myWS1080)
myWS1080_notify14 notify_Exec 265 120 13676 113.97 0 HASH(myWS1080_notify14); HASH(myWS1080)
myWS1080_notify8 notify_Exec 262 120 10515 87.62 0 HASH(myWS1080_notify8); HASH(myWS1080)
myWS1080_notify2 notify_Exec 260 120 13516 112.63 0 HASH(myWS1080_notify2); HASH(myWS1080)
myWS1080_notify5 notify_Exec 259 120 10216 85.13 0 HASH(myWS1080_notify5); HASH(myWS1080)
myWS1080_notify4 notify_Exec 258 120 10876 90.63 0 HASH(myWS1080_notify4); HASH(myWS1080)
myWS1080_notify6 notify_Exec 253 120 10044 83.70 0 HASH(myWS1080_notify6); HASH(myWS1080)
ds1 FHEM2FHEM_Read 217 893 54038 60.51 0 HASH(ds1)
myWS1080_notify12 notify_Exec 216 120 9881 82.34 0 HASH(myWS1080_notify12); HASH(myWS1080)
VG
Frank
Hallo Frank,
der log der rohmessages war interessant.
FHEM kennt die letzte message, es kommt aber eine andere. Könnte sein, dass diese von einem anderen IO stammt und nicht im Log ist. Ferner ist hier gerade ein IO-disconnect zu sehen. Es könnte also auch sein, dass ein IO die messages wegen ethernetproblemen nicht losbekommen hat und nach dem reconnect die uralten messages nun sendet.
Um das sehen zu können wärenrohmessages gemischt HMUSB und HMLAN1 notwendig. Dauer min 1min, da der disconnect schon 30sec alt sein kann (max)
Gruss Martin
Hallo Martin, den hmusb hab ich aus dem System verbannt. Als IO Devices gibt es nun nur noch HMLAN1 und HMLAN2. Habe das Netzwerk schon länger in Verdacht, Probleme zu machen (häufig kurze disconnects). Logge gleich nochmal Rohdaten.
VG
Frank
hallo frank,
dein "myWS1080" legt fhem bei jedem aufruf ca 59 sekunden lahm. 120 mal ist das geschehen. siehe apptime 1. zeile. das disconnectet deine hmlan regelmässig.
gruss frank
Dann kann es nur an:
Fowsr liegen, dass läuft direkt auf dem Host und liefert die aufbereiteten Daten für das WS3600 Modul
Ich möchte das aber ungerne aus der conf. nehmen, da ich mit der Wetterstation Luftdruck,Wind,Windrichtung,Regen usw. logge. Ich setze das Intervall für WS3600 mal hoch.
VG
Frank
Hier die Rohmessages, ich hoffe es ist was dabei.
ZitatIch setze das Intervall für WS3600 mal hoch.
ein hmlan möchte aber regelmässig mindestens alle 30s gestreichelt werden. also bei jedem aufruf disconnect. entweder der modulautor kann/möchte das ändern, oder auf eine andere fheminstanz auslagern. eventuell ist ein hmusb nicht betroffen, wegen usb.
Auf dem Host läuft fowsr und das WS3600 Modul (von betateilchen) fragt mit "/usr/bin/fowsr -c" 600, jetzt alle 10 min die Daten von der Wetterstation ab. Da hat nichts mit dem IO Devices von fhem zu tun, da die Wetterstation über usb am Host hängt. Könnte mir nur vorstellen das der Host dann blockiert ist.
Habe jetzt mal top auf dem Host laufen, vielleicht sieht man ja was.
top - 10:28:24 up 15:00, 1 user, load average: 0,03, 0,06, 0,11
Tasks: 93 total, 1 running, 92 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,7 us, 0,5 sy, 0,0 ni, 98,7 id, 0,0 wa, 0,0 hi, 0,2 si, 0,0 st
KiB Mem: 1887912 total, 514860 used, 1373052 free, 117724 buffers
KiB Swap: 0 total, 0 used, 0 free, 230372 cached
Da ist nichts verdächtiges?!
VG
Frank
So, ich bin jetzt mit fowsr und dem WS3600 Modul auf einen Raspi umgezogen und beobachte das Ganze. Bis jetzt haben scheinbar keine disconnects auf der fhem Hauptinstanz mehr stattgefunden. Lasse das Ganze jetzt erst mal laufen und gebe heue Nachmittag Rückmeldung.
VG
Frank
Es lag eindeutig an fowsr, welches den Host ausbremste und fhem somit auch ausbremste. fhem reagierte daraufhin mit disconnects.
Jetzt läuft das System völlig stabil und die CUL_HM 16_LED attack ist mit der Korrektur der IOList von vccu auch beseitigt!
VG
Frank
habe leider auch sowas in meiner Log-Datei entdeckt. :(
2014.11.26 17:09:55 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_12 led orange
2014.11.26 17:09:55 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_11 led orange
2014.11.26 17:09:56 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_16 led orange
2014.11.26 17:09:57 2: CUL_HM StatusMonitor attack:118F55B31EB6B6801003:118F55B31EB6B6800C03.
2014.11.26 17:09:57 2: CUL_HM StatusMonitor attack:118F55B31EB6B6801003:118F55B31EB6B6800B03.
2014.11.26 17:09:57 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_10 led orange
2014.11.26 17:10:17 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_16 led green
2014.11.26 17:10:19 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_15 led green
2014.11.26 17:10:19 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_09 led green
...
...
...
2014.11.26 17:10:22 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_10 led green
2014.11.26 17:10:23 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_10 led green
2014.11.26 17:10:23 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_10 led green
2014.11.26 17:10:24 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_10 led green
2014.11.26 17:10:24 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_10 led green
2014.11.26 17:10:25 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_10 led green
2014.11.26 17:10:28 2: CUL_HM StatusMonitor attack:118F55B31EB6B6800B02:118F55B31EB6B6800902.
2014.11.26 17:10:31 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_13 led green
2014.11.26 17:10:51 3: CUL_HM set CUL_HM_HM_OU_LED16_1EB6B6_Led_12 led green
In meiner VCCU habe ich aber in der IOList die beiden IOs (CUL,hmusb) mit Komma getrennt. Ich kann noch keine Fehlfunktion feststellen, aber der Eintrag im Log müßte nicht sein. Werde das weiter verfolgen.
Was ich mich unabhängig davon frage ist, ob ich die Einträge (Kanäle) der LED sprechender benennen sollte. Aber das gehört vermutlich in ein anderes Thread.
Ich hole den Thread mal nach oben.
Bei mir kann ich das gleiche Problem feststellen. Szenario ist: vccu mit mehreren IOs (siehe Signatur), OU_LED16 korrekt mit vccu gepaired und kein exklusives IO zugewiesen.
Bei mir tauchen die Attack-Meldungen wenn, dann nur dann auf, wenn in engem zeitlichen Zusammenhang weitere Sensoren und/oder Aktoren Messages senden. Bspw. wird ein Fenster geöffnet, MK sendet an fhem, fhem reagiert über DOIF und setzt eine LED der OU. usw.
Kann ich da noch irgendwo was drehen?
Edit, Beispiel:
2015.05.19 12:36:58 3: led1_status(7) # eine Perl-Funktion zum Auslesen von States und Setzen der betreffenden LED
2015.05.19 12:36:58 3: CUL_HM set GEN_LED1_07 led green
2015.05.19 12:36:58 3: [Alarm 2] canceled from device GEN_Verschluss_L2 # hier wurde das Fenster 7 geschlossen
2015.05.19 12:37:00 3: led1_status(4) # s.o.
2015.05.19 12:37:00 3: CUL_HM set GEN_LED1_04 led red
2015.05.19 12:37:00 3: [Alarm 2] raised from device ASR_Fenster with event open # Fenster 4 geöffnet
2015.05.19 12:37:02 2: CUL_HM GEN_LED1 attack:11123456FFF93B800401:11123456FFF93B800702.
2015.05.19 12:37:02 2: CUL_HM GEN_LED1 attack:11123456FFF93B800401:11123456FFF93B800702.
2015.05.19 12:37:03 2: CUL_HM GEN_LED1 attack:11123456FFF93B800401:11123456FFF93B800702.
...
2015.05.19 12:45:00 3: led1_status(15) # s.o.
2015.05.19 12:45:00 3: CUL_HM set GEN_LED1_15 led red # Fenster 15 geöffnet. Hier keine Attacks.
da kommt die 2. Message, danach wird die erste vom anderen IO empfangen.
kannst du es einmal loggen - roh von allen IOs?
Ich werde es versuchen :) .
Edit: Blöde Frage, mit verbose 5 auf jedes IO? Oder reicht verbose 5 auf die vCCU?
siehe wiki => homematic sniffen.
Danke, Frank. Ich war blind bei der Suche.
Hallo Martin,
ich habe Dir eine PN mit dem Log-Auszug geschickt.