[gelöst] Im Log CUL_HM 16_LED attack, Warum?

[martinp876]

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

[franky08]

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

[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

[franky08]

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

[franky08]

Hier die Rohmessages, ich hoffe es ist was dabei.

[frank]

Ich 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.

[franky08]

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.

Code Auswählen Erweitern

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

[franky08]

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

[franky08]

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

[Alcamar]

habe leider auch sowas in meiner Log-Datei entdeckt.

Code Auswählen Erweitern

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.

[Ralli]

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:

Code Auswählen Erweitern


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.


[martinp876]

da kommt die 2. Message, danach wird die erste vom anderen IO empfangen.
kannst du es einmal loggen - roh von allen IOs?

[Ralli]

Ich werde es versuchen .

Edit: Blöde Frage, mit verbose 5 auf jedes IO? Oder reicht verbose 5 auf die vCCU?

[frank]

siehe wiki => homematic sniffen.

[Ralli]

Danke, Frank. Ich war blind bei der Suche.