Immer wieder new condition timeout

Begonnen von Damian, 15 Dezember 2013, 14:15:02

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten1
Benutzer-Aktionen

Damian

15 Dezember 2013, 14:15:02 Letzte Bearbeitung: 15 Dezember 2013, 14:22:21 von Damian
Hallo Martin,

ich bekomme immer wieder new condition timeout, obwohl kaum über HM_LAN gesendet wird lt. log:

Code Auswählen
2013.12.14 09:53:43.852 1: HMLAN_Parse: HMLAN new condition timeout
2013.12.14 09:53:43.872 1: 192.168.178.32:1000 disconnected, waiting to reappear
2013.12.14 09:53:43.879 1: HMLAN_Parse: HMLAN new condition disconnected
2013.12.14 09:54:17.749 3: FS20 set Zirkulation on
2013.12.14 09:54:47.031 1: 192.168.178.32:1000 reappeared (HMLAN)
2013.12.14 09:54:47.033 1: HMLAN_Parse: HMLAN new condition init
2013.12.14 09:54:47.075 1: HMLAN_Parse: HMLAN new condition ok
2013.12.14 09:59:17.750 3: FS20 set Zirkulation off
2013.12.14 10:01:38.770 3: Watchdog w_Heizung_aus triggered
2013.12.14 10:01:38.771 3: FS20 set Therme_230V off
2013.12.14 11:14:02.325 3: FS20 set Therme_230V on
2013.12.14 11:26:27.331 3: FS20 set Alarm_aus on
2013.12.14 11:28:46.822 3: Watchdog w_Heizung_aus triggered
2013.12.14 11:28:46.823 3: FS20 set Therme_230V off
2013.12.14 11:31:29.249 2: CUL_HM set Tuer statusRequest
2013.12.14 11:31:32.316 2: CUL_HM set Tuer statusRequest
2013.12.14 11:36:11.494 2: CUL_HM set Tuer statusRequest
2013.12.14 11:36:14.494 2: CUL_HM set Tuer statusRequest
2013.12.14 11:44:30.978 2: CUL_HM set R_Kinderzimmer2_W1 statusRequest
2013.12.14 11:44:31.985 2: CUL_HM set R_Kinderzimmer2_W2 statusRequest
2013.12.14 12:00:00.548 2: set TH_R_Dachgeschoss desired 23.0
2013.12.14 12:30:00.473 2: set TH_R_Wohnzimmer_S desired 23.0
2013.12.14 12:34:41.732 2: CUL_HM set Tuer statusRequest
2013.12.14 12:34:44.730 2: CUL_HM set Tuer statusRequest
2013.12.14 13:00:00.329 2: set TH_DG desired 19.5
2013.12.14 13:00:00.373 3: FS20 set Therme on
2013.12.14 13:00:00.401 3: FS20 set Therme_230V on
2013.12.14 13:00:00.461 2: set TH_Kz_w desired 19.5
2013.12.14 13:00:00.496 2: set TH_Kueche desired 19.5
2013.12.14 13:00:00.528 2: set TH_Wz desired 20.0
2013.12.14 13:00:00.562 2: set TH_R_Kueche desired 30.0
2013.12.14 13:00:00.592 2: set TH_R_Kinderzimmer1_S desired 23.0
2013.12.14 13:00:00.628 2: set TH_R_Kinderzimmer2_S desired 23.0
2013.12.14 13:00:00.793 2: set TH_Keller desired 20.0
2013.12.14 13:03:56.883 2: CUL_HM set H_Wohnzimmer on
2013.12.14 13:04:09.219 2: CUL_HM set H_Dachgeschoss off
2013.12.14 13:04:14.796 2: CUL_HM set H_Kinderzimmer_w off
2013.12.14 13:04:16.361 2: CUL_HM set H_Kueche off
2013.12.14 13:04:23.039 2: CUL_HM set H_Keller off
2013.12.14 13:08:56.875 2: CUL_HM set H_Wohnzimmer off
2013.12.14 13:22:42.745 3: Watchdog w_Heizung_aus triggered
2013.12.14 13:22:42.746 3: FS20 set Therme_230V off
2013.12.14 14:00:00.558 2: set TH_R_Kinderzimmer1_O desired 30.0
2013.12.14 14:06:04.600 2: CUL_HM set Tuer statusRequest
2013.12.14 14:06:08.349 2: CUL_HM set Tuer statusRequest
2013.12.14 14:14:05.468 3: FS20 set Therme_230V on
2013.12.14 14:38:43.022 3: Watchdog w_Heizung_aus triggered
2013.12.14 14:38:43.023 3: FS20 set Therme_230V off
2013.12.14 15:00:08.035 2: CUL_HM set Tuer statusRequest
2013.12.14 15:00:11.110 2: CUL_HM set Tuer statusRequest
2013.12.14 15:09:17.946 3: FS20 set Zirkulation on
2013.12.14 15:14:17.964 3: FS20 set Zirkulation off
2013.12.14 15:50:00.490 2: set TH_R_Wohnzimmer_W1 desired 23.0
2013.12.14 15:50:00.532 2: set TH_R_Wohnzimmer_W2 desired 23.0
2013.12.14 15:50:00.565 2: set TH_R_Wohnzimmer_W3 desired 23.0
2013.12.14 15:50:00.607 2: set TH_R_Kinderzimmer2_W1 desired 23.0
2013.12.14 15:50:00.656 2: set TH_R_Kinderzimmer2_W2 desired 23.0
2013.12.14 16:20:11.094 2: CUL_HM set Tuer statusRequest
2013.12.14 16:20:14.093 2: CUL_HM set Tuer statusRequest
2013.12.14 16:29:05.528 3: FS20 set Therme_230V on
2013.12.14 16:29:05.599 2: CUL_HM set Tuer statusRequest
2013.12.14 16:29:07.488 2: CUL_HM set Tuer statusRequest
2013.12.14 16:52:24.387 3: FS20 set Lampekueche on
2013.12.14 16:52:24.402 3: FS20 set Lampeflur on
2013.12.14 16:52:24.415 3: FS20 set Schreibtisch on
2013.12.14 17:00:00.375 3: FS20 set Therme on
2013.12.14 17:00:00.399 3: FS20 set Therme_230V on
2013.12.14 17:00:00.802 2: set TH_Bad desired 19.5
2013.12.14 17:04:24.496 2: CUL_HM set H_Bad off
2013.12.14 17:04:27.850 2: CUL_HM set Wandleuchten_W on
2013.12.14 17:11:43.285 2: CUL_HM set Tuer statusRequest
2013.12.14 17:11:46.283 2: CUL_HM set Tuer statusRequest
2013.12.14 17:22:24.464 2: CUL_HM set R_W_S off
2013.12.14 17:22:24.484 2: CUL_HM set R_W_W1 off
2013.12.14 17:22:24.501 2: CUL_HM set R_W_W2 off
2013.12.14 17:22:24.517 2: CUL_HM set R_W_W3 off
2013.12.14 17:24:28.161 2: CUL_HM set R_W_S statusRequest
2013.12.14 17:24:29.166 2: CUL_HM set R_W_W1 statusRequest
2013.12.14 17:24:30.169 2: CUL_HM set R_W_W2 statusRequest
2013.12.14 17:24:31.173 2: CUL_HM set R_W_W3 statusRequest
2013.12.14 17:31:12.154 3: Watchdog w_Heizung_aus triggered
2013.12.14 17:31:12.155 3: FS20 set Therme_230V off
2013.12.14 18:15:53.672 1: HMLAN_Parse: HMLAN new condition timeout
2013.12.14 18:15:53.695 1: 192.168.178.32:1000 disconnected, waiting to reappear
2013.12.14 18:15:53.701 1: HMLAN_Parse: HMLAN new condition disconnected
2013.12.14 18:15:55.505 1: 192.168.178.32:1000 reappeared (HMLAN)
2013.12.14 18:15:55.506 1: HMLAN_Parse: HMLAN new condition init
2013.12.14 18:15:55.549 1: HMLAN_Parse: HMLAN new condition ok
2013.12.14 18:21:50.545 1: HMLAN_Parse: HMLAN new condition timeout
2013.12.14 18:21:50.565 1: 192.168.178.32:1000 disconnected, waiting to reappear
2013.12.14 18:21:50.570 1: HMLAN_Parse: HMLAN new condition disconnected
2013.12.14 18:22:53.069 1: 192.168.178.32:1000 reappeared (HMLAN)
2013.12.14 18:22:53.070 1: HMLAN_Parse: HMLAN new condition init
2013.12.14 18:22:53.114 1: HMLAN_Parse: HMLAN new condition ok


