Hi, mein HMLAN ueber das ich gerade mal 3 Geraete ansteuere bringt immer wieder Fehlermeldungen.
Es ist wie folgt konfiguriert:
define HMLAN1 HMLAN 192.168.178.35:1000
attr HMLAN1 group HomeMatic
attr HMLAN1 hmId xxxxx
attr HMLAN1 hmLanQlen 2_low
attr HMLAN1 hmProtocolEvents 1_dump
attr HMLAN1 wdTimer 25Das Logfile sagt:
Zitat2014.05.08 22:07:30 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.05.08 22:07:30 3: Opening HMLAN1 device 192.168.178.35:1000
2014.05.08 22:07:30 3: HMLAN1 device opened
2014.05.08 22:07:30 1: HMLAN_Parse: HMLAN1 new condition init
2014.05.08 22:07:35 1: HMLAN_Parse: HMLAN1 new condition ok
2014.05.08 22:07:39 3: CUL_HM set HM_LC_SW4_WM_1E4863 statusRequest
2014.05.08 22:35:42 1: 192.168.178.35:1000 disconnected, waiting to reappear
2014.05.08 22:35:42 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.05.08 22:36:44 1: 192.168.178.35:1000 reappeared (HMLAN1)
2014.05.08 22:36:44 1: HMLAN_Parse: HMLAN1 new condition init
2014.05.08 22:36:44 1: HMLAN_Parse: HMLAN1 new condition ok
2014.05.09 09:18:57 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.05.09 09:18:57 3: Opening HMLAN1 device 192.168.178.35:1000
2014.05.09 09:18:57 3: HMLAN1 device opened
2014.05.09 09:18:57 1: HMLAN_Parse: HMLAN1 new condition init
Kann man da was machen oder ist das normal?
Passiert das disconnecten immer wenn auf das webinterface auf einen bestimmten Raum /device zugegriffen wird?
Ich hatte so ein Problem mit dem sysmon modul, immer wenn ich über das weninterface auf das sysmon zugegriffen habe, um bestimmte status meines raspberrypi abzurufen hing das webinterface und der hmlan Adapter disconnectete sich.
Jetzt hab ich sysmon erstmal wieder rausgeschmissen. Ich vermute es liegt daran, das auf dem raspberry alles über denselben Bus läuft und netzwerkzugriffe und zugriffe auf USB die CPU Last erhöhen
Gesendet von meinem iPhone mit Tapatalk
prüfe, wie das timing ist.
- schaue die internals in HMLAN an - ist das keepalive zu spät? Schon mit wiki verglichen?
- schau dir apptime an - hast du langläufer die dein system blockieren?
Ich hab auf dem raspi nur fhem laufen.
Gesendet von meinem iPhone mit Tapatalk
ok - aber da gibt es viele optionen, einige sind blockierend....
also - was sagt HMLAN?
was sagt apptime?
Also HMLAN sagt unter keepalive folgendes:
msgKeepAlive
dlyMax:2.006 bufferMin:2
msgLoadEst
1hour:0% 10min steps: 0/0/0/0/0/0
msgParseDly
min:-13 max:1987 last:7 cnt:1186
ich habe in den Attributen die Standardwerte
wdTimer 25
Apptime?
Ich finde da zwar was in der commandref, leider nur englisch...
was muß ich nehmen apptime count?
Gruß
Jens
Hi Jens,
hm - mit 2 sec delay sollte es noch klappen.
mache
apptime
dann fängt es an, werte zu sammeln.
Du kannst dann eine tabelle anzeigen lassen, wieder mit apptime oder nach Spalten sortiert (es werden immer nur die grössten Werte ausgegeben
apptime maxDly
apptime count
...
mit
apptime clear
werden die Zähler rückgesetzt, das Zählen beginnt neu.
Also starte apptime. warte auf den Fehler und dann schaue die Tabelle an.
Gruss Martin
Ich habe das früher auch gehabt, immer wenn auf Sysmon zugegriffen wurde. Das lag wohl daran, dass das System so lange mit der Erstellung der Grafiken zu tun hat. Dann habe ich im FHEMWEB attr plotfork 1 aktiviert und seitdem ist Ruhe.
Ja, plotfork ist ganz wichtig. Vereinzelt hatte ich aber immer noch Disconnects. Dann habe ich dafür gesorgt, dass am Switch die Ports mit angeschlossenem HMLAN Adapter auf 100MBit eingestellt sind. Danach war entgültig Ruhe.
Also entweder am manageable Switch einstellen oder falls der an der Fritzbox hängt den Port auf "Green Mode" stellen oder gleich alles was mit FHEM zu tun hat auf einen eigenen alten 100MBit Switch hängen.
Ich habe seit einigen Wochen letzteres in Betrieb, da ich alle drei HMLAN getrennt in den Keller patchen konnte.
Gruß Jürgen
Also der hmlan hängt an der Fritz box und der Port ist auf Green Mode geschaltet. Leider habe ich nur eine unmanaged Switch von tplink der automatisch 1gbit/100mbit schaltet.
Plotfork werde ich mal einschalten.
Gruß hens
Gesendet von meinem iPhone mit Tapatalk
Bei mir hat auf dem Raspberry außerdem geholfen, die Webseite durch einen Apache im reverse-proxy nach außen zu leiten. Das scheint fhem auch zu entlasten, die Plots bauen sich schneller auf. Kommt mir jedenfalls so vor. :D
Außerdem habe ich (pösepöse, soll man nicht, aber Aspirin ist eben manchmal auch ein Segen :D)
attr HMLAN1 wdTimer 18
gesetzt, also alle 18 Sekunden den Ping statt alle 25. Seitdem disconnectet da gar nichts mehr.
Naja soviel aufwand auch noch einen revers Proxy einzurichten wollte ich nicht betreiben. Da lasse ich die Plots und sysmon eher weg.;)
Gesendet von meinem iPhone mit Tapatalk
Hi,
also bei mir scheint plotfork ein wenig geholfen zu haben. wie auch immer, heute Nacht um 04:00 gabe es wieder einen Aussetzer. Da wurde weder das Webinterface noch irgendein homematic modul bedient.
Zitat2014.05.14 04:00:23 1: 192.168.178.35:1000 disconnected, waiting to reappear
2014.05.14 04:00:23 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.05.14 04:01:28 1: 192.168.178.35:1000 reappeared (HMLAN1)
2014.05.14 04:01:28 1: HMLAN_Parse: HMLAN1 new condition init
2014.05.14 04:01:28 1: HMLAN_Parse: HMLAN1 new condition ok
HMLAN sagt:
RSSI -79
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDs 1E4863
assignedIDsCnt 1
assignedIDsReport 0
firmware 0.961
msgKeepAlive dlyMax:3.315 bufferMin:1
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
msgParseDly min:2 max:7 last:4 cnt:8
uptime 035 841:38:30.947
Xmit-Events ok:1 2014-05-14 04:01:28
cond ok 2014-05-14 04:01:28
prot_ERROR-Overload last 2014-03-15 17:46:33
prot_Overload-released last 2014-03-15 17:18:46
prot_Warning-HighLoad last 2014-03-15 17:46:33
prot_disconnected last 2014-05-14 04:00:23
prot_init last 2014-05-14 04:01:28
prot_keepAlive last 2014-05-14 04:00:23
prot_ok last 2014-05-14 04:01:28
prot_timeout last 2014-05-10 09:08:36
eingestellt hab ich
hmLanQlen 1_min
wdTimer 25
es war also ein keepalive problem.
hast du apptime schon probiert?
Hi, dake fuer Den tipp.
Also ich habs aufgerufen, mir dann mein Dashboard ( wie so oft angeschaut) und nochmal aufgerufen.
Hier deas Ergebnis:
Zitat name function max count total average maxDly
FHEMWEB:195.233.250.7:28237 FW_Read 2062 9 2102 233.56 0 HASH(0xd1a1a8)
PowerLog FileLog_Get 1538 1 1538 1538.00 0 HASH(0x15408e0); PowerLog; CURRENT; INT; 2014-05-14_00:00:00; 2014-05-15_00:00:01; 4:Wechselrichter.AC.Power\x3a::; 4:Wechselrichter.Daily.Energy\x3a::; 4:Wechselrichter.EnergyExpected\x3a::; 3:Wechselrichter.*::24.3; 4:Wechselrichter.generator1power\x3a::; 4:Wechselrichter.generator3power\x3a::
FHEMWEB:195.233.250.7:28239 FW_Read 1338 10 1383 138.30 0 HASH(0x121a480)
FHEMWEB:195.233.250.7:28087 FW_Read 1332 14 1398 99.86 0 HASH(0x125c870)
FHEMWEB:195.233.250.7:28231 FW_Read 1229 11 1274 115.82 0 HASH(0x129c980)
FHEMWEB:195.233.250.7:41036 FW_Read 1120 7 1725 246.43 0 HASH(0xd17590)
PowerLog2 FileLog_Get 872 2 989 494.50 0 HASH(0x1550588); PowerLog2; CURRENT; INT; 2014-01-01_00:00:00; 2015-01-01_00:00:01; 4:Wechselrichter.Total.Energy\x3a::; 4:Wechselrichter.Daily.Energy.Last\x3a::; 4:WechselrichterPlan.*::; 4:Wechselrichter2013.Total.Energy\x3a::
Log_Heizung FileLog_Get 778 3 2224 741.33 0 HASH(0x1264230); Log_Heizung; CURRENT; INT; 2014-05-14_00:00:00; 2014-05-15_00:00:01; 7:Heizung.sGlobal\x3a::; 9:Heizung.sGlobal\x3a::; 11:Heizung.sGlobal\x3a::; 13:Heizung.sGlobal\x3a::; 5:Heizung.sGlobal\x3a::
FHEMWEB:195.233.250.7:28236 FW_Read 548 12 1048 87.33 0 HASH(0x1529068)
tmr-KOSTALPIKO_GetStatus HASH(0xd14da8) 527 1 527 527.00 229 HASH(0xd14da8)
Log_Pool FileLog_Get 293 1 293 293.00 0 HASH(0xd12830); Log_Pool; CURRENT; INT; 2014-05-14_00:00:00; 2014-05-15_00:00:01; 4:Pool_auf.level\x3a:0:; 4:Pool_zu.level\x3a:0:; 3:Poolpumpe.*:0:; 4:Wechselrichter.AC.Power\x3a::; 4:Heizung.AussenTemp\x3a::; 4:Poolrelais.*:0:
FHEMWEB:195.233.250.7:46598 FW_Read 254 4 268 67.00 0 HASH(0x15d5ba8)
FHEMWEB:195.233.250.7:28225 FW_Read 170 7 207 29.57 0 HASH(0x1502da8)
FHEMWEB:195.233.250.7:28238 FW_Read 147 10 190 19.00 0 HASH(0x15498c8)
HMLAN1 HMLAN_Read 56 2 57 28.50 0 HASH(0x1534728)
Log_HeizungHistory FileLog_Get 51 1 51 51.00 0 HASH(0x1221eb8); Log_HeizungHistory; CURRENT; INT; 2014-05-11_00:00:00; 2014-05-18_00:00:01; 4:Heizung.sElectrHCDay\x3a::; 4:Heizung.sHeatRecoveredDay\x3a::; 4:Heizung.sElectrDHWDay\x3a::
Log_HeizungHistory FileLog_Set 14 1 14 14.00 0 HASH(0x1221eb8); Log_HeizungHistory; ?
PowerLog FileLog_Set 10 2 18 9.00 0 HASH(0x15408e0); PowerLog; ?
HMLAN1 HMLAN_Ready 9 11 9 0.82 0 HASH(0x1534728)
PowerLog2 FileLog_Set 9 2 17 8.50 0 HASH(0x1550588); PowerLog2; ?
FHEMWEB:195.233.250.7:28240 FW_Read 8 2 13 6.50 0 HASH(0x154b198)
Von der Seite: https://blog.chanoa.de/fhem-performance hab ich erfahren das alles "MAX" werte uber 1000ms angeschaut werden sollten. Shit da gibts jede Menge. Aber was mach ich jetzt?
Offensichtlich gibt es mehrfache FHEM Webinstanzen, obwohl ihc nur mit einem PC zugreife, evtl. bruacht die PV Anlage uber Ethernet auch noch so einen Process zum loggen. Und das Powerlog passt ja auch dazu.
PV Anlage (Kostal) und HMLAN haengen am gleichen Fritzbox7390 switch der ja auch Gigabit Ehternet supported. Kostal kann aber nur 10Mbit, HMLAN 100 so weit ich weiss.
du solltest auch ein
apptime maxDly
machen. Das gibt die Liste sortiert nach der maximalen Verzögerung aus. Also wenn ein timer gestartet wurde und die entsprechende Funktion nicht zum Zeitpunkt des Ablaufs sondern später ausgeführt wurden. Damit kannst du dann auch sehen, wenn es Delay von "ausserhalb FHEM" gibt.
Gruss Martin
ok, das sieht dann so aus:
Zitat name function max count total average maxDly
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 49 2947 6913 2.35 6402 keepAlive:HMLAN1
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN1 4 2952 22 0.01 6156 keepAliveCk:HMLAN1
tmr-FW_closeOldClients 8 1232 1359 1.10 2026
tmr-HMLAN_UpdtMsgCnt UpdtMsg:HMLAN1 3 3700 3755 1.01 1283 UpdtMsg:HMLAN1
tmr-KOSTALPIKO_GetStatus HASH(0xd14da8) 6194 1233 752921 610.64 674 HASH(0xd14da8)
tmr-at_Exec HASH(0x128c9e0) 140 1 140 140.00 33 HASH(0x128c9e0)
tmr-holiday_refresh feiertage 73 1 73 73.00 20 feiertage
tmr-at_Exec HASH(0x1531748) 166 1 166 166.00 15 HASH(0x1531748)
tmr-at_Exec HASH(0x14e2ae0) 233 247 40153 162.56 7 HASH(0x14e2ae0)
tmr-at_Exec HASH(0xae2e40) 8 1 8 8.00 7 HASH(0xae2e40)
tmr-at_Exec HASH(0x1290930) 177 1 177 177.00 6 HASH(0x1290930)
tmr-at_Exec HASH(0x12639e0) 574 247 122531 496.08 5 HASH(0x12639e0)
tmr-Weather_GetUpdate HASH(0x1261b30) 427 11 4058 368.91 3 HASH(0x1261b30)
tmr-CUL_HM_statCntRfresh StatCntRfresh 1 1 1 1.00 2 StatCntRfresh
FHEMWEB:195.233.250.7:23505 FW_Notify 7 5 15 3.00 0 HASH(0x1293d68); HASH(0xd14da8)
FHEMWEB:195.233.250.7:23505 FW_Read 1024 27 1345 49.81 0 HASH(0x1293d68)
FHEMWEB:195.233.250.7:23505 FW_Set 0 2 0 0.00 0
FHEMWEB:195.233.250.7:23521 FW_Notify 0 5 0 0.00 0
FHEMWEB:195.233.250.7:23521 FW_Read 1235 23 1881 81.78 0 HASH(0x12854f8)
FHEMWEB:195.233.250.7:23521 FW_Set 0 2 0 0.00 0
FHEMWEB:195.233.250.7:49317 FW_Read 578 6 743 123.83 0 HASH(0xd16bd0)
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 49 2947 6913 2.35 6402 keepAlive:HMLAN1
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN1 4 2952 22 0.01 6156 keepAliveCk:HMLAN1
da wurde das keepAlive um über 6 sec verzögert. Mehr als 5 führt zum Disconnect. Es kann die Summe von einzel-delays sein
ok und was nun, warum dauert der keepalive so lange?
Wie kann ich das rausfinden?
...und die vielen Eintraege unter FHEMWEB bei apptime, sind die "normal" oder kann man das auch verbessern?
Die Verzoegerung ist also erst einmal der Grund fuer den disconnect.
Wenn du dies nun mit der Laufzeit vergleichst findest du
tmr-KOSTALPIKO_GetStatus HASH(0xd14da8) 6194 1233 752921 610.64 674 HASH(0xd14da8)
der Timer laesst sich min einmal 6 sec Zeit. Jedenfalls manchmal. Und er wird so alle Minute aufgerufen.
Was macht der? die 6sec halte ich generell fuer untragbar (musst aber du entscheiden)
Du musst also in erster Linie die maxDly und max (laufzeit) im Auge behalten. Der Rest dient dann zum weiteren Tuning... wenn man will.
Die vielen fhemweb sind connections, die aufgemacht werden, wenn jemand auf FHEM zugreift. Welche genau dies sind kann ich nicht sagen. Mit apptime name all kannst du alle Eintraege sehen, nach Namen sortiert. ggf bei Rudi nachfragen.
Gruss Martin