Hallo,
ich benutze FHEM seit einigen Wochen. Ich habe aktuell nur Homematic Komponenten, nämlich Heizkörper- und Wandthermostate sowie Fensterkontakte. FHEM läuft auf einem Raspberry Pi B, auf dem sonst nichts anderes läuft. Als IO-Gerät benutze ich den HMLAN Adapter.
Es kommt bei mir eigentlich schon seit Anfang an vor, dass sich das HMLAN ab und an disconnected und sofort wieder connected. Dies habe ich nun angefangen zu untersuchen. Dazu habe ich erstmal alles deaktiviert was ich nicht brauche, sowie das LogLevel auf 5 gestellt. Es kommt weiterhin ca. 5x am Tag zum Disconnect.
Hier habe ich einen Log-Auszug von einem der Disconnects von heute. Zu diesem Zeitpunkt war niemand im Haus, es hat also niemand auf FHEM zugegriffen.
2014.11.04 15:51:33 5: Notify loop for Schlafzimmer.Heizkoerperthermostat.Clima measured-temp: 21.3
2014.11.04 15:51:33 4: eventTypes: CUL_HM Schlafzimmer.Heizkoerperthermostat.Clima measured-temp: 21.3 -> measured-temp: .*
2014.11.04 15:51:33 4: eventTypes: CUL_HM Schlafzimmer.Heizkoerperthermostat.Clima ValvePosition: 0 -> ValvePosition: .*
2014.11.04 15:51:33 4: eventTypes: CUL_HM Schlafzimmer.Heizkoerperthermostat.Clima desired-temp: 17.0 -> desired-temp: .*
2014.11.04 15:51:33 5: DbLog: logging of Device: Schlafzimmer.Heizkoerperthermostat.Clima , Type: CUL_HM , Event: measured-temp: 21.3 , Reading: measured-temp , Value: 21.3 , Unit:
2014.11.04 15:51:33 5: DbLog: logging of Device: Schlafzimmer.Heizkoerperthermostat.Clima , Type: CUL_HM , Event: ValvePosition: 0 , Reading: ValvePosition , Value: 0 , Unit:
2014.11.04 15:51:33 5: DbLog: logging of Device: Schlafzimmer.Heizkoerperthermostat.Clima , Type: CUL_HM , Event: desired-temp: 17.0 , Reading: desired-temp , Value: 17.0 , Unit:
2014.11.04 15:51:47 5: HMLAN_Send: HMLAN1 I:K
2014.11.04 15:51:48 5: HMLAN_Send: HMLAN1 I:K
2014.11.04 15:51:49 5: HMLAN_Send: HMLAN1 I:K
2014.11.04 15:51:49 5: HMLAN/RAW: /E28B903,0000,45C19BBE,FF,FFCE,CB861028B9030000000A88D60F0000
2014.11.04 15:51:49 5: HMLAN_Parse: HMLAN1 R:E28B903 stat:0000 t:45C19BBE d:FF r:FFCE m:CB 8610 28B903 000000 0A88D60F0000
2014.11.04 15:51:49 5: HMLAN1 dispatch A0FCB861028B9030000000A88D60F0000::-50:HMLAN1
2014.11.04 15:51:50 5: HMLAN_Send: HMLAN1 I:K
2014.11.04 15:51:51 1: HMLAN_Parse: HMLAN1 new condition timeout
2014.11.04 15:51:51 5: Triggering HMLAN1 (3 changes)
2014.11.04 15:51:51 5: Notify loop for HMLAN1 cond: timeout
2014.11.04 15:51:51 4: eventTypes: HMLAN HMLAN1 cond: timeout -> cond: timeout
2014.11.04 15:51:51 4: eventTypes: HMLAN HMLAN1 Xmit-Events: timeout:6 ok:6 disconnected:6 init:6 -> Xmit-Events: timeout:.* ok:.* disconnected:.* init:.*
2014.11.04 15:51:51 4: eventTypes: HMLAN HMLAN1 prot_timeout: last -> prot_timeout: last
2014.11.04 15:51:51 5: DbLog: logging of Device: HMLAN1 , Type: HMLAN , Event: cond: timeout , Reading: cond , Value: timeout , Unit:
2014.11.04 15:51:51 5: DbLog: logging of Device: HMLAN1 , Type: HMLAN , Event: Xmit-Events: timeout:6 ok:6 disconnected:6 init:6 , Reading: Xmit-Events , Value: timeout:6 ok:6 disconnected:6 init:6 , Unit:
2014.11.04 15:51:51 5: DbLog: logging of Device: HMLAN1 , Type: HMLAN , Event: prot_timeout: last , Reading: prot_timeout , Value: last , Unit:
2014.11.04 15:51:51 1: 192.168.1.24:1000 disconnected, waiting to reappear (HMLAN1)
2014.11.04 15:51:51 5: Triggering HMLAN1 (1 changes)
2014.11.04 15:51:51 5: Notify loop for HMLAN1 DISCONNECTED
2014.11.04 15:51:51 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.11.04 15:51:51 5: Triggering HMLAN1 (4 changes)
2014.11.04 15:51:51 4: eventTypes: HMLAN HMLAN1 DISCONNECTED -> DISCONNECTED
2014.11.04 15:51:51 4: eventTypes: HMLAN HMLAN1 cond: disconnected -> cond: disconnected
2014.11.04 15:51:51 4: eventTypes: HMLAN HMLAN1 Xmit-Events: timeout:6 ok:6 disconnected:7 init:6 -> Xmit-Events: timeout:.* ok:.* disconnected:.* init:.*
2014.11.04 15:51:51 4: eventTypes: HMLAN HMLAN1 prot_disconnected: last -> prot_disconnected: last
2014.11.04 15:51:51 5: DbLog: logging of Device: HMLAN1 , Type: HMLAN , Event: DISCONNECTED , Reading: state , Value: DISCONNECTED , Unit:
2014.11.04 15:51:51 5: DbLog: logging of Device: HMLAN1 , Type: HMLAN , Event: cond: disconnected , Reading: cond , Value: disconnected , Unit:
2014.11.04 15:51:51 5: DbLog: logging of Device: HMLAN1 , Type: HMLAN , Event: Xmit-Events: timeout:6 ok:6 disconnected:7 init:6 , Reading: Xmit-Events , Value: timeout:6 ok:6 disconnected:7 init:6 , Unit:
2014.11.04 15:51:51 5: DbLog: logging of Device: HMLAN1 , Type: HMLAN , Event: prot_disconnected: last , Reading: prot_disconnected , Value: last , Unit:
2014.11.04 15:51:52 1: 192.168.1.24:1000 reappeared (HMLAN1)
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:A26ED12
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:C
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:+267F5E,00,01,FE1F
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:+26EF71,00,01,00
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:+28B907,00,01,00
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:+28B91B,00,01,00
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:+28B903,00,01,00
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:+286A21,00,01,00
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:+26E039,00,01,00
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:+26E56E,00,01,00
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:Y01,00,
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:Y02,00,
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:Y03,00,
2014.11.04 15:51:52 5: HMLAN_Send: HMLAN1 I:T1BEB9678,04,00,00000000
2014.11.04 15:51:52 1: HMLAN_Parse: HMLAN1 new condition init
2014.11.04 15:51:52 5: Triggering HMLAN1 (3 changes)
2014.11.04 15:51:52 5: Notify loop for HMLAN1 cond: init
Ich sehe da absolut keinen Grund für den Timeout. Hat jemand eine Idee? Die anderen Disconnects von heute sehen ähnlich aus.
Interessant sind die Zeiten, zu denen heute ein Timeout passiert ist:
09:51
10:06 --> +15min
14:07 --> +4h
14:21 --> +15min
15:21 --> +1h
15:51 --> +30min
Also ich würde sagen, das tritt immer bei vielfachen von 15min auf. Wie kann ich rausfinden was das sein kann?
Ich verdaechtige erst einm prasventiv den dblog
Hmlan muss alle 30sec getriggert werden. Das wird alle 25sec gemacht, sind also 5s puffer
Schalte einmal apptime an und pruefe, ob und wer hier kein echtzeit kann und das system blockiert. Dann ueberlege
ueberlege, obdu die funktion brauchst und wie du sie vom fhem prozess fern haeltst
Hm, ich bin nicht mehr 100% sicher, aber ich glaube das Problem war auch schon da bevor ich dbLog benutzt habe. apptime läuft schon eine ganze Weile (seit gestern), und sieht aktuell so aus:
name function max count total average maxDly
HMLAN1 HMLAN_Ready 2799 132 3341 25.31 0 HASH(HMLAN1)
HMLAN1 HMLAN_Read 1279 8522 205360 24.10 0 HASH(HMLAN1)
onTerraceDoorStatus notify_Exec 1214 1 1214 1214.00 0 HASH(onTerraceDoorStatus); HASH(Wohnzimmer.Terrassentuer)
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN1 628 3698 1185 0.32 45 keepAliveCk:HMLAN1
myDbLog DbLog_Log 575 2898 34625 11.95 0 HASH(myDbLog); HASH(HMLAN1)
FHEMWEB:192.168.1.30:61107 FW_Read 496 10 638 63.80 0 HASH(FHEMWEB:192.168.1.30:61107)
lp logProxy_Get 232 26 4530 174.23 0 HASH(lp); lp; HISTORY; INT; 2014-11-03_00:00:00; 2014-11-04_00:00:01; DbLog:myDbLog:Wohnzimmer.Wandthermostat.Climate:measured-temp; DbLog:myDbLog:Wohnzimmer.Wandthermostat.Climate:desired-temp; DbLog:myDbLog:Wohnzimmer.Wandthermostat.Climate:humidity; DbLog:myDbLog:Wohnzimmer.Heizkoerperthermostat.Clima:ValvePosition; Func:logProxy_WeekProfile2Plot("Wohnzimmer.Wandthermostat.Climate",$from,$to)
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 115 3652 7727 2.12 36 keepAlive:HMLAN1
myDbLog DbLog_Get 84 91 3764 41.36 0 HASH(myDbLog); myDbLog; HISTORY; INT; 2014-11-03_00:00:00; 2014-11-04_00:00:01; Bad.Heizkoerperthermostat.Clima:measured-temp
BerndAtHome DOIF_Notify 55 2898 114 0.04 0 HASH(BerndAtHome); HASH(geofancy)
Wohnzimmer.Wandthermostat.Climate CUL_HM_Set 50 18 186 10.33 0 HASH(Wohnzimmer.Wandthermostat.Climate); Wohnzimmer.Wandthermostat.Climate; desired-temp; 20.5
HM HMinfo_GetFn 41 1 41 41.00 0 HASH(HM); HM; rssi
isBerndAtHome dummy_Set 18 4 36 9.00 0 HASH(isBerndAtHome); isBerndAtHome; off
tmr-CUL_HM_ActCheck ActionDetector 13 152 1680 11.05 3 ActionDetector
eventTypes eventTypes_Notify 12 2898 4847 1.67 0 HASH(eventTypes); HASH(geofancy)
Arbeitszimmer.Heizkoerperthermostat.Clima CUL_HM_Set 8 6 48 8.00 0 HASH(Arbeitszimmer.Heizkoerperthermostat.Clima); Arbeitszimmer.Heizkoerperthermostat.Clima; ?
Bad.Heizkoerperthermostat.Clima CUL_HM_Set 8 5 40 8.00 0 HASH(Bad.Heizkoerperthermostat.Clima); Bad.Heizkoerperthermostat.Clima; ?
Esszimmer.Heizkoerperthermostat.Clima CUL_HM_Set 8 2 16 8.00 0 HASH(Esszimmer.Heizkoerperthermostat.Clima); Esszimmer.Heizkoerperthermostat.Clima; ?
Kueche.Heizkoerperthermostat.Clima CUL_HM_Set 8 2 15 7.50 0 HASH(Kueche.Heizkoerperthermostat.Clima); Kueche.Heizkoerperthermostat.Clima; ?
Schlafzimmer.Heizkoerperthermostat.Clima CUL_HM_Set 8 6 48 8.00 0 HASH(Schlafzimmer.Heizkoerperthermostat.Clima); Schlafzimmer.Heizkoerperthermostat.Clima; ?
Wohnzimmer.Heizkoerperthermostat.Clima CUL_HM_Set 8 2 16 8.00 0 HASH(Wohnzimmer.Heizkoerperthermostat.Clima); Wohnzimmer.Heizkoerperthermostat.Clima; ?
Was sagt mir das jetzt? Irgendwie scheint alles was kritisch aussieht von HMLAN selbst zu kommen?
P.S.: HMLAN hat sich seit meinem Post vorhin nochmal Disconnected, Uhrzeit 19:51. Also irgendwas muss da doch regelmäßig passieren??
Hallo,
ich benutze auch DBLog und einen HM-Lan-Adapter und habe keine disconnects.
Ist deine Netzwerkverbindung zum HM-Lan stabil?
Versuch mal ein anderes Netzwerkkabel - wenn du das nicht schon versucht hast.
Grüße
Ich habe auch täglich disconnects des HMLAN; benutze kein dblog und hatte das bis vor einiger Zeit nicht.
Bisher konnte ich keinen Zusammenhang zwischen bestimmten Funktionen/Aufrufen und dem disconnect erkennen.
In Verdacht habe ich noch die "Bildgenerierung" des RSS-Modul, aber dann müsste das eigentlich viel öfter passieren.
Aktuell habe ich zunächst das Logging optimiert, um die Schreibzugriffe zu minimieren und das Log übersichtlicher zu machen.
Vielleicht bringt mir das ja einen Ansatz, ob es meist in Kombination mit etwas anderem passiert.
ZitatHMLAN hat sich seit meinem Post vorhin nochmal Disconnected, Uhrzeit 19:51. Also irgendwas muss da doch regelmäßig passieren??
apptime am besten direkt nach disconnect aufrufen (notify). so wie du es aufrufst, ist es nach "max" sortiert und nur die grössten werte werden angezeigt. interessant wäre auch die spalte maxdly. da die meisten einträge unsichtbar sind, hat es so aber füe maxdly keine aussagekraft. wenn du mit option all aufrufst, ist alles dabei.
häufig wird auch das netzwerk blockiert und fhem kann den hmlan nicht erreichen.
es gibt auch noch das modul performancemonitor. sicher schon gefunden.
Bei mir sind die disconnects völlig verschwunden, seit ich HMLAN und Raspi einen eigenen Switch spendiert habe, auf dem nur die beiden und das Kabel zur Fritzbox sind. An der Fritzbox hängt dann der Switch mit dem Rest.
Ansonsten hat bei mir immer geholfen:
FHEM stoppen, fscheck aktivieren: touch /forcefsck und Raspi herunterfahren, kurz vom Strom trennen, wieder hochfahren und beobachten.
Zitat von: topfi am 05 November 2014, 12:23:50
Bei mir sind die disconnects völlig verschwunden, seit ich HMLAN und Raspi einen eigenen Switch spendiert habe
Kann ich bestätigen. Disconnects waren schon weg, nachdem ich am Switch die Ports mit den HMLAN Adaptern fest auf 100MBit/s eingestellt hatte. Nun habe ich einen alten "dummen" 100MBit Switch exklusiv für Cubietruck und drei HMLAN in Verwendung. Weiterhin habe ich alle zusätzlichen Dienste (Wetter, RSS ...) auf eine zweite FHEM Instanz verlagert.
Disconnects kenne ich gar nicht mehr - was ist das ;)
Ich habe schon seit dem ich Fhem nutze jede Menge disconnects im Monat. Anfangs mit dem RPI und nun auch mit einem Cubietruck.
Hatte einen Switch mit 100MBit/s an der FritzBox dran. An dem Switch hängt auch nur Fhem und der HMLan. An der FritzBox den entsprechenden Port auch auf 100MBit/s umgestellt => Keine Besserung
Nun einen Switch mit 1GBit/s dran und den Port an der FritzBox auch entsprechend umgestellt => Keine Besserung
Hatte mir auch schon apptime und perfmon zu Gemüte geführt => Keine nennenswerte Erkenntnisse
Ich werde mir das demnächst aber nochmal mit apptime und perfmon anschauen. Ist bei mir schon eine Weile her.
Ich hatte aber laut Log immer den Eindruck, dass ich die disconnects nur habe, sobald ich über das Webfrontend auf Fhem zugreife.
Hast Du plotfork aktiviert? Das hilft normalerweise auch.
ZitatIst deine Netzwerkverbindung zum HM-Lan stabil?
Versuch mal ein anderes Netzwerkkabel - wenn du das nicht schon versucht hast.
Sollte schon stabil sein, habe sonst mit dem Netzwerk keine Probleme. Es ist alles mit CAT7 verkabelt, ordentlich an einem Patchfeld aufgelegt und hängt an einem 24 Port Switch.
Das Logging habe ich schon soweit optimiert dass nur das geloggt wird was ich brauche.
Zitates gibt auch noch das modul performancemonitor. sicher schon gefunden.
Stimmt, der läuft schon die ganze Zeit mit. Allerdings finden sich keine Einträge zu den Zeitpunkten wo die Disconnects stattfinden. Allerdings jetzt was interessantes, habe gestern Abend noch "apptime maxDly" aufgerufen und folgende Ausgabe erhalten:
tmr-perfmon_ProcessTimer HASH(0x22f89c0) 1 92552 60 0.00 4100 HASH(0x22f89c0)
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 115 3695 7813 2.11 3540 keepAlive:HMLAN1
tmr-FW_closeOldClients 3 1542 1554 1.01 803
tmr-HMLAN_UpdtMsgCnt UpdtMsg:HMLAN1 2 2776 45 0.02 188 UpdtMsg:HMLAN1
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN1 628 3741 1185 0.32 45 keepAliveCk:HMLAN1
tmr-CUL_HM_ActCheck ActionDetector 13 154 1702 11.05 3 ActionDetector
tmr-HMLAN_clearQ hmClearQ:HMLAN1 1 1 1 1.00 2 hmClearQ:HMLAN1
tmr-CUL_HM_statCntRfresh StatCntRfresh 0 1 0 0.00 1
ActionDetector CUL_HM_Set 2 2 4 2.00 0 HASH(ActionDetector); ActionDetector; ?
Arbeitszimmer.Heizkoerperthermostat CUL_HM_Set 2 4 8 2.00 0 HASH(Arbeitszimmer.Heizkoerperthermostat); Arbeitszimmer.Heizkoerperthermostat; ?
Arbeitszimmer.Heizkoerperthermostat.Clima CUL_HM_Set 8 6 48 8.00 0 HASH(Arbeitszimmer.Heizkoerperthermostat.Clima); Arbeitszimmer.Heizkoerperthermostat.Clima; ?
Bad.Heizkoerperthermostat CUL_HM_Set 3 3 9 3.00 0 HASH(Bad.Heizkoerperthermostat); Bad.Heizkoerperthermostat; ?
Bad.Heizkoerperthermostat.Clima CUL_HM_Set 8 5 40 8.00 0 HASH(Bad.Heizkoerperthermostat.Clima); Bad.Heizkoerperthermostat.Clima; ?
BerndAtHome DOIF_Notify 55 2938 114 0.04 0 HASH(BerndAtHome); HASH(geofancy)
Esszimmer.Heizkoerperthermostat CUL_HM_Set 3 2 5 2.50 0 HASH(Esszimmer.Heizkoerperthermostat); Esszimmer.Heizkoerperthermostat; ?
Esszimmer.Heizkoerperthermostat.Clima CUL_HM_Set 8 2 16 8.00 0 HASH(Esszimmer.Heizkoerperthermostat.Clima); Esszimmer.Heizkoerperthermostat.Clima; ?
FHEMWEB:192.168.1.30:61408 FW_Read 0 1 0 0.00 0
FileLog_isBerndAtHome FileLog_Log 1 2 2 1.00 0 HASH(FileLog_isBerndAtHome); HASH(isBerndAtHome)
HM HMinfo_GetFn 41 1 41 41.00 0 HASH(HM); HM; rssi
HMLAN1 HMLAN_Notify 6 2938 31 0.01 0 HASH(HMLAN1); HASH(HMLAN1)
HMLAN1 HMLAN_Read 1279 8621 207711 24.09 0 HASH(HMLAN1) Was heißt das jetzt? Dass der Performancemonitor selbst die Probleme verursacht? :o ;D
Jedenfalls habe ich den gestern Abend dann deaktiviert und gerade mal "apptime maxDly" eingegeben, jetzt sieht es so aus:
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN1 412 2899 963 0.33 67 keepAliveCk:HMLAN1
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 50 2851 6110 2.14 65 keepAlive:HMLAN1
tmr-FW_closeOldClients 2 1191 1193 1.00 25
tmr-HMLAN_UpdtMsgCnt UpdtMsg:HMLAN1 1 714 24 0.03 25 UpdtMsg:HMLAN1
tmr-CUL_HM_ActCheck ActionDetector 13 119 1315 11.05 10 ActionDetector
tmr-HMLAN_clearQ hmClearQ:HMLAN1 3 10 11 1.10 6 hmClearQ:HMLAN1
tmr-CUL_HM_respPendTout respPend:28B907 13 1 13 13.00 3 respPend:28B907
tmr-CUL_HM_complConfigTO CUL_HM_complConfigTO 1 1 1 1.00 2 CUL_HM_complConfigTO
tmr-CUL_HM_procQs CUL_HM_procQs 0 1 0 0.00 2
ActionDetector CUL_HM_Set 3 4 10 2.50 0 HASH(ActionDetector); ActionDetector; ?
Arbeitszimmer.Heizkoerperthermostat CUL_HM_Set 3 5 14 2.80 0 HASH(Arbeitszimmer.Heizkoerperthermostat); Arbeitszimmer.Heizkoerperthermostat; ?
Arbeitszimmer.Heizkoerperthermostat.Clima CUL_HM_Set 9 8 65 8.12 0 HASH(Arbeitszimmer.Heizkoerperthermostat.Clima); Arbeitszimmer.Heizkoerperthermostat.Clima; ?
Arbeitszimmer.Heizkoerperthermostat.ClimaTeam CUL_HM_Set 3 1 3 3.00 0 HASH(Arbeitszimmer.Heizkoerperthermostat.ClimaTeam); Arbeitszimmer.Heizkoerperthermostat.ClimaTeam; ?
Arbeitszimmer.Heizkoerperthermostat.Climate CUL_HM_Set 3 1 3 3.00 0 HASH(Arbeitszimmer.Heizkoerperthermostat.Climate); Arbeitszimmer.Heizkoerperthermostat.Climate; ?
Arbeitszimmer.Heizkoerperthermostat.Remote CUL_HM_Set 3 1 3 3.00 0 HASH(Arbeitszimmer.Heizkoerperthermostat.Remote); Arbeitszimmer.Heizkoerperthermostat.Remote; ?
Arbeitszimmer.Heizkoerperthermostat.Weather CUL_HM_Set 2 1 2 2.00 0 HASH(Arbeitszimmer.Heizkoerperthermostat.Weather); Arbeitszimmer.Heizkoerperthermostat.Weather; ?
Arbeitszimmer.Heizkoerperthermostat.WindowRec CUL_HM_Set 2 1 2 2.00 0 HASH(Arbeitszimmer.Heizkoerperthermostat.WindowRec); Arbeitszimmer.Heizkoerperthermostat.WindowRec; ?
Bad.Heizkoerperthermostat CUL_HM_Set 3 9 27 3.00 0 HASH(Bad.Heizkoerperthermostat); Bad.Heizkoerperthermostat; ?
Bad.Heizkoerperthermostat.Clima CUL_HM_Set 10 12 98 8.17 0 HASH(Bad.Heizkoerperthermostat.Clima); Bad.Heizkoerperthermostat.Clima; ?
Bad.Heizkoerperthermostat.ClimaTeam CUL_HM_Set 3 1 3 3.00 0 HASH(Bad.Heizkoerperthermostat.ClimaTeam); Bad.Heizkoerperthermostat.ClimaTeam; ?
Bad.Heizkoerperthermostat.Climate CUL_HM_Set 3 1 3 3.00 0 HASH(Bad.Heizkoerperthermostat.Climate); Bad.Heizkoerperthermostat.Climate; ? Also eigentlich alles gut oder? Hatte aber trotzdem wieder Disconnects den Tag über :P
Jetzt werde ich vielleicht mal die Vorschläge mit dem Switch probieren, auch wenn ich das wirklich überhaupt nicht verstehen würde. Das würde ja heißen, der Switch würde die Pakete mehrere Sekunden verzögern, und da müsste man so einen Switch schon gehörig kaputt konfigurieren dass sowas passiert.
ZitatHast Du plotfork aktiviert? Das hilft normalerweise auch.
Sagt mir jetzt nix, wo finde ich da was dazu? Klingt irgendwie als würden dann Plots im Hintergrund laufen, aber wie gesagt, die Disconnects passieren ja auchtagsüber wenn niemand irgendwelche Plots erzeugt.
ZitatStimmt, der läuft schon die ganze Zeit mit. Allerdings finden sich keine Einträge zu den Zeitpunkten wo die Disconnects stattfinden.
das kannst du nur mit global verbose=5 rausfinden.
tmr-perfmon_ProcessTimer HASH(0x22f89c0) 1 92552 60 0.00 4100 HASH(0x22f89c0) das modul hat fhem maximal 1ms beschäftigt (max) und wurde von fhem 4,1s (maxdly) verzögert. also wurde hier eine 4,1 sec verzögerung vom performancemonitor festgestellt. hättest du die option all benutzt, könnte man den übeltäter mit 4,1s erkennen.
ZitatAlso eigentlich alles gut oder? Hatte aber trotzdem wieder Disconnects den Tag über
4,1 s stillstand ist zwar alles andere als gut, erklärt aber den disconnect nicht, wenn wdtimer vom hmlan auf 25 eingestellt ist. demnach kommem die blockaden von ausserhalb.
Zitat von: frank am 05 November 2014, 20:08:58
das kannst du nur mit global verbose=5 rausfinden.
Ja, ist mir klar, ich sehe ja auch ab und zu mal "possible freeze starting...", aber eben nicht zu den Zeiten wo die Disconnects stattfinden.
Zitattmr-perfmon_ProcessTimer HASH(0x22f89c0) 1 92552 60 0.00 4100 HASH(0x22f89c0)
das modul hat fhem maximal 1ms beschäftigt (max) und wurde von fhem 4,1s (maxdly) verzögert. also wurde hier eine 4,1 sec verzögerung vom performancemonitor festgestellt. hättest du die option all benutzt, könnte man den übeltäter mit 4,1s erkennen.
4,1 s stillstand ist zwar alles andere als gut, erklärt aber den disconnect nicht, wenn wdtimer vom hmlan auf 25 eingestellt ist. demnach kommem die blockaden von ausserhalb.
Achso ist das zu lesen, dann habe ich das falsch verstanden. Was genau heißt "Option all"? "apptime all" anscheinend nicht, das nimmt er nicht...
Zitat von: Joker am 05 November 2014, 19:42:35
Sagt mir jetzt nix, wo finde ich da was dazu? Klingt irgendwie als würden dann Plots im Hintergrund laufen, aber wie gesagt, die Disconnects passieren ja auchtagsüber wenn niemand irgendwelche Plots erzeugt.
Das war für dancatt gedacht:
"Ich hatte aber laut Log immer den Eindruck, dass ich die disconnects nur habe, sobald ich über das Webfrontend auf Fhem zugreife."
Seinerzeit hatte ich disconnects, wenn SVG_Plots aufgerufen wurden. Mit attr FHEMWEB plotfork 1 wird die Berechnung der Plots auf mehrere Threads aufgeteilt, was damals bei mir geholfen hat.
ZitatWas genau heißt "Option all"? "apptime all" anscheinend nicht, das nimmt er nicht...
zb "apptime max all" -> commandref.
Zitat"Ich hatte aber laut Log immer den Eindruck, dass ich die disconnects nur habe, sobald ich über das Webfrontend auf Fhem zugreife."
ich habe auch festgestellt, dass andfhem, über handy (gprs) auf fritzbox mit fhem, oft disconnects auslöst. je nachdem wie das aktualisierungsverhalten der app konfiguriert ist, erscheinen die disconnects dann ziehmlich regelmässig. vor allem läuft die app auch gerne im hintergrund.
gruss frank
Zitatich habe auch festgestellt, dass andfhem, über handy (gprs) auf fritzbox mit fhem, oft disconnects auslöst
Muss ich mir mal anschauen. Hab das Teil auch drauf.
Wenn dem so ist sollte man Matthias Klaas bescheid geben.
Ich hatte das Problem ja auch, leider auch mit langen disconnects.
Hatte testweise einen neuen HMLAN gekauft, exakt gleich eingebunden (getauscht) und siehe da: seit einem 3/4 Jahr keine Disconnects.
Das klingt ja nicht gut :P
Ich habe jetzt die letzten Tage immer mal wieder was geändert und weiter geforscht.
- Langläufer habe ich laut apptime keine:
apptime max (Auszug vom Anfang)
name function max count total average maxDly
HMLAN1 HMLAN_Ready 3008 101 15991 158.33 0 HASH(HMLAN1)
HMLAN1 HMLAN_Read 1244 17113 420645 24.58 0 HASH(HMLAN1)
onTerraceDoorStatus notify_Exec 1180 2 2122 1061.00 0 HASH(onTerraceDoorStatus); HASH(Wohnzimmer.Terrassentuer)
myDbLog DbLog_Log 700 6225 77744 12.49 0 HASH(myDbLog); HASH(Wohnzimmer.Heizkoerperthermostat.Clima)
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN1 520 7462 2466 0.33 582 keepAliveCk:HMLAN1
lp logProxy_Get 222 19 3528 185.68 0 HASH(lp); lp; HISTORY; INT;
apptime maxDly:
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN1 520 7466 2466 0.33 582 keepAliveCk:HMLAN1
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 109 7326 15530 2.12 270 keepAlive:HMLAN1
tmr-FW_closeOldClients 10 3063 3104 1.01 159
tmr-CUL_HM_ActCheck ActionDetector 14 306 3377 11.04 32 ActionDetector
tmr-HMLAN_UpdtMsgCnt UpdtMsg:HMLAN1 1 1838 74 0.04 25 UpdtMsg:HMLAN1
tmr-CUL_HM_statCntRfresh StatCntRfresh 0 2 0 0.00 3
ActionDetector CUL_HM_Set 3 6 14 2.33 0 HASH(ActionDetector); ActionDetector; ?
Trotzdem mehrere Disconnects am Tag.
Ich habe das Filesystem des Raspberry mal gecheckt, weiterhin als erstens den Switchport von HMLAN und Pi fix auf 100Mbit eingestellt, dann als zweiten Schritt einen zweiten Switch nur für HMLAN und Pi dazugestellt: Bringt alles genau gar nix.
Hat wer eine Strategie wie ich vorgehen kann, um rauszufinden was hier schiefgehen könnte? Es scheint ja irgendwie außerhalb von FHEM zu liegen. Ich habe mir mal die Prozesse etc angeschaut aber finde da auch nix besonderes.
hast du einmal apptime maxDly gemacht? das zeigt dir, wie lange ein timer ausserordentlich verzögert worden ist.
apptime registriert nur die Laufzeiten von FHEM jobs. der delay kann auch von "extern" kommen.
Ich hatte das exakt gleiche Problem wie Joker.
Ein ping auf den HMLAN brachte exakt alle 15 Minuten ein paar Pings (4-5) mit Antwortzeiten um die 3-4 Sekunden. Im Betrieb führte dies sehr oft zu einem timeout am HMLAN.
Diese Ping-Langläufer bekam ich auch, wenn fhem gar nicht gestartet war. Kein anderes Netzwerkdevice, welches ich gleichzeitig anpinge, hat diese Langläufer. Sieht also so aus als käme HMLAN mit irgendeiner Art Netzwerktraffic nicht klar, was für andere Devices kein Problem darstellt.
Ich habe nun HMLAN ein eigenes Netzwerkinterface am Server spendiert, auf dem fhem läuft. Interface kommt bei autoneg up mit 10 MBit und Half(!!!) Duplex. Seither kein einziges timeout mehr und alles funktioniert wunderbar :-)
Matthias
Zitat von: nebukadnezza am 24 Februar 2015, 09:59:25
...Ich habe nun HMLAN ein eigenes Netzwerkinterface am Server spendiert, auf dem fhem läuft. Interface kommt bei autoneg up mit 10 MBit und Half(!!!) Duplex. Seither kein einziges timeout mehr und alles funktioniert wunderbar :-)
Habe den Switch-Port, an dem mein HMLAN hängt, jetzt auch mal fest auf 10MBit Halbduplex eingestellt. Das hat die Abbrüche nochmals vermindert.
Ich habe diese Abbrüche auch seitdem ich Ende Januar irgendetwas neu konfiguriert habe ... nur was ::)
Jetzt habe ich heute mal einen Netzwerksniffer angeschlossen ... alle 25 Sekunden schickt FHEM ein Paket an den HMLAN, normalerweise kommt der Acknowledgement sofort (unterhalb der Zeitauflösung des Sniffers ;)) ...
aber nicht wenn es danach zum Disconnect kommt ... dann kommt gar kein Ack
nach 0,25, 0,8, 2 und 4,4 Sekunden macht FHEM ein Retransmit des Pakete (aber auch ohne Antwort) und dann wird die Verbindung abgebrochen und neu aufgebaut.
Aus meiner Sicht zeigt das, dass es nichts mit FHEM zu tun hat sondern ein HMLAN-Problem ist ... ich schaue mal, ob ich noch mehr heraus bekomme
ZitatAus meiner Sicht zeigt das, dass es nichts mit FHEM zu tun hat
kann sein
Zitatsondern ein HMLAN-Problem ist
oder den netzwerk. wo hast du gemessen? Kann es sein, dass du die message nicht gesehen hast?
Möglich ist eben auch, dass der HMLAN aus anderem Grund rebootet.
Zitat von: martinp876 am 01 März 2015, 17:40:28
kann seinoder den netzwerk. wo hast du gemessen? Kann es sein, dass du die message nicht gesehen hast?
Möglich ist eben auch, dass der HMLAN aus anderem Grund rebootet.
da ich direkt im TCP-Stack des Servers den Capture-Filter eingeklinkt habe ist es recht unwahrscheinlich ;) das FHEM den ACK vorher noch abfängt ... den ACK zu übersehen ist unmöglich, weil das Originalpaket und der 1. Retry unmittelbar nacheinander im Log liegen
Der HMLAN und der Server hängen am selben Switch ... ich schau mal ob ich mir einen Hardware-Sniffer ausleihen kann um die Daten direkt am HMLAN zu loggen
wenn es nur ein disconnect ist rebootet der HMLAN nicht. Wenn es ein reboot ist kannst du das an der Dauer erkennen. Auch meldet das Device die angemeldeten HMIds (die Anzahl). Nach einem Reboot wären die 0.
damit kannst du die Unterschiede erkennen. Leider weiss ich nicht, wann und warum ein HMLAN rebooten darf. Das müsste man ggf aus der Vorgeschichte erkennen.... können wir versuchen.
könnt aber auch schlicht an irgend einem Zähler schlecht empfangener messages liegen.... das wird schwer.
Ich habe jetzt einen zweiten HMLAN gekauft. Mit diesem gibt es nullkommanull disconnects, am gleichen Ort, Kabel und Netzteil. Dann habe ich den (ca. 1 Jahr) alten wieder angeschlossen, die neueste Firmware aufgespielt und siehe da: Ab und zu ein disconnect, vorrangig nachts, wenn überhaupt nichts anliegt.
Das ist also ein Hardwareproblem.
Ich hatte gestern 2 disconnects kurz hintereinander ... und vermute, dass das Reboots des HMLAN waren weil der 2. Reconnect zu der uptime des HMLAN passt.
Interessanterweise findet man im Sniffer jeweils 2 IGMPv1 membership reports mit der Multicastadresse 255.255.255.255 ... was mich doch ehrlich gesagt etwas wundert weil IGMP doch eigentlich den Routern im Netz eine Gruppenadresse/Multicast mitteilen soll und 255.255.255.255 ist hier m.E. nicht zulässig.
Ich werde mich jetzt mal an den eQ3-Support wenden
Da eQ-3 den direkten Support für Endkunden ablehnt >:( >:( habe ich mich jetzt an den Lieferanten gewendet, schau'n wir mal ;) ich habe keine Lust einen Zweiten zu kaufen und dann zwei mit dem selben Verhalten rumliegen zu haben
He Nobby1805,
hast du noch was erreichen können?
Grüße,
baeri3
Schau mal hier ... http://forum.fhem.de/index.php/topic,40391.msg327053.html#msg327053
aber ich muss da jetzt noch einmal nachhaken, mein HMLAN hat gerade wieder ausgesetzt sprich. etliche Reboots durchgeführt
Heute kam folgende Info von ELV
Zitatdas Verhalten konnte nun doch vom Hersteller eQ-3 reproduziert werden und wird in einem kommenden Update behoben. Wir empfehlen Ihnen, in regelmäßigen Abständen im eQ-3 Download-Bereich nach dem Update zu schauen, da aktuell leider noch kein Release-Termin vorliegt.
Ja das ist ja mal eine Interessante Info! Ich hoffe dieses Update kommt bald.
Nach der Ersteinrichtung vom HMLAN Anfang November hatte ich keine Disconnects aber nun teilweise alle 2-3 Minuten. Manchmal auch nur alle 10 Min aber mein Log ist voll damit.
Der HMLAN hängt an einem HP 1910-8G und der Port wurde von mir schon auf 10Mbit Half gestellt aber das hat nichts gebracht :(
Grüße
Dirk
Hallo Dersch,
hast du den fhem Server und HMLAN in ein eigenes Netz gehängt? 10MBit/half alleine reicht nicht.
lg,
Matthias
Ich hatte den Cubie und alle HMLAN mal auf einem eigenen dummen 100Mbit Switch und es gab keine disconnects mehr. Da ich nun im Keller einen neuen manageable 24er Switch habe, ist es natürlich unsinnig daneben noch einen nur für FHEM zu betreiben. Also alles auf den neuen umgebaut und die Disconnects waren wieder da (so alle paar Tage). Ich vermute, dass die HMLAN mit irgendwelchen speziellen Meldungen ein Problem haben und dann abschmieren (bei mir geht Fernsehen über IPv6 Multicast, es gibt einigen Applekram, NFS, VLAN etc.). Der alte Switch ist zu dumm, um diese Meldungen weiterzuleiten. Nun habe ich auf dem neuen Switch für alle HMLANs eine Port-Isolation konfiguriert und somit allen anderen Traffic ausgesperrt. Siehe da, Disconnects sind wieder weg. Ich habe mir daher nicht mehr die Mühe gemacht mit dem LAN-Sniffer den Übeltäter zu ermitteln.
Mein Tipp daher: Entweder alten dummen Switch nehmen, oder auf dem manageable Switch mittels Port-Isolation oder VLAN unerwünschten Traffic aussperren.
Grüße Deudi
Zitat von: Nobby1805 am 10 November 2015, 11:00:15
das Verhalten konnte nun doch vom Hersteller eQ-3 reproduziert werden und wird in einem kommenden Update behoben. Wir empfehlen Ihnen, in regelmäßigen Abständen im eQ-3 Download-Bereich nach dem Update zu schauen, da aktuell leider noch kein Release-Termin vorliegt.
Nur lustig, dass die Updates nicht im eQ-3 Download-Bereich zur Verfügung stehen werden. Das Update wird nur über die HMLAN Konfigurationssoftware angeboten. Habe gerade mal nach gesehen, ist immer noch die 964 ...
Zitat von: Deudi am 26 November 2015, 12:23:22
Mein Tipp daher: Entweder alten dummen Switch nehmen, oder auf dem manageable Switch mittels Port-Isolation oder VLAN unerwünschten Traffic aussperren.
Grüße Deudi
Danke für den Tipp, doch ist der wahrscheinlich nur selten durchführbar (Nicht jeder hat das Glück die HMLAN's wired zu haben)
Bei mir hängt einer an der Fritzbox, und zwei über WLAN Bridges. (OpenWRT mit relayd)