Hab´s mal mit Verbose 5 probiert, da sieht man vor lauter Bäume den Wald nicht mehr. Gibt´s eine einfache Möglichkeit dem Übeltäter auf die Schliche zu kommen?

Gruß

Damian

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

martinp876

#1
15 Dezember 2013, 15:07:14
Hallo Damian,

du musst global verbose auf 1 setzen und HMLAN verbose auf 5 - oder besser
attr global verbose 1
attr global mseclog 1
attr <hmlan> logIDs all,sys

ausserdem kannst du mit HMinfo ein paar Statistiken ansehen:
set hm protoEvents short
set hm msgStat

was ich aber sehe ist erst einmal kein overload sondern ein disconnect.

hierzu kannst du auch einmal im HMLAN die internal ansehen:

msgKeepAlive dlyMax:1540.232 bufferMin:-1535
msgLoadEst 1hour:30% 10min steps: 0/0/0/0/0/30
msgParseDly min:-12 max:1536730 last:8 cnt:3363


Gruss Martin

Damian

#2
15 Dezember 2013, 15:20:02
Hallo Martin,

danke für die schnelle Rückmeldung.

Dann weiß ich wo ich suchen muss  :).

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ban

#3
28 Dezember 2013, 13:06:59
Hallo Damian,

hast du eine Lösung gefunden?
Habe seit ca. einer Woche neben dem CUL auch einen HMLan und seit Beginn an geht die Verbindung zum HMLan ständig verloren.
Immer zwischen 2min und 60min. Habe gelesen, dass wegen Modulen die in den sleep gehen, der KeepAlive zu spät gesendet wird.
Habe für mich aber noch keine Lösung gefunden.

