Hallo,
um den Empfang einiger weiter entfernten HM-Sendern zu verbessern habe ich vor einiger Zeit ein zweites HMLAN eingerichtet ... genauer: zuerst einen VCCU mit mit 1. HMLAN konfiguriert und dann den 2. HMLAN hinzugefügt.
Prinzipiell funktioniert es, aber ich bekomme sehr häufig diosconnects vom 2. HMLAN. Der Firmwareupdate von 0.964 auf 0.965 für den "neuen" HMLAN sträubte sich etwas bis ich den HMLAN direkt an das Netzwerksegment des PC mit dem Konfigurationsprogramm gelegt habe.
Die Disconnects kommen weiter, und es sind keien Reboots des HMLAN.
Wenn ich mir die beiden HMLAN s ansehe, gibt es ein paar Unterschiede ... warum? z.B. warum gibt es bei HMLAN1 eine owner_CCU und beim HMLAN2 nicht?
Internals:
CHANGED
DEF 192.168.1.42:1000
DeviceName 192.168.1.42:1000
FD 80
HMLAN1_MSGCNT 115048
HMLAN1_TIME 2018-05-16 09:58:01
IFmodel LAN
NAME HMLAN1
NR 3
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG E3422B5,0000,0A0610A2,FF,FFB4,68A45F3422B52AEDA283B1F40053FD03CF08B702
RSSI -76
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 24
msgKeepAlive dlyMax:702.591 bufferMin:-697
msgLoadCurrent 4
msgLoadHistoryAbs 5min steps: 4/4/4/4/4/4/4/3/4/4/3/3
msgParseDly min:-20025 max:795813 last:10 cnt:112264
owner 2AEDA2
owner_CCU VCCU
uptime 001 46:42:49.634
READINGS:
2018-05-09 13:14:17 D-HMIdAssigned 2AEDA2
2018-05-09 13:14:17 D-HMIdOriginal 2BA0A8
2018-05-09 13:14:17 D-firmware 0.965
2018-05-09 13:14:17 D-serialNr LEQ0579416
2018-05-14 11:16:39 Xmit-Events ok:2 init:2 disconnected:3
2018-05-14 11:16:39 cond ok
2018-05-16 09:57:55 loadLvl low
2018-05-14 11:03:59 prot_disconnected last
2016-04-29 12:07:24 prot_dummy last
2018-05-14 11:16:35 prot_init last
2017-10-17 03:47:33 prot_keepAlive last
2018-05-14 11:16:39 prot_ok last
2017-03-20 08:22:23 prot_timeout last
2018-05-14 11:16:35 state opened
2018-05-16 09:57:55 xyz 46:42
helper:
assIdCnt 24
assIdRep 24
info 03C5,LEQ0579416,2BA0A8,2AEDA2
setTime 46583
cnd:
0 2
253 3
255 2
dly:
cnt 112264
lst 10
max 795813
min -20025
ids:
2866E8:
cfg +2866E8,00,00,00
chn 01
flg 0
msg
name Trockner
to 1525864499.67678
2BBF2B:
cfg +2BBF2B,00,00,00
name Aussen
2C914A:
cfg +2C914A,00,00,00
chn 01
flg 0
msg
name Spuel
to 1525864474.69035
2C918E:
cfg +2C918E,00,00,00
chn 01
flg 0
msg
name Buero
to 1525864465.07894
2DB07C:
cfg +2DB07C,00,00,00
chn 01
flg 0
msg
name Aqua
to 1525864464.03705
2DD75A:
cfg +2DD75A,00,00,00
chn 01
flg 0
msg
name UnterT
to 1525864505.25593
2E0FA7:
cfg +2E0FA7,00,00,00
chn 01
flg 0
msg
name Waschm
to 1525864513.08311
3141E8:
cfg +3141E8,00,00,00
chn 02
flg 0
msg
name Innen4
to 1526428512.91168
3422B5:
cfg +3422B5,00,00,00
chn 01
flg 0
msg
name Bett
to 1525864464.32829
34B012:
cfg +34B012,00,00,00
chn 02
flg 0
msg
name Innen
to 1526440977.73781
3505E8:
cfg +3505E8,00,00,00
chn 01
flg 0
msg
name Kontakt
to 1526395250.76213
35A39F:
cfg +35A39F,00,00,00
chn 02
flg 0
msg
name Innen2
to 1526430082.87713
35B60F:
cfg +35B60F,00,00,00
chn 02
flg 0
msg
name Innen3
to 1526378284.28253
39CBFA:
cfg +39CBFA,00,00,00
name Remote
3F3FA6:
cfg +3F3FA6,00,00,00
chn 02
flg 0
msg
name Innen5
to 1526388964.25737
41FEFE:
cfg +41FEFE,00,00,00
chn 01
flg 0
msg
name Rollade
to 1525864467.11155
42002F:
cfg +42002F,00,00,00
chn 01
flg 0
msg
name Rollade2
to 1525864469.25237
4D106F:
cfg +4D106F,00,00,00
chn 02
flg 0
msg
name HM_4D106F
to 1525864945.44518
4EC040:
cfg +4EC040,00,00,00
name HM_4EC040
4F862E:
cfg +4F862E,00,00,00
chn 01
flg 0
msg
name RolladeOben
to 1525864472.55541
52D357:
cfg +52D357,00,00,00
chn 02
flg 0
msg
name Innen6
to 1526395931.07826
52D39E:
cfg +52D39E,00,00,00
chn 02
flg 0
msg
name Innen7
to 1526453244.30242
56C871:
cfg +56C871,00,00,00
chn 01
flg 0
msg
name Radio
to 1525864466.09802
56C894:
cfg +56C894,00,00,00
chn 01
flg 0
msg
name TV
to 1525864492.86265
k:
BufMin -697
DlyMax 702.591
Next 1526457500.2208
Start 1526457475.2208
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 4
loadNo 11
scnt 4
ald:
4
4
4
4
4
4
4
3
4
4
3
3
apIDs:
ref:
drft -0.000159936025589764
hmtL 168163517
kTs 0
offL 1526289311707
sysL 1526457475224
Attributes:
event-on-change-reading .*
hmId 2AEDA2
hmLanQlen 1_min
hmProtocolEvents 0_off
loadLevel 0:low,40:batchLevel,90:high,99:suspended
logIDs
respTime 2
room CUL_HM
userReadings xyz {substr(InternalVal("HMLAN1","uptime",""),4,length(InternalVal("HMLAN1","uptime",""))-11)}
verbose 3
Internals:
DEF 192.168.1.43:1000
DeviceName 192.168.1.43:1000
FD 78
HMLAN2_MSGCNT 121462
HMLAN2_TIME 2018-05-16 09:48:32
IFmodel LAN
NAME HMLAN2
NR 5
NTFY_ORDER 50-HMLAN2
PARTIAL
RAWMSG E4D106F,0000,09F77197,FF,FFAC,B7865E4D106F00000031F58C007E90
RSSI -84
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 1
msgKeepAlive dlyMax:702.591 bufferMin:-697
msgLoadCurrent 1
msgLoadHistoryAbs 5min steps: 1/1/1/0/0/0/0/0/0/0/0/0
msgParseDly min:-21758 max:1079227 last:2 cnt:115765
owner 2AEDA2
uptime 001 46:26:51.415
READINGS:
2018-05-14 11:14:40 D-HMIdAssigned 2AEDA2
2018-05-14 11:14:40 D-HMIdOriginal 2BB5AD
2018-05-14 11:14:40 D-firmware 0.965
2018-05-14 11:14:40 D-serialNr LEQ0579235
2018-05-16 09:34:27 Xmit-Events disconnected:159 ok:84 init:84
2018-05-16 09:34:27 cond ok
2018-05-16 09:48:18 loadLvl low
2018-05-16 09:34:26 prot_disconnected last
2018-05-16 09:34:27 prot_init last
2018-05-16 09:34:27 prot_ok last
2018-05-16 09:34:27 state opened
helper:
assIdCnt 1
assIdRep 1
info 03C5,LEQ0579235,2BB5AD,2AEDA2
setTime 46583
cnd:
0 84
253 159
255 84
dly:
cnt 115765
lst 2
max 1079227
min -21758
ids:
3505E8:
cfg +3505E8,00,00,00
name Kontakt
k:
BufMin -697
DlyMax 702.591
Next 1526456923.07988
Start 1526456898.07988
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x1644974)
q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 1
loadNo 9
scnt 4
ald:
1
1
1
0
0
0
0
0
0
0
0
0
apIDs:
ref:
drft -0.00015999360025599
hmtL 167196982
kTs 0
offL 1526289701102
sysL 1526456898084
Attributes:
hmId 2AEDA2
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room CUL_HM
Hast Du mal versucht, die beiden zu tauschen? Also den bisherigen HMLAN1 als HMLAN2 und umgekehrt zu betreiben.
Wenn die disconnects dann bei dem physikalisch gleichen Adapter bleiben, solltest Du mal die Netzwerkverbindung zu diesem kontrollieren bzw. damit experimentieren.
ist auf dem weg zum hmlan2 wlan im spiel?
poste noch ein list der vccu.
@topfi: tauschen ist etwas schwierig weil ich den HMLAN1 mit einer externen Antenne versehen habe und die müsste ich dann mit umbauen :(
@frank: Internals:
DEF 2AEDA2
HMLAN1_MSGCNT 177
HMLAN1_RAWMSG E2AEDA2,0000,0A0F04F4,FF,FFAE,5E80022AEDA23505E800
HMLAN1_RSSI -82
HMLAN1_TIME 2018-05-16 10:07:48
HMLAN2_MSGCNT 13129
HMLAN2_RAWMSG E2AEDA2,0000,0A188299,FF,FFAD,8280022AEDA23422B500
HMLAN2_RSSI -83
HMLAN2_TIME 2018-05-16 10:24:39
IODev HMLAN1
LASTInputDev HMLAN2
MSGCNT 13306
NAME VCCU
NOTIFYDEV global
NR 7
NTFY_ORDER 50-VCCU
STATE HMLAN1:ok,
TYPE CUL_HM
assignedIOs HMLAN1,HMLAN2
lastMsg No:82 - t:02 s:2AEDA2 d:3422B5 00
protLastRcv 2018-05-16 10:24:39
rssi_at_HMLAN1 cnt:177 min:-99 max:-78 avg:-86.4 lst:-82
rssi_at_HMLAN2 cnt:13129 min:-107 max:-79 avg:-84.93 lst:-83
READINGS:
2018-05-16 10:24:39 CommandAccepted yes
2018-05-15 16:40:44 recentStateType ack
2018-05-14 11:16:39 state HMLAN1:ok,
helper:
HM_CMDNR 130
PONtest 1
mId FFF0
regLst ,0
rxType 1
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
nextSend 1526459079.28384
prefIO
vccu VCCU
ioList:
HMLAN1
mRssi:
mNo 82
io:
HMLAN1:
HMLAN2:
-83
-83
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
rssi:
at_HMLAN1:
avg -86.406779661017
cnt 177
lst -82
max -78
min -99
at_HMLAN2:
avg -84.9324396374441
cnt 13129
lst -83
max -79
min -107
Attributes:
IODev HMLAN1
IOList HMLAN1, HMLAN2
IOgrp VCCU
expert 2_raw
model CCU-FHEM
subType virtual
webCmd virtual:update
Edit: auf dem Weg zum HMLAN2 ist kein WLAN im Spiel, aber eine Devolo-Verbindung
IOList HMLAN1, HMLAN2
entferne das leerzeichen nach dem komma. dann findet die vccu ihn auch.
ich kenne diese disconnects durch wlan. daher würde ich bei dir auf die devolo verbindung tippen. vielleicht mal andere steckdosen probieren und schauen, dass die selbe phase zum einsatz kommt.
Ich habe auch einen zweiten HMLAN über devolo. Dieser zeigte bisweilen disconnects (ohne reboot), im Mittel einen pro Tag. Der andere, im exclusiven gemeinsamen vlan mit dem FHEM-Server und per Kabel angeschlossen, ist seit dem Tausch der Elkos völlig unauffällig.
Ich habe noch ein drittes IO-Gerät für HM, ein Raspi-HMUART-Modul. Hier hatte ich noch nie disconnects. Den zweiten HMLAN habe ich inzwischen auf Dummy gesetzt, den halte ich nur als Backup vor.
Mal grundsätzlich zur fehlersuche: die vccu hat mit disconnects nichts zu tun. Über die vccu wird dies überhaupt nicht gesteuert.
Ein haeufiger grund für reset ist, dass das ping zu spät kommt.
Ich glaube es ist im Wiki beschrieben: ein hmlan braucht alle 30 s ein ping von fhem(damit hat die vccu auch nichts zu tun). Fhem sendet alle 25s. Das sind 5s puffer. Der ping wird entsprechend schnell wiederholt.
Untersuche also die netzdelays.
Vergleiche den max msgdelay der beiden hmlan. Hmlan1hat 700ms. Hmlan 2 har 10s. Treten die 10s auch bei einem ping auf sind wir bei 35s. Hmlan wird reset machen.
=> Der grund ist dein netzwerk. Der develo ist zu langsam.
1. Du kannst den hmlan am leben halten wenn du den ping auf 15 setzt.
Attr hmlan2 wdtimer 15
2. Ein delay von 10s und eventuell noch mehr wird immer wieder zu Problemen führen. Fhem kann nicht schnell antworten, msgs werden wiederholt, acks bleiben aus, kommunikation wird abgebrochen. Die Schnittstelle in dieser Form kann mithören und einfache Kommando s gerade einmal so übertragen. Setzen von Register, Anfrage derselben und programmieren von rt Temperaturen ist Glückssache.
=> Die Schnittstelle ist unzuverlässig. Wenn du sie betreiben willst musst du mit Problemen rechnen und diese selbst lösen
Nur als Ergänzung bzw. Bestätigung: Mit einer devolo-Verbindung (in der Garage, kein LAN-Kabel, daher PowerLAN, d.h. über Netzkabel mit devolo) hat es nie funktioniert, weder mit HLMAN noch mit dem neueren HM-LGW-O-TW-W-EU. Ich habe damals wochenlang experimentiert, aber keine Chance. Das Problem: Devolo hat die Daten nicht konstant genug übertragen, es waren immer wieder Aussetzer drin. Versuche mit verschiedenen devolo-Varianten (bis hin zur "professionellen" Version) waren erfolglos. Am Ende blieb nur eine bessere Positionierung eines HM-LGW-O-TW-W-EU im Haus.
Disconnects sind aus meiner Erfahrung mit einem umfangreicheren LAN in der Regel durch Netzwerkprobleme (Latenzen) verursacht. Das kann auch ganz einfach durch hohe Netzwerk-Auslastung ohne Priorisierung der Ports am Switch entstehen. Wenn z.B. ein Windows 10 System einen Update-Download fährt dann kann dies das LAN so blockieren das es auch zu Disconnects führt. Alles schon erlebt und ist immer noch nachvollziehbar. Wer hat denn schon ein reines "HomeMatic"-LAN ohne andere Systeme.
(Übrigens: FHEM selbst kann auch Disconnects verursachen. Wenn ich im Web-UI ein List für alle Devices mache dann gibt's auch Disconnects - weil FHEM blockiert. Nur als ein weiteres Beispiel.)
Gruß, Klaus