Hallo Zusammen,
mein HMLAN ist gestern abend um 23:40 in den Overload gegangen - soweit so gut.
Allerdings ist er jetzt, nach über acht Stunden, immer noch in diesem Zustand. In der Zwischenzeit sind allerdings keine Befehle abgesetzt worden, die das noch rechtfertigen. Was läuft da schief?
Logs und Parameter anbei.
Viele Grüße Christoph
Internals:
CFGFN /opt/fhem/fhem_include_HomeMatic.cfg
DEF 192.168.4.200:1000
DeviceName 192.168.4.200:1000
FD 14
HMLAN1_MSGCNT 15382
HMLAN1_TIME 2014-03-17 08:45:14
HM_CMDNR 131
NAME HMLAN1
NR 102
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG E26024F,0000,069023E6,FF,FFB4,BA865A26024F000000A8D332
RSSI -76
STATE overload
TYPE HMLAN
XmitOpen 1
assignedIDs 26024F,2236BE,21735F,1F7594,219144,21CFF0,24AD08,219A8C,21CF29,236C2B,21720B,235955,23C68F,221C2C,21CDC5,2230AE,22309C
assignedIDsCnt 17
assignedIDsReport 12
firmware 0.961
msgKeepAlive dlyMax:381.16 bufferMin:1
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
msgParseDly min:-68 max:12365 last:15 cnt:14843
owner CC0007
serialNr JEQ0706431
uptime 001 30:35:14.118
Readings:
2014-03-17 00:01:20 Xmit-Events ok:1
2014-03-17 00:01:20 cond ok
2014-03-16 23:40:58 prot_ERROR-Overload last
2014-03-16 23:51:19 prot_Warning-HighLoad last
2014-03-16 02:10:19 prot_disconnected last
2014-03-16 02:10:25 prot_init last
2014-03-13 17:14:10 prot_keepAlive last
2014-03-17 00:01:20 prot_ok last
2014-03-16 02:10:19 prot_timeout last
Assids:
1F7594 1
21720B 1
21735F 1
219144 1
219A8C 1
21CDC5 1
21CF29 1
21CFF0 1
221C2C 1
22309C 1
2230AE 1
2236BE 1
235955 1
236C2B 1
23C68F 1
24AD08 1
26024F 1
Helper:
000001:
flg 0
msg
to 1395010882.43431
1f7594:
chn 02
flg 0
msg
name Hzkp_Flur
to 1394989653.65576
21720b:
chn 02
flg 0
msg
name OG_Nachtlicht
to 1394991483.09394
21735f:
chn 02
flg 0
msg
name Kueche_Nachtlicht
to 1394990262.12944
219144:
chn 01
flg 0
msg
name Fnstr_Schlafzimmer
to 1394968274.42386
219a8c:
chn 01
flg 0
msg
name Fnstr_Bad
to 1395008939.1961
21cdc5:
chn 02
flg 0
msg
name Hzkp_Bad
to 1395000116.52422
21cf29:
chn 80
flg 0
msg
name Hzkp_Wohnzimmer
to 1394937337.4898
21cff0:
chn 02
flg 0
msg
name Hzkp_Esszimmer
to 1394949193.03815
221c2c:
chn 02
flg 0
msg
name Hzkp_Philipp
to 1394970287.0145
22309c:
chn 80
flg 0
msg
name Hzkp_Klo
to 1394937367.35304
2230ae:
chn 02
flg 0
msg
name Hzkp_Schlafzimmer
to 1394946352.03222
2236be:
chn 02
flg 0
msg
name Hzkp_Veranda
to 1394949875.36491
235955:
chn 02
flg 0
msg
name Hzkp_Treppenhaus
to 1394985682.6653
236c2b:
chn 80
flg 0
msg
name Hzkp_Kueche
to 1394937302.93019
23c68f:
chn 02
flg 0
msg
name Hzkp_Erker
to 1394969927.37403
24ad08:
chn 02
flg 0
msg
name CUL_HM_HM_ES_PMSw1_Pl_24AD08
to 1394891180.42269
26024f:
chn 03
flg 0
msg
name Thrm_Bad
to 1395009658.47072
Cc0007:
flg 0
Assids:
Dly:
cnt 14843
lst 15
max 12365
min -68
K:
BufMin 1
DlyMax 381.16
Next 1395042343.56016
Start 1395042318.56016
Log:
all 1
sys 1
ids:
sys
all
Q:
HMcndN 0
answerPend 0
hmLanQlen 5
keepAliveRec 1
keepAliveRpt 0
apIDs:
Cap:
0 0
1 0
2 0
3 0
4 0
5 0
last 4
sum 0
Ref:
drft 3.99808092115784e-05
hmtL 110114118
kTs 0
offL 1394932204453
sysL 1395042318571
Attributes:
alias HMLan
devStateIcon overload:WLAN_Status.0
group Input/Output
hmId CC0007
hmLanQlen 5_critical
icon hm_lan
logIDs sys,all
room CUL_HM,Maschinenraum
wdTimer 25
Hallo,
zum einen - HM-LAN vom Strom trennen und wieder anschließen restettet den HM-LAN, dann kann er wieder senden.
Was versucht das Teil den alle ca. 25-30 sec. zu senden ? HMLAN_Send: HMLAN1 I:K ? Das der dann in den Overload geht ist normal.
Gruß Christoph
Zitat von: Bennemannc am 17 März 2014, 09:10:54
zum einen - HM-LAN vom Strom trennen und wieder anschließen restettet den HM-LAN, dann kann er wieder senden.
Was versucht das Teil den alle ca. 25-30 sec. zu senden ? HMLAN_Send: HMLAN1 I:K ? Das der dann in den Overload geht ist normal.
Dass Stromabtrennen den Overload beseitigt ist mir klar. Ich will aber nicht die Symptome beheben sondern die Ursachen. Zumal ich dieses Verhalten schön öfters hatte. Ich bin ja nicht immer zuhause, um den Stecker zu ziehen.
HMLAN_Send: HMLAN1 I:K
ist doch normal und das habe ich immer; das sollte den Overload auch nicht verursachen.
selbstverständlich muss das HMLAN wieder aus Overload recovern.
Mit dem Ziehen des Steckers kann man die Zähler rücksetzen, aber das IO erholt sich automatisch. Max nach 1h ist alles auf 0 - ein senden ist i.a. deutlich eher wieder möglich.
Alle 100sec wird dies geprüft.
In deinem Fall ist dies auch so.
16 23:40:39 HMLAN_Send: stat: 00 m:7B B001 CC0007 26024F 00040000000000
16 23:40:40 HMLAN_Send: stat: 00 m:7C B001 CC0007 26024F 0103
16 23:40:40 HMLAN_Parse: new condition Warning-HighLoad
16 23:40:40 HMLAN_Send: stat: 00 m:7D B001 CC0007 26024F 01040000000001
16 23:40:41 HMLAN_Send: stat: 00 m:7E B001 CC0007 26024F 0203
16 23:40:42 HMLAN_Send: stat: 00 m:7F B001 CC0007 26024F 02040000000001
16 23:40:43 HMLAN_Send: stat: 00 m:80 B001 CC0007 26024F 00040000000007
16 23:40:47 HMLAN_Send: stat: 00 m:81 B001 CC0007 26024F 02040000000008
16 23:40:52 HMLAN_Send: stat: 00 m:82 B001 CC0007 26024F 02040000000009
16 23:40:56 HMLAN_Send: stat: 00 m:83 B001 CC0007 26024F 0303
16 23:40:58 HMLAN_Parse: new condition ERROR-Overload
16 23:51:19 HMLAN_Send: stat: 00 m:99 8112 CC0007 000001
16 23:51:19 HMLAN_Parse: new condition Warning-HighLoad
17 00:01:20 HMLAN_Send: stat: 00 m:99 8112 CC0007 000001
17 00:01:20 HMLAN_Parse: new condition ok
Nicht senden war also nur von 23:40:58 bis 23:51:19 nicht möglich.
Der Grund der overload war die Kommunikation mit 26024F - welches mit burst kommunizert. Es handelt sich offensichtlich um einen TC-IT bei dem ein getConfig ausgeführt wurde.
Den Grund für das getConfig kann ich aktuell nicht erkennen.
Den Performancebedarf eines burst-device werde ich versuchen zu optimieren.
Wieso kommst du auf die Idee, dass sich das System nicht erholt hat?
Gruss Martin
Weil der State immer noch im Overload ist. Siehe Anhang im ersten Post.
hm - anzeigeproblem - werde ich mich drum kümmern.
entscheidend ist, dass
Xmit-Events ok:1
cond ok
das senden erlaubt. Operationell also alles ok
23:40:58 prot_ERROR-Overload last
23:51:19 prot_Warning-HighLoad last
02:10:19 prot_disconnected last
02:10:25 prot_init last
17:14:10 prot_keepAlive last
00:01:20 prot_ok last
02:10:19 prot_timeout last
Gruss Martin
Nun senden geht aber auch nicht!
Da bekomme ich einen IOErr.
Nachtrag:
Ich habe jetzt FHEM neugestartet. HMLAN hatte ich NICHT vom Strom getrennt. Jetzt ist wieder alles in Ordnung. Seltsam, seltsam,...
hm - muss ich dir recht geben - STATE wird doch einbezogen.
Mit einem Update sollte es behoben sein (morgen versteht sich, jetzt in SVN Version 5244)
Super und schon mal 1000 Dank !!
so, jetzt kommt noch eine Performance-Spar-Massnahme, die ich schon länger geplant hatte.
Ein TC-IT braucht bei einem kompletten getConfig bislang 16% der 1h Kapazität einer HMLAN/USB. Das sollte sich ab Morgen auf 4% reduzieren.
Die Verbesserung liegt in der sparsameren Nutzung des Burst (wachrütteln).
Insbesondere Performance sparsam kann der User umgehen indem er
- Registeränderungen mit "perp/exec" vorbereitet/ausführt
- kommandos für ein Device blockweise abschickt. Es wird ein burst gesendet und dann alles was in der Queue hängt. Sollt einen Pause entstehen muss noch einmal geweckt werden.
Gruss Martin
Klingt gut!
Irgendwie läuft der TC-IT (zumindest bei mir) noch nicht so ganz rund:
Manche Register (z.B. die Templisten und Bitfelder) lassen sich so gut wie nie setzen: meistens quittiert mit "no ACK". Gefühlt würde ich sagen, dass es in einem von zehn Fällen mal klappt.
Das Setzen der desired-Temp per FHEM klappt dagegen ohne Probleme. Komisch.
Ich will morgen den TC-IT mal resetten und neu anlernen. Mal sehen, ob das hilft. Wenn nicht, werde ich Rohmessages aufzeichnen und hier posten.
wäre seltsam, wenn neu anlernen etwas bringt.
Wenn die Kommunikation nicht klappt solltest du rohmessages loggen und mir schicken. Dazu sagen, was du gemacht hast.
Gruss Martin
Zitat von: martinp876 am 17 März 2014, 19:55:09
so, jetzt kommt noch eine Performance-Spar-Massnahme, die ich schon länger geplant hatte.
Ein TC-IT braucht bei einem kompletten getConfig bislang 16% der 1h Kapazität einer HMLAN/USB. Das sollte sich ab Morgen auf 4% reduzieren.
Die Verbesserung liegt in der sparsameren Nutzung des Burst (wachrütteln).
Hi Martin,
was hast Du da alles geändert? Meine Probleme mit dem Setzen von diversen Registern bestehen nicht mehr. Wurde am Timing etwas geändert?
Gruß
Christoph
nein, nicht am timing, aber am nutzen der Burst-events auf der Funkstrecke. Insbesondere der TC-IT ist beim Konfigurieren betroffen. Generell ging es vorher auch schon... aber der HMLAN wird weniger belastet. Konnte leichter sein, dass er in overload ging.