Grüße,
Michael
Homematic, Homematic IP, Sonos, Echos
fhem und Raspberrymatic auf VirtualBox (Asustor AS6704T)

Damian

#4
28 Dezember 2013, 13:27:33
Hallo Michael,

leider kommt die Meldung bei mir immer noch (ca. einmal am Tag).

Da mein FHEM-System recht performant ist (keine Fritzbox), gehe ich davon aus, dass irgendetwas bei mir mit dem Netzwerk nicht stimmt. Die Analyse ist da recht schwierig.

Wenn ich die Ursache finde, werde ich es hier posten.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ban

#5
28 Dezember 2013, 14:43:28 Letzte Bearbeitung: 28 Dezember 2013, 16:44:34 von MiWi
Hallo Damian,

danke für die Info!
Dann scheint es bei mir doch eine andere Ursache zu haben. In meinem Log steht fast nichts anderes mehr.

Falls du ein Netzwerkproblem vermutest würde ich testweise einen Dauerping absetzen und in ein Log schreiben. Falls du hier dann Aussetzer siehst weißt du schon mal das es nicht an fhem liegt.

Viele Grüße,
Michael
Homematic, Homematic IP, Sonos, Echos
fhem und Raspberrymatic auf VirtualBox (Asustor AS6704T)

Damian

#6
28 Dezember 2013, 14:45:06
Zitat von: MiWi am 28 Dezember 2013, 14:43:28
Falls du ein Netzwerkproblem vermutest würde ich testweise einen Dauerping absetzen und in ein Log schreiben. Falls du hier dann Aussetzer siehst weißt du schon mal das es nicht an fhem liegt.

Gute Idee.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

LuckyDay

#7
28 Dezember 2013, 15:00:04
ich würde erst mal schauen ob du irgendwelche Langweiler drin hast.

ich würde nach frezze Fhem schauen

http://forum.fhem.de/index.php/topic,17286.msg113066.html#msg113066
erste variante

2: apptime

Ban

#8
28 Dezember 2013, 17:32:12 Letzte Bearbeitung: 28 Dezember 2013, 19:46:22 von MiWi
Danke, das war für mich der perfekte Tip!
Nicht das fhem freeze, sondern der verlinkte Beitrag.
Ich habe auch einen Max Cube und bei der Info, dass fhem während dem Pollen ausgelastet ist,
ist mir direkt klar geworden, dass das wahrscheinlich auch mein Problem ist.
Nachgetestet und es ist so. Max Cube abgehängt und keine timeouts mehr beim HMLan.
Danke, noch keine Lösung, aber die Ursache gefunden!

@Damian: vielleicht läuft bei dir zum Zeitpunkt des timeouts auch irgendein Task welcher fhem auslastet und der keep alive Ping dann zu spät kommt.

Viele Grüsse,
Michael
Homematic, Homematic IP, Sonos, Echos
fhem und Raspberrymatic auf VirtualBox (Asustor AS6704T)
Drucken
Nach oben Seiten1
Benutzer-Aktionen