Moin!
Ich bin neu im FHEM und Haustechnik bereich, allerdings einigermaßen fit unter Linux / PC Technik.
Ich habe mir eine kleine "Testumgebung" zusammengestellt, bestehend aus:
- 1 x EQ3 85128 HomeMatic Konfigurations-Adapter LAN
-- 1 x HomeMatic 105155 Funk-Stellantrieb
-- 1 x HomeMatic Funk-Tür-/ Fensterkontakt für Zentrale
-- 1 x HomeMatic 105788 Funk-Zwischenstecker-Schaltaktor 1-fach, HM-LC-Sw1-PL
Ich habe, nach Hinweise aus dem Netz, den LAN Adapter hinzugefügt (Inkl. geändertem Zugangsschlüssel, über die Windows Software AES deaktiviert etc. also nach Anleitung vorgegangen) und die Komponenten angelernt. Die Funktion ist auch gegeben, allerdings switcht der Lan Adapter andauernt zwischen verbunden und nicht verbunden, wo ich derzeit absolut keine Begründung für sehe.
Installiert ist FHEM (Update auf neuste Version wurde via update Befehl ausgefüht) auf einem aktuell gepachtem Ubuntu 64 Bit System. Intakte und sonst einwandfreie verkabelte Ethernet Verkabelung.
Im Logfile sieht das ganze wiefolgt aus:
...
2014.02.26 18:53:53 1: 192.168.10.50:1000 disconnected, waiting to reappear
2014.02.26 18:53:53 1: HMLAN_Parse: wz_HMLAN new condition disconnected
2014.02.26 18:55:58 1: 192.168.10.50:1000 reappeared (wz_HMLAN)
2014.02.26 18:55:58 1: HMLAN_Parse: wz_HMLAN new condition init
2014.02.26 18:55:58 1: HMLAN_Parse: wz_HMLAN new condition ok
2014.02.26 18:58:48 1: 192.168.10.50:1000 disconnected, waiting to reappear
2014.02.26 18:58:48 1: HMLAN_Parse: wz_HMLAN new condition disconnected
2014.02.26 19:00:53 1: 192.168.10.50:1000 reappeared (wz_HMLAN)
2014.02.26 19:00:53 1: HMLAN_Parse: wz_HMLAN new condition init
2014.02.26 19:00:53 1: HMLAN_Parse: wz_HMLAN new condition ok
2014.02.26 19:03:58 1: 192.168.10.50:1000 disconnected, waiting to reappear
2014.02.26 19:03:58 1: HMLAN_Parse: wz_HMLAN new condition disconnected
2014.02.26 19:06:03 1: 192.168.10.50:1000 reappeared (wz_HMLAN)
2014.02.26 19:06:03 1: HMLAN_Parse: wz_HMLAN new condition init
2014.02.26 19:06:03 1: HMLAN_Parse: wz_HMLAN new condition ok
2014.02.26 19:09:08 1: 192.168.10.50:1000 disconnected, waiting to reappear
2014.02.26 19:09:08 1: HMLAN_Parse: wz_HMLAN new condition disconnected
2014.02.26 19:11:13 1: 192.168.10.50:1000 reappeared (wz_HMLAN)
2014.02.26 19:11:13 1: HMLAN_Parse: wz_HMLAN new condition init
2014.02.26 19:11:13 1: HMLAN_Parse: wz_HMLAN new condition ok
2014.02.26 19:14:08 1: 192.168.10.50:1000 disconnected, waiting to reappear
2014.02.26 19:14:08 1: HMLAN_Parse: wz_HMLAN new condition disconnected
2014.02.26 19:17:17 1: 192.168.10.50:1000 reappeared (wz_HMLAN)
2014.02.26 19:17:17 1: HMLAN_Parse: wz_HMLAN new condition init
2014.02.26 19:17:17 1: HMLAN_Parse: wz_HMLAN new condition ok
... usw.
Sprich irgendwann disconnected sich der Adapter und und connected sich einige Minuten später wieder. Das kann doch so nicht normal sein? Ich habe den Adapter div. male neugestartet und an andere Knoten / Netzwerkpunkte gehängt.
Kann jemand dieses Verhalten auch bestätigen? Ich habe ein paar Einträge im Netz bezüglich Netzwerkproblemen gesehen, was ich bei mir ausschließen kann... Mit dem wdTimer Wert habe ich es zwischen 5 und 25 auch probiert.
Über Hinweise wäre ich sehr dankbar. Ansonsten muss ich wohl von einem Defekt ausgehen?
Gruß
Benni
das sollte er sicher nicht tun. Der Adapter muss mit keepalive alle 30sec am leben gehalten werden. FHEM sendet daher alle 25sec (default) einen trigger.
Was sagt ein list den HMLAN?
Gründe könnten sein
- schlechte LAN verbindung, messages gehen verloren
- überschreiten der 30sec keepalive
- HW defekt
- ethernet schlecht eingerichtet
List Ausgabe bei disconnect:
DEF 192.168.10.50:1000
DeviceName 192.168.10.50:1000
HM_CMDNR 49
NAME wz_HMLAN
NEXT_OPEN 1393442450.75722
NR 23
NTFY_ORDER 50-wz_HMLAN
PARTIAL
RAWMSG E2402EF,0000,02C5FF3A,FF,FFCF,1586102402EF0000000A78EB10002D
RSSI -49
STATE disconnected
TYPE HMLAN
XmitOpen 0
assignedIDs 250227,2402EF,238585
assignedIDsCnt 3
assignedIDsReport 0
firmware 0.961
msgKeepAlive dlyMax:11.511 bufferMin:13
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
msgParseDly min:-14 max:121 last:7 cnt:142
owner 2574EB
serialNr KEQ1023114
uptime 000 12:55:42.167
wz_HMLAN_MSGCNT 362
wz_HMLAN_TIME 2014-02-26 20:19:33
Readings:
2014-02-26 20:19:50 Xmit-Events disconnected:1
2014-02-26 20:19:50 cond disconnected
2014-02-26 20:19:50 prot_disconnected last
2014-02-26 20:14:55 prot_init last
2014-02-26 20:14:55 prot_ok last
2014-02-25 21:46:16 prot_timeout last
Assids:
238585 1
2402EF 1
250227 1
Helper:
assId 0
000001:
flg 0
msg
to 1393442097.55511
238585:
chn 02
flg 0
msg
name wz_Stehlampe
to 1393441448.71087
2402ef:
chn 86
flg 0
msg
name bz_Heizung
to 1393442221.41694
250227:
chn 01
flg 0
msg
name efl_Tuer
to 1393441481.28502
2574eb:
flg 0
Assids:
Dly:
cnt 142
lst 7
max 121
min -14
K:
BufMin 13
DlyMax 11.511
Next 1393442395.7541
Start 1393442390.7541
Log:
all 0
sys 0
ids:
ARRAY(0x1990570)
Q:
HMcndN 253
answerPend 0
hmLanQlen 1
keepAliveRec 0
keepAliveRpt 1
apIDs:
Cap:
0 0
1 12
2 0
3 0
4 0
5 0
last 1
sum 12
Ref:
drft 0
hmtL 46542167
kTs 1393442390754
offL 1393395843589
sysL 1393442385756
Attributes:
hmId 2574EB
hmKey 01:******************************
hmLanQlen 1_min
room Technik
wdTimer 5
List Ausgabe bei Connect:
Internals:
DEF 192.168.10.50:1000
DeviceName 192.168.10.50:1000
FD 11
HM_CMDNR 49
NAME wz_HMLAN
NR 23
NTFY_ORDER 50-wz_HMLAN
PARTIAL
RAWMSG E2402EF,0000,02C8280B,FF,FFCF,1686102402EF0000000A78EA10002D
RSSI -49
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDs 250227,2402EF,238585
assignedIDsCnt 3
assignedIDsReport 0
firmware 0.961
msgKeepAlive dlyMax:11.511 bufferMin:13
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
msgParseDly min:-14 max:121 last:7 cnt:142
owner 2574EB
serialNr KEQ1023114
uptime 000 12:59:38.533
wz_HMLAN_MSGCNT 363
wz_HMLAN_TIME 2014-02-26 20:21:57
Readings:
2014-02-26 20:21:57 Xmit-Events ok:1
2014-02-26 20:21:57 cond ok
2014-02-26 20:19:50 prot_disconnected last
2014-02-26 20:21:57 prot_init last
2014-02-26 20:21:57 prot_ok last
2014-02-25 21:46:16 prot_timeout last
Assids:
238585 1
2402EF 1
250227 1
Helper:
assId 0
000001:
flg 0
msg
to 1393442519.01913
238585:
chn 02
flg 0
msg
name wz_Stehlampe
to 1393441448.71087
2402ef:
chn 86
flg 0
msg
name bz_Heizung
to 1393442221.41694
250227:
chn 01
flg 0
msg
name efl_Tuer
to 1393441481.28502
2574eb:
flg 0
Assids:
Dly:
cnt 142
lst 7
max 121
min -14
K:
BufMin 13
DlyMax 11.511
Next 1393442627.09252
Start 1393442622.09252
Log:
all 0
sys 0
ids:
ARRAY(0x1990570)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
apIDs:
Cap:
0 0
1 0
2 1
3 0
4 0
5 0
last 2
sum 1
Ref:
drft -0.000199920031987205
hmtL 46778533
kTs 0
offL 1393395843562
sysL 1393442622095
Attributes:
hmId 2574EB
hmKey 01:******************
hmLanQlen 1_min
room Technik
wdTimer 5
Eine schlechte LAN Verbindung kann ich ausschließen, da alle anderen Dienste sehr performant funktionieren (Auch von diesem Server aus).
Den KeepAlive habe ich jetzt von 5-25 Sek mit div. Werten ausprobiert, ohne Veränderung...
Ethernet schlecht eingerichtet schließe ich auch mal aus, ich habe eine feste IP für den LAN Adapter vergeben und dieser ist dauerthaft via PING erreichbar mit einem Wert Zeit<1ms und das auch wenn der Adapter laut FHEM nicht erreichbar sein soll.
Also gehe ich jetzt von einem Defekt aus... Auch wenn ich es nicht wirklich verstehen kann, da ich den Adapter wie gesagt auch permanent pingen kann.
msgKeepAlive dlyMax:11.511 bufferMin:13
die 11 sec klingen nicht gut, aber du hast ja den wdTimer auf 5 gesetzt. Das sollte reichen.
evtl einmal die rohmessages loggen. Interessant ist auch, wer hier 11 sec bummelt. apptime probieren
IP-Adresse evtl. (doch) doppelt vergeben? (Hatten wir hier schon im Forum als Ursache mal gehabt - war das Tablett vom Sohn...).
Doppelt vergebene IP kann ich ausschließen, die habe ich schon gewechselt...
Was genau bedeutet der Wert "msgKeepAlive dlyMax" von 11 Sekunden? Müsste der eigentlich auf 5 stehen, oder was wäre hier der Zielwert?
Wie würde ich die "Rohmessages" loggen und was bedeutet apptime probieren?
rohmessages
http://forum.fhem.de/index.php/topic,16563.0.html
apptime siehe commandref
http://fhem.de/commandref.html#apptime
Ich habe genau das gleiche Problem:
2014.02.28 22:47:54 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 22:47:54 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 22:48:55 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 22:48:55 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 22:48:55 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 22:49:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 22:49:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 22:50:55 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 22:50:55 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 22:50:55 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 22:51:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 22:51:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 22:52:56 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 22:52:56 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 22:52:56 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 22:53:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 22:53:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 22:54:56 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 22:54:56 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 22:54:59 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 22:55:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 22:55:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 22:56:56 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 22:56:56 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 22:56:56 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 22:57:56 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 22:57:56 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 22:58:56 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 22:58:56 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 22:58:56 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 22:59:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 22:59:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 23:00:00 2: CUL_HM set Klingelbeleuchtung off
2014.02.28 23:00:58 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 23:00:58 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 23:00:58 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 23:01:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 23:01:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 23:02:58 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 23:02:58 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 23:02:58 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 23:03:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 23:03:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 23:04:58 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 23:04:58 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 23:04:58 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 23:05:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 23:05:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 23:06:58 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 23:06:58 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 23:06:58 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 23:07:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 23:07:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 23:08:58 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 23:08:58 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 23:08:58 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 23:09:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 23:09:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 23:10:58 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 23:10:58 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 23:10:58 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 23:11:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 23:11:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 23:12:56 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 23:12:56 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 23:12:56 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 23:13:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 23:13:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 23:13:56 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 23:13:56 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 23:13:56 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.28 23:14:55 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.02.28 23:14:55 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.28 23:14:57 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.02.28 23:14:57 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.28 23:15:01 1: HMLAN_Parse: HMLAN1 new condition ok
Würde ebenfalls sagen, dass ich Netzwerkprobleme ausschließen kann! Schließlich läuft der HMLAN schon 2 Monate ohne Probleme! Nun fängt ständig die linke LED an zu blinken, dann irgendwann leuchtet kurz die mittlere LED rot und der HMLAN ist wieder online. Dann geht das Spiel von vorne los!
List bei disconnect:
Internals:
DEF 192.168.188.222:1000
DeviceName 192.168.188.222:1000
HMLAN1_MSGCNT 121
HMLAN1_TIME 2014-02-28 23:26:19
HM_CMDNR 65
NAME HMLAN1
NEXT_OPEN 1393626475.49495
NR 102
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG R7A9AF718,0001,00013BA8,FF,FFDC,41800223D52523A6D70101C80025
RSSI -36
STATE disconnected
TYPE HMLAN
XmitOpen 0
assignedIDs 23D2DD,23D2DE,254DE7,24DBBB,23D525,206036,1D66E8
assignedIDsCnt 7
assignedIDsReport 3
firmware 0.961
msgKeepAlive dlyMax:10.542 bufferMin:-5
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
owner 23A6D7
serialNr KEQ0852411
uptime 000 00:01:24.461
Readings:
2014-02-28 23:26:55 Xmit-Events disconnected:1
2014-02-28 23:26:55 cond disconnected
2014-02-28 23:26:55 prot_disconnected last
2014-02-28 23:25:58 prot_init last
2014-02-28 00:07:31 prot_keepAlive last
2014-02-28 23:25:58 prot_ok last
Assids:
1D66E8 1
206036 1
23D2DD 1
23D2DE 1
23D525 1
24DBBB 1
254DE7 1
Helper:
assId 0
000001:
flg 0
msg
to 1393626360.54062
1d66e8:
chn 01
flg 0
msg
name Dimmer_Terasse
to 1393626378.93429
206036:
chn 02
flg 0
msg
name Hutschienenaktor
to 1393624860.46341
23a6d7:
flg 0
23d2dd:
chn 02
flg 0
msg
name Vase
to 1393626381.45552
23d2de:
chn 02
flg 0
msg
name Sideboard
to 1393626381.07937
23d525:
chn 02
flg 0
msg
name Vitrine
to 1393626381.7335
24dbbb:
chn 02
flg 0
msg
name Funk_Gong
to 1393621009.2885
254de7:
chn 01
flg 0
msg
name Garage_Aktor
to 1393621009.9087
Assids:
K:
BufMin -5
DlyMax 10.542
Next 1393626440.45279
Start 1393626415.45279
Log:
all 0
sys 0
ids:
ARRAY(0xdb7bf0)
Q:
HMcndN 253
answerPend 0
hmLanQlen 1
keepAliveRec 0
keepAliveRpt 1
apIDs:
Cap:
0 0
1 0
2 7
3 0
4 0
5 0
last 2
sum 7
Ref:
hmtL 84461
kTs 1393626415452
Attributes:
group System
hmId 23A6D7
hmKey 01:CE619E3197059B7751208CFFEED9E285
hmLanQlen 1_min
respTime 5
room System
wdTimer 25
List bei opened:
Internals:
DEF 192.168.188.222:1000
DeviceName 192.168.188.222:1000
FD 24
HMLAN1_MSGCNT 121
HMLAN1_TIME 2014-02-28 23:26:19
HM_CMDNR 65
NAME HMLAN1
NR 102
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG R7A9AF718,0001,00013BA8,FF,FFDC,41800223D52523A6D70101C80025
RSSI -36
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDs 23D2DD,23D2DE,254DE7,24DBBB,23D525,206036,1D66E8
assignedIDsCnt 7
assignedIDsReport 0
firmware 0.961
msgKeepAlive dlyMax:10.542 bufferMin:-5
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
owner 23A6D7
serialNr KEQ0852411
uptime 000 00:03:22.202
Readings:
2014-02-28 23:27:56 Xmit-Events ok:1
2014-02-28 23:27:56 cond ok
2014-02-28 23:26:55 prot_disconnected last
2014-02-28 23:27:56 prot_init last
2014-02-28 00:07:31 prot_keepAlive last
2014-02-28 23:27:56 prot_ok last
Assids:
1D66E8 1
206036 1
23D2DD 1
23D2DE 1
23D525 1
24DBBB 1
254DE7 1
Helper:
assId 0
000001:
flg 0
msg
to 1393626478.25174
1d66e8:
chn 01
flg 0
msg
name Dimmer_Terasse
to 1393626378.93429
206036:
chn 02
flg 0
msg
name Hutschienenaktor
to 1393624860.46341
23a6d7:
flg 0
23d2dd:
chn 02
flg 0
msg
name Vase
to 1393626381.45552
23d2de:
chn 02
flg 0
msg
name Sideboard
to 1393626381.07937
23d525:
chn 02
flg 0
msg
name Vitrine
to 1393626381.7335
24dbbb:
chn 02
flg 0
msg
name Funk_Gong
to 1393621009.2885
254de7:
chn 01
flg 0
msg
name Garage_Aktor
to 1393621009.9087
Assids:
K:
BufMin -5
DlyMax 10.542
Next 1393626526.26816
Start 1393626501.26816
Log:
all 0
sys 0
ids:
ARRAY(0xdb7bf0)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
apIDs:
Cap:
0 0
1 0
2 1
3 0
4 0
5 0
last 2
sum 1
Ref:
hmtL 202202
kTs 0
Attributes:
group System
hmId 23A6D7
hmKey 01:CE619E3197059B7751208CFFEED9E285
hmLanQlen 1_min
respTime 5
room System
wdTimer 25
ZitatmsgKeepAlive dlyMax:10.542 bufferMin:-5
das keepalive wurde max um 10.542sec verzoegert, was einen Puffer von -5sec ergibt. Nun, negativ heist, du warst zu spät.
Suche also, wer sich erlaubt, dein System für über 10 sec zu blockieren. Solche Delays sind voraussichtlich FHEM-intern.
Apptime koennte eine hinweis geben (siehe commandref).
Zitat von: martinp876 am 01 März 2014, 08:23:07
das keepalive wurde max um 10.542sec verzoegert, was einen Puffer von -5sec ergibt. Nun, negativ heist, du warst zu spät.
Suche also, wer sich erlaubt, dein System für über 10 sec zu blockieren. Solche Delays sind voraussichtlich FHEM-intern.
Apptime koennte eine hinweis geben (siehe commandref).
Ok!
Gerade mal Apptime gestartet! Mal heute Abend schauen, was es so aufgezeichnet hat.
Was ich komisch finde: Die ganze Nacht hat sich der HMLAN nicht neu connected, hat aber dann heut morgen wieder angefangen. Kann man damit darauf schließen, dass es sich um irgendein Programm handeln muss, das nachts nicht aktiv ist? Was meinst du genau mit FHEM-intern? Sollte ich mal die fhem.cfg nach Funktionen absuchen, die evtl. nicht richtig funktionieren? Oder können das auch Module sein, die den HMLAN ausbremsen?
2014.03.01 00:17:27 2: CUL_HM set Sideboard off
2014.03.01 00:17:27 2: CUL_HM set Vase off
2014.03.01 00:17:27 2: CUL_HM set Vitrine off
2014.03.01 01:00:00 2: CUL_HM set Sideboard off
2014.03.01 01:00:00 2: CUL_HM set Vase off
2014.03.01 01:00:00 2: CUL_HM set Vitrine off
2014.03.01 03:00:00 2: ENIGMA2 set Spark_One off
2014.03.01 06:12:00 2: CUL_HM set Lampe_Terasse on
2014.03.01 06:12:06 2: CUL_HM set Lampe_Terasse statusRequest
2014.03.01 06:13:30 2: CUL_HM set Lampe_Terasse off
2014.03.01 06:13:36 2: CUL_HM set Lampe_Terasse statusRequest
2014.03.01 06:18:33 2: CUL_HM set Sideboard on
2014.03.01 06:18:33 2: CUL_HM set Vase on
2014.03.01 06:18:33 2: CUL_HM set Vitrine on
2014.03.01 08:31:11 2: CUL_HM set Sideboard off
2014.03.01 08:31:11 2: CUL_HM set Vase off
2014.03.01 08:31:11 2: CUL_HM set Vitrine off
2014.03.01 09:42:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 09:42:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 09:43:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 09:43:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 09:43:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 09:44:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 09:44:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 09:45:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 09:45:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 09:45:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 09:46:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 09:46:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 09:47:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 09:47:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 09:47:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 09:48:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 09:48:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 09:49:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 09:49:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 09:49:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 09:50:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 09:50:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 09:51:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 09:51:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 09:51:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 09:52:13 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 09:52:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 09:53:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 09:53:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 09:53:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 09:54:15 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 09:54:15 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 09:55:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 09:55:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 09:55:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 09:56:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 09:56:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 09:57:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 09:57:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 09:57:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 09:58:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 09:58:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 09:59:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 09:59:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 09:59:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:00:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:00:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:01:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:01:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:01:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:02:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:02:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:03:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:03:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:03:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:03:43 1: HMLAN_Parse: HMLAN1 new condition timeout
2014.03.01 10:03:43 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:03:43 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:03:48 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:03:48 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:03:48 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:05:13 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:05:13 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:06:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:06:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:06:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:07:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:07:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:08:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:08:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:08:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:09:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:09:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:10:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:10:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:10:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:11:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:11:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:12:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:12:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:12:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:13:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:13:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:14:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:14:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:14:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:15:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:15:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:16:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:16:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:16:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:17:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:17:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:18:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:18:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:18:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:19:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:19:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:20:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:20:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:20:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:21:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:21:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:22:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:22:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:22:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:23:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:23:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:24:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:24:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:24:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:25:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:25:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:26:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:26:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:26:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:27:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:27:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:28:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:28:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:28:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:29:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:29:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:30:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:30:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:30:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:31:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:31:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:32:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:32:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:32:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:33:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:33:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:34:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:34:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:34:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:35:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:35:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:36:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:36:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:36:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:37:13 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:37:13 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:38:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:38:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:38:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:39:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:39:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:40:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:40:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:40:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:41:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:41:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:42:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:42:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:42:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:43:13 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:43:13 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:44:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:44:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:44:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:45:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:45:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:46:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:46:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:46:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:47:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:47:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:48:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:48:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:48:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:49:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:49:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:50:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:50:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:50:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:51:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:51:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:52:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:52:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:52:15 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:53:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:53:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:54:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:54:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:54:16 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:55:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:55:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:56:14 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:56:14 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:56:14 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:57:15 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:57:15 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 10:58:16 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 10:58:16 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 10:58:16 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 10:59:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 10:59:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 11:00:16 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 11:00:16 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 11:00:16 1: HMLAN_Parse: HMLAN1 new condition ok
Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 24.
Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 58.
2014.03.01 11:01:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 11:01:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 11:01:15 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 11:01:15 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 11:01:16 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.01 11:02:14 1: 192.168.188.222:1000 disconnected, waiting to reappear
2014.03.01 11:02:14 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.01 11:03:16 1: 192.168.188.222:1000 reappeared (HMLAN1)
2014.03.01 11:03:16 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.01 11:03:16 1: HMLAN_Parse: HMLAN1 new condition ok@Bdombrowsky: Hast du die Ursache bei dir gefunden?
Hier ein erster Auszug von Apptime:
name function max count total average maxDly
HMLAN1 HMLAN_Ready 52 171 263 1.54 0 HASH(0xd82ab8)
FileLog_Garagentor FileLog_Get 37 3 106 35.33 0 HASH(0xb5b3e8); FileLog_Garagentor; CURRENT; INT; 2014-02-28_00:00:00; 2014-03-02_00:00:01; 4:Garagentor.Torstatus\x3a::
FileLog_Klingeltaster FileLog_Get 28 3 83 27.67 0 HASH(0x141d880); FileLog_Klingeltaster; CURRENT; INT; 2014-02-28_00:00:00; 2014-03-02_00:00:01; 4:Klingeltaster.Klingelstatus\x3a::
HMLAN1 HMLAN_Read 23 18 202 11.22 0 HASH(0xd82ab8)
Alle_Steckdosen_EG structure_Set 22 5 104 20.80 0 HASH(0x1363a58); Alle_Steckdosen_EG; ?
FileLog_Raumtemperatur_Soll FileLog_Get 21 3 61 20.33 0 HASH(0x14a0068); FileLog_Raumtemperatur_Soll; CURRENT; INT; 2014-02-28_00:00:00; 2014-03-02_00:00:01; 4:Raumtemperatur_Soll.Temperatur\x3a::
tmr-Twilight_sunpos HASH(0x1d26120) 21 1 21 21.00 5 HASH(0x1d26120)
tmr-Twilight_sunpos HASH(0x1b45158) 16 1 16 16.00 507 HASH(0x1b45158)
tmr-ENIGMA2_GetStatus HASH(0x129e170) 11 9 70 7.78 299 HASH(0x129e170)
n_batt_chk notify_Exec 11 61 266 4.36 0 HASH(0x138bc30); HASH(0x129e170)
FileLog_Funkschnittstelle_Sicherungskasten FileLog_Set 10 4 37 9.25 0 HASH(0x1431a68); FileLog_Funkschnittstelle_Sicherungskasten; ?
FileLog_Garagentor FileLog_Set 10 3 28 9.33 0 HASH(0xb5b3e8); FileLog_Garagentor; ?
FileLog_Dimmer_Terasse FileLog_Set 9 4 36 9.00 0 HASH(0x14a16d0); FileLog_Dimmer_Terasse; ?
FileLog_Funk_Gong FileLog_Set 9 4 36 9.00 0 HASH(0x1431f48); FileLog_Funk_Gong; ?
FileLog_Garage_Aktor FileLog_Set 9 3 27 9.00 0 HASH(0xc82c40); FileLog_Garage_Aktor; ?
FileLog_Hutschienenaktor FileLog_Set 9 4 35 8.75 0 HASH(0xe072d8); FileLog_Hutschienenaktor; ?
FileLog_Klingeltaster FileLog_Set 9 3 27 9.00 0 HASH(0x141d880); FileLog_Klingeltaster; ?
FileLog_Raumtemperatur_Soll FileLog_Set 9 3 26 8.67 0 HASH(0x14a0068); FileLog_Raumtemperatur_Soll; ?
FileLog_Vitrine FileLog_Set 9 4 36 9.00 0 HASH(0x1363958); FileLog_Vitrine; ?
Logfile FileLog_Set 9 3 27 9.00 0 HASH(0xe074c0); Logfile; ?
tmr-FW_closeOldClients 9 9 36 4.00 168
Jetzt sieht Apptime so aus:
name function max count total average maxDly
eventTypes eventTypes_Define 4222 1 4222 4222.00 0 HASH(0x1363728); eventTypes eventTypes ./log/eventTypes.txt
DM500HD ENIGMA2_Define 2010 1 2010 2010.00 0 HASH(0x139d6e0); DM500HD ENIGMA2 192.168.188.33 80 60 root blendax3
Spark_One ENIGMA2_Define 2010 1 2010 2010.00 0 HASH(0x1363ad8); Spark_One ENIGMA2 192.168.188.11 80 60 root pkteam
tmr-CUL_HM_updateConfig updateConfig 601 1 601 601.00 5 updateConfig
tmr-Weather_GetUpdate HASH(0x70f960) 400 2 785 392.50 5 HASH(0x70f960)
HMLAN1 HMLAN_Read 374 1616 13312 8.24 0 HASH(0x14314e8)
tmr-Weather_GetUpdate HASH(0x208b2d0) 369 2 733 366.50 75 HASH(0x208b2d0)
MyWeather Weather_Define 358 1 358 358.00 0 HASH(0x70f960); MyWeather Weather 651465 3600 de
tmr-Twilight_Midnight HASH(0x1dfad10) 340 1 340 340.00 12430 HASH(0x1dfad10)
Forecast Weather_Define 320 1 320 320.00 0 HASH(0x208b2d0); Forecast Weather 651465 3600 de
BM_Terasse_Motion notify_Exec 224 29 446 15.38 0 HASH(0x1ab5a80); HASH(0x1d62130)
Klingelsignal notify_Exec 134 6 331 55.17 0 HASH(0x1b3cc70); HASH(0x1c68ac8)
WatchGaragentor notify_Exec 133 11 1388 126.18 0 HASH(0x141d550); HASH(0x2062eb0)
FileLog_Garagentor FileLog_Get 98 3 197 65.67 0 HASH(0x2063740); FileLog_Garagentor; CURRENT; INT; 2014-02-28_00:00:00; 2014-03-02_00:00:01; 4:Garagentor.Torstatus\x3a::
tmr-WeekdayTimer_Update HASH(0x12f8130) 86 1 86 86.00 1921 HASH(0x12f8130)
Lampe_Terasse CUL_HM_Set 69 40 461 11.53 0 HASH(0x196e860); Lampe_Terasse; 100; 30
WatchRaumtemperatur notify_Exec 66 1 66 66.00 0 HASH(0xf560a0); HASH(0x12f8130)
HMLAN1 HMLAN_Define 63 1 63 63.00 0 HASH(0x14314e8); HMLAN1 HMLAN 192.168.188.222:1000
n_batt_chk notify_Exec 61 249 946 3.80 0 HASH(0x2073050); HASH(0x1363ad8)
HMLAN1 HMLAN_Ready 54 1 54 54.00 0 HASH(0x14314e8)
FileLog_Klingeltaster FileLog_Get 53 3 129 43.00 0 HASH(0x1a70a08); FileLog_Klingeltaster; CURRENT; INT; 2014-02-28_00:00:00; 2014-03-02_00:00:01; 4:Klingeltaster.Klingelstatus\x3a::
Ich habe inzwischen wdtimer auf 5 gesetzt (vorher 25) und jetzt habe ich keine disconnects mehr. Kann ich das denn so lassen oder ist das nicht empfehlenswert?
Was kann/soll ich sonst machen?
ZitatIch habe inzwischen wdtimer auf 5 gesetzt (vorher 25) und jetzt habe ich keine disconnects mehr. Kann ich das denn so lassen oder ist das nicht empfehlenswert?
Was kann/soll ich sonst machen?
empfehlenswert ist, die verzögrungen in deinem system zu identifizieren, und dann, wenn möglich, zu eleminieren.
mit der einstellung wdtimer 5, erreichst du nur, dass trotz deiner bisherigen systemverzögerungen der keep-alive noch rechtzeitig gesendet wird. deine verzögerungen behälst du bei. fhem ist während der verzögerungen lahmgelegt. die 5-fach häufigeren keep-alives belasten dein system nun zusätzlich.
wenn dir das reicht, ok! gut und normal ist das nicht.
ich habe meine verzögerungen sehr gut hiermit identifizieren können: http://forum.fhem.de/index.php/topic,16347.msg106295.html#msg106295 (http://forum.fhem.de/index.php/topic,16347.msg106295.html#msg106295)
gruss frank
Kann denn jmd von Euch in meinem Apptime-Post einen möglichen Verursacher entdecken?
Was könnte alles zu Verzögerungen führen?
Soll ich mal meine komplette cfg posten?
an deinen apptime-aufzeichnungen sind die ersten drei zeilen erwähnenswert. die funktion eventTypes wurde 1 mal ausgeführt und verursachte 4222 milisec verzögerung. ob die zeit normal ist weiss ich nicht. aber 1 mal ausgeführt, kann das keine ursache für dauernde verzögerungen sein.
ebenso die nächsten zwei zeilen.
auffällig wären regelmässige verzögerungen, grösseren aussmasses.
hast du mal meinen vorschlag probiert?
gruss frank.
Die grossen Verzögerungen sind im Aufnahmezeitraum nur einmal aufgetreten. Wenn das nicht häufiger kommt kann es nicht z regelmäßigen Ausfälle führen
Interessant sind auch die 12 sec:
tmr-Twilight_Midnight HASH(0x1dfad10) 340 1 340 340.00 12430 HASH(0x1dfad10)
du kannst apptime maxDly eingeben, dann sortiert es entsprechend. Vielleicht gibt es noch mehr kritische im MaxDly bereich.
=> wenn es keine langläufer in FHEM gibt und die Verzögerungen anhalten muss der Übertäter außerhalb sitzen. Dann wird es komplexer.
Hier mal mit "Apptime maxDly":
name function max count total average maxDly
tmr-Twilight_fireEvent HASH(0x21115e8) 4 1 4 4.00 33398019 HASH(0x21115e8)
tmr-Twilight_fireEvent HASH(0x2362bd8) 3 1 3 3.00 31092782 HASH(0x2362bd8)
tmr-Twilight_fireEvent HASH(0x222d090) 4 1 4 4.00 28803640 HASH(0x222d090)
tmr-Twilight_fireEvent HASH(0xf5a4e0) 4 1 4 4.00 26491361 HASH(0xf5a4e0)
tmr-Twilight_fireEvent HASH(0x1ec6a30) 4 1 4 4.00 26100862 HASH(0x1ec6a30)
tmr-Twilight_fireEvent HASH(0x1c9da50) 4 1 4 4.00 24516131 HASH(0x1c9da50)
tmr-HttpUtils_ConnErr HASH(0x19c35e8) 0 1 0 0.00 28138
tmr-HttpUtils_ReadErr HASH(0x19c35e8) 0 1 0 0.00 28133
tmr-HttpUtils_ConnErr HASH(0x2405c70) 0 1 0 0.00 28012
tmr-HttpUtils_ConnErr HASH(0x192a450) 0 1 0 0.00 28003
tmr-HttpUtils_ConnErr HASH(0x2143768) 0 1 0 0.00 27998
tmr-HttpUtils_ConnErr HASH(0x14cb6a8) 0 1 0 0.00 27993
tmr-HttpUtils_ConnErr HASH(0x23bd2a8) 0 1 0 0.00 27988
tmr-HttpUtils_ConnErr HASH(0x2425168) 0 1 0 0.00 27983
tmr-HttpUtils_ConnErr HASH(0x199aff0) 0 1 0 0.00 27977
tmr-HttpUtils_ReadErr HASH(0x192a450) 0 1 0 0.00 27948
tmr-HttpUtils_ReadErr HASH(0x14cb6a8) 0 1 0 0.00 27947
tmr-HttpUtils_ReadErr HASH(0x2425168) 0 1 0 0.00 27947
tmr-HttpUtils_ReadErr HASH(0x2405c70) 0 1 0 0.00 27945
tmr-HttpUtils_ReadErr HASH(0x199aff0) 0 1 0 0.00 27944
tmr-HttpUtils_ReadErr HASH(0x23bd2a8) 0 1 0 0.00 27944
@Frank: Werde das Modul gleich mal installieren.
das sieht wohl ziehmlich eindeutig aus. :o
da werden viele http zugriffe gemacht mit fiesen maxDly werten. wahrscheinlich nicht zu erreichen. oder alles überschneidet sich. mit dem anderen modul kannst du dann ganz genau erkennen, welches modul zu welcher zeit mit welcher resultierenden verzögerung einen aufruf startet. dein twilight wohl auch.
gruss frank
Also ich habe jetzt mal das PerfMon Modul installiert und so wie es aussieht, ist das ENIGMA Modul schuld.
Das Modul scheint minütlich die komplette Sender- und Timerliste und einige weitere Readings vom Receiver abzufragen. Das dauert dann recht lange. Verstehe ich nicht, warum das sein muss. Senderliste würde doch reichen, die einmal am Tag auszulesen. Wenn es da kein Update gibt, bleibt wohl nix anderers übrig, als das Modul wieder rauzuschmeißen.
Wieso macht das Twilight denn solche Sachen? Hier alles aus der cfg, was das twilight Modul betrifft:
define Twilight Twilight 50.9833 6.0 1 651465
attr Twilight group Umwelt
attr Twilight room Haus
attr Twilight stateFormat light
In folgendem Logauszug passt das aber irgendwie nicht zusammen! Da soll ein Freeze von etwas ausgelöst worden sein, das um 16:36:58 stattgefunden hat. Da war aber garnix?!?!?
2014.03.02 16:36:54.492 4: HTTP FHEMWEB:192.168.188.177:58912 GET /fhem/pgm2/style.css
2014.03.02 16:36:54.499 4: HTTP FHEMWEB:192.168.188.177:58911 GET /fhem/pgm2/dashboard.js
2014.03.02 16:36:54.506 4: HTTP FHEMWEB:192.168.188.177:58910 GET /fhem/pgm2/jquery.min.js
2014.03.02 16:36:54.512 4: HTTP FHEMWEB:192.168.188.177:58913 GET /fhem/pgm2/jquery-ui.min.js
2014.03.02 16:36:54.518 4: HTTP FHEMWEB:192.168.188.177:58907 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.03.02 16:36:54.523 4: HTTP FHEMWEB:192.168.188.177:58912 GET /fhem/pgm2/fhemweb.js
2014.03.02 16:36:54.530 4: Connection accepted from FHEMWEB:192.168.188.177:58914
2014.03.02 16:36:54.532 4: HTTP FHEMWEB:192.168.188.177:58911 GET /fhem/pgm2/fhemweb_multiple.js
2014.03.02 16:36:54.538 4: HTTP FHEMWEB:192.168.188.177:58910 GET /fhem/pgm2/fhemweb_noArg.js
2014.03.02 16:36:54.545 4: HTTP FHEMWEB:192.168.188.177:58907 GET /fhem/pgm2/fhemweb_svg.js
2014.03.02 16:36:54.550 4: HTTP FHEMWEB:192.168.188.177:58912 GET /fhem/pgm2/fhemweb_textField.js
2014.03.02 16:36:54.555 4: HTTP FHEMWEB:192.168.188.177:58911 GET /fhem/pgm2/fhemweb_time.js
2014.03.02 16:36:54.561 4: HTTP FHEMWEB:192.168.188.177:58910 GET /fhem/pgm2/dashboard_darkstyle.css
2014.03.02 16:36:54.567 4: HTTP FHEMWEB:192.168.188.177:58914 GET /fhem/pgm2/svg.js
2014.03.02 16:36:54.572 4: HTTP FHEMWEB:192.168.188.177:58913 GET /fhem/pgm2/fhemweb_slider.js
2014.03.02 16:36:54.578 4: HTTP FHEMWEB:192.168.188.177:58907 GET /fhem/icons/favicon
2014.03.02 16:36:54.653 4: HTTP FHEMWEB:192.168.188.177:58907 GET /fhem/images/default/icoHaus.png
2014.03.02 16:36:54.660 4: HTTP FHEMWEB:192.168.188.177:58912 GET /fhem/images/default/icoEverything.png
2014.03.02 16:36:54.665 4: HTTP FHEMWEB:192.168.188.177:58911 GET /fhem/images/default/fhemicon_dark.png
2014.03.02 16:36:54.770 4: HTTP FHEMWEB:192.168.188.177:58907 GET /fhem?XHR=1&inform=type=status;filter=room=Logs×tamp=1393774643083
2014.03.02 16:36:57.608 4: Connection closed for FHEMWEB:192.168.188.177:58907
2014.03.02 16:36:57.612 4: HTTP FHEMWEB:192.168.188.177:58912 GET /fhem/FileLog_logWrapper&dev=Logfile&type=text&file=fhem-2014-03.log
2014.03.02 16:37:04.109 1: Perfmon: possible freeze starting at 16:36:58, delay is 6.107
ZitatWieso macht das Twilight denn solche Sachen? Hier alles aus der cfg, was das twilight Modul betrifft:
define Twilight Twilight 50.9833 6.0 1 651465
vielleicht die namensgleichheit! ;)
ansonsten bei yahoo mal schauen ob die wetterseite (651465) noch stimmt.
gruss frank
Habs mal in "My_Twilight" geändert.
Die Wetter-ID stimmt noch.
perform misst eine verzoegerung eines 1-sec timers - wenn der delay groesser 1 sec ist wird es geloggt.
Apptime macht keinen log bei entsprechenden events, zeigt aber alle delays zu real aktiven timern.
Apptime hat delays von ueber 30 sec in mehrere Faellen festgestellt, aber keine einzelne Prozedur, die eine entsprechende Laufzeit hat. Der FHEM-kernal sollte einen solchen delays erzeugen. Damit tippe ich auf eine FHEM-externe Application, was auch durch den letzten Log untermauert wird.
Wie ist den die Auslastung deiner CPU?
Hallo zusammen,
hier mal meine Beobachtungen zum Thema.
Ich betreibe FHEM an einer FB7390 mit dem Image aus dem Fhem Projekt. Habe inzwischen hauptsächlich Rolladenaktoren in Betrieb. Nach ersten Versuchen und fortschreitendem Montagestand habe ich vom CUL auf HMLAN umgestellt, weil einige Aktoren schlecht, bzw. gar nicht erreichbar waren. Mit dem HMLAN hat sich die Funksituation verbessert (bessere RSSI-Werte) .
Allerdings sind mir deutliche Verzögerungen bei den Reaktionen der Aktoren auf die Befehle aus dem Webgui aufgefallen. Im Log hatte ich ebenfalls diese hier beschriebennen Aussetzer.
2014.03.05 17:00:46.664 2: CUL_HM set EG_Roll_Kueche2 statusRequest
2014.03.05 17:01:21.205 1: HMLAN_Parse: HMLAN1 new condition timeout
2014.03.05 17:01:21.213 1: 172.16.2.43:1000 disconnected, waiting to reappear
2014.03.05 17:01:21.216 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.05 17:02:32.909 1: 172.16.2.43:1000 reappeared (HMLAN1)
2014.03.05 17:02:32.918 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.05 17:02:32.979 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.05 17:02:41.828 2: CUL_HM set EG_Roll_EZ1 statusRequest
2014.03.05 17:02:46.823 2: CUL_HM set EG_Roll_Kueche1 statusRequest
2014.03.05 17:02:47.860 2: CUL_HM set EG_Roll_Kueche2 statusRequest
2014.03.05 17:04:43.027 2: CUL_HM set EG_Roll_EZ1 statusRequest
2014.03.05 17:04:48.019 2: CUL_HM set EG_Roll_Kueche1 statusRequest
2014.03.05 17:04:49.056 2: CUL_HM set EG_Roll_Kueche2 statusRequest
2014.03.05 17:05:31.993 1: HMLAN_Parse: HMLAN1 new condition timeout
2014.03.05 17:05:32.000 1: 172.16.2.43:1000 disconnected, waiting to reappear
2014.03.05 17:05:32.004 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.05 17:05:37.029 1: 172.16.2.43:1000 reappeared (HMLAN1)
2014.03.05 17:05:37.037 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.05 17:05:37.074 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.05 17:06:44.236 2: CUL_HM set EG_Roll_EZ1 statusRequest
2014.03.05 17:06:49.218 2: CUL_HM set EG_Roll_Kueche1 statusRequest
2014.03.05 17:06:50.256 2: CUL_HM set EG_Roll_Kueche2 statusRequest
2014.03.05 17:08:45.432 2: CUL_HM set EG_Roll_EZ1 statusRequest
Mit den hier beschriebenen Methoden konnte 99_perfmon.pm und apptime konnte ich nicht wirklich einen "Schuldigen" ausmachen. Habe dieses Problem aber erstmal zurückgestellt weil ich noch einen Rollenaktor hatte, den ich per FHEM nicht ansprechen konnte. Der Aktor war mal richtig angelernt und hat auch auf FHEM Befehle reagiert. Aber, warum auch immer er tat's nicht mehr. Ich ging schon von einem Defekt aus, habe aber sicherheitshalber noch mal die Anlerntaste gedrückt und angelernt mit set HMLAN1 hmPairSerial KEQXXXXXXX . Was soll ich sagen, der Aktor funktioniert und meine Unterbrechungen sind auch weg. Das Modul perfmon mäkelt zwar gelegengtlich, aber alles ist gut.
2014.03.06 12:30:55.472 0: Server shutdown
2014.03.06 12:30:59.252 1: Including fhem.cfg
2014.03.06 12:31:00.245 2: Perfmon: ready to watch out for delays greater than one second
2014.03.06 12:31:00.386 3: telnetPort: port 7072 opened
2014.03.06 12:31:01.431 3: WEB: port 8083 opened
2014.03.06 12:31:01.439 3: WEBphone: port 8084 opened
2014.03.06 12:31:01.450 3: WEBtablet: port 8085 opened
2014.03.06 12:31:02.149 2: eventTypes: loaded 1545 events from ./log/eventTypes.txt
2014.03.06 12:31:02.455 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.06 12:31:02.458 3: Opening HMLAN1 device 172.16.2.43:1000
2014.03.06 12:31:02.502 3: HMLAN1 device opened
2014.03.06 12:31:02.508 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.06 12:31:02.596 3: Opening fritzbox device fritz.box:2002
2014.03.06 12:31:02.606 3: fritzbox device opened
2014.03.06 12:31:02.612 1: FBAHA fritzbox registered with handle: 0000000a
2014.03.06 12:31:07.178 1: Including ./log/fhem.save
2014.03.06 12:31:08.160 1: usb create starting
2014.03.06 12:31:08.890 1: usb create end
2014.03.06 12:31:08.894 2: Werner's Spielwiese
2014.03.06 12:31:08.896 0: Server started with 92 defined entities (version $Id: fhem.pl 5126 2014-03-04 16:27:09Z rudolfkoenig $, os linux, user boxusr99, pid 2737)
2014.03.06 12:31:08.899 1: Perfmon: possible freeze starting at 12:31:01, delay is 7.898
2014.03.06 12:31:08.914 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.06 12:31:11.536 3: Device OG_HZ_Bad added to ActionDetector with 000:10 time
2014.03.06 12:31:11.693 3: Device UG_HZ_ELW added to ActionDetector with 000:10 time
2014.03.06 12:31:12.845 2: CUL_HM set EG_Dimmer_WZ statusRequest
2014.03.06 12:31:13.866 2: CUL_HM set EG_Roll_EZ1 statusRequest
2014.03.06 12:31:14.883 2: CUL_HM set EG_Roll_EZ2 statusRequest
2014.03.06 12:31:15.901 2: CUL_HM set EG_Roll_Erker1 statusRequest
2014.03.06 12:31:16.919 2: CUL_HM set EG_Roll_Erker2 statusRequest
2014.03.06 12:31:17.937 2: CUL_HM set EG_Roll_Erker3 statusRequest
2014.03.06 12:31:18.955 2: CUL_HM set EG_Roll_Kueche1 statusRequest
2014.03.06 12:31:19.974 2: CUL_HM set EG_Roll_Kueche2 statusRequest
2014.03.06 12:31:20.991 2: CUL_HM set EG_Roll_WZ statusRequest
2014.03.06 12:31:22.006 2: CUL_HM set HM_Schaltsteckdose1 statusRequest
2014.03.06 12:31:23.023 2: CUL_HM set OG_Licht_Buero statusRequest
2014.03.06 12:31:24.040 2: CUL_HM set UG_Roll_Kueche statusRequest
2014.03.06 13:20:35.473 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2014.03.06 13:20:37.046 1: Perfmon: possible freeze starting at 13:20:36, delay is 1.045
2014.03.06 18:11:43.014 2: CUL_HM set HM_Schaltsteckdose1 on
2014.03.06 18:59:14.015 2: CUL_HM set EG_Roll_EZ1 off
2014.03.06 18:59:14.035 2: CUL_HM set EG_Roll_Erker1 off
2014.03.06 18:59:14.049 2: CUL_HM set EG_Roll_Erker2 off
2014.03.06 18:59:14.063 2: CUL_HM set EG_Roll_Erker3 off
2014.03.06 18:59:14.076 2: CUL_HM set EG_Roll_Kueche1 off
2014.03.06 18:59:14.089 2: CUL_HM set EG_Roll_Kueche2 off
2014.03.06 18:59:14.102 2: CUL_HM set EG_Roll_WZ off
2014.03.06 18:59:14.115 2: CUL_HM set UG_Roll_Kueche off
Hier habe ich mal ein update force angestossen, danach geht es aber normal weiter. Alles ist gut.
2014.03.06 19:52:25.775 1: update 1171 file(s) have been updated.
2014.03.06 19:52:25.840 1: update A new version of fhem.pl was installed, 'shutdown restart' is required!
2014.03.06 20:14:42.562 0: Server shutdown
2014.03.06 20:14:46.762 1: Including fhem.cfg
2014.03.06 20:14:47.804 2: Perfmon: ready to watch out for delays greater than one second
2014.03.06 20:14:47.954 3: telnetPort: port 7072 opened
2014.03.06 20:14:49.497 3: WEB: port 8083 opened
2014.03.06 20:14:49.505 3: WEBphone: port 8084 opened
2014.03.06 20:14:49.515 3: WEBtablet: port 8085 opened
2014.03.06 20:14:50.256 2: eventTypes: loaded 1545 events from ./log/eventTypes.txt
2014.03.06 20:14:50.575 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.06 20:14:50.579 3: Opening HMLAN1 device 172.16.2.43:1000
2014.03.06 20:14:50.625 3: HMLAN1 device opened
2014.03.06 20:14:50.632 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.06 20:14:50.723 3: Opening fritzbox device fritz.box:2002
2014.03.06 20:14:50.763 3: fritzbox device opened
2014.03.06 20:14:50.785 1: FBAHA fritzbox registered with handle: 0000000b
2014.03.06 20:14:55.849 1: Including ./log/fhem.save
2014.03.06 20:14:56.864 1: usb create starting
2014.03.06 20:14:57.615 1: usb create end
2014.03.06 20:14:57.619 2: Werner's Spielwiese
2014.03.06 20:14:57.621 0: Server started with 92 defined entities (version $Id: fhem.pl 5126 2014-03-04 16:27:09Z rudolfkoenig $, os linux, user boxusr99, pid 2923)
2014.03.06 20:14:57.625 1: Perfmon: possible freeze starting at 20:14:48, delay is 9.623
2014.03.06 20:14:57.641 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.06 20:15:00.143 3: Device OG_HZ_Bad added to ActionDetector with 000:10 time
2014.03.06 20:15:00.299 3: Device UG_HZ_ELW added to ActionDetector with 000:10 time
2014.03.06 20:15:01.464 2: CUL_HM set EG_Dimmer_WZ statusRequest
2014.03.06 20:15:02.486 2: CUL_HM set EG_Roll_EZ1 statusRequest
2014.03.06 20:15:03.504 2: CUL_HM set EG_Roll_EZ2 statusRequest
2014.03.06 20:15:04.522 2: CUL_HM set EG_Roll_Erker1 statusRequest
2014.03.06 20:15:05.540 2: CUL_HM set EG_Roll_Erker2 statusRequest
2014.03.06 20:15:06.558 2: CUL_HM set EG_Roll_Erker3 statusRequest
2014.03.06 20:15:07.575 2: CUL_HM set EG_Roll_Kueche1 statusRequest
2014.03.06 20:15:08.593 2: CUL_HM set EG_Roll_Kueche2 statusRequest
2014.03.06 20:15:09.611 2: CUL_HM set EG_Roll_WZ statusRequest
2014.03.06 20:15:10.629 2: CUL_HM set HM_Schaltsteckdose1 statusRequest
2014.03.06 20:15:11.647 2: CUL_HM set OG_Licht_Buero statusRequest
2014.03.06 20:15:12.665 2: CUL_HM set UG_Roll_Kueche statusRequest
2014.03.06 20:19:11.309 1: Perfmon: possible freeze starting at 20:19:10, delay is 1.308
2014.03.06 20:41:28.348 1: Perfmon: possible freeze starting at 20:41:26, delay is 2.347
Vielleicht hilft es ja jemandem weiter.
Gruß Werner
Hallo,
ich bin neu im Thema fhem und Heimautomatisierung generell.
Leider habe ich das Problem mit den Dis/connects auch.
Als blutiger Anfänger bin noch nicht über ein Setup mit fhem und HMLAN hinaus gekommen ;D
Sprich meine fhem.cfg ist entsprechend minimal.
#attr global logfile ./log/fhem-%Y-%m.log
attr global logfile -
attr global modpath .
attr global motd none
attr global statefile ./log/fhem.save
attr global verbose 5
attr global updateInBackground 1
define telnetPort telnet 7072 global
#define HM HMinfo
# set HM help
define HMLAN1 HMLAN 192.168.0.6:1000
attr HMLAN1 hmId 2576E2
define WEB FHEMWEB 8083 global
define WEBphone FHEMWEB 8084 global
# attr WEBphone stylesheetPrefix smallscreen
attr WEBphone stylesheetPrefix ios7
define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix ios7
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log
define eventTypes eventTypes ./log/eventTypes.txt
Das HMLAN hängt am gleichen Switch wie das QNAP NAS. Der Switch verbindet via Powerline zum Kabelmodem/Router. Im Netz gibts noch ein Canon Drucker, zwei Macbook's, iPhones und iPads als auch ein AppleTV.
Was mich jedoch noch erstaunt hat ist, dass das HMLAN nur eine Verbindung vom fhem zulässt wenn AES aktiviert ist?
ping zum HMLAN ist denke ich ok:
[~] # ping 192.168.0.6
PING 192.168.0.6 (192.168.0.6): 56 data bytes
64 bytes from 192.168.0.6: icmp_seq=0 ttl=128 time=1.9 ms
64 bytes from 192.168.0.6: icmp_seq=1 ttl=128 time=0.3 ms
64 bytes from 192.168.0.6: icmp_seq=2 ttl=128 time=0.3 ms
64 bytes from 192.168.0.6: icmp_seq=3 ttl=128 time=0.4 ms
64 bytes from 192.168.0.6: icmp_seq=4 ttl=128 time=0.3 ms
64 bytes from 192.168.0.6: icmp_seq=5 ttl=128 time=0.4 ms
64 bytes from 192.168.0.6: icmp_seq=6 ttl=128 time=0.4 ms
64 bytes from 192.168.0.6: icmp_seq=7 ttl=128 time=0.3 ms
Die Disconnect/Connect Sequenzen laufen immer gleich ab, wodurch ich hier nur ein Ausschnit aus dem Log poste.
014.03.07 13:29:32 1: Including fhem-hmlan.cfg
2014.03.07 13:29:32 5: Cmd: >attr global logfile -<
2014.03.07 13:29:32 5: Cmd: >attr global modpath .<
2014.03.07 13:29:32 5: Loading ./FHEM/99_SUNRISE_EL.pm
2014.03.07 13:29:33 5: Loading ./FHEM/99_Utils.pm
2014.03.07 13:29:33 5: Cmd: >attr global motd none<
2014.03.07 13:29:33 5: Cmd: >attr global statefile ./log/fhem.save<
2014.03.07 13:29:33 5: Cmd: >attr global verbose 5<
2014.03.07 13:29:33 5: Cmd: >attr global updateInBackground 1<
2014.03.07 13:29:33 5: Cmd: >define telnetPort telnet 7072 global<
2014.03.07 13:29:33 5: Loading ./FHEM/98_telnet.pm
2014.03.07 13:29:33 3: telnetPort: port 7072 opened
2014.03.07 13:29:33 5: Cmd: >define HMLAN1 HMLAN 192.168.0.6:1000<
2014.03.07 13:29:33 5: Loading ./FHEM/00_HMLAN.pm
2014.03.07 13:29:33 2: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.07 13:29:33 3: Opening HMLAN1 device 192.168.0.6:1000
2014.03.07 13:29:33 3: HMLAN1 device opened
2014.03.07 13:29:33 5: HMLAN_Send: HMLAN1 I:C
2014.03.07 13:29:33 5: HMLAN_Send: HMLAN1 I:Y01,00,
2014.03.07 13:29:33 5: HMLAN_Send: HMLAN1 I:Y02,00,
2014.03.07 13:29:33 5: HMLAN_Send: HMLAN1 I:Y03,00,
2014.03.07 13:29:33 5: HMLAN_Send: HMLAN1 I:T1AAC6A1D,04,00,00000000
2014.03.07 13:29:33 2: HMLAN_Parse: HMLAN1 new condition init
2014.03.07 13:29:33 5: Cmd: >attr HMLAN1 hmId 2576E2<
2014.03.07 13:29:33 5: Cmd: >define WEB FHEMWEB 8083 global<
2014.03.07 13:29:33 5: Loading ./FHEM/01_FHEMWEB.pm
2014.03.07 13:29:33 3: WEB: port 8083 opened
2014.03.07 13:29:33 5: Cmd: >define WEBphone FHEMWEB 8084 global<
2014.03.07 13:29:33 3: WEBphone: port 8084 opened
2014.03.07 13:29:33 5: Cmd: >attr WEBphone stylesheetPrefix ios7<
2014.03.07 13:29:33 5: Cmd: >define WEBtablet FHEMWEB 8085 global<
2014.03.07 13:29:33 3: WEBtablet: port 8085 opened
2014.03.07 13:29:33 5: Cmd: >attr WEBtablet stylesheetPrefix ios7<
2014.03.07 13:29:33 5: Cmd: >define Logfile FileLog ./log/fhem-%Y-%m.log fakelog<
2014.03.07 13:29:33 5: Loading ./FHEM/92_FileLog.pm
2014.03.07 13:29:33 5: Cmd: >define autocreate autocreate<
2014.03.07 13:29:33 5: Loading ./FHEM/98_autocreate.pm
2014.03.07 13:29:33 5: Cmd: >attr autocreate filelog ./log/%NAME-%Y.log<
2014.03.07 13:29:33 5: Cmd: >define eventTypes eventTypes ./log/eventTypes.txt<
2014.03.07 13:29:33 5: Loading ./FHEM/91_eventTypes.pm
2014.03.07 13:29:33 1: Including ./log/fhem.save
2014.03.07 13:29:33 5: Cmd: >setstate HMLAN1 opened<
2014.03.07 13:29:33 5: Cmd: >setstate HMLAN1 2014-03-07 12:03:02 Xmit-Events init:1<
2014.03.07 13:29:33 5: Cmd: >setstate HMLAN1 2014-03-07 12:03:02 cond init<
2014.03.07 13:29:33 5: Cmd: >setstate HMLAN1 2014-03-07 12:03:02 prot_disconnected last<
2014.03.07 13:29:33 5: Cmd: >setstate HMLAN1 2014-03-07 12:03:02 prot_init last<
2014.03.07 13:29:33 5: Cmd: >setstate Logfile active<
2014.03.07 13:29:33 5: Cmd: >setstate autocreate active<
2014.03.07 13:29:33 5: Cmd: >setstate eventTypes active<
2014.03.07 13:29:33 5: Cmd: >setstate global <no definition><
2014.03.07 13:29:33 5: Interface "interface": readings "", getters "", setters ""
2014.03.07 13:29:33 5: Interface "switch": readings "onoff", getters "onoff", setters ""
2014.03.07 13:29:33 5: Interface "switch_active": readings "onoff", getters "onoff", setters ""
2014.03.07 13:29:33 5: Interface "switch_passive": readings "onoff", getters "onoff", setters "on:off"
2014.03.07 13:29:33 5: Interface "dimmer": readings "onoff:level", getters "onoff:level", setters "on:off:dimto:dimup:dimdown"
2014.03.07 13:29:33 5: Interface "temperature": readings "temperature", getters "temperature", setters ""
2014.03.07 13:29:33 5: Interface "humidity": readings "humidity", getters "humidity", setters ""
2014.03.07 13:29:33 5: Interface "wind": readings "wind", getters "wind", setters ""
2014.03.07 13:29:33 5: Interface "power": readings "power:maxPower:energy", getters "power:maxPower:energy", setters ""
2014.03.07 13:29:33 5: Triggering global (1 changes)
2014.03.07 13:29:33 5: Notify loop for global INITIALIZED
2014.03.07 13:29:33 4: eventTypes: Global global INITIALIZED -> INITIALIZED
2014.03.07 13:29:33 0: Server started with 9 defined entities (version $Id: fhem.pl 3872 2013-09-07 11:58:33Z rudolfkoenig $, os linux, user admin, pid 24826)
2014.03.07 13:29:33 5: HMLAN1 Unknown msg >V1309040241201008AA552A150A050201<
2014.03.07 13:29:58 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:29:59 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:30:00 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:30:01 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:30:02 1: 192.168.0.6:1000 disconnected, waiting to reappear
2014.03.07 13:30:02 5: Triggering HMLAN1 (1 changes)
2014.03.07 13:30:02 5: Notify loop for HMLAN1 DISCONNECTED
2014.03.07 13:30:02 4: eventTypes: HMLAN HMLAN1 DISCONNECTED -> DISCONNECTED
2014.03.07 13:30:02 2: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.07 13:30:02 5: Triggering HMLAN1 (3 changes)
2014.03.07 13:30:02 5: Notify loop for HMLAN1 cond: disconnected
2014.03.07 13:30:02 4: eventTypes: HMLAN HMLAN1 cond: disconnected -> cond: disconnected
2014.03.07 13:30:02 4: eventTypes: HMLAN HMLAN1 Xmit-Events: disconnected:1 -> Xmit-Events: disconnected:.*
2014.03.07 13:30:02 4: eventTypes: HMLAN HMLAN1 prot_disconnected: last -> prot_disconnected: last
2014.03.07 13:30:07 1: 192.168.0.6:1000 reappeared (HMLAN1)
2014.03.07 13:30:07 5: HMLAN_Send: HMLAN1 I:A2576E2
2014.03.07 13:30:07 5: HMLAN_Send: HMLAN1 I:C
2014.03.07 13:30:07 5: HMLAN_Send: HMLAN1 I:Y01,00,
2014.03.07 13:30:07 5: HMLAN_Send: HMLAN1 I:Y02,00,
2014.03.07 13:30:07 5: HMLAN_Send: HMLAN1 I:Y03,00,
2014.03.07 13:30:07 5: HMLAN_Send: HMLAN1 I:T1AAC6A3F,04,00,00000000
2014.03.07 13:30:07 2: HMLAN_Parse: HMLAN1 new condition init
2014.03.07 13:30:07 5: Triggering HMLAN1 (3 changes)
2014.03.07 13:30:07 5: Notify loop for HMLAN1 cond: init
2014.03.07 13:30:07 4: eventTypes: HMLAN HMLAN1 cond: init -> cond: init
2014.03.07 13:30:07 4: eventTypes: HMLAN HMLAN1 Xmit-Events: init:1 -> Xmit-Events: init:.*
2014.03.07 13:30:07 4: eventTypes: HMLAN HMLAN1 prot_init: last -> prot_init: last
2014.03.07 13:30:07 5: Triggering HMLAN1 (1 changes)
2014.03.07 13:30:07 5: Notify loop for HMLAN1 CONNECTED
2014.03.07 13:30:07 4: eventTypes: HMLAN HMLAN1 CONNECTED -> CONNECTED
2014.03.07 13:30:07 5: HMLAN1 Unknown msg >V1309040241201008AB552A150A050201<
2014.03.07 13:30:32 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:30:33 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:30:34 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:30:35 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:30:36 1: 192.168.0.6:1000 disconnected, waiting to reappear
2014.03.07 13:30:36 5: Triggering HMLAN1 (1 changes)
2014.03.07 13:30:36 5: Notify loop for HMLAN1 DISCONNECTED
2014.03.07 13:30:36 4: eventTypes: HMLAN HMLAN1 DISCONNECTED -> DISCONNECTED
2014.03.07 13:30:36 2: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.07 13:30:36 5: Triggering HMLAN1 (3 changes)
2014.03.07 13:30:36 5: Notify loop for HMLAN1 cond: disconnected
2014.03.07 13:30:36 4: eventTypes: HMLAN HMLAN1 cond: disconnected -> cond: disconnected
2014.03.07 13:30:36 4: eventTypes: HMLAN HMLAN1 Xmit-Events: disconnected:1 -> Xmit-Events: disconnected:.*
2014.03.07 13:30:36 4: eventTypes: HMLAN HMLAN1 prot_disconnected: last -> prot_disconnected: last
2014.03.07 13:30:41 1: 192.168.0.6:1000 reappeared (HMLAN1)
2014.03.07 13:30:41 5: HMLAN_Send: HMLAN1 I:A2576E2
2014.03.07 13:30:41 5: HMLAN_Send: HMLAN1 I:C
2014.03.07 13:30:41 5: HMLAN_Send: HMLAN1 I:Y01,00,
2014.03.07 13:30:41 5: HMLAN_Send: HMLAN1 I:Y02,00,
2014.03.07 13:30:41 5: HMLAN_Send: HMLAN1 I:Y03,00,
2014.03.07 13:30:41 5: HMLAN_Send: HMLAN1 I:T1AAC6A61,04,00,00000000
2014.03.07 13:30:41 2: HMLAN_Parse: HMLAN1 new condition init
2014.03.07 13:30:41 5: Triggering HMLAN1 (3 changes)
2014.03.07 13:30:41 5: Notify loop for HMLAN1 cond: init
2014.03.07 13:30:41 4: eventTypes: HMLAN HMLAN1 cond: init -> cond: init
2014.03.07 13:30:41 4: eventTypes: HMLAN HMLAN1 Xmit-Events: init:1 -> Xmit-Events: init:.*
2014.03.07 13:30:41 4: eventTypes: HMLAN HMLAN1 prot_init: last -> prot_init: last
2014.03.07 13:30:41 5: Triggering HMLAN1 (1 changes)
2014.03.07 13:30:41 5: Notify loop for HMLAN1 CONNECTED
2014.03.07 13:30:41 4: eventTypes: HMLAN HMLAN1 CONNECTED -> CONNECTED
2014.03.07 13:30:41 5: HMLAN1 Unknown msg >V1309040241201008AC562B150A050201<
2014.03.07 13:31:06 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:31:07 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:31:08 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:31:09 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:31:10 1: 192.168.0.6:1000 disconnected, waiting to reappear
2014.03.07 13:31:10 5: Triggering HMLAN1 (1 changes)
2014.03.07 13:31:10 5: Notify loop for HMLAN1 DISCONNECTED
2014.03.07 13:31:10 4: eventTypes: HMLAN HMLAN1 DISCONNECTED -> DISCONNECTED
2014.03.07 13:31:10 2: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.07 13:31:10 5: Triggering HMLAN1 (3 changes)
2014.03.07 13:31:10 5: Notify loop for HMLAN1 cond: disconnected
2014.03.07 13:31:10 4: eventTypes: HMLAN HMLAN1 cond: disconnected -> cond: disconnected
2014.03.07 13:31:10 4: eventTypes: HMLAN HMLAN1 Xmit-Events: disconnected:1 -> Xmit-Events: disconnected:.*
2014.03.07 13:31:10 4: eventTypes: HMLAN HMLAN1 prot_disconnected: last -> prot_disconnected: last
2014.03.07 13:31:15 1: 192.168.0.6:1000 reappeared (HMLAN1)
2014.03.07 13:31:15 5: HMLAN_Send: HMLAN1 I:A2576E2
2014.03.07 13:31:15 5: HMLAN_Send: HMLAN1 I:C
2014.03.07 13:31:15 5: HMLAN_Send: HMLAN1 I:Y01,00,
2014.03.07 13:31:15 5: HMLAN_Send: HMLAN1 I:Y02,00,
2014.03.07 13:31:15 5: HMLAN_Send: HMLAN1 I:Y03,00,
2014.03.07 13:31:15 5: HMLAN_Send: HMLAN1 I:T1AAC6A83,04,00,00000000
2014.03.07 13:31:15 2: HMLAN_Parse: HMLAN1 new condition init
2014.03.07 13:31:15 5: Triggering HMLAN1 (3 changes)
2014.03.07 13:31:15 5: Notify loop for HMLAN1 cond: init
2014.03.07 13:31:15 4: eventTypes: HMLAN HMLAN1 cond: init -> cond: init
2014.03.07 13:31:15 4: eventTypes: HMLAN HMLAN1 Xmit-Events: init:1 -> Xmit-Events: init:.*
2014.03.07 13:31:15 4: eventTypes: HMLAN HMLAN1 prot_init: last -> prot_init: last
2014.03.07 13:31:15 5: Triggering HMLAN1 (1 changes)
2014.03.07 13:31:15 5: Notify loop for HMLAN1 CONNECTED
2014.03.07 13:31:15 4: eventTypes: HMLAN HMLAN1 CONNECTED -> CONNECTED
2014.03.07 13:31:15 5: HMLAN1 Unknown msg >V1309040241201008AD562B150A050201<
Was mich wundert ist die Unknown msg, V1309040241201008AD562B150A050201. Dieser String (?) wird auch ausgegeben wenn ich mich mit telnet auf das HMLAN verbinde.
perfom habe ich auch laufen lassen, das modul lädt zwar und kündigt seine Dienste an, aber ein Log-Eintrag wird nicht generiert bzw. fhem-interne Probleme scheint es nicht festzustellen.
Ein apptime maxDly nach ca 4min und ein paar Reconnects sieht so aus:
fhem> apptime maxDly
name function max count total average maxDly
tmr-perfmon_ProcessTimer HASH(0x2e71a0) 0 142 0 0.00 29
tmr-HMLAN_UpdtMsgCnt UpdtMsg:HMLAN1 0 1 0 0.00 11
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 1 5 5 1.00 10 keepAlive:HMLAN1
tmr-FW_closeOldClients 0 2 0 0.00 9
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN1 12 19 61 3.21 9 keepAliveCk:HMLAN1
HMLAN1 HMLAN_Notify 2 16 8 0.50 0 HASH(0x30bed8); HASH(0x30bed8)
HMLAN1 HMLAN_Read 0 4 0 0.00 0
HMLAN1 HMLAN_Ready 21 4 77 19.25 0 HASH(0x30bed8)
Logfile FileLog_Log 0 16 0 0.00 0
WEB FW_Notify 0 16 0 0.00 0
WEBphone FW_Notify 0 16 0 0.00 0
WEBtablet FW_Notify 0 16 0 0.00 0
eventTypes eventTypes_Notify 1 16 12 0.75 0 HASH(0x518de8); HASH(0x30bed8)
telnet:127.0.0.1:57548 telnet_Read 1 4 1 0.25 0 HASH(0x244a30)
Und hier noch ein list auf das HMLAN opened
fhem> list HMLAN1
Internals:
DEF 192.168.0.6:1000
DeviceName 192.168.0.6:1000
FD 6
NAME HMLAN1
NR 9
NTFY_ORDER 50-HMLAN1
PARTIAL
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDs
assignedIDsCnt 0
msgKeepAlive dlyMax:0.011 bufferMin:4
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
Readings:
2014-03-07 16:10:47 Xmit-Events init:1
2014-03-07 16:10:47 cond init
2014-03-07 16:10:46 prot_disconnected last
2014-03-07 16:10:47 prot_init last
2014-03-07 16:10:46 prot_timeout last
Helper:
Assids:
Bm:
Hmlan_notify:
cnt 96
dmx 0
mAr HASH(0x30bed8); HASH(0x30bed8)
max 2
tot 48
Hmlan_read:
cnt 24
dmx 0
mAr
max 0
tot 0
Hmlan_ready:
cnt 24
dmx 0
mAr HASH(0x30bed8)
max 21
tot 451
K:
BufMin 4
DlyMax 0.011
Next 1394205072.02043
Start 1394205047.02043
Log:
all 0
sys 0
ids:
ARRAY(0x30e5e0)
Q:
HMcndN 255
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
apIDs:
Cap:
0 0
1 1
2 0
3 0
4 0
5 0
last 1
sum 1
Attributes:
hmId 2576E2
hmLanQlen 1_min
und disconnected
fhem> list HMLAN1
Internals:
DEF 192.168.0.6:1000
DeviceName 192.168.0.6:1000
NAME HMLAN1
NR 9
NTFY_ORDER 50-HMLAN1
PARTIAL
STATE disconnected
TYPE HMLAN
XmitOpen 0
assignedIDs
assignedIDsCnt 0
msgKeepAlive dlyMax:0.011 bufferMin:4
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
Readings:
2014-03-07 16:12:46 Xmit-Events disconnected:1
2014-03-07 16:12:46 cond disconnected
2014-03-07 16:12:46 prot_disconnected last
2014-03-07 16:12:17 prot_init last
2014-03-07 16:12:46 prot_timeout last
Helper:
Assids:
Bm:
Hmlan_notify:
cnt 110
dmx 0
mAr HASH(0x30bed8); HASH(0x30bed8)
max 2
tot 56
Hmlan_read:
cnt 27
dmx 0
mAr
max 0
tot 0
Hmlan_ready:
cnt 27
dmx 0
mAr HASH(0x30bed8)
max 21
tot 508
K:
BufMin 4
DlyMax 0.011
Next 1394205190.05686
Start 1394205165.05686
Log:
all 0
sys 0
ids:
ARRAY(0x30e5e0)
Q:
HMcndN 253
answerPend 0
hmLanQlen 1
keepAliveRec 0
keepAliveRpt 3
apIDs:
Cap:
0 0
1 1
2 0
3 0
4 0
5 0
last 1
sum 1
Ref:
kTs 1394205165056
Attributes:
hmId 2576E2
hmLanQlen 1_min
Ich werde fhem mit dieser config noch auf meinen Mac laufen lassen um das NAS auszuschliessen, dieses hatte aber während dieser Zeit nicht sehr viel zu tun.
Zu Testzwecken habe ich noch fhem trunk ausgecheckt und laufen lassen, jedoch kein anderes Ergebniss erhalten.
Um Hinweise und Lösungen bin ich natürlich sehr dankbar :-)
Danke & Gruss
dein Problem liegt nicht im Delay, FHRM arbeitet korrekt. Da brauchst du nicht mehr zu suchen. Aber HMLAN antwortet nicht
Zitat2014.03.07 13:29:33 5: HMLAN1 Unknown msg >V1309040241201008AA552A150A050201<
2014.03.07 13:29:58 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:29:59 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:30:00 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:30:01 5: HMLAN_Send: HMLAN1 I:K
2014.03.07 13:30:02 1: 192.168.0.6:1000 disconnected, waiting to reappear
4 mal keepalive aber keine Antwort
Die Antwort muesste so aussehen:
Zitat2014.03.08 15:16:54.209 0: HMLAN_Send: iohl1 I:K
2014.03.08 15:16:54.217 0: HMLAN_Parse: iohl1 V:03C1 sNo:IEQ0244337 d:1743BF O:1743BF t:09538B35 IDcnt:0010
Da der Ping funktioniert stellt sich die Frage, warum das keepalive nicht gesendet - oder zumindest nicht beantwortet wird. Eine firewall oder aehnlich ist nicht aktiv?
Gruss Martin
Hallo Martin,
danke für Deine Antwort und den Hinweis, welcher mich - bislang - zum Ziel führte.
Nachdem ich mit Wireshark den Traffic gesnifft habe und keine Requests an HMLanfand, sehr wohl aber wenn ich mich manuell via Telnet beim HMLan anmeldete,
ging ich quasi wieder auf Feld 1 und versuchte AES zu deaktivieren.
Das führte dann dazu das die Reconnects verschwanden.
Komischerweise konnte ich nun auf einmal auch ohne AES verbinden, was vorher nicht ging(?), jedenfalls lat fhem-log.
Danke nochmals
Hallo Forum,
in einem Post weiter oben habe ich geschrieben
ZitatMit den hier beschriebenen Methoden konnte 99_perfmon.pm und apptime konnte ich nicht wirklich einen "Schuldigen" ausmachen. Habe dieses Problem aber erstmal zurückgestellt weil ich noch einen Rollenaktor hatte, den ich per FHEM nicht ansprechen konnte. Der Aktor war mal richtig angelernt und hat auch auf FHEM Befehle reagiert. Aber, warum auch immer er tat's nicht mehr. Ich ging schon von einem Defekt aus, habe aber sicherheitshalber noch mal die Anlerntaste gedrückt und angelernt mit set HMLAN1 hmPairSerial KEQXXXXXXX . Was soll ich sagen, der Aktor funktioniert und meine Unterbrechungen sind auch weg. Das Modul perfmon mäkelt zwar gelegengtlich, aber alles ist gut.
Es ist nicht alles gut. Das Problem besteht weiter.
In der Ausgangssituation ist der HMLAN über einem Switch an der FB angeschlossen. Mit den, hier mehrfach beschriebenen Methoden kam ich nicht weiter. Ich habe den HMLAN jetzt ins Wohnzimmer umgezogen. Dort hängt er an einer FB7270 (ohne FHEM). Diese FB ist über einen Powerlineadapter ins Netz integriert und dient mir als AP im Wohnzimmer.
Mit dem Umzug ins Wohnzimmer hat sich die Situation verbessert. Ich habe im normalen Betrieb 1-2 Disconnect am Tag. Nach einer Woche bin ich recht zufrieden. Aber woran kann es liegen? An der kürzeren Funkstrecke zu den meisten meiner Aktoren? Wohl kaum. So wie ich das jetzt sehe handelt es sich um ein schnödes Netzwerkproblem des HMLAN. Im Wohnzimmer hängt er an einem 100 MBit Port der FB und Powerline ist noch mal langsamer, dass will ich aber garnicht betrachten. In der Ausgangssituation hing HMLAN an einem GigaBit Port meines Switches im Büro.
Also gut, langes Netzwerkkabel vom Büro ins Wohnzimmer und siehe da die Probleme treten wieder massiv auf. Ich habe wieder Timeouts in kurzen Abständen. Gelegentlich habe ich 4 Wiederholungen und dann kommt doch eine Antwort.
2014.03.18 07:58:37.504 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FCF8DB IDcnt:0000
2014.03.18 07:59:02.501 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 07:59:02.509 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FD5A8C IDcnt:0000
2014.03.18 07:59:27.507 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 07:59:28.513 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 07:59:29.518 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 07:59:30.524 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 07:59:30.574 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FDC831 IDcnt:0000
2014.03.18 07:59:30.581 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FDC835 IDcnt:0000
2014.03.18 07:59:30.583 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FDC837 IDcnt:0000
2014.03.18 07:59:30.585 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FDC838 IDcnt:0000
2014.03.18 07:59:55.529 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 07:59:55.536 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FE29B8 IDcnt:0000
Hier hats gerade noch geklappt.
2014.03.18 08:01:10.544 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 08:01:10.553 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FF4ECB IDcnt:0000
2014.03.18 08:01:13.697 0: HMLAN_Parse: HMLAN1 R:E21F320 stat:0000 t:01FF5B0D d:FF r:FFC2 m:42 8610 21F320 000000 0A88DF0E0020
2014.03.18 08:01:35.550 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 08:01:36.556 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 08:01:37.561 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 08:01:38.566 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 08:01:39.570 1: HMLAN_Parse: HMLAN1 new condition timeout
2014.03.18 08:01:39.582 1: 172.16.2.43:1000 disconnected, waiting to reappear
2014.03.18 08:01:39.585 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.18 08:02:41.011 1: 172.16.2.43:1000 reappeared (HMLAN1)
2014.03.18 08:02:41.013 0: HMLAN_Send: HMLAN1 I:AF11034
2014.03.18 08:02:41.015 0: HMLAN_Send: HMLAN1 I:C
2014.03.18 08:02:41.017 0: HMLAN_Send: HMLAN1 I:Y01,00,
2014.03.18 08:02:41.019 0: HMLAN_Send: HMLAN1 I:Y02,00,
2014.03.18 08:02:41.021 0: HMLAN_Send: HMLAN1 I:Y03,00,
2014.03.18 08:02:41.024 0: HMLAN_Send: HMLAN1 I:T1ABA9E01,04,00,00000000
2014.03.18 08:02:41.026 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.18 08:02:41.039 0: HMLAN_Send: HMLAN1 S:SD3FFCFD2 stat: 00 t:00000000 d:01 r:D3FFCFD2 m:99 8112 F11034 000001
2014.03.18 08:02:41.055 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:0200B039 IDcnt:0000
2014.03.18 08:02:41.057 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FFC405 IDcnt:0000
2014.03.18 08:02:41.060 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FFC409 IDcnt:0000
2014.03.18 08:02:41.062 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FFC40A IDcnt:0000
2014.03.18 08:02:41.066 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:01FFC40B IDcnt:0000
2014.03.18 08:02:41.070 0: HMLAN_Parse: HMLAN1 R:RD3FFCFD2 stat:0002 t:00000000 d:FF r:7FFF m:99 8112 F11034 000001
2014.03.18 08:02:41.072 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.18 08:03:06.040 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 08:03:06.048 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:02011204 IDcnt:0000
2014.03.18 08:03:17.458 0: HMLAN_Parse: HMLAN1 R:E21FECE stat:0000 t:02013E91 d:FF r:FFB8 m:04 8610 21FECE 000000 0A88B20E0018
Es geht aber auch schief.
Zum sniffen mit WireShark habe ich einen uralt Hub mit 10 MBit eingebaut. Also FB --> GigaBit Switch --> 10MBit Hub --> HMLAN.
Seit einer halben Stunde läuft das so ohne Probleme. In der Situation bringt sniffen nichts. Die Zeit ist natürlich viel zu kurz um zu behaupten das es das jetzt war. Ich wollte das jetzt nur mal los werden. Habe ich mich vergallopiert oder könnt ihr mir folgen. Auch Martin hatte ja schon die These, dass es eigentlich kein FHEM Problem ist, weil die gelegentlichen Ausreisser von perfmon die vielen Unterbrechungen nicht erklären.
Ich bin gespannt auf eure Meinung.
Werner
ZitatSo wie ich das jetzt sehe handelt es sich um ein schnödes Netzwerkproblem
ja
Zitatdes HMLAN
warum? Eher dein Netzwerk. Der HMLAN antwortet immer prompt, das ist bei allen anderen so, also auch bei dir.
Zitatlanges Netzwerkkabel vom Büro ins Wohnzimmer und siehe da die Probleme treten wieder massiv auf
kann es sein, dass die Verbindung so schlecht ist, dass ständig wiederholt wird?
ZitatGelegentlich habe ich 4 Wiederholungen und dann kommt doch eine Antwort.
fast richtig. Es kommen 4 Antworten. Es sind nur alle verzögert - um sage und schreibe 3 sec! Und dann kommen alle! Etwas in deinem Netzwerk macht ein eigenes timing - sendet nur blockweise... aus irgend einem Grund.
ZitatZum sniffen mit WireShark habe ich einen uralt Hub mit 10 MBit eingebaut.
Du solltest versuchen an verschiedenen Stellen im Netz zu sniffen um zu sehen, wer hier bummelt.
Hallo Martin,
ich habe mich bestimmt nicht richtig ausgedrückt.
Ich bin auf dem Tripp, dass das Gerät HM-CFG-LAN nicht mit Giga-Bit Ports zurecht kommt. Bei sonst gleichem Aufbau, (langes Kabel zum Wohnzimmer etwa 10 Meter) habe ich keine Probleme, wenn ich einen langsamen Hub zusätzlich dazwischen hänge. Der Grund warum ich den Hub eingebaut habe liegt am Sniffen. Im Netzwerk sehe ich den Traffic zwischen FHEM und dem Device nicht an den unbeteiligten Ports des Switch. Mein Switch zu Hause läßt sich nicht managen und ich kann keinen Monitorport einrichten. Am Hub kann ich aber den Datenverkehr an allen Ports sehen. Bei mir im Netz ist sonst nicht viel los und die 10 Meter von meinem häuslichen Arbeitszimmer zum Wohnzimmer sind sicher auch nicht das Problem. Ich bringe mir mal einen inteligenteren Switch von meinem Arbeitgeber mit. Dann kann ich versuchen meine These zu beweisen.
2014.03.18 08:03:56.049 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 08:03:57.055 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 08:03:58.059 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 08:03:59.064 0: HMLAN_Send: HMLAN1 I:K
2014.03.18 08:03:59.117 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:0201E15A IDcnt:0000
2014.03.18 08:04:03.043 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:0201F0AB IDcnt:0000
2014.03.18 08:04:03.045 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:0201F0AC IDcnt:0000
2014.03.18 08:04:03.047 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:0201F0AD IDcnt:0000
2014.03.18 08:04:24.069 0: HMLAN_Send: HMLAN1 I:K
Ich lese das so: Aus Fhem heraus wird das Gerät angesprochen. Es kommt keine Antwort innerhalb einer Sekunde und das Telegramm wird 3 mal wiederholt. Erst dann kommen die Antworten. Gerade noch rechtzeitig. Interpretiere ich das jetzt komplett falsch?
deine Interpretation des Ablaufs ist korrekt.
Ich habe das Port des HMLAN auf 1GB gesetzt. Es schaltet nicht um, was sinn macht. Was will ein HMLAN mit 1GBit? Es macht 100MBit und läuft zuverlässig.
Sollte dein Router immer wieder auf die Idee kommen 1GB zu probieren kann es zu Problemen führen.
LAN AutoNegotiate führt immer zu (geringem) datenverlust, was die Erfahrung zeigt. Evtl versucht dein Router etwas zu viel.
Gruss Martin
ZitatIch habe das Port des HMLAN auf 1GB gesetzt.
Ich nehme mal an, dass du das im Switch gemacht hast. Bei dem Config-Tool des HMLAN finde ich dazu keine Einstellmöglichkeit. Da werde ich mir einen managebaren Switch kaufen müssen um eine feste Geschwindigkeit einstellen zu können. Oder den "doofen" Hub beibehalten. Der kann nur 10MBit, was ja vollkommen reicht. ;)
in deiner fritzbox kannst du das auch einstellen.
gruss frank
Ich habe jetzt mein HM-CFG-LAN direct mit einem kurzen CAT5 Kabel (ja auch ein anderes Kabel probiert) an der FB 7390 angeschlossen. Der Port der FB ist im green mode und ich habe weiter Unterbrechungen. Wenn ich einen managebaren Switch dazwischen schalte, ist die Verbindung nur stabil wenn ich den Port im Switch (an dem der Lan-Adapter hängt) auf 10MBit einstelle. Zur Erinnerung mit einem einfachen Hub 10MBit funktioniert es auch.
Ich habe bisher keine Möglichkeit gefunden entweder die FB oder den Lan-Adapter fest auf 10 MBit einzustellen damit endlich Ruhe ist. Übersehe ich da was oder läuft bei euch die Kommunikation in dem genannten Aufbau stabil?
Logauszug, keine Meldungen von perfmon, ich hatte gehofft
attr HMLAN1 wdTimer 20
verschafft mit Luft. Ist aber nicht so nach 3 Wiederholungen kommt timeout.
2014.03.20 18:49:51.474 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:020918C8 IDcnt:0000
2014.03.20 18:50:11.472 0: HMLAN_Send: HMLAN1 I:K
2014.03.20 18:50:11.479 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:020966F0 IDcnt:0000
2014.03.20 18:50:24.194 0: HMLAN_Parse: HMLAN1 R:E21FECE stat:0000 t:02099896 d:FF r:FFB8 m:7A 8610 21FECE 000000 0A88CB0E0018
2014.03.20 18:50:31.477 0: HMLAN_Send: HMLAN1 I:K
2014.03.20 18:50:31.484 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:0209B517 IDcnt:0000
2014.03.20 18:50:51.481 0: HMLAN_Send: HMLAN1 I:K
2014.03.20 18:50:51.488 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:020A033E IDcnt:0000
2014.03.20 18:51:11.485 0: HMLAN_Send: HMLAN1 I:K
2014.03.20 18:51:11.492 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:020A5166 IDcnt:0000
2014.03.20 18:51:31.490 0: HMLAN_Send: HMLAN1 I:K
2014.03.20 18:51:32.495 0: HMLAN_Send: HMLAN1 I:K
2014.03.20 18:51:33.500 0: HMLAN_Send: HMLAN1 I:K
2014.03.20 18:51:34.505 0: HMLAN_Send: HMLAN1 I:K
2014.03.20 18:51:35.510 1: HMLAN_Parse: HMLAN1 new condition timeout
2014.03.20 18:51:35.518 1: 172.16.2.43:1000 disconnected, waiting to reappear
2014.03.20 18:51:35.522 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.20 18:51:37.506 1: Perfmon: possible freeze starting at 18:51:36, delay is 1.506
2014.03.20 18:52:38.010 1: 172.16.2.43:1000 reappeared (HMLAN1)
2014.03.20 18:52:38.013 0: HMLAN_Send: HMLAN1 I:AF11034
2014.03.20 18:52:38.014 0: HMLAN_Send: HMLAN1 I:C
2014.03.20 18:52:38.017 0: HMLAN_Send: HMLAN1 I:Y01,00,
2014.03.20 18:52:38.019 0: HMLAN_Send: HMLAN1 I:Y02,00,
2014.03.20 18:52:38.021 0: HMLAN_Send: HMLAN1 I:Y03,00,
2014.03.20 18:52:38.024 0: HMLAN_Send: HMLAN1 I:T1ABDD956,04,00,00000000
2014.03.20 18:52:38.026 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.20 18:52:38.036 0: HMLAN_Send: HMLAN1 S:SE09F93D7 stat: 00 t:00000000 d:01 r:E09F93D7 m:99 8112 F11034 000001
2014.03.20 18:52:38.047 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:020BA36E IDcnt:0000
2014.03.20 18:52:38.049 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:020AB6FE IDcnt:0000
2014.03.20 18:52:38.052 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:020AB702 IDcnt:0000
2014.03.20 18:52:38.053 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:020AB704 IDcnt:0000
2014.03.20 18:52:38.058 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:020AB705 IDcnt:0000
2014.03.20 18:52:38.060 0: HMLAN_Parse: HMLAN1 R:E21F320 stat:0000 t:020B5FCB d:FF r:FFBE m:B5 8610 21F320 000000 0A88CF0E0020
2014.03.20 18:52:38.115 0: HMLAN_Parse: HMLAN1 R:RE09F93D7 stat:0002 t:00000000 d:FF r:7FFF m:99 8112 F11034 000001
2014.03.20 18:52:38.116 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.20 18:52:58.037 0: HMLAN_Send: HMLAN1 I:K
2014.03.20 18:52:58.044 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:020BF1AD IDcnt:0000
2014.03.20 18:53:12.946 0: HMLAN_Parse: HMLAN1 R:E21FECE stat:0000 t:020C2BDF d:FF r:FFB8 m:7B 8610 21FECE 000000 0A88CB0E0018
2014.03.20 18:53:18.041 0: HMLAN_Send: HMLAN1 I:K
2014.03.20 18:53:18.048 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851629 d:23A33B O:F11034 t:020C3FD4 IDcnt:0000
2014.03.20 18:53:38.045 0: HMLAN_Send: HMLAN1 I:K
ich habe eine 7390 - der HMLAN steht auf 100MBit. Funktioniert ohne Probleme.
1GBit würde ich nicht einstellen
ok ich habe eine Supportanfrage an ELV gestellt und das Problem beschrieben. Interessant ist, dass wenn ich den managebaren Switch auf 100 MBit stelle ist die Verbindung auch nicht stabil. Meistens sitzt das Problem ja vor dem Monitor, ;) aber in diesem Fall gehe ich jetzt von einem defekten HM-CFG-LAN aus.
kann man nie ausschliessen
hallo wtue,
meiner ist auch mit der 100mbit einstellung an der 7390 und läuft eigentlich stabil.
mich würde mal deine fw-version interessieren.
gruss frank
Hi Frank,
da muss ich dich auf morgen vertrösten. Über VPN verbunden zeigt mir der Interfacekonfigurator kein Device an. Ich habe auch schon mal ein update über die Windowssoftware gemacht. Während des Update zeigt er verschiedene FW Stände an zum Schluss blieb dann aber alles beim Alten. Die Nummer kriege ich jetzt aber nicht auf die Reihe.
Gruß Werner
kein problem.
steht aber auch in fhem beim hmlan-details-internals.
gruss frank
Wer lesen kann ist klar im Vorteil ???
Ich habs glatt übersehen. Da steht
firmware 0.961
Gruß Werner
Hallo zusammen,
ich möchte gerne mal meinen Status in der Angelegenheit abgeben.
Ich habe den HM-CFG-LAN bei ELV reklamiert und Ersatz bekommen. Leider dadurch keine Änderung. Immer wieder Unterbrechungen heute von 00:00 bis etwa 18:00 Uhr waren es bereits über 70.
Ich habe Logs aufgezeichnet und auch einen TCP-Dump gemacht, die ich hier als Datei anhänge. Darin enthalten ist mal eine Unterbrechung.
Meine Konfiguration ist im Moment ein Cul der im Moment den Funkbetrieb macht.
define CUL_0 CUL /dev/ttyACM0@9600 1034
attr CUL_0 hmId F11034
attr CUL_0 rfmode HomeMatic
attr CUL_0 room x_System
attr CUL_0 verbose 3
Weiter den HMLAN ohne angelernte Geräte (mit anderer hmId):
define HMLAN1 HMLAN 172.16.2.250:1000
attr HMLAN1 hmId F11035
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 logIDs sys,all
attr HMLAN1 room x_System
attr HMLAN1 wdTimer 25
Mein fhem ist aktuell:
# $Id: fhem.pl 5340 2014-03-27 16:19:53Z rudolfkoenig $
# $Id: 00_CUL.pm 5289 2014-03-22 13:38:21Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 5366 2014-03-29 09:12:24Z martinp876 $
# $Id: 00_FBAHA.pm 2777 2013-02-20 08:02:01Z rudolfkoenig $
# $Id: 10_FBDECT.pm 2779 2013-02-21 08:52:27Z rudolfkoenig $
# $Id: 01_FHEMWEB.pm 5259 2014-03-20 09:20:15Z rudolfkoenig $
# $Id: 95_FLOORPLAN.pm 5051 2014-02-26 12:36:45Z betateilchen $
# $Id: 92_FileLog.pm 5068 2014-02-28 07:15:18Z rudolfkoenig $
# $Id: 00_HMLAN.pm 5343 2014-03-27 19:31:41Z martinp876 $
# $Id: 98_HMinfo.pm 5366 2014-03-29 09:12:24Z martinp876 $
# $Id: 99_SUNRISE_EL.pm 4537 2014-01-03 08:28:59Z rudolfkoenig $
# $Id: 98_SVG.pm 5076 2014-03-01 06:30:23Z rudolfkoenig $
# $Id: 99_Utils.pm 3595 2013-08-05 05:38:48Z tobiasfaust $
# $Id: 59_Weather.pm 4887 2014-02-11 19:27:08Z borisneubert $
# $Id: 90_at.pm 5319 2014-03-25 10:11:47Z rudolfkoenig $
# $Id: 98_autocreate.pm 5268 2014-03-20 20:46:00Z rudolfkoenig $
# $Id: 98_dummy.pm 4934 2014-02-15 08:23:12Z rudolfkoenig $
# $Id: 91_eventTypes.pm 2982 2013-03-24 17:47:28Z rudolfkoenig $
# $Id: 95_holiday.pm 5334 2014-03-26 23:14:05Z rudolfkoenig $
# $Id: 99_myUtils.pm
# $Id: 91_notify.pm 5362 2014-03-29 07:02:12Z rudolfkoenig $
# $Id: 98_structure.pm 5050 2014-02-26 08:29:44Z rudolfkoenig $
# $Id: 98_telnet.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
# $Id: 98_update.pm 5173 2014-03-09 09:12:35Z rudolfkoenig $
# $Id: 98_weblink.pm 3770 2013-08-23 13:29:58Z rudolfkoenig $
Die Firmware Version meines HMLAN ist 0.961 seit heute gibt es eine neue im Downloadbereich von eq3 http://www.eq-3.de/downloads.html (http://www.eq-3.de/downloads.html) Konfigurationsadapter LAN Usersoftware V1.514.1
Diese Version habe ich noch nicht probiert, angeblich hat sich nur was auf der Funkseite und nichts auf der Lan-Seite geändert.
Interessant wäre jetzt, das jemand der diese Probleme nicht hat mal checkt welche Firmware er hat und ob in meiner Config des LAn-Adapter was nicht stimmt.
Gruß Werner
Hallo zusammen,
ich habe auch schon seit längerem dieses Problem. Allein im März schon 229 mal ein disconnect:
2014.03.28 06:24:58.557 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851774 d:23A38D O:23A38D t:1C1491E7 IDcnt:0004
2014.03.28 06:25:23.277 0: HMLAN_Send: HMLAN1 I:K
2014.03.28 06:25:23.283 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851774 d:23A38D O:23A38D t:1C14F283 IDcnt:0004
2014.03.28 06:25:48.285 0: HMLAN_Send: HMLAN1 I:K
2014.03.28 06:25:49.289 0: HMLAN_Send: HMLAN1 I:K
2014.03.28 06:25:50.294 0: HMLAN_Send: HMLAN1 I:K
2014.03.28 06:25:51.298 0: HMLAN_Send: HMLAN1 I:K
2014.03.28 06:25:52.302 1: HMLAN_Parse: HMLAN1 new condition timeout
2014.03.28 06:25:52.311 1: 192.168.178.67:1000 disconnected, waiting to reappear
2014.03.28 06:25:52.315 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.28 13:17:17.291 1: Including fhem.cfg
2014.03.28 13:17:19.039 3: telnetPort: port 7072 opened
2014.03.28 13:17:20.721 3: WEB: port 8083 opened
2014.03.28 13:17:20.761 3: WEBphone: port 8084 opened
2014.03.28 13:17:20.788 3: WEBtablet: port 8085 opened
2014.03.28 13:17:21.656 2: eventTypes: loaded 1264 events from ./log/eventTypes.txt
2014.03.28 13:17:21.697 1: Including /opt/fhem/FHEM/fhem_Dashboard.cfg
2014.03.28 13:17:22.049 1: Including /opt/fhem/FHEM/fhem_Maschinenraum.cfg
2014.03.28 13:17:22.061 1: Including /opt/fhem/FHEM/fhem_Maschinenraum_RPi.cfg
2014.03.28 13:17:23.144 3: Opening FritzBox device 192.168.178.1:1012
2014.03.28 13:17:26.141 3: Can't connect to 192.168.178.1:1012: No route to host
2014.03.28 13:17:26.348 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.03.28 13:17:26.351 3: Opening HMLAN1 device 192.168.178.67:1000
2014.03.28 13:17:26.359 3: HMLAN1 device opened
2014.03.28 13:17:26.363 1: HMLAN_Parse: HMLAN1 new condition init
2014.03.28 13:17:27.187 1: Including /opt/fhem/FHEM/fhem_Floorplan.cfg
2014.03.28 13:17:27.432 1: Including /opt/fhem/FHEM/fhem_Wetter.cfg
2014.03.28 13:17:52.716 1: Including /opt/fhem/FHEM/fhem_Global.cfg
2014.03.28 13:17:52.777 1: Including /opt/fhem/FHEM/fhem_Kinderzimmer.cfg
2014.03.28 13:17:54.757 1: Including /opt/fhem/FHEM/fhem_Wohnzimmer.cfg
2014.03.28 13:17:55.233 1: Including /opt/fhem/FHEM/fhem_Media.cfg
2014.03.28 13:17:56.643 1: Including /opt/fhem/FHEM/fhem_Watchdog.cfg
2014.03.28 13:17:56.707 1: Including ./log/fhem.save
2014.03.28 13:17:57.486 1: usb create starting
2014.03.28 13:17:58.958 3: Probing CUL device /dev/ttyAMA0
2014.03.28 13:17:59.503 3: Probing TCM310 device /dev/ttyAMA0
2014.03.28 13:17:59.724 3: Probing FRM device /dev/ttyAMA0
2014.03.28 13:18:04.998 1: usb create end
2014.03.28 13:18:05.002 0: Server started with 123 defined entities (version $Id: fhem.pl 5238 2014-03-16 16:23:31Z rudolfkoenig $, os linux, user fhem, pid 1908)
2014.03.28 13:18:05.008 0: HMLAN_Send: HMLAN1 I:K
2014.03.28 13:18:08.011 3: ONKYO_AVR device Onkyo_AVR is unavailable
2014.03.28 13:18:11.050 3: Device Kinderzimmer_Heizung added to ActionDetector with 000:10 time
2014.03.28 13:18:11.178 3: Device Wohnzimmer_Heizung added to ActionDetector with 000:10 time
2014.03.28 13:18:11.303 3: Device Wohnzimmer_Wandthermostat added to ActionDetector with 000:10 time
2014.03.28 13:18:11.413 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851774 d:23A38D O:23A38D t:00007C44 IDcnt:0000
2014.03.28 13:18:11.415 0: HMLAN_Parse: HMLAN1 R:R089F92A3 stat:0002 t:00000000 d:FF r:7FFF m:99 8112 999999 000001
2014.03.28 13:18:11.416 1: HMLAN_Parse: HMLAN1 new condition ok
Auszug Apptime:
name function max count total average maxDly
FHEMWEB:192.168.178.25:52642 FW_Read 9224 36 9275 257.64 0 HASH(0x158fef0)
tmr-ONKYO_AVR_GetStatus HASH(0xfe4a38) 4708 18 38965 2164.72 2400 HASH(0xfe4a38)
Raspbmc XBMC_Ready 3003 797 66004 82.82 0 HASH(0x1002580)
tmr-SYSMON_Update HASH(0x8b0528) 266 22 4051 184.14 10280 HASH(0x8b0528)
HMLAN1 HMLAN_Read 119 86 2384 27.72 0 HASH(0xa37f60)
FHEMWEB:192.168.178.25:52671 FW_Read 41 27 74 2.74 0 HASH(0x14e4a70)
Temperatur_Check_Notify notify_Exec 12 90 598 6.64 0 HASH(0x1155d68); HASH(0x7823b0)
Valve_Check_Notify notify_Exec 12 90 217 2.41 0 HASH(0x1159e38); HASH(0x7823b0)
Batterie_Check_Notify notify_Exec 9 90 186 2.07 0 HASH(0x114eb00); HASH(0xfd3288)
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 7 54 114 2.11 5837 keepAlive:HMLAN1
FileLog_sysmon FileLog_Log 5 22 36 1.64 0 HASH(0x931080); HASH(0x8b0528)
WEB FW_Read 5 31 51 1.65 0 HASH(0x612a68)
tmr-CUL_HM_ActCheck ActionDetector 5 2 10 5.00 6 ActionDetector
tmr-FW_closeOldClients 5 22 61 2.77 10285
eventTypes eventTypes_Notify 3 90 80 0.89 0 HASH(0x808828); HASH(0x8b0528)
FileLog_Kinderzimmer_Heizung_Clima FileLog_Log 2 8 11 1.38 0 HASH(0xfa3a18); HASH(0xfa1c20)
Onkyo_AVR ONKYO_AVR_Set 2 2 4 2.00 0 HASH(0xfe4a38); Onkyo_AVR; ?
ActionDetector_Check_Notify notify_Exec 1 90 62 0.69 0 HASH(0x11ef600); HASH(0xfccb40)
FHEMWEB:192.168.178.25:52703 FW_Read 1 3 2 0.67 0 HASH(0x13300e0)
FileLog_Kinderzimmer_Heizung FileLog_Log 1 8 8 1.00 0 HASH(0xe53000); HASH(0xb01930)
FileLog_Wohnzimmer_Heizung FileLog_Log 1 8 8 1.00 0 HASH(0xfd3960); HASH(0xfd3288)
In der Firtzbox stand der entsprechende Port auf 1GBit. Habe diesen nun mal auf 100MBit umgestellt. Mal sehen was nun passiert.
Kann jemand zufällig zu meinem Auszug von apptime was sagen? Wenn ich das richtig verstehe, dann ist da einiges dabei was nicht so gut aussieht, oder?
Vielen Dank.
Gruß
Hallo zusammen,
auch nach FW Update habe ich weiter Unterbrechungen. Perfom und apptime geben keinen Hinweis darauf dass das Problem innerhalb von fhem liegt. Auch mit der Software Komponenten konfigurieren blinkt die Staus LED des Lan Adapter immer mal kurz auf, was ich als disconnect interpretiere.
Ich habe Kontakt mit dem Support von ELV und habe denen meine Logs und auch eine TCP-Dump geschickt. Mal sehen was da so kommt.
Gruß Werner
Edit: ELV hat das Thema an den Hersteller weitergeleitet. Sie melden sich wieder und bitten um Geduld.
Ich hab festgestellt, dass der Adaper sporadisch eine wahnsinnig hohe Antwortzeit im LAN hat.
Er laeuft 20minuten super mit <1ms und hat dann auf einmal eine Antwortzeit von mehreren hundert milisekunden.
Ich bin allerdings noch nicht dahinter gestiegen wieso das so ist. An der Hardware oder LAN auslastung liegts nicht.
Auch sehe ich auch meinen Cisco Switches keine Error-Counts. Somit koennte der Fehler vielleicht wieder Firmware-Related sein...
Bei mir sind viele Disconnects nach löschen von ein paar stateformat Einträgen verschwunden. Jetzt kommt nur noch hin und wieder einer beim Anzeigen von Plots.
Hallo stromer-12,
ich denke in deinem Fall haben sicher Perfmon apptime HInweise auf Performance Probleme gegeben. Bei mir gibt es die nicht. Also es gibt durchaus verschieden Ursachen.
Gruß Werner
Hallo,
ich habe auch häufige disconnect und connect
2014.12.04 03:43:12.217 1: 192.168.188.27:1000 disconnected, waiting to reappear (HmLanAdapter)
2014.12.04 03:43:12.223 1: HMLAN_Parse: HmLanAdapter new condition disconnected
2014.12.04 03:44:13.289 1: 192.168.188.27:1000 reappeared (HmLanAdapter)
2014.12.04 03:44:13.296 1: HMLAN_Parse: HmLanAdapter new condition init
2014.12.04 03:44:13.470 1: HMLAN_Parse: HmLanAdapter new condition ok
2014.12.04 03:46:02.536 1: 192.168.188.27:1000 disconnected, waiting to reappear (HmLanAdapter)
2014.12.04 03:46:02.539 1: HMLAN_Parse: HmLanAdapter new condition disconnected usw.
Ich habe dann mal mit Performance Monitor geschaut, das ergibt im Log direkt nach dem shutdown restart einiges an:
2014.12.04 13:30:44.412 1: Perfmon: possible freeze starting at 13:30:41, delay is 3.412
2014.12.04 13:30:58.345 1: Perfmon: possible freeze starting at 13:30:55, delay is 3.345
2014.12.04 13:31:12.377 1: Perfmon: possible freeze starting at 13:31:09, delay is 3.377
hab dann verbose auf 5 geändert und dabei sind mir dann diese Punkte aufgefallen, die sich dann häufiegr im Log finden:
2014.12.04 13:37:09.278 1: Perfmon: possible freeze starting at 13:36:54, delay is 15.277
2014.12.04 13:37:09.279 4: HTTPMOD: GetUpdate called, hash = HASH(0x22735e0), name = TV_Programme
2014.12.04 13:37:09.280 4: HttpUtils url=http://www.tvmovie.de/tv-programm-jetzt-im-tv.html?tv-stations-count=100&time=now&form_build_id=form-7f6a9332d4b1e7b5bc6af20e39353673&form_id=dikr_tvm_tv_guide_tv_stations_count_form
2014.12.04 13:37:09.311 4: HTTPMOD: GetUpdate called, hash = HASH(0x254ab28), name = TV_Programme_next
2014.12.04 13:37:09.312 4: HttpUtils url=http://www.tvmovie.de/tv-programm-gleich-im-tv.html?tv-stations-count=100&time=soon&form_build_id=form-6c71e36a9e9651420736eccb5287fdec&form_id=dikr_tvm_tv_guide_tv_stations_count_form
2014.12.04 13:37:55.372 1: Perfmon: possible freeze starting at 13:37:52, delay is 3.372
2014.12.04 13:37:55.464 5: FBAHA/RAW: /0703001c000000214e2000000000000c0000001400040000000000000703001c000000214e2000000000000c0000001400040000000000000703001c000000214e2000000000000c0000001400040000000000000703001c000000214e2000000000000c000000140004000000000000
2014.12.04 13:37:55.465 5: FBSmartHome dispatch 0703001c000000214e2000000000000c000000140004000000000000
2014.12.04 13:37:55.467 4: Payload: 000000140004000000000000 -> power: 0.00 W
2014.12.04 13:37:55.468 5: FBDECT_Parse for device Powerline done
2014.12.04 13:37:55.469 5: FBSmartHome dispatch 0703001c000000214e2000000000000c000000140004000000000000
2014.12.04 13:38:48.009 1: Perfmon: possible freeze starting at 13:38:45, delay is 3.008
2014.12.04 13:38:52.017 4: iTunes_HTTP_Request http://192.168.188.22:3689/login?pairing-guid=0x42b352fdd013f43c: Can't connect to http://192.168.188.22:3689
2014.12.04 13:38:52.137 1: Perfmon: possible freeze starting at 13:38:49, delay is 3.137
2014.12.04 13:38:52.137 5: HMLAN_Send: HmLanAdapter I:K
2014.12.04 13:38:52.141 5: HMLAN/RAW: /HHM-LAN-IF,03C1,KEQ0852050,23A503,000041,09256140,000B
2014.12.04 13:39:01.045 1: Perfmon: possible freeze starting at 13:38:58, delay is 3.044
2014.12.04 13:39:01.045 5: ENIGMA2 VU_Ultimo: called function ENIGMA2_ReceiveCommand()
2014.12.04 13:39:01.080 4: https://root:xxx@192.168.188.24:444/web/timerlist: HTTP response code 200
2014.12.04 13:39:01.081 4: HttpUtils https://root:xxx@192.168.188.24:444/web/timerlist: Got data, length: 68
2014.12.04 13:39:01.081 5: ENIGMA2 VU_Ultimo: called function ENIGMA2_ReceiveCommand()
2014.12.04 13:39:01.082 4: ENIGMA2 VU_Ultimo: RCV timerlist
2014.12.04 13:39:01.082 5: ENIGMA2 VU_Ultimo: RES timerlist
2014.12.04 13:39:06.075 1: Perfmon: possible freeze starting at 13:39:03, delay is 3.075
2014.12.04 13:39:06.076 5: ENIGMA2 Uno_Schlafzimmer: called function ENIGMA2_GetStatus()
2014.12.04 13:39:06.076 5: ENIGMA2 Uno_Schlafzimmer: called function ENIGMA2_SendCommand()
2014.12.04 13:39:06.076 4: ENIGMA2 Uno_Schlafzimmer: REQ powerstate
2014.12.04 13:39:06.077 5: ENIGMA2 Uno_Schlafzimmer: GET https://root:xxx@192.168.188.29:443/web/powerstate
2014.12.04 13:39:06.077 4: HttpUtils url=https://root:xxx@192.168.188.29:443/web/powerstate
2014.12.04 13:39:20.179 1: Perfmon: possible freeze starting at 13:39:17, delay is 3.179
2014.12.04 13:39:22.997 5: HMLAN/RAW: /E222529,0000,0925D9C7,FF,FFCD,0286102225290000000A98C70C0416
2014.12.04 13:40:32.166 1: Perfmon: possible freeze starting at 13:40:31, delay is 1.165
2014.12.04 13:40:32.166 5: ENIGMA2 Uno_Kellerbar: called function ENIGMA2_GetStatus()
2014.12.04 13:40:32.167 5: ENIGMA2 Uno_Kellerbar: called function ENIGMA2_SendCommand()
2014.12.04 13:40:32.168 4: ENIGMA2 Uno_Kellerbar: REQ powerstate
2014.12.04 13:40:32.168 5: ENIGMA2 Uno_Kellerbar: GET https://root:xxx@192.168.188.30:443/web/powerstate
2014.12.04 13:40:32.169 4: HttpUtils url=https://root:xxx@192.168.188.30:443/web/powerstate
2014.12.04 13:40:32.193 4: https://root:xxx@192.168.188.24:444/web/timerlist: HTTP response code 200
2014.12.04 13:40:32.194 4: HttpUtils https://root:xxx@192.168.188.24:444/web/timerlist: Got data, length: 68
2014.12.04 13:40:32.194 5: ENIGMA2 VU_Ultimo: called function ENIGMA2_ReceiveCommand()
2014.12.04 13:40:32.195 4: ENIGMA2 VU_Ultimo: RCV timerlist
2014.12.04 13:40:32.195 5: ENIGMA2 VU_Ultimo: RES timerlist
Das sieht mir so aus, alsob das Enigma2 Modul, iTunes, FBDect/FBSmartHome,HttpMod bei mir für verzögerungen sorgen!?
Interpretiere ich das richtig?
Dann würde ich ja was enigma2 und iTunes am besten mal im entsprechenden Thread fragen oder wie seht ihr das?
Ich hab dann auch mal noch mit apptime geschaut, das sieht dann so aus:
name function max count total average param Max call
XBMC XBMC_Ready 3014 12951 93219 7.20 HASH(0x3944c98)
tmr-WOL_UpdateReadings HASH(0x39272f8) 2066 12 24638 2053.17 HASH(0x39272f8)
tmr-WOL_UpdateReadings HASH(0x33ff5c8) 2064 12 24622 2051.83 HASH(0x33ff5c8)
WEB FW_Read 947 124 11898 95.95 HASH(0x392d0f8)
FHEMWEB:192.168.188.73:52585 FW_Read 482 1 482 482.00 HASH(0x3bb9da0)
FBSmartHome FBAHA_Read 455 1299 32303 24.87 HASH(0x3d50b28)
HmLanAdapter HMLAN_Read 70 172 3855 22.41 HASH(0x3406860)
tmr-HttpUtils_ReadErr HASH(0x3ba9490) 53 1 53 53.00 HASH(0x3ba9490)
tmr-HttpUtils_ReadErr HASH(0x3d93ac8) 46 1 46 46.00 HASH(0x3d93ac8)
tmr-HTTPMOD_GetUpdate HASH(0x2fbdcb0) 39 31 302 9.74 HASH(0x2fbdcb0)
FBDECT_Temperatur notify_Exec 16 108 182 1.69 HASH(0x33bff10); HASH(0x33c6b28)
FBDECT_20000_temp dummy_Set 14 36 163 4.53 HASH(0x2ae54f8); FBDECT_20000_temp; 21.9
FHEMWEB:192.168.188.73:52577 FW_Read 12 4 18 4.50 HASH(0x39450b8)
tmr-ENIGMA2_GetStatus HASH(0x2e0db60) 11 21 76 3.62 HASH(0x2e0db60)
tmr-FW_closeOldClients 10 31 113 3.65
Alarm_nt notify_Exec 9 2409 278 0.12 HASH(0x33c2d38); HASH(0x33c6b28)
Wohnzimmer_Heizung_nty notify_Exec 9 2409 25 0.01 HASH(0x33c84f8); HASH(0x33c6b28)
Logfile FileLog_Log 8 2409 11 0.00 HASH(0x3d50ea0); HASH(0x33c6b28)
FHEMWEB:192.168.188.73:52585 FW_Notify 7 294 737 2.51 HASH(0x3bb9da0); HASH(0x33ff5c8)
tmr-CUL_HM_ActCheck ActionDetector 7 3 18 6.00 ActionDetector
FileLog_Fenster_neben_Couch FileLog_Set 6 4 21 5.25 HASH(0x3d510e0); FileLog_Fenster_neben_Couch; ?
Das sieht aus als ob das XBMC Modul und das WOL Modul für viele belastung sorgt!?
Könnte das für meine disconnects verantworlich sein?
Danke
EDIT
Hab XBMC mal rausgeschmissen, da ich das aktuell eh nicht nutze, mal sehn ob das schon hilft
ZitatDas sieht mir so aus, alsob das Enigma2 Modul, iTunes, FBDect/FBSmartHome,HttpMod bei mir für verzögerungen sorgen!?
Interpretiere ich das richtig?
nicht wirklich.
entscheidend sind aktionen, die zur angegebenen zeit aktiv wurden.
Perfmon: possible freeze starting at 13:37:52, delay is 3.372also um 13:37:52. da ist dann aber nichts.
XBMC XBMC_Ready 3014 12951 93219 7.20 HASH(0x3944c98) das ist auch nicht schön, aber eigentlich noch kein grund. ausserdem sind ja keine disconnects im log, während verbose=5.
dein netzwerk ist aber schon sehr aktiv. einfach weiter beobachten.
Hallo frank, ok Schade, hatte gehofft hätte schon mal ein paar Probleme identifiziert.
Ich hab XBMC jetzt mal deinstaliiert, mal sehen ob es jetzt besser wird.
An der CPU und Speicher auslastund solte es eigentlich nicht liegen
ZitatLoad average: 0.00 0.03 0.05
RAM: Total: 1999.16 MB, Used: 72.30 MB, 3.62 %, Free: 1926.86 MB
Hab im Log aber immer noch einige Freetzer, werd das mal weiter beobachten
2014.12.04 15:59:39.102 1: Perfmon: possible freeze starting at 15:59:15, delay is 24.101
2014.12.04 15:59:42.720 1: Perfmon: possible freeze starting at 15:59:41, delay is 1.72
2014.12.04 16:07:11.009 1: Perfmon: possible freeze starting at 16:07:10, delay is 1.009
2014.12.04 16:08:41.081 1: Perfmon: possible freeze starting at 16:08:40, delay is 1.081
2014.12.04 16:10:11.007 1: Perfmon: possible freeze starting at 16:10:10, delay is 1.007
2014.12.04 16:13:15.179 1: Perfmon: possible freeze starting at 16:13:14, delay is 1.178
2014.12.04 16:14:47.222 1: Perfmon: possible freeze starting at 16:14:46, delay is 1.221
2014.12.04 16:16:19.494 1: Perfmon: possible freeze starting at 16:16:18, delay is 1.494
2014.12.04 16:17:51.439 1: Perfmon: possible freeze starting at 16:17:50, delay is 1.439
2014.12.04 16:19:23.392 1: Perfmon: possible freeze starting at 16:19:22, delay is 1.392
2014.12.04 16:20:55.447 1: Perfmon: possible freeze starting at 16:20:54, delay is 1.447
2014.12.04 16:22:11.110 1: Perfmon: possible freeze starting at 16:22:10, delay is 1.11
2014.12.04 16:22:27.502 1: Perfmon: possible freeze starting at 16:22:26, delay is 1.501
2014.12.04 16:23:59.570 1: Perfmon: possible freeze starting at 16:23:58, delay is 1.569
2014.12.04 16:25:31.716 1: Perfmon: possible freeze starting at 16:25:30, delay is 1.715
2014.12.04 16:26:58.535 1: Perfmon: possible freeze starting at 16:26:39, delay is 19.535
Kleine zwischen Meldung, hab zwar die ganze Nacht Meldungen im Log wie diese hier:
2014.12.05 00:00:03.981 1: Perfmon: possible freeze starting at 00:00:00, delay is 3.98
2014.12.05 00:00:18.065 1: Perfmon: possible freeze starting at 00:00:14, delay is 4.065
2014.12.05 00:00:32.010 1: Perfmon: possible freeze starting at 00:00:28, delay is 4.01
2014.12.05 00:00:46.059 1: Perfmon: possible freeze starting at 00:00:43, delay is 3.059
2014.12.05 00:01:00.118 1: Perfmon: possible freeze starting at 00:00:57, delay is 3.118
2014.12.05 00:01:14.080 1: Perfmon: possible freeze starting at 00:01:11, delay is 3.08
2014.12.05 00:01:28.160 1: Perfmon: possible freeze starting at 00:01:25, delay is 3.16
2014.12.05 00:01:42.120 1: Perfmon: possible freeze starting at 00:01:39, delay is 3.119
2014.12.05 00:01:56.139 1: Perfmon: possible freeze starting at 00:01:53, delay is 3.139
2014.12.05 00:02:10.321 1: Perfmon: possible freeze starting at 00:02:07, delay is 3.321
2014.12.05 00:02:17.650 1: Perfmon: possible freeze starting at 00:02:16, delay is 1.65
2014.12.05 00:02:24.238 1: Perfmon: possible freeze starting at 00:02:21, delay is 3.238
2014.12.05 00:02:26.286 1: Perfmon: possible freeze starting at 00:02:25, delay is 1.286
2014.12.05 00:02:38.294 1: Perfmon: possible freeze starting at 00:02:35, delay is 3.293
2014.12.05 00:02:52.220 1: Perfmon: possible freeze starting at 00:02:49, delay is 3.219
2014.12.05 00:03:06.240 1: Perfmon: possible freeze starting at 00:03:03, delay is 3.239
2014.12.05 00:03:20.354 1: Perfmon: possible freeze starting at 00:03:17, delay is 3.353
2014.12.05 00:03:34.279 1: Perfmon: possible freeze starting at 00:03:31, delay is 3.279
allerdings keine disconnects mehr, ich denke das mein Poblem das XBMC Modul war welches die disconnects ausgelöst hat, die jetzigen delays kann ich glaub ich erstmal ignorieren!?
hast du für das xbmc modul das fork attribut gesetzt? sonst bleibt das modul hängen wenn der player aus ist.
gruss
andre
Ich hab kein fork gesetzt und bei mir schmiert auch nichts ab?!
wo steht etwas von anschmieren?
Was meinst du dann mit "bleibt" das Modul hängen? Ich hatte mit bleib hängen verstanden, dass es quasi nicht mehr funktioniert: Umgangsprachlich quasi absturz. Ich will jetzt keine Haare spalten, scheinbar hab ich dich falsch verstanden?
Hi, ich bin mir relativ sicher das ich das fork Attribut gesetzt hatte, kann es aber nicht 100% garantieren da ich das xbmc Modul erstmal gelöscht hab.
Und seit dem sind auf jeden Fall meine disconnects weg.
bleibt hängen heisst das es verzögerungen beim verbundungsazfbau gibt und fhem regelmässig mehrere sekunden hängen bleibt. genau um das zu vermeiden gibt es ja das fork attribut.
Danke für die Info
Gesendet von meinem Smartphone
Hi, hab heute plötzlich den Log wieder voll mit
2015.01.05 00:00:00.864 1: HMLAN_Parse: HmLanAdapter new condition timeout
2015.01.05 00:00:00.887 1: 192.168.188.27:1000 disconnected, waiting to reappear (HmLanAdapter)
2015.01.05 00:00:00.891 1: HMLAN_Parse: HmLanAdapter new condition disconnected
2015.01.05 00:01:05.662 1: 192.168.188.27:1000 reappeared (HmLanAdapter)
2015.01.05 00:01:05.670 1: HMLAN_Parse: HmLanAdapter new condition init
2015.01.05 00:01:05.779 1: HMLAN_Parse: HmLanAdapter new condition ok
2015.01.05 00:08:38.117 1: HMLAN_Parse: HmLanAdapter new condition timeout
2015.01.05 00:08:38.146 1: 192.168.188.27:1000 disconnected, waiting to reappear (HmLanAdapter)
2015.01.05 00:08:38.151 1: HMLAN_Parse: HmLanAdapter new condition disconnected
2015.01.05 00:09:40.131 1: 192.168.188.27:1000 reappeared (HmLanAdapter)
2015.01.05 00:09:40.136 1: HMLAN_Parse: HmLanAdapter new condition init
2015.01.05 00:09:40.235 1: HMLAN_Parse: HmLanAdapter new condition ok
2015.01.05 00:29:52.827 1: HMLAN_Parse: HmLanAdapter new condition timeout
2015.01.05 00:29:52.847 1: 192.168.188.27:1000 disconnected, waiting to reappear (HmLanAdapter)
2015.01.05 00:29:52.852 1: HMLAN_Parse: HmLanAdapter new condition disconnected
2015.01.05 00:30:59.438 1: 192.168.188.27:1000 reappeared (HmLanAdapter)
2015.01.05 00:30:59.446 1: HMLAN_Parse: HmLanAdapter new condition init
2015.01.05 00:30:59.663 1: HMLAN_Parse: HmLanAdapter new condition ok
2015.01.05 00:59:13.037 1: HMLAN_Parse: HmLanAdapter new condition timeout
2015.01.05 00:59:13.056 1: 192.168.188.27:1000 disconnected, waiting to reappear (HmLanAdapter)
2015.01.05 00:59:13.060 1: HMLAN_Parse: HmLanAdapter new condition disconnected
2015.01.05 01:00:19.701 1: 192.168.188.27:1000 reappeared (HmLanAdapter)
2015.01.05 01:00:19.708 1: HMLAN_Parse: HmLanAdapter new condition init
2015.01.05 01:00:34.546 1: HMLAN_Parse: HmLanAdapter new condition ok
2015.01.05 01:00:43.741 1: HMLAN_Parse: HmLanAdapter new condition timeout
2015.01.05 01:00:43.761 1: 192.168.188.27:1000 disconnected, waiting to reappear (HmLanAdapter)
Das letzte mal wo ich soviele Meldungen dazu hatte ist ca. 1 Monat her, und habe auch zumindest gestern und vorgestern keine Updates eingespielt, und heute dann plötzlich wieder jede Menge disconnect....,
mal abwarten was morgen passiert
Ist eintimeout, wie du sehen kannst. Irgendwer blockiert. Netzwerk, cpu oder fhem. Ich wuerde mit fhem anfangen. Kann auch dein netz sein.....
Hallo,
ich hatte auch ständig diconnects. Immer wenn ich eine Seite mit vielen SVGs aufgerufen habe.
Durch andere Netzwerkprobleme (verzögertes aufrufen der Webseite, timeouts TW etc.)
habe ich meine WLAN einstellungen kontrolliert.
Standart ist beim RPi Weezey PowerSave on (o.ä.)
Über
Zitatsudo iwconfig wlan0 power off
habe ich den Modus ausgeschaltet.
Seitdem keine disconnects und keine Probleme beim Verbindungsaufbau.
Vieleicht mal checken
Vg
Also wenn ich das jetzt richtig versteh hast du das wlan am pie worauf fhem läuft einfach deaktiviert? Kann ich natürlich auch mal versuchen, da ich eh alles über lan mache.
Es ist auch seltsam, Gesten z.b hatte ich über den ganzen Tag nur 5 disconnect, denke das ist durchaus vertretbar. Mal sehn wie es heute aussieht.
Werd dann heut Abend mal das wlan deaktivieren
Zitat von: Tommy82 am 07 Januar 2015, 08:54:17
Also wenn ich das jetzt richtig versteh hast du das wlan am pie worauf fhem läuft einfach deaktiviert? Kann ich natürlich auch mal versuchen, da ich eh alles über lan mache.
Nein nicht das komplette WLan. Nur den PowerSave Modus des WLAN.
Ich greife nur über Wlan auf den RPi.
VG
Ok kann ich auch machen, allerdings könnte ich es auch ganz abschalten, da ich es garnicht nutze
Hmmm...
einfacher und effizienter dürfte sein, einen vorhandenen W-LAN-Stick am RasPi einfach abzuziehen, wenn du ihn sowieso nicht brauchst. Und wenn du keinen W-LAN-Stick angesteckt hast, brauchst du auch nichts abzuschalten.
Gruß
Thomas
hallo,
bis gestern abend hatte ich ebenfalls immerzu verbindungsabbrüche. hmlan hängt direkt an der fritzbox. hatte bereits einiges am netzwerk versucht, nichts half. gestern abend dann die firmware neu aufgespielt. war nen megakrampf da mal ne verbindung herzustellen. das update hat dann letztendlich mit dem fw-update tool geklappt. raspi & fhem sind danach ohne weitere aktionen sofort hochgefahren und alles funktionierte. bis heute morgen keine abbrüche mehr. werde das aber weiter beobachten.
dummerweise hatte ich mir bei der aktion meinen accesspoint im wohnzimmer weggeschossen (netgear router ohne dhcp mit stat. ip). leider habe ich mich damit nen bissl blöd angestellt und musste das teil zig mal resetten bis mir wieder einfiel das es in dieser konfig. keinen sinn macht den router am dsl port mit dem netzwerk zu verbinden >:(. anyway, router hat auch ne neue fw bekommen und funzt wieder.
ich kann also nicht wirklich ausschliessen dass es keine andere ursachen für abbrüche gibt. kann sein das der router im netz kasper gemacht hat. wie gesagt, der hmlan hängt an der fritzbox die auch dhcp/internet bereit stellt.
gruss,
harry
*edit*
bis heute 11:00 keine verbindungsabbrüche
moin,
ok, da es ein nerviges problem ist, will das wahrscheinlich niemand hören. aber bis heute keine verbindungsabbrüche mehr. die funkschalter reagieren auch wieder 'sofort' auf die fernbedienung. bis jetzt alles ok. hoffe das es so bleibt.
harry
Ich hatte das gleiche nach vccu Einrichtung. Ein Neustart des pi und das Problem war weg.
Gesendet von meinem HTC One mit Tapatalk
Hi,
ich habe leider dasselbe Problem.
Ohne AES Verschlüsselung kein Problem, aber sobald ich verschlüsseln will kriege ich die besagten Fehlermeldungen.
Den aes key habe ich natürlich in fhem konfiguriert.
Vccu Einrichtung inkl. Neustart meines Raspi ist ebenfalls durch...
Hat jemand noch eine Idee?
welceh fehler tauchen auf?
gibt es probleme mit der Performance? apptime schon probiert?
ist das etherne stabil`?
15.01.19 10:49:51 1: 192.168.178.80:1000 disconnected, waiting to reappear (HMLAN_AZ)
2015.01.19 10:49:51 1: HMLAN_Parse: HMLAN_AZ new condition disconnected
2015.01.19 10:49:56 1: 192.168.178.80:1000 reappeared (HMLAN_AZ)
2015.01.19 10:49:56 1: HMLAN_Parse: HMLAN_AZ new condition init
2015.01.19 10:50:25 1: HMLAN_Parse: HMLAN_AZ new condition timeout
2015.01.19 10:50:25 1: 192.168.178.80:1000 disconnected, waiting to reappear (HMLAN_AZ)
2015.01.19 10:50:25 1: HMLAN_Parse: HMLAN_AZ new condition disconnected
2015.01.19 10:50:30 1: 192.168.178.80:1000 reappeared (HMLAN_AZ)
2015.01.19 10:50:30 1: HMLAN_Parse: HMLAN_AZ new condition init
2015.01.19 10:50:59 1: HMLAN_Parse: HMLAN_AZ new condition timeout
2015.01.19 10:50:59 1: 192.168.178.80:1000 disconnected, waiting to reappear (HMLAN_AZ)
2015.01.19 10:50:59 1: HMLAN_Parse: HMLAN_AZ new condition disconnected
2015.01.19 10:51:02 1: 192.168.178.80:1000 reappeared (HMLAN_AZ)
2015.01.19 10:51:02 1: HMLAN_Parse: HMLAN_AZ new condition init
2015.01.19 10:51:31 1: HMLAN_Parse: HMLAN_AZ new condition timeout
2015.01.19 10:51:31 1: 192.168.178.80:1000 disconnected, waiting to reappear (HMLAN_AZ)
2015.01.19 10:51:31 1: HMLAN_Parse: HMLAN_AZ new condition disconnected
2015.01.19 10:51:36 1: 192.168.178.80:1000 reappeared (HMLAN_AZ)
2015.01.19 10:51:36 1: HMLAN_Parse: HMLAN_AZ new condition init
Apptime habe ich noch nicht ausprobiert, werde ich dann die Tage mal machen. Wobei ich außer 4 Thermostate und 1 Fensterkontakt noch nichts drin habe.
ICh habe über die HM Software (nach Einrichtung) den AES key geändert. Dieser ist aber in FHEM auch eingetragen.
Zur Sicherheit habe ich auch mal den alten eingetragen, aber ebenfalls ohne Erfolg.
Gruß,
Tobias
hast du die verschlüsselung vom hmlan auf netzwerkseite über eq3 software abgeschaltet? das muss du tun, damit der hmlan mit fhem kommunizieren kann. das hat nichts mit aes im funk zu tun.
hab das Problem nun auch wieder. Keine Ahnung an was das liegt, pi neugestartet, hmlan neugestartet, mal beobachten bisher hab ich das Problem noch.
Aktuell habe ich die diesconnects ca. alle 10 Minuten. >:(
Ich wunder mich, dass in dem System überhaupt noch etwas funktioniert.
Ich behaupte mittlerweile, dass das nicht am HMLAN alleine liegen kann; es ist unterschiedlich häufig und war anfangs gar nicht.
Wie belastet ist dein router, wie sehr deine cpu und wartet fhem gelegentlich? Apptime?
hab aktuell allle 1-5 mins disconnects. hab auch nen Pi.
Was sagt apptime, was macht die performance der cpu
Apptime? CPU Performance meist 700mhz mal 1000mhz
Gesendet von meinem HTC One mit Tapatalk
Zitat von: martinp876 am 26 Januar 2015, 21:54:45
Was sagt apptime, was macht die performance der cpu
Wenn der Kasten das RSS neu generiert, ist die CPU-Last bei 100% , ABER...
das war ja schon immer so und hat zwischendurch auch mit 2 Tablets funktioniert.
Es muss noch etwas anderes sein, denn es hat sich ja wesentlich verschlimmert (bei mir).
Ich logge seit heute den ping auf den hmlan. Hier Stelle ich aktuell schon fest dass es teilweise 150ms dauert. Rest der Geräte LAN ping von 0-2ms. Vllt hat das auch was zu heißen?
Gesendet von meinem HTC One mit Tapatalk
ZitatABER...
was sagt apptime ?
Zitat von: Hollo am 26 Januar 2015, 09:31:32
Aktuell habe ich die diesconnects ca. alle 10 Minuten. >:( ...
Manchmal hilft es ja, darüber zu reden. ;D
Nachdem ich das so geschrieben habe, habe ich überlegt, was denn alle 10 Minuten passiert.
Daraufhin habe ich mal meine beiden at's readGDS und checkGDS für die DWD-Sachen disabled.
Siehe da, in 24 Stunden noch 7 disconnects, statt sonst fast alle 10 Minuten.
SCHEINBAR ist nicht die CPU-Auslastung massgeblich, sondern die Netzwerkkommunikation entscheidend.
Wäre ja auch logisch, weil der HMLAN disconnected wenn ihm das keepalive fehlt.
Ich komme wohl nicht umhin, mein FHEM testweise mal auf meinen Server umzuziehen und per FHEM2FHEM den Pi mit Sensoren und 433-Sender anzubinden.
Zitat von: Hollo am 28 Januar 2015, 08:18:56... Nachdem ich das so geschrieben habe, habe ich überlegt, was denn alle 10 Minuten passiert.
Daraufhin habe ich mal meine beiden at's readGDS und checkGDS für die DWD-Sachen disabled.
Wo ich dann immer meine Probleme damit habe, welchen tieferen Sinn es für "Otto Normalo" macht, die DWD-Daten (womöglich mit Satelliten-Fotos etc.) alle 10 Minuten zu erneuern? Selbst bei akuten Warnmeldungen mMn keinen, aber die Antwort darf sich jeder selbst geben 8)
Zitat... SCHEINBAR ist nicht die CPU-Auslastung massgeblich, sondern die Netzwerkkommunikation entscheidend. ...
Nein, sondern eher der missliebige Umstand, dass das Schreiben der DWD-Daten (und sonstiger Fhem-Log-Dateien) auf SD-Karte am RPi
und die Netzwerkkommunikation über ein und denselben IO-Controller erfolgen. Das ist ein ständig wiederkehrendes Problem.
Gruß
Thomas
Zitat von: Rohan am 28 Januar 2015, 08:40:17
Wo ich dann immer meine Probleme damit habe, welchen tieferen Sinn es für "Otto Normalo" macht, die DWD-Daten (womöglich mit Satelliten-Fotos etc.) alle 10 Minuten zu erneuern? Selbst bei akuten Warnmeldungen mMn keinen, aber die Antwort darf sich jeder selbst geben 8)
Korrekt.
Die Aktualisierung findet nur tagsüber statt, betrifft nur die Warnungen (also keine Karten etc) und sind ein "Folgeschaden" aus knapp 30 Jahren Feuerwehr. ;D
Zitat
Nein, sondern eher der missliebige Umstand, dass das Schreiben der DWD-Daten (und sonstiger Fhem-Log-Dateien) auf SD-Karte am RPi und die Netzwerkkommunikation über ein und denselben IO-Controller erfolgen. Das ist ein ständig wiederkehrendes Problem.
Du hast USB vergessen, was ja leider ebenfalls am selben Controller hängt.
Komisch nur, dass sich das öfter mal ändert. Vielleicht sollte man mit rpi-kernelupdate vorsichtiger sein. ;)
Der Pi ist nunmal eine Bastelplattform.
Ist ja nicht so, als ob ich nicht auch diese "Bastelplattform" einsetze, aber nur um zu schauen, ob es so wie angedacht läuft. Wenn es dann grundsätzlich läuft, wird umgezogen.
Mein momentanes "Bastelprojekt" ist ein RPi an dessen GPIO ein Arduino dranhängt, der 2 Gassensoren für CO und LPG/CNG (MQ-5 und MQ-9) im Umgebungsbereich meiner Gastherme ausliest. Der RPi tut nix anderes, als jede Minute die Werte an der Schnittstelle zum Arduino per Python-Skript auszulesen und auf SD-Karte in ein File zu schreiben. Einmal täglich hole ich mir vom RPi per SSH über WLAN die Datei ab und pflege sie in mein Produktiv-Fhem als Fakelog ein. Mittlerweile ist die Log-Datei über 2 MByte groß. Einmal braucht der Datentransfer nur ein paar Sekunden, an einem anderen Tag aber fast 2 Minuten (kein RPi-Neustart zwischendurch).
Da nach allem, was ich bisher über HomeMatic-Kommunikation mitbekommen habe, gerade das Timing zum IO-Device (HM-LAN, CUL, HM-USB-CFG) besonders wichtig ist, habe ich keinen Bedarf für eine Nutzung des RPi als Fhem-Zentrale, es sei denn gerade und nur für Testzwecke.
Btw: Das ganze obige Projekt soll dann demnächst direkt an Fhem angebunden werden mit E-Mail bei zu hohen Werten. Und bevor jemand schreit: Nein, die Bastel-Gassensoren sind zusätzlich neben kommerziellen Warnsensoren für CO und Erd-/Flüssiggas mit Prüfzertifikat und akustischer Alarmmeldung. Das wäre mir sonst zu heiß.
Edith möchte noch nachtragen: Mit der Vorsicht beim Kernel-Update hast du durchaus Recht (http://forum.fhem.de/index.php/topic,32858.msg252435.html). Das war mir gleich ein Bookmark wert ;)
Gruß
Thomas
Ich muss dieses Thema mal wieder ausgraben. Ich habe festgestellt, dass mein Harmony Hub und mein HMLan regelmäßig der Verbindung verlieren. Ein Intervall von ca. 2h ist manchmal zu erkennen, aber nicht immer. Jetzt habe ich mal Apptime angeschaltet und auch das Performance Modul eingebaut. Hier sind die ersten Ergebnisse:
Apptime:
name function max count total average maxDly
tmr-perfmon_ProcessTimer HASH(0x1ee5300) 0 9 0 0.00 445
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN1 0 1 0 0.00 13
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 2 1 2 2.00 5 keepAlive:HMLAN1
Alarm_Ausloesung DOIF_Notify 0 6 0 0.00 0
Alles.Ausschalten DOIF_Notify 0 6 0 0.00 0
Anwesenheit.Vergessen DOIF_Notify 0 6 0 0.00 0
FHEMWEB:192.168.2.10:50823 FW_Read 28 4 77 19.25 0 HASH(FHEMWEB:192.168.2.10:50823)
FHEMWEB:192.168.2.10:50826 FW_Read 27 3 78 26.00 0 HASH(FHEMWEB:192.168.2.10:50826)
FHEMWEB:192.168.2.10:50827 FW_Read 20 3 38 12.67 0 HASH(FHEMWEB:192.168.2.10:50827)
FHEMWEB:192.168.2.10:50828 FW_Notify 0 6 0 0.00 0
FHEMWEB:192.168.2.10:50829 FW_Read 37 3 86 28.67 0 HASH(FHEMWEB:192.168.2.10:50829)
FHEMWEB:192.168.2.10:50832 FW_Notify 0 6 0 0.00 0
FHEMWEB:192.168.2.10:50832 FW_Read 36 5 151 30.20 0 HASH(FHEMWEB:192.168.2.10:50832)
Feiertag.Check DOIF_Notify 0 6 0 0.00 0
FileLog_SZ.Heizung.R FileLog_Log 12 1 12 12.00 0 HASH(FileLog_SZ.Heizung.R); HASH(SZ.Heizung.R)
FileLog_WC.Fenster FileLog_Log 11 6 17 2.83 0 HASH(FileLog_WC.Fenster); HASH(HMLAN1)
HMLAN1 HMLAN_Notify 0 6 0 0.00 0
HMLAN1 HMLAN_Read 779 2 1110 555.00 0 HASH(HMLAN1)
Heizung.Anja.Morgens DOIF_Notify 0 6 0 0.00 0
Heizung.Etienne.Tagdienst DOIF_Notify 0 6 0 0.00 0
Heizung.SZ.1900 DOIF_Notify 0 6 0 0.00 0
Performance mit Verbose 5:
2015.09.17 10:41:50 4: Closing inactive connection FHEMWEB:192.168.2.10:65343
2015.09.17 10:41:50 4: Closing inactive connection FHEMWEB:192.168.2.10:65344
2015.09.17 10:41:50 4: Closing inactive connection FHEMWEB:192.168.2.10:65346
2015.09.17 10:41:50 4: Closing inactive connection FHEMWEB:192.168.2.10:65347
2015.09.17 10:41:50 4: Closing inactive connection FHEMWEB:192.168.2.10:65345
2015.09.17 10:42:19 1: Perfmon: possible freeze starting at 10:42:16, delay is 3.034
2015.09.17 10:43:23 1: Perfmon: possible freeze starting at 10:43:20, delay is 3.005
2015.09.17 10:44:26 1: Perfmon: possible freeze starting at 10:44:23, delay is 3.034
2015.09.17 10:45:30 1: Perfmon: possible freeze starting at 10:45:27, delay is 3.024
2015.09.17 10:46:34 1: Perfmon: possible freeze starting at 10:46:31, delay is 3.024
2015.09.17 10:47:38 1: Perfmon: possible freeze starting at 10:47:35, delay is 3.014
2015.09.17 10:48:42 1: Perfmon: possible freeze starting at 10:48:39, delay is 3.372
2015.09.17 10:49:46 1: Perfmon: possible freeze starting at 10:49:43, delay is 3.004
2015.09.17 10:50:49 1: Perfmon: possible freeze starting at 10:50:46, delay is 3.019
2015.09.17 10:51:53 1: Perfmon: possible freeze starting at 10:51:50, delay is 3.004
2015.09.17 10:52:56 1: Perfmon: possible freeze starting at 10:52:53, delay is 3.004
2015.09.17 10:53:59 1: Perfmon: possible freeze starting at 10:53:56, delay is 3.016
2015.09.17 10:55:03 1: Perfmon: possible freeze starting at 10:55:00, delay is 3.004
2015.09.17 10:56:06 1: Perfmon: possible freeze starting at 10:56:03, delay is 3.015
2015.09.17 10:57:10 1: Perfmon: possible freeze starting at 10:57:07, delay is 3.004
2015.09.17 10:57:32 1: Perfmon: possible freeze starting at 10:57:31, delay is 1.163
2015.09.17 10:58:13 1: Perfmon: possible freeze starting at 10:58:10, delay is 3.024
2015.09.17 10:59:17 1: Perfmon: possible freeze starting at 10:59:14, delay is 3.004
2015.09.17 11:00:20 1: Perfmon: possible freeze starting at 11:00:17, delay is 3.01
2015.09.17 11:01:23 1: Perfmon: possible freeze starting at 11:01:20, delay is 3.024
2015.09.17 11:02:27 1: Perfmon: possible freeze starting at 11:02:24, delay is 3.014
2015.09.17 11:03:31 1: Perfmon: possible freeze starting at 11:03:28, delay is 3.011
2015.09.17 11:04:35 1: Perfmon: possible freeze starting at 11:04:32, delay is 3.019
2015.09.17 11:05:38 1: Perfmon: possible freeze starting at 11:05:35, delay is 3.01
2015.09.17 11:06:42 1: Perfmon: possible freeze starting at 11:06:39, delay is 3.021
2015.09.17 11:07:45 1: Perfmon: possible freeze starting at 11:07:43, delay is 2.669
2015.09.17 11:08:49 1: Perfmon: possible freeze starting at 11:08:46, delay is 3.311
2015.09.17 11:09:53 1: Perfmon: possible freeze starting at 11:09:50, delay is 3.004
2015.09.17 11:10:56 1: Perfmon: possible freeze starting at 11:10:53, delay is 3.014
2015.09.17 11:12:00 1: Perfmon: possible freeze starting at 11:11:57, delay is 3.004
2015.09.17 11:13:03 1: Perfmon: possible freeze starting at 11:13:00, delay is 3.104
2015.09.17 11:14:07 1: Perfmon: possible freeze starting at 11:14:04, delay is 3.015
2015.09.17 11:15:11 1: Perfmon: possible freeze starting at 11:15:08, delay is 3.014
2015.09.17 11:16:29 2: HarmonyHub: disconnect
2015.09.17 11:16:29 1: 192.168.2.104:1000 disconnected, waiting to reappear (HMLAN1)
2015.09.17 11:16:29 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.09.17 11:16:33 1: Perfmon: possible freeze starting at 11:15:56, delay is 37.044
2015.09.17 11:16:33 3: HarmonyHub: connected
2015.09.17 11:16:33 1: 192.168.2.104:1000 reappeared (HMLAN1)
2015.09.17 11:16:33 1: HMLAN_Parse: HMLAN1 new condition init
2015.09.17 11:16:34 1: HMLAN_Parse: HMLAN1 new condition ok
2015.09.17 11:16:52 3: HarmonyHub: new config
2015.09.17 11:16:52 1: Perfmon: possible freeze starting at 11:16:36, delay is 16.883
2015.09.17 11:17:37 1: Perfmon: possible freeze starting at 11:17:34, delay is 3.025
2015.09.17 11:18:41 1: Perfmon: possible freeze starting at 11:18:38, delay is 3.014
2015.09.17 11:19:45 1: Perfmon: possible freeze starting at 11:19:42, delay is 3.004
2015.09.17 11:20:48 1: Perfmon: possible freeze starting at 11:20:45, delay is 3.001
2015.09.17 11:21:51 1: Perfmon: possible freeze starting at 11:21:48, delay is 3.002
2015.09.17 11:22:54 1: Perfmon: possible freeze starting at 11:22:51, delay is 3.013
2015.09.17 11:23:58 1: Perfmon: possible freeze starting at 11:23:55, delay is 3.003
2015.09.17 11:25:01 1: Perfmon: possible freeze starting at 11:24:58, delay is 3.003
2015.09.17 11:26:04 1: Perfmon: possible freeze starting at 11:26:01, delay is 3.003
2015.09.17 11:27:07 1: Perfmon: possible freeze starting at 11:27:04, delay is 3.004
2015.09.17 11:28:10 1: Perfmon: possible freeze starting at 11:28:07, delay is 3.004
2015.09.17 11:29:13 1: Perfmon: possible freeze starting at 11:29:10, delay is 3.004
2015.09.17 11:30:16 1: Perfmon: possible freeze starting at 11:30:13, delay is 3.013
2015.09.17 11:30:28 4: Connection accepted from FHEMWEB:192.168.2.10:50823
2015.09.17 11:30:28 4: HTTP FHEMWEB:192.168.2.10:50823 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2015-09.log
Allerdings werde ich leider nicht schlau darauf, was nun den Delay auslöst, dass sowohl das Harmony Hub, als auch der HMLan sich neu Verbinden muss?? Offensichtlich ist es wohl das erste bei Apptime, was ein sehr langes Delay hat, aber was ist das??
apptime mit option max aufrufen und perfmon bringt (meist) nur etwas in verbindung mit global verbose 5.
Zitat von: frank am 17 September 2015, 11:48:24
apptime mit option max aufrufen und perfmon bringt (meist) nur etwas in verbindung mit global verbose 5.
Wie gesagt, Verbose 5 ist eingeschaltet und oben auch der Code aus dem Log eingefügt. Oder was möchtest du mir damit sagen?
ZitatWie gesagt, Verbose 5 ist eingeschaltet und oben auch der Code aus dem Log eingefügt. Oder was möchtest du mir damit sagen?
dann muss im log mehr zu sehen sein.
Wo hast du verbose 5 eingestellt? frank sprach von "global verbose 5". Also verbose 5 im Device global nicht in einem anderen Device.
Verrückte FHEM-Welt. Habe ich doch tatsächlich nicht bei global Verbose 5 eingestellt, sondern bei WEB. :D
Na gut, dann warten wir jetzt nochmal ein bisschen auf das nächste aufhängen und schauen dann was passiert. Danke für den Hinweis. :-[
Zitat von: Amenophis86 am 17 September 2015, 12:54:31
Verrückte FHEM-Welt.
Hm. Eigentlich ist das sehr logisch. Zudem hat frank ja geschrieben, wo es eingestellt werden muss ;)
Der erste Blick sollte m.E. immer zu der uptime des HMLAN führen ... wie bereits mehrfach hier beschrieben rebootet der HMLAN bei mir manchmal im Minutentakt und dann sind die disconnects nicht von Fhem sondern durch die Reboots hervorgerufen.
Reboots können von fehlenden keepalive kommen, also von schlechten Verbindungen oder timing Problemen in fhem.
Es kann auch an unsauberen messages liegen....das sollte ader nicht der Fall sein, das Problem hätten auch andere
Das Harmony Hub hatte seit ich Verbose 5 eingestellt hab, bisher kein Verbindungsverlust mehr. Und der HMLan vorhin das erste Mal. Das Log davor hat folgendes ausgegeben:
2015.09.17 18:28:05 5: HMLAN_Parse: HMLAN1 R:E309275 stat:0000 t:0843B532 d:FF r:FFDF m:35 A03F 309275 26EEC9
2015.09.17 18:28:05 5: HMLAN1 dispatch A0935A03F30927526EEC9::-33:HMLAN1
2015.09.17 18:28:05 5: HMLAN_Send: HMLAN1 S:+309275,00,00,00
2015.09.17 18:28:05 5: HMLAN_Send: HMLAN1 S:SDC2264D8 stat: 00 t:00000000 d:01 r:DC2264D8 m:35 803F 26EEC9 309275 02041D8DA695
2015.09.17 18:28:05 5: CUL_HM WZ.Heizung.R protEvent:CMDs_done
2015.09.17 18:28:05 5: CUL_HM WZ.Heizung.R sent ACK:2
2015.09.17 18:28:05 5: Triggering WZ.Heizung.R (2 changes)
2015.09.17 18:28:05 5: Notify loop for WZ.Heizung.R CMDs_done
2015.09.17 18:28:11 5: HMLAN_Send: HMLAN1 I:K
2015.09.17 18:28:11 4: HarmonyHub: send: <iq type='get' id='ping-439'><ping xmlns='urn:xmpp:ping'/></iq>
2015.09.17 18:28:11 5: HarmonyHub: tag: iq, attr: id='ping-439' type='result'
2015.09.17 18:28:11 5: HarmonyHub: got ping response 439
2015.09.17 18:28:12 5: HMLAN_Send: HMLAN1 I:K
2015.09.17 18:28:13 5: HMLAN_Send: HMLAN1 I:K
2015.09.17 18:28:14 5: HMLAN_Send: HMLAN1 I:K
2015.09.17 18:28:15 1: HMLAN_Parse: HMLAN1 new condition timeout
2015.09.17 18:28:15 5: Triggering HMLAN1 (3 changes)
2015.09.17 18:28:15 5: Notify loop for HMLAN1 cond: timeout
2015.09.17 18:28:15 5: Triggering myVCCU (1 changes)
2015.09.17 18:28:15 5: Notify loop for myVCCU HMLAN1:timeout,
2015.09.17 18:28:15 1: 192.168.2.104:1000 disconnected, waiting to reappear (HMLAN1)
2015.09.17 18:28:15 5: Triggering HMLAN1 (1 changes)
2015.09.17 18:28:15 5: Notify loop for HMLAN1 DISCONNECTED
2015.09.17 18:28:15 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.09.17 18:28:15 5: Triggering HMLAN1 (4 changes)
2015.09.17 18:28:15 5: Triggering myVCCU (1 changes)
2015.09.17 18:28:15 5: Notify loop for myVCCU HMLAN1:disconnected,
2015.09.17 18:28:19 1: Perfmon: possible freeze starting at 18:28:16, delay is 3.012
2015.09.17 18:28:24 1: Perfmon: possible freeze starting at 18:28:21, delay is 3.006
2015.09.17 18:29:01 4: HarmonyHub: send: <iq type='get' id='ping-440'><ping xmlns='urn:xmpp:ping'/></iq>
2015.09.17 18:29:01 5: HarmonyHub: tag: iq, attr: id='ping-440' type='result'
2015.09.17 18:29:01 5: HarmonyHub: got ping response 440
2015.09.17 18:29:07 4: Connection accepted from FHEMWEB:192.168.2.10:55439
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem?room=S_DOIF
2015.09.17 18:29:07 4: 7938:FHEMWEB:192.168.2.10:55439: /fhem?room=S_DOIF / RL:1756 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.09.17 18:29:07 4: Connection closed for FHEMWEB:192.168.2.10:55372: EOF
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/style.css
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_colorpicker.js
2015.09.17 18:29:07 4: Connection accepted from FHEMWEB:192.168.2.10:55440
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_fbcalllist.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/jquery-ui.min.css
2015.09.17 18:29:07 4: Connection accepted from FHEMWEB:192.168.2.10:55441
2015.09.17 18:29:07 4: Connection accepted from FHEMWEB:192.168.2.10:55442
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55441 GET /fhem/pgm2/jquery.min.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_knob.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/darkCommon.css
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/jquery-ui.min.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55441 GET /fhem/pgm2/fhemweb_readingsGroup.js
2015.09.17 18:29:07 4: Connection accepted from FHEMWEB:192.168.2.10:55443
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/fhemweb_sortable.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_readingsHistory.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem/pgm2/fhemweb.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/images/default/icoEverything.png
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/dashboard_darkstyle.css
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55441 GET /fhem/pgm2/fhemweb_uzsu.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55441 GET /fhem/images/default/fhemicon_dark.png
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55441 GET /fhem?XHR=1&inform=type=status;filter=room=S_DOIF;since=1442507346;fmt=JSON×tamp=1442507348116
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem?detail=Heizung.Wohnraum
2015.09.17 18:29:13 4: 7938:FHEMWEB:192.168.2.10:55442: /fhem?detail=Heizung.Wohnraum / RL:3304 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.09.17 18:29:13 4: Connection closed for FHEMWEB:192.168.2.10:55441: EOF
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/jquery-ui.min.css
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/style.css
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem/pgm2/jquery.min.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/fhemweb_colorpicker.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/jquery-ui.min.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/fhemweb_fbcalllist.js
2015.09.17 18:29:13 4: Connection accepted from FHEMWEB:192.168.2.10:55444
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/fhemweb_readingsHistory.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_readingsGroup.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/darkCommon.css
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem/pgm2/fhemweb_knob.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55444 GET /fhem/pgm2/fhemweb.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/fhemweb_sortable.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_uzsu.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/images/default/icoEverything.png
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem/pgm2/dashboard_darkstyle.css
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem/images/default/fhemicon_dark.png
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem?cmd={ReadingsVal(%22Heizung.Wohnraum%22,%22disable%22,%22%22)}&XHR=1
2015.09.17 18:29:13 5: Cmd: >{ReadingsVal("Heizung.Wohnraum","disable","")}<
2015.09.17 18:29:13 4: 7938:FHEMWEB:192.168.2.10:55443: /fhem?cmd={ReadingsVal(%22Heizung.Wohnraum%22,%22disable%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem?cmd={AttrVal(%22Heizung.Wohnraum%22,%22room%22,%22%22)}&XHR=1
2015.09.17 18:29:13 5: Cmd: >{AttrVal("Heizung.Wohnraum","room","")}<
2015.09.17 18:29:13 4: 7938:FHEMWEB:192.168.2.10:55440: /fhem?cmd={AttrVal(%22Heizung.Wohnraum%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem?XHR=1&inform=type=status;filter=Heizung.Wohnraum;since=1442507352;fmt=JSON×tamp=1442507354168
2015.09.17 18:29:20 1: 192.168.2.104:1000 reappeared (HMLAN1)
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:A26EEC9
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:C
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+26924E,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2AB1CD,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+269027,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2BCDB0,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+303868,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+290540,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+35367D,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2BA5BD,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2BCF78,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2FE033,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+309275,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+28C16A,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+26982D,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2FE139,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+269591,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2BCCC8,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2BCD3B,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+353807,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:Y01,00,
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:Y02,00,
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:Y03,00,
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:T1D8DA6E0,04,00,00000000
2015.09.17 18:29:20 1: HMLAN_Parse: HMLAN1 new condition init
2015.09.17 18:29:20 5: Triggering HMLAN1 (3 changes)
2015.09.17 18:29:20 5: Notify loop for HMLAN1 cond: init
2015.09.17 18:29:20 5: ZE.Batterie: no longer visible, ignoring notify
2015.09.17 18:29:20 5: Triggering myVCCU (1 changes)
2015.09.17 18:29:20 5: Notify loop for myVCCU HMLAN1:init,
2015.09.17 18:29:20 5: ZE.Batterie: not on any display, ignoring notify
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 S:SDC238903 stat: 00 t:00000000 d:01 r:DC238903 m:99 8112 26EEC9 000000
2015.09.17 18:29:20 5: Triggering HMLAN1 (1 changes)
2015.09.17 18:29:20 5: Notify loop for HMLAN1 CONNECTED
der harmony hub erwartet jede minute ein keepalive. das modul sendet es 50 sekunden. kleinere abweichungen sind aber nicht so kritisch wie bei hmlan.
gruss
andre
wie gesagt, hat das Hub auch nicht mehr gemeckert seit heute Mittag. Nur der HMLan hat sich mal wieder verabschiedet. Vll kann ja einer in dem Log oben etwas erkennen, ich sehe keinen Fehler. Meine Kenntnisse sind aber auch beschränkt.
Zitat von: martinp876 am 17 September 2015, 20:19:52
Reboots können von fehlenden keepalive kommen,
Bist du sicher ? Ich habe selbst einen Monitor programmiert der die Messages vom HMLAN liest aber NIE einen keepalive sendet ... reboots passieren da keine
Nein, nicht sicher. Es gibt sicher einen disconnect wenn nach 30s kein keepalive gekommen ist. Ob die uptime auf 0 gesetzt wird kann ich eigentlich nicht sagen.
uptime, bzw. genauer: der x8 Zeitstempel-Wert in den Telegrammen, wird dabei NICHT auf Null gesetzt
2015.09.17 18:28:05 5: HMLAN_Parse: HMLAN1 R:E309275 stat:0000 t:0843B532 d:FF r:FFDF m:35 A03F 309275 26EEC9
2015.09.17 18:28:05 5: HMLAN1 dispatch A0935A03F30927526EEC9::-33:HMLAN1
2015.09.17 18:28:05 5: HMLAN_Send: HMLAN1 S:+309275,00,00,00
2015.09.17 18:28:05 5: HMLAN_Send: HMLAN1 S:SDC2264D8 stat: 00 t:00000000 d:01 r:DC2264D8 m:35 803F 26EEC9 309275 02041D8DA695
2015.09.17 18:28:05 5: CUL_HM WZ.Heizung.R protEvent:CMDs_done
2015.09.17 18:28:05 5: CUL_HM WZ.Heizung.R sent ACK:2
2015.09.17 18:28:05 5: Triggering WZ.Heizung.R (2 changes)
2015.09.17 18:28:05 5: Notify loop for WZ.Heizung.R CMDs_done
2015.09.17 18:28:11 5: HMLAN_Send: HMLAN1 I:K
2015.09.17 18:28:11 4: HarmonyHub: send: <iq type='get' id='ping-439'><ping xmlns='urn:xmpp:ping'/></iq>
2015.09.17 18:28:11 5: HarmonyHub: tag: iq, attr: id='ping-439' type='result'
2015.09.17 18:28:11 5: HarmonyHub: got ping response 439
2015.09.17 18:28:12 5: HMLAN_Send: HMLAN1 I:K
2015.09.17 18:28:13 5: HMLAN_Send: HMLAN1 I:K
2015.09.17 18:28:14 5: HMLAN_Send: HMLAN1 I:K
2015.09.17 18:28:15 1: HMLAN_Parse: HMLAN1 new condition timeout
2015.09.17 18:28:15 5: Triggering HMLAN1 (3 changes)
2015.09.17 18:28:15 5: Notify loop for HMLAN1 cond: timeout
2015.09.17 18:28:15 5: Triggering myVCCU (1 changes)
2015.09.17 18:28:15 5: Notify loop for myVCCU HMLAN1:timeout,
2015.09.17 18:28:15 1: 192.168.2.104:1000 disconnected, waiting to reappear (HMLAN1)
2015.09.17 18:28:15 5: Triggering HMLAN1 (1 changes)
2015.09.17 18:28:15 5: Notify loop for HMLAN1 DISCONNECTED
2015.09.17 18:28:15 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.09.17 18:28:15 5: Triggering HMLAN1 (4 changes)
2015.09.17 18:28:15 5: Triggering myVCCU (1 changes)
2015.09.17 18:28:15 5: Notify loop for myVCCU HMLAN1:disconnected,
2015.09.17 18:28:19 1: Perfmon: possible freeze starting at 18:28:16, delay is 3.012
2015.09.17 18:28:24 1: Perfmon: possible freeze starting at 18:28:21, delay is 3.006
2015.09.17 18:29:01 4: HarmonyHub: send: <iq type='get' id='ping-440'><ping xmlns='urn:xmpp:ping'/></iq>
2015.09.17 18:29:01 5: HarmonyHub: tag: iq, attr: id='ping-440' type='result'
2015.09.17 18:29:01 5: HarmonyHub: got ping response 440
2015.09.17 18:29:07 4: Connection accepted from FHEMWEB:192.168.2.10:55439
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem?room=S_DOIF
2015.09.17 18:29:07 4: 7938:FHEMWEB:192.168.2.10:55439: /fhem?room=S_DOIF / RL:1756 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.09.17 18:29:07 4: Connection closed for FHEMWEB:192.168.2.10:55372: EOF
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/style.css
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_colorpicker.js
2015.09.17 18:29:07 4: Connection accepted from FHEMWEB:192.168.2.10:55440
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_fbcalllist.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/jquery-ui.min.css
2015.09.17 18:29:07 4: Connection accepted from FHEMWEB:192.168.2.10:55441
2015.09.17 18:29:07 4: Connection accepted from FHEMWEB:192.168.2.10:55442
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55441 GET /fhem/pgm2/jquery.min.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_knob.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/darkCommon.css
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/jquery-ui.min.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55441 GET /fhem/pgm2/fhemweb_readingsGroup.js
2015.09.17 18:29:07 4: Connection accepted from FHEMWEB:192.168.2.10:55443
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/fhemweb_sortable.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_readingsHistory.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem/pgm2/fhemweb.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/images/default/icoEverything.png
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/dashboard_darkstyle.css
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55441 GET /fhem/pgm2/fhemweb_uzsu.js
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55441 GET /fhem/images/default/fhemicon_dark.png
2015.09.17 18:29:07 4: HTTP FHEMWEB:192.168.2.10:55441 GET /fhem?XHR=1&inform=type=status;filter=room=S_DOIF;since=1442507346;fmt=JSON×tamp=1442507348116
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem?detail=Heizung.Wohnraum
2015.09.17 18:29:13 4: 7938:FHEMWEB:192.168.2.10:55442: /fhem?detail=Heizung.Wohnraum / RL:3304 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2015.09.17 18:29:13 4: Connection closed for FHEMWEB:192.168.2.10:55441: EOF
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/jquery-ui.min.css
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/style.css
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem/pgm2/jquery.min.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/fhemweb_colorpicker.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/jquery-ui.min.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/fhemweb_fbcalllist.js
2015.09.17 18:29:13 4: Connection accepted from FHEMWEB:192.168.2.10:55444
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/fhemweb_readingsHistory.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_readingsGroup.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/pgm2/darkCommon.css
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem/pgm2/fhemweb_knob.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55444 GET /fhem/pgm2/fhemweb.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55442 GET /fhem/pgm2/fhemweb_sortable.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55439 GET /fhem/pgm2/fhemweb_uzsu.js
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem/images/default/icoEverything.png
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem/pgm2/dashboard_darkstyle.css
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem/images/default/fhemicon_dark.png
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55443 GET /fhem?cmd={ReadingsVal(%22Heizung.Wohnraum%22,%22disable%22,%22%22)}&XHR=1
2015.09.17 18:29:13 5: Cmd: >{ReadingsVal("Heizung.Wohnraum","disable","")}<
2015.09.17 18:29:13 4: 7938:FHEMWEB:192.168.2.10:55443: /fhem?cmd={ReadingsVal(%22Heizung.Wohnraum%22,%22disable%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem?cmd={AttrVal(%22Heizung.Wohnraum%22,%22room%22,%22%22)}&XHR=1
2015.09.17 18:29:13 5: Cmd: >{AttrVal("Heizung.Wohnraum","room","")}<
2015.09.17 18:29:13 4: 7938:FHEMWEB:192.168.2.10:55440: /fhem?cmd={AttrVal(%22Heizung.Wohnraum%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2015.09.17 18:29:13 4: HTTP FHEMWEB:192.168.2.10:55440 GET /fhem?XHR=1&inform=type=status;filter=Heizung.Wohnraum;since=1442507352;fmt=JSON×tamp=1442507354168
2015.09.17 18:29:20 1: 192.168.2.104:1000 reappeared (HMLAN1)
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:A26EEC9
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:C
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+26924E,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2AB1CD,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+269027,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2BCDB0,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+303868,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+290540,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+35367D,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2BA5BD,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2BCF78,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2FE033,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+309275,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+28C16A,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+26982D,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2FE139,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+269591,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2BCCC8,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+2BCD3B,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:+353807,00,00,00
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:Y01,00,
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:Y02,00,
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:Y03,00,
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 I:T1D8DA6E0,04,00,00000000
2015.09.17 18:29:20 1: HMLAN_Parse: HMLAN1 new condition init
2015.09.17 18:29:20 5: Triggering HMLAN1 (3 changes)
2015.09.17 18:29:20 5: Notify loop for HMLAN1 cond: init
2015.09.17 18:29:20 5: ZE.Batterie: no longer visible, ignoring notify
2015.09.17 18:29:20 5: Triggering myVCCU (1 changes)
2015.09.17 18:29:20 5: Notify loop for myVCCU HMLAN1:init,
2015.09.17 18:29:20 5: ZE.Batterie: not on any display, ignoring notify
2015.09.17 18:29:20 5: HMLAN_Send: HMLAN1 S:SDC238903 stat: 00 t:00000000 d:01 r:DC238903 m:99 8112 26EEC9 000000
2015.09.17 18:29:20 5: Triggering HMLAN1 (1 changes)
2015.09.17 18:29:20 5: Notify loop for HMLAN1 CONNECTED
und
2015.09.18 01:27:17 5: HMLAN_Parse: HMLAN1 R:E2BCD3B stat:0000 t:017F8E6A d:FF r:FFD3 m:30 A03F 2BCD3B 26EEC9
2015.09.18 01:27:17 5: HMLAN1 dispatch A0930A03F2BCD3B26EEC9::-45:HMLAN1
2015.09.18 01:27:17 5: HMLAN_Send: HMLAN1 S:+2BCD3B,00,00,00
2015.09.18 01:27:17 5: HMLAN_Send: HMLAN1 S:SDDA22DB7 stat: 00 t:00000000 d:01 r:DDA22DB7 m:30 803F 26EEC9 2BCD3B 02041D8E08D5
2015.09.18 01:27:17 5: CUL_HM WZ.Heizung.L protEvent:CMDs_done
2015.09.18 01:27:17 5: CUL_HM WZ.Heizung.L sent ACK:2
2015.09.18 01:27:17 5: Triggering WZ.Heizung.L (2 changes)
2015.09.18 01:27:17 5: Notify loop for WZ.Heizung.L CMDs_done
2015.09.18 01:27:17 5: ZE.Batterie: not on any display, ignoring notify
2015.09.18 01:27:38 5: HMLAN_Send: HMLAN1 I:K
2015.09.18 01:27:39 5: HMLAN_Send: HMLAN1 I:K
2015.09.18 01:27:40 5: HMLAN_Send: HMLAN1 I:K
2015.09.18 01:27:41 5: HMLAN_Send: HMLAN1 I:K
2015.09.18 01:27:42 1: HMLAN_Parse: HMLAN1 new condition timeout
2015.09.18 01:27:42 5: Triggering HMLAN1 (3 changes)
2015.09.18 01:27:42 5: Notify loop for HMLAN1 cond: timeout
2015.09.18 01:27:42 5: ZE.Batterie: not on any display, ignoring notify
2015.09.18 01:27:42 5: Triggering myVCCU (1 changes)
2015.09.18 01:27:42 5: Notify loop for myVCCU HMLAN1:timeout,
2015.09.18 01:27:42 5: ZE.Batterie: not on any display, ignoring notify
2015.09.18 01:27:42 1: 192.168.2.104:1000 disconnected, waiting to reappear (HMLAN1)
2015.09.18 01:27:42 5: Triggering HMLAN1 (1 changes)
2015.09.18 01:27:42 5: Notify loop for HMLAN1 DISCONNECTED
2015.09.18 01:27:42 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.09.18 01:27:42 5: Triggering HMLAN1 (4 changes)
2015.09.18 01:27:42 5: Triggering myVCCU (1 changes)
2015.09.18 01:27:42 5: Notify loop for myVCCU HMLAN1:disconnected,
2015.09.18 01:27:42 5: ZE.Batterie: not on any display, ignoring notify
2015.09.18 01:27:42 5: ZE.Batterie: not on any display, ignoring notify
2015.09.18 01:27:44 1: 192.168.2.104:1000 reappeared (HMLAN1)
kann jemand hieraus erkennen, wieso der HMLan sich zwei Mal disconnected hat und mir damit bei der Fehler Beseitigung helfen?
schau doch mal nach der uptime des HMLAN
Zitat von: martinp876 am 17 September 2015, 22:35:00
Nein, nicht sicher. Es gibt sicher einen disconnect wenn nach 30s kein keepalive gekommen ist. Ob die uptime auf 0 gesetzt wird kann ich eigentlich nicht sagen.
ich hatte auch schon mal tests gemacht mit einem blockierenden sleep, um einen reboot des hmlan zu erzwingen. das war mir aber nicht gelungen. ob es in dieser zeit einen "normalen" disconnect gab, kann ich nicht sagen. fhem hatte ich mindestens für 5 minuten blockiert und es gab nie einen reboot.
jedenfalls habe ich festgestellt, sobald fhem condition=timeout meldet, muss ein reboot des hmlan erfolgt sein, da die load immer zurückgesetzt wurde. bei einem "normalen" disconnect passiert dies nicht.
da die letzten beiden geposteten disconnects in verbindung mit einem timeout stattgefunden haben, behaupte ich, dass diese disconnects nicht durch eine blockade von fhem (fehlende keepalive) hervorgerufen wurden. auch perfmon bestätigt dies, da keine freezes zu den zeitpunkten geloggt wurden.
es bleibt also die frage, warum der hmlan rebootet.
wenn überhaupt, kann es wohl nur aus einem lan mitschnitt ermittelt werden. da nobby noch nie einen reboot mit seinem monitor hatte, müsste es ja dann eigentlich an unterschiedlichen connections zum hmlan liegen, so dass eine connction von fhem zum hmlan diesen "anfällig" für reboots macht. dann wäre es ja interessant zu erfahren, welche unterschiede es hier gibt.
gruss frank
Zitat von: Nobby1805 am 18 September 2015, 10:44:57
schau doch mal nach der uptime des HMLAN
Die Uptime passt genau zum letzten Disconncet.
Zitat von: frank am 18 September 2015, 12:20:22
wenn überhaupt, kann es wohl nur aus einem lan mitschnitt ermittelt werden. da nobby noch nie einen reboot mit seinem monitor hatte, müsste es ja dann eigentlich an unterschiedlichen connections zum hmlan liegen, so dass eine connction von fhem zum hmlan diesen "anfällig" für reboots macht. dann wäre es ja interessant zu erfahren, welche unterschiede es hier gibt.
Aktuell ist das ganze wie folgt angeschlossen:
Router <-> Switch <-> HMLan alles per LANKabel.
Wenn du mir sagst, wie ich einen WLan Mitschnitt mache, dann kann ich das überprüfen. Die Steckdose, in der der HMLan sitzt ist eine Mehrfachsteckdose, welche sich nicht schalten lässt. Ein Stromverlust kann somit eigentlich ausgeschlossen werden, da sonst auch der PI (gleiche Mehrfachsteckdose) mit neustarten müsste und dies ist ja nicht der Fall.
Zitat von: frank am 18 September 2015, 12:20:22
es bleibt also die frage, warum der hmlan rebootet.
diese Frage habe ich auch an ELV und ELV dann an eQ3 gestellt ... leider bis heute noch keine Antwort
Zitat
wenn überhaupt, kann es wohl nur aus einem lan mitschnitt ermittelt werden. da nobby noch nie einen reboot mit seinem monitor hatte, müsste es ja dann eigentlich an unterschiedlichen connections zum hmlan liegen, so dass eine connction von fhem zum hmlan diesen "anfällig" für reboots macht. dann wäre es ja interessant zu erfahren, welche unterschiede es hier gibt.
das muss ich etwas präzisieren ... ich habe mit dem Monitor schon reboots festgestellt ... am normalen LAN genau so häufig, aber nicht gleichzeitig, zum HMLAN der am Fhem hängt ... dann auf Bitte von ELV/eQ3 an einem LAN an dem nur eine Rechner und der HMLAN hängt sehr, sehr selten
Es liegt aus meiner Sicht also an bestimmten Paketen auf dem LAN ... ein normaler Netzwerk-Sniff auf dem Rechner auf dem auch Fhem bzw. der Monitor läuft zeigt zu den Zeiten wo die reboots stattfinden nichts Auffäliges. Eigentlich müsste man ja direkt den Port des HMLAN sniffen, aber leider habe ich keinen Zugriff auf einen Hardware-Sniffer (mehr).
@Amenophis86: hast du bei dir im Netz Geräte die mit Multicast arbeiten? Z.B. Telekom Entertain ?
PS ich habe für den HMLAN ein User-Reading eingerichtet das die Uptime als Reading "wandelt" und sie dadurch in den Log schreibt, da habe ich dann gefunden, das manchmal die Reboots im Abstand von wenigen Minuten stattfinden ... ok, xyz ist vielleicht nicht der sinnvollste Name dafür :o
userReadings
xyz {substr(InternalVal("HMLAN1","uptime",""),4,length(InternalVal("HMLAN1","uptime",""))-11)}
die wenigsten disconnects gibt es wohl, wenn fhem und der hmlan möglichst ohne weitere netzwerkkomponenten am selben router/switch hängen. und beachten, der hmlan kann nur 100mbit. hat nobby ja gerade bestätigt.
meine fritzbox hat wireshark zum mitschneiden direkt auf der box.
wie schonmal irgendwo gesagt, hatte ich regelmässige reboots des hmlan kurz nach mitternacht beobachtet, im zusammenhang mit dem setzen der uhrzeit an meinen hm-cc-tc. nicht jeden tag und auch nicht immer mit dem selben tc, aber auffällig häufig. seitdem diese vom hmusb bedient werden, ist mit diesen mitternächtlichen reboots schluss.
Zitat von: Nobby1805 am 18 September 2015, 13:23:45
@Amenophis86: hast du bei dir im Netz Geräte die mit Multicast arbeiten? Z.B. Telekom Entertain ?
Ja, habe Telekom Entertain. Kann aber zu den Uhrzeiten wo der HMLan sich disconnceted keine Verbindung zu Telekom Entertain feststellen. Die Box war nur im Standby.
Zitat von: frank am 18 September 2015, 13:40:25
die wenigsten disconnects gibt es wohl, wenn fhem und der hmlan möglichst ohne weitere netzwerkkomponenten am selben router/switch hängen. und beachten, der hmlan kann nur 100mbit. hat nobby ja gerade bestätigt.
Beide hängen am gleichen Switch, welches bis zu 1GBit kann. Der PI jedoch an einem Medium Port und der HMLan am Standardport. Es handelt sich um ein Zyxel GS-108B v2 (http://www.zyxel.com/uk/en/products_services/gs_108b.shtml) Natürliche hängen an dem Switch noch andere Komponenten, wie zB die Synology NAS. Der Entertain Reciver hingegen hängt direkt am Speedport.
http://forum.fhem.de/index.php/topic,28689.msg266106.html#msg266106 (http://forum.fhem.de/index.php/topic,28689.msg266106.html#msg266106)
Zitat von: frank am 18 September 2015, 15:03:13
http://forum.fhem.de/index.php/topic,28689.msg266106.html#msg266106 (http://forum.fhem.de/index.php/topic,28689.msg266106.html#msg266106)
Habe ich jetzt 2x Mal gelesen und immer noch nicht ganz verstanden.
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 :-)
Was möchte er damit sagen?
Zitat von: Hollo am 25 Februar 2015, 18:30:04
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.
Habe nirgends etwas gefunden, was mich auf eine Konfiguration des Switches lässt um so etwas einzustellen. Das Switch selbst hat auch keine IP Adresse, zumindest auf dem Speedport nicht zu erkennen, um auf ein Webinterface oder ähnliches zuzugreifen.
Zitat von: frank am 18 September 2015, 13:40:25
...und beachten, der hmlan kann nur 100mbit. hat nobby ja gerade bestätigt...
Wer sagt das? Ich habe da was von 10MBit halbduplex im Kopf. :-\
meine bedienungsanleitung => Ethernet, 10/100Base-T
Zitat von: frank am 18 September 2015, 15:55:22
meine bedienungsanleitung => Ethernet, 10/100Base-T
war wohl falsch/schlecht von mir ausgedrückt. Versuchen wir es neu:
Bei diesem Switch kann man leider nicht die Geschwindigkeit des Ports beschränken. Es gibt generell kein Interface um etwas einzustellen. Es ist ein reines Plug&Play Gerät.
D.h. vermutlich, dass ich mit den Connection Verlust vorerst leben muss. Trotzdem danke :)
Zitat von: Amenophis86 am 18 September 2015, 14:38:06
Ja, habe Telekom Entertain. Kann aber zu den Uhrzeiten wo der HMLan sich disconnceted keine Verbindung zu Telekom Entertain feststellen. Die Box war nur im Standby.
Auch wenn die Box im Standby ist findet Kommunikation statt ... und die verwendeten Multicast-Pakete werden von den meisten SOHO-Switch/Routern überall weitergeleitet .. und der von dir verwendete Switch kann auch keine Broadcast-Filterung
Edit: abschalten von Entertain ist natürlich auch keine Lösung ... ich werde jetzt noch mal bei ELV/eQ3 nachhaken ... falls von da etwas kommt melde ich mich hier
ZitatD.h. vermutlich, dass ich mit den Connection Verlust vorerst leben muss.
wenn du alles so lässt, wie es ist, dann sieht es wohl danach aus.
Zitat von: Nobby1805 am 18 September 2015, 16:34:02
Edit: abschalten von Entertain ist natürlich auch keine Lösung ... ich werde jetzt noch mal bei ELV/eQ3 nachhaken ... falls von da etwas kommt melde ich mich hier
Wollte mal fragen, ob es etwas Neues von ELV/eQ3 gibt?
also bei mir klappt es mit dem HMLAN und Entertain super gut ...
Achte beim Switch darauf, dass er IGMP V3 !!!! kann. Dann bekommt der Port wo der HMLAN angedengelt ist auch nicht die ganzen Multicasts mit und es sollte "Ruhe" auf dem Port sein
Zitat von: Amenophis86 am 20 Oktober 2015, 10:22:17
Wollte mal fragen, ob es etwas Neues von ELV/eQ3 gibt?
Nein, leider nicht ... ELV hat nur geantwortet, dass bei eQ3 ein Ticket eröffnet worden ist
Zitat von: Wuppi68 am 20 Oktober 2015, 11:40:59
Achte beim Switch darauf, dass er IGMP V3 !!!! kann. Dann bekommt der Port wo der HMLAN angedengelt ist auch nicht die ganzen Multicasts mit und es sollte "Ruhe" auf dem Port sein
aber selbst dann ist bei mir alles 100% Ok, die Anzahl der Reboots hat sich allerdings von "alle paar Minuten" in "ca. alle 2 Wochen" verbessert
einen Reboot habe ich bei mir auch schon lokalisieren können :-)
An meiner Terassentür sind oben und unten jeweils Fensterkontakte ... senden diese "gleichzeitig" macht der HMLAN schon einmal einen Reboot und es ist egal ob CCU2 oder FHEM diesen als IO Device hat ... scheint also ein Timing Problem in dem HMLAN zu geben
ZitatAn meiner Terassentür sind oben und unten jeweils Fensterkontakte ... senden diese "gleichzeitig" macht der HMLAN schon einmal einen Reboot
da könntest du ja minimal unterschiedliche eventDlyTime setzen und das problem entschärfen.
Zitat von: frank am 20 Oktober 2015, 15:11:57
da könntest du ja minimal unterschiedliche eventDlyTime setzen und das problem entschärfen.
so habe ich das ja auch gemacht :-)
Ich habe seit 2 Tagen auch disconnects im Minutentakt. Bislang max 1-2 pro Tag. Weder an der Netzwerkkonfig noch an FHEM wurde etwas geändert. Bin echt ratlos.
Dann schau als erstes mal ob diese mit einem Reboot des HMLAN zusammen hängen (uptime beim HMLAN prüfen) ... wenn das der Grund ist: da hat eQ3 etwas gefunden und wir warten jetzt auf die Veröffentlichung der neuen Firmware
Also bei mir hat es echt was gebracht ein Mulitcast fähigen Netzswitch (TL-SG2008) zu kaufen und den HMLan auf 10 Mbit Half Duplex zu setzen. Seit dem sind die Probleme und Meldungen im Logfile so gut wie weg. Vielen Dank für die Tipps hierzu.
Dann auch mal ein aktueller Status von mir, nachdem ich einiges verändert habe...
- mit externer Antenne ausgerüstet
- Elkos ausgetauscht
- Switch-Einstellungen bzgl. Multicast etc. optimiert
- Switch Port wieder auf "auto" zurückgesetzt, also nicht mehr fest 10MBit/half
- Parallelnutzung durch Testsystem deaktiviert (kleines Eigentor beim Rumbasteln)
- fhem auf aktuellstem Stand
seitdem rennt die Kiste problemlos und ich kann keine disconnects mehr feststellen.
Hardware möchte ich ungerne austauschen, zumal es in der Konstellation bislang ja funktioniert hat.
Ich habe jetzt gem. Wiki mal die Firmware (0.964) neu auf den HMLAN geflasht. Seit 3h ohne reconnects. Ich werde weiter beobachten.
Edith: 11h ohne disconnect !!
Mist, reboot vor 11h, seitdem 23 reconnects :'( :'(
Bist du sicher, dass du nichts geändert hast? Auch nicht im Netzwerk neue Komponenten oder ähnliches? Update des Routers?
Zitat von: Bartimaus am 06 Dezember 2015, 09:57:02
Mist, reboot vor 11h, seitdem 23 reconnects :'( :'(
hast du mal mit perfmon nach längeren "Blockaden" in Fhem geschaut ?
Hm,
Router wurde nichts geändert. Da hat UM die Finger drauf.
Aber jetzt wo Du es sagst, mein neuer Beamer hängt jetzt auch im Netzwerk.
Perfmon sagt mir nichts :-[
Zitat von: Bartimaus am 06 Dezember 2015, 11:31:02
Hm,
Router wurde nichts geändert. Da hat UM die Finger drauf.
Aber jetzt wo Du es sagst, mein neuer Beamer hängt jetzt auch im Netzwerk.
Perfmon sagt mir nichts :-[
Damit kannst du sehen, ob etwas in Fhem die Kommunikation mit dem HMLAN verzögert, siehe Commandref: http://<Fhem-Server>:8083/fhem/docs/commandref.html#perfmon
ZitatEdith: 11h ohne disconnect !!
« Letzte Änderung: Gestern um 22:28:07 von Bartimaus »
und anschliessend mit deinem beamer gespielt?
Danke. Werde ich mal schauen.
Via Apptime habe ich gerade schon festegestellt, das das XBMC-Modul für meinen FireTV ziemlich viel Last verursacht. Leider auch das STV für meinen SamsungTV.
XBMC habe ich jetzt deaktiviert, bei Samsung muss ich mir was überlegen.
Zu Perfmon finde ich in der Commandref leider nichts ???
Zitat von: frank am 06 Dezember 2015, 11:48:03
und anschliessend mit deinem beamer gespielt?
Nee, vorher....
Den Tag über lief es ja ohne Reconnects. Momentan so alle 45min ca.
Perfmon habe ich gefunden, eingebunden und FHEM neu gestartet. Danke für den Hinweis, ich werde beobachten.
So, STV durch WOL ersetzt und XBMC gelöscht. Jetzt gibt perfmon Ruhe, und Apptime reklamiert nur noch meinen unverzichtbaren 1wire-Bus mit erhöhter Antwortzeit. (1015ms). Dort hatte ich aber schon die Resolution auf 9bit gestellt.
Mal sehen ob, und wenn was der HMLAN noch zu beanstanden hat.
Sodele,
Problem dank Perfmon/Apptime gelöst. Die minütlichen disconnects des HMLAN sind wieder verschwunden.
Danke für Eure Hilfe.
eQ-3 hat eine neue Version Konfigurationsadapter LAN Usersoftware V1.520 auf die Downloadseite gestellt ... ich werde das mal testen ;)
Edit: die Versionsnummer bleibt auch nach dem Update (und reboot) bei 0.964 ... ich bin mir nicht sicher, ob das alles so richtig ist :-\
hast du vorher die alte sw deinstalliert? hat er wirklich ein update gemacht?
du meinst auf dem PC deinstalliert ? Nein habe ich nicht, aber man sieht, dass die neue installiert worden ist (gab es schon mal Probleme damit wenn die alte Installation nicht entfernt worden ist?)
Wenn ich auf update klicke dann läuft einige Zeit der grüne Balken durch und dann wird ein Reboot gemacht, dabei wird zwischendurch kurz die Versionsnummer 0.952 angezeigt
Zitatdu meinst auf dem PC deinstalliert ?
ja.
Zitat(gab es schon mal Probleme damit wenn die alte Installation nicht entfernt worden ist?)
ich glaube. hier http://forum.fhem.de/index.php/topic,21537.msg170487.html#msg170487 (http://forum.fhem.de/index.php/topic,21537.msg170487.html#msg170487)
0.952das ist der bootloader.
Deinstalliert ... neu installiert .... weiterhin 0.964
dann wie hier http://www.eq-3.de/Downloads/eq3/pdf_FAQ/HomeMatic_KonfigAdapter_LAN.pdf beschrieben den Maintenance-Mode versucht ... weiterhin 0.964
Schaun' wir mal wie ELV/eQ-3 auf eine Nachfrage antwortet ::)
Hi,
bei mir das gleiche. Version der Firmware ändert sich nicht nach Update.
Probleme mit Disconnects auch nicht. :(
Habe heute auch mal ein Update auf die neue Firmware versucht, leider ohne Erfolg.
Hoffe EQ3 meldet sich bei dir Nobby1805
Ich habe ab und an disconnects, seit dem ich einen 2. HMLAN habe und das ganze mit vccu manage.
Für mich ist das kein großes Problem, da immer nur einer der beiden sich neu connected, somit ist der andere in diesem Zeitraum erreichbar, aber richtig ist das ganze ja nicht.
Vorher, als ich nur einen HMLAN hatte, hatte ich 2-3 mal im Monat einen disconnect, jetzt 1-3 pro Tag.
Grüße Marcel
und du bist sicher, dass der HMLAN die Ursache für den disconnect ist ... d.H. die uptime des HMLAN zeigt, dass er zur selben Zeit rebootet hat ?
Ja, die uptime passt zu dem letzten disconnect...
Gestern habe ich ja das Firmwareupdate gemacht, mit der aktuellen Software von EQ3, ich dachte bisher ohne Erfolg, da die Versionsnummer auf 0.964 stehen bleibt.
Bis jetzt habe ich allerdings keinen einzigen Ausfall mehr gehabt. Gemessen im Zeitraum von ca. 21 Stunden.
Ich habe wohl auch gestern die 00_HMLAN.pm aktualisiert.
Zitatnach Rücksprache mit dem Hersteller eQ-3 müssen wir Ihnen leider mitteilen, dass das Software-Update lediglich neue HomeMatic Komponenten beinhaltet. Eine Anpassung bezüglich der "Reboots" ist hierbei noch nicht erfolgt. Hierzu soll es zu einem späteren Zeitpunkt ein Firmware-Update der LAN-Konfigadapter auf V.0965 geben.
frag doch mal nach dem quellcode der aktuellen fw, um es selber machen zu können. ;)
Zitat von: frank am 15 Dezember 2015, 10:26:44
frag doch mal nach dem quellcode der aktuellen fw, um es selber machen zu können. ;)
könnte ja klappen - der AES Key ist ja mittlerweile auch public geworden :-)
Zitat von: frank am 15 Dezember 2015, 10:26:44
frag doch mal nach dem quellcode der aktuellen fw, um es selber machen zu können. ;)
;) wovon träumst du ;)
eQ-3 lehnt es ja ab direkt mit Endkunden zu kommunizieren ... also läuft alles über ELV ::)
aber mal ehrlich, ist zwar nur eine Formalie, aber ein Gerät das seit Jahren an Kunden verkauft wird sollte nicht mit einer Firmware 0-Version ausgestattet sein :( und wenn einer meiner Mitarbeiter mir eine Software wie das Konfiguration-Tool abliefern würde (neue Versionsnummer wird nicht angezeigt, Update Button aktiv trotz unveränderter Version) ... der hätte bei den nächsten Bonus-/Tantieme-Gesprächen schlechte Karten
Hallo,
gibt es sonst noch Maßnahmen die man ergreifen kann?
Mein HM-LAN bootet alle 3-5min. seit ich ihn vor kurzem gegen einen neuen ausgetauscht habe.
Der alte war leider defekt. Das ist jetzt schon der zweite neue Adapter mit dem gleichen Problem. Die können doch nicht alle defekt sein.
Gruß cornhoulio
Kommt darauf an wie du defekt definierst ... ein Bug in der Firmware ist auch ein defekt ... ich hatte zeitweise auch reboots im Minutenrhythmus :( nachdem ich den Switch an dem der HMLAN hängt getauscht habe wurde es deutlich besser, der neue Switch trennt Multicast-Traffic besser und mein Verdacht ist, dass die Firmware des HMLAN ein race-condition-Problem hat das empfindlich aus bestimmte ankommende Pakete reagiert
Hallo zusammen,
ich hatte diese ständigen Disconnects/Reboots auch - mit insgesamt 4 Stück HMLAN. Inzwischen ist das Problem gelöst. Das ist sicher nicht als globale Lösung zu sehen, aber in jedem Fall habe ich folgende Ursachen gefunden:
Netzwerk-Traffic: Es gab im LAN Probleme mit der Netzwerk-Discovery (Network Browser, NetBIOS over TCP/IP) seit Windows 10 im Einsatz ist. Da ist im November-Update zu Windows 10 ein böser Bug reingekommen (bekannt, im Internet vielfach diskutiert), ein Problem mit dem SMB 3.x Protokoll (neu in Win10) zusammen. Eine temporäre Änderung auf SMB 1.x . hat für 3 HMLANs die Disconnects beseitigt. Soweit ich das analysieren konnte sind durch das "defekte" Protokoll Timing-Probleme in LAN entstanden, der Netzwerk-Traffic zeitweise blockiert, und dann steigt der HMLAN aus.
Blieb nur noch HMLAN Nr. 4, der über eine Powerline-Verbindung (LAN über Netzkabel) in der Garage hängt. Hier war es auch ein Timing-Problem. Eine Änderung des wdTimer Attributs auf 20 hat auch das Problem gelöst. (Dieses Attribut sollte man aber nur sehr vorsichtig ändern.)
Jetzt ist seit Tagen Ruhe - Problem gelöst.
Gruß, Klaus
Mag ja auch eine Ursache sein ... aber ich hatte die Problem schon vorher mit Win 7 und Win 8.1 ... auf meinem Testsystem, das den HMLAN an einem eigenen LAN betrieb, traten die Probleme sehr, sehr selten auf sowohl unter Win XP als auch nach dem Update auf 8.1 und dann auf 10
Eine weitere Ursache für Disconnects/Reboots konnte ich bei mir feststellen: Das "gleichzeitige" Dimmen von zwei HM-LC-Dim1PWM-CV (PWM Dimmer) führte in ~1/20 Fällen zum Reboot eines HMLAN (auch dann, wenn je 1 Dimmer über einen eigenen HMLAN gesteuert wurde). Reproduzierbar. Ein Delay von 0.3s reichte hingegen aus, um diesen Effekt zu vermeiden.
Zitat von: dev0 am 17 Dezember 2015, 12:50:07
Eine weitere Ursache für Disconnects/Reboots konnte ich bei mir feststellen: Das "gleichzeitige" Dimmen von zwei HM-LC-Dim1PWM-CV (PWM Dimmer) führte in ~1/20 Fällen zum Reboot eines HMLAN (auch dann, wenn je 1 Dimmer über einen eigenen HMLAN gesteuert wurde). Reproduzierbar. Ein Delay von 0.3s reichte hingegen aus, um diesen Effekt zu vermeiden.
2 hm-sec an einer Tür Gleichheit --> reboot
hatte lange gedauert bis ich den Fehler gefunden habe
Ich häng mich hier mal dran. Der HMLAN1 macht bei mir auch disconnects. Zusammen habe ich 3 HMLAN an einer vccu im Einsatz. Disconnects kommen nur bei dem HMLAN1 vor. Habe jetzt einen 100/10 ner Switch dazwischen gehangen aber leider keine Besserung.
Ein list vom Kandidaten:
Internals:
DEF 192.168.2.222:1000
DeviceName 192.168.2.222:1000
FD 42
HMLAN1_MSGCNT 51705
HMLAN1_TIME 2015-12-17 22:21:23
IFmodel LAN
NAME HMLAN1
NR 45
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG E222575,0000,008E3009,FF,FFBF,BD86102225750000000AB8EB0E0040
RSSI -65
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 50
msgKeepAlive dlyMax:38.496 bufferMin:2
msgLoadCurrent 26
msgLoadHistory 5min steps: 0/4/0/7/0/1/2/0/4/0/0/1
msgParseDly min:-1454 max:53592 last:9 cnt:46026
owner 123ABC
owner_CCU vccu
uptime 000 02:35:18.409
CHANGETIME:
Readings:
2015-12-15 12:32:11 D-HMIdAssigned 123ABC
2015-12-15 12:32:11 D-HMIdOriginal 1E9D1E
2015-12-15 12:32:11 D-firmware 0.964
2015-12-15 12:32:11 D-serialNr JEQ0707561
2015-12-17 19:47:00 Xmit-Events timeout:21 ok:24 disconnected:24 init:24
2015-12-17 19:47:00 cond ok
2015-12-17 22:21:20 loadLvl low
2015-07-09 10:04:01 prot_ERROR-Overload last
2015-07-09 10:05:02 prot_Warning-HighLoad last
2015-12-17 19:45:56 prot_disconnected last
2015-12-17 19:47:00 prot_init last
2015-12-17 19:47:00 prot_ok last
2015-12-17 19:46:00 prot_timeout last
2015-12-17 19:47:00 state opened
Helper:
assIdCnt 50
assIdRep 50
info 03C4,JEQ0707561,1E9D1E,123ABC
setTime 44262
Bm:
Hmlan_get:
cnt 2
dmx 0
mAr
max 0
tot 0
Hmlan_notify:
cnt 88888
dmx 0
max 40
tot 116
mAr:
HASH(HMLAN1)
HASH(HMLAN1)
Hmlan_read:
cnt 8110
dmx 0
max 477
tot 1008334
mAr:
HASH(HMLAN1)
Hmlan_ready:
cnt 307
dmx 0
max 3004
tot 3293
mAr:
HASH(HMLAN1)
Hmlan_set:
cnt 688
dmx 0
mAr
max 0
tot 0
Cnd:
0 24
252 21
253 24
255 24
Dly:
cnt 46026
lst 9
max 53592
min -1454
Ids:
1a4f71:
cfg +1A4F71,00,00,00
name IR_Sensor
1d481f:
cfg +1D481F,00,00,00
chn 80
flg 0
msg
name 16_LED
to 1450387201.15698
1eb2f3:
cfg +1EB2F3,00,00,00
name Wandtaster
1fca09:
cfg +1FCA09,00,00,00
name TH_Sensor_Bad
1fcbb9:
cfg +1FCBB9,00,00,00
name TH_Sensor_KinderZi
206aa2:
cfg +206AA2,00,00,00
name THSensor
20bd8b:
cfg +20BD8B,00,00,00
name Diff_Temp_Sensor
20c241:
cfg +20C241,00,00,00
chn 01
flg 0
msg
name Radio
to 1450179158.74926
20c729:
cfg +20C729,00,00,00
chn 02
flg 0
msg
name Ladegeraet
to 1450306742.16096
20c733:
cfg +20C733,00,00,00
chn 02
flg 0
msg
name Stehlampe
to 1450386880.30176
20e1fa:
cfg +20E1FA,00,00,00
name Temperatur_Garten
21930d:
cfg +21930D,00,00,00
chn 01
flg 0
msg
name Schalter_Wohnungstuer
to 1450383806.50786
21963c:
cfg +21963C,00,00,00
chn 01
flg 0
msg
name Schalter_Tuer
to 1450362422.41079
21d82f:
cfg +21D82F,00,00,00
chn 02
flg 0
msg
name Licht_Wohnungstuer
to 1450383801.49051
220f52:
cfg +220F52,00,00,00
name Handsender
2221d0:
cfg +2221D0,00,00,00
chn 01
flg 0
msg
name Kueche_Heizung
to 1450385338.08911
2221f7:
cfg +2221F7,00,00,00
chn 02
flg 0
msg
name Bad_Heizung
to 1450329336.97048
222575:
cfg +222575,00,00,00
chn 02
flg 0
msg
name SZ_Heizung_links
to 1450371333.49642
2225d5:
cfg +2225D5,00,00,00
chn 02
flg 0
msg
name SZ_Heizung_rechts
to 1450375937.11334
223338:
cfg +223338,00,00,00
chn 02
flg 0
msg
name Kinderzimmer_Heizung_rechts
to 1450348974.2303
223379:
cfg +223379,00,00,00
chn 02
flg 0
msg
name Kinderzimmer_Heizung_links
to 1450326439.91297
2383ed:
cfg +2383ED,00,00,00
chn 02
flg 0
msg
name Subwoofer
to 1450179138.97948
23d3b7:
cfg +23D3B7,00,00,00
chn 02
flg 0
msg
name UV_Lampe
to 1450380602.63694
23eb90:
cfg +23EB90,00,00,00
chn 02
flg 0
msg
name Licht_WZ
to 1450179155.68361
23fd56:
cfg +23FD56,00,00,00
name Handsender_2
247f95:
cfg +247F95,00,00,00
name Fenster_KiZi_links
248736:
cfg +248736,00,00,00
name TH_Sensor_HZ
24a421:
cfg +24A421,00,00,00
chn 02
flg 0
msg
name Leistungsmesser_Tablet
to 1450369176.89427
251558:
cfg +251558,00,00,00
name TH_Sensor_Flur
255544:
cfg +255544,00,00,00
chn 81
flg 0
msg
name Heizung_WZ_rechts
to 1450386006.18493
2560bb:
cfg +2560BB,00,00,00
chn 81
flg 0
msg
name Heizung_WZ_links
to 1450386098.97955
258299:
cfg +258299,00,00,00
chn 02
flg 0
msg
name Verstaerker
to 1450331942.09067
26ae23:
cfg +26AE23,00,00,00
name Fenster_Bad
27379b:
cfg +27379B,00,00,00
chn 02
flg 0
msg
name Anzeige_Bad
to 1450366901.94436
2865e4:
cfg +2865E4,00,00,00
chn 02
flg 0
msg
name Gefrierschraenke
to 1450382402.51589
2a4f5d:
cfg +2A4F5D,00,00,00
chn 01
flg 0
msg
name Klima_Switch
to 1450179148.47255
2ade84:
cfg +2ADE84,00,00,00
chn 01
flg 0
msg
name Badtuer
to 1450366901.79739
2ae585:
cfg +2AE585,00,00,00
chn 01
flg 0
msg
name Tuer_Kinderzimmer
to 1450339122.2549
2c9c31:
cfg +2C9C31,00,00,00
name Hauptschalter_HZ
2dbaef:
cfg +2DBAEF,00,00,00
chn 01
flg 0
msg
name Leistungsmesser_Aquarium
to 1450179156.07135
30e0b1:
cfg +30E0B1,00,00,00
name TH_Sensor_Kueche
331c56:
cfg +331C56,00,00,00
chn 01
flg 0
msg
name Leistungsmesser_AVR_Board
to 1450179151.53009
331ca6:
cfg +331CA6,00,00,00
chn 02
flg 0
msg
name Kaffeemaschine
to 1450368002.70194
33c474:
cfg +33C474,00,00,00
chn 02
flg 0
msg
name Mikrow_Kuehlschr
to 1450382402.49587
3490bf:
cfg +3490BF,00,00,00
chn 01
flg 0
msg
name Gefriertruhe
to 1450379675.32302
353366:
cfg +353366,00,00,00
name Gas_Sensor
35b6be:
cfg +35B6BE,00,00,00
chn 86
flg 0
msg
name Wandthermostat
to 1450336027.13024
393c81:
cfg +393C81,00,00,00
name Gewitterwarner
5297dd:
cfg +5297DD,00,00,00
chn 02
flg 0
msg
name Kueche_Unterschrank
to 1450364866.13191
52cad0:
cfg +52CAD0,00,00,00
chn 01
flg 0
msg SA569E446,00,00000000,01,A569E446,02B001123ABC52CAD0010E
name Rauchmelder_KiZi
to 1450179159.76082
K:
BufMin 2
DlyMax 38.496
Next 1450387300.81291
Start 1450387280.81291
Loadlvl:
bl 40
a:
99
90
40
0
H:
0 low
40 batchLevel
90 high
99 suspended
Log:
all 0
sys 0
ids:
ARRAY(0x28a26e0)
Q:
HMcndN 0
answerPend 0
hmLanQlen 3
keepAliveRec 1
keepAliveRpt 0
loadLast 26
loadNo 4
scnt 6
apIDs:
Ref:
drft -9.99700089973008e-05
hmtL 9316032
kTs 0
offL 1450377964785
sysL 1450387280817
Attributes:
DbLogExclude .*
hmId 123ABC
hmLanQlen 3_normal
icon icoSYSTEM
loadLevel 0:low,40:batchLevel,90:high,99:suspended
respTime 5
room HM-Adapter,System
wdTimer 20
Und apptime maxDly (letzte 8h, dabei einige disconnects):
name function max count total average maxDly
tmr-at_Exec HASH(0x4b886b0) 132 233 8533 36.62 8267 HASH(Valve_Abfrage)
tmr-at_Exec HASH(0x49a3e78) 193 233 19748 84.76 8110 HASH(ADC_Abfrage)
tmr-at_Exec HASH(0x4488f30) 347 156 18805 120.54 8029 HASH(Durchschnitt_Temp_Aufruf)
tmr-at_Exec HASH(0x490e0b8) 349 2802 609017 217.35 7938 HASH(Sub_DAC_Aufruf)
tmr-at_Exec HASH(0x4473960) 184 934 41193 44.10 7918 HASH(Zeit_dummy_read)
tmr-at_Exec HASH(0x4964620) 188 3502 230766 65.90 7898 HASH(HZ_TH_at)
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN1 149 1438 228 0.16 7868 keepAliveCk:HMLAN1
tmr-HMLAN_KeepAlive keepAlive:HMLAN3 5 1119 1006 0.90 7841 keepAlive:HMLAN3
tmr-HMLAN_KeepAlive keepAlive:HMLAN2 3 1113 997 0.90 7840 keepAlive:HMLAN2
tmr-at_Exec HASH(0x49e8bf0) 203 233 24967 107.15 7840 HASH(ram_at)
tmr-at_Exec HASH(0x439baf0) 5 233 438 1.88 7621 HASH(Power2_read)
tmr-at_Exec HASH(0x44706b0) 209 233 25855 110.97 7582 HASH(Abfrage_rssi)
tmr-at_Exec HASH(0x4a174d0) 2109 78 40048 513.44 7271 HASH(Zycl_HZ)
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 3 1365 1212 0.89 7217 keepAlive:HMLAN1
tmr-at_Exec HASH(0x430f140) 350 93 18216 195.87 7056 HASH(Gas_split_Abfrage)
tmr-VIERA_GetStatus HASH(0x33bbd68) 2007 934 1070539 1146.19 6819 HASH(TV)
tmr-at_Exec HASH(0x4964c50) 387 93 12097 130.08 6807 HASH(Notabschaltung_at)
tmr-at_Exec HASH(0x432dea0) 115 46 2022 43.96 6757 HASH(Garten_Temp_read)
tmr-at_Exec HASH(0x49a36e0) 175 93 6085 65.43 6713 HASH(Fenster_oeffnen_Sommer)
tmr-at_Exec HASH(0x49a35a8) 2 93 35 0.38 6621 HASH(Klima_test1_at)
tmr-HttpUtils_ReadErr HASH(0x77281f8) 0 1 0 0.00 6551
Vlt. sieht ja einer was ;)
VG
Frank
Bei einer uptime von etwa 2 Stunden scheint auch das ein reboot gewesen zu sein ...
die letzten Hinweise hier bestärken mich in meiner Vermutung, das es eine race-condition in der Firmware des HMLAN gibt, es wird uns nichts anderes übrig bleiben als zu 3warten, bis eQ-3 die 0.965 endlich zum Download frei gibt
Ist ja schon lange angekündigt ::)
apptime maxdly zeigt ja nur an, welche funktionen durch ein freeze verzögert wurden. apptime max hingegen die, die die verzögerung aüsgelöst haben.
Stimmt, hier noch apptime max:
name function max count total average maxDly
myDbLogesa DbLog_Get 4773 217 60974 280.99 0 HASH(myDbLogesa); myDbLogesa; HISTORY; INT; 2015-01-01_00:00:00; 2016-01-01_00:00:01; Sensor_Strom:year:10:10:
myDbLog DbLog_Get 3306 622 86481 139.04 0 HASH(myDbLog); myDbLog; HISTORY; INT; 2015-01-01_00:00:00; 2016-01-01_00:00:01; Gas_split_dummy:Gas_Jahr
HMLAN1 HMLAN_Ready 3005 874 16322 18.68 0 HASH(HMLAN1)
tmr-at_Exec HASH(0x4a174d0) 2113 179 78088 436.25 7271 HASH(Zycl_HZ)
tmr-VIERA_GetStatus HASH(0x33bbd68) 2007 2153 3021462 1403.37 6819 HASH(TV)
FB7390 FB_CALLMONITOR_Read 719 3 1250 416.67 0 HASH(FB7390)
HMLAN1 HMLAN_Read 545 19225 2339685 121.70 0 HASH(HMLAN1)
HMLAN2 HMLAN_Read 437 19147 580802 30.33 0 HASH(HMLAN2)
Klima_test1_nty notify_Exec 409 422 112075 265.58 0 HASH(Klima_test1_nty); HASH(Temperatur_Garten)
tmr-at_Exec HASH(0x4964c50) 407 215 27502 127.92 6807 HASH(Notabschaltung_at)
HZ_WZ_gesteuert THRESHOLD_Set 396 551 25012 45.39 0 HASH(HZ_WZ_gesteuert); HZ_WZ_gesteuert; external
Klima_Schalter_ny notify_Exec 385 421 126386 300.20 0 HASH(Klima_Schalter_ny); HASH(TH_Sensor_WZ)
tmr-at_Exec HASH(0x430f140) 360 215 42084 195.74 7056 HASH(Gas_split_Abfrage)
tmr-at_Exec HASH(0x490e0b8) 353 6463 1390845 215.20 7938 HASH(Sub_DAC_Aufruf)
tmr-Calendar_Wakeup HASH(0x3c252b0) 349 3 981 327.00 8 HASH(Ferien)
tmr-at_Exec HASH(0x4488f30) 347 359 42903 119.51 8029 HASH(Durchschnitt_Temp_Aufruf)
ds2 FHEM2FHEM_Read 331 1189 114818 96.57 0 HASH(ds2)
ds1 FHEM2FHEM_Read 306 1973 171604 86.98 0 HASH(ds1)
HMLAN3 HMLAN_Read 301 18588 167449 9.01 0 HASH(HMLAN3)
FileLog_sunDummy FileLog_Get 295 16 2442 152.62 0 HASH(FileLog_sunDummy); FileLog_sunDummy; CURRENT; INT; 2015-01-01_00:00:00; 2016-01-01_00:00:01; 4:sunDummy.sunrise\x3a::time2dec($fld[3]); 4:sunDummy.sunset\x3a::time2dec($fld[3]); 4:sunDummy.sunset\x3a::time2dec($fld[3])
FONLIST FB_CALLLIST_Notify 293 3 573 191.00 0 HASH(FONLIST); HASH(FB7390)
VG
Frank
die dblogeinträge sind hoffentlich nur einmalig (plot?).
2sek von HASH(Zycl_HZ) war vielleicht auch nur eine ausnahme, würde ich jedenfalls weiter beobachten.
den burschen würde ich optimieren. über 2000 mal durschnittlich 1,4 sek (max 2,1) verzögert.
tmr-VIERA_GetStatus HASH(0x33bbd68) 2007 2153 3021462 1403.37 6819 HASH(TV)
bleibt die frage, was hier 7-8 sek verzögert?
Zitatbleibt die frage, was hier 7-8 sek verzögert?
Mmh, das VIERA Modul, da stand das Intervall aud default (60sec) hab es mal auf 120 gesetzt.
Zitatdie dblogeinträge sind hoffentlich nur einmalig (plot?)
Ja, hatte einen Raum mit 12 Plot´s (u.a. Jahresverbrauch Gas) aufgerufen. Zyc_HZ aktiviert sich erst wenn die Heizung gezündet hat und berechnet den Temperaturanstieg innerhalb von 6min, wird es zu langsam warm (innerhalb der 6min) wird der DAC Wert für die Steuerung der Brennerleistung hochgesetzt.
P.S. vlt. bringt ja event-on-change reading auf das VIERA Modul was, hab´s mal gesetzt
VG
Frank
Habe gerade mal bei eq3 nachgesehen, ist das vlt. die lange Erwartete Firm. für den HM-CFG-LAN?
ZitatKonfigurationsadapter LAN Usersoftware V1.520
Kurz Bez.: HM-CFG-LAN
ist vom 10.12.2015.
VG
Frank
Ne, leider nicht...
http://forum.fhem.de/index.php/topic,20776.msg372751.html#msg372751 (http://forum.fhem.de/index.php/topic,20776.msg372751.html#msg372751)
Kann mir mal jemand bitte die beiden attr für den HMLAN erklären ?
hmLanQlen und wdTimer
Ich lese immer, wdTimer ist mit Vorsicht zu ändern, aber nirgends eine Begründung, warum und was da passiert wenn ich diesen ändere...?!
Grüße Marcel
uptime 025 620:33:27.415kaum zu glauben, schon über 620 std (25 tage) keinen reboot. :)
ZitatIch lese immer, wdTimer ist mit Vorsicht zu ändern, aber nirgends eine Begründung, warum und was da passiert wenn ich diesen ändere...?!
warum willst du das ändern, wenn du nicht einmal weisst, was das ist?
es sollte genügend threads geben, wo erklärt wird, dass damit das interval der keepalive msg's von fhem an den hmlan eigestellt wird. warum öfter senden als nötig?
commandref:
ZitatrespTime
Define max response time of the HMLAN adapter in seconds. Default is 1 sec.
Longer times may be used as workaround in slow/instable systems or LAN configurations.
wdTimer
Time in sec to trigger HMLAN. Values between 5 and 25 are allowed, 25 is default.
It is not recommended to change this timer. If problems are detected with
HLMLAN disconnection it is advisable to resolve the root-cause of the problem and not symptoms.
hmLanQlen
defines queuelength of HMLAN interface. This is therefore the number of simultanously send messages. increasing values may cause higher transmission speed. It may also cause retransmissions up to data loss.
Effects can be observed by watching protocol events
1 - is a conservatibe value, and is default
5 - is critical length, likely cause message loss
Zitat von: frank am 20 Dezember 2015, 14:25:59
uptime 025 620:33:27.415
kaum zu glauben, schon über 620 std (25 tage) keinen reboot. :)
so etwas habe ich bei mir noch NIE gesehen ... das Maximum waren bisher etwas über 574 Stunden :(
hmlan1
uptime 048 1166:53:03.889
hmlan2
uptime 032 790:57:38.628
Ironie an
nur mal den @frank seine schlechten Werte toppen :)
Ironie aus
48 tage sind natürlich top. 8)
bis heute kannte ich eigentlich nur werte von 10-12 tagen, falls ich mal zufällig auf die uptime geschaut habe, die ich auch schon als gut empfunden hatte. es gab zeiten, da habe ich bestimmt jeden tag ein paar mails über disconnects bekommen, natürlich nicht alle durch einen reboot des hmlan verursacht.
an meinem netzwerk hat sich auch nichts geändert. in letzter zeit habe ich nur überflüssige devices aus fhem entfernt (zb diverse httpmod, presence mit lan-ping), events verringert, plotfork abgeschaltet, ... insgesammt versucht fhem@fritzbox stabiler mit weniger freezes laufen zu lassen.
das scheint ja dem hmlan auch zu gefallen.
Zitat von: fhem-hm-knecht am 20 Dezember 2015, 14:50:07
hmlan1
uptime 048 1166:53:03.889
Ist das dein aktueller Wert ? Dann schau mal, was in ca. 26 Stunden passiert ;D
ist aktuell ;D
wann soll ich morgen schauen ?
Zitat von: fhem-hm-knecht am 20 Dezember 2015, 17:02:27
ist aktuell ;D
wann soll ich morgen schauen ?
so gegen 17:00
heul :'(
uptime 000 00:08:48.267
aber kein disconnect :)
Weil das ja auch kein Boot war :)
Der Uptime-Zähler im HMLAN ist übergelaufen und anscheinend hat eQ-3 den Fall nicht berücksichtigt und kein Überlaufbit realisiert bzw. wir kennen es nicht ;)
Der Zähler ist 64 Bit lang also maximal 0xFFFFFFFF = 4.294.967.295 ms, das sind etwas mehr als 1.193 Stunden (49 Tage)
Zitatanscheinend hat eQ-3 den Fall nicht berücksichtigt und kein Überlaufbit realisiert
vielleicht hat keiner so viele stunden erwartet. :)
dann könnte/sollte martin das überlaufen abfangen.
Zitatdas sind etwas mehr als 1.193 Stunden (49 Tage)
na dann ist HMLAN2 und HMLAN3 bei mir bald fällig, HMLAN1 macht eh was er will ;)
VG
Frank
Will das Thema nochmals aufgreifen, nachdem ich per Zufall darauf gestoßen bin.
Musste leider feststellen, dass ich auch im Schnitt mindesten einmal täglich einen
disconnected, waiting to reappear (HMLAN1) hatte!
Ich bin mir sicher dass ich das Problem in der Vergangenheit nie hatte.
Nach dem ich auch feststellen musste, dass ich meine HM-CC-TC nicht mehr sauber ansteuern konnte (controlMode und desired-temp)
habe ich meine HM Konfigiration auf meinen Stand vom Februar zurückgedreht.
--> # $Id: 00_HMLAN.pm 7822 2015-02-01 16:28:10Z martinp876 $
--> # $Id: 10_CUL_HM.pm 8070 2015-02-22 16:10:26Z martinp876 $
--> # $Id: 98_HMinfo.pm 7823 2015-02-01 17:04:30Z martinp876 $
--> $Id: HMConfig.pm 8070 2015-02-22 16:10:26Z martinp876 $
Seitdem habe ich keine HMLAN disconnects mehr und meine TC's laufen absolut sauber.
Vielleicht hilfts ja dem einen oder anderen.
Gruß Billy
Auf Grund dieses Threads habe ich meine Uptime auch mal geprüft und festgestellt, dass das Teil nur nachts gut läuft (wenn kein Funkverkehr ist bzw. nur wenig). Tagsüber habe ich diverse disconnects. Ich habe so ca. 60 Homematic-Komponenten im Einsatz und das Gefühl, dass das Problem beim Gleichzeitigen Funken der Komponenten liegt. D.h. wenn z.b. ein Türkontakt zusammen mit einem Bewegungsmelder an den HMLAN sendet und dann noch etwas Drittes gleichzeitig. Denn die Reboots treten ja nicht immer bei den gleichen Komponenten auf.
Ich hoffe das kann noch durch ein Update der Firmware irgendwann behoben werden, denn es schränkt die Benutzbarkeit doch arg ein.
Grüße
Zitathabe ich meine HM Konfigiration auf meinen Stand vom Februar zurückgedreht.
Hatte ich zum testen auch mal gemacht, da sind alle 4 HMLAN bei mir 2Wochen ohne disconnects durchgelaufen, seltsam :o
P.S. nach 2Wochen bin ich dann wieder auf die aktuelle Version zurück und die disconnects waren wieder da
VG
Frank
Billy, kannst du mal deine
Zitat--> # $Id: 00_HMLAN.pm 7822 2015-02-01 16:28:10Z martinp876 $
--> # $Id: 10_CUL_HM.pm 8070 2015-02-22 16:10:26Z martinp876 $
--> # $Id: 98_HMinfo.pm 7823 2015-02-01 17:04:30Z martinp876 $
--> $Id: HMConfig.pm 8070 2015-02-22 16:10:26Z martinp876 $
als Anhang einfügen, würde das gerne mal testen.
Grüße Marcel und allen einen guten Rutsch ins neue Jahr
Zitat von: Ma_Bo am 31 Dezember 2015, 07:32:28
Billy, kannst du mal deine als Anhang einfügen, würde das gerne mal testen.
Grüße Marcel und allen einen guten Rutsch ins neue Jahr
Mach ich doch gerne. Viel Erfolg und ebenfalls guten Rutsch.
Auf deine Rückmeldung bin ich gespannt.
Gruß Billy
Hallo Billy,
das ist interessant, aber nicht wirklich hilfreich.
Da ich nicht weiss was bei dir schief geht kann ich diesen Beitrag nur ignorieren.
Falls du zur Problemlösung beitragen willst könntest du testen
1) HMConfig und HMInfo könntest du hochdrehen. die haben höchst wahrscheinlic nichts damit zu tun
2) wenn du auf die neuste Version updatest könntest du
- apptime laufen lassen
- die internals des HMLAN schicken - insbesondere die MSG informationen zu delays.
Alternativ kannst du dich bei Updates auch selbständig machen. Ab 2016 wird FHEM strikte Regeln zu reading namen realisieren - viel Glück.
Zitat von: martinp876 am 31 Dezember 2015, 11:42:02
Hallo Billy,
das ist interessant, aber nicht wirklich hilfreich.
Da ich nicht weiss was bei dir schief geht kann ich diesen Beitrag nur ignorieren.
Hallo Martin erstmal vielen Dank für deine auch in 2015 geleistete Arbeit und für heute einen guten Rutsch.
Das ist wirklich interessant, ich hatte auch auf Bestätigung von anderen Usern gehofft bevor es für dich lohnt tiefer einzusteigen.
Zitat
Alternativ kannst du dich bei Updates auch selbständig machen. Ab 2016 wird FHEM strikte Regeln zu reading namen realisieren - viel Glück.
Ich habe nicht die Absicht mich selbständig zu machen.
Ich musste nur kurzfristig eine Lösung über die Feiertage finden um meine TC's den Feiertagsbedingungen anzupassen. Ausfälle der HCS Steuerung nicht akzeptabel.
Außerdem gibt es in dieser Zeit auch keinen Slot für mich um groß zu testen.
Die Erkenntnis, dass das Zurückdrehen auf eine alte Konfiguration auch das Thema disconnects positiv beeinflusst war eher Zufall.
Ich hoffe dass diese Erkenntnis auch von weiteren Usern bestätigt werden kann.
Ich melde mich sobald ich Zeit für detaillierte Tests habe.
Gruß Billy
Hallo zusammen,
ich habe gerade erst mit einem HMLAN gestartet und hatte beim alten RPI auch ständig Abbrüche (mit den neuen und den alten *.pm-Dateien von Dir). Gerade habe ich einen RPI 2 bekommen und damit läuft es tadellos (identische Installation, einfach SD-Karte im neuen RPI 2). Der alte war häufig bei 100% Systemlast, der neue ist da doch deutlich kräftiger. Daher denke ich, dass es eventuell einfach an einem zu schwachen/überlasteten Server liegen könnte, wenn die Abbrüche kommen. Was denkt ihr?
Gruß
Torben
absolut!
Hmm, jetzt habe ich auch immer wieder Abbrüche mit dem RPI 2 >:(
die logs? apptime, msg infos in HMLAN internal?
So, habe jetzt mal die Dateien von Billy eingespielt, mal schauen was passiert.
Bisher hatte ich mindestens 1 Timeout bei jedem HMLan innerhalb von 24 Stunden, das extremste waren 6.
Ich werde berichten.
@Martin
Mein HMLAN bootet alle ca. 15min.
Vielleicht kannst Du in meinen Files was sehen.
FHEM ist aktuell.
Gruß cornhoulio.
@cornhoulio
hast du Telekom Entertain in Betrieb ? Dann solltest du einen Switch einsetzen der Multicast-Traffic besser trennt oder auf die neue Firmware 0.965 für den HMLAN warten
Zitat von: Nobby1805 am 02 Januar 2016, 22:51:33
@cornhoulio
hast du Telekom Entertain in Betrieb ? Dann solltest du einen Switch einsetzen der Multicast-Traffic besser trennt oder auf die neue Firmware 0.965 für den HMLAN warten
bei Entertain muss der Switch
IGMP V3 können
folgende Dinge kannst du raus lesen:
msgKeepAlive dlyMax:12.77 bufferMin:-2
das keepalive ist 12sec später als geplant gekommen. Du hast wohl eingestellt, dass es alle 20sec kommen soll, somit war es 2 sec zu spät, also 32 sec anstatt die notwendigen 30sec. Das wird ein disconnect.
HMLAN1 HMLAN_Ready 3117 3277 151882 46.35 0 HASH(HMLAN1)
tmr-Calendar_Wakeup HASH(0x293b108) 1045 3 2938 979.33 84 HASH(Kalender)
diese beiden dauern etwas lang. Das kannzu problemen bei der Kommunikation führen.
HMLAN hat wohl 3 sec da es disconnected ist. Das ist eine standardZeit des warten auf den Socket.
Zum disconnect wird dies nicht führen.
Auffällig sind die vielen maxDly in der Grösenordnung 3sec. Timer sind also 3sec später gekommen als geplant. Das kann nicht alles vom HMLAN Disconnect kommen.
=> Die Verzögerung ist demnach ausserhalb von FHEM
Uncool ist auch noch
tmr-Calendar_Wakeup HASH(0x293b108) 1045 3 2938 979.33 84 HASH(Kalender)
Im Schnitt 1 sec dauer. Das ist zu lang - hier kann es zu Problemen in der kommunikation kommen
da du keine rohmessages geschickt hast kann ich nicht sehen, wie langsam die keepalives sind. Aber dein Problem liegt wohl ausserhalb von FHEM.
Zwischenstatus : seit 24 Stunden keinen Disconnect, beide HMLan´s laufen stabil.
Keine Änderung am Netzwerk oder sonstigem, nur die Dateien von Billy eingespielt und neugestartet.
Getauscht habe ich folgende Dateien :
00_HMLAN.pm 7822 2015-02-01 16:28:10Z martinp876 $
10_CUL_HM.pm 8070 2015-02-22 16:10:26Z martinp876 $
HMConfig.pm 8070 2015-02-22 16:10:26Z martinp876 $
Danke für Euere Einschätzungen.
Entertain habe ich nicht, aber Amazon TV. IGMP kann mein Switch leider nicht obwohl es ein Managed Switch von HP ist.
Dan werde ich wohl weiter suchen. FHEM läuft auf einem RPI vielleicht hat der ja ein Problem.
Gruß cornhoulio.
Zum Verständnis: Wirkt sich denn ein Disconnect, der durch ein Timeout ausgelöst wird auf die Uptime des HMLAN aus? D.h. wird der Uptime-Zähler daraufhin auf 0 gesetzt oder passiert das nur wenn es zu einem Neustart/Reboot des HMLAN kommt?
Grüße
Zitat von: rx am 04 Januar 2016, 12:20:40
Zum Verständnis: Wirkt sich denn ein Disconnect, der durch ein Timeout ausgelöst wird auf die Uptime des HMLAN aus? D.h. wird der Uptime-Zähler daraufhin auf 0 gesetzt oder passiert das nur wenn es zu einem Neustart/Reboot des HMLAN kommt?
umgekehrt ... ein Reboot hat auch ein Disconnect zur Folge, ein Disconnect weil ein Timeout zwischen dem HMLAN und Fhem stattgefunden hat bedingt keinen Reboot des HMLAN
PS die Gründe für einen Reboot des HMLAN scheinen vielfältig zu sein, u.a. scheint es auch Situationen zu geben wo durch die Kommunikation zwischen Fhem und HMALN ein Reboot ausgelöst wird :(
Typisch hast du ein disconnect, kein reboot.
Einen reboot kann ich bisher nicht sicher ereugen.
Ok, dann ist es so wie ich mir dachte - wollte nur sicher gehen. Ich habe bei meinen Disconnects immer ein Setzen der Uptime auf 00:00:00, d.h. vermutlich rebootet sich mein HMLAN alle n-Stunden und der Disconnect ist nur eine Folge davon :(
Zitat von: rx am 04 Januar 2016, 17:22:47
vermutlich rebootet sich mein HMLAN alle n-Stunden
Ich hatte reboots im Minutenrhytmus ... Auslöser vermutlich Telekom Entertain, der HMLAN hat anscheinend ein Problem mit Multicast-Traffic ... durch den Wechsel des Switches durch einen der Multicasts besser separiert ist es bei mir deutlich verbessert worden ... Reboots alle paar Wochen
eQ-3 hat wohl einen Fehler gefunden und wir warten jetzt auf die Veröffentlichung der neuen Version 0.965 für den HMLAN
Kurzer Statusbericht, seit 02.01.16 keinen einzigen Disconnect mehr.
Vielen Dank an Billy für die Dateien.
Hallo in die Runde,
ich habe mich in der letzten Woche zur Erweiterung meiner Hausinstallation auch für das Homematic System entschieden. Die Probleme mit dem CFG-LAN habe ich gestern erst gelesen. Bisher steuere ich alles per FHEM und einer Siemens LOGO, wo es leistungstechnisch geht. Die ersten HM Aktoren habe ich bereits in unser Merten Programm integriert und ich muss sagen sie machen dort einen sehr wertigen Eindruck. Der CFG-LAN kommt morgen erst.
Das heißt ich werde erst zum Wochenende testen können. Sollten mich auch die reboots begleiten und sollte diese in der Tat auf ein Problem der Multicast Verarbeitung beruhen, kann ich das im Anschluss mit einem Cisco Catalysten mal testen. Ich würde dann alle Multicast Frames auf dem Interface zum HM LAN discarden.
Sollte dann ruhe sein hat er die beschriebenen Probleme. Ich kann mir gut vorstellen das der IP Stack für die Aufnahme von Multicast Frames aufgebaut ist. Weiß jemand ob man bei dem Einsatz einer CCU auch mit drei HM LAN´s die Reichweite erhöhen kann? Sprich die beiden Extender bekommen die Frames im LAN per Multicast?
Ein Switch mit IGMPv3 wird das Problem dann auch nicht in gänze lösen. Denn wenn die Consumer Geräte nicht dem Standard konforme IGMP Membership Registrierungen senden wird der Switch seine Multicast Gruppen nicht bilden können. Resultat ist, dass der Switch diese Pakete flutet.
Ich weiß nicht wie T-Entertain arbeitet, aber so typische Aspiranten für Multicast Verteilung im LAN sind Multi Room Systeme wie Sonos oder Raumfeld Lautsprecher. Bei Amazon Prime Video sollte das ein dedizierter Unicast Strom sein, da jeder Client seinen Film on demand startet.
Für die Benutzer von FHEM auf einem PI bietet sie in diesem Fall natürlich ein zweiter (USB) LAN Adapter zur ausschließlichen Anbindung der HM LAN an.
Für jemanden der aus der Prozess Automatisierung kommt, ist so etwas auch nicht ungewöhnlich. Hier wird in der Regel immer der Prozess Ring zum CP (SPS) und die Visualisierung getrennt. Die Siemens S7 CP´s waren schon immer leicht Broadcast anfällig.
Gruß Andreas
Zitat von: shootingstar am 13 Januar 2016, 21:53:31
Die Probleme mit dem CFG-LAN habe ich gestern erst gelesen
Davon würde ich mich an Deiner Stelle erstmal nicht verrückt machen lassen. Die Probleme, die in Verbindung mit Multicast auftreten, kann ich z.B. in keinster Weise nachvollziehen, trotz Multicast Traffic in meinem Netz (Sonos, VLC, ...). Wäre dieses Problem typisch, dann wäre dieser Thread 300+ Seiten lang ;)
Dem stimme ich zu!
Mittlerweile läuft mein HMLAN seit Monaten wieder stabil.
Es kann immer Probleme geben, aber es kann genauso gut auch relativ problemlos funktionieren.
Hallo zusammen,
nachdem ich jetzt ebenfalls einen HM-LAN-CFG in Einsatz habe, hatte ich von Anfang an Probleme mit Reboots in mehr oder weniger kurzen Abständen. Ich habe dien Thread hoch und runter gelesen um einen Lösungsansatz zu finden.
Nach diversen Tests mit Anschlußvarianten etc. verdichtete sich auch bei mir der Verdacht bzgl. der hier beschriebenen Empfindlichkeit des HMLAN auf bestimmte Netzwerkpakete, d.h. Multicast.
Nun gibt es bei mir kein IP-TV und ich war zunächst ratlos.
Die Lösung fand ich in der Softwarekonfiguration der bei mir im Netz betriebenen Synology Surveillance Station.
In den Kamera Live-Ansicht-Einstellungen kann man über eine Checkbox "Multicast-Streaming in Live-Ansicht aktivieren" setzen (siehe Bild im Anhang). Testweise hatte ich diese Einstellung mal für eine Kamera aktiviert und inzwischen total vergessen, da ich diese Streams nicht verwende.
Nachdem ich den Haken entfernt hatte -> kein Reboot des HMLAN mehr !
Haken rein -> wieder Reboots.
Der Zusammenhang der Reboots mit der Multicast-Aktivierung in der Synology Surveillance Station ist gegeben und reproduzierbar.
Wer also die Syno SVS einsetzt und die Rebootprobleme mit dem HMLAN hat kann mal einen Blick auf die Multicast-Einstellung in der SVS wagen.
Bei mir hab ich per apptime max-zeiten von über 20s. Modul fhem2fhem (minimaler log-traffic)ist der erzeuger. Daher auch regelmäßig disconects und entspr. Verzögerungen. wenn ich das include mit der fhem2fhem rausnehme läufts... Ich werd die files von oben einspielen und berichten.
hab fhem2fhem rausgeschmissen, seit gestern keine disconnects mehr.
Zitat von: Ma_Bo am 02 Januar 2016, 15:50:00
So, habe jetzt mal die Dateien von Billy eingespielt, mal schauen was passiert.
Bisher hatte ich mindestens 1 Timeout bei jedem HMLan innerhalb von 24 Stunden, das extremste waren 6.
Ich werde berichten.
Ich kann auch berichten: seitdem keinen einzigen Disconnect mehr.
Danke Billy. :)
Hallo zusammen!
Gehe ich richtig in der Annahme, dass ihr alle dieses Problem (Wechsel zwischen connected und disconnected) mit dem Homematic Lan Adapter (HM-CFG-LAN) habt?
Bin ich dann der einzige, bei dem dieser Fehler mit dem USB Adapter (HM-CFG-USB) auftaucht?
Hierbei kann doch kaum Multicast Traffic der Grund sein, oder?
Auch ein hmusb benötigt das keepalive. Hast du die entsprechenden timer ausgewertet, welche im io angeboten werden? Apptime studiert?
Hallo,
bei mir zeigt sich der disconnect/reconnect jedes Mal wenn mein Kalender aktualisiert wird, also alle 30 min. Gibt es hier eine Abhilfe? Ich verwende das neue Kalender Modul vom Februar.
Gruß,
Tobias
Kalender abschalten.
Wenn ein job 5 oder mehr Sekunden arbeitet besteht Gefahr, daß ein disconnect entsteht. Er verdrängt alles. Bein30s ist der disconnect sogar garantiert.
Der job sollte im batch arbeiten. Ich nutze solche Applikationen nicht in fhem.
Zitat von: martinp876 am 11 Februar 2016, 21:15:56
Ich nutze solche Applikationen nicht in fhem.
Ich nutze solche Applikationen in einer extra fhem Instanz.
Zitat von: Deudi am 11 Februar 2016, 21:34:31
Ich nutze solche Applikationen in einer extra fhem Instanz.
Du hast zwei gleichzeitig laufen? Aber auf verschiedenen Systemen, oder?
das ist nicht notwendig! Die zweite Fhem Instanz bekommt nur andere Ports verpasst... ich nutze das gleiche Konstrukt um blockierende Module aus meiner Primärinstanz zu entkoppeln.
Aber das Kalenderproblem sollte sich doch erledigt haben mit der Umstellung auf nonblocking oder? Bisher habe ich die neue Version nicht getestet...
Greetz
Eldrik
Ich stehe aufm Schlauch, sry.
Also du hast auf einem Gerät zwei Mal FHEM laufen, als eigene Prozesse. Eins als Haupt-Instanz und eins als Zweit-Instanz. In die Zweit-Instanz hast du sämtliche blocking oder störenden Module ausgelagert. Und die verbindest du dann wieder mit fhem2fhem, oder wie machst du das? Finde den Ansatz interessant, da ja oftmals der HM-Lan gerade wegen der blocking Module ein Problem bekommt und ich manche dieser trotzdem gerne nutzen würde.
Mach eine Kopie deines fhem aus /opt/fhem nach /opt/fhem2. Dann hast du dort eine zweite Instanz, die du eigenständig konfigurieren und updaten kannst.
In /opt/fhem2/fhem.cfg:
- alle Portnummern +10
- aussortieren was du hier nicht brauchst
- alle blocking Module hier rein
- fhem starten
In der ersten Instanz ein fhem2fhem zur zweiten Instanz anlegen.
Falls du aus der zweiten Instanz etwas über die erste schalten möchtest, geht das per wget.
Have fun!
Manchmal kann es so einfach sein ...
Sau cool, vielen Dank für die Info. Werde ich die Tage mal testen.
Zitat von: Deudi am 12 Februar 2016, 10:42:02
Mach eine Kopie deines fhem aus /opt/fhem nach /opt/fhem2. Dann hast du dort eine zweite Instanz, die du eigenständig konfigurieren und updaten kannst.
In /opt/fhem2/fhem.cfg:
- alle Portnummern +10
- aussortieren was du hier nicht brauchst
- alle blocking Module hier rein
- fhem starten
In der ersten Instanz ein fhem2fhem zur zweiten Instanz anlegen.
Falls du aus der zweiten Instanz etwas über die erste schalten möchtest, geht das per wget.
Have fun!
japp so läufts 8)
- bis auf das schalten, dafür nutze ich RFHEM (per Forumsuche auffindbar)
- in Kombination mit fhem2fhem bieten sich dann auf der Hauptinstanz noch die Module readingsproxy und clonedummy an
ich habe über das Konstrukt so meine eigene fhem Instanzen, für 1Wire (jeweils 1x EG, 1x OG, 1x KG, 1x Aussenbereich) sowie eine kombinierte fhem Instanz aus Kalenderabruf und Push Nachrichtenversand neben meiner Hauptinstanz am Laufen :)
Greetz
Eldrik
Ich habe bei meiner Konstellation jetzt ein wenig weiter geforscht und viele Dinge ausgeschlossen. Ich lasse mir jetzt alle Disconnects in eine Datei loggen und habe dabei eine lustige Auffälligkeit festgestellt. Der Disconnect erfolgt mehrmals am Tag, aber immer zu "komischen" Uhrzeiten:
2016-02-21 08:08:45 HMLAN1:Xmit-Events: timeout:9 ok:7 disconnected:8 init:8
2016-02-21 19:07:29 HMLAN1:Xmit-Events: timeout:10 ok:8 disconnected:9 init:9
2016-02-22 06:06:47 HMLAN1:Xmit-Events: timeout:11 ok:9 disconnected:10 init:10
2016-02-22 07:07:22 HMLAN1:Xmit-Events: timeout:14 ok:11 disconnected:13 init:13
2016-02-23 18:06:44 HMLAN1:Xmit-Events: timeout:15 ok:12 disconnected:13 init:13
2016-02-24 14:02:53 HMLAN1:Xmit-Events: timeout:15 ok:13 disconnected:15 init:15
Da ist ja eine Regel zu erkennen (Verhältnis Stunde zu Minute), aber woran mag das liegen?
Vielleicht gibt es ja eine Idee.
Grüße
Zitat von: rx am 29 Februar 2016, 10:34:29
Der Disconnect erfolgt mehrmals am Tag, aber immer zu "komischen" Uhrzeiten:
immer ?
Ja, da scheint es einen Rhythmus zu geben ... aber wo sind die Disconnects 11, 12 und 14 ... und es scheinen manchmal disconnects mit bzw. durch Timeout zu sein und manchmal nicht ... interessant wäre es jeweils zusätzlich die uptime des HMLAN zu loggen
Hast du perfmon aktiviert ?
Hallo,
ich wollte euch auch mal kurz meine Erkenntnisse mitteilen.
Ich habe ja die Dateien von Billy eingespielt und seit dem keinen disconnect mehr gehabt.
Vor kurzem habe ich dann einen CO20 Luftgütemesser von Rehau installiert und folgendes auf meinem System ausgeführt : sudo apt-get install libdevice-usb-perl
Seit dieser Zeit habe ich wieder mindestens einen disconnect pro 24 Stunden.
Da ich aber vorher ein komplettes SSD Image gemacht habe, habe ich das Image wieder zurückgespielt und siehe da, keine disconnects mehr.
Jetzt wollte ich wissen ob es ein dummer Zufall war und hab den Befehl erneut ausgeführt und siehe da, wieder disconnect. Die disconnects bleiben auch, auch wenn ich den USB Stick abstecke.
Es hat also (bei mir) definitiv was mit dem System zu tun.
z.Z. läuft mein System wieder mit dem Image und ohne disconnects seit ca. 238 Stunden.
Aber was hat der USB mit meinem Netzwerk zu tun, HMLAN hat doch nix mit USB am Hut.
Grüße Marcel
Das Problem ist sicher dass das hmlan nicht rechtzeitig bedient wird.
Der Grund ist nicht die hmlan logic sondern dass ein anderer job die Zeit stiehlt. Probleme gibt es, wenn hmlan mehr als 5s verdrängt wird, mit Sicherheit wenn es länger als 30 sec dauert.
Wer also kann verdrängen? Fhem ist (primär) single threated. Wer immer arbeitet oder wartet blockiert.
Aber auch Prozesse des OS können den kompletten fhem threat verdrängen. Auch ein USB Treiber.
Apptime sollte zeigen, dass fhem nicht blockiert ( oder doch) und der timer dennoch zu spät kommt.
Falls du ein USB device e in fhem installiert hast versucht fhem dies, wenn es nicht aktiv ist, zu finden. Dabei blockiert es das system für ich glaube 3s. Oder auch länger.
Alles hat mit timing zu tun.
Zitat von: Nobby1805 am 04 Januar 2016, 17:27:24
eQ-3 hat wohl einen Fehler gefunden und wir warten jetzt auf die Veröffentlichung der neuen Version 0.965 für den HMLAN
ist die neue fw vielleicht endlich da? es gibt ein neues fwupdatetool.zip bei eq3 http://www.eq-3.de/downloads.html (http://www.eq-3.de/downloads.html)
ZitatAnleitung zur Installation des HomeMatic Firmware Update Tools (V1.2)
1. Laden Sie die Datei "HM-Firmware-Update-Tool_V1_2_eQ-3_160211.zip" herunter
und speichern Sie diese auf Ihrem PC.
2. Entpacken Sie die Datei.
3. Installieren Sie das Programm "Setup_HMFirmwareUpdateTool.exe".
4. Sie erhalten drei verschiedene Verknüpfungen.
a. HomeMatic-Lan-Interface konfigurieren
Über dieses Programm können Sie den HomeMatic Konfigurationsadapter LAN konfigurieren und aktualisieren.
Achtung: Um Konflikte während der Konfiguration und des Updates zu vermeiden,
bitte nur einen Konfigurationsadapter LAN im Netzwerk betreiben.
b. HomeMatic-CFG-USB aktualisieren
Über dieses Programm können Sie die Firmware des HomeMatic Konfigurationsadapter USB aktualisieren.
c. HomeMatic Firmware Update Tool
Über dieses Programm können Sie die Firmware von HomeMatic Geräten mit dem Konfigurationsadapter USB
(HM-CFG-USB-2) aktualisieren.
ich habe es bisher nur mit einem update des hmusb probiert, was aber immer abbricht. mein hmusb hat fw 0.967. das hmlan update habe ich noch nicht probiert. zumindestens erkennt das tool meinen hmlan mit fw 0.964 ;)
Ich habe eben mal einen meiner HMLANs aktualisiert.
Der zeigt jetzt korrekt die neue Firmware-Version 0.965 an.
Dann heißt es mal abwarten, wie er sich so verhält die nächste Zeit.
lustig, meiner lässt mit sich kein Update machen. Er führt es zwar aus und arbeitet auch, aber nach einem reboot bleibt er bei 0.964. Komisch.
Update ist durch... abwarten ...
Hab' auch gerade das Update meines HMLAN auf 0.965 durchgeführt.
Mal sehen, ob's was bringt.
Grüße,
Nik
jep, auch update durchgeführt.
ging übrigens problemlos - naja, war mal wieder ein windows notwendig dafür...
Wird beobachtet, was der Patient macht...
Nach dem Update von beiden wollte zunächst der im Keller nicht.
FHEM restart brachte besserung... mal beobachten obs nun besser wird.
Endlich, über 20 Stunden war nun Ruhe mit Disconnects. :D
Seit dem 16.01.2016 kamen die bei mir alle 30 Sekunden bis 50 Minuten, obwohl ich FHEM ausgemistet hatte und der Raspi 2 sich gelangweilt hat.
Ich habe die neue Version gerade mal auf meinem Win10 pro installiert.
Ich muss sagen, gefällt mir gut. Dem HM-Lan auf Anhieb gefunden, Update lief durch, ohne Probleme.
Wenn ich dran denke, was ich letztens für Probleme mit dem updaten hatte...
Nun mal abwarten, wie der HM-Lan sich verhält.
vb
bei mir leider keine Besserung.
nach wie vor Meldungen wie diese:
Zitat2016.03.05 11:19:06.093 1: 192.168.0.220:1000 disconnected, waiting to reappear (T_HMLAN1)
2016.03.05 11:19:06.107 1: HMLAN_Parse: T_HMLAN1 new condition disconnected
2016.03.05 11:19:06.420 1: 192.168.0.220:1000 reappeared (T_HMLAN1)
2016.03.05 11:19:06.424 1: HMLAN_Parse: T_HMLAN1 new condition init
2016.03.05 11:19:06.667 1: HMLAN_Parse: T_HMLAN1 new condition ok
Zitat von: VB90 am 05 März 2016, 11:34:40
bei mir leider keine Besserung.
Sieht bei mir genau so aus. :(
War aber auch nicht anders zu erwarten.
Meine disconnects sind mit 99%-er Wahrscheinlichkeit auf Netzwerkunzulänglichkeiten zurückzuführen und nicht auf Reboots des HMLAN.
Irgendwann muss ich doch mal noch anständige Kabel überall dorthin legen, wo ich stabiles Netzwerk haben möchte (also überall ;D)
ich habe das update jetzt auch mal gemacht.
im vergleich zu früher, echt easy. einfach in fhem den hmlan auf attr dummy gesetzt und das update tool mit win7 über wlan gestartet. beim ersten mal abgebrochen (fw 0.92 => bootloader), aber nach refresh und erneutem update, war es drauf. tool beendet und attr dummy wieder gelöscht, fertig.
mal schauen, was es bringt. hoffentlich 49 tage uptime. :)
Zitat von: frank am 05 März 2016, 13:54:10
in fhem den hmlan auf attr dummy gesetzt ... und attr dummy wieder gelöscht, fertig.
:o Das war bei mir gar nicht nötig. Habe einfach im Windows-Tool das Update gestartet und das war's.
Firmware vor dem Update war 0.964
Seit 2 Tagen laufen alle 4 HMLAN, ohne disconnects, mit der neuen Firm. Mal sehen :)
Habe aber auch etliches in der config aufgeräumt, notifiys und überflüssige at´s und all solches Zeug rausgeschmissen und viel in sub´s untergebracht, bringt sichtbaren Performance Gewinn und ist somit gut für die HMLAN´s ;)
VG
Frank
Ich war der mit den Disconnects zu komischen Zeiten. Seit dem Update der Firmware sind die komplett verschwunden und ich hatte seit 3 Tagen keinen Disconnect mehr (Uptime des HMLAN identisch).
Ich hatte den HMLan hinter einem TP-Link Powerline Adapter. Da hatte ich auch alle paar Stunden disconnects. Ich habe ihn jetzt direkt am Router und keine disconnects mehr.
Hi,
bei mir sind Reboot nach demUpdate auch weg. Vorher spätestens alle 10 min. ein Reboot.
Ich habe jetzt aber noch die folgenden Einträge im Log:
2016.03.06 12:03:10.042 5: HMLAN_Parse: HMLAN1 R:EBCB781 stat:0000 t:03BE1EFD d:FF r:FFA3 m:10 008E BCB781 7C0274 0281ABD362A346AE2C1883
2016.03.06 12:03:10.043 5: HMLAN1 dispatch A1410008EBCB7817C02740281ABD362A346AE2C1883::-93:HMLAN1
2016.03.06 12:03:10.053 3: HMLAN1: Unknown code A1410008EBCB7817C02740281ABD362A346AE2C1883::-93:HMLAN1, help me!
2016.03.06 12:03:16.612 5: HMLAN/RAW: /E28B8F7,0000,03BE38AD,FF,FFC9,BA861028B8F70000000AA8E30C0C00
Kann das jemand deuten?
Gruß Cornhoulio.
ein nicht konfiguriertes Gerät ... evt. vom Nachbarn ?
Der Firmware-Update ist bei mir problemlos durchgelaufen:
In einer Windows 10 Installation Login "als Admin", dann Installation des Firmware-Update-Tools ausgeführt
Firmware Update für insgesamt 4 HM-LAN-Adapter ausgeführt -> erfolgreich
Es waren keine Änderungen, kein Shutdown für FHEM notwendig!
Gruß, Klaus
Ich bin gerade eher versehentlich beim LAN-Konfigurator vorbeigekommen, den ich schon länger nicht geupdatet hatte. Der bot ein Firmwareupdate an, was ich mal anstieß - erst danach fiel mir auf, dass es vielleicht sinnvoll gewesen wäre, FHEM solange abzuschalten...
a) Auch ältere HMLAN-Konfiguratoren finden die neueste Firmware.
b) das Update blieb im Zustand "Bootmodus 0.952" hängen. Nach drei Minuten Wartezeit hatte das HMLAN aber laut FHEM längst reconnected. Ein Klick auf Refresh - und der HMLAN war in der Liste, mit 0.965. Also falls das noch jemandem passiert - don't panic.
Auch bei mir hat FHEM den Wechsel ohne irgendeinen Eingriff klaglos weggesteckt.
Derzeit schnalle ich noch nicht, wieso es sowohl im Homematic-Konfigurator als auch im Firmware Update Tool jeweils eine lanif_config_gui.exe gibt, die beide völlig unterschiedliche Versionsnummern zeigen (1.520.8.6244 bzw. 1.2.8.6244), unterschiedlichen Inhalt haben (bei gleicher Größe), aber offenbar das gleiche machen, wenn man sie startet ... :o aber das nur am Rande...
Ich habe gestern auch mal die neue FW aufgespielt. Hätte ich vielleicht lassen sollen. Vorher hatte ich ein bis zwei disconnects pro Tag, seitdem habe ich deutlich mehr. Schöner Mist. Wie komme ich auf die 0.964 zurück?
Gruß
G.
versuch es mal mit dem "Konfigurationsadapter LAN Usersoftware V1.520", die enthält definitiv die 0.964
Bist du sicher, dass deine Reconnects an Reboots liegen? Schau mal nach der Uptime
Zitat von: Nobby1805 am 08 März 2016, 22:36:47
versuch es mal mit dem "Konfigurationsadapter LAN Usersoftware V1.520", die enthält definitiv die 0.964
Nope. Die Firmware kommt irgendwo anders her. Siehe mein Post von heute früh.Korrektur (nicht dass das mal jemand liest und meint ...): sofern sich im Verzeichnis nur eine hmlanif.enc befindet, wird diese rückfragefrei genommen - egal ob jünger oder älter als das was auf dem HMLAN ist... Die Version kann man nur anhand des Dateidatums schätzen.
Zitat von: Nobby1805 am 08 März 2016, 22:36:47
Bist du sicher, dass deine Reconnects an Reboots liegen? Schau mal nach der Uptime
Keine Ahnung, ehrlich gesagt. Vor 24 h war das FW-Update, angezeigte uptime ist 12 h, also war mind. ein Reboot?
Seit Update hatte ich 9 disconnects. Das war vorher deutlich weniger. Was anderes habe ich am System nicht geändert.
Gruß
G.
So, ich habe die 0.964 wieder drauf. Die FW-Datei heißt immer hmlanif.enc. Ich habe noch eine ältere Version in einem anderen Ordner gefunden (Dateidatum 26.11.2013). Die neue habe ich umbenannt in hmlanif$.enc. Nach dem Öffnen des Update-Tools erschien unten rechts ein Auswahlfenster, wo beide Dateien wählbar waren. Die von 2013 erschien nach Update als 0.964. Geht also downzugraden.
Gruß
G.
Und? Kannst du schon sehen, ob es damit wieder besser geworden ist?
Zitat von: Nobby1805 am 08 März 2016, 22:36:47
versuch es mal mit dem "Konfigurationsadapter LAN Usersoftware V1.520", die enthält definitiv die 0.964
Zitat von: Pfriemler am 08 März 2016, 22:43:07
Nope. Die Firmware kommt irgendwo anders her. Siehe mein Post von heute früh.
Zitat von: Gernott am 09 März 2016, 00:53:14
So, ich habe die 0.964 wieder drauf. Die FW-Datei heißt immer hmlanif.enc. Ich habe noch eine ältere Version in einem anderen Ordner gefunden (Dateidatum 26.11.2013).
und genau diese Datei ist Bestandteil des Konfigurationsadapters V1.520 ... dort dann Setup_HMCFG.exe ausführen
Zitatund genau diese Datei ist Bestandteil des Konfigurationsadapters V1.520 ... dort dann Setup_HMCFG.exe ausführen
Ich fasse es nicht. Es ist so wie Nobby sagt: Das frisch heruntergeladene und installierte Homematic-Firmware-Update-Tool enthält eine hmlanif.enc von Oktober 2015 (das müsste die 0.965 sein), das frisch heruntergeladene Homematic Konfigurationstool enthält die Datei von 2013. Da hätte ich eben beinahe ein ungefragtes Downgrade zustandegebracht. In diesem Verzeichnis gibt es nämlich auch ein lanif_config_gui.
Das mit der Dialogbox bei mehreren hmlanif.*.enc stimmt auch.
Bei so einem Kuddelmuddel soll noch einer durchsehen ... :o
Zitat von: Benni am 09 März 2016, 07:41:36
Und? Kannst du schon sehen, ob es damit wieder besser geworden ist?
Gestern hatte ich mit der alten FW noch 7 disconnects, heute bis gerade noch gar keinen. Wahrscheinlich muß man das mal etwas länger laufenlassen, um eine aussagefähige Statistik zu bekommen. Seltsam ist das Ganze schon etwas.
Gruß
G.
Hallo,
Ich habe ein ähnliches Phänomen.
Hab FEHM auf Raspberry Pi 2.
HMLAN, AES deaktiviert, permanente IP eingestellt. Nachdem es alle 29s ein deactivated gab, hab ich die Firmware von 0.964 auf 0.965 mit der Homeatic Software aktualisiert (Achtung: erst nach dem 2. Mal, wurde die Firmware Version 0.965 sichtbar im Tool). Keine weiteren Komponenten sind angehängt.
Da dies keine Besserung gab, habe ich den HMLAN zurückgeschickt und mir von einem anderen Shop wieder gekauft.
--> Gleiches Problem, vor und nach dem Firmware Update.
Nun hab ich mal angefangen mit dem "wdtimer" Attribut was zu ändern. Bei wdtimer=10, gibt es nun ein Deaktivieren alle 14 Sekunden!
Ich dachte, dass der HMLAN ein keepAlive Signal spätestens alle 30 Sekunden erwartet und er sich sonst rebootet. Mit wdtimer=10 müsste doch die Zentrale (FHEM) nun alle 10s ein WatchDog (KeepAlive) Signal schicken?
Jetzt wird es aber noch seltsamer (zumindest für mich): Bei wdtimer=5 hört das dauernde Reboot auf.
Da das zwar mal symptomatisch das Problem bedient, es aber aus meiner Sicht nicht sein soll, dass der FHEM alle 5s ein keepAlive Signal schicken muss, wollte ich euch um Hilfe bitten, wie ich auf den Grund des Problems kommen kann.
Was kann/soll ich prüfen bzw. einstellen?
Danke
bart
Zitat von: bart0190 am 13 März 2016, 08:43:37
Ich dachte, dass der HMLAN ein keepAlive Signal spätestens alle 30 Sekunden erwartet und er sich sonst rebootet.
Nein, nicht rebootet sondern die Netzwerkverbindung disconnected
Zitat von: bart0190 am 13 März 2016, 08:43:37
Bei wdtimer=5 hört das dauernde Reboot auf.
Hast du mal in der uptime nachgeschaut ob es reboots oder disconnects sind ?
danke für die schnelle Antwort.
Ja richtig, es sind disconnects, und dann versucht er sich wieder zu verbinden. Es schaut halt aus wie "Neustarten".
Ich hab am Raspberry Jessie laufen. Hab es aber auch schon mit wheezy versucht.
Kann es vielleicht sein, dass es am FHEM setup liegt?
Komponenten kann ich aber anlernen bzw. liefern Werte (jetzt wo ich auf wdtimer=5 gestellt habe).
da bin ich raus ... keine Ahnung was Jessie odedr Wheezy ist :-[
du könntest am HMLAN aber mal für ca. 1 Minute hmProtocolEvents auf 1_dump und verbose auf 5 setzen ... und danach das was in den Log geschrieben worden ist hier posten
Zitat von: knopf_piano am 03 März 2016, 20:54:20
jep, auch update durchgeführt.
ging übrigens problemlos - naja, war mal wieder ein windows notwendig dafür...
Wird beobachtet, was der Patient macht...
Beobachtung des Patienten in der Klinik mit FW 0.965:
Der Patient verhält sich nach anfänglichen 2-3x disconnect mittlerweile zickig.
Ich bekomm 5-10 am Tag.
nach shutdown restart oder nach HMLAN-Hard-Reset ist erstmal Ruhe, nach ein paar Stunden kommt der erste usw.
Bei mir hat 0.965 die sporadischen Reboots des HMLAN NICHT behoben >:( würde mich mal sehr interessieren welchen Fehler eQ3 dort angeblich gefunden hat ::)
Hallo,
also bei mir hat das Update des Lan-Adapters auch nichts gebracht. Hatte zwischenzeitlich FHEM-Module im verdacht, hat sich aber nicht bestätigt.
Kurios ist nur, das bei mir die Disconnect´s immer dann auftretten, wenn im Netzwerk sonst nichts los ist (also nur FHEM läuft).
vg jens
Hi,
Hab nun das logging aufgedreht, wie von Nobby1805 vorgeschlagen, danke nochmal.
Davor hab ich wieder den wdtimer auf 25 gesetzt (womit ich wieder alle 29s ein disconnect bekomme). Das passiert mit oder ohne zusätzliche HM-Module.
Logging im Anhang. Leider sagt mir das Logging nicht viel.
Zusätzlich muss ich sagen, dass wenn ich den wdtimer auf 5 setze, sind die disconnects nicht vollkommen weg und kommen unregelmäßig (min bis einige Stunden) wieder.
Versteht jemand die Loggings?
lg
bart
Da schaue ich einmal nicht ins Log sondern sage dir, dass du einen Timeout hast. Der hmlan wird nicht alle 30sgetriggert. Wenn du ihm auf 5 setzt und immer noch Disconnects hast ist es ein Task ausserhalb von culhm, evtl ausserhalb von fhem.
Ich würde mit apptime suchen.
Dass es Probleme gibt, wenn du alle Logs einschaltest ist bekannt, muss ich nicht ansehen. Die konsumieren erhabli h Zeit.
Hallo,
danke für den Hinweis. Anbei der Output vom apptime.
Heißt das, dass alle keepAlives ankommen? Oder wie kann man das interpretieren?
lg
bart
apptime hat ein paar optionen. in dem aufgenommenen Zeitraum hat HMLAN einmal 3sec am Stück gebraucht. Das war sicher ein Disconnect - FHEM wartet dann 3 sec ob er nicht doch noch kommt. Nachdem es 500 mal aufgerufen wurde hast du wohl so 200min geloggt...
Du siehst nur die top-verbraucher sortiert nach laufzeit. Das ist eine gute Aussage über FHEM intern.
interessant ist jetzt
apptime maxDly all
zeigt die Verzögerung - die auch von extern hervorgerufen werden kann.
die Parameter maxDly,... steuern nur die Anzeigesortierung. Aufgezeihnete Werte bleiben erhalten bis "clear" gesendet wird.
Hi,
Danke für die Info.
Ich hab nun versucht meinen Raspberry Pi mit Rasbian - Wheezy (vorher hatte ich Jessie) aufzusetzen, FHEM drauf und FHEM update gemacht. Gleiche Fehler. :-\
Hab nun
apptime maxDly all
ausgeführt und das erhalten:
name function max count total average maxDly
tmr-HMLAN_KeepAlive keepAlive:HM_LAN 0 10 0 0.00 25
tmr-FW_closeInactiveClients 0 9 0 0.00 14
tmr-HMLAN_KeepAliveCheck keepAliveCk:HM_LAN 17 22 53 2.41 1 keepAliveCk:HM_LAN
HM_LAN HMLAN_Notify 1 39 5 0.13 0 HASH(HM_LAN); HASH(HM_LAN)
HM_LAN HMLAN_Read 11 21 68 3.24 0 HASH(HM_LAN)
HM_LAN HMLAN_Ready 3005 107 13087 122.31 0 HASH(HM_LAN)
Logfile FileLog_Log 0 39 0 0.00 0
WEB FW_Notify 0 39 0 0.00 0
WEB FW_Read 1 6 5 0.83 0 HASH(WEB)
WEB_10.0.0.5_52069 FW_Read 0 1 0 0.00 0
WEBphone FW_Notify 0 39 0 0.00 0
WEBtablet FW_Notify 0 39 0 0.00 0
eventTypes eventTypes_Notify 1 39 2 0.05 0 HASH(eventTypes); HASH(HM_LAN)
Sagt mir das etwas Genaueres über mein Problem, oder die Bestätigung, dass das keepAlive Signal nicht immer (oder nie) angkommt?
Was kann ich noch probieren, um das Problem zu lösen?
Mittlerweile kann ich ausschließen, dass die HMLAN HW was hat, da sie bei einem Freund richtig funktioniert (ohne disconnects).
lg
bart
Sieht gut aus. Das waren 10 keepalive, also 5 Minuten. Wieviele Disconnects waren in diesem Zeitraum?
Was sagen eigentlich die internals des hmlan? Da stehen performance Daten bereit.
Hallo,
ich beschäftige mich seit kurzem mit FHEM und wollte mal über meine Erfahrungen berichten. Bei mir läuft FHEM auf einem Raspberry Pi 2. Ich habe auch ständig Disconnects mit dem HM-CFG-LAN Adapter. Nach Einspielen der neuen Softwareversion 0.965 hat sich bei mir leider nichts geändert. Ich habe dann verschiedenes ausprobiert (was hier auch stellenweise beschrieben wurde), zwei verschiedene 10/100 Mbps Switchs oder auch direkt an der FritzBox (Port auf 100Mbps gestellt), nichts hat geholfen. Auch wenn nur ein PC, der Raspberry und der HM-CFG-LAN über einen Switch verbunden waren (Switch isoliert, keine Verbindung zum restlichen Netzwerk) gab es Disconnects. Dann habe mir von der Firma wo ich arbeite einen alten 10Mbps Hub mitgebracht, um mal mt Wireshark die Telegramme mitzuschneiden - seit der HM-CFG-LAN am Hub hing gab es keine Disconnects mehr. Also habe ich mir zwei Hubs bei EBAY besorgt. Ich habe zum Test jetzt nochmal einen Switch hinter den Hub geschaltet und den HM-CFG-LAN an den Switch gehängt - keine Disconnects. Das ist mir jetzt etwas unklar, der Hub lässt ja alles durch, der einzige Unterschied zwischen Hub dann Switch und nur Switch ist ja die geringere Geschwindigkeit von 10Mbps durch den zwischengeschalteten Hub.
Jedenfalls bin ich froh, des es mit Hub keine Disconnects mehr gibt.
Viele Grüße
Uwe
Das Netzwerk kann immer ein Problem sein. Wireshark sollte auch auf Pi laufen. Fhem kümmert sich nicht um dein LAN.
Wenn dein Netzwerk Probleme mit 100 mbit hat kann es Probleme bereiten. Du kannst natürlich auch dein LAN interface auf 10 drosseln. Sollte den Treiber ersetzen.
Bei mir läuft es an der FB ohne Probleme. Auch mit pi2 als Server. Direkt verbinden mache ich nicht, ist ja im netzwerk
Disconnects gibt es bei mir immer gleich viele wie keepAlives, also damals 10 disconnects.
Ich hab jetzt ein wenig länger laufen gehabt, hier dazu die internals
DEF 10.0.0.98:1000
DeviceName 10.0.0.98:1000
FD 5
HM_LAN_MSGCNT 124
HM_LAN_TIME 2016-03-20 12:49:50
IFmodel LAN
NAME HM_LAN
NR 20
NTFY_ORDER 50-HM_LAN
PARTIAL
RAWMSG E4589F3,0000,008FBDBB,FF,FFC0,E484704589F300000000FE27
RSSI -64
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 0
msgKeepAlive dlyMax:0.816 bufferMin:4
msgLoadCurrent 3
msgLoadHistory 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
owner xxxxxx
uptime 000 02:38:03.620
und weiter die disconnects im log file:
2016.03.20 12:55:23 1: 10.0.0.98:1000 reappeared (HM_LAN)
2016.03.20 12:55:23 1: HMLAN_Parse: HM_LAN new condition init
2016.03.20 12:55:23 1: HMLAN_Parse: HM_LAN new condition ok
2016.03.20 12:55:52 1: HMLAN_Parse: HM_LAN new condition timeout
2016.03.20 12:55:52 1: 10.0.0.98:1000 disconnected, waiting to reappear (HM_LAN)
2016.03.20 12:55:52 1: HMLAN_Parse: HM_LAN new condition disconnected
2016.03.20 12:55:57 1: 10.0.0.98:1000 reappeared (HM_LAN)
2016.03.20 12:55:57 1: HMLAN_Parse: HM_LAN new condition init
2016.03.20 12:55:57 1: HMLAN_Parse: HM_LAN new condition ok
2016.03.20 12:56:26 1: HMLAN_Parse: HM_LAN new condition timeout
2016.03.20 12:56:26 1: 10.0.0.98:1000 disconnected, waiting to reappear (HM_LAN)
2016.03.20 12:56:26 1: HMLAN_Parse: HM_LAN new condition disconnected
2016.03.20 12:56:31 1: 10.0.0.98:1000 reappeared (HM_LAN)
2016.03.20 12:56:31 1: HMLAN_Parse: HM_LAN new condition init
2016.03.20 12:56:31 1: HMLAN_Parse: HM_LAN new condition ok
2016.03.20 12:56:41 3: HM_LAN: Unknown code A0CE7865A4589F3000000A8F622::-71:HM_LAN, help me!
2016.03.20 12:57:00 1: HMLAN_Parse: HM_LAN new condition timeout
2016.03.20 12:57:00 1: 10.0.0.98:1000 disconnected, waiting to reappear (HM_LAN)
2016.03.20 12:57:00 1: HMLAN_Parse: HM_LAN new condition disconnected
2016.03.20 12:57:03 1: 10.0.0.98:1000 reappeared (HM_LAN)
2016.03.20 12:57:03 1: HMLAN_Parse: HM_LAN new condition init
2016.03.20 12:57:03 3: HM_LAN: Unknown code A0CE784704589F300000000F622::-69:HM_LAN, help me!
Die "help me!" bzw. Unkown code Meldungen gab es früher nicht, wobei ich dort auch noch nicht auf das neue FHEM aktualisiert hatte.
Weitere Ideen?
danke
bart
msgKeepAlive dlyMax:0.816 bufferMin:4
kenne ich so nicht. da ist noch ein Puffer von 4 sec. FHEM sendet nicht verzögert. offensichtlich kommt die msg nicht am Device an. Möglich auch, es komm an, aber die Antwort kommt nicht zurück.
Ich tippe auf dein Netzwerk, was du schon so gu wie bestätigt hast. Wie hier eine solche Verzögerung kommen kann ist mir nicht transparent. Jedenfalls ist es dein Netzwerk.
Hallo,
also mein Netzwerk besteht aus der Fritzbox und 3 Gigabit Switches. Was ich halt merkwürdig finde ist, wenn der HM-CFG-LAN an einem Switch hängt (auch testweise an einem 10/100Mbs) gibt es Disconnects, wenn ich vor den HM-CFG-LAN einen Hub schalte, nicht. Der Hub läßt ja alles durch, der einzige Unterschied ist das der Hub nur 10Mbs kann. Anscheinend scheint der HM-CFG-LAN mit der schnelleren Geschwindigkeit ein Problem zu haben ???
Autonego ist nicht so unproblematisch wie allgemein angenommen. Setze deinen Gigabit auf 10tel Ration. Besser gleich 10MBit einstellen am hmlan Port. Auch die beste macht kein Gigabit.
Möglich sollte sein, den hmlan an der FB zu betreiben und gleich die Leistung hzu drosseln.
Habe leider auch das Problem der HMLAN disconnects am LAN Port der Fritzbox (7490). Der HMLAN bootet immer wieder mal neu. Leider kann die FB nur auf 100 mbit, nicht aber auf 10mbit beschränken..
Bin am überlegen mal ein ganz altes CAT3 Kabel zu testen, dass kann nur 10 MBit
würde ich sein lassen, die Datenrate über ein Kabel einzustellen.
Zitat von: martinp876 am 20 März 2016, 19:34:31
würde ich sein lassen, die Datenrate über ein Kabel einzustellen.
Dass nenn ich mal ne Ansage - DANKE ;)
Merkwürdig finde ich, dass meine anderen beiden HMLAN Adapter, welche über WLAN Repaeter betrieben werden, seitdem Firmware update Ruhe geben. Nur der, der direkt an der FB hängt zickt noch (ist wahrscheinlich das Weibchen) ..
Zitat von: Nobby1805 am 17 März 2016, 17:10:02
Bei mir hat 0.965 die sporadischen Reboots des HMLAN NICHT behoben >:( würde mich mal sehr interessieren welchen Fehler eQ3 dort angeblich gefunden hat ::)
Nach dreifacher Rückmeldung im ELV-Forum, dass die Reboots weiterhin auftreten kam dort heute die Antwort von ELV, dass eQ3 den Fehler behoben hat (vermutlich aber nur einen von vielen :( ) und eine neue Anfrage mit Netzwerkinformationen erstellt werden soll.
Das habe ich eben gemacht.
ZitatDas habe ich eben gemacht.
0.966 also zu weihnachten. :)
Zitat von: frank am 23 März 2016, 10:06:10
0.966 also zu weihnachten. :)
Vielleicht kann sich eQ3 irgendwann auch mal entschließen die Beta-Phase zu verlasen und eine V1 heraus zu geben :'( >:(
Hallo,
auch wenn es sicher schon viele weitere Beiträge dazu gibt schliesse ich mich mal hier mit dran.
Ich habe seit einigen Monaten des Betriebs meines HMLAN auch die Disconnects im Minutentakt:
2016.03.24 09:48:28 1: 192.168.11.2:1000 disconnected, waiting to reappear (HMLAN1)
2016.03.24 09:48:28 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.03.24 09:48:29 1: 192.168.11.2:1000 reappeared (HMLAN1)
2016.03.24 09:48:29 1: HMLAN_Parse: HMLAN1 new condition init
2016.03.24 09:48:29 1: HMLAN_Parse: HMLAN1 new condition ok
2016.03.24 09:54:56 1: 192.168.11.2:1000 disconnected, waiting to reappear (HMLAN1)
2016.03.24 09:54:56 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.03.24 09:54:57 1: 192.168.11.2:1000 reappeared (HMLAN1)
2016.03.24 09:54:57 1: HMLAN_Parse: HMLAN1 new condition init
2016.03.24 09:54:58 1: HMLAN_Parse: HMLAN1 new condition ok
2016.03.24 10:00:25 3: CUL_HM set HM_0D0376_Sw_01 statusRequest
2016.03.24 10:00:27 3: CUL_HM set HM_0D0376_Sw_02 statusRequest
2016.03.24 10:05:42 1: 192.168.11.2:1000 disconnected, waiting to reappear (HMLAN1)
2016.03.24 10:05:42 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.03.24 10:06:46 1: 192.168.11.2:1000 reappeared (HMLAN1)
2016.03.24 10:06:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.03.24 10:06:49 1: HMLAN_Parse: HMLAN1 new condition ok
Ich habe AS Encryption aus. Das läuft so schon seit einigen Monaten. Mein Hotfix war ein HMUSB welchen ich nun zusätzlich betriebe. Dieser ist aber an einer ungünstigen Stelle im Keller und ich würde doch gerne meinen HMLAN mal richtig verwenden können.
Nun habe ich auch mal dem HMLAN ein eigenes VLAN (daher die 192.168.11.2, mein Heimnetz hat 192.168.10.0/24) gegeben wo nur er und der Router vorhanden ist, ich dachte immer der HMLAN hat irgendwie Probleme mit Broadcast eines Netzes. Daher dieser Schritt. Gebracht hat es aber gar nichts. Die Disconnects fangen nach ein paar Minuten nach anschalten wieder an.
Ich habe auch schon die Datenraten für den HMLAN am Switch auf 10Mbit gestellt aber das hat nix gebracht.
Hatte Anfang März auch auf 0.965 geflasht aber auch keine Änderung des Problems.
Gibt es mittlerweile einen allgemein gültigen Workaround für dieses Problem was doch einige zu haben scheinen?
Wird die 0.966 das Problem beheben?
Grüße Dirk
und du bist sicher das es Reboots sind (Uptime auf Null gesetzt?)
Mein Verdacht war auch, dass ein mit Broadcasts bzw.- Multicasts zu tun hat ... ich habe allerdings kein VLAN aufgespannt sondern den Port mit dem HMLAN am Switch für Multicasts gesperrt ... danach war es deutlich besser, von Reboots alle paar Minuten jetzt auf zig bis einige Hundert Stunden
eQ3 hat inzwischen ein neues Support-Ticket (EQ3_SUPPORT-409) erstellt
Zitat von: Dersch am 24 März 2016, 10:25:31
Gibt es mittlerweile einen allgemein gültigen Workaround für dieses Problem was doch einige zu haben scheinen?
Die Ursachen für Disconnects/Reboots sind vielfältig: nicht funktionierendes auto negotiation der Switch Ports, defekte Ports, defekte Kabel/Stecker/Buchsen, instabiles WLAN, Multicast, blockierende Module, Volllast Fhem/Host, buggy HM-LAN Firmware,...
DEN Workaround wird es nicht geben.
Zitat von: Dersch am 24 März 2016, 10:25:31
Wird die 0.966 das Problem beheben?
Probiere es aus.
Mittlerweile habe ich mein System soweit aufgeräumt, dass ich keine Disconnects mehr habe. Jetzt habe ich nur noch das Problem der Reboots und das alle 8-10 Stunden. Mein HMLAN habe ich jetzt mal direkt an meinen Cubietruck gehängt, d.h. an die LAN-Buchse -> leider keine Verbesserung. Ich denke damit habe ich auf Netzwerkseite alles getan, dass keine "schädlichen" Pakete zum HMLAN kommen. Jetzt habe ich schon länger den Verdacht, dass bestimmte Pakete von Homematic-Komponenten das Teil rebooten lassen. Wie könnte man an der Theorie ansetzen und weiter forschen?
Grüße
Zitat von: rx am 25 März 2016, 19:41:33
Jetzt habe ich schon länger den Verdacht, dass bestimmte Pakete von Homematic-Komponenten das Teil rebooten lassen.
Den Eindruck habe ich auch. Manchmal führt das Setzen einer LED-Farbe bei der 16er LED Anzeige zum Reboot.
Ja, so etwas habe ich gesehen. Leider nicht reproduzierbar so dass ich nicht sagen kann ob es eine message, eine einstellmessage oder eine sequenz ist. Oder gar ein hmlan interner zaehler.
ich hatte bei mir festgestellt wenn 2 Fensterkontakte "zeitgleich" senden macht der HMLAN einen reboot ....
also einen unten an der Tür und einen oben, damit man die gekippte Tür von der offenen unterscheiden kann. Ein wenig das Timing geändert und es läuft jetzt schon länger sauber
Das ist natürlich übel. Das ist ja eq3 intern. Fhem macht gar nichts..... Oder hast du etwas programmiert? Das sollte eq3 im griff haben. Schade
Die Reboots, bei "gleichzeitigen" Schalten kann ich bestätigen. Traten bei mir unregelmäßig auf, wenn zwei PWM Dimmer, von Fhem aus, mit einer ramp time angesprochen wurden (set dev1,dev2 100 0 2). Ein Delay von ~0.5s brachte zuverlässig Abhilfe.
Zitat von: martinp876 am 26 März 2016, 21:29:00
Das ist natürlich übel. Das ist ja eq3 intern. Fhem macht gar nichts..... Oder hast du etwas programmiert? Das sollte eq3 im griff haben. Schade
bei mir waren die beiden auf "Werkseinstellung"
nach dem ändern von eventDlyTime war das Thema dann erledigt
Zitat von: Wuppi68 am 27 März 2016, 15:37:43
bei mir waren die beiden auf "Werkseinstellung"
nach dem ändern von eventDlyTime war das Thema dann erledigt
Ist das ein internal? Den seh ich bei mir nicht. Was muss ich dafür eingeben?
Noch einmal zum Unterschied: wenn fhem sendet und der hmlan gebootet haben wir evtl ein Protokol Problem. Wenn dies Auftritt als Reaktion auf das Schalten 2er Sensoren ist es ein eq3 Problem.
Solltemes ein fhem Problem sein bitte loggen und beschreiben.
Ich forsche ja schon längere Zeit und habe in Sachen HMLAN-Reboots schon diverse Dinge ausschliessen können. Ich habe mir z.B. die Funklast angeschaut, einzelne Komponenten deaktiviert, ein neues HMLAN gekauft, eine andere Firmware eingesetzt, ein Interface explizit für das HMLAN verwendet usw. - ohne Erfolg. Meine Disconnects kommen jeden Tag abends und morgens - nie zur gleichen Zeit, aber regelmäßig. Das wird schon stark in Richtung von irgendwelchen Paketen gehen, die von den HM-Komponenten ausgehen und den Reboot auslösen.
Den Zeitpunkt des Reboots kann ich anhand der Uptime sehr schön eingrenzen und zurückrechnen - leider fällt mir in dem Zeitraum dann keine Kommunikation besonders auf - alles scheint normal und so wie am Rest des Tages auch. Ich denke ich werde mir jetzt die Funkpakete mal anschauen, die das HMLAN empfängt. Wie kann ich das anstellen?
Grüße
Habe jetzt das Logging auf 5 gestellt und sehe "Raw"-Messages im Log - ich denke damit kann ich mal etwas rumprobieren.
Zitat von: rx am 31 März 2016, 09:13:49
Habe jetzt das Logging auf 5 gestellt und sehe "Raw"-Messages im Log - ich denke damit kann ich mal etwas rumprobieren.
deutlich weniger log bekommst du mit den einstellungen, wie sie im wiki homematic sniffen beschrieben sind.
Danke für den Tipp!
Je mehr ich vom Datenverkehr mitlese und je mehr ich darüber nachdenke, umso sinnloser kommt es mir vor.
Ich denke, dass die Pakete, die das HMLAN zum Absturz bringen, nicht mehr im Log auftauchen.
Schade, aber vielleicht kommt ja irgendwann nochmal eine vernünftige Firmware...
besser würde es funktionieren, wenn du 2 io sniffen würdestet und zusätzlich jeweils den netzwerktraffic von/zu den io's.
Ist schon merkwürdig..., jeden morgen bootet der HMLAN Adapter, welcher direkt an der Fritzbox hängt durch. Die anderen beiden Adapter, jeweils über Repeater angebunden, laufen schon 28 Tage am Stück durch. Werde mich wohl auch mal am sniffen versuchen...
Zitat von: Rampler am 01 April 2016, 09:35:14
Ist schon merkwürdig..., jeden morgen bootet der HMLAN Adapter, welcher direkt an der Fritzbox hängt durch. Die anderen beiden Adapter, jeweils über Repeater angebunden, laufen schon 28 Tage am Stück durch. Werde mich wohl auch mal am sniffen versuchen...
tausche doch einfach die HMLANs untereinander aus. Ohne die Konfig zu verändern. Wandert der Fehler, dann wissen wir schon etwas mehr
Zitat von: Wuppi68 am 01 April 2016, 09:41:15
tausche doch einfach die HMLANs untereinander aus. Ohne die Konfig zu verändern. Wandert der Fehler, dann wissen wir schon etwas mehr
Der Fehler wandert nicht mit, ergo der Adapter selbst hat nichts..
Nach wie vor, der HMLAN an der Fritzbox bootet brav mind. einmal täglich ..
Zitat von: Rampler am 02 April 2016, 18:43:36
Der Fehler wandert nicht mit, ergo der Adapter selbst hat nichts..
Nach wie vor, der HMLAN an der Fritzbox bootet brav mind. einmal täglich ..
dann sieht es glatt danach aus, dass es "irgendwelche" Multicasts sind
setz mal ein der Fritte den Port auf 10MBit, vielleicht hilft das
Zitat von: Wuppi68 am 02 April 2016, 20:00:53
dann sieht es glatt danach aus, dass es "irgendwelche" Multicasts sind
setz mal ein der Fritte den Port auf 10MBit, vielleicht hilft das
Bei der 7390 kann man nur 10/100 Mbit oder Gbit wählen, habe schon länger auf 10/100 gestellt ..
Ich gebe die Hoffnung noch nicht auf, EQ3 wird sicherlich mit hochdruck an einer Lösung arbeiten ;)
Wir waren am WE nicht Zuhause - keine Disconnects. Das bestätigt meine Vermutung in Richtung von Funkpaketen, die den HMLAN zum Absturz bringen nochmal.
sollten sie von FHEM kommen kannst du es loggen. Einfach alle messages aufzeichnen. (sniffen)
Also bei mir kommen sie nicht von FHEM, sondern von HM-Komponenten. Ich habe Bewegungsmelder im Verdacht - wenn sie gleichzeitig senden (bei mehr als einem in einem Raum).
Das waere traurig. Hm sollte sich korrekt verhalten. Fhem muss ein paar einstellungen am hmlan durchfuehren. Bei devices zu denen ni ht gesendet wird sollte es kein problem geben. Nun ja.
Ist irgendwie traurig die Story...
Habe unter anderem meine Alarmanlage damit realisiert. Bei mir bootet der HMLAN Adapter (Murphys Gesetz) immer dann, wenn die Alarmanlage angeschlagen hat. Dann ist es natürlich blöde, wenn sich die Sirene nicht abschalten lässt, weil der Adapter gerade bootet.
Bin etwas stinkig auf EQ-3, immerhin habe ich mind. 2000 Euro in Homematic investiert...
Ich weiß, dass gejammer bringt nichts, musste aber trotzdem mal raus ...
Umso besser finde ich das Forum und die FHEM Entwickler !!!
Habe meinen HMLAN gestern auch aktualisiert. Nach 15-20 vergeblichen Versuchen über das WLAN/LAN habe ich ihn direkt an den LAN Port gehängt, dann ging es auf Anhieb. Seither sind meine disconnect/connect Probleme weg.
Mein HMLAN hängt an einer FritzBox 7490 mit aktueller Labor-FW und der Port ist auf 1Gbit/s eingestellt. Die Einstellung auf 100Mbit/s hatten in der Vergangenheit keine Verbesserung gebracht.
VG
Stefan
Ich geb ja nicht auf. Bei meinen letzten Tests hatte ich AES beim Türkontakt in Verdacht und habe es daraufhin disabled. HMLAN-Reboots sind natürlich immer noch da. Jetzt schaue ich mir immer nach einem Reboot die letzten Aktionen an. Heute morgen dann Reboot nachdem jemand in die Küche gekommen ist (Bewegungsmelder meldet an fhem und fhem schaltet Licht an). Letzte Meldung im Log vor Reboot:
2016.04.11 07:01:57.140 5: HMLAN_Send: HMLAN1 S:S03B29B67 stat: 00 t:00000000 d:01 r:03B29B67 m:98 A011 1EA04F 24EB56 0201C800009601
2016.04.11 07:01:57.141 5: HMLAN_Send: HMLAN1 I:K
Das Kommando ist nicht beim Licht angekommen.
Frage 1: Kann man daraus irgendwas erkennen?
Frage 2: Könnte man ein zweites HMLAN zum Sniffen-only nehmen? Ich habe ja bei meinen Tests ein Zweites erworben...
Hallo,
ich hab ja auch seit Anfang Februar Probleme gehabt. Na jedensfalls kommen bei mir die Disconnect´s wohl vom Netzwerk bzw. der FritzBox.
HMLan muss alleine am Lan-Port(gedrosselt auf 100MB) angeschlossen sein, jede andere Konfiruration führt bei mir zu mehr oder weniger Fehlern.
Eventuell ist auch die Firmware der Fritte fehlerhaft, bis zum Februar gab es ja keine Probleme.
vg Jens
Ich nehme jetzt mein 2. HMLAN als Sniffer mit einer minimalen FHEM-Installation auf einem Raspberry. Mal schauen ob es beide HMLAN gleichzeitig zerreisst... ich bleib dran :)
Zitat von: rx am 12 April 2016, 22:09:35
Ich nehme jetzt mein 2. HMLAN als Sniffer mit einer minimalen FHEM-Installation auf einem Raspberry. Mal schauen ob es beide HMLAN gleichzeitig zerreisst... ich bleib dran :)
Da bin ich mal gespannt ... ich habe in einer ähnlichen Konfiguration getestet bevor ich vor fast 1 Jahr den Servicecall bei eq-3 über ELV erzielt hatte .. der führte dann zu der Firmware 0.965 die aber leider das Problem nicht löst
Bei mir waren übrigens die Reboots der beiden HMLAN nie gleichzeitig
Ok, heute den ganzen Tag ruhig. Dann gegen 15:30 Uhr ein Reboot vom ersten HMLAN - kein Reboot beim zweiten HMLAN. Ob man dadurch aber einfach die "Empfangsseite" ausklammern kann, wage ich zu bezweifeln. Stochern im Nebel :)
Von seitens EQ3 ist wohl nicht mehr mit einer Korrektur zu rechnen, guckst Du:
ZitatHallo Nobody****,
wir können uns an dieser Stelle lediglich wiederholen.
Laut Hersteller eQ-3 ist das Verhalten behoben. Es sind dabei umfangreiche Tests mit verschiedenen Geräten durchgeführt worden.
Die Ursache für das Verhalten bei Ihnen beiden (nobody*** und Nobby1805) können wir so nicht feststellen. Zumal keine weiteren Rückmeldungen diesbezüglich vorliegen.
Wir würden Sie daher bitten, eine eMail-Anfrage hierzu einzureichen. Geben Sie dabei bitte genau an, welche Netzwerk-Komponenten verwendet werden und wie die Netzwerkstruktur aufgebaut ist. Zudem geben Sie bitte auch die ELV-Kundennummer mit an.
Ob sich was ändert, wenn jeder hier eine EMAIL-Anfrage einreicht ?
Hier ist der Link:
http://www.elv.de/topic/hm-lan-reboots.html (http://www.elv.de/topic/hm-lan-reboots.html)
Ich hatte wie gewünscht die eMail-Anfrage direkt am 23. März an ELV geschickt und es wurde mir auch eine Support-Nummer von eQ-3 mitgeteilt ... ich fände es sehr zielführend wenn sich alle mit diesem Problem bei ELV melden würden ;)
Vielleicht sollte man mal das Problem von Wuppi68 schildern (2 Fensterkontakte gleichzeitig führen zum Reboot). Das ist doch ein schöner Testfall.
Zitat von: Nobby1805 am 14 April 2016, 17:09:18
Ich hatte wie gewünscht die eMail-Anfrage direkt am 23. März an ELV geschickt und es wurde mir auch eine Support-Nummer von eQ-3 mitgeteilt ... ich fände es sehr zielführend wenn sich alle mit diesem Problem bei ELV melden würden ;)
Vielleicht kannst Du Deine Support Anfrage ja mal hier posten...
Dann können wir alle mit leichten Abwandlungen den gleichen Fehler melden, um dem so etwas mehr Nachdruck zu verleihen...
Leider habe ich das direkt in die Supportmaske von ELV eingetragen ... mit der Hoffnung in der Bestätigungsmail oder im ELV-Forum den Text zu sehen ... aber dann kam zuerst nur der Hinweis doch die 0.965 zu installieren >:( als ich dann darauf hingewiesen hatte, dass das Problem sowohl vor als auch nach 0.965 aufgetreten ist und daraus ja die Bitte von ELV geäußert wurde einen erneuten Call auf zu machen kam dann am 24.3.
Zitatvielen Dank für Ihre Anfrage in der technischen Kundenbetreuung und das damit verbundene Interesse an unseren Produkten. Wir haben Ihre Frage aufgrund der Komplexität an den Hersteller der Produkte eQ-3 AG weitergeleitet. Hier wird der Vorgang unter der Bearbeitungsnummer
EQ3_SUPPORT-409
geführt. Sobald wir weiterführende Informationen vom Hersteller erhalten, setzen wir uns mit Ihnen erneut in Verbindung. Bis dahin bitten wir Sie um etwas Geduld.
Sollten Sie weitere Fragen haben, stehen wir Ihnen montags bis freitags von 9 Uhr bis 19 Uhr unter nachfolgenden Kontaktdaten zur Verfügung.
Deutschland Österreich Schweiz
Telefon 0491/6008-245 0662/627-310 061/8310-100
E-Mail technik@elv.de technik@elv.at technik@elv.ch
Mit freundlichen Grüßen
ELV Elektronik AG
Ich teste immer noch eifrig und möchte kurz den Zwischenstand darstellen.
Ich habe den HMLAN-Adapter via Ethernet-Adapter USB an den Cubietruck gehängt. Dazu verwende ich das folgende Modell von Xiaomi:
http://www.gearbest.com/cables-connectors/pp_259718.html (http://www.gearbest.com/cables-connectors/pp_259718.html)
Dadurch erreiche ich, dass das HMLAN-Interface direkt am Rechner hängt und kein Switch oder ähnliches dazwischen geschaltet ist.
Ein zweites HMLAN habe ich ja mittlerweile ich Einsatz, welches parallel an einem Raspberry PI hängt und nur lauscht. Bei diesem HMLAN habe ich keinen einzigen Reboot gehabt und mittlerweile eine Uptime von über 5 Tagen. Das lässt mich zu dem Schluss kommen, dass ein Reboot nicht an einem Paket hängt welches vom HMLAN empfangen wird, sondern eher an der anderen Richtung.
Das wird auch durch die Beobachtung gestärkt, dass das jeweils letzte Paket vor dem Reboot vom HMLAN ein "HMLAN_Send" ist.
Btw. habe ich natürlich auch das neue HMLAN-Interface im Echtbetrieb gehabt und dort die gleichen Reboots wie beim alten Interace, d.h. ein Hardware-Problem beim HMLAN ist auszuschließen.
Weitere Erkenntnisse folgen hoffentlich...
Welches send? Ich brauche mehrere msgs vor dem Crash.
Beispiel:
2016.04.19 05:23:20.388 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:23:20.398 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:JEQ0706588 d:1EA04F O:1EA04F t:031B8189 IDcnt:0078 L:31 %
2016.04.19 05:23:22.845 0: HMLAN_Parse: HMLAN1 R:E390C23 stat:0000 t:031B8B11 d:FF r:FFA9 m:C3 8410 390C23 1EA04F 06010400
2016.04.19 05:23:23.139 0: HMLAN_Parse: HMLAN1 R:E33972F stat:0000 t:031B8C3A d:FF r:FFC8 m:0B A410 33972F 1EA04F 06010000
2016.04.19 05:23:24.391 0: HMLAN_Parse: HMLAN1 R:E31DC02 stat:0000 t:031B911F d:FF r:FFCE m:0F 865A 31DC02 000000 88E021
2016.04.19 05:23:28.118 0: HMLAN_Parse: HMLAN1 R:E3903E3 stat:0000 t:031B9FAE d:FF r:FFDC m:46 865A 3903E3 000000 88E21D
2016.04.19 05:23:33.784 0: HMLAN_Parse: HMLAN1 R:E21A55C stat:0000 t:031BB5AC d:FF r:FFE2 m:CF 8410 21A55C 1EA04F 06012000
2016.04.19 05:23:42.674 0: HMLAN_Parse: HMLAN1 R:E2516C8 stat:0000 t:031BD88C d:FF r:FFCC m:C6 845E 2516C8 000000 8A5714000023003508F8FC
2016.04.19 05:23:43.991 0: HMLAN_Parse: HMLAN1 R:E3903E3 stat:0000 t:031BDDB1 d:FF r:FFDC m:09 A03F 3903E3 1EA04F
2016.04.19 05:23:44.093 0: HMLAN_Send: HMLAN1 S:S2C8B8F52 stat: 00 t:00000000 d:01 r:2C8B8F52 m:09 803F 1EA04F 3903E3 02041EA8613F
2016.04.19 05:23:44.094 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:23:49.096 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:23:54.097 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:23:59.099 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:24:04.100 1: HMLAN_Parse: HMLAN1 new condition timeout
Und hier dann vom zweiten HMLAN die Messages - da sieht man, dass noch was reinkommt aber vom ersten HMLAN nicht mehr empfangen wird:
2016.04.19 05:23:34.645 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:23:34.649 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0986152 d:3223B5 O:000041 t:2227FA21 IDcnt:0008 L:0 %
2016.04.19 05:23:42.653 0: HMLAN_Parse: HMLAN1 R:E2516C8 stat:0000 t:2228195A d:FF r:FFB2 m:C6 845E 2516C8 000000 8A5714000023003508F8FC
2016.04.19 05:23:43.969 0: HMLAN_Parse: HMLAN1 R:E3903E3 stat:0000 t:22281E7F d:FF r:FFB4 m:09 A03F 3903E3 1EA04F
2016.04.19 05:23:44.097 0: HMLAN_Parse: HMLAN1 R:E1EA04F stat:0000 t:22281EFF d:FF r:FFC1 m:09 803F 1EA04F 3903E3 02041EA86141
2016.04.19 05:23:44.370 0: HMLAN_Parse: HMLAN1 R:E31DC02 stat:0000 t:22282010 d:FF r:FFB6 m:0F 8470 31DC02 000000 00E021
2016.04.19 05:23:45.131 0: HMLAN_Parse: HMLAN1 R:E1EA04F stat:0000 t:22282309 d:FF r:FFC1 m:09 803F 1EA04F 3903E3 02041EA8613F
2016.04.19 05:23:48.097 0: HMLAN_Parse: HMLAN1 R:E3903E3 stat:0000 t:22282E9F d:FF r:FFB4 m:46 8470 3903E3 000000 00E21D
2016.04.19 05:23:51.483 0: HMLAN_Parse: HMLAN1 R:E239878 stat:0000 t:22283BDA d:FF r:FFC0 m:9E 8670 239878 000000 00E325
2016.04.19 05:23:59.654 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:23:59.658 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0986152 d:3223B5 O:000041 t:22285BD6 IDcnt:0008 L:0 %
2016.04.19 05:24:03.060 0: HMLAN_Parse: HMLAN1 R:E3BAAC2 stat:0000 t:22286915 d:FF r:FFB2 m:52 8410 3BAAC2 1EA04F 06012600
2016.04.19 05:24:04.310 0: HMLAN_Parse: HMLAN1 R:E24EB56 stat:0000 t:22286DF9 d:FF r:FFAF m:27 8410 24EB56 000000 06010000
2016.04.19 05:24:08.394 0: HMLAN_Parse: HMLAN1 R:E206A27 stat:0000 t:22287DEC d:FF r:FFB7 m:21 8670 206A27 000000 005444
2016.04.19 05:24:08.447 0: HMLAN_Parse: HMLAN1 R:E288145 stat:0000 t:22287E21 d:FF r:FFB4 m:5F 8670 288145 000000 008E45
2016.04.19 05:24:12.797 0: HMLAN_Parse: HMLAN1 R:E2E8C2D stat:0000 t:22288F20 d:FF r:FFC4 m:5D 8610 2E8C2D 000000 0AC0F00C6400
2016.04.19 05:24:22.396 0: HMLAN_Parse: HMLAN1 R:E1F84EE stat:0000 t:2228B4A0 d:FF r:FFB8 m:0C 8410 1F84EE 1EA04F 06012000
Nichts zu sehen.
Wieviel devices hast du am hmlan?
Werden am io internal angezeigt.
Melde mich auch mal zu dem Thema. Seit ich die HM-OU-LED16 aus meinem System verbannt habe ist Schluss mit den ewigen disconnects.
VG
Frank
Nachdem mein HMLAN jetzt eine Uptime von 80 Stunden hat, wage ich mal zu behaupten, dass mein System jetzt stabil läuft. Vielleicht führt meine Vorgehensweise auch bei anderen zu einer Besserung, daher eine kurze Schilderung meiner Maßnahmen.
Nach allen Optimierungen innerhalb von fhem bezüglich Timeouts und einem direkten Anschluss des HMLAN an eine USB-Netzwerkkarte am Cubietruck hatte ich nur noch jeweils ein bis vier Reboots des HMLAN am Tag. Ich habe dann wie im Wiki beschrieben das Sniffen von HMLAN-Paketen aktiviert und mir nach einem Reboot im Logfile die folgende Stelle gesucht:
HMLAN_Parse: HMLAN1 new condition disconnected
Dann habe ich mir die Meldungen davor angeschaut und insbesondere die HMLAN_Send - Meldungen. Denn ich hatte mit einem zweiten HMLAN herausgefunden, dass die Reboots nicht auftauchen wenn das HMLAN nur empfängt.
Ein Beispiel habe ich hier:
2016.04.19 05:23:20.388 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:23:20.398 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:JEQ0706588 d:1EA04F O:1EA04F t:031B8189 IDcnt:0078 L:31 %
2016.04.19 05:23:22.845 0: HMLAN_Parse: HMLAN1 R:E390C23 stat:0000 t:031B8B11 d:FF r:FFA9 m:C3 8410 390C23 1EA04F 06010400
2016.04.19 05:23:23.139 0: HMLAN_Parse: HMLAN1 R:E33972F stat:0000 t:031B8C3A d:FF r:FFC8 m:0B A410 33972F 1EA04F 06010000
2016.04.19 05:23:24.391 0: HMLAN_Parse: HMLAN1 R:E31DC02 stat:0000 t:031B911F d:FF r:FFCE m:0F 865A 31DC02 000000 88E021
2016.04.19 05:23:28.118 0: HMLAN_Parse: HMLAN1 R:E3903E3 stat:0000 t:031B9FAE d:FF r:FFDC m:46 865A 3903E3 000000 88E21D
2016.04.19 05:23:33.784 0: HMLAN_Parse: HMLAN1 R:E21A55C stat:0000 t:031BB5AC d:FF r:FFE2 m:CF 8410 21A55C 1EA04F 06012000
2016.04.19 05:23:42.674 0: HMLAN_Parse: HMLAN1 R:E2516C8 stat:0000 t:031BD88C d:FF r:FFCC m:C6 845E 2516C8 000000 8A5714000023003508F8FC
2016.04.19 05:23:43.991 0: HMLAN_Parse: HMLAN1 R:E3903E3 stat:0000 t:031BDDB1 d:FF r:FFDC m:09 A03F 3903E3 1EA04F
2016.04.19 05:23:44.093 0: HMLAN_Send: HMLAN1 S:S2C8B8F52 stat: 00 t:00000000 d:01 r:2C8B8F52 m:09 803F 1EA04F 3903E3 02041EA8613F
2016.04.19 05:23:44.094 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:23:49.096 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:23:54.097 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:23:59.099 0: HMLAN_Send: HMLAN1 I:K
2016.04.19 05:24:04.100 1: HMLAN_Parse: HMLAN1 new condition timeout
2016.04.19 05:24:04.139 3: Disconnect return value: -1
2016.04.19 05:24:04.272 1: 172.16.2.1:1000 disconnected, waiting to reappear (HMLAN1)
2016.04.19 05:24:04.294 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.04.19 05:24:07.394 1: Perfmon: possible freeze starting at 05:24:05, delay is 2.394
2016.04.19 05:25:07.535 1: 172.16.2.1:1000 reappeared (HMLAN1)
Das letzte HMLAN_Send vor dem Timeout geht an das Device mit der ID 3903E3. In dem Fall war das ein Wand-Thermostat (HM-TC-IT-WM-W-EU). In anderen Fällen war es mehrmals ein Bewegungsmelder oder auch ein Unterputzschaltaktor.
Ich habe dann jeweils
1. das Device zurückgesetzt (5 Sekunden Pairingknopf drücken, dann nochmal 5 Sekunden Pairingknopf oder wie im Handbuch des Device beschrieben)
2. das Device aus fhem komplett gelöscht
3. das Device neu gepaired
4. das Device konfiguriert (beim Bewegungsmelder z.B. Parameter wie "minInterval" angepasst)
Das habe ich für jedes Device wiederholt was vor dem Disconnect ein Send bekommen hat (das waren bei mir 5 verschiedene).
Und jetzt habe ich Ruhe mit Reboots - warum auch immer.
Grüße
Zitat von: rx am 22 April 2016, 13:32:45
Und jetzt habe ich Ruhe mit Reboots - warum auch immer.
Abwarten, ich glaube noch nicht dran....
Irgendwie habe ich keine Lust alle meine 55 Devices neu zu pairen ...
Trotzdem Danke für Deine Mühen
Zitat von: Rampler am 22 April 2016, 15:25:27
Abwarten, ich glaube noch nicht dran....
Ich auch nicht :(
Ich habe durch diverse Maßnahmen im Netz Uptimes bis zu 844 Stunden erreicht ... aber manchmal sind es auch nur 200.
Als nur der HMLAN und ein Port des Rechners an einem LAN hingen gab es sogar keine Reboots bis zum Überlauf des internen Zeitzählers
Aus meiner Sicht ist allerdings jeder Reboot der nicht durch einen Stromausfall oder ein (nicht bekanntes) Kommando willentlich ausgelöst wird ein Fehler in der Firmware des HMLAN.
Mein Verdacht ist, dass der HMLAN Probleme hat wenn Aufgaben auf der LAN-Seite und der Funk-Seite quasi gleichzeitig ausgeführt werden sollen/müssen ... oder IT-technisch gesagt: irgendwo stimmt die Reentrancy der Kodierung nicht
Ich habe auch ca. 50 Devices und musste für den o.g. Effekt lediglich 5 neu pairen. Bislang keine Reboots mehr. Ich schließe daraus, dass es bei einer "schlechten" fhem-Konfiguration möglich ist, das HMLAN zum Reboot zu bringen. Da ich schon mehrere Monate teste, kann ich einen Uptime-Zufall mittlerweile ausschließen. Ich hatte vor dem Neu-Pairing immer mindestens 2 Reboots pro Tag.
PS: Dass es auch viele andere Gründe für einen Reboot des HMLAN gibt, steht für mich außer Frage.
Zitat von: rx am 28 April 2016, 23:08:24
Ich habe auch ca. 50 Devices und musste für den o.g. Effekt lediglich 5 neu pairen.
Ich frage mich, was anders ist oder wurde, nachdem neu gepairt wurde. Eigentlich sollte sich nach einem erneuten pairen doch nichts ändern. Oder ist der Softwarestand beim pairen von Bedeutung ?
Evtl.kann sich Martin mal dazu äußern ..
Aus dem älteren Backup habe ich aus der fhem.save folgendes extrahieren können:
vorher:
setstate FileLog_parkstrasse_vorratsraum_licht active
setstate parkstrasse_vorratsraum_licht off
setstate parkstrasse_vorratsraum_licht 2014-05-21 22:09:16 .D-devInfo 010100
setstate parkstrasse_vorratsraum_licht 2014-05-21 22:09:16 .D-stc 10
setstate parkstrasse_vorratsraum_licht 2014-10-20 17:45:31 .R-intKeyVisib invisib
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:35 .peerListRDate 2016-03-11 01:03:35
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 .protLastRcv 2016-03-11 06:58:27
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:56:23 CommandAccepted yes
setstate parkstrasse_vorratsraum_licht 2014-05-21 22:09:16 D-firmware 1.12
setstate parkstrasse_vorratsraum_licht 2014-05-21 22:09:16 D-serialNr KEQ0435000
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:34 PairedTo 0x1EA04F
setstate parkstrasse_vorratsraum_licht 2014-10-20 17:45:31 R-pairCentral 0x1EA04F
setstate parkstrasse_vorratsraum_licht 2014-10-20 17:45:32 R-sign off
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:34 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:34 RegL_01. 08:00 00:00
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 deviceMsg off (to broadcast)
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 level 0
setstate parkstrasse_vorratsraum_licht 2015-12-14 19:34:30 levelMissed desired:100
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 pct 0
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:32 powerOn 2016-03-11 01:03:32
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 recentStateType info
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 state off
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 timedOn off
nachher:
setstate FileLog_parkstrasse_vorratsraum_licht active
setstate parkstrasse_vorratsraum_licht off
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:21 .D-devInfo 010100
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:21 .D-stc 10
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:27 .R-intKeyVisib invisib
setstate parkstrasse_vorratsraum_licht 2016-04-18 20:06:19 .peerListRDate 2016-04-18 20:06:19
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 .protLastRcv 2016-04-28 20:14:49
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:12:47 CommandAccepted yes
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:21 D-firmware 1.12
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:21 D-serialNr KEQ0435000
setstate parkstrasse_vorratsraum_licht 2016-04-18 20:06:18 PairedTo 0x1EA04F
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:27 R-pairCentral 0x1EA04F
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:27 R-sign off
setstate parkstrasse_vorratsraum_licht 2016-04-18 20:06:18 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_vorratsraum_licht 2016-04-18 20:06:18 RegL_01. 08:00 00:00
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 deviceMsg off (to broadcast)
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 level 0
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 pct 0
setstate parkstrasse_vorratsraum_licht 2016-04-28 17:20:02 powerOn 2016-04-28 17:20:02
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 recentStateType info
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 state off
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 timedOn off
Treppenlicht:
vorher:
setstate FileLog_parkstrasse_flur_treppe_licht active
setstate parkstrasse_flur_treppe_licht off
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:02 .R-intKeyVisib invisib
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:28:33 .peerListRDate 2016-03-05 19:28:33
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 .protLastRcv 2016-03-11 07:01:49
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:00:43 CommandAccepted yes
setstate parkstrasse_flur_treppe_licht 2014-05-21 22:09:15 D-firmware 1.12
setstate parkstrasse_flur_treppe_licht 2014-05-21 22:09:15 D-serialNr KEQ0632741
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:28:32 PairedTo 0x1EA04F
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:02 R-pairCentral 0x1EA04F
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:03 R-sign off
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:28:32 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:28:32 RegL_01. 08:00 00:00
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 deviceMsg off (to broadcast)
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 level 0
setstate parkstrasse_flur_treppe_licht 2014-08-17 07:25:00 levelMissed desired:0
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 pct 0
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:21:30 powerOn 2016-03-05 19:21:30
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 recentStateType info
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 state off
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 timedOn off
nachher:
setstate FileLog_parkstrasse_flur_treppe_licht active
setstate parkstrasse_flur_treppe_licht off
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:02 .R-intKeyVisib invisib
setstate parkstrasse_flur_treppe_licht 2016-04-11 04:21:37 .peerListRDate 2016-04-11 04:21:37
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 .protLastRcv 2016-04-28 06:37:15
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:36:12 CommandAccepted yes
setstate parkstrasse_flur_treppe_licht 2014-05-21 22:09:15 D-firmware 1.12
setstate parkstrasse_flur_treppe_licht 2014-05-21 22:09:15 D-serialNr KEQ0632741
setstate parkstrasse_flur_treppe_licht 2016-04-11 04:21:35 PairedTo 0x1EA04F
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:02 R-pairCentral 0x1EA04F
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:03 R-sign off
setstate parkstrasse_flur_treppe_licht 2016-04-11 04:21:35 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_flur_treppe_licht 2016-04-11 04:21:36 RegL_01. 08:00 00:00
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 deviceMsg off (to broadcast)
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 level 0
setstate parkstrasse_flur_treppe_licht 2014-08-17 07:25:00 levelMissed desired:0
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 pct 0
setstate parkstrasse_flur_treppe_licht 2016-04-27 05:05:50 powerOn 2016-04-27 05:05:50
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 recentStateType info
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 state off
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 timedOn off
Was mir grundsätzlich auffällt ist, dass bei den alten RegL-Einträgen 2 Leerzeichen hinter "RegL_0X." stehen:
RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
Bei den neu gepairten ist das nicht der Fall. Ich finde in meiner alten Config noch mehrere Einträge mit den zwei Leerzeichen:
# grep "RegL_00. 0" fhem.save
setstate parkstrasse_flur_tablet 2016-03-11 00:51:26 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:28:32 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_flur_unten_licht 2016-03-07 21:21:11 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_hwr_licht 2016-03-07 19:01:45 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_kueche_lampe 2016-03-11 06:26:21 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:34 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
In meiner aktuellen Config nicht mehr...
Ist schon merkwürdig...
Ich habe auch zwei Kanditaten:
klaus@Raspberry /opt/fhem/log $ grep "RegL_00. 0" fhem.save
setstate HW.licht 2016-04-28 21:14:49 RegL_00. 02:81 0A:29 0B:A0 0C:83 15:FF 18:00 00:00
setstate WC.licht 2016-04-29 00:19:42 RegL_00. 02:81 0A:29 0B:A0 0C:83 15:FF 18:00 00:00
klaus@Raspberry /opt/fhem/log $ grep "RegL_01. 0" fhem.save
setstate HW.licht 2016-04-28 21:14:50 RegL_01. 08:00 30:06 57:24 00:00
setstate WC.licht 2016-04-29 00:19:43 RegL_01. 08:00 30:06 57:24 00:00
Und das bekommt man nur durch repairen wieder hin ?
Meine Vermutung wäre: fhem stoppen, Datei fhem.save ändern (die Leerzeichen entfernen) und fhem wieder starten.
???
Ein clear Register und dann ein getconfig halte ich fuer sinnvoller. Was soll!das editieren in der readings?
Fhem schreibt es auf eine Weise. Das muss passen oder adaptiert werden.
P.s. wo seht ihr ein Problem?
gibt es inzwischen Neuigkeiten zu dem Thema? Ich habe auch häufig hmlan reboots mit ca 100 devices...
@rx: ist noch immer kein reboot aufgetaucht nach dem neu pairen?
eQ-3 hat mich über ELV gebeten einen Wireshark-Log des Netzwerk-Traffic während eines Boots zur Verfügung zu stellen ... den ersten Log bei einem Boot der durch massiven Multicast-Verkehr der durch T-Entertain ausgelöst worden ist konnte ich bereits an ELV schicken.
Die selteneren Boots, die bei mir in Abständen von einigen zig bis zu 800 Stunden auftreten, erwarte ich z. Zt. ... wireshark läuft mit (uptime ist aktuell 223 Stunden)
Zitat von: Nobby1805 am 18 Mai 2016, 23:06:33
eQ-3 hat mich über ELV gebeten einen Wireshark-Log des Netzwerk-Traffic während eines Boots zur Verfügung zu stellen ... den ersten Log bei einem Boot der durch massiven Broadcast-Verkehr der durch T-Entertain ausgelöst worden ist konnte ich bereits an ELV schicken.
Moin Nobby,
was für Broadcasts sind das?
Entertain lebt von Multicasts und nur für den Senderaufbau gehen für 10-15 Sekunden Multicasts an den Receiver.
Hast Du einen gemanageten Switch?
Gruß
Ralf
Hallo Ralf,
im Prinzip werden bei Entertain fast alle Informationen per Multicast an die Receiver geschickt ... der Router bzw. Switch sollte allerdings diese nur an die Ports weiterleiten, die ihr Interesse an den Multicast gemeldet haben.
Mein Switch (teilweise gemanaged) hatte beim Firmwareupdate, den ich für das Port-Mirroring brauchte, ein Problem und hat deshalb die Multicasts an alle Port geschickt. Das habe ich dann sofort genutzt, um den Log an ELV zu senden. Meiner Meinung nach sollten allerdings auch diese Multicasts kein Grund sein, einen Reboot durchzuführen.
Aber wie gesagt, Reboots finden auch ohne die Multicasts statt .. und die versuche ich jetzt einzufangen.
Gruß Nobby
PS bitte in meinem vorherige post Broad durch Multi ersetzen ::)
wenn Du einen Managed Switch hast, kannst Du den HMLAN evtl. mal in ein eigenes VLAN werfen? Oder die MCast auf dem Switch für den Port komplett abschalten?
Hey Leute,
ich habe vor kurzem mein System mal geupdatet, jetzt habe ich das Phänomen, dass mein HMLAN1 ohne timeout läuft, jedoch mein HMLAN2 mindestens 1x in 24 Stunden einen timeout hat.
Netzwerkkabel habe ich auch schon getauscht, aber keine Besserung. Andere Port´s an der Fritzbox probiert, keine Besserung.
Zum testen habe ich jetzt einen 3. neuen HMLAN gekauft, diesen in FHEM definiert und in die VCCU eingetragen, auch hier mindestens 1x in 24Std. ein timeout, HMLAN1 weiterhin ok.
Jetzt ist mir aufgefallen, dass der HMLAN1 die Seriennr. KEQ..... am Anfang hat und die beiden anderen die Seriennr. LEQ..... am Anfang haben. Hat das was zu bedeuten?
Auf allen 3 HMLAN´s habe ich die aktuelle Firmware 0.965.
HMLAN1 ist als erster in der Config definiert und mit der IP xxx.xxx.xxx.80
HMLAN2 ist als zweiter in der Config definiert und mit der IP xxx.xxx.xxx.81
HMLAN2 ist als dritter in der Config definiert und mit der IP xxx.xxx.xxx.82
die VCCU ist nach den HMLAN´s definiert.
Seit eben habe ich einen Switch, mit dem ich die Verbindung managen kann.
Es laufen jetzt alle 3 HMLAN´s über diesen Switch, PORT1 zum Router mit 10MBit Full, Port 2-4 mit 10Mbit Half, an der Fritzbox steht der Port auf 100MBit Full.
Aufgefallen ist mir, dass wenn die HMLAN´s direkt an der Fritzbox hängen (diese kann man ja leider nur auf 100MBit Full oder 1000MBit Full einstellen) dann werden in der Netzwerkübersicht der Fritzbox, die HMLAN´als offline angeziegt, jetzt mit der 10MBit Einstellung werden sie als online angezeigt.
Leider kenne ich mich nicht so wirklich mit Netzwerkeinstellungen usw. aus, sonst würde ich das mit dem VLAN mal testen.
Wenn das alles so auch nicht klappt, dann werde ich meinen NUC, auf dem FHEM läuft, mal Richtung Switch verlagern und schauen ob es was bringt, wenn er per Kabel verbunden ins Netzwerk eingebunden ist. Er ist nämlich z.Z. per Wlan angebunden, da es Positionsbedingt leider nicht anders geht.
Ich teste jetzt schon eine ganze Weile und so langsam macht Homematic mir keinen Spass mehr.
Apptime sagt auch nix auffälliges, ausser ca. 3sec wegen dem timeout, genau wie ca. 3sec freeze über Perfmon nach dem timeout.
Die timeouts würden mir jetzt nicht so viel ausmachen, aber das Problem ist, wenn z.B. 2 HM Funksteckdosen angehen sollen und genau in diesem Moment der timeout kommt, dann schaltet eine und die andere nicht mehr. Leider ist dies schon 2x vorgekommen. Gibts da evtl. ne Möglichkeit, dies abzufangen, dann wären die timeouts nämlich nicht weiter schlimm für mich.
Ich gebe mal ein list von meinen HMLAN´s und der VCCU.
HMLAN1
Internals:
DEF 192.168.178.80:1000
DeviceName 192.168.178.80:1000
FD 17
HMLAN1_MSGCNT 1026
HMLAN1_TIME 2016-05-20 16:35:16
IFmodel LAN
NAME HMLAN1
NR 127
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG E2320F7,0000,00370600,FF,FFCD,8786102320F70000000A28E00F0058
RSSI -51
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 54
msgKeepAlive dlyMax:0.292 bufferMin:4
msgLoadCurrent 39
msgLoadHistory 5min steps: 3/1/2/2/2/1/27/0/-/-/-/-
msgParseDly min:4 max:11916 last:103 cnt:920
owner 257505
owner_CCU vccu
uptime 000 01:00:06.016
Readings:
2016-05-20 15:56:37 D-HMIdAssigned 257505
2016-05-20 15:56:37 D-HMIdOriginal 257505
2016-05-20 15:56:37 D-firmware 0.965
2016-05-20 15:56:37 D-serialNr KEQ1023165
2016-05-20 15:56:37 Xmit-Events init:1 ok:1 disconnected:1
2016-05-20 15:56:37 cond ok
2016-05-20 16:34:29 hmTrfHour 39 %
2016-05-20 16:34:53 loadLvl low
2015-12-02 02:49:07 prot_ERROR-Overload last
2016-05-12 16:09:23 prot_Warning-HighLoad last
2016-05-20 15:56:29 prot_disconnected last
2016-05-20 15:56:29 prot_init last
2016-04-29 18:23:57 prot_keepAlive last
2016-05-20 15:56:37 prot_ok last
2016-05-17 12:47:17 prot_timeout last
2016-05-20 15:56:29 state opened
Helper:
assIdCnt 54
assIdRep 54
info 03C5,KEQ1023165,257505,257505
setTime 44670
Bm:
Hmlan_get:
cnt 1
dmx 0
mAr
max 0
tot 0
Hmlan_notify:
cnt 4184
dmx 0
mAr
max 0
tot 0
Hmlan_read:
cnt 771
dmx 0
max 304
tot 47389
mAr:
HASH(HMLAN1)
Hmlan_set:
cnt 111
dmx 0
mAr
max 0
tot 0
Cnd:
0 1
253 1
255 1
Dly:
cnt 920
lst 103
max 11916
min 4
Ids:
229f9e:
cfg +229F9E,00,01,00
name Heizkoerperventil_Buero
2320f7:
cfg +2320F7,00,01,00
name Heizkoerperventil_Badezimmer
232126:
cfg +232126,00,01,00
name Heizkoerperventil_Kueche
23212b:
cfg +23212B,00,01,00
name Heizkoerperventil_Wohnzimmer
23c762:
cfg +23C762,00,01,00
name Heizkoerperventil_Schlafzimmer
23c763:
cfg +23C763,00,01,00
name Heizkoerperventil_Kinderzimmer
23d4f0:
cfg +23D4F0,00,01,00
chn 01
flg 0
msg
name Tueroeffner
to 1463752628.63114
263ddf:
cfg +263DDF,00,01,00
name Wandthermostat_Buero
26ae6e:
cfg +26AE6E,00,01,00
name Fenster2_Wohnzimmer
26ae6f:
cfg +26AE6F,00,01,00
name Fenster1_Buero
26af0a:
cfg +26AF0A,00,01,00
name Fenster1_Kueche
26af0f:
cfg +26AF0F,00,01,00
name Fenster1_Kinderzimmer
26b3cd:
cfg +26B3CD,00,01,00
name Fenster1_Badezimmer
26b3d5:
cfg +26B3D5,00,01,00
name Fenster1_Schlafzimmer
26b480:
cfg +26B480,00,01,00
name Fenster1_Wohnzimmer
26dd4a:
cfg +26DD4A,00,01,00
name Handsender1
270950:
cfg +270950,00,01,00
name Aussen
2766c5:
cfg +2766C5,00,01,00
name Fenster1_Flur
276d17:
cfg +276D17,00,01,00
name Schluesselboard
276f1f:
cfg +276F1F,00,01,00
name Briefkasten
27bbe8:
cfg +27BBE8,00,01,00
name Handsender2
27e0a7:
cfg +27E0A7,00,01,00
chn 01
flg 0
msg
name Wohnungstuer
to 1463752632.46877
280140:
cfg +280140,00,01,00
chn 01
flg 0
msg
name Vitrine_Beleuchtung_BE3_HM
to 1463752633.96073
2804d9:
cfg +2804D9,00,01,00
chn 01
flg 0
msg
name Flur_DE12_HM
to 1463752610.08784
28432d:
cfg +28432D,00,01,00
name Kueche_6_fach_Taster
2855b1:
cfg +2855B1,00,01,00
chn 01
flg 0
msg
name Waschmaschine_HM
to 1463752630.4568
28566b:
cfg +28566B,00,01,00
chn 01
flg 0
msg
name Spuelmaschine_HM
to 1463752616.14294
2ad36e:
cfg +2AD36E,00,01,00
name SolarBatterie_Warnung
2b3289:
cfg +2B3289,00,01,00
chn 01
flg 0
msg
name TV_Wohnzimmer
to 1463752626.40116
2b3668:
cfg +2B3668,00,01,00
chn 01
flg 0
msg
name TV_Schlafzimmer
to 1463752625.38007
2c587b:
cfg +2C587B,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder_Bett_Marcel
to 1463754748.5926
2c8818:
cfg +2C8818,00,01,00
chn 00
flg 0
msg
name Trockner_HM
to 1463754693.80888
2d378f:
cfg +2D378F,00,01,00
chn 02
flg 0
msg
name Bad_Taster1und2
to 1463752607.99078
2d379e:
cfg +2D379E,00,01,00
chn 01
flg 0
msg
name TV_Schaltmodul3
to 1463754445.25536
2d37a5:
cfg +2D37A5,00,01,00
chn 01
flg 0
msg
name TV_Schaltmodul2
to 1463754439.24493
2d37c6:
cfg +2D37C6,00,01,00
chn 01
flg 0
msg
name TV_Schaltmodul1
to 1463754439.26983
2e27b9:
cfg +2E27B9,00,01,00
chn 01
flg 0
msg
name Bad_Spiegel
to 1463752605.94126
2eb0ab:
cfg +2EB0AB,00,01,00
chn 01
flg 0
msg
name Bett_Beleuchtung
to 1463752609.05794
2eb2a6:
cfg +2EB2A6,00,01,00
chn 01
flg 0
msg
name Weihnachtsbel_ABCDE24
to 1463752638.12212
2eed4c:
cfg +2EED4C,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder_Bad
to 1463754654.67088
2ef2cb:
cfg +2EF2CB,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder_Kueche
to 1463754598.36038
2f4b38:
cfg +2F4B38,00,01,00
name Solar_Spannung
2f70fa:
cfg +2F70FA,00,01,00
name Fernbedienung1_HM
346362:
cfg +346362,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder_Bett_Sarah
to 1463754764.23665
5299b6:
cfg +5299B6,00,01,00
name Wandthermostat_Schlafzimmer
529a3d:
cfg +529A3D,00,01,00
name Wandthermostat_Kueche
529b72:
cfg +529B72,00,01,00
name Wandthermostat_Wohnzimmer
529be4:
cfg +529BE4,00,01,00
name Wandthermostat_Kinderzimmer
529c9a:
cfg +529C9A,00,01,00
name Wandthermostat_Badezimmer
52bff7:
cfg +52BFF7,00,01,00
chn 01
flg 0
msg
name Rauchmelder_Buero
to 1463752611.09058
52c091:
cfg +52C091,00,01,00
chn 01
flg 0
msg
name Rauchmelder_Wohnzimmer
to 1463752615.11756
52c09f:
cfg +52C09F,00,01,00
chn 01
flg 0
msg
name Rauchmelder_Schlafzimmer
to 1463752614.10866
52c69c:
cfg +52C69C,00,01,00
chn 01
flg 0
msg
name Rauchmelder_Kinderzimmer
to 1463752613.10169
52c6aa:
cfg +52C6AA,00,01,00
chn 01
flg 0
msg
name Rauchmelder_Flur
to 1463752612.09485
K:
BufMin 4
DlyMax 0.292
Next 1463754918.33126
Start 1463754893.33126
Loadlvl:
bl 40
a:
99
90
40
0
H:
0 low
40 batchLevel
90 high
99 suspended
Log:
all 0
sys 0
ids:
ARRAY(0x2e25f40)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLast 38
loadNo 6
scnt 6
apIDs:
Ref:
drft -0.000120009600768061
hmtL 3583373
kTs 0
offL 1463751309963
sysL 1463754893336
Attributes:
group 000_Uebersicht
hmId 257505
hmKey "auskommentiert"
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
respTime 1
room 0.00_Beobachten,0.00_VCCU,4.01_CUL_HM,4.07_USB_Geraete
verbose 3
wdTimer 25
HMLAN2
Internals:
DEF 192.168.178.81:1000
DeviceName 192.168.178.81:1000
FD 18
HMLAN2_MSGCNT 1174
HMLAN2_TIME 2016-05-20 16:36:07
IFmodel LAN
NAME HMLAN2
NR 129
NTFY_ORDER 50-HMLAN2
PARTIAL
RAWMSG E529B72,0000,003DE9BF,FF,FFC6,FB865A529B7200000028DE33
RSSI -58
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 10 report:18
msgKeepAlive dlyMax:0.114 bufferMin:4
msgLoadCurrent 22
msgLoadHistory 5min steps: -2/-10/2/2/0/1/3/26/0/-/-/-
msgParseDly min:7 max:11916 last:47 cnt:1022
owner 257505
owner_CCU vccu
uptime 000 01:07:37.535
Readings:
2016-05-20 15:56:38 D-HMIdAssigned 257505
2016-05-20 15:56:38 D-HMIdOriginal 2CD91B
2016-05-20 15:56:38 D-firmware 0.965
2016-05-20 15:56:38 D-serialNr LEQ0640911
2016-05-20 15:56:39 Xmit-Events init:1 disconnected:1 ok:1
2016-05-20 15:56:39 cond ok
2016-05-20 16:36:08 hmTrfHour 22 %
2016-05-20 16:36:04 loadLvl low
2016-05-20 15:56:29 prot_disconnected last
2016-05-20 15:56:29 prot_init last
2016-05-08 13:51:51 prot_keepAlive last
2016-05-20 15:56:39 prot_ok last
2016-05-20 14:50:24 prot_timeout last
2016-05-20 15:56:29 state opened
Helper:
assIdCnt 10
assIdRep 18
info 03C5,LEQ0640911,2CD91B,257505
setTime 44670
Bm:
Hmlan_notify:
cnt 4303
dmx 0
mAr
max 0
tot 0
Hmlan_read:
cnt 797
dmx 0
max 306
tot 21628
mAr:
HASH(HMLAN2)
Hmlan_set:
cnt 54
dmx 0
mAr
max 0
tot 0
Cnd:
0 1
253 1
255 1
Dly:
cnt 1022
lst 47
max 11916
min 7
Ids:
289ccc:
cfg +289CCC,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder1
to 1463754783.77086
2d3bc2:
cfg +2D3BC2,00,01,00
chn 02
flg 0
msg
name Steckdosen_LED_Licht
to 1463752618.19178
38b0af:
cfg +38B0AF,00,01,00
chn 04
flg 0
msg
name Alarmanlagen_Schaltmodul_4Kanal
to 1463752604.93575
3abc06:
cfg +3ABC06,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder_Alarm_Wohnzimmer
to 1463754824.83903
3abc25:
cfg +3ABC25,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder_Alarm_Kueche
to 1463754888.7533
3abc5f:
cfg +3ABC5F,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder_Alarm_Flur
to 1463754925.14312
3abd05:
cfg +3ABD05,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder_Alarm_Badezimmer
to 1463754794.52438
3abdaa:
cfg +3ABDAA,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder_Alarm_Schlafzimmer
to 1463754891.23937
3abf66:
cfg +3ABF66,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder_Alarm_Buero
to 1463752965.09155
3abfbc:
cfg +3ABFBC,00,01,00
chn 01
flg 0
msg
name Bewegungsmelder_Alarm_Kinderzimmer
to 1463754761.01452
K:
BufMin 4
DlyMax 0.114
Next 1463754989.3377
Start 1463754964.3377
Loadlvl:
bl 40
a:
99
90
40
0
H:
0 low
40 batchLevel
90 high
99 suspended
Log:
all 0
sys 0
ids:
ARRAY(0x2ee4648)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLast 22
loadNo 7
scnt 1
apIDs:
Ref:
drft -0.000199976002879654
hmtL 4054919
kTs 0
offL 1463750909422
sysL 1463754964341
Attributes:
group 000_Uebersicht
hmId 257505
hmKey "auskommentiert"
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
respTime 1
room 0.00_Beobachten,0.00_VCCU,4.01_CUL_HM,4.07_USB_Geraete
verbose 3
wdTimer 25
HMLAN3
Internals:
DEF 192.168.178.82:1000
DeviceName 192.168.178.82:1000
FD 19
HMLAN3_MSGCNT 1396
HMLAN3_TIME 2016-05-20 16:36:53
IFmodel LAN
NAME HMLAN3
NR 131
NTFY_ORDER 50-HMLAN3
PARTIAL
RAWMSG E257505,0000,003E788E,FF,FFD2,E880022575052C881800
RSSI -46
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 0 report:1
msgKeepAlive dlyMax:0.235 bufferMin:4
msgLoadCurrent 8
msgLoadHistory 5min steps: -1/-3/0/0/0/0/0/12/0/-/-/-
msgParseDly min:8 max:4007 last:166 cnt:1164
owner 257505
owner_CCU vccu
uptime 000 01:08:14.094
Readings:
2016-05-20 15:56:37 D-HMIdAssigned 257505
2016-05-20 15:56:37 D-HMIdOriginal 322362
2016-05-20 15:56:37 D-firmware 0.965
2016-05-20 15:56:37 D-serialNr LEQ0986235
2016-05-20 15:56:38 Xmit-Events init:1 ok:1 disconnected:1
2016-05-20 15:56:38 cond ok
2016-05-20 16:36:47 hmTrfHour 8 %
2016-05-20 16:36:30 loadLvl low
2016-05-20 15:56:29 prot_disconnected last
2016-05-20 15:56:29 prot_init last
2016-05-20 15:56:38 prot_ok last
2016-05-20 08:38:42 prot_timeout last
2016-05-20 15:56:29 state opened
Helper:
assIdCnt 0
assIdRep 1
info 03C5,LEQ0986235,322362,257505
setTime 44670
Bm:
Hmlan_notify:
cnt 4397
dmx 0
mAr
max 0
tot 0
Hmlan_read:
cnt 825
dmx 0
max 244
tot 6012
mAr:
HASH(HMLAN3)
Hmlan_set:
cnt 52
dmx 0
mAr
max 0
tot 0
Cnd:
0 1
253 1
255 1
Dly:
cnt 1164
lst 166
max 4007
min 8
Ids:
K:
BufMin 4
DlyMax 0.235
Next 1463755015.69132
Start 1463754990.69132
Loadlvl:
bl 40
a:
99
90
40
0
H:
0 low
40 batchLevel
90 high
99 suspended
Log:
all 0
sys 0
ids:
ARRAY(0x2f3cf70)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLast 8
loadNo 7
scnt 4
apIDs:
Ref:
drft -0.000198436321784339
hmtL 4071795
kTs 0
offL 1463750918900
sysL 1463754990695
Attributes:
group 000_Uebersicht
hmId 257505
hmKey "auskommentiert"
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
respTime 1
room 0.00_Beobachten,0.00_VCCU,4.01_CUL_HM,4.07_USB_Geraete
verbose 3
wdTimer 25
VCCU
Internals:
DEF 257505
HMLAN1_MSGCNT 217
HMLAN1_RAWMSG E257505,0000,0037237D,FF,FFE6,3F80022575053ABC5F01012F00
HMLAN1_RSSI -26
HMLAN1_TIME 2016-05-20 16:35:23
HMLAN2_MSGCNT 373
HMLAN2_RAWMSG E257505,0000,003EBC88,FF,FFE5,E980022575052C881800
HMLAN2_RSSI -27
HMLAN2_TIME 2016-05-20 16:37:00
HMLAN3_MSGCNT 583
HMLAN3_RAWMSG E257505,0000,003E977F,FF,FFD2,E980022575052C881800
HMLAN3_RSSI -46
HMLAN3_TIME 2016-05-20 16:37:00
IODev HMLAN1
LASTInputDev HMLAN3
MSGCNT 1173
NAME vccu
NR 164
NTFY_ORDER 50-vccu
STATE HMLAN1:ok,HMLAN2:ok,HMLAN3:ok,
TYPE CUL_HM
assignedIOs HMLAN1,HMLAN2,HMLAN3
lastMsg No:E9 - t:02 s:257505 d:2C8818 00
protLastRcv 2016-05-20 16:37:00
rssi_at_HMLAN1 cnt:217 max:-26 avg:-26.7 lst:-26 min:-49
rssi_at_HMLAN2 avg:-27.62 max:-27 lst:-27 min:-60 cnt:373
rssi_at_HMLAN3 max:-42 avg:-50.51 lst:-46 min:-86 cnt:583
Readings:
2016-05-20 16:37:00 CommandAccepted yes
2016-05-20 16:36:38 recentStateType ack
2016-05-20 15:56:39 state HMLAN1:ok,HMLAN2:ok,HMLAN3:ok,
2016-02-14 10:54:04 unknown_25017D received
2016-05-14 15:55:05 unknown_26DB46 received
2016-02-14 11:02:04 unknown_276D14 received
2016-02-14 10:57:58 unknown_2AE3B8 received
2016-02-15 18:56:51 unknown_2C2291 received
2016-02-15 18:49:37 unknown_2C587B received
2016-02-13 23:31:56 unknown_2F59E3 received
2016-02-15 19:05:20 unknown_346377 received
2016-02-13 23:20:10 unknown_3AB6BD received
Helper:
HM_CMDNR 233
PONtest 1
mId FFF0
rxType 1
Bm:
Cul_hm_set:
cnt 5
dmx 0
mAr
max 0
tot 0
Expert:
def 1
det 1
raw 1
tpl 1
Io:
nextSend 1463755021.01195
vccu vccu
ioList:
HMLAN1
HMLAN2
HMLAN3
Mrssi:
mNo E9
Io:
HMLAN2 -27
HMLAN3 -46
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
vrt 1
Rssi:
At_hmlan1:
avg -26.7004608294931
cnt 217
lst -26
max -26
min -49
At_hmlan2:
avg -27.627345844504
cnt 373
lst -27
max -27
min -60
At_hmlan3:
avg -50.5111492281304
cnt 583
lst -46
max -42
min -86
Tmpl:
Attributes:
IODev HMLAN1
IOList HMLAN1,HMLAN2,HMLAN3
IOgrp vccu
expert 251_anything
model CCU-FHEM
room 0.00_VCCU
subType virtual
webCmd virtual 1:virtual 2:update
Vielleicht fällt jemandem was auf, ob irgendwas falsch ist oder wie auch immer.
Ich teste weiter, lese weiter, hoffe weiter......
Grüße Marcel
KEQ sind älter als LEQ ... ob es dabei Änderungen an der HW gegeben hat ist nicht dokumentiert
Du solltest begrifflich zwischen Timeouts und Boots unterscheiden ... timeouts sind immer die Folge eines Boots, können aber auch durch andere Gründe hervorgerufen werden
Welchen Switch hast du denn jetzt ?
Ok, im Log steht ja immer timeout, deshalb hatte ich das so angenommen.
Habe den TP-Link TL-SG108E
Zitatwenn z.B. 2 HM Funksteckdosen angehen sollen und genau in diesem Moment der timeout kommt, dann schaltet eine und die andere nicht mehr. Leider ist dies schon 2x vorgekommen. Gibts da evtl. ne Möglichkeit, dies abzufangen, dann wären die timeouts nämlich nicht weiter schlimm für mich.
wie sind die steckdosen an die vccu gekoppelt (IOgrp)? nutze doch jeweils ein anderes prefered io. wie schaltest du sie gemeinsam?
wenn ich mir die uptime's betrachte, hatten aber alle 3 vor ca 1 std einen reboot.
Ja über IOgrp.
prefered IO ist für diese Steckdosen nicht gesetzt, da ich das die VCCU entscheiden lasse, habe es aus dem wiki so verstanden, wenn keins gesetzt ist, dann wird über den hmlan welcher die besseren rssi werte hat, gesendet.
Die Steckdosen werden über je ein notify geschaltet, sobald der Bewegungsmelder ein motion schickt. Ich könnte natürlich beide Steckdosen über ein notify steuern, aber es werden dort noch andere Abhängigkeiten abgefragt, die nicht bei beiden gleich sind.
Die Uptime kommt daher, dass ich wie schon geschrieben, heute alles umgebaut habe und den Switch verbaut habe, dafür habe ich auch die hmlans vom Strom trennen müssen. Bzw. habe ich fhem komplett neugestartet, sieht man auf dem Bild was als Anhang dabei ist.
bei ortsfesten devices, sollte sich der rssi eigentlich kaum ändern. da "entlastest" du die vccu/hmlan eher mit einem prefered io. ausserdem kannst du die load besser verteilen. zu zeit bedient ein hmlan 54 devices / 39%, der andere 18 devices / 22%.
und bei deinem problemfall könnte es eventuell auch helfen. falls beide dosen vom selben hmlan bedient werden, aber immer nur eine während des problems nicht geschaltet wird, sollte das problem verschwinden, denke ich.
Zitat von: Ma_Bo am 20 Mai 2016, 17:36:54
Habe den TP-Link TL-SG108E
OK, bei dem Switch kannst du das IGMP-snooping enablen ... das hat bei mir die reboots drastisch reduziert (s. Kapitel 4.2 im Handbuch)
Ich warte jetzt erst einmal ab, ob es was bringt mit meinem Switch, danach werde ich das mal testen, wobei ich davon ausgehe, dass es nicht wirklich besser wird.
ABER
der HMLAN1 mit dem hohen load, bleibt immer sauber, der HMLAN2 und HMLAN3 mit dem geringen load steigen öfter aus. Und das soll sich mit erhöhtem load bessern?
ZitatOK, bei dem Switch kannst du das IGMP-snooping enablen ... das hat bei mir die reboots drastisch reduziert (s. Kapitel 4.2 im Handbuch)
Schon passiert, ist aber von Werk aus an.
Sooooo, bei mir scheint das mit dem Switch zu funktionieren !
Seit Freitag laufen die HMLANs ja jetzt alleine über diesen Switch und seit dem hat sich nur 1x mal der 2.HMLAN verabschiedet.
Zitat von: Nobby1805 am 18 Mai 2016, 23:06:33
eQ-3 hat mich über ELV gebeten einen Wireshark-Log des Netzwerk-Traffic während eines Boots zur Verfügung zu stellen ... den ersten Log bei einem Boot der durch massiven Multicast-Verkehr der durch T-Entertain ausgelöst worden ist konnte ich bereits an ELV schicken.
Die selteneren Boots, die bei mir in Abständen von einigen zig bis zu 800 Stunden auftreten, erwarte ich z. Zt. ... wireshark läuft mit (uptime ist aktuell 223 Stunden)
Heute ist nach 409 Stunden uptime ein Reboot (ohne Multicastlast) des HMLAN erfolgt ... der Wireshark-Log ist auf dem Weg über ELV an eQ-3
Ich habe mir den Log etwas genauer angesehen und das bringt mich zu einer Frage an Martin!!
Fhem sendet ja im Normalfall (unveränderter wdTimer) alle 25 Sekunden ein K-Kommando an den HMLAN. Das ist im Log auch sehr gut zu sehen
Allerdings ist das letzte Paket, das vor dem Reboot an den HMLAN gesendet wird ein K-Kommando ... und das wird dann, weil der HMLAN nicht acknowledged, mehrfach retransmittet. Was jetzt interessant ist ist, dass dieses K-Kommando nicht 25 Sekunden nach dem vorherigen geschickt worden ist, sondern schon nach 13,4 Sekunden :o gibt es einen Grund, aus dem ein K-Kommando schon vorzeitig verschickt wird ?
PS wenn genauere Informationen aus dem Log benötigt werden kann ich die gerne liefern
Mir ist noch etwas aufgefallen ...
unmittelbar vor dem K-Kommando wurde von Fhem etwas an ein HM-Gerät gesendet (Thermostat) ... was bei mir eher selten passiert
Zitat58675 17:13:27.207851000 192.168.1.41 192.168.1.42 TCP 120 4679→1000 [PSH, ACK] Seq=1761 Ack=214609 Win=64767 Len=66
58677 17:13:27.217844000 192.168.1.41 192.168.1.42 TCP 60 4679→1000 [PSH, ACK] Seq=1827 Ack=214609 Win=64767 Len=3
dazu könnte folgender Eintrag im Fhem bei den Device Redaings passen
Zitat2016-05-26 17:13:20 state CMDs_done
2016-05-26 17:13:20 time-request -
die Zeit zwischen dem Fhem-Server und dem Wireshark-Laptop ist nicht exakt synchroniert
Das Paket sieht so aus
Zitat0000 00 1a 22 05 19 c8 00 0a e4 8b c3 d5 08 00 45 00 .."...........E.
0010 00 6a 7b 08 40 00 80 06 fb e1 c0 a8 01 29 c0 a8 .j{.@........)..
0020 01 2a 12 47 03 e8 be b6 3b 19 80 b0 b5 33 50 18 .*.G....;....3P.
0030 fc ff 09 dc 00 00 53 45 44 41 30 38 34 45 34 2c ......SEDA084E4,
0040 30 30 2c 30 30 30 30 30 30 30 30 2c 30 31 2c 45 00,00000000,01,E
0050 44 41 30 38 34 45 34 2c 37 34 38 30 33 46 32 41 DA084E4,74803F2A
0060 45 44 41 32 33 35 42 36 30 46 30 32 30 34 31 45 EDA235B60F02041E
0070 44 39 43 46 31 30 0d 0a D9CF10..
Zitat von: Nobby1805 am 27 Mai 2016, 09:44:19
Fhem sendet ja im Normalfall (unveränderter wdTimer) alle 25 Sekunden ein K-Kommando an den HMLAN. Das ist im Log auch sehr gut zu sehen
Allerdings ist das letzte Paket, das vor dem Reboot an den HMLAN gesendet wird ein K-Kommando ... und das wird dann, weil der HMLAN nicht acknowledged, mehrfach retransmittet. Was jetzt interessant ist ist, dass dieses K-Kommando nicht 25 Sekunden nach dem vorherigen geschickt worden ist, sondern schon nach 13,4 Sekunden :o gibt es einen Grund, aus dem ein K-Kommando schon vorzeitig verschickt wird ?
Hallo Nobby,
so wie ich das sehe, braucht doch der HM-Lan Adapter mind. alle 30 Sec. ein K-Command, sonst folgt ein disconnect. Folglich sind die 13,4 Sec. doch eher besser, zumindest was die disconnects angeht.
Gibst schon was neues ?
mfg Klaus
Hallo Klaus,
nein, ich warte jetzt auf ein zweites Auftreten um die beiden zu vergleichen ...
Wenn alle 30 Sekunden ein K-Kommando benötigt wird dann ist alles kleiner 29 nicht besser sondern verringert nur die Wahrscheinlichkeit, dass durch eine Verzögerung ein Timeout passiert.
Mir geht es im Prinzip erst mal darum, ob es einen Grund gibt dass das Kommando schon vorab geschickt worden ist. ES ist ja schon "komisch", dass das in direktem Zusammenhang mit dem Reboot steht.
Gruß Norbert
PS ich hoffe jetzt nur, dass mein Uralt-Laptop mit Wireshark (auf Windows XP) überlebt, einmal hat er sich vermutlich aus Wärmegründen schon aufgehängt
PPS ich bin übrigens der Meinung, dass das mit den 30 Sekunden nicht ganz richtig ist ... der HMLAN disconnectet, wenn er 30 Sekunden weder etwas gesendet noch etwas empfangen hat ... man könnte also auch den Timer bei jedem bearbeiteten Paket wieder zurücksetzen.
Zitat von: Nobby1805 am 28 Mai 2016, 19:04:36
Es ist ja schon "komisch", dass das in direktem Zusammenhang mit dem Reboot steht.
100 % agree
Zitat von: Nobby1805 am 27 Mai 2016, 09:44:19
Ich habe mir den Log etwas genauer angesehen und das bringt mich zu einer Frage an Martin!!
Fhem sendet ja im Normalfall (unveränderter wdTimer) alle 25 Sekunden ein K-Kommando an den HMLAN. Das ist im Log auch sehr gut zu sehen
Allerdings ist das letzte Paket, das vor dem Reboot an den HMLAN gesendet wird ein K-Kommando ... und das wird dann, weil der HMLAN nicht acknowledged, mehrfach retransmittet. Was jetzt interessant ist ist, dass dieses K-Kommando nicht 25 Sekunden nach dem vorherigen geschickt worden ist, sondern schon nach 13,4 Sekunden :o gibt es einen Grund, aus dem ein K-Kommando schon vorzeitig verschickt wird ?
PS wenn genauere Informationen aus dem Log benötigt werden kann ich die gerne liefern
Heute ist nach 85:00 Stunden das Problem wieder aufgetreten, die Situation vor dem Absturz des HMLAN sieht sehr ähnlich aus.
Wieder ist ein Kommando an einen Thermostaten gesendet worden (vermutlich Zeit setzen) und wieder wurde unmittelbar danach ein K-Kommando geschickt, das dann auf TCP-Ebene nicht mehr quittiert (und daher retransmittet) worden ist.
K-Kommando 6:13:40.404
Antwort des HMLAN um 6:13:40.410
Empfange Daten vom HMLAN um 6:13:41.651
Sende Daten an HMLAN um 6:13:41.748
erneute K-Kommando um 6:13:41.772 (also 1,3 Sekunden nach dem vorherigen)
Ich habe den Wireshark-Log wieder über ELV an eQ-3 geschickt
Hi,
Zitat von: Nobby1805 am 30 Mai 2016, 12:52:46
Wieder ist ein Kommando an einen Thermostaten gesendet worden (vermutlich Zeit setzen) und wieder wurde unmittelbar danach ein K-Kommando geschickt, das dann auf TCP-Ebene nicht mehr quittiert (und daher retransmittet) worden ist.
Was passiert denn, wenn man das KeepAlive nach 10 Sendevorgaengen im Code disabled?
Index: 00_HMLAN.pm
===================================================================
--- 00_HMLAN.pm (revision 11566)
+++ 00_HMLAN.pm (working copy)
@@ -891,7 +891,7 @@
syswrite($hash->{TCPDev}, $msg) if($hash->{TCPDev});
if ($hash->{helper}{q}{scnt} == 10){
$hash->{helper}{q}{scnt} = 0;
- HMLAN_KeepAlive("x:$name") ;
+ #HMLAN_KeepAlive("x:$name") ;
}
}
Evtl. kommt dieses K zu schnell während der HMLAN gerade noch mit dem vorherigen Kommando bzw. dessen Antwort beschäftigt ist.
Viele Grüße
Michael
Das könnte man mal probieren ... aber dann müsste man sehr lange warten, ob es nicht doch noch passiert :-\
Oder man ändert von 10 auf einen kleineren Wert, dann müsste es doch öfter passieren ?
Warum wird das denn überhaupt gemacht ?
UND vermutlich sind wir uns einig, dass das bei einer sauberen Programmierung im HMLAN aber NICHT zu einem Crash führen dürfte ::)
Hi,
Zitat von: Nobby1805 am 30 Mai 2016, 16:53:29
Das könnte man mal probieren ... aber dann müsste man sehr lange warten, ob es nicht doch noch passiert :-\
Oder man ändert von 10 auf einen kleineren Wert, dann müsste es doch öfter passieren ?
Ja, teste es evtl. mal mit 1.
Zitat
Warum wird das denn überhaupt gemacht ?
Das ganze kam am 24.6.2015 in Fhem und hatte als Log-Eintrag "00_HMLAN: regular read IO load".
IIRC begannen danach dann auch die HMLAN-Disconnectes beim Ansteuern der HM-OU-LED16. In dem Log, das ich gerade gefunden habe, war der Auslöser auch das "K" während eines laufenden Sendevorgangs: https://forum.fhem.de/index.php/topic,41024.msg334302.html#msg334302
Zitat
UND vermutlich sind wir uns einig, dass das bei einer sauberen Programmierung im HMLAN aber NICHT zu einem Crash führen dürfte ::)
Da stimme ich Dir voll und ganz zu, das müsste eQ-3 fixen (die Hoffnung stirbt zuletzt)...
Aber evtl. kann hier Martin im 00_HMLAN-Code einen Workaround bauen, damit die "K"s nicht gesendet werden, solange ein "S"endevorgang läuft. Die "normalen" Keepalives alle 25 Sekunden können übrigens auch zufällig genau zum falschen Zeitpunk kommen und den Crash auslösen, das ist aber deutlich unwahrscheinlicher.
Viele Grüße
Michael
Hallo,
so, jetzt habe ich 00_HMLAN.pm mal so umgebaut, dass ein K niemals einen laufenden Sendevorgang unterbrechen kann. Bitte mal testen und schauen, ob dieser Patch die Probleme behebt.
@Martin: Schau mal bitte drueber, ich bin mir nicht sicher, ob ich das "sending" ueberall wieder auf 0 setze, wo es sein muss (nach "R" und wenn ein HMLAN (re-)connected).
Viele Gruesse
Michael
Ich habe gerade von ELV eine Mail bekommen, dass das Problem reproduziert werden konnte und die Entwicklungsabteilung an einem Fix arbeitet.
Das ist die gute Nachricht, jetzt bleibt nur zu hoffen, dass die Veröffentlichung nicht wieder so lange wie bei der Version 0.965 dauert.
@mgernoth: dein neues Module wollte ich erst mal absichtlich nicht aktivieren, weil ich ja weitere Logs an eQ-3 senden wollte ... aber das hat sich ja jetzt erledigt.
Btw. ich hatte die Grenze auf 3 reduziert ... aber nichts ist passiert ... vielleicht aber deshalb, weil ich gleichzeitig verbose am HMLAN auf 5 gesetzt habe (ja, ich weiß, man sollte nie an mehreren Stellen gleichzeitig "drehen" ::) ) ... dadurch scheint sich das Timing leicht (aber entscheidend) zu ändern
Hallo alle!
Ich hoffe ich bin hier nicht falsch; habe das auch in einem anderen Thread gepostet, bevor ich über diesen hier gestolpert bin. habe auch dieses Problem: Mein HM-CFG-LAN Adapter rebootet (uptime geht auf 0) allerdings alle paar Minuten!
Bei mir läuft FHEM auf einer Synology DS414, und ist eine komplett neue Installation (ich steige gerade von einer reinen CCU2 basierenden Lösung auf FHEM um und bin Neuling).
Das habe ich bereits gemacht:
- Aktivierung des zweiten NICs auf der DS414, Vergabe einer eigenen IP in einem neuen Subnetz, und anschließen des HM-CFG-LAN Adapters an diesem Interface (direkt, ohne Switch dazwischen).
Die Verbindung klappt, die Reboots bleiben.
- Einstelllen dieses Interfaces auf 10Mbit/half Duplex und auto nego deaktivieren.
Kein Unterschied
Und so sieht das bei mir im Log aus:
2016.06.06 23:29:26 1: 192.168.240.123:1000 disconnected, waiting to reappear (HMLAN0)
2016.06.06 23:29:26 1: HMLAN_Parse: HMLAN0 new condition disconnected
2016.06.06 23:29:26 1: 192.168.240.123:1000 reappeared (HMLAN0)
2016.06.06 23:29:26 1: HMLAN_Parse: HMLAN0 new condition init
2016.06.06 23:29:26 1: HMLAN_Parse: HMLAN0 new condition ok
2016.06.06 23:33:36 1: 192.168.240.123:1000 disconnected, waiting to reappear (HMLAN0)
2016.06.06 23:33:36 1: HMLAN_Parse: HMLAN0 new condition disconnected
2016.06.06 23:33:36 1: 192.168.240.123:1000 reappeared (HMLAN0)
2016.06.06 23:33:36 1: HMLAN_Parse: HMLAN0 new condition init
2016.06.06 23:33:36 1: HMLAN_Parse: HMLAN0 new condition ok
2016.06.06 23:34:26 1: 192.168.240.123:1000 disconnected, waiting to reappear (HMLAN0)
2016.06.06 23:34:26 1: HMLAN_Parse: HMLAN0 new condition disconnected
2016.06.06 23:34:27 1: 192.168.240.123:1000 reappeared (HMLAN0)
2016.06.06 23:34:27 1: HMLAN_Parse: HMLAN0 new condition init
2016.06.06 23:34:27 1: HMLAN_Parse: HMLAN0 new condition ok
Liebe Grüße,
Max
schau mal im Fhem wiki, wie man das AES mit der Homematic Konfigurator auf den Lanseite auschaltet
AES ist auf der LAN-Seite deaktiviert. Ich habe die Firmware des Adapters upgedatet, die IP fixiert, und AES abgedreht; das waren die ersten Schritte, noch bevor ich die erste Verbindung mit FHEM hergestellt hatte.
ps: Die Kommunikation mit HM Devices funktioniert ja auch, sofern der Adapter nicht gerade neu startet ... ;-)
dann mußt du sniffen wie im Wiki beschrieben
, und zeige ein list von dem HmLan adapter
ich hasse Textaufgaben ohne Ihnhalt, auf deutsch will sehen was du auf dem Bildschirm siehst.
ich würde einen eigenen Beitrag aufmachen, hat hier mit dem Problem nichts zu tun.
Ich stelle gerne jeder Information zu Verfügung. Ich bin halt Anfänger, und weiß nicht was gebraucht wird. Unten der Output von dem List.
Soweit ich Nobby verstanden habe (auch aus anderen Threads, bzw. seiner Diskussion zu dem Thema auf der ELV Webseite), hat er genau das selbe Problem wie ich: Der Adapter rebootet aus unerklärlichen Gründen. Bei mir halt deutlich häufiger als bei ihm.
Sniffen wird schwierig, da der Adapter, wie bereits geschrieben, direkt, ohne Switch, an der Synology hängt. Ich kann ihn zwar wieder normal, an den Switch, anhängen, das hilft nur nichts, da ich zu Hause nicht über managebare Switches verfüge, auf denen ich Ports spiegeln könnte. Ich werde aber mal mit tcpdump auf der Synology experimentieren. Da sollte man ja alles mitbekommen, da wie gesagt der Adapter direkt an dem zweiten Interface angeschlossen ist.
Internals:
DEF 192.168.240.123:1000
DeviceName 192.168.240.123:1000
FD 4
HMLAN0_MSGCNT 645
HMLAN0_TIME 2016-06-07 01:01:47
IFmodel LAN
NAME HMLAN0
NR 24
NTFY_ORDER 50-HMLAN0
PARTIAL
RAWMSG E3740BA,0000,00025BD5,FF,FFA3,BE86533740BA000000004100B24200B543FFFD440003
RSSI -93
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 3
msgKeepAlive dlyMax:0.03 bufferMin:4
msgLoadCurrent 1
msgLoadHistory 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
msgParseDly min:-9 max:23 last:12 cnt:315
owner 351B6A
owner_CCU VCCU
uptime 000 00:02:34.581
Readings:
2016-06-06 22:46:05 D-HMIdAssigned 351B6A
2016-06-06 22:46:05 D-HMIdOriginal 3223F1
2016-06-06 22:46:05 D-firmware 0.964
2016-06-06 22:46:05 D-serialNr LEQ0986111
2016-06-07 01:00:16 Xmit-Events timeout:15 ok:38 disconnected:38 init:38
2016-06-07 01:00:16 cond ok
2016-06-07 01:01:31 loadLvl low
2016-06-07 00:59:10 prot_disconnected last
2016-06-07 01:00:16 prot_init last
2016-06-07 01:00:16 prot_ok last
2016-06-07 00:59:10 prot_timeout last
2016-06-07 01:00:16 state opened
Helper:
assIdCnt 3
assIdRep 3
info 03C4,LEQ0986111,3223F1,351B6A
setTime 44716
Bm:
Hmlan_get:
cnt 3
dmx 0
mAr
max 0
tot 0
Hmlan_notify:
cnt 670
dmx 0
max 14
tot 95
mAr:
HASH(0x1698e98)
HASH(0x1698e98)
Hmlan_read:
cnt 961
dmx 0
max 362
tot 5273
mAr:
HASH(0x1698e98)
Hmlan_ready:
cnt 785
dmx 0
max 3120
tot 42524
mAr:
HASH(0x1698e98)
Hmlan_set:
cnt 76
dmx 0
mAr
max 0
tot 0
Cnd:
0 38
252 15
253 38
255 38
Dly:
cnt 315
lst 12
max 23
min -9
Ids:
38668d:
cfg +38668D,00,01,00
name TFKontaktSZLinks
3866b9:
cfg +3866B9,02,01,00
chn 00
flg 0
msg
name TFKontaktSZRechts
to 1465251551.08803
38671a:
cfg +38671A,00,01,00
chn 01
flg 0
msg
name TFKontaktWZ
to 1465250203.69884
K:
BufMin 4
DlyMax 0.03
Next 1465254116.17412
Start 1465254091.17412
Loadlvl:
bl 40
a:
99
90
40
0
H:
0 low
40 batchLevel
90 high
99 suspended
Log:
all 0
sys 0
ids:
ARRAY(0x169a4f0)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLast 1
loadNo 0
scnt 0
apIDs:
Ref:
drft -0.000159936025589764
hmtL 137856
kTs 0
offL 1465253953321
sysL 1465254091177
Attributes:
hmId 351B6A
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
Zur Info: Mein FHEM ist eine Neuinstallation, und es gibt aktuell nur folgende 4 Komponenten:
HM-CFG-LAN Adapter
3 Stück Tür/Fenster Kontakte
Alle weiteren HM Komponenten, oder sonstige Devices bei mir habe ich noch nicht hinzugefügt.
Ich habe perfmon installiert und bekomme ab und zu (aber nicht so oft wie die Reboots des HM-CFG-LAN Adapters) folgende Meldung (Zeit variiert zwischen 1 und 3 Sekunden):
2016.06.07 08:01:11 1: Perfmon: possible freeze starting at 08:01:08, delay is 3.034
Der Output von "apptime maxDly all" sieht so aus (nur die ersten paar Zeilen):
name function max count total average maxDly
tmr-perfmon_ProcessTimer HASH(0x12cb058) 40 32905 509 0.02 3134 HASH(0x12cb058)
tmr-FW_closeInactiveClients 91 551 92 0.17 3034
tmr-CUL_HM_ActCheck ActionDetector 451 55 727 13.22 2979 ActionDetector
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN0 135 1356 827 0.61 205 keepAliveCk:HMLAN0
tmr-HMLAN_KeepAlive keepAlive:HMLAN0 23 1238 101 0.08 30 keepAlive:HMLAN0
Und ich habe mit tcpdump mitgeschaut ... ich vermute, dass eines der Multicast Pakete den Reboot auslöst ... Hier sieht man zu welchem Zeitpunkt der Adapter rebootet hat, bzw. eigentlich zu welchem Zeitpunkt FHEM das mitbekommen hat ... :
2016.06.07 08:03:16 1: 192.168.240.123:1000 reappeared (HMLAN0)
2016.06.07 08:03:16 1: HMLAN_Parse: HMLAN0 new condition init
2016.06.07 08:03:16 1: HMLAN_Parse: HMLAN0 new condition ok
2016.06.07 08:05:46 1: 192.168.240.123:1000 disconnected, waiting to reappear (HMLAN0)
2016.06.07 08:05:46 1: HMLAN_Parse: HMLAN0 new condition disconnected
2016.06.07 08:05:46 1: 192.168.240.123:1000 reappeared (HMLAN0)
2016.06.07 08:05:46 1: HMLAN_Parse: HMLAN0 new condition init
2016.06.07 08:05:46 1: HMLAN_Parse: HMLAN0 new condition ok
Und hier die Pakete in dieser Zeit, bzw. ab etwa einer Minute davor. Ich versuche heute mal mit iptables sämtlichen Traffic auf diesem Interface zu blockieren der nicht explizit vom/zum HM-CFG-LAN Adapter kommt; aber die Synology überschreibt meine iptables Regeln immer wieder ... komme erst heute Abend dazu mir das anzusehen. Zur Info_ 192.168.240.1 ist die IP der Synology in dem separatem Testnetz für den HM-CFG-LAN Adapter, und 192.168.240.123 ist jene des Adapters.
08:04:35.352881 IP 192.168.240.123.1000 > 192.168.240.1.53372: Flags [P.], seq 813:871, ack 215, win 4380, length 58
08:04:35.352945 IP 192.168.240.1.53372 > 192.168.240.123.1000: Flags [.], ack 871, win 15544, length 0
08:04:35.394041 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [5q] PTR (QM)? _raop._tcp.local. TXT (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. SRV (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. PTR (QM)? _airport._tcp.local. PTR (QM)? _airplay._tcp.local. (97)
08:04:35.483907 IP 192.168.240.123.1000 > 192.168.240.1.53372: Flags [P.], seq 871:937, ack 215, win 4380, length 66
08:04:35.483969 IP 192.168.240.1.53372 > 192.168.240.123.1000: Flags [.], ack 937, win 15544, length 0
08:04:35.553883 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [8q] SRV (QM)? MaxTV._airplay._tcp.local. TXT (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. SRV (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. TXT (QM)? 000C8AB38C23@Office._raop._tcp.local. SRV (QM)? 000C8AB38C23@Office._raop._tcp.local. TXT (QM)? MaxTV._airplay._tcp.local. TXT (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. SRV (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. (154)
08:04:35.683802 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [2q] SRV (QM)? KAirPortTimeCapsule._airport._tcp.local. TXT (QM)? KAirPortTimeCapsule._airport._tcp.local. (63)
08:04:35.735802 IP 192.168.240.123.1000 > 192.168.240.1.53372: Flags [P.], seq 937:997, ack 215, win 4380, length 60
08:04:35.735840 IP 192.168.240.1.53372 > 192.168.240.123.1000: Flags [.], ack 997, win 15544, length 0
08:04:56.064105 IP 192.168.240.1.53372 > 192.168.240.123.1000: Flags [P.], seq 215:218, ack 997, win 15544, length 3
08:04:56.064514 IP 192.168.240.123.1000 > 192.168.240.1.53372: Flags [.], ack 218, win 4380, length 0
08:04:56.066547 IP 192.168.240.123.1000 > 192.168.240.1.53372: Flags [P.], seq 997:1056, ack 218, win 4380, length 59
08:04:56.066580 IP 192.168.240.1.53372 > 192.168.240.123.1000: Flags [.], ack 1056, win 15544, length 0
08:05:21.074330 IP 192.168.240.1.53372 > 192.168.240.123.1000: Flags [P.], seq 218:221, ack 1056, win 15544, length 3
08:05:21.074698 IP 192.168.240.123.1000 > 192.168.240.1.53372: Flags [.], ack 221, win 4380, length 0
08:05:21.076734 IP 192.168.240.123.1000 > 192.168.240.1.53372: Flags [P.], seq 1056:1115, ack 221, win 4380, length 59
08:05:21.076777 IP 192.168.240.1.53372 > 192.168.240.123.1000: Flags [.], ack 1115, win 15544, length 0
08:05:34.901823 IP 0.0.0.0 > 255.255.255.255: igmp v1 report 255.255.255.255 [len 42]
08:05:34.902258 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1a:22:04:a0:f1, length 300
08:05:34.902709 IP 192.168.240.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 304
08:05:34.903964 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1a:22:04:a0:f1, length 300
08:05:34.964195 IP 192.168.240.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 304
08:05:35.820288 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0*- [0q] 37/0/0 (Cache flush) AAAA fe80::211:32ff:fe28:78d4, (Cache flush) PTR MaxDS414.local., (Cache flush) A 192.168.240.1, (Cache flush) PTR MaxDS414.local., (Cache flush) HINFO, PTR MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local., (Cache flush) SRV MaxDS414.local.:9 0 0, (Cache flush) TXT "", PTR MAXDS414._smb._tcp.local., (Cache flush) SRV MaxDS414.local.:445 0 0, (Cache flush) TXT "", PTR _smb._tcp.local., PTR iTunes_Ctrl_0011322878D36011._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6011 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR _dacp._tcp.local., PTR iTunes_Ctrl_0011322878D36012._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6012 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36013._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6013 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36014._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6014 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR MaxDS414._http._tcp.local., (Cache flush) SRV MaxDS414.local.:5000 0 0, (Cache flush) TXT "vendor=Synology" "model=DS414" "serial=13C0LUN000988" "version_major=6" "version_minor=0" "version_build=7321" "admin_port=5000" "secure_admin_port=5001" "mac_address=00:11:32:28:78:D3", PTR _http._tcp.local., PTR MaxDS414._device-info._tcp.local., (Cache flush) SRV MaxDS414.local.:0 0 0, (Cache flush) TXT "model=Xserve", PTR _device-info._tcp.local., PTR MaxDS414._webdavs._tcp.local., (Cache flush) SRV MaxDS414.local.:5006 0 0, (Cache flush) TXT "", PTR _webdavs._tcp.local. (1231)
08:05:35.833728 IP 192.168.240.1 > 224.0.0.22: igmp v3 report, 1 group record(s)
08:05:35.957073 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:35.957154 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:35.957200 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:35.957279 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:35.957326 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:35.960407 IP 192.168.240.1.138 > 192.168.240.255.138: NBT UDP PACKET(138)
08:05:35.960638 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
08:05:36.992364 IP 192.168.240.123 > 255.255.255.255: igmp v1 report 255.255.255.255 [len 42]
08:05:37.623742 IP 192.168.240.1 > 224.0.0.22: igmp v3 report, 1 group record(s)
08:05:37.674084 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [3q] [5n] ANY (QM)? 4.d.8.7.8.2.e.f.f.f.2.3.1.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? MaxDS414.local. ANY (QM)? 1.240.168.192.in-addr.arpa. (235)
08:05:37.713856 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [3q] PTR (QM)? _raop._tcp.local. PTR (QM)? _airport._tcp.local. PTR (QM)? _airplay._tcp.local. (64)
08:05:37.863972 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [8q] SRV (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. TXT (QM)? KAirPortTimeCapsule._airport._tcp.local. TXT (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. SRV (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. TXT (QM)? MaxTV._airplay._tcp.local. SRV (QM)? MaxTV._airplay._tcp.local. SRV (QM)? KAirPortTimeCapsule._airport._tcp.local. TXT (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. (160)
08:05:37.960207 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [3q] [5n] ANY (QM)? 4.d.8.7.8.2.e.f.f.f.2.3.1.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? MaxDS414.local. ANY (QM)? 1.240.168.192.in-addr.arpa. (235)
08:05:37.983881 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:37.983935 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:37.983966 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:37.983995 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:37.984023 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:37.984056 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
08:05:37.984951 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:37.984992 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:37.985024 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:37.985057 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:37.985087 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:37.985118 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
08:05:38.063866 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [2q] SRV (QM)? 000C8AB38C23@Office._raop._tcp.local. TXT (QM)? 000C8AB38C23@Office._raop._tcp.local. (60)
08:05:38.173966 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [2q] SRV (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. TXT (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. (64)
08:05:38.184721 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [3q] [5n] ANY (QM)? 4.d.8.7.8.2.e.f.f.f.2.3.1.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? MaxDS414.local. ANY (QM)? 1.240.168.192.in-addr.arpa. (235)
08:05:38.386125 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0*- [0q] 5/0/0 (Cache flush) PTR MaxDS414.local., (Cache flush) HINFO, (Cache flush) A 192.168.240.1, (Cache flush) PTR MaxDS414.local., (Cache flush) AAAA fe80::211:32ff:fe28:78d4 (217)
08:05:38.444146 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [9q] [18n] ANY (QM)? MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36011._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36012._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36013._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36014._dacp._tcp.local. ANY (QM)? MaxDS414._http._tcp.local. ANY (QM)? MaxDS414._smb._tcp.local. ANY (QM)? MaxDS414._device-info._tcp.local. ANY (QM)? MaxDS414._webdavs._tcp.local. (875)
08:05:38.704214 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [9q] [18n] ANY (QM)? MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36011._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36012._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36013._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36014._dacp._tcp.local. ANY (QM)? MaxDS414._http._tcp.local. ANY (QM)? MaxDS414._smb._tcp.local. ANY (QM)? MaxDS414._device-info._tcp.local. ANY (QM)? MaxDS414._webdavs._tcp.local. (875)
08:05:38.723854 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [3q] PTR (QM)? _raop._tcp.local. PTR (QM)? _airport._tcp.local. PTR (QM)? _airplay._tcp.local. (64)
08:05:38.864412 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [8q] SRV (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. TXT (QM)? KAirPortTimeCapsule._airport._tcp.local. TXT (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. SRV (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. TXT (QM)? MaxTV._airplay._tcp.local. SRV (QM)? MaxTV._airplay._tcp.local. SRV (QM)? KAirPortTimeCapsule._airport._tcp.local. TXT (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. (160)
08:05:38.954196 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [9q] [18n] ANY (QM)? MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36011._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36012._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36013._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36014._dacp._tcp.local. ANY (QM)? MaxDS414._http._tcp.local. ANY (QM)? MaxDS414._smb._tcp.local. ANY (QM)? MaxDS414._device-info._tcp.local. ANY (QM)? MaxDS414._webdavs._tcp.local. (875)
08:05:39.064090 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [2q] SRV (QM)? 000C8AB38C23@Office._raop._tcp.local. TXT (QM)? 000C8AB38C23@Office._raop._tcp.local. (60)
08:05:39.159249 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0*- [0q] 35/0/0 (Cache flush) TXT "", PTR iTunes_Ctrl_0011322878D36011._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6011 0 0, (Cache flush) AAAA fe80::211:32ff:fe28:78d4, (Cache flush) A 192.168.240.1, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36012._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6012 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36013._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6013 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36014._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6014 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR _dacp._tcp.local., PTR MaxDS414._http._tcp.local., (Cache flush) SRV MaxDS414.local.:5000 0 0, (Cache flush) TXT "vendor=Synology" "model=DS414" "serial=13C0LUN000988" "version_major=6" "version_minor=0" "version_build=7321" "admin_port=5000" "secure_admin_port=5001" "mac_address=00:11:32:28:78:D3", PTR _http._tcp.local., PTR MAXDS414._smb._tcp.local., (Cache flush) SRV MaxDS414.local.:445 0 0, (Cache flush) TXT "", PTR _smb._tcp.local., PTR MaxDS414._device-info._tcp.local., (Cache flush) SRV MaxDS414.local.:0 0 0, (Cache flush) TXT "model=Xserve", PTR _device-info._tcp.local., PTR MaxDS414._webdavs._tcp.local., (Cache flush) SRV MaxDS414.local.:5006 0 0, (Cache flush) TXT "", PTR _webdavs._tcp.local., PTR MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local., (Cache flush) SRV MaxDS414.local.:9 0 0, PTR _workstation._tcp.local. (1107)
08:05:39.183936 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [2q] SRV (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. TXT (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. (64)
08:05:39.404422 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0*- [0q] 3/0/0 (Cache flush) PTR MaxDS414.local., (Cache flush) HINFO, (Cache flush) PTR MaxDS414.local. (173)
08:05:40.003853 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:40.003897 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:40.003927 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:40.003954 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:40.003982 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:40.004015 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
08:05:40.005523 IP 192.168.240.1.138 > 192.168.240.255.138: NBT UDP PACKET(138)
08:05:40.168237 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0*- [0q] 35/0/0 (Cache flush) TXT "", PTR iTunes_Ctrl_0011322878D36011._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6011 0 0, (Cache flush) AAAA fe80::211:32ff:fe28:78d4, (Cache flush) A 192.168.240.1, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36012._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6012 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36013._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6013 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36014._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6014 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR _dacp._tcp.local., PTR MaxDS414._http._tcp.local., (Cache flush) SRV MaxDS414.local.:5000 0 0, (Cache flush) TXT "vendor=Synology" "model=DS414" "serial=13C0LUN000988" "version_major=6" "version_minor=0" "version_build=7321" "admin_port=5000" "secure_admin_port=5001" "mac_address=00:11:32:28:78:D3", PTR _http._tcp.local., PTR MAXDS414._smb._tcp.local., (Cache flush) SRV MaxDS414.local.:445 0 0, (Cache flush) TXT "", PTR _smb._tcp.local., PTR MaxDS414._device-info._tcp.local., (Cache flush) SRV MaxDS414.local.:0 0 0, (Cache flush) TXT "model=Xserve", PTR _device-info._tcp.local., PTR MaxDS414._webdavs._tcp.local., (Cache flush) SRV MaxDS414.local.:5006 0 0, (Cache flush) TXT "", PTR _webdavs._tcp.local., PTR MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local., (Cache flush) SRV MaxDS414.local.:9 0 0, PTR _workstation._tcp.local. (1107)
08:05:40.733875 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [3q] PTR (QM)? _raop._tcp.local. PTR (QM)? _airport._tcp.local. PTR (QM)? _airplay._tcp.local. (64)
08:05:40.883848 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [8q] SRV (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. TXT (QM)? KAirPortTimeCapsule._airport._tcp.local. TXT (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. SRV (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. TXT (QM)? MaxTV._airplay._tcp.local. SRV (QM)? MaxTV._airplay._tcp.local. SRV (QM)? KAirPortTimeCapsule._airport._tcp.local. TXT (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. (160)
08:05:41.083950 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [4q] SRV (QM)? 000C8AB38C23@Office._raop._tcp.local. TXT (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. SRV (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. TXT (QM)? 000C8AB38C23@Office._raop._tcp.local. (96)
08:05:41.414228 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0*- [0q] 5/0/0 (Cache flush) PTR MaxDS414.local., (Cache flush) HINFO, (Cache flush) A 192.168.240.1, (Cache flush) PTR MaxDS414.local., (Cache flush) AAAA fe80::211:32ff:fe28:78d4 (217)
08:05:41.515456 IP 192.168.240.1.138 > 192.168.240.255.138: NBT UDP PACKET(138)
08:05:42.179089 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0*- [0q] 35/0/0 (Cache flush) TXT "", PTR iTunes_Ctrl_0011322878D36011._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6011 0 0, (Cache flush) AAAA fe80::211:32ff:fe28:78d4, (Cache flush) A 192.168.240.1, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36012._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6012 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36013._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6013 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36014._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6014 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR _dacp._tcp.local., PTR MaxDS414._http._tcp.local., (Cache flush) SRV MaxDS414.local.:5000 0 0, (Cache flush) TXT "vendor=Synology" "model=DS414" "serial=13C0LUN000988" "version_major=6" "version_minor=0" "version_build=7321" "admin_port=5000" "secure_admin_port=5001" "mac_address=00:11:32:28:78:D3", PTR _http._tcp.local., PTR MAXDS414._smb._tcp.local., (Cache flush) SRV MaxDS414.local.:445 0 0, (Cache flush) TXT "", PTR _smb._tcp.local., PTR MaxDS414._device-info._tcp.local., (Cache flush) SRV MaxDS414.local.:0 0 0, (Cache flush) TXT "model=Xserve", PTR _device-info._tcp.local., PTR MaxDS414._webdavs._tcp.local., (Cache flush) SRV MaxDS414.local.:5006 0 0, (Cache flush) TXT "", PTR _webdavs._tcp.local., PTR MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local., (Cache flush) SRV MaxDS414.local.:9 0 0, PTR _workstation._tcp.local. (1107)
08:05:42.998464 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0*- [0q] 37/0/0 (Cache flush) AAAA fe80::211:32ff:fe28:78d4, (Cache flush) PTR MaxDS414.local., (Cache flush) A 192.168.240.1, (Cache flush) PTR MaxDS414.local., (Cache flush) HINFO, PTR MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local., (Cache flush) SRV MaxDS414.local.:9 0 0, (Cache flush) TXT "", PTR MAXDS414._smb._tcp.local., (Cache flush) SRV MaxDS414.local.:445 0 0, (Cache flush) TXT "", PTR _smb._tcp.local., PTR iTunes_Ctrl_0011322878D36011._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6011 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR _dacp._tcp.local., PTR iTunes_Ctrl_0011322878D36012._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6012 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36013._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6013 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36014._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6014 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR MaxDS414._http._tcp.local., (Cache flush) SRV MaxDS414.local.:5000 0 0, (Cache flush) TXT "vendor=Synology" "model=DS414" "serial=13C0LUN000988" "version_major=6" "version_minor=0" "version_build=7321" "admin_port=5000" "secure_admin_port=5001" "mac_address=00:11:32:28:78:D3", PTR _http._tcp.local., PTR MaxDS414._device-info._tcp.local., (Cache flush) SRV MaxDS414.local.:0 0 0, (Cache flush) TXT "model=Xserve", PTR _device-info._tcp.local., PTR MaxDS414._webdavs._tcp.local., (Cache flush) SRV MaxDS414.local.:5006 0 0, (Cache flush) TXT "", PTR _webdavs._tcp.local. (1231)
08:05:43.013738 IP 192.168.240.1 > 224.0.0.22: igmp v3 report, 1 group record(s)
08:05:43.116608 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:43.116699 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:43.116759 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:43.116849 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:43.116908 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:43.119931 IP 192.168.240.1.138 > 192.168.240.255.138: NBT UDP PACKET(138)
08:05:43.120171 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
08:05:44.093725 IP 192.168.240.1 > 224.0.0.22: igmp v3 report, 1 group record(s)
08:05:44.154046 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [3q] [5n] ANY (QM)? 4.d.8.7.8.2.e.f.f.f.2.3.1.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? MaxDS414.local. ANY (QM)? 1.240.168.192.in-addr.arpa. (235)
08:05:44.186636 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [3q] PTR (QM)? _raop._tcp.local. PTR (QM)? _airport._tcp.local. PTR (QM)? _airplay._tcp.local. (64)
08:05:44.359182 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [10q] SRV (QM)? KAirPortTimeCapsule._airport._tcp.local. TXT (QM)? 000C8AB38C23@Office._raop._tcp.local. SRV (QM)? 000C8AB38C23@Office._raop._tcp.local. TXT (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. SRV (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. TXT (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. SRV (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. TXT (QM)? MaxTV._airplay._tcp.local. SRV (QM)? MaxTV._airplay._tcp.local. TXT (QM)? KAirPortTimeCapsule._airport._tcp.local. (192)
08:05:44.409942 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [3q] [5n] ANY (QM)? 4.d.8.7.8.2.e.f.f.f.2.3.1.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? MaxDS414.local. ANY (QM)? 1.240.168.192.in-addr.arpa. (235)
08:05:44.503977 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [2q] SRV (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. TXT (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. (64)
08:05:44.673976 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [3q] [5n] ANY (QM)? 4.d.8.7.8.2.e.f.f.f.2.3.1.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. ANY (QM)? MaxDS414.local. ANY (QM)? 1.240.168.192.in-addr.arpa. (235)
08:05:44.876090 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0*- [0q] 5/0/0 (Cache flush) PTR MaxDS414.local., (Cache flush) HINFO, (Cache flush) A 192.168.240.1, (Cache flush) PTR MaxDS414.local., (Cache flush) AAAA fe80::211:32ff:fe28:78d4 (217)
08:05:44.954106 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [9q] [18n] ANY (QM)? MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36011._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36012._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36013._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36014._dacp._tcp.local. ANY (QM)? MaxDS414._http._tcp.local. ANY (QM)? MaxDS414._smb._tcp.local. ANY (QM)? MaxDS414._device-info._tcp.local. ANY (QM)? MaxDS414._webdavs._tcp.local. (875)
08:05:45.143944 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:45.143995 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:45.144027 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:45.144056 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:45.144085 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:45.144121 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
08:05:45.145022 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:45.145059 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:45.145091 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:45.145123 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:45.145154 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
08:05:45.145185 IP 192.168.240.1.137 > 192.168.240.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
08:05:45.203854 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [3q] PTR (QM)? _raop._tcp.local. PTR (QM)? _airport._tcp.local. PTR (QM)? _airplay._tcp.local. (64)
08:05:45.204386 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [9q] [18n] ANY (QM)? MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36011._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36012._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36013._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36014._dacp._tcp.local. ANY (QM)? MaxDS414._http._tcp.local. ANY (QM)? MaxDS414._smb._tcp.local. ANY (QM)? MaxDS414._device-info._tcp.local. ANY (QM)? MaxDS414._webdavs._tcp.local. (875)
08:05:45.293693 IP 192.168.240.1 > 224.0.0.22: igmp v3 report, 1 group record(s)
08:05:45.374403 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [10q] SRV (QM)? KAirPortTimeCapsule._airport._tcp.local. TXT (QM)? 000C8AB38C23@Office._raop._tcp.local. SRV (QM)? 000C8AB38C23@Office._raop._tcp.local. TXT (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. SRV (QM)? 745E1C575BE6@SC-LX88._raop._tcp.local. TXT (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. SRV (QM)? 7073CBD48AD2@MaxTV._raop._tcp.local. TXT (QM)? MaxTV._airplay._tcp.local. SRV (QM)? MaxTV._airplay._tcp.local. TXT (QM)? KAirPortTimeCapsule._airport._tcp.local. (192)
08:05:45.484069 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [9q] [18n] ANY (QM)? MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36011._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36012._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36013._dacp._tcp.local. ANY (QM)? iTunes_Ctrl_0011322878D36014._dacp._tcp.local. ANY (QM)? MaxDS414._http._tcp.local. ANY (QM)? MaxDS414._smb._tcp.local. ANY (QM)? MaxDS414._device-info._tcp.local. ANY (QM)? MaxDS414._webdavs._tcp.local. (875)
08:05:45.534596 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0 [2q] SRV (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. TXT (QM)? 000C8A8B78CB@Badezimmer._raop._tcp.local. (64)
08:05:45.678279 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0*- [0q] 35/0/0 (Cache flush) TXT "", PTR iTunes_Ctrl_0011322878D36011._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6011 0 0, (Cache flush) AAAA fe80::211:32ff:fe28:78d4, (Cache flush) A 192.168.240.1, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36012._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6012 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36013._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6013 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR iTunes_Ctrl_0011322878D36014._dacp._tcp.local., (Cache flush) SRV MaxDS414.local.:6014 0 0, (Cache flush) TXT "txtvers=1" "Ver=131077", PTR _dacp._tcp.local., PTR MaxDS414._http._tcp.local., (Cache flush) SRV MaxDS414.local.:5000 0 0, (Cache flush) TXT "vendor=Synology" "model=DS414" "serial=13C0LUN000988" "version_major=6" "version_minor=0" "version_build=7321" "admin_port=5000" "secure_admin_port=5001" "mac_address=00:11:32:28:78:D3", PTR _http._tcp.local., PTR MAXDS414._smb._tcp.local., (Cache flush) SRV MaxDS414.local.:445 0 0, (Cache flush) TXT "", PTR _smb._tcp.local., PTR MaxDS414._device-info._tcp.local., (Cache flush) SRV MaxDS414.local.:0 0 0, (Cache flush) TXT "model=Xserve", PTR _device-info._tcp.local., PTR MaxDS414._webdavs._tcp.local., (Cache flush) SRV MaxDS414.local.:5006 0 0, (Cache flush) TXT "", PTR _webdavs._tcp.local., PTR MaxDS414 [00:11:32:28:78:d4]._workstation._tcp.local., (Cache flush) SRV MaxDS414.local.:9 0 0, PTR _workstation._tcp.local. (1107)
08:05:45.894392 IP 192.168.240.1.5353 > 224.0.0.251.5353: 0*- [0q] 3/0/0 (Cache flush) PTR MaxDS414.local., (Cache flush) HINFO, (Cache flush) PTR MaxDS414.local. (173)
08:05:46.084501 ARP, Request who-has 192.168.240.123 tell 192.168.240.1, length 28
08:05:46.084800 ARP, Reply 192.168.240.123 is-at 00:1a:22:04:a0:f1, length 46
08:05:46.084820 IP 192.168.240.1.53372 > 192.168.240.123.1000: Flags [P.], seq 221:224, ack 1115, win 15544, length 3
08:05:46.085158 IP 192.168.240.123.1000 > 192.168.240.1.53372: Flags [R], seq 37356634, win 0, length 0
08:05:46.259397 IP 192.168.240.1.53531 > 192.168.240.123.1000: Flags , seq 2502839992, win 14600, options [mss 1460,sackOK,TS val 3574046 ecr 0,nop,wscale 4], length 0
08:05:46.262769 IP 192.168.240.123.1000 > 192.168.240.1.53531: Flags [S.], seq 7471103, ack 2502839993, win 4380, options [mss 1460], length 0
08:05:46.262821 IP 192.168.240.1.53531 > 192.168.240.123.1000: Flags [.], ack 1, win 14600, length 0
08:05:46.263443 IP 192.168.240.1.53531 > 192.168.240.123.1000: Flags [P.], seq 1:10, ack 1, win 14600, length 9
08:05:46.265679 IP 192.168.240.123.1000 > 192.168.240.1.53531: Flags [P.], seq 1:60, ack 1, win 4380, length 59
08:05:46.265720 IP 192.168.240.1.53531 > 192.168.240.123.1000: Flags [.], ack 60, win 14600, length 0
08:05:46.265922 IP 192.168.240.123.1000 > 192.168.240.1.53531: Flags [.], ack 10, win 4380, length 0
08:05:46.265949 IP 192.168.240.1.53531 > 192.168.240.123.1000: Flags [.], ack 60, win 14600, length 0
08:05:46.267209 IP 192.168.240.123.1000 > 192.168.240.1.53531: Flags [P.], seq 60:244, ack 10, win 4380, length 184
08:05:46.267244 IP 192.168.240.1.53531 > 192.168.240.123.1000: Flags [P.], seq 10:152, ack 244, win 15544, length 142
08:05:46.267794 IP 192.168.240.123.1000 > 192.168.240.1.53531: Flags [.], ack 152, win 4380, length 0
08:05:46.268506 IP 192.168.240.1.53531 > 192.168.240.123.1000: Flags [P.], seq 152:206, ack 244, win 15544, length 54
08:05:46.272838 IP 192.168.240.123.1000 > 192.168.240.1.53531: Flags [.], ack 206, win 4380, length 0
08:05:46.273362 IP 192.168.240.123.1000 > 192.168.240.1.53531: Flags [P.], seq 244:286, ack 206, win 4380, length 42
08:05:46.303697 IP 192.168.240.1.53531 > 192.168.240.123.1000: Flags [.], ack 286, win 15544, length 0
08:05:46.304484 IP 192.168.240.123.1000 > 192.168.240.1.53531: Flags [P.], seq 286:338, ack 206, win 4380, length 52
08:05:46.304525 IP 192.168.240.1.53531 > 192.168.240.123.1000: Flags [.], ack 338, win 15544, length 0
Das Thema in 2 Threads gleichzeitig abhandeln zu wollen, macht es nicht einfacher:
https://forum.fhem.de/index.php/topic,53758.msg459375.html#msg459375
;)
Ja, ich weiß, sorry. Ich hatte zuerst in einem Thread gepostet bevor ich diesen hier entdeckt hatte ... weiß nicht, wie ich zwei zusammenführen kann ... ich schreibe ab sofort einfach nicht mehr hier, sondern nur noch im anderen: https://forum.fhem.de/index.php/topic,53758.15.html
0.964 ist auch nicht die aktuelle Version der HMLAN-Firmware ... in 0.965 ist (laut eQ-3) ein Reboot-Problem behoben (wie viele es davon wohl noch gibt ;) )
Ja, das habe ich auch bereits gesehen; nur wo bekomme ich die 0.965 her? Ich habe die neueste Konfigurationsadapter Lan Usersoftware (1.520) von eq-3 heruntergeladen und sogar zweimal das Firmware Update durchgeführt ... Das Teil bleibt bei mir auf 0.964.
Generell dürfte die gute EQ-3 einige Probleme mit ihrer Software/Firmware haben ... es ist ja schon mal ein gutes Zeichen, dass das Utility den Adapter nur findet wenn man entweder alle anderen Netzwerkkarten im Laptop disabled, oder die Reihenfolge im Binding so bearbeitet, dass jene Karte in dem Netz in dem auch der Adapter ist an erster Stelle steht ...
So ... habe 0.965 gefunden ... recht irreführend die Logik von EQ-3. Einerseits schreiben Sie die Firmware des HM-CFG-LAN sei mit der Software "Konfigurationsadapter LAN Usersoftware" und eben nicht mit dem "HomeMatic Firmware Udpate Tool" upzudaten, wenn man dann aber eben Zweiteres runterlädt und dann das richtige der 3 installierten Programme startet, dann geht es doch damit. Und, surprise, surprise, ich habe jetzt 0.965. Ich teste jetzt mal damit.
Die neue Firmware sieht gut aus ... ich habe jetzt (nach wie vor auf dem eigenen Test-LAN Segment) seit 40 Minuten keinen Reboot mehr (vorher meist alle 3-4 Minuten, maximal alle 10). Ich baue jetzt wieder um und teste mit meinem normalem LAN.
Bei mir passt es jetzt nach dem Update auf 0.965 - keine Reboots mehr, auch im normalen LAN Segment.
Für meine Form der Reboots funktioniert der Fix von mgernoth in Sachen Keepalives - könnte der vielleicht fest übernommen werden?
Grüße
Hallo
Kann jemand die angepasste 00_HMLAN.pm mal hier einstellen.
Habe bei mir schon eine neuere Version Installiert
Würde mich auch über eine geänderte 00_HMLAN.pm freuen.
Gibt es eine einfach Möglichkeit, eine blabla.DIFF in ein System einzuspielen oder müsste man dies alles händisch machen ?
So wie ich das verstehe braucht es dazu die 00_HMLAN.pm r11560.
Soweit ich das sehe, ich der Keepalive-Fix bislang nicht implementiert. Man müsste also das Diff-File auf die aktuelle Version anwenden. Allerdings funktioniert das nur noch händisch, da am 12.06. eine Version mit erweitertem Kommandosatz herausgegeben wurde (reopen und reboot sind dazugekommen).
Hallo,
Zitat von: rx am 14 Juni 2016, 19:59:37
Soweit ich das sehe, ich der Keepalive-Fix bislang nicht implementiert. Man müsste also das Diff-File auf die aktuelle Version anwenden. Allerdings funktioniert das nur noch händisch, da am 12.06. eine Version mit erweitertem Kommandosatz herausgegeben wurde (reopen und reboot sind dazugekommen).
habe mal ein neues Diff erstellt.
Anwenden mit:
cd /opt/fhem
patch -p0 </path/to/keepalive-fix.diff
Viele Gruesse
Michael
Hallo
Vielen Dank.
Werde das morgen einspielen.
Geht die diff nur auf die Version 11666?
Im Moment ist bei mir die Version 11466 installiert.
Also bei mir ist die Version 11645, wo gibt es denn die 11666 ?
Habe den Fix jetzt mal auf die Version 11645 angewendet, aber ich hatte bis jetzt schon 1x reboot bei meinem HMLAN1 und 2x reboot bei meinem HMLAN2. Sonst hate ich höchstens 1x einen reboot bei einem der beiden. komischerweise läuft der HMLAN3 ohne Probleme bisher.
Es sind tatsächlich Reboots, sieht man ja anhand der uptime.
###### EDIT
Jetzt gerade hat sich der HMLAN3 auch rebootet. Ich spiel die alte Datei wieder ein.
Bei mir waren die Reboots ja in dem Senden von bestimmten Paketen begründet. Das konnte ich herausfinden, da der nur empfangene HMLAN sich nie rebootet hat.
Ich hatte dann so lange beobachtet bis ich gesehen habe, dass ein Delay zwischen dem Bestätigen des Bewegungsmelders und dem Senden an das Licht das Problem löst. Das konnte ich dann vorwärts und rückwärts nachvollziehen, d.h. Delay raus -> Regelmäßige Reboots und Delay von mindestens 750ms rein -> keine Reboots mehr.
Alternativ habe ich dann den Keepalive-Fix versucht, da ich auch schon die Beobachtung mit dem zeitnahen Senden der Keepalives und dem daraus resultierenden Reboot gemacht habe. Der Fix hat für mich den gleichen positiven Effekt, d.h. auch mit diesem Fix treten keine Reboots mehr auf. Das Delay habe ich ebenfalls wieder entfernt. D.h. der Fix scheint den gleichen Effekt wie das Delay zu haben.
Ich würde mir wünschen, dass das mit dem Keepalive dauerhaft in fhem eingebaut wird - vielleicht über eine Option aktivierbar. Dass es nicht für alle die Lösung ist, wird auch allen klar sein - dafür sind die Gründe für die Reboots zu unterschiedlich...
Grüße
... darf ich mich dranhängen?!
Seit (gefühlt) vorgestern erhalte ich nach einem Reboot oder ReloadCFG ohne Ende "unreachable" durchgehend bei allen Devices. Das sieht dann auf den Dashboard so aus, das alle nacheinander auf "unreachable" wechseln und, wenn ich Glück habe, nach und nach alle wieder zurück kommen; Lauflicht in unschön. Das Phänomen hatte ich vergangene Woche definitiv nicht.
Habe eben gerade noch mal ein Update gemacht in der Hoffnung, das irgendwo beim letzen Update (etwa 14 Tage her) was klemmte... nö...
Dann habe ich abschließend den SCC aus der Config geschmissen und hardwaretechnisch entfernt, aber auch das hat nichts geändert.
Was noch auffällig ist, ist die enorme Zeit, die nun Befehle benötigen vom Auslösen bis zur Aktion. Ich habe u.a. zwei 8CH Platinen-Aktoren (HM-MOD-Re-8), welche ich als optische Rückmeldung für allerlei Dinge benutze. Dazu gibt es einen Dummy, mit dem ich alle 2x8 Kanäle gemeinsam schalten kann. Das dauerte vorher vielleicht 3 Sekunden, bis alle Kanäle den Zustand auch physikalisch geändert haben, nunmehr vergehen da schon mal etliche Minuten, wenn es überhaupt erfolgreich durchläuft. Da tauchen dann im Log solche Dinge auf:
2016.06.17 16:35:23.913 3: CUL_HM set HM8NV1_1 off
2016.06.17 16:35:23.938 3: CUL_HM set HM8NV1_2 off
2016.06.17 16:35:23.958 3: CUL_HM set HM8NV1_3 off
2016.06.17 16:35:23.976 3: CUL_HM set HM8NV1_4 off
2016.06.17 16:35:23.989 3: CUL_HM set HM8NV1_5 off
2016.06.17 16:35:24.002 3: CUL_HM set HM8NV1_6 off
2016.06.17 16:35:24.014 3: CUL_HM set HM8NV1_7 off
2016.06.17 16:35:24.027 3: CUL_HM set HM8NV1_8 off
2016.06.17 16:35:24.051 3: CUL_HM set HM8NV2_1 off
2016.06.17 16:35:24.075 3: CUL_HM set HM8NV2_2 off
2016.06.17 16:35:24.099 3: CUL_HM set HM8NV2_3 off
2016.06.17 16:35:24.124 3: CUL_HM set HM8NV2_4 off
2016.06.17 16:35:24.148 3: CUL_HM set HM8NV2_5 off
2016.06.17 16:35:24.172 3: CUL_HM set HM8NV2_6 off
2016.06.17 16:35:24.197 3: CUL_HM set HM8NV2_7 off
2016.06.17 16:35:24.221 3: CUL_HM set HM8NV2_8 off
2016.06.17 16:36:39.269 1: HMLAN_Parse: UFO1 new condition timeout
2016.06.17 16:36:39.292 1: 192.168.1.198:1000 disconnected, waiting to reappear (UFO1)
2016.06.17 16:36:39.300 1: HMLAN_Parse: UFO1 new condition disconnected
2016.06.17 16:37:41.485 1: 192.168.1.198:1000 reappeared (UFO1)
2016.06.17 16:37:41.493 1: HMLAN_Parse: UFO1 new condition init
2016.06.17 16:37:43.987 1: HMLAN_Parse: UFO1 new condition ok
2016.06.17 16:38:49.429 3: CUL_HM set HM8NV1_1 on
2016.06.17 16:38:49.454 3: CUL_HM set HM8NV1_2 on
2016.06.17 16:38:49.474 3: CUL_HM set HM8NV1_3 on
2016.06.17 16:38:49.487 3: CUL_HM set HM8NV1_4 on
2016.06.17 16:38:49.499 3: CUL_HM set HM8NV1_5 on
2016.06.17 16:38:49.512 3: CUL_HM set HM8NV1_6 on
2016.06.17 16:38:49.525 3: CUL_HM set HM8NV1_7 on
2016.06.17 16:38:49.538 3: CUL_HM set HM8NV1_8 on
2016.06.17 16:38:49.563 3: CUL_HM set HM8NV2_1 on
2016.06.17 16:38:49.588 3: CUL_HM set HM8NV2_2 on
2016.06.17 16:38:49.613 3: CUL_HM set HM8NV2_3 on
2016.06.17 16:38:49.638 3: CUL_HM set HM8NV2_4 on
2016.06.17 16:38:49.664 3: CUL_HM set HM8NV2_5 on
2016.06.17 16:38:49.689 3: CUL_HM set HM8NV2_6 on
2016.06.17 16:38:49.715 3: CUL_HM set HM8NV2_7 on
2016.06.17 16:38:49.740 3: CUL_HM set HM8NV2_8 on
2016.06.17 16:39:00.015 1: HMLAN_Parse: UFO1 new condition timeout
2016.06.17 16:39:00.052 1: 192.168.1.198:1000 disconnected, waiting to reappear (UFO1)
2016.06.17 16:39:00.064 1: HMLAN_Parse: UFO1 new condition disconnected
2016.06.17 16:40:02.215 1: 192.168.1.198:1000 reappeared (UFO1)
2016.06.17 16:40:02.224 1: HMLAN_Parse: UFO1 new condition init
2016.06.17 16:40:05.761 1: HMLAN_Parse: UFO1 new condition ok
Wirklich eingeschaltet sind nach der Aktion allerdings nur 3 von 16 Kanälen... Ok, die Platinen sind nicht gerade die schnellsten, aber selbe Probleme bestehen auch mit allen anderen Aktoren, wie z.B. die 4CH Hutschinen- Teile... (Ich kann da gerne mal ein Video von machen, da ich die Platinen vor den Monitor legen kann, so das man beides sieht...)
Nachtrag:
Ich habe den HM-LAN jetzt mal komplett rausgeschmissen und über die VCCU nur noch den SSC dran. Jetzt ist das "Lichtorgelverhalten" zumindest weg. Leider ist das keine Dauerlösung, da der SCC bekannter Weise andere Probleme mit sich bringt. Ist also (für mich) die Frage, woran das beobachtete Verhalten nun liegt?
ZitatRegelmäßige Reboots und Delay von mindestens 750ms rein -> keine Reboots mehr.
Wie hast du das Umgesetzt?
DOIF mit Wait?
Hallo
Habe den "keepalive-fix" gestern Abend eingebaut:
Bis Heute Morgen kein Neustart von einem Lan Adapter.
HMLAN1 ist bei mir direkt an der Fritzbox
HMLAN2 über Powerline (AVM 546e an der Fritzbox, AVM 510E am Lan Adapter)
HMLAN3 über Powerline (AVM 546e an der Fritzbox, AVM 510E an einem Switch, Lan Adapter an dem Switch)
@Damu kannst du bitte mal deine gefixte 00_HMLAN.pm hier hochladen, möchte diese dann mal testen.
Ich hatte ja versucht den fix selber zu machen, aber mit der Datei hatte ich dann nur noch mehr reboots.
evtl geht es mit deiner, vielleicht hab ich ja was falsch gemacht.
Grüße Marcel
Hallo
Hier meine 00_HMLAN.pm
Perfekt ist es noch nicht, aber eben viel besse als vorher.
Habe nun mal Vebose auf 5 gestellt und werde beobachten.
Danke, werde ich gleich mal einspielen und testen.
Zitat von: Damu am 17 Juni 2016, 20:39:57
Wie hast du das Umgesetzt?
DOIF mit Wait?
Genau, ich habe in dem DOIF vor dem Einschalten der Lampen auf Grund von Bewegungsmelder-Aktivität einfach ein Sleep gesetzt. Der Keepalive-Fix scheint genau den gleichen Effekt zu haben - mittlerweile habe ich eine Uptime von 196 Stunden.
...die Reboots habe ich ja auch schon seit langem, aber ich hatte vorgestern das erste Mal den Fall, dass der HMLAN1 nach dem disconnect nicht wiedergekommen ist. Nach 2 Std. habe ich ihn dann vom Strom getrennt und wieder angeschlossen. Dann ging es wieder. Das gibt mir aber natürlich wenig Vertrauen in die Zuverlässigkeit des Systems.
Hatte das auch schon einmal jemand von Euch?
ich habe heute festgestellt das in meinem Log folgendes zu sehen ist. Das läuft endlos durch. Ist das normal?
2016.06.21 11:47:41 3: HMLAN1 device opened
2016.06.21 11:47:41 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:41 3: HMLAN1 device opened
2016.06.21 11:47:45 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:45 3: HMLAN1 device opened
2016.06.21 11:47:45 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:45 3: HMLAN1 device opened
2016.06.21 11:47:45 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:45 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:46 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:46 3: HMLAN1 device opened
2016.06.21 11:47:47 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:47 3: HMLAN1 device opened
2016.06.21 11:47:47 1: HMLAN_Parse: HMLAN1 new condition init
2016.06.21 11:47:47 3: HMLAN1 device opened
2016.06.21 11:47:48 1: HMLAN_Parse: HMLAN1 new condition init
Mein HMLAN trennt meistens zu einer vollen Stunde die Verbindung. Ich habe die diversen HourCounter im Verdacht, da diese immer zu einer vollen Stunde ein paar Berechnungen durchführen. Dann ist das System evtl. zu ausgelastet.
Zitat von: Bartimaus am 21 Juni 2016, 13:42:46
Mein HMLAN trennt meistens zu einer vollen Stunde die Verbindung. Ich habe die diversen HourCounter im Verdacht, da diese immer zu einer vollen Stunde ein paar Berechnungen durchführen. Dann ist das System evtl. zu ausgelastet.
Dann schau doch mal mit Perfmon ob du Delays feststellen kannst
Danke Damu für deine gefixte Datei, bis jetzt habe ich keinen Reboot mehr. Vorher mindestens 1x innerhalb von 24 Stunden.
Grüße Marcel
Zitat von: Damu am 19 Juni 2016, 12:32:55
Hallo
Hier meine 00_HMLAN.pm
Perfekt ist es noch nicht, aber eben viel besse als vorher.
Habe nun mal Vebose auf 5 gestellt und werde beobachten.
Vielleicht sollte man hier mal martinp876 als Modulbetreuer und HM-Kenner drüber schauen lassen, damit das dann per update kommt !?
ZitatVielleicht sollte man hier mal martinp876 als Modulbetreuer und HM-Kenner drüber schauen lassen, damit das dann per update kommt !?
Ich hab die Adapter über Powerline angeschlossen.
Das ist sicherlich nicht ideal.
Vielleicht als Option für Leute mit nicht Optimalen Netzwerken.
Zitat von: kvo1 am 24 Juni 2016, 12:02:22Vielleicht sollte man hier mal martinp876 als Modulbetreuer und HM-Kenner drüber schauen lassen, damit das dann per update kommt !?
... bin ich dafür 8)
Aber mit PowerLan o.ä. hat das vielleicht gar nichts zu tun? Denn ich habe das Ufo z.Z. an einem WLAN-Repeater (NetGear WN3000RPv3), an dem das Teil weit weniger Schluckauf hat als direkt im LAN, obwohl der Repeater u.a. auch AVR, TV und SmartPhones versorgt, wenn in Reichweite (vorher: RPi > 50cm Cat5e > FritzBox 7390 > 50cm Cat5e > NetGear 5port GS105 > 50cm Cat5e > UFO) ...
Hallo Damu
ZitatIch hab die Adapter über Powerline angeschlossen.
Das ist sicherlich nicht ideal.
Vielleicht als Option für Leute mit nicht Optimalen Netzwerken.
ups, ich auch, aber das sollte doch eigentlich nicht das Problem sein. Habe am gleichen Powerline noch einen RPI mit Optolink-Adapter (Status und Steuerung der Heizung) und der hat keine Aussetzer !
Auch ich habe einen HMLAN über Powerline angebunden. Dieser hat immer wieder mal Aussetzer (meist nur disconnects keine Reboots). Mein anderer HMLAN, der direkt an der Fritte hängt läuft sehr stabil (ganz, ganz selten mal ein Reboot).
Ich glaube daher auch, dass die Powerline-Anbindung für den HMLAN nicht gerade optimal ist, aber was will man machen? Klar, Kabel verlegen ... ist in Planung ;D
Habe die modifizerte 00_HMLAN.pm seit einigen Tagen im Einsatz. Läuft super bisher, vielen Dank an alle Beteiligten. :)
Grüße
Chris
Zitat von: Damu am 19 Juni 2016, 12:32:55
Hallo
Hier meine 00_HMLAN.pm
Perfekt ist es noch nicht, aber eben viel besse als vorher.
Habe nun mal Vebose auf 5 gestellt und werde beobachten.
Ich habe leider damit wieder kein Glück.
Hier ist der Effekt nur mit der 00_HMLAN.pm von Billy aus #179 verschwunden.
Gibt es noch eine Chance auf dauerhafte Implementierung des Patches in fhem???
Viele Grüße
Sorry, vergessen. Schau ich am Wochenende durch
hat schon jemand die neue Firmware (v0.965 vom 22.07.16) für den HMLan probiert?
Zitat von: aplatac am 05 August 2016, 09:17:04
hat schon jemand die neue Firmware (v0.965 vom 22.07.16) für den HMLan probiert?
Ja, aber die hat bei mir das Problem nicht behoben ... wir warten jetzt (seit Mai) auf die von eQ-3 angekündigte "ganz neue" Version
nachdem der hmlan ausgemustert wurde, erwarte ich kein update mehr.
mein hmlan hat gerade 510 std uptime, seitdem mein fhem umgezogen ist.
vorher ca 1-12 tage uptime mit fhem auf fritzbox und hmlan direkt an fritzbox.
nun fhem auf pi3 und über wlan mit fritzbox verbunden. auf der fritzbox läuft weiterhin das selbe fhem, allerdings mit einer demo-fhem.cfg plus minimalen änderungen. der hmlan ist weiterhin an der fritzbox.
das umgezogene fhem ist im selben subnetz. den hmlan patch habe ich nie benutzt.
ich vermute nun, dass mein fhem irgendwelchen netzwerktraffic erzeugt, der nun durch die wlan anbindung dem hmlan "verborgen" bleibt. eigentlich hatte ich erwartet, dass der hmlan durch die zusätzliche wlan anbindung mehr probleme macht.
alles wieder nur zufall?
Zitat von: frank am 05 August 2016, 12:30:30
nachdem der hmlan ausgemustert wurde, erwarte ich kein update mehr.
Wo hast du die Info denn her?
https://forum.fhem.de/index.php/topic,55501.0.html (https://forum.fhem.de/index.php/topic,55501.0.html)
Schau an. Danke.
Zitat von: frank am 05 August 2016, 12:30:30
nachdem der hmlan ausgemustert wurde, erwarte ich kein update mehr.
Die Nachricht, die ich von ELV erhalten hatte hieß: der Update kommt, aber es dauert etwas ... ich hake da jetzt noch einmal nach
Ich hatte bis vor kurzem massive Probleme mit disconnects/reconnects vom HMLAN, hat am Tag teilweise hunderte Zeilen in meine log geworfen. Habe dann per Zufall rausgefunden dass offenbar der logitech media server für die Probleme verantwortlich ist. Nachdem ich den aufgrund einer Änderung in meinem Netzwerk in ein anderes VLAN geschoben habe waren die Probleme plötzlich verschwunden. Heute habe ich den LMS wieder in das gleiche VLAN wie den HMLAN geworfen und die Probleme gingen wieder von vorne los.
Habe jetzt nicht weiter recherchiert, aber der LMS wird vermutlich eine Art Broadcast raushauen um die Radios wissen zu lassen dass er da ist. Vielleicht kommt der kleine HMLAN mit so einem "Sturm" nicht klar und steigt irgendwann aus.
Vielleicht ist ein ähnlicher Dienst (bspw. DLNA oder AirPlay) bei euch für die Probleme verantwortlich.
Grüße,
Markus
Zitat von: MarkusN am 09 August 2016, 11:38:41
vermutlich eine Art Broadcast raushauen
Multicast, nicht Broadcast. Das ist bekannt und tritt eigentlich auch nur auf, wenn ein (dummer) Switch das nicht filtern kann.
Zitat von: dev0 am 09 August 2016, 14:06:06
... und tritt eigentlich auch nur auf, wenn ein (dummer) Switch das nicht filtern kann.
weil dann der ganz dumme HMLAN damit gar nicht zurecht kommt und abschmiert :(
Wenn jetzt Dienste rund um Airplay / DLNA als potentielle Übeltäter in Frage kommen, müsste dieses Problem doch "jeden" treffen, oder bin ich hier auf dem Holzweg.
Nahezu jeder Drucker verwendet heutzutage Bonjour (als Implementierung von Airplay), ebenso Kodi / Openelec, um die Konfiguration zu vereinfachen. Auch so manches NAS preist doch seine Verfügbarkeit über diese Mechanismen im heimischen Netz an.
Interessanterweise war ich in den letzten anderthalb Wochen nicht daheim - Kodi somit aus, gedruckt wurde auch nicht, niemand hat (außer des FHEM-Rechners) das NAS angetriggert. Lediglich das NAS und der Drucker liefen durch - dennoch wimmelt es im Log nur so von disconnects, aber eben unregelmäßig - mal 20 Minuten Ruhe, dann nach zwei Minuten Hektik, dann mal drei Stunden Ruhe. Unabhängig von Tag- oder Nachtzeit - über einen Zeitraum von 10 Tagen immerhin 514 disconnects.
Im Zeitraum von 7 Tagen vor dem Urlaub waren es 134 disconnects. Rein statistisch traten in der Zeit, während Kodi häufiger lief, gedruckt wurde usw. (und vermutlicherweise auch mehr Bonjour / Airplay-Requests durchs Netz gejagt wurden) weniger disconnects auf als in meiner Abwesenheit.
Daher die Frage: Sind "wir" mit den Multicasts als Übeltäter auf dem richtigen Weg?
Helfe sehr gerne mit bei der Suche / Anamnese, wenn mich jemand mit in die richtige Richtung schiebt ;-)
Gruß,
Tom
Problematisch waren bei mir nur die Telekom Entertain (IPTV) Multicasts, welche meinen HMLAN oftmals aus dem Takt brachten. Airplay, Bonjour, DLNA usw. machen hier keine Probleme. Einen hohen Netzwerktraffic kannst du auch an einem beliebigen Netzwerkswitch sehen. Seinerzeit hat Entertain alle "Lämpchen" am Switch in rage gebracht :D, wobei Airplay/Bonjour/DLNA usw. keine aussergewöhnlich hohe Netzwerklast am Switch erzeugte.
Zudem hat die modifizerte HMLAN.pm (hier im Thread gepostet) meine ab und an dennoch vorkommenden HMLAN disconnects nahzu ausgemerzt. Über mehrere Wochen habe ich nun maximal 1-2 disconnects die Woche, wenn überhaupt.
Dieser HMLAN-Fix sollte in die offzielle Version eingebaut werden, bin mir sicher das so viele disconnects vermieden werden.
Grüße
Chris
Mein Switch als solcher hat schon gut zu tun - aber Netzwerküberlastung bei meinem 1GB Netzwerk habe ich noch nicht festgestellt. Die Übertragungsraten zu meinem NAS entsprechen idR den 100MB/s - viel mehr ist wohl via Samba auf 1GB-Ethernet auch nicht zu holen.
Gerade habe ich mal probeweise 100GB kopiert, um den Switch mal ein wenig anzuwärmen - dabei traten aber keinerlei HMLAN-spezifischen Probleme auf.
Bisher habe ich mit dem Einspielen des Patches gewartet - wollte hier auf das "offizielle" GO warten - werde es aber gleich mal in Betracht ziehen und mir die Datei einspielen.
Also die Antwort auf sich selbst ;-)
Nachdem ich den ganzen Thread noch mehrfach durchgearbeitet habe (eigentlich mit der Absicht, den mehrfach erwähnten Patch einzuspielen), bin ich den Anmerkungen von
Martin nochmal explizit nachgegangen.
Was waren die Hinweise:
- apptime auf Unregelmäßigkeiten untersuchen, speziell apptime maxDly all.
Ergebnis: Viele Einträge mit hohen maxDelays - perfmon hinzuziehen.
Ergebnis: Bei jeder Aktualisierung meiner MAX!--Komponenten kam es zu langen Aussetzern, ebenso beim periodischen Prüfen der XBMC-Devices. Auch die Fritzboxen (3 an der Zahl) verursachten immer wieder mal entsprechende Einträge im Logfile. In Summe hatte ich je Minute rund 3 Einträge durch perfmon... nicht schön
2016.08.19 14:29:58 1: Perfmon: possible freeze starting at 14:29:56, delay is 2.465
2016.08.19 14:30:34 1: Perfmon: possible freeze starting at 14:30:32, delay is 2.849
2016.08.19 14:31:02 1: Perfmon: possible freeze starting at 14:30:56, delay is 6.005
2016.08.19 14:31:38 1: Perfmon: possible freeze starting at 14:31:35, delay is 3.341
2016.08.19 14:32:06 1: Perfmon: possible freeze starting at 14:32:00, delay is 6.005
2016.08.19 14:32:41 1: Perfmon: possible freeze starting at 14:32:38, delay is 3.005
2016.08.19 14:33:10 1: Perfmon: possible freeze starting at 14:33:04, delay is 6.005
2016.08.19 14:33:44 1: Perfmon: possible freeze starting at 14:33:42, delay is 2.527
2016.08.19 14:34:14 1: Perfmon: possible freeze starting at 14:34:08, delay is 6.005
2016.08.19 14:34:48 1: Perfmon: possible freeze starting at 14:34:45, delay is 3.074
2016.08.19 14:35:14 1: Perfmon: possible freeze starting at 14:35:12, delay is 2.041
2016.08.19 14:35:18 1: Perfmon: possible freeze starting at 14:35:15, delay is 3.005
2016.08.19 14:35:50 1: Perfmon: possible freeze starting at 14:35:48, delay is 2.602
2016.08.19 14:36:18 1: Perfmon: possible freeze starting at 14:36:15, delay is 3.005
2016.08.19 14:36:21 1: Perfmon: possible freeze starting at 14:36:19, delay is 2.013
2016.08.19 14:36:54 1: Perfmon: possible freeze starting at 14:36:51, delay is 3.005
2016.08.19 14:37:22 1: Perfmon: possible freeze starting at 14:37:19, delay is 3.005
2016.08.19 14:37:25 1: Perfmon: possible freeze starting at 14:37:23, delay is 2.026
2016.08.19 14:37:58 1: Perfmon: possible freeze starting at 14:37:55, delay is 3.293
2016.08.19 14:38:11 1: Perfmon: possible freeze starting at 14:38:10, delay is 1.237
2016.08.19 14:38:26 1: Perfmon: possible freeze starting at 14:38:23, delay is 3.005
- Netzwerkkonstellation rund um den HM-CFG-LAN prüfen.
Ergebnis HM-CFG-LAN hing hinter einem (kaskadierten) Switch eines WLAN-Hotspots, der den Port mit 1GB ansteuerte
Also alles der Reihe nach angegangen:
- Sämtliche XBMC-Installationen auf "fork" umgestellt. attr <device> fork enable.
Effekt: Deutliche Reduktion der maxDly-Einträge in apptime, ebenso deutlich weniger Logeinträge durch perfmon - Umstellung der Plots auf plotfork via attr WEB plotfork 1
Effekt: Da zusammen mit der ersten Maßnahme umgestellt, mache ich beides für die Reduktion der Logeinträge durch perfmon verantwortlich - im Positiven.
2016.08.19 15:07:06 1: Perfmon: possible freeze starting at 15:07:05, delay is 1.024
2016.08.19 16:19:23 1: Perfmon: possible freeze starting at 16:19:22, delay is 1.024
2016.08.19 16:24:37 1: Perfmon: possible freeze starting at 16:24:29, delay is 8.213
2016.08.19 16:38:41 1: Perfmon: possible freeze starting at 16:38:40, delay is 1.595
2016.08.19 16:55:26 1: Perfmon: possible freeze starting at 16:55:25, delay is 1.723
2016.08.19 16:57:35 1: Perfmon: possible freeze starting at 16:57:34, delay is 1.294
2016.08.19 16:58:29 1: Perfmon: possible freeze starting at 16:58:28, delay is 1.615
2016.08.19 16:58:48 1: Perfmon: possible freeze starting at 16:58:39, delay is 9.155
2016.08.19 16:58:51 1: Perfmon: possible freeze starting at 16:58:49, delay is 2.359
2016.08.19 17:43:56 1: Perfmon: possible freeze starting at 17:43:55, delay is 1.11- Update-Häufigkeit der "komplexeren" Devices reduziert, zB die Fritzboxen.
Effekt: Ab jetzt keine Einträge mehr durch perfmon im Logfile - HM-CFG-LAN direkt an meinen Switch gehängt und den Port auf 10MBit/s runtergeregelt.
Effekt: Seit der Umstellung kein einziges disconnect/reconnect mehr. Reboots hatte ich ohnehin nicht. Hält jetzt seit 14:00 des Vortags... also gute 20h
Desweiteren habe ich einfach in allen angelegten Devices nachgeschaut, ob man die Update-Zyklen hochsetzen kann - und dies bei einigen durchgeführt. In summe fluppt das System - bei einem Intel NUC hatte ich aber auch keine Probleme wg. der HW erwartet. Meine MAX!-Probleme (anderer Thread) haben sich auch erstmal "reduziert" - noch nicht ganz weg, aber deutlich besser.
Nochmal zur Info:
HM-CFG-LAN Firmware: 0.965
Original HMLAN-Modul (keinen Patch aus dem Thread)
Vielleicht hilft es ja jemandem. In jedem Fall Danke @Martin, der mit seinen (wiederholten) Hinweisen bzgl. Netzwerkkonfiguration und Analyse via Bordmittel (perfmon / apptime) in meinem Fall den Nagel auf den Kopf getroffen hat.
Gruß,
Tom
Hallo die Runde der Geplagten
ich will ja die Verwirrung nicht weiter steigern, nur eine Beobachtung mitteilen.
Seit 17.08. habe ich keine HMLAN disconnects mehr, davor waren es meist so zwischen 5 und 10 am Tag.
Was habe ich am 17.08. gemacht? Blöderweise zwei Dinge:
1. Update FHEM
2. Firmware Update Fritz!Wlan Repeater 1750E
Na mal sehen, ob es hält.
Update
Zu früh gefreut. da war er wieder, der erste disconnect. :-\
Gruß
G.
ZitatZu früh gefreut. da war er wieder, der erste disconnect.
trigger damit ein notify und lass licht einschalten als anwesenheits-simulation. :)
Zitat von: frank am 20 August 2016, 19:50:12
trigger damit ein notify und lass licht einschalten als anwesenheits-simulation. :)
Das war jetzt aber nicht hilfreich. Bei uns ist immer einer da.
hallo zusammen,
ich hatte heute früh zum 2. mal das problem, dass der hmlan disconnected war und auch nach 1std noch nicht wieder funktionierte. normalerweise ist der ausfall ja nur wenige sekunde , aber diesmal nicht. selbst kurz vom strom trennen funktionierte nicht, erst als ich ihn mehrere minuten vom stom getrennt hatte ging er wieder.
ich hatte gestern ein fhem update gemacht und das modul dlnatenderer konfiguriert, keine ahnung ob es damit zu tun hatte.
sollte es nicht ein firmware update vom eq3 geben? wie ist denn da der stand?
ansonsten überlege ich schon auf das raspberry aufsteckmodul umzusteigen...
Dazu noch meine 2 Cent:
Ich habe bei meinem Switch die Möglichkeit der Port-Isolation und blockiere damit für die Ports, an denen ein HM-CFG-LAN angeschlossen ist, den kompletten Traffic von allen Ports außer für den Cubietruck auf dem FHEM läuft. Hat etwa die gleiche Qualität wie ein VLAN. Damit sind die Disconnects deutlich zurückgegangen. Übrig bleibt im Schnitt ein Disconnect je HM-CFG-LAN pro Woche. Nachdem ich den Keep-Alive Patch eingespielt habe, sind die verbleibenden Disconnects weg.
Ich denke diese Änderung sollte Martin in das Modul aufnehmen.
Ich befürchte inzwischen, dass der von eQ-3 aufgrund meiner Logs gefundene Fehler zwar laut Aussage behoben ist, diese neue Version aber doch nicht mehr ausgeliefert wird :(
Auf meine diesbezügliche Anfrage kam nur auf Deutsch gesagt nur Bla-Bla zurück :(
fürchte ich auch. ich habe bei eq3 auch nachgefragt und am telefon meinte er, er kennt das problem nicht und ich soll auf ccu2 umstellen oder nochmal per email den eq3 support fragen. letzteres habe ich dann gemacht mit der aussage, der hmlan sei defekt und ich soll mich an den händler wenden.
was für ein support... :(
Zitat von: Nobby1805 am 28 August 2016, 12:00:42
Ich befürchte inzwischen, dass der von eQ-3 aufgrund meiner Logs gefundene Fehler zwar laut Aussage behoben ist, diese neue Version aber doch nicht mehr ausgeliefert wird :(
Auf meine diesbezügliche Anfrage kam nur auf Deutsch gesagt nur Bla-Bla zurück :(
schade, passt aber irgendwie zum bisherigen fw-handling.
hast du mal nach dem sourcecode gefragt, um es selbst zu beheben? ;)
...hab jetzt erstmal meinen HMLAN1 hinter einer Intertechno Funk-Steckdose, die ich mit fhem aus- und einschalte, wenn der HMLAN1 länger als 10min disconnected ist. Sicher ist sicher...
Zusätzlich versuche ich auch mal mein Glück mit einem getrenntem VLAN auf meinem Openwrt-Router...
Zitat...hab jetzt erstmal meinen HMLAN1 hinter einer Intertechno Funk-Steckdose,
mutig. nach spannungsausfall (zb gewitter) ist das teil immer off.
ja, das problem versuche ich gerade zu lösen. bei stromausfall sollte auch der rpi mit fhem neu starten und ich hab ein notify auf global:Initialized, der die it steckdose wieder anschaltet...
wenn jemand eine bessere idee zum reset eines hängenden hmlan1 hat, immer her damit..,
Zitatbei stromausfall sollte auch der rpi mit fhem neu starten
das kommt wohl auf verschiedenste bedingungen an, wie ich erfahren musste.
zunächst sollten rpi und die hmlan-dose mindestens an der selben phase, besser an der selben steckdose hängen.
dann gibt es noch kurzzeitige spannungsschwankungen, die von den geräte unterschiedlich behandelt werden. manche sind aus, manche bleiben an.
sicher sein kannst du eigentlich nur mit einer dose, die bei spannungswiederkehr automatisch immer an geht.
neuere homeaticaktoren können das meistens. finde ich für mich allerdings unnötig teuer, weil für das geld bekommt man auch schon wieder ein weiteres io.
ok, aber selbst wenn der der rpi anbleibt und nur die it steckdose ausgeht, ich habe einen watchdog auf den hmlan1 und wenn der >10min disconnected ist macht er ein off-for-timer 300 der it steckdose. habs noch nicht getestet, aber ich denke sie müsste wenn sie aus war nach ablauf von off-for-timer wieder angehen...
Zitat von: FhemPiUser am 29 August 2016, 11:01:23
ok, aber selbst wenn der der rpi anbleibt und nur die it steckdose ausgeht, ich habe einen watchdog auf den hmlan1 und wenn der >10min disconnected ist macht er ein off-for-timer 300 der it steckdose. habs noch nicht getestet, aber ich denke sie müsste wenn sie aus war nach ablauf von off-for-timer wieder angehen...
die theorie hört sich jedenfalls gut an.
hast du dies schon mal probiert => HMLAN_SimpleWrite($defs{'hmlan1'}, "Y05")?
https://forum.fhem.de/index.php/topic,38708.0.html (https://forum.fhem.de/index.php/topic,38708.0.html)
danke, ich fürchte aber das reicht bei mit nicht. beim letzten hänger habe ich den hmlan für 3s vom strom getrennt und er hing noch immer. erst nach längerer trennung vom strom ging er wieder. daher die fubksteckdose und das off-for-timer 300...
ist aber innerhalb von 2 jahren auch erst 2x vorgekommen, normalerweise hängt er nur 1min und kommt von alleine zurück...
Hallo,
im Anhang der Patch gegen die aktuelle 00_HMLAN.pm (sowie die gepatchte Datei).
@Martin: Kannst Du Dir den Patch bitte bei Gelegenheit mal anschauen und evtl. uebernehmen? Danke :-)
Viele Gruesse
Michael
Moin,
mein HMLAN hatte in letzter Zeit locker 5-10 reconnects pro Tag.
Und zwar immer zur vollen Stunde.
Zur vollen Stunde werden meine HourCounter aktiv (bestimmt 8 Stck), sowie sehr viele DOIF's mit DOELSE die Zeiträume von [08:00-20:00] etc. hatten. Diese habe ich jetzt alle auf volle Stunde + 1min umgestellt. Also [08:01-20:01].
Jetzt liegen die Reconnects des HMLAN bei ca. 1-2/Tag.
Just my 2cents
Hallo,
ich stehe vor der Entscheidung ob ich meinen Kabel TV Anschluss verlängere oder auf Telekom Entertain gehe.
Jetzt habe ich in diesem Beitrag von größeren Problemen gelesen mit der Netzlast.
Ich habe eine Raspi3 mit FHEM und einem ZWAVE Dongle , sowie einem Funksender (433 Mhz) am GPIO.
Sind die Probleme mit Entertain nur bei dem HMLAN oder bekomme ich da auch Schwierigkeiten mit meinem Setup ?
::) ::) ::)
Viele Grüße
Joachim
kauf dir ein Switch, welches damit umgehen kann. Hab mir das TL-SG2008 gekauft und funktioniert alles super trotz Entertain etc. seit dem keine Probleme mehr gehabt.
Nachdem ich jetzt seit Juni nur 2 disconnects hatte, macht mir jetzt die "tiefstehende Mittagssonne" wieder Probleme ... ein HM-SEC-SCo sendet in der Mittagszeit in einem kurzen Zeitraum zig Telegramme an den HMLAN und dieser verschluckt sich regelmäßig daran und bootet durch >:(
Leider habe ich inzwischen die Hoffnung aufgegeben, dass die (angeblich) fertige neue Firmware mit dem Bugfix noch ausgeliefert wird :(
Ich bin erfolgreich auf den hm-lgw-o-tw-w-eu-2 umgestiegen, seit dem habe ich ruhe.
Meine hmlans werde ich bald hier oder bei eBay Kleinanzeigen verkaufen, mit denen hatte ich leider ja auch so meine Probleme, bzw. haben die hmlans ein Problem.
Kann echt nur jedem raten umzustellen auf hm-lgw-o-tw-w-eu-2, auch wenn das wieder mit kosten verbunden ist.
Gibt ja auch noch die günstigere Variante für den pi.
Grüße Marcel
Gesendet von iPhone mit Tapatalk
... hu ??
Ich dachte resp. meine letzten Informationen lauteten, das der HM-LGW-O-TW-W-EU-2 mit FHEM nicht wirklich läuft?!?
Ich kann jetzt nicht genau sagen, was das/die Problem/e waren/sind, aber irgend was Entscheidendes war da ...
Schau mal hier : http://www.fhemwiki.de/wiki/HM-LGW-O-TW-W-EU_Funk-LAN_Gateway
Und hier : https://forum.fhem.de/index.php?topic=54511.0
Gesendet von iPhone mit Tapatalk
Hi, seit einigen Tage, ist mein Fhem wieso auch immer wieder sehr träge und auch im Log tauchen wieder vermehrt disconnects auf.
apptime max sagt dazu:
name function max count total average maxDly
HmLanAdapter HMLAN_Read 30097 74 580787 7848.47 0 HASH(HmLanAdapter)
rd_Batterie readingsGroup_Notify 6569 1743 304970 174.97 0 HASH(rd_Batterie); HASH(Bewegungsmelder)
rd_Batterie2 readingsGroup_Notify 6502 1743 277033 158.94 0 HASH(rd_Batterie2); HASH(Kinderzimmer_Laya)
inTemp FileLog_Log 6442 1743 563986 323.57 0 HASH(inTemp); HASH(rd_Batterie2)
tmr-HttpUtils_Err HASH(0x4a73ba0) 3182 1 3182 3182.00 224 HASH(0x4a73ba0)
FireTV_Kodi XBMC_Ready 3007 1103 48234 43.73 0 HASH(FireTV_Kodi)
tmr-HttpUtils_Err HASH(0x4a02cb8) 2630 1 2630 2630.00 27207 HASH(0x4a02cb8)
tmr-HttpUtils_Err HASH(0x49df9f8) 2587 1 2587 2587.00 29835 HASH(0x49df9f8)
rg_VU_Ultimo readingsGroup_Notify 1676 1743 6317 3.62 0 HASH(rg_VU_Ultimo); HASH(VU_Ultimo)
rg_Uno_Schlafzimmer readingsGroup_Notify 1484 1743 3135 1.80 0 HASH(rg_Uno_Schlafzimmer); HASH(Uno_Schlafzimmer)
FBSmartHome FBAHA_Read 996 12 6572 547.67 0 HASH(FBSmartHome)
TV_Programm readingsGroup_Notify 977 1743 4998 2.87 0 HASH(TV_Programm); HASH(TV_Programme)
tmr-at_Exec HASH(0x2008c18) 474 106 13048 123.09 32975 HASH(at_fp_time)
VU_UltimoRG readingsGroup_Notify 454 1743 2161 1.24 0 HASH(VU_UltimoRG); HASH(VU_Ultimo)
WEB FW_Read 450 47 12441 264.70 0 HASH(WEB)
tmr-at_Exec HASH(0x3bb92e0) 363 1 363 363.00 4 HASH(Steckdose_Flur_Oben_Stehlampe_an)
Steckdose_Flur_Oben IT_Set 359 3 360 120.00 0 HASH(Steckdose_Flur_Oben); Steckdose_Flur_Oben; on
Batterie_Status_nt notify_Exec 351 1743 5111 2.93 0 HASH(Batterie_Status_nt); HASH(rd_Batterie)
myDbLog DbLog_Log 329 1743 18355 10.53 0 HASH(myDbLog); HASH(VU_Ultimo)
rg_Uno_Schlafzimmer_1 readingsGroup_Notify 302 1743 1530 0.88 0 HASH(rg_Uno_Schlafzimmer_1); HASH(Uno_Schlafzimmer)
Cul433 CUL_Get 290 1 290 290.00 0 HASH(Cul433); ; raw; is0000FF000FFF
Sieht da schon einer etwas auffälliges?
Perform lass ich aktuell im Hintergrund laufen, mal sehen was da aufschlägt
So, hier mal ein paar perform Meldungen, wenn ich mit verbose 3 Log, gibt es jede menge perform Meldungen, auf verbose 5 ist der Log sehr schnell sehr groß, obwohl ich nur nachts geloggt habe, wo eigentlich nichts groß laufen sollte
2016.11.26 00:00:47.011 1: Perfmon: possible freeze starting at 00:00:44, delay is 3.01
2016.11.26 00:00:47.016 5: SYSMON sysmon: updateReadings.1056
2016.11.26 00:00:47.023 5: Triggering sysmon (1 changes)
2016.11.26 00:00:47.024 5: Starting notify loop for sysmon, first event cpu_freq: 480
2016.11.26 00:00:47.036 5: ABFALL_Notify(myAbfall) - Device: sysmon
2016.11.26 00:00:47.036 5: Notify from Device: sysmon recieved
2016.11.26 00:00:47.038 5: DbLog: logging of Device: sysmon , Type: SYSMON , Event: cpu_freq: 480 , Reading: cpu_freq , Value: 480 , Unit:
2016.11.26 00:00:47.043 5: rd_Batterie: not on any display, ignoring notify
2016.11.26 00:00:47.044 5: rd_Batterie2: not on any display, ignoring notify
2016.11.26 00:00:47.045 5: rd_SysInfo: not on any display, ignoring notify
2016.11.26 00:00:47.064 4: BlockingCall (SYSMON_blockingCall): created child (15844), uses telnetPort to connect back
2016.11.26 00:00:47.078 5: HMLAN_Send: HmLanAdapter I:K
2016.11.26 00:00:47.083 5: exec at command at_fp_time
2016.11.26 00:00:47.085 5: Cmd: >{ fhem 'set fp_time '.strftime('%H:%M Uhr', localtime) }<
2016.11.26 00:00:47.089 5: Cmd: >set fp_time 00:00 Uhr<
2016.11.26 00:00:47.092 4: dummy set fp_time 00:00 Uhr
2016.11.26 00:00:47.095 5: Triggering fp_time (1 changes)
2016.11.26 00:00:47.096 5: Starting notify loop for fp_time, first event 00:00 Uhr
2016.11.26 00:00:47.101 5: SYSMON sysmon: blockingCall.950 sysmon,
2016.11.26 00:00:47.103 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /proc/uptime'
2016.11.26 00:00:47.116 5: ABFALL_Notify(myAbfall) - Device: fp_time
2016.11.26 00:00:47.117 5: Notify from Device: fp_time recieved
2016.11.26 00:00:47.121 5: DbLog: logging of Device: fp_time , Type: DUMMY , Event: 00:00 Uhr , Reading: state , Value: 00:00 Uhr , Unit:
2016.11.26 00:00:47.132 5: rd_Batterie: not on any display, ignoring notify
2016.11.26 00:00:47.133 5: rd_Batterie2: not on any display, ignoring notify
2016.11.26 00:00:47.135 5: rd_Datum: not on any display, ignoring notify
2016.11.26 00:00:47.139 5: redefine at command at_fp_time as +*00:00:10 { fhem 'set fp_time '.strftime('%H:%M Uhr', localtime) }
2016.11.26 00:00:47.143 5: Triggering at_fp_time (1 changes)
2016.11.26 00:00:47.144 5: Starting notify loop for at_fp_time, first event Next: 00:00:55
2016.11.26 00:00:47.143 5: SYSMON sysmon: Exec_Local.4106 Result '152519.94 271314.29'
2016.11.26 00:00:47.147 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /sys/class/hwmon/hwmon0/device/temp1_input 2>&1'
2016.11.26 00:00:47.154 5: ABFALL_Notify(myAbfall) - Device: at_fp_time
2016.11.26 00:00:47.155 5: Notify from Device: at_fp_time recieved
2016.11.26 00:00:47.157 5: DbLog: logging of Device: at_fp_time , Type: AT , Event: Next: 00:00:55 , Reading: Next , Value: 00:00:55 , Unit:
2016.11.26 00:00:47.164 5: rd_Batterie: not on any display, ignoring notify
2016.11.26 00:00:47.165 5: rd_Batterie2: not on any display, ignoring notify
2016.11.26 00:00:47.173 4: Connection accepted from AMADCommBridge_192.168.188.23_41388
2016.11.26 00:00:47.174 5: HMLAN/RAW: /HHM-LAN-IF,03C1,KEQ0852050,23A503,000041,5385CB90,0010
2016.11.26 00:01:50.105 1: Perfmon: possible freeze starting at 00:01:48, delay is 2.105
2016.11.26 00:01:50.110 5: HMLAN/RAW: /HHM-LAN-IF,03C1,KEQ0852050,23A503,000041,5386C1C8,0010
2016.11.26 00:01:50.112 5: HMLAN_Parse: HmLanAdapter V:03C1 sNo:KEQ0852050 d:23A503 O:000041 t:5386C1C8 IDcnt:0010 L:0 %
2016.11.26 00:01:50.115 5: Triggering HmLanAdapter (1 changes)
2016.11.26 00:01:50.116 5: Starting notify loop for HmLanAdapter, first event loadLvl: low
2016.11.26 00:01:50.125 5: SYSMON sysmon: blockingCall.950 sysmon,
2016.11.26 00:01:50.128 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /proc/uptime'
2016.11.26 00:01:50.136 5: ABFALL_Notify(myAbfall) - Device: HmLanAdapter
2016.11.26 00:01:50.137 5: Notify from Device: HmLanAdapter recieved
2016.11.26 00:01:50.141 5: DbLog: logging of Device: HmLanAdapter , Type: HMLAN , Event: loadLvl: low , Reading: loadLvl , Value: low , Unit:
2016.11.26 00:01:50.143 5: FRITZBOX FritzBox7490: Shell_Exec_Telnet.3930 Result '0'
2016.11.26 00:01:50.144 5: FRITZBOX FritzBox7490: Shell_Exec_Telnet.3922 Execute 'ctlmgr_ctl r tam settings/TAM0/NumOldMessages'
2016.11.26 00:01:50.152 5: rd_Batterie: not on any display, ignoring notify
2016.11.26 00:01:50.153 5: rd_Batterie2: not on any display, ignoring notify
2016.11.26 00:01:50.179 5: SYSMON sysmon: Exec_Local.4106 Result '152582.97 271432.59'
2016.11.26 00:01:50.182 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /sys/class/hwmon/hwmon0/device/temp1_input 2>&1'
2016.11.26 00:01:50.193 5: FRITZBOX FritzBox7490: Shell_Exec_Telnet.3930 Result '1'
2016.11.26 00:01:50.194 5: FRITZBOX FritzBox7490: Shell_Exec_Telnet.3922 Execute 'ctlmgr_ctl r user settings/user0/name'
2016.11.26 00:01:50.217 5: SYSMON sysmon: Exec_Local.4106 Result '34600'
2016.11.26 00:01:50.220 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /proc/loadavg'
2016.11.26 00:01:50.246 5: FRITZBOX FritzBox7490: Shell_Exec_Telnet.3930 Result '(guest)'
2016.11.26 00:01:50.247 5: FRITZBOX FritzBox7490: Shell_Exec_Telnet.3922 Execute 'ctlmgr_ctl r user settings/user0/this_month_time'
2016.11.26 00:01:50.256 5: SYSMON sysmon: Exec_Local.4106 Result '0.08 0.08 0.12 1/100 16097'
2016.11.26 00:01:50.258 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /proc/stat'
2016.11.26 00:01:50.296 5: SYSMON sysmon: Exec_Local.4098 Result '$VAR1 = 'cpu 2756609 2436 794471 26505921 36147 294 350088 0 0 0
2016.11.26 00:08:08.347 1: Perfmon: possible freeze starting at 00:08:06, delay is 2.347
2016.11.26 00:08:08.371 4: BlockingCall (WOL_Ping): created child (17487), uses telnetPort to connect back
2016.11.26 00:08:08.377 5: SYSMON sysmon: Exec_Local.4106 Result '0.10 0.08 0.12 3/99 17487'
2016.11.26 00:08:08.378 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /proc/stat'
2016.11.26 00:08:08.389 5: HMLAN/RAW: /HHM-LAN-IF,03C1,KEQ0852050,23A503,000041,538C871E,0010
2016.11.26 00:08:08.398 5: HMLAN_Parse: HmLanAdapter V:03C1 sNo:KEQ0852050 d:23A503 O:000041 t:538C871E IDcnt:0010 L:0 %
2016.11.26 00:08:08.405 5: Triggering HmLanAdapter (1 changes)
2016.11.26 00:08:08.407 5: Starting notify loop for HmLanAdapter, first event loadLvl: low
2016.11.26 00:08:08.420 5: SYSMON sysmon: Exec_Local.4098 Result '$VAR1 = 'cpu 2758495 2436 795962 26577048 36156 295 350917 0 0 0
2016.11.26 00:11:17.291 1: Perfmon: possible freeze starting at 00:11:15, delay is 2.29
2016.11.26 00:11:17.293 5: exec at command at_fp_time
2016.11.26 00:11:17.295 5: Cmd: >{ fhem 'set fp_time '.strftime('%H:%M Uhr', localtime) }<
2016.11.26 00:11:17.300 5: Cmd: >set fp_time 00:11 Uhr<
2016.11.26 00:11:17.303 4: dummy set fp_time 00:11 Uhr
2016.11.26 00:11:17.305 5: SYSMON sysmon: blockingCall.950 sysmon,
2016.11.26 00:11:17.307 5: Triggering fp_time (1 changes)
2016.11.26 00:11:17.308 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /proc/uptime'
2016.11.26 00:11:17.308 5: Starting notify loop for fp_time, first event 00:11 Uhr
2016.11.26 00:11:17.330 5: ABFALL_Notify(myAbfall) - Device: fp_time
2016.11.26 00:11:17.332 5: Notify from Device: fp_time recieved
2016.11.26 00:11:17.336 5: DbLog: logging of Device: fp_time , Type: DUMMY , Event: 00:11 Uhr , Reading: state , Value: 00:11 Uhr , Unit:
2016.11.26 00:11:17.344 5: SYSMON sysmon: Exec_Local.4106 Result '153150.14 272526.67'
2016.11.26 00:11:17.348 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /sys/class/hwmon/hwmon0/device/temp1_input 2>&1'
2016.11.26 00:11:17.353 5: rd_Batterie: not on any display, ignoring notify
2016.11.26 00:11:17.354 5: rd_Batterie2: not on any display, ignoring notify
2016.11.26 00:11:17.355 5: rd_Datum: not on any display, ignoring notify
2016.11.26 00:11:17.360 5: redefine at command at_fp_time as +*00:00:10 { fhem 'set fp_time '.strftime('%H:%M Uhr', localtime) }
2016.11.26 00:11:17.365 5: Triggering at_fp_time (1 changes)
2016.11.26 00:11:17.366 5: Starting notify loop for at_fp_time, first event Next: 00:11:25
2016.11.26 00:11:17.378 5: ABFALL_Notify(myAbfall) - Device: at_fp_time
2016.11.26 00:11:17.379 5: Notify from Device: at_fp_time recieved
2016.11.26 00:11:17.381 5: DbLog: logging of Device: at_fp_time , Type: AT , Event: Next: 00:11:25 , Reading: Next , Value: 00:11:25 , Unit:
2016.11.26 00:11:17.384 5: SYSMON sysmon: Exec_Local.4106 Result '34600'
2016.11.26 00:11:17.387 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /proc/loadavg'
2016.11.26 00:11:17.389 5: rd_Batterie: not on any display, ignoring notify
2016.11.26 00:11:17.390 5: rd_Batterie2: not on any display, ignoring notify
2016.11.26 00:11:17.406 4: Connection accepted from AMADCommBridge_192.168.188.23_54413
2016.11.26 00:11:17.408 5: HMLAN/RAW: /HHM-LAN-IF,03C1,KEQ0852050,23A503,000041,538F69B5,0010
2016.11.26 02:32:01.364 1: Perfmon: possible freeze starting at 02:31:59, delay is 2.363
2016.11.26 02:32:01.368 5: HMLAN/RAW: /HHM-LAN-IF,03C1,KEQ0852050,23A503,000041,54104741,0010
2016.11.26 02:32:01.377 5: HMLAN_Parse: HmLanAdapter V:03C1 sNo:KEQ0852050 d:23A503 O:000041 t:54104741 IDcnt:0010 L:0 %
2016.11.26 02:32:01.380 5: Triggering HmLanAdapter (1 changes)
2016.11.26 02:32:01.381 5: Starting notify loop for HmLanAdapter, first event loadLvl: low
2016.11.26 02:32:01.397 5: SYSMON sysmon: blockingCall.950 sysmon,
2016.11.26 02:32:01.401 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /proc/uptime'
2016.11.26 02:32:01.433 5: ABFALL_Notify(myAbfall) - Device: HmLanAdapter
2016.11.26 02:32:01.435 5: Notify from Device: HmLanAdapter recieved
2016.11.26 02:32:01.452 5: DbLog: logging of Device: HmLanAdapter , Type: HMLAN , Event: loadLvl: low , Reading: loadLvl , Value: low , Unit:
2016.11.26 02:32:01.476 5: rd_Batterie: not on any display, ignoring notify
2016.11.26 02:32:01.477 5: rd_Batterie2: not on any display, ignoring notify
2016.11.26 02:32:01.498 5: SYSMON sysmon: Exec_Local.4106 Result '161594.32 288789.12'
2016.11.26 02:32:01.502 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /sys/class/hwmon/hwmon0/device/temp1_input 2>&1'
2016.11.26 02:32:01.560 5: SYSMON sysmon: Exec_Local.4106 Result '34600'
2016.11.26 02:32:01.564 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /proc/loadavg'
2016.11.26 02:32:01.603 5: SYSMON sysmon: Exec_Local.4106 Result '0.08 0.05 0.07 2/105 16274'
2016.11.26 02:32:01.604 5: SYSMON sysmon: Exec_Local.4093 Execute 'cat /proc/stat'
2016.11.26 02:32:01.648 5: SYSMON sysmon: Exec_Local.4098 Result '$VAR1 = 'cpu 2802074 2436 830168 28200740 36647 313 369883 0 0 0
Für mich ist auffällig das sysmon immer wieder auftritt!?
Hallo allerseits,
leider bin auch ich seit einiger Zeit vom "HMLAN disconnected/connected" - Problem betroffen.
Aus verschiedenen Threads konnte ich folgende potentielle Fehlerursachen finden:
(1) Blockierende Threads mit einer Dauer > 10 Sekunden
(2) Multicast Messages
(3) Elkos im HMLAN, deren Kapazität sich wesentlich geändert hat
Da ich zwei HMLANs besitze und nur einer das Verhalten zeigt, habe ich beide getauscht. Nun trat das Problem beim vorher fehlerfrei arbeitenden HMLAN auf und der andere arbeite tadellos.
Damit möchte ich Problem (3) ausschließen.
Problem (1) versuche ich gerade mit AppTime auf die Spur zu kommen. Es trat glücklicherweise auch kurz nach dessen Start auf. Allerdings kann ich in der Zusamenfassung unten keine Probleme erkennen.
Könnte das bitte jemand bestätigen, der sich damit gut auskennt?
------------------------------------------------------------------------------------------------------------------------------------------------------------
name function max count total average maxDly
------------------------------------------------------------------------------------------------------------------------------------------------------------
HMLAN1 HMLAN_Read 389 270 3573 13.23 0 HASH(HMLAN1)
FileLog_iStatus FileLog_Log 373 101 442 4.38 0 HASH(FileLog_iStatus); HASH(iStatus)
tmr-CUL_HM_procQs CUL_HM_procQs 254 4 362 90.50 23 CUL_HM_procQs
tmr-at_Exec HASH(0x12d3150) 169 1 169 169.00 7 HASH(at.tmp.Warn_open_egTSensor_3)
tmr-at_Exec HASH(0x3b6d048) 161 1 161 161.00 4 HASH(at.tmp.Warn_open_egTSensor_5)
tmr-at_Exec HASH(0x335f0d8) 116 1 116 116.00 5 HASH(at.tmp.Warn_open_egTSensor_4)
HMLAN2 HMLAN_Read 107 225 5808 25.81 0 HASH(HMLAN2)
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN2 54 57 54 0.95 42 keepAliveCk:HMLAN2
Batteriezustand readingsGroup_Notify 51 574 267 0.47 0 HASH(Batteriezustand); HASH(global)
tmr-Weather_GetUpdate HASH(0x2cbcd70) 33 1 33 33.00 1 HASH(MeinWetter)
HMLAN2 HMLAN_Ready 28 2 28 14.00 0 HASH(HMLAN2)
tmr-HourCounter_Run Counter.azSteckdose1 28 1 28 28.00 3 Counter.azSteckdose1
tmr-HourCounter_Run Counter.azLichtSchalter 19 1 19 19.00 0 Counter.azLichtSchalter
tmr-FRITZBOX_Readout_Start FritzBox.Readout 15 22 308 14.00 31 FritzBox.Readout
tmr-PRESENCE_StartLocalScan HASH(0x2a06570) 14 4 56 14.00 12 HASH(Handy_1)
tmr-PRESENCE_StartLocalScan HASH(0x2dc5908) 14 4 56 14.00 2 HASH(Handy_2)
tmr-at_Exec HASH(0x1ec9140) 14 1 14 14.00 1 HASH(at.check_system)
HMLAN2 HMLAN_Notify 13 574 13 0.02 0 HASH(HMLAN2); HASH(HMLAN2)
at.tmp.Warn_open_egTSensor_6 at_Define 12 1 12 12.00 0 HASH(at.tmp.Warn_open_egTSensor_6);
at.tmp.Warn_open_egTSensor_6 at +00:10:00
{Send_open_warning("egTSensor")}
tmr-CUL_HM_readStateTo sUpdt:iStatus 12 1 12 12.00 36 sUpdt:iStatus
tmr-CUL_HM_ActCheck ActionDetector 7 3 21 7.00 5 ActionDetector
Zu Problem (3) mache ich mich gerade schlau.
Mein erster Ansatz ist, Geräte vom Netz zu nehmen, die einen UPnP Server besitzen.
Eventuell hat jemand noch Tipps, wie hier am Besten vorzugehen ist.
Ciao James
Ergänzung:
In der Zwischenzeit habe ich nun auch de Bedeutung des Internals "msgKeepAlive" und des Readings "wdTimer" verstanden.
msgKeepAlive dlyMax:28.055 bufferMin:-23
wdTimer 25
Das sollte also bedeuten, ich habe ein Problem im Netzwerk.
Der HMLAN erwartet alle 30 Sekunden eine Keep-Alive-Message von der Zentrale. Er fordert sie alle 25 Sekunden an (Inhalt von "wdTimer"), hat damit einen Puffer von 5 Sekunden.
Wie "msgKeepAlive" zeigt, kam es im Fehlerfall zu einer Verzögerung von ~28 Sekunden ("dlyMax"), was den Puffer von 5 Sekunde um 23 Sekunden ("bufferMin") überschritt.
Damit dürfte Problem (1) auch ausgeschlossen sein und ich fokussiere auf Problem (2), die Multicasts oder generell Blockierungen im LAN.
Kommentare sind natürlich weiterhin äußerst erwünscht :)
Zitat von: RadioJames am 02 März 2017, 11:44:10
Hallo allerseits,
leider bin auch ich seit einiger Zeit vom "HMLAN disconnected/connected" - Problem betroffen.
Aus verschiedenen Threads konnte ich folgende potentielle Fehlerursachen finden:
(1) Blockierende Threads mit einer Dauer > 10 Sekunden
(2) Multicast Messages
(3) Elkos im HMLAN, deren Kapazität sich wesentlich geändert hat
Da ich zwei HMLANs besitze und nur einer das Verhalten zeigt, habe ich beide getauscht. Nun trat das Problem beim vorher fehlerfrei arbeitenden HMLAN auf und der andere arbeite tadellos.
Damit möchte ich Problem (3) ausschließen.
Problem (1) versuche ich gerade mit AppTime auf die Spur zu kommen. Es trat glücklicherweise auch kurz nach dessen Start auf. Allerdings kann ich in der Zusamenfassung unten keine Probleme erkennen.
Könnte das bitte jemand bestätigen, der sich damit gut auskennt?
------------------------------------------------------------------------------------------------------------------------------------------------------------
name function max count total average maxDly
------------------------------------------------------------------------------------------------------------------------------------------------------------
HMLAN1 HMLAN_Read 389 270 3573 13.23 0 HASH(HMLAN1)
FileLog_iStatus FileLog_Log 373 101 442 4.38 0 HASH(FileLog_iStatus); HASH(iStatus)
tmr-CUL_HM_procQs CUL_HM_procQs 254 4 362 90.50 23 CUL_HM_procQs
tmr-at_Exec HASH(0x12d3150) 169 1 169 169.00 7 HASH(at.tmp.Warn_open_egTSensor_3)
tmr-at_Exec HASH(0x3b6d048) 161 1 161 161.00 4 HASH(at.tmp.Warn_open_egTSensor_5)
tmr-at_Exec HASH(0x335f0d8) 116 1 116 116.00 5 HASH(at.tmp.Warn_open_egTSensor_4)
HMLAN2 HMLAN_Read 107 225 5808 25.81 0 HASH(HMLAN2)
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN2 54 57 54 0.95 42 keepAliveCk:HMLAN2
Batteriezustand readingsGroup_Notify 51 574 267 0.47 0 HASH(Batteriezustand); HASH(global)
tmr-Weather_GetUpdate HASH(0x2cbcd70) 33 1 33 33.00 1 HASH(MeinWetter)
HMLAN2 HMLAN_Ready 28 2 28 14.00 0 HASH(HMLAN2)
tmr-HourCounter_Run Counter.azSteckdose1 28 1 28 28.00 3 Counter.azSteckdose1
tmr-HourCounter_Run Counter.azLichtSchalter 19 1 19 19.00 0 Counter.azLichtSchalter
tmr-FRITZBOX_Readout_Start FritzBox.Readout 15 22 308 14.00 31 FritzBox.Readout
tmr-PRESENCE_StartLocalScan HASH(0x2a06570) 14 4 56 14.00 12 HASH(Handy_1)
tmr-PRESENCE_StartLocalScan HASH(0x2dc5908) 14 4 56 14.00 2 HASH(Handy_2)
tmr-at_Exec HASH(0x1ec9140) 14 1 14 14.00 1 HASH(at.check_system)
HMLAN2 HMLAN_Notify 13 574 13 0.02 0 HASH(HMLAN2); HASH(HMLAN2)
at.tmp.Warn_open_egTSensor_6 at_Define 12 1 12 12.00 0 HASH(at.tmp.Warn_open_egTSensor_6);
at.tmp.Warn_open_egTSensor_6 at +00:10:00
{Send_open_warning("egTSensor")}
tmr-CUL_HM_readStateTo sUpdt:iStatus 12 1 12 12.00 36 sUpdt:iStatus
tmr-CUL_HM_ActCheck ActionDetector 7 3 21 7.00 5 ActionDetector
Zu Problem (3) mache ich mich gerade schlau.
Mein erster Ansatz ist, Geräte vom Netz zu nehmen, die einen UPnP Server besitzen.
Eventuell hat jemand noch Tipps, wie hier am Besten vorzugehen ist.
Ciao James
Ergänzung:
In der Zwischenzeit habe ich nun auch de Bedeutung des Internals "msgKeepAlive" und des Readings "wdTimer" verstanden.
msgKeepAlive dlyMax:28.055 bufferMin:-23
wdTimer 25
Das sollte also bedeuten, ich habe ein Problem im Netzwerk.
Der HMLAN erwartet alle 30 Sekunden eine Keep-Alive-Message von der Zentrale. Er fordert sie alle 25 Sekunden an (Inhalt von "wdTimer"), hat damit einen Puffer von 5 Sekunden.
Wie "msgKeepAlive" zeigt, kam es im Fehlerfall zu einer Verzögerung von ~28 Sekunden ("dlyMax"), was den Puffer von 5 Sekunde um 23 Sekunden ("bufferMin") überschritt.
Damit dürfte Problem (1) auch ausgeschlossen sein und ich fokussiere auf Problem (2), die Multicasts oder generell Blockierungen im LAN.
Kommentare sind natürlich weiterhin äußerst erwünscht :)
ist doch schon einmal gut dokumentiert :-)
Ich hätte da noch eine Idee um dem Multicast Problem ein wenig auf die schliche zu kommen.
Wenn Du Dein FHEM NICHT auf der Fritzbox betreibst, dann versuche doch mal folgendes:
Weise Deiner Netzwerkarte von FHEM eine 2. IP Adresse in einem anderen IP Netzwerk zu. In dieses Netzwerk kommt dann der HMLAN der Probleme macht
Also wenn dein Router im Netz 192.168.178.0/24 ist mit der IP 192.168.178.1 (Default von AVM)
Dann füge ein Virtuelles Interface mit z.B. der Adresse 192.168.42.1 hinzu (Abschnitt Virtuelle Schnittstellen in https://wiki.ubuntuusers.de/interfaces/ ) und gibst dem HMLAN dann die Adresse 192.168.42.55 und änderst entsprechend in FHEM die Adresse
Wenn jetzt Besserung eintritt solltest Du entweder mit diesem Workaround leben oder Dir einen Managed Switch kaufen
Ich würde als erstes immer nach der uptime des HMLAN schauen ... wenn diese beim disconnect auf 0 gesetzt wurde war es ein Reboot des HMLAN, und das weist auf (2) ... wenn es kein Reboot war dann ist die Ursache eher in (1) zu suchen
firmware 0.965 drauf?
Hallo,
danke für euer Feedback.
... wenn diese beim disconnect auf 0 gesetzt wurde war es ein Reboot des HMLAN, und das weist auf (2)
"uptime" wird zurückgesetzt.
firmware 0.965 drauf
Die Firmware auf meinen beiden HMLANs ist die aktuelle V0.965.
@Wuppi68
Danke, interessanter Vorschlag, muss ich geistig aber noch durchdringen. ;)
Mein FHEM läuft auf einem Raspberry Pi im Keller. Die HMLANs sind über das Haus verteilt (Keller, Wohnzimmer). Der Problem-HMLAN ist der im Wohnzimmer.
Das Stichwort Managed Switch hatte ich auch schon mal im Hinterkopf, muss aber zugeben, dass ich das Ganze noch nicht verstanden habe.
Ich denke, es ist jetzt ziemlich eindeutig ein Problem mit meinem Netzwerk und ich werde an Wuppis Vorschlag weiterforschen.
Grüße
James
Hallo Zusammen,
sorry, dass ich das hier mal wieder aufrolle, aber ich habe letztens angefangen, mein fhem neu aufzusetzen und ziehe zur Zeit nach und nach die Komponenten um. Da ist mir das hier beschriebene verhalten aufgefallen.
@RadioJames: hast du den von Wuppi68 vorgeschlagenen Weg mal ausprobiert? Da ich sowieso nur mit fhem auf den hmlan zugreife, wäre das für mich ein akzeptabler Workaround.
Viele Grüße,
Blade
Hallo,
ich habe immer dann ständige disconnects des HMALN, wenn ich den CUL aktivere. Beide gleichzeitig kann ich nicht nutzen. Den Grund dafür habe ich noch nicht gefunden. Sobald ich dem CUL "none" als Device gebe, gibt es keine Disconnects des HMLAN mehr.
Kann das jemand bestätigen? Laufen beide parallel bei irgend jemandem ohne Disconnects des HMLAN?
Ach ja: Den CUL habe ich per ser2net angebunden.
Gruß,
Mirko.
Vccu eingerichtet? Haben beide verschiedene HM ID? Beide auf Verbose 5 stellen und im Log schauen.
Ja, vccu ist eingerichtet. Allerdings haben beide dieselbe HM ID. Ist das mein Problem? ???
Wenn du meinst HMLAN und CUL haben die selbe, dann wird das vermutlich dein Problem sein.
Da hatte ich wohl etwas misverstanden. Für mich waren beide (CUL und HMLAN) IO-Device für dieselbe vccu und hatten deshalb auch beide die gleiche HM-Id. :-[ Das habe ich jetzt geändert, indem ich dem CUL eine eigene HM-Id zugewiesen und ihn dann der vccu erneut als IO-Device hinzugefügt habe. Das hat auch erst ganz gut funktioniert, aber nun bekomme ich doch wieder die disconnects des HMLAN. :-\
Ich habe bei HMLAN und CUL einmal verbose=5 gesetzt. Anbei das Log rund um ein disconnect des HMLAN. Ich kann da leider nicht herauslesen, warum das HMLAN nicht rechtzeitig antwortet.
2018.01.22 20:34:03 5: HMLAN_Parse: HMLAN1 V:03C5 sNo:MEQ0313652 d:37A0AD O:F12305 t:0000936B IDcnt:0006 L:1 %
2018.01.22 20:34:03 5: HMLAN/RAW: /HHM-LAN-IF,03C5,MEQ0313652,37A0AD,F12305,0000936B,0006,01
2018.01.22 20:34:03 5: HMLAN_Send: HMLAN1 I:K
2018.01.22 20:34:01 5: CUL1: dispatch A0CB8847058800600000000BF2C::-88:CUL1
2018.01.22 20:34:01 4: CUL_Parse: CUL1 A 0C B8 8470 588006 000000 00BF2CE4 -88
2018.01.22 20:34:01 5: CUL/RAW: /A0CB8847058800600000000BF2CE4
2018.01.22 20:34:01 5: HMLAN1: dispatch A0AEA8002F123055AF44A00::-73:HMLAN1
2018.01.22 20:34:01 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:00008B36 d:FF r:FFB7 m:EA 8002 F12305 5AF44A 00
2018.01.22 20:34:01 5: HMLAN_Send: HMLAN1 I:+588006,00,01,00
2018.01.22 20:34:01 5: HMLAN1: dispatch A0CB8847058800600000000BF2C::-62:HMLAN1
2018.01.22 20:34:01 5: HMLAN_Parse: HMLAN1 R:E588006 stat:0000 t:00008ADD d:FF r:FFC2 m:B8 8470 588006 000000 00BF2C
2018.01.22 20:34:01 5: HMLAN1: dispatch A14EAA45F5AF44AF1230580B4B20016F201920936FF::-57:HMLAN1
2018.01.22 20:34:01 5: HMLAN_Parse: HMLAN1 R:E5AF44A stat:0000 t:00008AB3 d:FF r:FFC7 m:EA A45F 5AF44A F12305 80B4B20016F201920936FF
EF12305,0000,00008B36,FF,FFB7,EA8002F123055AF44A00
E588006,0000,00008ADD,FF,FFC2,B8847058800600000000BF2C
2018.01.22 20:34:01 5: HMLAN/RAW: /E5AF44A,0000,00008AB3,FF,FFC7,EAA45F5AF44AF1230580B4B20016F201920936FF
2018.01.22 20:34:01 5: SW: As0AEA8002F123055AF44A00
2018.01.22 20:34:01 5: CUL 5AF44A dly:93ms
2018.01.22 20:34:01 5: CUL1 sending As0AEA8002F123055AF44A00
2018.01.22 20:34:01 5: HMLAN_Send: HMLAN1 I:-5AF44A
2018.01.22 20:34:01 5: HMLAN_Send: HMLAN1 I:+5AF44A,00,01,00
2018.01.22 20:34:01 5: CUL1: dispatch A14EAA45F5AF44AF1230580B4B20016F201920936FF::-66:CUL1
2018.01.22 20:34:01 4: CUL_Parse: CUL1 A 14 EA A45F 5AF44A F12305 80B4B20016F201920936FF10 -66
2018.01.22 20:34:01 5: CUL/RAW: /A14EAA45F5AF44AF1230580B4B20016F201920936FF10
2018.01.22 20:33:57 5: HMLAN1: dispatch A0F4586103094FE0000000AB8FB0C2400::-84:HMLAN1
2018.01.22 20:33:57 5: HMLAN_Parse: HMLAN1 R:E3094FE stat:0000 t:00006E7D d:FF r:FFAC m:45 8610 3094FE 000000 0AB8FB0C2400
2018.01.22 20:33:57 5: HMLAN/RAW: /E3094FE,0000,00006E7D,FF,FFAC,4586103094FE0000000AB8FB0C2400
2018.01.22 20:33:54 5: CUL1: dispatch A0F4586103094FE0000000AB8FB0C2400::-61.5:CUL1
2018.01.22 20:33:54 4: CUL_Parse: CUL1 A 0F 45 8610 3094FE 000000 0AB8FB0C240019 -61.5
2018.01.22 20:33:54 5: CUL/RAW: /A0F4586103094FE0000000AB8FB0C240019
2018.01.22 20:33:53 5: HMLAN1: dispatch A0AE98002F123055AF44A00::-74:HMLAN1
2018.01.22 20:33:53 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:00006BFE d:FF r:FFB6 m:E9 8002 F12305 5AF44A 00
2018.01.22 20:33:53 5: HMLAN/RAW: /EF12305,0000,00006BFE,FF,FFB6,E98002F123055AF44A00
2018.01.22 20:33:53 5: HMLAN1: dispatch A14E9A45F5AF44AF1230580B4B1000DF900FD0936FE::-57:HMLAN1
2018.01.22 20:33:53 5: HMLAN_Parse: HMLAN1 R:E5AF44A stat:0000 t:00006B71 d:FF r:FFC7 m:E9 A45F 5AF44A F12305 80B4B1000DF900FD0936FE
2018.01.22 20:33:53 5: HMLAN/RAW: /E5AF44A,0000,00006B71,FF,FFC7,E9A45F5AF44AF1230580B4B1000DF900FD0936FE
2018.01.22 20:33:53 5: CUL1: dispatch A0AE98002F123055AF44A00::-69:CUL1
2018.01.22 20:33:53 4: CUL_Parse: CUL1 A 0A E9 8002 F12305 5AF44A 000A -69
2018.01.22 20:33:53 5: CUL/RAW: /A0AE98002F123055AF44A000A
2018.01.22 20:33:53 5: SW: As0AE98002F123055AF44A00
2018.01.22 20:33:53 5: CUL 5AF44A dly:96ms
2018.01.22 20:33:53 5: CUL1 sending As0AE98002F123055AF44A00
2018.01.22 20:33:53 5: HMLAN_Send: HMLAN1 I:-5AF44A
2018.01.22 20:33:53 5: CUL1: dispatch A14E9A45F5AF44AF1230580B4B1000DF900FD0936FE::-66:CUL1
2018.01.22 20:33:53 4: CUL_Parse: CUL1 A 14 E9 A45F 5AF44A F12305 80B4B1000DF900FD0936FE10 -66
2018.01.22 20:33:53 5: CUL/RAW: /A14E9A45F5AF44AF1230580B4B1000DF900FD0936FE10
2018.01.22 20:33:52 5: HMLAN_Send: HMLAN1 I:-4513D1
2018.01.22 20:33:52 5: HMLAN1: dispatch A0AE380024513D14B4D1C00::-55:HMLAN1
2018.01.22 20:33:52 5: HMLAN_Parse: HMLAN1 R:E4513D1 stat:0000 t:0000696F d:FF r:FFC9 m:E3 8002 4513D1 4B4D1C 00
2018.01.22 20:33:52 5: HMLAN/RAW: /E4513D1,0000,0000696F,FF,FFC9,E380024513D14B4D1C00
2018.01.22 20:33:52 5: HMLAN_Send: HMLAN1 I:+4513D1,00,01,00
2018.01.22 20:33:52 5: CUL1: dispatch A0AE380024513D14B4D1C00::-75.5:CUL1
2018.01.22 20:33:52 4: CUL_Parse: CUL1 A 0A E3 8002 4513D1 4B4D1C 00FD -75.5
2018.01.22 20:33:52 5: CUL/RAW: /A0AE380024513D14B4D1C00FD
2018.01.22 20:33:52 5: HMLAN_Send: HMLAN1 I:-4B4D1C
2018.01.22 20:33:52 5: HMLAN1: dispatch A0CE3A0414B4D1C4513D1017300::-54:HMLAN1
2018.01.22 20:33:52 5: HMLAN_Parse: HMLAN1 R:E4B4D1C stat:0000 t:000068F0 d:FF r:FFCA m:E3 A041 4B4D1C 4513D1 017300
2018.01.22 20:33:52 5: HMLAN/RAW: /E4B4D1C,0000,000068F0,FF,FFCA,E3A0414B4D1C4513D1017300
2018.01.22 20:33:52 5: HMLAN_Send: HMLAN1 I:+4B4D1C,00,01,00
2018.01.22 20:33:52 5: CUL1: dispatch A0CE3A0414B4D1C4513D1017300::-81:CUL1
2018.01.22 20:33:52 4: CUL_Parse: CUL1 A 0C E3 A041 4B4D1C 4513D1 017300F2 -81
2018.01.22 20:33:52 5: CUL/RAW: /A0CE3A0414B4D1C4513D1017300F2
2018.01.22 20:33:52 5: HMLAN_Send: HMLAN1 I:-45139E
2018.01.22 20:33:52 5: HMLAN1: dispatch A0AE2800245139E4B4D1C00::-51:HMLAN1
2018.01.22 20:33:52 5: HMLAN_Parse: HMLAN1 R:E45139E stat:0000 t:00006871 d:FF r:FFCD m:E2 8002 45139E 4B4D1C 00
2018.01.22 20:33:52 5: HMLAN/RAW: /E45139E,0000,00006871,FF,FFCD,E2800245139E4B4D1C00
2018.01.22 20:33:52 5: HMLAN_Send: HMLAN1 I:+45139E,00,01,00
2018.01.22 20:33:52 5: CUL1: dispatch A0AE2800245139E4B4D1C00::-76.5:CUL1
2018.01.22 20:33:52 4: CUL_Parse: CUL1 A 0A E2 8002 45139E 4B4D1C 00FB -76.5
2018.01.22 20:33:52 5: CUL/RAW: /A0AE2800245139E4B4D1C00FB
2018.01.22 20:33:52 5: HMLAN_Send: HMLAN1 I:-4B4D1C
2018.01.22 20:33:52 5: HMLAN1: dispatch A0CE2B0414B4D1C45139E017300::-54:HMLAN1
2018.01.22 20:33:52 5: HMLAN_Parse: HMLAN1 R:E4B4D1C stat:0000 t:000067F2 d:FF r:FFCA m:E2 B041 4B4D1C 45139E 017300
2018.01.22 20:33:52 5: HMLAN/RAW: /E4B4D1C,0000,000067F2,FF,FFCA,E2B0414B4D1C45139E017300
2018.01.22 20:33:52 5: HMLAN_Send: HMLAN1 I:+4B4D1C,00,01,00
2018.01.22 20:33:52 5: CUL1: dispatch A0CE2B0414B4D1C45139E017300::-80.5:CUL1
2018.01.22 20:33:52 4: CUL_Parse: CUL1 A 0C E2 B041 4B4D1C 45139E 017300F3 -80.5
2018.01.22 20:33:52 5: CUL/RAW: /A0CE2B0414B4D1C45139E017300F3
2018.01.22 20:33:51 5: HMLAN1: dispatch A0AE18002F123054B4D1C00::-73:HMLAN1
2018.01.22 20:33:51 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:00006614 d:FF r:FFB7 m:E1 8002 F12305 4B4D1C 00
2018.01.22 20:33:51 5: HMLAN1: dispatch A0CE1A4414B4D1CF12305017300::-54:HMLAN1
2018.01.22 20:33:51 5: HMLAN_Parse: HMLAN1 R:E4B4D1C stat:0000 t:00006592 d:FF r:FFCA m:E1 A441 4B4D1C F12305 017300
EF12305,0000,00006614,FF,FFB7,E18002F123054B4D1C00
2018.01.22 20:33:51 5: HMLAN/RAW: /E4B4D1C,0000,00006592,FF,FFCA,E1A4414B4D1CF12305017300
2018.01.22 20:33:51 5: SW: As0AE18002F123054B4D1C00
2018.01.22 20:33:51 5: CUL 4B4D1C dly:96ms
2018.01.22 20:33:51 5: CUL1 sending As0AE18002F123054B4D1C00
2018.01.22 20:33:51 5: HMLAN_Send: HMLAN1 I:-4B4D1C
2018.01.22 20:33:51 5: HMLAN_Send: HMLAN1 I:+4B4D1C,00,01,00
2018.01.22 20:33:51 5: CUL1: dispatch A0CE1A4414B4D1CF12305017300::-81:CUL1
2018.01.22 20:33:51 4: CUL_Parse: CUL1 A 0C E1 A441 4B4D1C F12305 017300F2 -81
2018.01.22 20:33:51 5: CUL/RAW: /A0CE1A4414B4D1CF12305017300F2
2018.01.22 20:33:51 5: HMLAN_Send: HMLAN1 I:-588006
2018.01.22 20:33:51 5: HMLAN1: dispatch A0EB984105880060000000B80BF2B00::-62:HMLAN1
2018.01.22 20:33:51 5: HMLAN_Parse: HMLAN1 R:E588006 stat:0000 t:000063CD d:FF r:FFC2 m:B9 8410 588006 000000 0B80BF2B00
2018.01.22 20:33:51 5: HMLAN/RAW: /E588006,0000,000063CD,FF,FFC2,B984105880060000000B80BF2B00
2018.01.22 20:33:51 5: HMLAN_Send: HMLAN1 I:+588006,00,01,00
2018.01.22 20:33:51 5: CUL1: dispatch A0EB984105880060000000B80BF2B00::-90.5:CUL1
2018.01.22 20:33:51 4: CUL_Parse: CUL1 A 0E B9 8410 588006 000000 0B80BF2B00DF -90.5
2018.01.22 20:33:51 5: CUL/RAW: /A0EB984105880060000000B80BF2B00DF
2018.01.22 20:33:50 5: HMLAN_Send: HMLAN1 I:-4513D1
2018.01.22 20:33:50 5: HMLAN1: dispatch A0AE080024513D14B4D1C00::-56:HMLAN1
2018.01.22 20:33:50 5: HMLAN_Parse: HMLAN1 R:E4513D1 stat:0000 t:000060A6 d:FF r:FFC8 m:E0 8002 4513D1 4B4D1C 00
2018.01.22 20:33:50 5: HMLAN/RAW: /E4513D1,0000,000060A6,FF,FFC8,E080024513D14B4D1C00
2018.01.22 20:33:50 5: HMLAN_Send: HMLAN1 I:+4513D1,00,01,00
2018.01.22 20:33:50 5: CUL1: dispatch A0AE080024513D14B4D1C00::-74.5:CUL1
2018.01.22 20:33:50 4: CUL_Parse: CUL1 A 0A E0 8002 4513D1 4B4D1C 00FF -74.5
2018.01.22 20:33:50 5: CUL/RAW: /A0AE080024513D14B4D1C00FF
2018.01.22 20:33:50 5: HMLAN_Send: HMLAN1 I:-4B4D1C
2018.01.22 20:33:50 5: HMLAN1: dispatch A0CE0A0414B4D1C4513D10172C8::-53:HMLAN1
2018.01.22 20:33:50 5: HMLAN_Parse: HMLAN1 R:E4B4D1C stat:0000 t:00006027 d:FF r:FFCB m:E0 A041 4B4D1C 4513D1 0172C8
2018.01.22 20:33:50 5: HMLAN/RAW: /E4B4D1C,0000,00006027,FF,FFCB,E0A0414B4D1C4513D10172C8
2018.01.22 20:33:50 5: HMLAN_Send: HMLAN1 I:+4B4D1C,00,01,00
2018.01.22 20:33:50 5: CUL1: dispatch A0CE0A0414B4D1C4513D10172C8::-80:CUL1
2018.01.22 20:33:50 4: CUL_Parse: CUL1 A 0C E0 A041 4B4D1C 4513D1 0172C8F4 -80
2018.01.22 20:33:50 5: CUL/RAW: /A0CE0A0414B4D1C4513D10172C8F4
2018.01.22 20:33:50 5: HMLAN_Send: HMLAN1 I:-45139E
2018.01.22 20:33:50 5: HMLAN1: dispatch A0ADF800245139E4B4D1C00::-50:HMLAN1
2018.01.22 20:33:50 5: HMLAN_Parse: HMLAN1 R:E45139E stat:0000 t:00005FA7 d:FF r:FFCE m:DF 8002 45139E 4B4D1C 00
2018.01.22 20:33:50 5: HMLAN/RAW: /E45139E,0000,00005FA7,FF,FFCE,DF800245139E4B4D1C00
2018.01.22 20:33:50 5: HMLAN_Send: HMLAN1 I:+45139E,00,01,00
2018.01.22 20:33:50 5: CUL1: dispatch A0ADF800245139E4B4D1C00::-76:CUL1
2018.01.22 20:33:50 4: CUL_Parse: CUL1 A 0A DF 8002 45139E 4B4D1C 00FC -76
2018.01.22 20:33:50 5: CUL/RAW: /A0ADF800245139E4B4D1C00FC
2018.01.22 20:33:50 5: HMLAN_Send: HMLAN1 I:-4B4D1C
2018.01.22 20:33:50 5: HMLAN1: dispatch A0CDFB0414B4D1C45139E0172C8::-53:HMLAN1
2018.01.22 20:33:50 5: HMLAN_Parse: HMLAN1 R:E4B4D1C stat:0000 t:00005F28 d:FF r:FFCB m:DF B041 4B4D1C 45139E 0172C8
2018.01.22 20:33:50 5: HMLAN/RAW: /E4B4D1C,0000,00005F28,FF,FFCB,DFB0414B4D1C45139E0172C8
2018.01.22 20:33:50 5: HMLAN_Send: HMLAN1 I:+4B4D1C,00,01,00
2018.01.22 20:33:50 5: CUL1: dispatch A0CDFB0414B4D1C45139E0172C8::-80.5:CUL1
2018.01.22 20:33:50 4: CUL_Parse: CUL1 A 0C DF B041 4B4D1C 45139E 0172C8F3 -80.5
2018.01.22 20:33:50 5: CUL/RAW: /A0CDFB0414B4D1C45139E0172C8F3
2018.01.22 20:33:49 5: HMLAN1: dispatch A0ADE8002F123054B4D1C00::-73:HMLAN1
2018.01.22 20:33:49 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:00005D62 d:FF r:FFB7 m:DE 8002 F12305 4B4D1C 00
2018.01.22 20:33:49 5: HMLAN/RAW: /EF12305,0000,00005D62,FF,FFB7,DE8002F123054B4D1C00
2018.01.22 20:33:49 5: HMLAN1: dispatch A0ADE8002F123054B4D1C00::-73:HMLAN1
2018.01.22 20:33:49 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:00005D49 d:FF r:FFB7 m:DE 8002 F12305 4B4D1C 00
2018.01.22 20:33:49 5: HMLAN1: dispatch A0CDEA4414B4D1CF123050172C8::-54:HMLAN1
2018.01.22 20:33:49 5: HMLAN_Parse: HMLAN1 R:E4B4D1C stat:0000 t:00005CC8 d:FF r:FFCA m:DE A441 4B4D1C F12305 0172C8
EF12305,0000,00005D49,FF,FFB7,DE8002F123054B4D1C00
2018.01.22 20:33:49 5: HMLAN/RAW: /E4B4D1C,0000,00005CC8,FF,FFCA,DEA4414B4D1CF123050172C8
2018.01.22 20:33:49 5: SW: As0ADE8002F123054B4D1C00
2018.01.22 20:33:49 5: CUL1 sending As0ADE8002F123054B4D1C00
2018.01.22 20:33:49 5: SW: As0ADE8002F123054B4D1C00
2018.01.22 20:33:49 5: CUL 4B4D1C dly:96ms
2018.01.22 20:33:49 5: CUL1 sending As0ADE8002F123054B4D1C00
2018.01.22 20:33:49 5: CUL1: dispatch A0CDEA4414B4D1CF123050172C8::-78:CUL1
2018.01.22 20:33:49 4: CUL_Parse: CUL1 A 0C DE A441 4B4D1C F12305 0172C8F8 -78
2018.01.22 20:33:49 5: CUL/RAW: /A0CDEA4414B4D1CF123050172C8F8
2018.01.22 20:33:45 5: HMLAN_Send: HMLAN1 I:-569404
2018.01.22 20:33:45 5: HMLAN1: dispatch A0F3586105694040000000A80AE0B0000::-59:HMLAN1
2018.01.22 20:33:45 5: HMLAN_Parse: HMLAN1 R:E569404 stat:0000 t:00004DAD d:FF r:FFC5 m:35 8610 569404 000000 0A80AE0B0000
2018.01.22 20:33:45 5: HMLAN/RAW: /E569404,0000,00004DAD,FF,FFC5,3586105694040000000A80AE0B0000
2018.01.22 20:33:45 5: HMLAN_Send: HMLAN1 I:+569404,00,01,00
2018.01.22 20:33:45 5: CUL1: dispatch A0F3586105694040000000A80AE0B0000::-71.5:CUL1
2018.01.22 20:33:45 4: CUL_Parse: CUL1 A 0F 35 8610 569404 000000 0A80AE0B000005 -71.5
2018.01.22 20:33:45 5: CUL/RAW: /A0F3586105694040000000A80AE0B000005
2018.01.22 20:33:44 5: HMLAN1: dispatch A0FE686105697370000000A80B60D0000::-75:HMLAN1
2018.01.22 20:33:44 5: HMLAN_Parse: HMLAN1 R:E569737 stat:0000 t:000049E5 d:FF r:FFB5 m:E6 8610 569737 000000 0A80B60D0000
2018.01.22 20:33:44 5: HMLAN/RAW: /E569737,0000,000049E5,FF,FFB5,E686105697370000000A80B60D0000
2018.01.22 20:33:44 5: CUL1: dispatch A0FE686105697370000000A80B60D0000::-70.5:CUL1
2018.01.22 20:33:44 4: CUL_Parse: CUL1 A 0F E6 8610 569737 000000 0A80B60D000007 -70.5
2018.01.22 20:33:44 5: CUL/RAW: /A0FE686105697370000000A80B60D000007
2018.01.22 20:33:41 5: HMLAN_Send: HMLAN1 I:-588006
2018.01.22 20:33:41 5: HMLAN1: dispatch A0CB8865A58800600000080BF2C::-62:HMLAN1
2018.01.22 20:33:41 5: HMLAN_Parse: HMLAN1 R:E588006 stat:0000 t:00003CBA d:FF r:FFC2 m:B8 865A 588006 000000 80BF2C
2018.01.22 20:33:41 5: HMLAN/RAW: /E588006,0000,00003CBA,FF,FFC2,B8865A58800600000080BF2C
2018.01.22 20:33:41 5: HMLAN_Send: HMLAN1 I:+588006,00,01,00
2018.01.22 20:33:41 5: CUL1: dispatch A0CB8865A58800600000080BF2C::-89:CUL1
2018.01.22 20:33:41 4: CUL_Parse: CUL1 A 0C B8 865A 588006 000000 80BF2CE2 -89
2018.01.22 20:33:41 5: CUL/RAW: /A0CB8865A58800600000080BF2CE2
2018.01.22 20:33:39 5: HMLAN1: dispatch A0D4D8002F12305580A440101C800::-74:HMLAN1
2018.01.22 20:33:39 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:00003421 d:FF r:FFB6 m:4D 8002 F12305 580A44 0101C800
2018.01.22 20:33:39 5: HMLAN/RAW: /EF12305,0000,00003421,FF,FFB6,4D8002F12305580A440101C800
2018.01.22 20:33:39 5: HMLAN1: dispatch A0A4D8002F12305580A4400::-73:HMLAN1
2018.01.22 20:33:39 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:00003406 d:FF r:FFB7 m:4D 8002 F12305 580A44 00
2018.01.22 20:33:39 5: HMLAN/RAW: /EF12305,0000,00003406,FF,FFB7,4D8002F12305580A4400
2018.01.22 20:33:39 5: HMLAN1: dispatch A0A628002F12305580A8D00::-74:HMLAN1
2018.01.22 20:33:39 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:00003395 d:FF r:FFB6 m:62 8002 F12305 580A8D 00
2018.01.22 20:33:39 5: HMLAN1: dispatch A0A618002F12305580A8D00::-73:HMLAN1
2018.01.22 20:33:39 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:00003329 d:FF r:FFB7 m:61 8002 F12305 580A8D 00
2018.01.22 20:33:39 5: HMLAN1: dispatch A0A608002F12305580A8D00::-73:HMLAN1
2018.01.22 20:33:39 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:000032BE d:FF r:FFB7 m:60 8002 F12305 580A8D 00
2018.01.22 20:33:39 5: HMLAN1: dispatch A0A5F8002F12305580A8D00::-73:HMLAN1
2018.01.22 20:33:39 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:00003252 d:FF r:FFB7 m:5F 8002 F12305 580A8D 00
2018.01.22 20:33:39 1: HMLAN_Parse: HMLAN1 new condition ok
2018.01.22 20:33:39 5: HMLAN_Parse: HMLAN1 R:R1F5C9D7B stat:0002 t:00000000 d:FF r:7FFF m:99 8112 F12305 000000
EF12305,0000,00003395,FF,FFB6,628002F12305580A8D00
EF12305,0000,00003329,FF,FFB7,618002F12305580A8D00
EF12305,0000,000032BE,FF,FFB7,608002F12305580A8D00
EF12305,0000,00003252,FF,FFB7,5F8002F12305580A8D00
2018.01.22 20:33:39 5: HMLAN/RAW: /R1F5C9D7B,0002,00000000,FF,7FFF,998112F12305000000
2018.01.22 20:33:39 5: CUL1: dispatch A09998112F12305000000::-69.5:CUL1
2018.01.22 20:33:39 4: CUL_Parse: CUL1 A 09 99 8112 F12305 000000 09 -69.5
2018.01.22 20:33:39 5: CUL/RAW: /A09998112F1230500000009
2018.01.22 20:33:39 5: HMLAN1: dispatch A0D4D8002F12305580A440101C800::-74:HMLAN1
2018.01.22 20:33:39 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:00002618 d:FF r:FFB6 m:4D 8002 F12305 580A44 0101C800
2018.01.22 20:33:39 5: HMLAN1: dispatch A0A4D8002F12305580A4400::-74:HMLAN1
2018.01.22 20:33:39 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:000025FD d:FF r:FFB6 m:4D 8002 F12305 580A44 00
2018.01.22 20:33:39 5: SW: As0D4D8002F12305580A440101C800
2018.01.22 20:33:39 5: CUL1 sending As0D4D8002F12305580A440101C800
2018.01.22 20:33:39 5: SW: As0A4D8002F12305580A4400
2018.01.22 20:33:38 5: CUL 580A44 dly:98ms
2018.01.22 20:33:38 5: CUL1 sending As0A4D8002F12305580A4400
2018.01.22 20:33:38 5: HMLAN1: dispatch A0C4DA641580A44F123050186C8::-75:HMLAN1
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 R:E580A44 stat:0000 t:0000257B d:FF r:FFB5 m:4D A641 580A44 F12305 0186C8
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:-569404
2018.01.22 20:33:38 5: HMLAN1: dispatch A0A4C8002569404580A4400::-57:HMLAN1
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 R:E569404 stat:0000 t:000024ED d:FF r:FFC7 m:4C 8002 569404 580A44 00
2018.01.22 20:33:38 5: HMLAN1: dispatch A0C4CB641580A445694040186C8::-73:HMLAN1
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 R:E580A44 stat:0000 t:0000246E d:FF r:FFB7 m:4C B641 580A44 569404 0186C8
2018.01.22 20:33:38 5: HMLAN1: dispatch A0A628002F12305580A8D00::-74:HMLAN1
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:0000172E d:FF r:FFB6 m:62 8002 F12305 580A8D 00
2018.01.22 20:33:38 5: SW: As0A628002F12305580A8D00
2018.01.22 20:33:38 5: CUL 580A8D dly:97ms
2018.01.22 20:33:38 5: CUL1 sending As0A628002F12305580A8D00
2018.01.22 20:33:38 5: HMLAN1: dispatch A0D62A610580A8DF1230506010000::-56:HMLAN1
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 R:E580A8D stat:0000 t:000016AB d:FF r:FFC8 m:62 A610 580A8D F12305 06010000
2018.01.22 20:33:38 5: HMLAN1: dispatch A0A618002F12305580A8D00::-73:HMLAN1
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:000013F1 d:FF r:FFB7 m:61 8002 F12305 580A8D 00
2018.01.22 20:33:38 5: SW: As0A618002F12305580A8D00
2018.01.22 20:33:38 5: CUL 580A8D dly:97ms
2018.01.22 20:33:38 5: CUL1 sending As0A618002F12305580A8D00
2018.01.22 20:33:38 5: HMLAN1: dispatch A0D61A610580A8DF1230506010000::-56:HMLAN1
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 R:E580A8D stat:0000 t:0000136F d:FF r:FFC8 m:61 A610 580A8D F12305 06010000
2018.01.22 20:33:38 5: HMLAN1: dispatch A0A608002F12305580A8D00::-73:HMLAN1
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:000011BC d:FF r:FFB7 m:60 8002 F12305 580A8D 00
2018.01.22 20:33:38 5: SW: As0A608002F12305580A8D00
2018.01.22 20:33:38 5: CUL 580A8D dly:96ms
2018.01.22 20:33:38 5: CUL1 sending As0A608002F12305580A8D00
2018.01.22 20:33:38 5: HMLAN1: dispatch A0D60A610580A8DF1230506010000::-56:HMLAN1
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 R:E580A8D stat:0000 t:0000113A d:FF r:FFC8 m:60 A610 580A8D F12305 06010000
2018.01.22 20:33:38 5: HMLAN1: dispatch A0A5F8002F12305580A8D00::-73:HMLAN1
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:000010AC d:FF r:FFB7 m:5F 8002 F12305 580A8D 00
2018.01.22 20:33:38 5: SW: As0A5F8002F12305580A8D00
2018.01.22 20:33:38 5: CUL 580A8D dly:98ms
2018.01.22 20:33:38 5: CUL1 sending As0A5F8002F12305580A8D00
2018.01.22 20:33:38 5: HMLAN1: dispatch A0D5FA610580A8DF1230506010000::-56:HMLAN1
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 R:E580A8D stat:0000 t:0000102A d:FF r:FFC8 m:5F A610 580A8D F12305 06010000
2018.01.22 20:33:38 5: HMLAN_Parse: HMLAN1 V:03C5 sNo:MEQ0313652 d:37A0AD O:F12305 t:000031A6 IDcnt:0000 L:0 %
I00,01,00,00
I00,01,00,00
I00,01,00,00
EF12305,0000,00002618,FF,FFB6,4D8002F12305580A440101C800
EF12305,0000,000025FD,FF,FFB6,4D8002F12305580A4400
E580A44,0000,0000257B,FF,FFB5,4DA641580A44F123050186C8
E569404,0000,000024ED,FF,FFC7,4C8002569404580A4400
E580A44,0000,0000246E,FF,FFB7,4CB641580A445694040186C8
EF12305,0000,0000172E,FF,FFB6,628002F12305580A8D00
E580A8D,0000,000016AB,FF,FFC8,62A610580A8DF1230506010000
EF12305,0000,000013F1,FF,FFB7,618002F12305580A8D00
E580A8D,0000,0000136F,FF,FFC8,61A610580A8DF1230506010000
EF12305,0000,000011BC,FF,FFB7,608002F12305580A8D00
E580A8D,0000,0000113A,FF,FFC8,60A610580A8DF1230506010000
EF12305,0000,000010AC,FF,FFB7,5F8002F12305580A8D00
E580A8D,0000,0000102A,FF,FFC8,5FA610580A8DF1230506010000
2018.01.22 20:33:38 5: HMLAN/RAW: /HHM-LAN-IF,03C5,MEQ0313652,37A0AD,F12305,000031A6,0000,00
2018.01.22 20:33:38 1: 192.168.178.26:1000 reappeared (HMLAN1)
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 S:S1F5C9D7B stat: 00 t:00000000 d:01 r:1F5C9D7B m:99 8112 F12305 000000
2018.01.22 20:33:38 1: HMLAN_Parse: HMLAN1 new condition init
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:T21F8EB02,04,00,00000000
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:Y03,00,
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:Y02,00,
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:Y01,01,c4683d74356c9b8d02930caddf1096b3
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:+36E81A,00,00,00
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:+4A0FCD,01,01,02
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:+580A44,00,01,00
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:+36E97A,00,00,00
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:+365CEE,00,01,00
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:+569404,00,01,00
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:+5AF44A,00,01,00
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:C
2018.01.22 20:33:38 5: HMLAN_Send: HMLAN1 I:AF12305
2018.01.22 20:33:35 5: SW: As0D4D8002F12305580A440101C800
2018.01.22 20:33:35 5: CUL1 sending As0D4D8002F12305580A440101C800
2018.01.22 20:33:35 5: SW: As0A4D8002F12305580A4400
2018.01.22 20:33:35 5: CUL 580A44 dly:97ms
2018.01.22 20:33:35 5: CUL1 sending As0A4D8002F12305580A4400
2018.01.22 20:33:35 5: CUL1: dispatch A0C4DA641580A44F123050186C8::-77.5:CUL1
2018.01.22 20:33:35 4: CUL_Parse: CUL1 A 0C 4D A641 580A44 F12305 0186C8F9 -77.5
2018.01.22 20:33:35 5: CUL/RAW: /A0C4DA641580A44F123050186C8F9
2018.01.22 20:33:35 1: HMLAN_Parse: HMLAN1 new condition disconnected
2018.01.22 20:33:35 1: 192.168.178.26:1000 disconnected, waiting to reappear (HMLAN1)
2018.01.22 20:33:35 1: HMLAN_Parse: HMLAN1 new condition disconnected
2018.01.22 20:33:35 5: HMLAN_Send: HMLAN1 I:+569404,00,01,00
2018.01.22 20:33:35 5: CUL1: dispatch A0A4C8002569404580A4400::-68.5:CUL1
2018.01.22 20:33:35 4: CUL_Parse: CUL1 A 0A 4C 8002 569404 580A44 000B -68.5
2018.01.22 20:33:35 5: CUL/RAW: /A0A4C8002569404580A44000B
2018.01.22 20:33:35 5: HMLAN_Send: HMLAN1 I:+580A44,00,01,00
2018.01.22 20:33:35 5: CUL1: dispatch A0C4CB641580A445694040186C8::-77:CUL1
2018.01.22 20:33:35 4: CUL_Parse: CUL1 A 0C 4C B641 580A44 569404 0186C8FA -77
2018.01.22 20:33:35 5: CUL/RAW: /A0C4CB641580A445694040186C8FA
2018.01.22 20:33:34 5: HMLAN_Send: HMLAN1 I:K
2018.01.22 20:33:33 5: HMLAN_Send: HMLAN1 I:K
2018.01.22 20:33:32 5: HMLAN_Send: HMLAN1 I:K
2018.01.22 20:33:31 5: SW: As0A628002F12305580A8D00
2018.01.22 20:33:31 5: CUL 580A8D dly:95ms
2018.01.22 20:33:31 5: CUL1 sending As0A628002F12305580A8D00
2018.01.22 20:33:31 5: CUL1: dispatch A0D62A610580A8DF1230506010000::-90:CUL1
2018.01.22 20:33:31 4: CUL_Parse: CUL1 A 0D 62 A610 580A8D F12305 06010000E0 -90
2018.01.22 20:33:31 5: CUL/RAW: /A0D62A610580A8DF1230506010000E0
2018.01.22 20:33:31 5: HMLAN_Send: HMLAN1 I:K
2018.01.22 20:33:30 5: SW: As0A618002F12305580A8D00
2018.01.22 20:33:30 5: CUL 580A8D dly:96ms
2018.01.22 20:33:30 5: CUL1 sending As0A618002F12305580A8D00
2018.01.22 20:33:30 5: CUL1: dispatch A0D61A610580A8DF1230506010000::-89:CUL1
2018.01.22 20:33:30 4: CUL_Parse: CUL1 A 0D 61 A610 580A8D F12305 06010000E2 -89
2018.01.22 20:33:30 5: CUL/RAW: /A0D61A610580A8DF1230506010000E2
2018.01.22 20:33:30 5: SW: As0A608002F12305580A8D00
2018.01.22 20:33:30 5: CUL 580A8D dly:95ms
2018.01.22 20:33:30 5: CUL1 sending As0A608002F12305580A8D00
2018.01.22 20:33:30 5: CUL1: dispatch A0D60A610580A8DF1230506010000::-89.5:CUL1
2018.01.22 20:33:30 4: CUL_Parse: CUL1 A 0D 60 A610 580A8D F12305 06010000E1 -89.5
2018.01.22 20:33:30 5: CUL/RAW: /A0D60A610580A8DF1230506010000E1
2018.01.22 20:33:29 5: SW: As0A5F8002F12305580A8D00
2018.01.22 20:33:29 5: CUL 580A8D dly:93ms
2018.01.22 20:33:29 5: CUL1 sending As0A5F8002F12305580A8D00
2018.01.22 20:33:29 5: HMLAN_Send: HMLAN1 I:-580A8D
2018.01.22 20:33:29 5: HMLAN_Send: HMLAN1 I:+580A8D,00,01,00
2018.01.22 20:33:29 5: CUL1: dispatch A0D5FA610580A8DF1230506010000::-88.5:CUL1
2018.01.22 20:33:29 4: CUL_Parse: CUL1 A 0D 5F A610 580A8D F12305 06010000E3 -88.5
2018.01.22 20:33:29 5: CUL/RAW: /A0D5FA610580A8DF1230506010000E3
2018.01.22 20:33:27 5: CUL1: dispatch A1413845E5AF47D0000008094AB00000A002D0943FD::-60.5:CUL1
2018.01.22 20:33:27 4: CUL_Parse: CUL1 A 14 13 845E 5AF47D 000000 8094AB00000A002D0943FD1B -60.5
2018.01.22 20:33:27 5: CUL/RAW: /A1413845E5AF47D0000008094AB00000A002D0943FD1B
2018.01.22 20:33:24 5: CUL1: dispatch A0FA486102B1D3A0000000AACED0B0E00::-56:CUL1
2018.01.22 20:33:24 4: CUL_Parse: CUL1 A 0F A4 8610 2B1D3A 000000 0AACED0B0E0024 -56
2018.01.22 20:33:24 5: CUL/RAW: /A0FA486102B1D3A0000000AACED0B0E0024
2018.01.22 20:33:20 5: HMLAN_Send: HMLAN1 I:+5AF44A,00,01,00
2018.01.22 20:33:20 5: CUL1: dispatch A14C8845E5AF44A00000080B4B00004D3006D0938FD::-66:CUL1
2018.01.22 20:33:20 4: CUL_Parse: CUL1 A 14 C8 845E 5AF44A 000000 80B4B00004D3006D0938FD10 -66
2018.01.22 20:33:20 5: CUL/RAW: /A14C8845E5AF44A00000080B4B00004D3006D0938FD10
2018.01.22 20:33:13 5: CUL1: dispatch A0C978670323DEF00000000395A::-67:CUL1
2018.01.22 20:33:13 4: CUL_Parse: CUL1 A 0C 97 8670 323DEF 000000 00395A0E -67
2018.01.22 20:33:13 5: CUL/RAW: /A0C978670323DEF00000000395A0E
2018.01.22 20:33:06 5: SW: As0DF88002F123053FC66E0101C800
2018.01.22 20:33:06 5: CUL 3FC66E dly:95ms
2018.01.22 20:33:06 5: CUL1 sending As0DF88002F123053FC66E0101C800
2018.01.22 20:33:06 5: HMLAN_Send: HMLAN1 I:-3FC66E
2018.01.22 20:33:06 5: HMLAN_Send: HMLAN1 I:+3FC66E,00,01,00
2018.01.22 20:33:06 5: CUL1: dispatch A0CF8A6413FC66EF1230501A100::-77:CUL1
2018.01.22 20:33:06 4: CUL_Parse: CUL1 A 0C F8 A641 3FC66E F12305 01A100FA -77
2018.01.22 20:33:06 5: CUL/RAW: /A0CF8A6413FC66EF1230501A100FA
2018.01.22 20:33:06 5: HMLAN_Parse: HMLAN1 V:03C5 sNo:MEQ0313652 d:37A0AD O:F12305 t:000C0E97 IDcnt:0004 L:1 %
2018.01.22 20:33:06 5: HMLAN/RAW: /HHM-LAN-IF,03C5,MEQ0313652,37A0AD,F12305,000C0E97,0004,01
2018.01.22 20:33:06 5: HMLAN_Send: HMLAN1 I:K
2018.01.22 20:33:00 5: HMLAN1: dispatch A0DF78002F123053FC66E0101C800::-73:HMLAN1
2018.01.22 20:33:00 5: HMLAN_Parse: HMLAN1 R:EF12305 stat:0000 t:000BF901 d:FF r:FFB7 m:F7 8002 F12305 3FC66E 0101C800
2018.01.22 20:33:00 5: HMLAN1: dispatch A0CF7A6413FC66EF1230501A0C8::-66:HMLAN1
2018.01.22 20:33:00 5: HMLAN_Parse: HMLAN1 R:E3FC66E stat:0000 t:000BF87C d:FF r:FFBE m:F7 A641 3FC66E F12305 01A0C8
EF12305,0000,000BF901,FF,FFB7,F78002F123053FC66E0101C800
2018.01.22 20:33:00 5: HMLAN/RAW: /E3FC66E,0000,000BF87C,FF,FFBE,F7A6413FC66EF1230501A0C8
2018.01.22 20:33:00 5: SW: As0DF78002F123053FC66E0101C800
2018.01.22 20:33:00 5: CUL 3FC66E dly:95ms
2018.01.22 20:33:00 5: CUL1 sending As0DF78002F123053FC66E0101C800
2018.01.22 20:33:00 5: HMLAN_Send: HMLAN1 I:-3FC66E
2018.01.22 20:33:00 5: HMLAN_Send: HMLAN1 I:+3FC66E,00,01,00
2018.01.22 20:33:00 5: CUL1: dispatch A0CF7A6413FC66EF1230501A0C8::-74:CUL1
2018.01.22 20:33:00 4: CUL_Parse: CUL1 A 0C F7 A641 3FC66E F12305 01A0C800 -74
2018.01.22 20:33:00 5: CUL/RAW: /A0CF7A6413FC66EF1230501A0C800
Achtung: Ich habe reverseLog aktiviert, also bitte rückwärts lesen. :P
Hallo zusammen,
ich kann zum aktuellen Thema nichts beisteuern, habe aber ebenfalls Probleme mit Disconnects, wenn auch relativ unregelmäßig.
Die sehen dann ungefähr so aus (Disconnect|Init|OK):
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: Event received for HMLAN1 - (msg: cond: init)
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading assignedIDsCnt: 56 report:55
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgLoadCurrent: 14
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgKeepAlive: dlyMax:71.303 bufferMin:-66
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgLoadHistoryAbs: 5min steps: 21/21/22/21/21/21/21/21/21/21/21/22
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading uptime: 006 144:27:24.709
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgParseDly: min:-8267 max:73819 last:125 cnt:46949
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading condition: init
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading Xmit-Events: init:3 disconnected:3 ok:2
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading load: n/a
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading loadLvl: low
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: Event received for HMLAN1 - (msg: cond: ok)
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading assignedIDsCnt: 56 report:0
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgLoadCurrent: 0
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgKeepAlive: dlyMax:71.303 bufferMin:-66
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgLoadHistoryAbs: 5min steps: 21/21/22/21/21/21/21/21/21/21/21/22
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading uptime: 000 00:00:07.907
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgParseDly: min:-8267 max:73819 last:125 cnt:46949
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading condition: ok
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading Xmit-Events: init:3 disconnected:3 ok:3
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading load: n/a
2018.01.21 23:50:32 1: Notify_HMLAN_Connection: HMLAN1: Reading loadLvl: low
2018.01.22 03:05:32 1: Notify_HMLAN_Connection: Event received for HMLAN1 - (msg: disconnected)
2018.01.22 03:05:32 1: Notify_HMLAN_Connection: HMLAN1: Reading assignedIDsCnt: 59
2018.01.22 03:05:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgLoadCurrent: 21
2018.01.22 03:05:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgKeepAlive: dlyMax:71.303 bufferMin:-66
2018.01.22 03:05:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgLoadHistoryAbs: 5min steps: 21/21/22/23/23/23/23/23/23/23/22/22
2018.01.22 03:05:32 1: Notify_HMLAN_Connection: HMLAN1: Reading uptime: 000 03:14:55.629
2018.01.22 03:05:32 1: Notify_HMLAN_Connection: HMLAN1: Reading msgParseDly: min:-8267 max:73819 last:11 cnt:49191
2018.01.22 03:05:32 1: Notify_HMLAN_Connection: HMLAN1: Reading condition: disconnected
2018.01.22 03:05:32 1: Notify_HMLAN_Connection: HMLAN1: Reading Xmit-Events: init:3 disconnected:4 ok:3
2018.01.22 03:05:32 1: Notify_HMLAN_Connection: HMLAN1: Reading load: n/a
2018.01.22 03:05:32 1: Notify_HMLAN_Connection: HMLAN1: Reading loadLvl: low
2018.01.22 03:06:33 1: Notify_HMLAN_Connection: Event received for HMLAN1 - (msg: cond: init)
2018.01.22 03:06:33 1: Notify_HMLAN_Connection: HMLAN1: Reading assignedIDsCnt: 59
2018.01.22 03:06:33 1: Notify_HMLAN_Connection: HMLAN1: Reading msgLoadCurrent: 21
2018.01.22 03:06:33 1: Notify_HMLAN_Connection: HMLAN1: Reading msgKeepAlive: dlyMax:71.303 bufferMin:-66
2018.01.22 03:06:33 1: Notify_HMLAN_Connection: HMLAN1: Reading msgLoadHistoryAbs: 5min steps: 21/21/22/23/23/23/23/23/23/23/22/22
2018.01.22 03:06:33 1: Notify_HMLAN_Connection: HMLAN1: Reading uptime: 000 03:14:55.629
2018.01.22 03:06:33 1: Notify_HMLAN_Connection: HMLAN1: Reading msgParseDly: min:-8267 max:73819 last:11 cnt:49191
2018.01.22 03:06:33 1: Notify_HMLAN_Connection: HMLAN1: Reading condition: init
2018.01.22 03:06:33 1: Notify_HMLAN_Connection: HMLAN1: Reading Xmit-Events: init:4 disconnected:5 ok:3
2018.01.22 03:06:33 1: Notify_HMLAN_Connection: HMLAN1: Reading load: n/a
2018.01.22 03:06:33 1: Notify_HMLAN_Connection: HMLAN1: Reading loadLvl: low
2018.01.22 03:06:34 1: Notify_HMLAN_Connection: Event received for HMLAN1 - (msg: cond: ok)
2018.01.22 03:06:34 1: Notify_HMLAN_Connection: HMLAN1: Reading assignedIDsCnt: 54 report:59
2018.01.22 03:06:34 1: Notify_HMLAN_Connection: HMLAN1: Reading msgLoadCurrent: 21
2018.01.22 03:06:34 1: Notify_HMLAN_Connection: HMLAN1: Reading msgKeepAlive: dlyMax:71.303 bufferMin:-66
2018.01.22 03:06:34 1: Notify_HMLAN_Connection: HMLAN1: Reading msgLoadHistoryAbs: 5min steps: 21/21/22/23/23/23/23/23/23/23/22/22
2018.01.22 03:06:34 1: Notify_HMLAN_Connection: HMLAN1: Reading uptime: 000 03:16:08.682
2018.01.22 03:06:34 1: Notify_HMLAN_Connection: HMLAN1: Reading msgParseDly: min:-8267 max:73819 last:11 cnt:49191
2018.01.22 03:06:34 1: Notify_HMLAN_Connection: HMLAN1: Reading condition: ok
2018.01.22 03:06:34 1: Notify_HMLAN_Connection: HMLAN1: Reading Xmit-Events: init:4 disconnected:5 ok:4
2018.01.22 03:06:34 1: Notify_HMLAN_Connection: HMLAN1: Reading load: n/a
2018.01.22 03:06:34 1: Notify_HMLAN_Connection: HMLAN1: Reading loadLvl: lo
Die Disconnects beziehen sich nur auf die beiden HM-LAN-CFG Adapter.
Ich betreibe ebenfalls eine VCCU mit 2 HM-LAN-CFG und einem HM-UART-PI Module.
Alle drei HM-Interfaces haben als D-HMIdAssigned die HM-ID der VCCU eingetragen.
Nun wollte ich ein VLAN aufbauen um dort die beiden HM-LAN-CFGs reinzuhängen um Fehler durch Multicasts (bspw. meine PV-Wechselrichter) oder SONOS als Störenfried im Netzwerk auszuschließen.
Dort habe ich mich an gängige, im Internet verfügbare, Tutorials angelehnt, bekomme aber kein VLAN zum Laufen. Nutzen wolle ich das vlan Paket (apt-get install vlan).
Konfiguriert habe ich in /etc/network/interfaces folgendes:
# The primary network interface
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
#adding vlan segment for HMLAN
auto eth0.1
iface eth0.1 inet static
address 192.168.10.1
netmask 255.255.255.0
#vlan-raw-device eth0
Mit und ohne Zusatz "vlan-raw-device eth0" kann ich den Rapi (Jessie) unter 192.168.10.1 (natürlich habe ich meinen Rechner in das gleiche Netz gelegt) nicht pingen.
Der RaPi selbst kann sich unter der IP pingen.
Hat jemand diesbezüglich schon Erfahrungen? Kann mein Switch mir diesbezüglich einen Strich durch die Rechnung machen (ich dachte eigentlich nicht).
Danke für Eure Kommentare und viele Grüße,
Marcel
Der Switch muss IEEE 802.1Q beherschen und die Ports müssen entsprechend konfiguriert sein (access oder trunk mode).
Danke für den Hinweis.
Das kann der olle TP-Link SG1024 nicht. Ein Grund mehr endlich auf einen managed Switch umzusteigen.
Werde es jetzt erst einmal mit einem kleinen anderen Switch probieren.
Zitat von: Xguide am 24 Januar 2018, 15:36:03
Danke für den Hinweis.
Das kann der olle TP-Link SG1024 nicht. Ein Grund mehr endlich auf einen managed Switch umzusteigen.
Werde es jetzt erst einmal mit einem kleinen anderen Switch probieren.
Hi,
die Cisco SG300/200er Serie geht End Of Sale ... dadurch kann man diese immer wieder gut bei EBay ergattern und die lassen sich auch relativ einfach per Web Interface managen ...
sollten 100MBit ausreichen bekommt man auch für nen Appel und nen Ei (meine beiden haben 25 gekostet) dort z.B. einen 3560 mit 24Ports mit POE 2 * SFP (Gigabit) als Uplink
Tata, endlich habe ich den richtigen Faden gefunden, denn auch ich habe seit einiger Zeit massive Probleme, sowohl mit dem HM-USB als auch mit dem HM-LAN, beide an VCCU auf einem Raspberry. Ich werde jetzt mal hier alles in Ruhe durchlesen und vielleicht finde ich eine Lösung oder zumindest Verbesserung. Wenn es einfach nur ein nicht merkliches Hintergrundproblem wäre - leider läuft nun die ganze Automatisierung instabil. Mehrmals am Tag schaltet irgend etwas nicht richtig.
Ich habe die disconnects gänzlich beseitigen können. Habe zwei HMLAN-Adapter und einen HMUART (die 19EUR-Platine an einem extra Raspi). Einen HMLAN habe ich auch mit einem managed Switch in ein eigenes vlan gelegt, das war aber nicht die Lösung.
Folgende zeitkritische Geräte/Module habe ich auf eine zweite FHEM-Instanz verlegt und per fhem2fhem verbunden:
SIRD (Lidl-Internetradio)
IPCAM (derzeit 5 Kameras, die bei Events Bilder aufnehmen und per Mail versenden.)
Seitdem hatte ich zwei disconnects in einem halben Jahr. Da hatte dann auch der HMLAN-Adapter von selbst rebootet. Das Ganze läuft übrigens auf einem NUC N3700 (Debian).
Ich ärger mich auch schon die letzten Tag emit den Disconnects rum. Ich hatte nun aber begonnen, die CCU2 via HMCCU einzubinden. Treten die Fehler bei der CCU2 via HMCCU auch auf? Falls nicht, könnte ich die Fehlersuche beim HM-LAN abbrechen.
Hallo zusammen,
ich habe mein VLAN Projekt noch nicht realisieren können, dennoch läuft es jetzt schon eine ganze Weile stabil ohne Verbindungsabbrüche.
Das IPCam Modul habe ich auch im Einsatz und hatte das Modul als Verursacher ebenfalls in Verdacht. Kann es sein, dass sich da mit den letzten Updates etwas in Richtung non-blocking getan hat?
Nur so eine Idee!
Gruß Marcel
Nachdem mein HMLAN inzwischen ab und zu mal von allein neu startet, habe ich am Wochenende die Elkos gewechselt. Das hat aber das Problem nicht ganz beseitigt, heute hat er sich schon wieder spontan neu gestartet. Vielleicht sollte ich mal das Netzteil tauschen? War das schon mal irgendwo der Übeltäter?
Ich habe jetzt ca. 20 Seiten des Beitrags durch gelesen, aber so richitg nicht gefunden was bei mir weiterhilft
Da ich meinen HMLAN an einem zweiten System mal wieder in Betrieb nehmen will habe ich nun die hier beschriebenen Probleme.
Der HMLAN ist mit der Firmware 0.964 ausgestattet.
Ich weiß nicht was ich noch machen soll, dass ich den vernünftig nutzen kann.
Fehler im Log sehen so aus:
2018.11.13 16:45:43 1: HMLAN_Parse: HMLanHaus new condition ok
2018.11.13 16:45:43 1: 10.0.0.45:1000 reappeared (HMLanHaus)
2018.11.13 16:45:43 1: HMLAN_Parse: HMLanHaus new condition init
2018.11.13 16:45:38 1: HMLAN_Parse: HMLanHaus new condition disconnected
2018.11.13 16:45:38 1: 10.0.0.45:1000 disconnected, waiting to reappear (HMLanHaus)
2018.11.13 16:45:38 1: HMLAN_Parse: HMLanHaus new condition disconnected
2018.11.13 16:43:54 1: HMLAN_Parse: HMLanHaus new condition ok
2018.11.13 16:43:54 1: 10.0.0.45:1000 reappeared (HMLanHaus)
2018.11.13 16:43:54 1: HMLAN_Parse: HMLanHaus new condition init
2018.11.13 16:42:44 1: HMLAN_Parse: HMLanHaus new condition disconnected
2018.11.13 16:42:44 1: 10.0.0.45:1000 disconnected, waiting to reappear (HMLanHaus)
2018.11.13 16:42:44 1: HMLAN_Parse: HMLanHaus new condition disconnected
2018.11.13 16:42:15 1: HMLAN_Parse: HMLanHaus new condition ok
2018.11.13 16:42:15 3: HMLanHaus device opened
apptime:
name function max count total average maxDly avgDly TS Max call param Max call
HMLanHaus HMLAN_Ready 3010 2997 136203.36 45.45 0.00 0.00 13.11. 15:18:12 HASH(HMLanHaus)
HMLanHaus HMLAN_Set 3009 855 4150.87 4.85 0.00 0.00 13.11. 16:17:10 HASH(HMLanHaus); HMLanHaus; reopen
WEB_10.0.0.11_60471 FW_Read 71 44 130.90 2.97 0.00 0.00 13.11. 16:46:41 HASH(WEB_10.0.0.11_60471)
tmr-Wunderground_GetStatus HASH(0x5574155d1268) 71 29 475.21 16.39 23.22 5.23 13.11. 14:43:36 HASH(WUweather)
tmr-Weather_GetUpdate HASH(0x557415acfe40) 35 3 105.97 35.32 5.81 3.54 13.11. 16:23:47 HASH(MeinWetter)
tmr-DWD_OpenData::Timer HASH(0x557415323f38) 17 10 134.42 13.44 9.42 6.78 13.11. 14:45:05 HASH(DWD)
HMLanHaus HMLAN_Define 17 3 40.92 13.64 0.00 0.00 13.11. 16:12:46 HASH(HMLanHaus); HMLanHaus HMLAN 10.0.0.40:1000
tmr-HMLAN_KeepAliveCheck keepAliveCk 14 379 549.65 1.45 18.43 3.57 13.11. 16:46:37 keepAliveCk:HMLanHaus
tmr-FRITZBOX_Readout_Start FritzBox100.Readout 12 29 222.62 7.68 11.63 6.01 13.11. 16:23:43 FritzBox100.Readout
HMLanHaus HMLAN_Read 9 1010 2119.47 2.10 0.00 0.00 13.11. 14:45:49 HASH(HMLanHaus)
tmr-UWZ_Start HASH(0x5574160cf098) 7 3 22.68 7.56 8.99 6.31 13.11. 16:23:32 HASH(Unwetterzentrale)
tmr-FRITZBOX_Readout_Start FritzBox101.Readout 7 29 101.38 3.50 15.60 6.80 13.11. 16:33:43 FritzBox101.Readout
tmr-FRITZBOX_Readout_Start FritzBox.Readout 7 29 180.64 6.23 10.33 6.63 13.11. 16:43:43 FritzBox.Readout
tmr-HourCounter_Run VerpassteAnrufe 7 2 11.96 5.98 4.01 3.48 13.11. 15:00:00 VerpassteAnrufe
tmr-PROPLANTA_Start HASH(0x557415c9db40) 6 3 18.09 6.03 4.15 3.45 13.11. 14:23:53 HASH(Proplanta)
tmr-freezemon_ProcessTimer HASH(0x5574183d2bb0) 6 1423 312.60 0.22 3020.79 33.08 13.11. 15:14:37 HASH(pefmon)
mqttiobroker MQTT::Ready 6 11551 1171.30 0.10 0.00 0.00 13.11. 16:08:43 HASH(mqttiobroker)
HMLanHaus HMLAN_Attr 5 9 6.23 0.69 0.00 0.00 13.11. 16:15:05 set; HMLanHaus; dummy; 1
tmr-Twilight_sunpos HASH(0x557418af8728) 5 1 5.60 5.60 2.37 2.37 13.11. 15:33:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557419463e40) 5 1 5.47 5.47 3.44 3.44 13.11. 14:48:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557419ea9e58) 5 1 5.28 5.28 1.77 1.77 13.11. 15:28:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x55741a0ef3f8) 5 1 5.20 5.20 3010.50 3010.50 13.11. 15:58:28 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557419e2b478) 4 1 4.99 4.99 1.43 1.43 13.11. 15:08:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557419ee5e28) 4 1 4.93 4.93 1.63 1.63 13.11. 15:18:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557419d9ee78) 4 1 4.86 4.86 3.49 3.49 13.11. 15:53:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557419e4b7f8) 4 1 4.84 4.84 1.34 1.34 13.11. 15:03:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557418de5a90) 4 1 4.83 4.83 10.16 10.16 13.11. 14:28:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x55741abd3a10) 4 1 4.83 4.83 2.92 2.92 13.11. 16:23:28 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557419768bd0) 4 1 4.80 4.80 1.87 1.87 13.11. 15:43:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x55741a14db20) 4 1 4.78 4.78 4.93 4.93 13.11. 16:33:28 HASH(myTwilight_sunpos)
HMLanHaus HMLAN_Notify 4 1105 160.47 0.15 0.00 0.00 13.11. 14:20:07 HASH(HMLanHaus); HASH(HMLanHaus)
tmr-Twilight_sunpos HASH(0x557419c03bc8) 4 1 4.72 4.72 3.60 3.60 13.11. 16:28:28 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557418e21610) 4 1 4.61 4.61 5.83 5.83 13.11. 16:03:28 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x55741975f648) 4 1 4.59 4.59 6.35 6.35 13.11. 15:48:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557418fd9c70) 4 1 4.58 4.58 1.70 1.70 13.11. 15:23:25 HASH(myTwilight_sunpos)
tmr-Twilight_fireEvent HASH(0x557416513eb8) 4 1 4.58 4.58 2.59 2.59 13.11. 15:49:43 HASH(myTwilight_ss_weather)
tmr-HTTPMOD_GetUpdate update 4 20 58.71 2.94 6.98 2.90 13.11. 14:53:28 update:Star
tmr-Twilight_sunpos HASH(0x5574193f8ab0) 4 1 4.55 4.55 5.68 5.68 13.11. 14:58:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x55741a0efc50) 4 1 4.52 4.52 3.12 3.12 13.11. 16:18:28 HASH(myTwilight_sunpos)
tmr-RainTMC_ScheduleUpdate HASH(0x55741589e320) 4 36 130.46 3.62 13.22 4.97 13.11. 14:35:24 HASH(Regenvorhersage)
tmr-Twilight_sunpos HASH(0x557418e1ac48) 4 1 4.48 4.48 7.70 7.70 13.11. 14:33:25 HASH(myTwilight_sunpos)
apptime maxDly:
name function max count total average maxDly avgDly TS Max call param Max call
tmr-Twilight_fireEvent HASH(0x557416513f90) 0 1 0.13 0.13 23300956.61 23300956.61 13.11. 14:49:43 HASH(myTwilight_sr_weather)
tmr-freezemon_ProcessTimer HASH(0x5574183d2bb0) 6 1423 312.60 0.22 3020.79 33.08 13.11. 15:14:37 HASH(pefmon)
tmr-HMLAN_KeepAlive keepAlive 1 288 204.46 0.71 3016.73 15.93 13.11. 14:23:54 keepAlive:HMLanHaus
tmr-Twilight_sunpos HASH(0x55741a0ef3f8) 5 1 5.20 5.20 3010.50 3010.50 13.11. 15:58:28 HASH(myTwilight_sunpos)
tmr-FW_closeInactiveClients 0 2 152 99.85 0.66 3009.93 46.30 13.11. 16:16:43 0
tmr-Wunderground_GetStatus HASH(0x5574155d1268) 71 30 512.46 17.08 23.22 5.17 13.11. 14:43:36 HASH(WUweather)
tmr-BlockingKill HASH_unnamed 0 40 1.24 0.03 22.48 6.73 13.11. 16:46:05 HASH(0x557419736e90)
tmr-HMLAN_KeepAliveCheck keepAliveCk 14 390 562.43 1.44 18.43 3.56 13.11. 16:46:37 keepAliveCk:HMLanHaus
tmr-FRITZBOX_Readout_Start FritzBox101.Readout 7 30 104.67 3.49 15.60 6.68 13.11. 16:33:43 FritzBox101.Readout
tmr-RainTMC_ScheduleUpdate HASH(0x55741589e320) 4 38 137.64 3.62 13.22 4.90 13.11. 14:35:24 HASH(Regenvorhersage)
tmr-FRITZBOX_Readout_Start FritzBox100.Readout 12 30 232.50 7.75 11.63 5.89 13.11. 16:23:43 FritzBox100.Readout
tmr-FRITZBOX_Readout_Start FritzBox.Readout 7 30 186.18 6.21 10.33 6.62 13.11. 16:43:43 FritzBox.Readout
tmr-Twilight_sunpos HASH(0x557418de5a90) 4 1 4.83 4.83 10.16 10.16 13.11. 14:28:25 HASH(myTwilight_sunpos)
tmr-DWD_OpenData::Timer HASH(0x557415323f38) 17 10 134.42 13.44 9.42 6.78 13.11. 14:45:05 HASH(DWD)
tmr-UWZ_Start HASH(0x5574160cf098) 7 3 22.68 7.56 8.99 6.31 13.11. 16:23:32 HASH(Unwetterzentrale)
tmr-Twilight_sunpos HASH(0x55741a11c530) 3 1 3.86 3.86 8.94 8.94 13.11. 14:53:25 HASH(myTwilight_sunpos)
tmr-CUL_HM_ActCheck ActionDetector 0 15 11.42 0.76 8.12 4.52 13.11. 14:33:23 ActionDetector
tmr-Twilight_sunpos HASH(0x5574193838c8) 4 1 4.45 4.45 8.10 8.10 13.11. 14:38:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557418e1ac48) 4 1 4.48 4.48 7.70 7.70 13.11. 14:33:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557419a1ea40) 3 1 3.88 3.88 7.42 7.42 13.11. 16:38:28 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557419d449b0) 3 1 3.84 3.84 7.20 7.20 13.11. 16:43:28 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557418afd0b8) 3 1 3.88 3.88 7.16 7.16 13.11. 16:13:28 HASH(myTwilight_sunpos)
tmr-HTTPMOD_GetUpdate update 4 20 58.71 2.94 6.98 2.90 13.11. 14:53:28 update:Star
tmr-Twilight_sunpos HASH(0x55741975f648) 4 1 4.59 4.59 6.35 6.35 13.11. 15:48:25 HASH(myTwilight_sunpos)
tmr-Twilight_fireEvent HASH(0x5574165140e0) 3 1 3.92 3.92 6.01 6.01 13.11. 16:26:10 HASH(myTwilight_ss)
tmr-Twilight_sunpos HASH(0x557418e21610) 4 1 4.61 4.61 5.83 5.83 13.11. 16:03:28 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557419d86788) 4 1 4.16 4.16 5.81 5.81 13.11. 16:08:28 HASH(myTwilight_sunpos)
tmr-Weather_GetUpdate HASH(0x557415acfe40) 35 3 105.97 35.32 5.81 3.54 13.11. 16:23:47 HASH(MeinWetter)
tmr-Twilight_sunpos HASH(0x5574193f8ab0) 4 1 4.55 4.55 5.68 5.68 13.11. 14:58:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x5574193f8d68) 4 1 4.47 4.47 5.62 5.62 13.11. 14:43:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x55741a14db20) 4 1 4.78 4.78 4.93 4.93 13.11. 16:33:28 HASH(myTwilight_sunpos)
tmr-Twilight_WeatherTimerUpdate HASH(0x5574165135e8) 3 1 3.23 3.23 4.79 4.79 13.11. 14:49:43 HASH(myTwilight_weather)
tmr-PROPLANTA_Start HASH(0x557415c9db40) 6 3 18.09 6.03 4.15 3.45 13.11. 14:23:53 HASH(Proplanta)
tmr-Twilight_sunpos HASH(0x557419769410) 4 1 4.75 4.75 4.07 4.07 13.11. 16:48:28 HASH(myTwilight_sunpos)
tmr-HourCounter_Run VerpassteAnrufe 7 2 11.96 5.98 4.01 3.48 13.11. 15:00:00 VerpassteAnrufe
tmr-Twilight_sunpos HASH(0x557419c03bc8) 4 1 4.72 4.72 3.60 3.60 13.11. 16:28:28 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x557419d9ee78) 4 1 4.86 4.86 3.49 3.49 13.11. 15:53:25 HASH(myTwilight_sunpos)
tmr-Twilight_fireEvent HASH(0x5574165145d0) 4 1 4.29 4.29 3.46 3.46 13.11. 16:02:46 HASH(myTwilight_ss_indoor)
tmr-Twilight_sunpos HASH(0x557419463e40) 5 1 5.47 5.47 3.44 3.44 13.11. 14:48:25 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x55741a0efc50) 4 1 4.52 4.52 3.12 3.12 13.11. 16:18:28 HASH(myTwilight_sunpos)
tmr-Twilight_sunpos HASH(0x55741abd3a10) 4 1 4.83 4.83 2.92 2.92 13.11. 16:23:28 HASH(myTwilight_sunpos)
als erstes würde ich fw 0.965 flashen.
ich bekomme ja keine andere mit dem heute runter geladenem Firmware Tool für den HMLAN
Diese habe ich heute herunter geladen "HM-Firmware-Update-Tool_V1_2_eQ-3_160211" mit diesem Programm kam die 0.964 hatte vorher die 0.952 drauf
Nochmal ne kurze Rückmeldung von mir, in dem Moment wo ich hier heute etwas schreibe, hat der HMLAN wohl etwas Angst bekommen und ich habe seit
uptime 000 00:44:56.055 keine disconnected mehr... das ist doch kaum zu glauben :-\
egal, nicht ablenken lassen. nur 0.965 "zählt". ;)
dein download scheint richtig zu sein, aber irgendwas läuft falsch. hast du alle alten eq3 sw vorher gelöscht/deinstalliert? readme datei gelesen?
ja ich habe das aus der PDF Datei entnommen, denn erst hatte er einen Fehler gezeigt und danach wurde die 0.964 drauf gespielt.
Ich müßte dann wohl das file hmlanif.enc für die neue Version haben.
EDIT://
uptime 000 19:03:21.275
da lasse ich es erst mal so, bin ja zufrieden das er läuft
wie gesagt, du nutzt sicherlich nicht das entsprechende program aus dem richtigen ordner.
Siehe WIKI: https://wiki.fhem.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter#Firmware
Extra eingepflegt, klappt wunderbar.
Sachstand meines HMLAN firmware 0.965.
Nachdem die Abstände zwischen disconnected / connected immer öfters am Tag
auftauchten, war die Überlegung was tun.
Unter anderem dachte ich über einen Tausch der Kondensatoren nach.
Nach öffnen des Gehäuses viel auf, dass 2 tote Fliegen ziemlich hartnäckig an der Platine hingen.
Also abgekratzt und die Platine mit Spiritus gereinigt, testweise wieder eingebaut und HMLAN in Betrieb genommen.
Seitdem kein disconnect mehr.
uptime --> 002 66:59:25.942
Vielleicht hilft's bei einem oder anderem auch?
das ist genau das klassische Debugging ;-)
Zitat von: frank am 14 November 2018, 12:53:03
wie gesagt, du nutzt sicherlich nicht das entsprechende program aus dem richtigen ordner.
EDIT:// Ok ich habe nun die 0.965 gefunden mal schauen ob er damit besser läuft
welches nutzt du denn ich denke ich bräuchte ja nur die 0965 einspielen in mein Programm.
Ich habe nur dieses gefunden.Ich frage deshalb ich habe den HMLAN jetzt einmal umgelegt und schon geht das Theater wieder los, nicht so viele disconnected wie vorher aber genug :-\
Zitat von: moonsorrox am 17 November 2018, 17:10:44
EDIT:// Ok ich habe nun die 0.965 gefunden mal schauen ob er damit besser läuft
welches nutzt du denn ich denke ich bräuchte ja nur die 0965 einspielen in mein Programm.
Ich habe nur dieses gefunden.
Ich frage deshalb ich habe den HMLAN jetzt einmal umgelegt und schon geht das Theater wieder los, nicht so viele disconnected wie vorher aber genug :-\
1. Update
2. wenn er dann immer abschmiert --> Kondensatoren
Hallo zusammen,
LÖSUNG!!!
ich melde mich hier mal da ich seit ca. 4 Wochen dasselbe Problem mit meinem HM-CFG-LAN habe. Ich habe diesen Thread bestimmt zwei mal gelesen... Ich schildere kurz mein Problem, bevor ich zur Ursache für das Problem komme.
Problem: Seit Anfang November Disconnects im 2-5 Minuten Takt
Ursachenforschung:
- Apptime
- Netzwerk
- Austausch von Netzwerkkomponenten
- Wireshark
- Protokoll Sniffing
Ich möchte hier nicht Haarklein erläutern wie viel zeit und Nerven mich dieser Scheiß gekostet hat.
Ursache gefunden durch:
Ich habe mein Netzwerk komplett im Keller nachgebaut um Leitungswege etc. auszuschließen. Hiernach hatte mein HMLAN Adapter für mehr als zwei Tage keine einzigen Reconnects mehr. Daher dachte ich, dass es die Verbindung (LAN Cat6 Kabel) in das Wohnzimmer ist, wo der HMLAN Adapter normalerweise steht. Falsch.
Ich habe nun den gesamten Aufbau im Keller samt Kabeltrommel, Switch und HMLAN Adapter mit ins Wohnzimmer genommen (Ich habe nichts ausgestöpselt. Und plötzlich hatte ich nach zwei problemlosen Tagen im Keller wieder permanente Reconnects.
Ursache: Äußere Einflüsse durch andere Funkfrequenzen auf den HMLAN Adapter. Grund: Mein Keller ist mehr oder weniger abgeschirmt. Ich habe die Kellerdecke im letzten Jahr mit Alu-Kaschierten Dämmplatten gedämmt.
Ich habe das Gefühl, dass es evtl. mit Homematic IP zusammen hängt. Ich selber habe keine HmIP Geräte, aber vermutlich irgendein Nachbar. Ich meine da mal etwas gelesen zu haben, finde es aber nicht.
Mein aktueller Firmwarestand ist noch 0.964. Ich konnte ihn aber nicht Updaten, weil ich keinen Zugriff auf ihn hatte. Ich denke, dass das auch etwas mit den ständigen Verbindungsabbrüchen zu tun hat. Ich werde die tage versuchen ein Update auf 0.965 durchzuführen. Im Keller wohlgemerkt. Danach berichte ich nochmal.
Ich hoffe, dass ich einigen einen Denkanstoß in eine andere Richtung geben kann, da dieser Fehler nicht wirklich trivial ist. Ich war der Verzweiflung nah, da sehr viele Dinge physikalisch gar nicht logisch waren.
Ich habe sogar zum testen den neuen HMLANGW gekauft. Nach dem Firmware und LAN Update hatte ich aber dieselben Fehler im Log. Deshalb dachte ich immer dass mein Netzwerk das Problem ist. Ich habe das HMLANGW wieder zurück geschickt und mich gar nicht mehr wirklich mit dem HMLANGW Auseinandergesetzt. Aber warum hatte das HMLANGW dieselben Probleme trotz Update?
Für weitere Diskussionen stehe ich offen.
Gruß
Soweit ich mich erinnere sind das bekannte Probleme mit IP die durch dir 965-er Firmware behoben (oder zumindest stark reduziert) werden.
Zitat
Ursache: Äußere Einflüsse durch andere Funkfrequenzen auf den HMLAN Adapter...
Beliebte Störquellen sind auch DECT-Telefone.
Wenn Du den Start der Probleme zeitlich eingrenzen kannst, stellt sich die Frage, was sich Ende Oktober / Anfang November geändert hat.
Dabei alles in Erwägung ziehen... räumliche oder technische Änderungen, neue Geräte, Defekte an vorhandenen Geräten usw.
Außerdem die Firmware auf die 0.965 updaten.
Hallo nochmal,
also nachdem ich meinen HMLAN Adapter auf 0.965 aktualisiert habe läuft alles wieder ohne Ausfälle. (1x reconnect nach 52h --> ok)
Das größte Problem war in der Tat, dass ich Aufgrund der Ausfälle auch nicht updaten konnte.
Danke für die vielen Tipps hier im Thread! Ein Nachbar hat sich scheinbar zu Weihnachten ein IP Gerät gegönnt, das mein HMLAN außer tritt gebracht hat.
Update der FW war mit einem aktuellen Windows 10 nicht machbar. Mit einem alten geliehenen Laptop mit WinXP hat es funktioniert. Sehr wichtig war auch der Tipp, dass man alle Netzwerkinterfaces, die nicht benötigt werden, deaktiviert werden muss.
Insofern funktioniert jetzt wieder alles. Ich muss mir aber Gedanken machen, das HMLAN gegen zB eine CCU3 zu tauschen, da ich nicht wissen will, was los ist, wenn der Adapter bzw. die Elkos den Geist aufgeben :/
Ich muss das jetzt kurz loswerden...
Einer meiner HMLAN CFG war seit ca. 2 Wochen auch ständig auf disconnected. Gemerkt habe ich das durch permanente Fehlalarme durch
getriggerte Notifies. Ich probierte auch alles, ohne Lösung. Strom ab, Netzwerkkabel getauscht, Fritte update, Fhem update und natürlich
update auf 0.965, da ich vermutete ein Nachbar hat evtl. zu Weihnachten ein Homematic IP Starterset bekommen :D
Bei der kleinen Bucht günstig einen CFG nachgekauft, konfiguriert. Und was fällt mir da auf beim Wechsel ins FritzBox Menü ?
Auf derselben IP wie mein "gestörter" HMLan tumelt sich das Tablet, das ich meiner Frau zu Weihnachten geschenkt habe ::)
Ich hatte vor Jahren meinen HMlans eine statische IP verpasst.
IP des Tablets geändert, alles wieder okay.
Selber schuld ;)
Zitat von: Wuppi68 am 17 November 2018, 20:56:12
1. Update
2. wenn er dann immer abschmiert --> Kondensatoren
Hallo Ralf,
Da es bei mir mittlerweile auch Probleme gibt, mach ich mich mal ans Werk.
Update ist vorhanden, d.h. hier kann ich nichts weiter machen.
"2. wenn er dann immer abschmiert --> Kondensatoren"
Es gibt insgesamt 4 Kondensatoren, die beiden dicken haben die Aufschrift: 25V / 100µF, Fa. Nichicon
Müssen es genau diese sein, oder zumindest 25V / 100µF?
Ich hätte 2 verschiedene Sorten zur Verfügung, und zwar 25V / 470µF - gehen die auch, gerade noch oder evtl sogar besser?
Ein Typ hat den gleichen Durchmesser, Länge, ein anderer ist deutlich dünner aber auch 25V / 470µF.
Bevor neue bestelle, dann wieder im 20-50iger Pack, würde ich gerne deine/eure Meinung hören.
Vielen Dank und viele Grüße
Gisbert
https://forum.fhem.de/index.php/topic,101031.0.html (https://forum.fhem.de/index.php/topic,101031.0.html)
Hallo Fridolin,
schon mal vielen Dank für deinen Hinweis. Da ich das Teil schon geöffnet habe, waren mir diese Infos schon bekannt.
Ich hätte aber noch 2 Fragen:
- Kann man die beiden großen Kondensatoren gegen welche mit 25V / 470 uF tauschen?
- Ist es notwendig oder wenigstens empfehlenswert auch die beiden kleinen Elkos zu tauschen?
Viele Grüße Gisbert
Hallo Gisbert,
ich kann deine Fragen nicht direkt beantworten. Aber ich habe für die 4 Elkos zusammen ca. 1,40€ bezahlt. Bei dem Preis für eine einmalige Sache würde ich keine Experimente machen. Und wenn ich schon dabei bin, dann tausche ich gleich alle vier aus.
Man weiß nicht, welche Funktion die einzelnen Elkos haben, da kein Schaltbild vorliegt. Aber auch mit Schaltbild würde ich mir das nicht zutrauen.
Gruß, Fridolin
Hallo Fridolin,
das ist ja keine Frage bei den Kosten, aber schon, um die richtigen Kondensatoren zur Verfügung zu haben.
Ich hab's jetzt mal gewagt und die 25V / 470 µF (gleiche Bauform wie die die vorhandenen) reinzubraten.
Das Gerät funktioniert damit, ob die disconnects jetzt besser werden, muss ich dann mal beobachten.
Viele Grüße Gisbert
Edit: bei den beiden kleinen Kondensatoren hatte ich nichts vergleichbares da, d.h. die sind jetzt noch drin.
Hallo,
das HMLAN funktioniert zwar mit den 25V/470 µF-Kondensatoren als Ersatz für die beiden größeren Kondensatoren, aber die disconnects kommen nach wie vor alle 20-30 Minuten rein.
Das hat demnach noch keine wirkliche Verbesserung gebracht.
Viele Grüße Gisbert
Zitat von: Gisbert am 23 Juni 2019, 13:49:00
Hallo,
das HMLAN funktioniert zwar mit den 25V/470 µF-Kondensatoren als Ersatz für die beiden größeren Kondensatoren, aber die disconnects kommen nach wie vor alle 20-30 Minuten rein.
Das hat demnach noch keine wirkliche Verbesserung gebracht.
Viele Grüße Gisbert
Hallo Gisbert,
so aus dem bauch raus habe die Elkos keine zeitkritischen Funktionen, sondern dienen wegen der großen Kapazitäten zum stabilisieren der Spannung. Ein Austausch - zur not auch einen größeren - sollte dem also nicht im Wege stehen
Hallo,
HMLAN und disconnect - dafür könnte man mittlerweile ein eigenes Unterforum aufmachen.
Ich hab meinen gestern in die ewigen Jagdgründe geschickt, nachdem er ein paar Wochen auf der Intensivstation gepäppelt wurde.
Zwischenzeitlich hatte ich es geschafft nur ganz wenige disconnects zu bekommen, indem ich die Datenrate am Switch auf 10 Mbit gesenkt hatte. Das hat auch einige Monate richtig gut funktioniert, mit weniger als einem disconnect pro Tag. Seit einigen Wochen fing es wieder an, pro Stunde 2-4 disconnects.
Ich war's jetzt leid und habe einen HM-MOD-UART (mit ESP8266 und esplink) aufgesetzt und zur VCUU hinzugefügt.
Bei den Homematic-Devices habe ich das neue Gateway in die IOgrp eingetragen und den HMLAN-Adapter in der VCCU gelöscht - ich hoffe das war der richtige Weg.
Augenscheinlich läuft noch alles, aber ich bekomme im HMinfo-Modul folgende Ausgabe bei configCheck:
configCheck done:
missing register list
Handsender.04: RegL_01.
Haustuer.Licht: RegL_00.,RegL_01.
TH.Haushaltsraum: RegL_00.
TH.Kuhlmannweg8: RegL_00.
Wassermelder: RegL_00.,RegL_01.
peer list incomplete. Use getConfig to read it.
incomplete: Wassermelder:
no IO device assigned
Handsender
PairedTo missing/unknown
Haustuer.Licht
TH.Haushaltsraum
TH.Kuhlmannweg8
Muss ich Gedanken oder gar Sorgen machen?
Viele Grüße Gisbert
Ja :)
Wenn die IOgrp nur VCCU war - hätte alles so bleiben können.
Zitatno IO device assigned
Handsender
ist auf alle Fälle Mist, also schau was als IOgrp steht und ob IODev gelöscht ist - das wäre nicht gut!!!
ZitatPairedTo missing/unknown
Haustuer.Licht
TH.Haushaltsraum
TH.Kuhlmannweg8
die musst Du bez. Pairing kontrollieren und ev. nochmal pairen (nix löschen einfach drüber).
Der Rest wird sich allein klären.
Gruß Otto
Hallo Otto,
es sieht jetzt so aus:
configCheck done:
missing register list
Handsender.04: RegL_01.
Haustuer.Licht: RegL_00.,RegL_01.
TH.Haushaltsraum: RegL_00.
TH.Kuhlmannweg8: RegL_00.
Wassermelder: RegL_00.,RegL_01.
Register changes pending
Haustuer.Licht
TH.Haushaltsraum
TH.Kuhlmannweg8
peer list incomplete. Use getConfig to read it.
incomplete: Wassermelder:ZitatDer Rest wird sich allein klären.
Muss ich dann nichts anderes mehr machen?
Viele Grüße Gisbert
Hallo Gisbert,
bei Homematic hilft manchmal die Zeit :)
Du kannst alles "klären" wenn Du bei den Batteriegeräten mal den config Taster drückst (manchmal hilft auch nur "benutzen") oder eben getConfig bei den Geräten aber eben auch wieder bei Batteriegeräten die Datenübertragung anschubsen.
In schwierigen Fällen: Geduld, Ruhe bewahren, die obigen Schritte und vielleicht vorher clear msgEvents ausführen.
Gruß Otto
und vielleicht noch ein paar gebete und opfergaben für den wlan gott. :)
Zitat von: frank am 01 Mai 2020, 23:32:36
und vielleicht noch ein paar gebete und opfergaben für den wlan gott. :)
Hallo frank,
Homematic ist eine zickige Angelegenheit, und die beiden Außen-Temperatur/Feuchtemesser wurden erfolgreich (wieder) gepairt - danach haben sie über Nacht den Dienst eingestellt.
Na toll, dann wieder raus, an der Rückseite gefummelt, bis man den config-Knopf gefunden hat; danach ging es beim ersten, den zweiten muss ich noch bezirzen.
Dieses Pairen und diese 100,000 Details sind dermaßen kompliziert geregelt, als User interessiert mich das herzlich begrenzt. Und dann dieser Außensensor, der Entwickler, der das Batteriefach und den config-Knopf auf die fast nicht zugängliche Rückseite gelegt hat, gehört sonderbehandelt, na gut für ihn gelten auch Menschenrechte, aber hassen tue ich ihn trotzdem, das musste jetzt zum wiederholten Mal raus.
Wünschenswert wäre eine batterieschonende Arbeitsweise wie bei Homematic und ein einfaches "Pairen" wie bei einer Wlan-Kopplung.
Viele Grüße Gisbert
ZitatAußen-Temperatur/Feuchtemesser
HM-WDS10-TH-O
Sollte doch auch dir inzwischen bekannt sein, dass die einen FirmwareBug haben, gerade bezüglich nach getConfig und pairen.
und dann ist er anscheinend tot, und meldet keine Temp/Hum Werte mehr.
https://forum.fhem.de/index.php/topic,91905.msg844194.html#msg844194 (https://forum.fhem.de/index.php/topic,91905.msg844194.html#msg844194)
hatte doch den Beitrag mit dir wieder gefunden
Hallo fhem-hm-knecht,
danke für die Erinnerung und Verlinkung, ja ich konnte mich dumpf an die Aktion erinnern, aber an keine Details.
Hier ging es ja um die disconnects beim HMLAN-Adapter, welches dann die anderen Probleme nach sich gezogen hat. Da ich einen von beiden Sensoren für die Steuerung meiner Heizung benötige (der andere ist baugleich, hängt aber innen), ist heute morgen aufgefallen, dass die Heizung wegen fehlendem, aktuellem Außenwert nicht lief.
Mittlerweile laufen die beiden Sensoren wieder, und es ist immer wieder schön sich mit den gleichen Problemen rumzuplagen. Einen Wassermelder muss ich noch etwas betrommeln, sonst sind alle Homematic-Devices wieder unauffällig.
Den Ausfall des einzigen Sensors habe ich mal als Anlass genommen, diese Temperaturmessung redundand zu gestalten. Da ich diverse Wettermodule benutze, ermittele ich aus allen verfügbaren Daten einen Minimalwert, wobei ich dann noch darauf achte, dass alle Werte aktuell sind, die für die Ermittelung des Minimalwertes benutzt werden.
Das ganze ist in eine sub in 99_myUtils.pm (bzw. in meinem Fall in einer eigenen 99_myUtils) ausgelagert und wird alle 2.5 Minuten abgefragt. Wichtig ist, dass alle abgefragten Devices ein reading <temperature> haben, notfalls wird eins per userReadings erzeugt.
sub:
sub min_temp() {
my $minTemp=50;
my $mindev="";
foreach my $device (qw(DEVICE1 DEVICE2 DEVICE3 DEVICE4 ... usw)) {
my $temperature = ReadingsNum($device, "temperature", 0);
my $age = ReadingsAge($device, "temperature", 0);
if($age <= 1200 and $temperature < $minTemp) {
$minTemp=$temperature;
$mindev=$device;
}
}
return $minTemp;
}
Abfrage alle 2.5 Minuten:
defmod myTemperature at +*00:02:30 {min_temp()}
attr myTemperature icon temp_temperature
attr myTemperature room Weather
attr myTemperature stateFormat state<br>\
temperature: mytemp°C
attr myTemperature userReadings mytemp {round(min_temp(),1)}
attr myTemperature verbose 0
Viele Grüße Gisbert
Liebe Leute,
dies ist nicht wirklich eine Antwort auf den letzten Eintrag aber ich habe durch viel Recherche eine neue Erkenntnis:
Vielleicht bin ich ja einer der letzten, die das Problem mit dem Disconnect hatten, aber falls nicht, möchte ich hier gern meine Erfahrung und Lösung (-> Update!) posten.
Eine temporäre (!) Homematic IP(!) Installation hat das Disconnecten des HMLANs ausgelöst.
Ein Update des HMLANs von 0.964 auf 0.965 hat bei mir Abhilfe gebracht !
Interessante Erkenntnis: Ein Homematic IP-System, welches nur einen einzigen Tag hier zum Testen installiert war (seitdem räumlich und netzwerktechnisch getrennt!), hat den HMLAN zum ständigen Disconnecten gebracht... Auf sowas muss man erstmal kommen.
Ich habe das Update gemacht (wie hier beschrieben: https://wiki.fhem.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter bzw. hier als Downloadlink: https://www.eq-3.de/downloads/software/firmware_update_tool/hm-firmware-update-tool_v1_2_eq-3_160211.zip)
Hat inklusive Updaten des HMLANs selbst keine 5 Minuten gedauert.
Seidem habe ich keine Disconnects mehr :-)
Ich hoffe, ich kann mit dieser Erkenntnis noch anderen Leuten helfen !
Viele Grüße
Zitat von: tobiwan am 02 November 2022, 15:26:41
Eine temporäre (!) Homematic IP(!) Installation hat das Disconnecten des HMLANs ausgelöst.
Ein Update des HMLANs von 0.964 auf 0.965 hat bei mir Abhilfe gebracht !
...
Seidem habe ich keine Disconnects mehr :-)
Hier auch. Seit ich eine Rasperrymatic im Netzwerk habe, ist mein HMLAN Amok gelaufen. Mit der 0.965 war sofort Ruhe.
Allerdings hat das Updatetool den HMLAN nur von einem Win7-PC aus gefunden. Mit Win10 hatte ich keine Chance.
Zitat von: tobiwan am 02 November 2022, 15:26:41
Eine temporäre (!) Homematic IP(!) Installation hat das Disconnecten des HMLANs ausgelöst.
Ein Update des HMLANs von 0.964 auf 0.965 hat bei mir Abhilfe gebracht !
alter hut.
https://forum.fhem.de/index.php/topic,63702.0.html (https://forum.fhem.de/index.php/topic,63702.0.html)