Hallo zusammen
seit heute habe ich plötzlich das Phänomen, das alle 3 HMLAN disconnect sind
auch wenn ich fhem runterfahre und mit dem original homatikprogramm suchen lasse, sind diese nicht auffindbar (siehe Datei)
wie bekomme ich das wieder hin?
habe auch bereits alle drei HMLAN einzeln versucht - auch ohne Erfolg
sie lassen sich auch nur sporadisch anpingen
Über Hilfe würde ich mich freuen
Gruss tagedieb
sieht nach einem Netzwerkproblem aus ...
gibt es bei den 3 HMLANs Gemeinsamkeiten?
allee am gleichen Switch? Alle auf DHCP? Netzwerk geändert? Kabel defekt? Welche Lampen leuchten?
Hallo Wuppi68
danke das du dich dem Problem annimmst
ich habe im Netztwerk alles feste ip - obendrein sind die geräte auch in der FB vermerkt, das sie immer die gleiche ip bekommen
ich erreiche sie auch nicht, wenn ich sie nur einzeln einschalte
ich habe einen TP Linkswitch, an dem alle Geräte "hängen" - auch diesen habe ich schon kontrolliert, ob alle kabel fest eingeklickt sind
jetzt habe ich das Netzwerk mit nur einem HMLAN durchsucht und er gibt mir eine IP des abgeschalteten HMLAN als connect an
Die HMLANS haben aber alle andere Ser.Nummern, alle unterschidliche ID, laufen über Vccu
Internals:
DEF 192.168.1.91:1000
DeviceName 192.168.1.91:1000
HMLAN3_MSGCNT 3
HMLAN3_TIME 2016-12-30 12:50:39
IFmodel LAN
NAME HMLAN3
NEXT_OPEN 1483099779.11922
NR 1685
NTFY_ORDER 50-HMLAN3
PARTIAL
RAWMSG E266B77,0000,0000284B,FF,FF9C,818410266B77456DEF06012300
RSSI -100
STATE disconnected
TYPE HMLAN
XmitOpen 0
assignedIDsCnt 3 report:0
msgKeepAlive dlyMax:1.824 bufferMin:3
msgLoadCurrent 0
msgLoadHistoryAbs 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
owner 789FED
uptime 000 00:00:04.449
Readings:
2016-12-30 12:32:34 D-HMIdAssigned 789FED
2016-12-30 12:32:34 D-HMIdOriginal 26E92C
2016-12-30 12:32:34 D-firmware 0.964
2016-12-30 12:32:34 D-serialNr LEQ0102691
2016-12-30 13:06:28 Xmit-Events disconnected:13 init:12 timeout:12 ok:9
2016-12-30 13:06:28 cond disconnected
2016-12-30 13:05:57 loadLvl low
2016-12-30 13:06:28 prot_disconnected last
2016-12-30 13:05:56 prot_init last
2016-12-30 10:49:43 prot_keepAlive last
2016-12-30 13:06:00 prot_ok last
2016-12-30 13:06:28 prot_timeout last
2016-12-30 13:08:39 state disconnected
Helper:
assIdCnt 3
assIdRep 0
info 03C4,LEQ0102691,26E92C,789FED
setTime 45260
Cnd:
0 9
252 12
253 13
255 12
Ids:
401303:
cfg +401303,00,00,00
name Masterfernbedienung
4a7e07:
cfg +4A7E07,00,00,00
chn 01
flg 1
msg
name Messschalter
to 1483097669.50112
4e3fb3:
cfg +4E3FB3,00,00,00
chn 01
flg 1
msg
name Relais_Lift
to 1483098959.86964
K:
BufMin 3
DlyMax 1.824
Next 1483099612.20968
Start 1483099587.20968
Loadlvl:
bl 40
a:
99
90
40
0
H:
0 low
40 batchLevel
90 high
99 suspended
Log:
all 0
sys 0
ids:
ARRAY(0x2596100)
Q:
HMcndN 253
answerPend 0
hmLanQlen 1
keepAliveRec 0
keepAliveRpt 3
loadLastMax 0
loadNo 1
scnt 8
ald:
0
0
0
0
0
0
0
0
0
0
0
0
apIDs:
Ref:
kTs 1483099587209
Attributes:
devStateIcon opened:rc_GREEN disconnected:rc_RED
hmId 789FED
hmLanQlen 1_min
icon hm_lan
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room Container
wdTimer 25
und dieser Internals:
DEF 192.168.1.95:1000
DeviceName 192.168.1.95:1000
FD 378
HMLAN1_MSGCNT 15
HMLAN1_TIME 2016-12-30 12:55:17
IFmodel LAN
NAME HMLAN1
NR 652
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG R4F95883F,0001,0000180A,FF,FFBE,04A4104F1CAE456DEF0601C80042
RSSI -66
STATE opened
TYPE HMLAN
XmitOpen 0
assignedIDsCnt 57 report:0
msgKeepAlive dlyMax:5.483 bufferMin:0
msgLoadCurrent 0
msgLoadHistoryAbs 5min steps: 1/1/0/0/0/0/0/0/0/0/0/0
owner 456DEF
uptime 000 00:00:04.471
Readings:
2016-12-30 12:33:38 D-HMIdAssigned 456DEF
2016-12-30 12:33:38 D-HMIdOriginal 2BAB90
2016-12-30 12:33:38 D-firmware 0.964
2016-12-30 12:33:38 D-serialNr LEQ0579845
2016-12-30 13:10:34 Xmit-Events disconnected:7 init:7 timeout:6 ok:5
2016-12-30 13:10:34 cond init
2016-12-30 13:10:35 loadLvl low
2016-11-30 19:19:00 prot_ERROR-Overload last
2016-11-30 19:49:21 prot_Warning-HighLoad last
2016-12-30 12:55:46 prot_disconnected last
2016-12-30 13:10:34 prot_init last
2016-12-30 11:20:36 prot_keepAlive last
2016-12-30 12:55:16 prot_ok last
2016-12-30 12:55:46 prot_timeout last
2016-12-30 13:10:34 state opened
Helper:
assIdCnt 57
assIdRep 0
info 03C4,LEQ0579845,2BAB90,456DEF
setTime 45260
Cnd:
0 5
252 6
253 7
255 7
Ids:
11beac:
cfg +11BEAC,00,00,00
name SchlossMaster
172f3d:
cfg +172F3D,00,00,00
name SchlossDublette
1f186c:
cfg +1F186C,00,00,00
name Fenster_Bad
20310f:
cfg +20310F,00,00,00
name Fenster_li_Buero
203280:
cfg +203280,00,00,00
name Fenster_Schlafzimmer
203291:
cfg +203291,00,00,00
name Balkontuer_Kueche
2032e1:
cfg +2032E1,00,00,00
name fenster_re_Buero
205c89:
cfg +205C89,00,00,00
name CUL_HM_HM_SCI_3_FM_205C89
209c5d:
cfg +209C5D,00,00,00
chn 01
flg 1
msg
name CUL_HM_HM_LC_Sw1PBU_FM_209C5D
to 1483097645.53127
20b29e:
cfg +20B29E,00,00,00
name Rolladen_WZ
20bbe3:
cfg +20BBE3,00,00,00
name Rolladen_Dachfenster
20f55b:
cfg +20F55B,00,00,00
name ZUFASchalter
21a532:
cfg +21A532,00,00,00
name BMBad
21ab76:
cfg +21AB76,00,00,00
name Rolladen_SpK
21ba59:
cfg +21BA59,00,00,00
name Heizung_Kueche
220941:
cfg +220941,00,00,00
name Heizung_Schlafzimmer
220954:
cfg +220954,00,00,00
name Heizung_Bad
221876:
cfg +221876,00,00,00
name Heizungli_Buero
223111:
cfg +223111,00,00,00
name Heizungre_Buero
22311c:
cfg +22311C,00,00,00
name Heizung_WZ
22498a:
cfg +22498A,00,00,00
chn 01
flg 1
msg
name ROKTSchalter
to 1483098663.86859
224a0d:
cfg +224A0D,00,00,00
chn 04
flg 1
msg
name RODFSchalter
to 1483098638.67945
224a86:
cfg +224A86,00,00,00
chn 03
flg 1
msg
name ROSZSchalter
to 1483098672.85915
225c4b:
cfg +225C4B,00,00,00
name unterer_Anschl
241c98:
cfg +241C98,00,00,00
name Rolladen_Anbau
266b77:
cfg +266B77,00,00,00
name BMGaesteWC
278ad8:
cfg +278AD8,00,00,00
chn 01
flg 1
msg
name RelaisGaesteWC
to 1483098687.75075
291352:
cfg +291352,00,00,00
name Fenster_GaesteWC
29c2f9:
cfg +29C2F9,00,00,00
name MarkiseSchalter
2d9277:
cfg +2D9277,00,00,00
name Kontaktsensor
2fd409:
cfg +2FD409,00,00,00
name Rolladen_Bad
3274a5:
cfg +3274A5,00,00,00
name Doppelschalter
352b49:
cfg +352B49,00,00,00
name FlurobenTaster
354036:
cfg +354036,00,00,00
name Heizung_Flur
35403a:
cfg +35403A,00,00,00
name Heizung_Gaeste_WC
354310:
cfg +354310,00,00,00
name Heizung_Buero_unten
3608c4:
cfg +3608C4,00,00,00
name Relais_Caffeeautomat
3768e2:
cfg +3768E2,00,00,00
name SZLicht
376916:
cfg +376916,00,00,00
name LichtObererFlur
376936:
cfg +376936,00,00,00
name DeckenlichtBad
38172e:
cfg +38172E,00,00,00
name LichttasterFlurOben
392f53:
cfg +392F53,00,00,00
name RelaisSpeisekammer
395b00:
cfg +395B00,00,00,00
name BMmitTaster
3deee7:
cfg +3DEEE7,00,00,00
name BMAussen
3e4ae8:
cfg +3E4AE8,00,00,00
name BMLEDStufen
3e8429:
cfg +3E8429,00,00,00
name Schloss
3e9167:
cfg +3E9167,00,00,00
name HM_3E9167
3ea77c:
cfg +3EA77C,00,00,00
name Fernbedienung2
41a814:
cfg +41A814,00,00,00
name Tassenschacht
4384e2:
cfg +4384E2,00,00,00
name Containerrelais
4442c9:
cfg +4442C9,00,00,00
name Deckenlicht_Kueche
44be31:
cfg +44BE31,00,00,00
name Hoftor
44be36:
cfg +44BE36,00,00,00
name Hofeingang
4cdf44:
cfg +4CDF44,00,00,00
name Heizung_Flur_Kellertreppe
4f1cae:
cfg +4F1CAE,00,00,00
chn 02
flg 1
msg
name Relais_Kuechenled
to 1483098935.46845
4fb35c:
cfg +4FB35C,00,00,00
name WZWandlampe
4fb526:
cfg +4FB526,00,00,00
name WZdeckenleuchte
K:
BufMin 0
DlyMax 5.483
Next 1483099859.7562
Start 1483099834.7562
Loadlvl:
bl 40
a:
99
90
40
0
H:
0 low
40 batchLevel
90 high
99 suspended
Log:
all 0
sys 0
ids:
ARRAY(0x2155340)
Q:
HMcndN 255
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 0
loadNo 2
scnt 7
ald:
1
1
0
0
0
0
0
0
0
0
0
0
apIDs:
Attributes:
devStateIcon opened:rc_GREEN disconnected:rc_RED
fp_dachgeschoss 180,555,0,
hmId 456DEF
hmLanQlen 1_min
icon hm_lan
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room Flur_oben
wdTimer 25 ist "am Netz ?????
Moin Moin ..
hatte ich heute früh auch, nachdem ich ein FHEM-Update gemacht hatte. Netzwerk war auch erst meine Vermutung, bis ich gesehen hatte, dass beide HMLANs völlig synchron alle paar Sekunden rebooteten. Das liess vermuten, dass die Ursache irgendwas zentrales ist.
Abhilfe schaffte das zurückdrehen des Updates auf meinen letzten Stand von Anfang Dezember...Seitdem gab es Änderungen in 00_HMLAN.pm
Grüße
meloggg
uptime 000 00:00:04.471
anhand der uptime's scheinen die hmlan ständig zu rebooten. das hat mit fhem eigentlich nichts zu tun.
manuell kann man das nur durch stecker ziehen erreichen.
ansonnsten reagieren sie wohl allergisch auf multicast messages auf netzseite.
es gibt wohl auch phänomene, dass kollidierende/gleichzeitige funkmessages so etwas auslösen können.
also entweder im netz nach multicast messages sniffen oder vielleicht gibt es ein device welches ein dauerfeuer von funkmessages produziert (fernbedienung?). das könntest du mit sniffen über einen cul vielleicht erkennen.
Moin Moin ...
Wie gesagt, Netzwerk hatte ich anfangs auch im Fokus... Schien mir nur nicht wirklich plausibel, da ich da keine Änderungen hatte. Multicasts würde ich auch ausschließen wollen, da ich für das HM-Thema ein isoliertes VLAN betreibe, in dem eigentlich keine Multicast-Stürme ankommen sollten.
Dann hatte ich im Wiki was gelesen, das auf ein Hardwareproblem hindeutet. Gegen beide Varianten spricht, dass die Ausfälle immer völlig synchron bei beiden HMLANs auftraten. Ein Trennen eines HMLAN brachte für ein Intervall Besserung, danach hatten sich beide HMLANs mit ihren Reboots wieder synchronisiert. Auch bei gestoppten FHEM blieben die Reboots aus... Das alles zusammen lässt mich vermuten, dass die Kommunikation FHEM <--> HMLAN für die Reboots sorgt.
Grüße
meloggg
hallo zusammen
leider hat all das bisher keine Besserung gezeigt
im event Monitor erhalte ich016.12.30 14:24:48 1 : HMLAN_Parse: HMLAN1 new condition ok
2016.12.30 14:25:17 1 : HMLAN_Parse: HMLAN1 new condition timeout
2016.12.30 14:25:17 1 : 192.168.1.95:1000 disconnected, waiting to reappear (HMLAN1)
2016.12.30 14:25:17 1 : HMLAN_Parse: HMLAN1 new condition disconnected
und wenn ich die HMLAN direkt an den PC anschliesse findet es das Homematic Suchprogramm weder wenn sie einzeln, noch wenn sie alle am Netz sind
das "kuriose" ich kann an der Netzwerkarteneinstellung immer beobachten, das die Netzwerkverbindung zwischen PC und HMLAN wechselt zwischen Netzwerkidentifiezierung und Netzwerkkabel entfernt
ich gehe mittlerweile davon aus, das es Hardwareseitig sein könnte
hat jemand noch eine weitere Idee? :-[
gruss tagedieb
Wenn die HMLANs schon ein paar Tage älter sind, können es auch die Elkos auf der Platine sein, sind nur Centartikel und können auf Verdacht einfach ausgetauscht werden - den Tipp gabe es schon mal hier im Forum
Guten Morgen zusammen
zuerst allen Helfern ein grosses Dankeschön
falls jemand mal das gleiche Problem hat, hier die Lösung, welche bei mir geholfen hat - es war eine kleine Ursache mit grosse Wirkung
Support von eq3 erklärte mir, das Homatic ip bei den HMLANs ein ständiges reboot verursacht -( wie ich das dem Forum entnehmen konnte, haben das auch schon mehere beobachtet) und hier ein HMLAN update Abhilfe schafft.
um die HMLAN`s wieder zu erreichen, sollte ich ALLE Homematic IP vom Strom nehmen (CCu und Geräte)
ich hatte zwar bei meiner Fehlersuche die CCu ausgeschalten, jedoch nicht die einzelnen Homematik IP Geräte
Nach dem update aller drei HMLAN´s auf die Version 0.965 konnte ich wieder alles wie gewohnt nutzen - die HMLAN`s rebooten nicht mehr ständig. es erscheint zwar im Log noch alle 10 minuten2016.12.31 06:45:11 3: HMLAN1: Unknown code A1312008385ECBCF0000100003BCA0875B3D602DB::-70:HMLAN1, help me!
2016.12.31 06:45:11 3: HMLAN2: Unknown code A1312008385ECBCF0000100003BCA0875B3D602DB::-76:HMLAN2, help me!
jedoch ein disconnect der HMLAN´s gab es in 12 h nur einmal
ich wünsche allen einen schönen Tag
einen Guten Rutsch und ein gesundes neues Jahr
lg tagedieb
Zitatich hatte zwar bei meiner Fehlersuche die CCu ausgeschalten, jedoch nicht die einzelnen Homematik IP Geräte
demnach wurden die hmlan also über funk zum rebooten gebracht, richtig?
ist ein fehlverhalten dann auch bei anderen devices denkbar? hat eq3 sich dazu geäussert?
Hallo zusammen
ich wünsche allen ein gesundes neues Jahr
@Frank
ja- die CCU2 hat ein ständiges rebooten verursacht, - das hat man mit der "neuen" aktualisierten Firmware für die HMLAN`s beseitigt
(ist auch so)
ich weiss nicht, ob es mit den anderen zentralen Homematicsendern (wie CUL, USB und den HM-CFG-Lan) auch ist, kann ich mir aber vorstellen
vielleicht zum Prüfen, mal ALLE Homematic IP Sender und Empfänger vom Strom nehmen und prüfen, ob die Unregelmäßigkeiten weiter erscheinen, meine HMLAN`s haben vor dem Update, teilweise im halbminuten Takt rebootet
viele Grüsse tagedieb
hallo tagedieb,
ebenfalls ein frohes neues jahr.
du hast mich leider nicht ganz verstanden.
deine aussage war, dass die hmlan weiterhin rebootet wurden, obwohl du die ccu2 bereits abgeschaltet hattest. daraus schliesse ich, dass das rebooten zu dieser zeit durch deine anderen hmip-devices ausgelöst wurde. also durch irgendwelche aktoren oder sensoren der hmip-serie, denn erst nachdem du diese ebenfalls abgeschaltet hast, war das rebooten endlich vorüber.
ist das so richtig?
wenn also zb ein hmip-aktor über funkmessages einen hmlan stören/rebooten kann, könnte ich mir vorstellen, dass dieser hmip-aktor theoretisch auch sensoren/aktoren der "alten" bidcos-serie stören/beeinflussen kann.
zu dieser spekulation hat eq3 sicherlich nichts gesagt, oder?
gruss frank
Hallo Frank
ja, da habe ich mich falsch ausgedrückt , es haben die HMLAN`s nur andauernd rebootet, wenn die CCU2 angeschlossen war und er rpcserver lief
und als ich die HMLN`S einzeln durchprobiert habe - war die CCU2 nicht ausgeschaltet, da diese als Fehler für mich nicht in Betracht kam ???
da ich jedoch selbst bei runtergefahrenem FHEM und ausgeschalteter CCU2 die HMLAN´s mit der Homematik Lan Config nicht erreichen konnte, sollte ich alle IP Geräte entfernen und DANACH waren meine HMLAN`s für ein Update erreichbar
Gruss tagedieb
ok, danke.
Zitatda ich jedoch selbst bei runtergefahrenem FHEM und ausgeschalteter CCU2 die HMLAN´s mit der Homematik Lan Config nicht erreichen konnte, sollte ich alle IP Geräte entfernen und DANACH waren meine HMLAN`s für ein Update erreichbar
richtig "gesund" hört sich das aber nicht an. auch hinsichtlich anderer bidcos-devices.
hm..., was wäre gewesen, wenn dein nachbar noch ein paar hmip-devices am laufen hätte.
Hallo Frank
ich stimme Dir zu - habe aber glücklicherweise, nur einen Nachbarn, die solch Technik als Schnickschack und überflüssig findet ::) und weiter als 200 m weg wohnt :o
lg Grüsse
Moin moin & Frohes Neues auch von mir ;-)
Ich hatte mich zu früh gefreut... Abhilfe brachte tatsächlich erst ein Update der HMLANs auf 0.965 (vorher 0.964).
HMIP betreibe ich selbst nicht. Wenn das der Auslöser für die Reboots ist, müssen die fraglichen Funkmessages von außen aus der Nachbarschaft gekommen sein.
Grüße
meloggg
Hallo,
ich klinke mich hier mal mit ein. Seit Anfang Dezember habe ich dauernd disconnects bei meinem HMLAN. An FHEM etc. wurde nicht geändert ausser den üblichen, regelmässigen Updates.
Netzwerkprobleme schließe ich auch mal aus, da an der Installation des Netzwerkes nichts geändert wurde (RPi mit FHEM hängt via GBit Kabel am Switch und dort dran hängt der HMLAN). Neue geräte gibt es auch nicht im Netzwerk. Der Event-Monitor sowie apptime zeigen keine Auffälligkeiten, die dieses Verhalten erklären (Ausnahme siehe unten). Ich habe trotzdem mal spasseshalber gestern den RPi2 gegen einen RPi3 getsucht wegen mehr Rechenleistung aber der Effekt bleibt.
Der HMLAN ist nun min. 3 Jahre alt und FW update habe ich noch nie gemacht (warum auch, tut ja und never touch a running system)
Verstehe ich den Thread hier wie folgt richtig bezgl. möglicher Probleme:
1. die Elkos auf dem HMLAN könnten defekt sein und müssen getauscht werden
2. mögliche HM-IP Geräte in der Nachbarschaft bringen den HMLAN zum rebooten. Abhilfe schafft ein FW Update
Ich hatte mich bisher nie mit dem Event Monitor beschäftigt, habe aber dieser Tage gesehen, dass der HMLAN ca. alle 3-4 Minuten Message von Geräten hat, die nicht von mir sind. Ich kann also nicht sagen, ob diese Geräte nun neu sind oder ob das schon seit einiger Zeit so ist. Neu ist aber das Nachbarhaus. Die sind Mitte Dezember eingezogen. Ob die aber HM Geräte haben weiß ich nicht und die sind gerade im Ski-Urlaub; ich kann also die nächsten Tage nicht fragen und bin ab Sonntag dann beruflich wieder eine ganze Zeit unterwegs. Kann ich irgendwie erkennen, ob die gemeldeten Geräte HM IP sind?
Nebenfrage:
da mich die Probleme mit dem HMLAN so ca. 1 mal pro Jahr beschäftigen: bringt denn der Umstieg auf den neuen LAN Adapter von eq3 oder der direkte RPi Adapter etwas? Ich steige dann um.
warum zeigst du die messages nicht?
Hallo,
ich möchte mich hier anschließen, dass seit ca. Anfang Dezember meine beiden HMLANs in regelmäßigen Abständen (ca. alle 60 Minuten) sich "disconnecten" und sofort wieder "connecten". Einer der beiden HMLANs ist relativ neu, also sollte man die ELKOs ausschließen; die Firmware ist auch aktuell.
Könnte mir jemand sagen, wo der Austausch der ELKOs beschrieben ist, ich kann den Artikel nicht finden?
Gruß
Blueberry63
https://wiki.fhem.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter (https://wiki.fhem.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter)
Die WIKI-Seite kenne ich natürlich. Aber ist denn auch irgendwo der Austausch der Elkos beschrieben?
Zitat von: blueberry63 am 03 Januar 2017, 12:37:13
Die WIKI-Seite kenne ich natürlich. Aber ist denn auch irgendwo der Austausch der Elkos beschrieben?
wie meinst du das genau?
ich denke, dass automatisierer einfach alle elkos getauscht hat.
in der regel kleine "tönnchen" mit 2 beinchen, aufrecht stehend. ein beinchen ist plus, das andere minus, erkennbar an der aufschrift. also die neuen richtig rum einbauen.
ich habe jetzt aber nicht reingeschaut in den hmlan.
Zitat von: blueberry63 am 03 Januar 2017, 12:37:13
Die WIKI-Seite kenne ich natürlich. Aber ist denn auch irgendwo der Austausch der Elkos beschrieben?
Wenn ich das richtig sehe sind es drei Stück, einfach erreichbar -> http://2.bp.blogspot.com/-r19u6WxbZHM/VavjB2sIuAI/AAAAAAAAEUU/hpXG-zyH-dM/s1600/HMLANneueAntenne.png
Ich reiße die einfach immer durch drehen/zerstören mit der Zange herunter. Dann stehen die beiden Beinchen frei und man kann die bequem auslöten. Mit einer Nadel und Lötkolben die Löcher freistoßen und die neuen sauber einlöten.
Drei neue Elkos kosten am Ende im Wesentlichen die Transportkosten 8)
Gruß Otto
@frank: ich kann die Messages grad nicht posten, da ich nicht zu Hause bin und keinen Zugriff auf das Logfile habe. Kann ich heute abend aber gerne nachholen, nur vermutlich ist der Erkenntnissgewinn nicht hoch, denn wie im Logfile ein HMLAN, der disconnected ist aussieht, ist ja bekannt :-)
Im Event-Monitor gibt es auch nach 3 Stunden anschauen keinen Zusammenhang. Die Events, die kurz vor dem disconnect kommen sind jedesmal andere. Ergo kann ich da keinen Zusammenhang zwischen einem speziellen Device, seinen Events und einem direkt danach folgenden disconnect erkennen.
Apptime hat mir jetzt nach mehr als 48 Stunden Laufzeit gezeigt, dass das Abrufen der Wetter Info von Yahoo einmal 8 Sekunden gedauert hat sowie dass das Aktualiesieren eines Owncloud Kalenders einmal 6 Sekunden gedauert hat. Der Rest ist im Millisekunden Bereich. Das erklärt nicht, warum der HMLAN sich deutlich öfters disconnected. Im Worst Case disconnected er sich bereits nach 1 Minute, manchmal kriegt er aber auch fast 20 Minuten ohne disconnect hin. Und wie gesagt: an dem FHEM wurde seit Monaten ausser den Updates nichts gemacht. er lief jetzt monatelang ohne Änderungen einfach so vor sich hin.
@bugster_de
ZitatIch hatte mich bisher nie mit dem Event Monitor beschäftigt, habe aber dieser Tage gesehen, dass der HMLAN ca. alle 3-4 Minuten Message von Geräten hat, die nicht von mir sind. Ich kann also nicht sagen, ob diese Geräte nun neu sind oder ob das schon seit einiger Zeit so ist. Neu ist aber das Nachbarhaus. Die sind Mitte Dezember eingezogen. Ob die aber HM Geräte haben weiß ich nicht und die sind gerade im Ski-Urlaub; ich kann also die nächsten Tage nicht fragen und bin ab Sonntag dann beruflich wieder eine ganze Zeit unterwegs. Kann ich irgendwie erkennen, ob die gemeldeten Geräte HM IP sind?
diese messages meine ich.
Hi Frank,
zuerst mal: als ich heute nach Hause kam hat mich der Schlag getroffen: der HMLAN war im 30 Sekunden Rhythmus disconnected und das Log-File entsprechend gut gefüllt. Auch habe ich gesehen, dass der HMLAN wohl alle paar Sekunden neu bootet. Also habe ich die neue FW aufgespielt, was gar nicht so einfach ist, wenn der HMLAN dauernd rebootet. Die neue FW ist nun seit einer Stunde drauf und bisher nur ein disconnect (daran hat man sich bei Homematic ja schon gewöhnt).
Sieht also erstmal deutlich besser aus wie bisher. Danke für die Hilfe in den Thread hier !
Die Messages mit den unknown Devices sehen wie folgt aus:
2017-01-03 18:06:02 HMLAN OG_HMLAN UNKNOWNCODE A118BA00234959C2F2D4604122B68E34D3102::-102:OG_HMLAN
2017-01-03 18:06:03 HMLAN OG_HMLAN UNKNOWNCODE A0E8B800234959C2F2D46004E6CCCE5::-101:OG_HMLAN
2017-01-03 18:06:24 HMLAN OG_HMLAN UNKNOWNCODE A1187A00234959C46C95504F610EFD3534A02::-101:OG_HMLAN
2017-01-03 18:06:27 HMLAN OG_HMLAN UNKNOWNCODE A0E87800234959C46C9550066B0660E::-101:OG_HMLAN
2017-01-03 18:06:42 HMLAN OG_HMLAN UNKNOWNCODE A1112A00234959C38D194041CCAC53DF11002::-103:OG_HMLAN
2017-01-03 18:06:43 HMLAN OG_HMLAN UNKNOWNCODE A0E12800234959C38D19400B49DF354::-102:OG_HMLAN
2017-01-03 18:06:44 HMLAN OG_HMLAN UNKNOWNCODE A0C03867034195B00000000EE24::-99:OG_HMLAN
2017-01-03 18:07:01 HMLAN OG_HMLAN UNKNOWNCODE A11E4A00234959C38D1D104CBB1940DCE2D02::-102:OG_HMLAN
2017-01-03 18:07:01 HMLAN OG_HMLAN UNKNOWNCODE A0E078470312DDC00000000D43503D3::-94:OG_HMLAN
2017-01-03 18:07:01 HMLAN OG_HMLAN UNKNOWNCODE A0EE4800234959C38D1D100F92050CC::-103:OG_HMLAN
2017-01-03 18:07:03 HMLAN OG_HMLAN loadLvl: low
2017-01-03 18:07:10 HMLAN OG_HMLAN UNKNOWNCODE A0E7DA01134959C2A962A0201000000::-102:OG_HMLAN
2017-01-03 18:07:10 HMLAN OG_HMLAN UNKNOWNCODE A0E7D80022A962A34959C010100002B::-101:OG_HMLAN
2017-01-03 18:07:29 HMLAN OG_HMLAN UNKNOWNCODE A0D43A6102F2BF234959C06013900::-81:OG_HMLAN
2017-01-03 18:07:29 HMLAN OG_HMLAN UNKNOWNCODE A1143A00234959C2F2BF204251482C7F2E002::-100:OG_HMLAN
2017-01-03 18:07:29 HMLAN OG_HMLAN UNKNOWNCODE A0E43800234959C2F2BF2002705A0E2::-102:OG_HMLAN
2017-01-03 18:07:47 HMLAN OG_HMLAN UNKNOWNCODE A11B8A00234959C34600404AF513A37C77602::-102:OG_HMLAN
2017-01-03 18:07:47 HMLAN OG_HMLAN UNKNOWNCODE A0EB8800234959C34600400D9C28B1E::-101:OG_HMLAN
2017-01-03 18:07:47 HMLAN OG_HMLAN UNKNOWNCODE A0C37A01134959C2FBEE6820A00::-102:OG_HMLAN
2017-01-03 18:07:47 HMLAN OG_HMLAN UNKNOWNCODE A0A3780022FBEE634959C00::-98:OG_HMLAN
2017-01-03 18:07:48 HMLAN OG_HMLAN UNKNOWNCODE A11B8A00234959C34600404DC749554B43502::-103:OG_HMLAN
2017-01-03 18:07:48 HMLAN OG_HMLAN UNKNOWNCODE A0EB8800234959C34600400A5368025::-104:OG_HMLAN
2017-01-03 18:07:48 HMLAN OG_HMLAN UNKNOWNCODE A11B9A00234959C34600404B8DD3CDFE11602::-102:OG_HMLAN
2017-01-03 18:07:48 HMLAN OG_HMLAN UNKNOWNCODE A0EB9800234959C34600400C7B5A9C4::-103:OG_HMLAN
2017-01-03 18:07:49 HMLAN OG_HMLAN UNKNOWNCODE A0C37A01134959C2FBEE6820A00::-102:OG_HMLAN
2017-01-03 18:07:49 HMLAN OG_HMLAN UNKNOWNCODE A0A3780022FBEE634959C00::-97:OG_HMLAN
2017-01-03 18:07:49 HMLAN OG_HMLAN UNKNOWNCODE A0C40A01134959C2FBEE6800A01::-100:OG_HMLAN
2017-01-03 18:07:49 HMLAN OG_HMLAN UNKNOWNCODE A124080022FBEE634959C010A01002BAEA7AAAA::-96:OG_HMLAN
2017-01-03 18:07:49 HMLAN OG_HMLAN UNKNOWNCODE A0C49A01134959C2FBEE6820A00::-102:OG_HMLAN
2017-01-03 18:07:49 HMLAN OG_HMLAN UNKNOWNCODE A0A4980022FBEE634959C00::-97:OG_HMLAN
2017-01-03 18:07:49 HMLAN OG_HMLAN UNKNOWNCODE A0C52A01134959C2FBEE6800A03::-102:OG_HMLAN
2017-01-03 18:07:49 HMLAN OG_HMLAN UNKNOWNCODE A125280022FBEE634959C010A03002BAEAFAAAA::-97:OG_HMLAN
Und jede Menge mehr. Wie man sieht ist da ganz schön was los auf dem Bus.
Löst jedes dieser Messages jedesmal die komplette event und notify Maschine von FHEM aus? Wenn ja, wäre ja der Horror bezgl. Rechenlast
ich habe zwar noch nie hmip-messages gesehen, aber diese hier scheinen "normale" messages zu sein, auch einige aes-signierungen. fraglich, ob hmip-messages überhaupt über hmlan zu monitoren wären.
wenn deine hmlan mit neuer fw deutlich weniger reboots haben, könnte das natürlich ein hinweis auf hmip beim nachbar sein.
richte dir eine vccu ein, wie im wiki beschrieben, dann werden die messages frühzeitig aussortiert. in der vccu wird dann für jedes unbekannte device ein reading erscheinen.
Hi Frank,
Danke für die schnelle Antwort. Laut Logfile war bisher seit FW Update nur ein disconnect. Ich kreuze mal die Finger, dass das auch so bleibt.
VCCU habe ich gerade im Wiki durch gelesen. Hat natürlich auch den schicken Nebenvorteil, dass dann das Pairing in Software ist und nicht bei einem Ausfall des HMLAN verloren ist. Heißt aber auch, dass ich alle Devices neu Pairen muß, oder? Ich habe alleine 18 Rolladen-Aktoren mit teilweise Eigenbau Frontblenden. Das ist min. ein halber Tag Arbeit im Haus :-(
Zitat von: bugster_de am 03 Januar 2017, 19:45:42
Hi Frank,
Danke für die schnelle Antwort. Laut Logfile war bisher seit FW Update nur ein disconnect. Ich kreuze mal die Finger, dass das auch so bleibt.
VCCU habe ich gerade im Wiki durch gelesen. Hat natürlich auch den schicken Nebenvorteil, dass dann das Pairing in Software ist und nicht bei einem Ausfall des HMLAN verloren ist. Heißt aber auch, dass ich alle Devices neu Pairen muß, oder? Ich habe alleine 18 Rolladen-Aktoren mit teilweise Eigenbau Frontblenden. Das ist min. ein halber Tag Arbeit im Haus :-(
Das pairing unterscheidet sich nicht! Und Du musst nichts neu machen! Du gibst der VCCU die HMID von Deinem HMLAN.
Pairing bedeutet am Ende immer, das beide Seiten die HMID kennen. Sie wird im Gerät eingetragen und der HMALN bekommt sie von seiner Definition in "FHEM" oder von der DEF der VCCU. Logisch gesehen das Gleiche.
Gruß Otto
Hi,
Kommando zurück: habe mich zu früh gefreut. Seit 20:10h sind die disconnects wieder da.
Ich glaube ich mache jetzt mit dem HM Zeugs nur noch eines: die Entscheidung treffen ob gelbe oder schwarze Tonne ....
Um Netzwerkprobleme nochmal auszuschliessen habe ich vom Server im Keller ein 16 GB große Video Datei sowie ca. 500 kleine 1KB große Files über das Netzwerk geladen. Diese Daten gehen den gleichen weg über den Switch etc. wie der Weg vom FHEM-Pi zum HMLAN. Kein Zusammenhang zwischen dem Disconnect und Netzwerklast erkennbar. Während der ca. 5 Minuten Transferzeit der Dateien war kein Disconnect. Ich würde daher also LAN Probleme mal ausschliessen.
Danke für den Hinweis mit der ID. Ich spiele jetzt mal mit der VCCU rum; mal sehen ob das was bringt, da ja dann die Events weg sind.
EDIT:
ich habe jetzt mal eine VCCU angelegt nach folgendem Vorgehen
- HMID des HMLAN auf irgendwas umgestellt --> Rolläden gehen wie erwartet nicht mehr via FHEM
- VCCU nach WIKI angelegt. Bisherige HMID des HMLAN zugewiesen und HMLAN in der IOList eingetragen --> --> HMLAN geht auf die HMID der VCCU --> Rolläden kann man wieder schalten (wie erwartet)
Das kann doch nicht so einfach sein, oder? Muß ich bei meinen Homematic Devices nun auch das IODevice auf die VCCU umstellen?
Ist so einfach!
Steht alles im Wiki! IODev musst Du nicht ändern wird ignoriert. IOgrp musst Du einrichten, steht auch im Wiki.
Bloß weil Du ein Problem mit HMLAN hast, ist es nicht unbedingt für die Tonne. Ich habe seit Jahren null Probleme mit HMLAN.
Gruß Otto
Ich weise mal wieder darauf hin, dass man unterscheiden muss ob es Disconnects sind die z.B. durch Timeouts im Fhem entstehen oder ob der HMLAN gebootet hat (das kann man sehr schnell an der Uptime des HMLAN sehen) was dann in der Folge zu dem Disconnect führt.
Gründe für den Reboot gibt es wohl einige ... eQ3 hatte aufgrund von LAN-Sniffs bei mir (mindestens) einen Fehler gefunden ... jetzt warten wir aber schon ewig auf die Veröffentlichung der neuen Version
Hi,
Status: heute Nacht gab es keine disconnects mehr. Logfile war clean heute morgen. Die disconnects haben gegen 23:30h aufgehört. Ich habe gegen 0:30h meinen PC runter gefahren, sprich ich war noch bei uns im Haus im LAN aktiv.
VCCU: habe mir das Wiki noch min 5 mal durch gelesen und dann das umgesetzt, was ich davon glaubte verstanden zu haben. Sprich bei jedem HM Device habe ich die IOGrp und das IODev auf die VCCU umgestellt. Dauert dann pro device ca 1 Min, bis es wieder reagiert, aber dann geht es. Danke für eure Geduld ! Ich glaube ich habe das jetzt so alles richtig auf VCCU umgestellt.
ZitatIst so einfach!
Stimmt. Und es beweist sich mal wieder: kaum macht man's richtig tut's auch schon :-)
ZitatIch weise mal wieder darauf hin, dass man unterscheiden muss ob es Disconnects sind die z.B. durch Timeouts im Fhem entstehen oder ob der HMLAN gebootet hat (das kann man sehr schnell an der Uptime des HMLAN sehen) was dann in der Folge zu dem Disconnect führt.
Stimmt. Ich mache mir heute abend mal ein FileLog, der die Uptime loggt, denn weder apptime noch der Eventmonitor haben Hinweise auf einen Timeout auf FHEM Seiten geliefert.
Weiterer Grund kann natürlich auch am Netzwerk liegen (Auslastung / Überlastung), oder?
Mülltonne: da habe ich mehrere Anmerkungen / Gründe dafür
- mein Homematic scheint so eine Art telepathische Angewohnheit zu haben: immer wenn es am besten einfach funktionieren sollte (weil z.B. Weihnachten ist und wir die ganze Familie im Haus haben) oder ich z.B. wegen Geschäftsreise nicht zu Hause bin, dann tritt der Effekt mit den disconnects auf. Der WAF sinkt dadurch erheblich
- wie programmiert man eine Firmware, die bei Empfangen von neuen Funk-Messages (HM Ip) sich resettet? Ein Feature wird das wohl eher nicht sein, oder? Mein Bauchgefühl zur Qualität der HM Firmware sagt mir da nix Gutes. Und wie soll Otto-Normalanwender als Käufer von Homematic Geräten denn auf sowas kommen? Wir hier im Forum sind mit FHEM ja durch die Natur der Sache näher an der Technik aber Lieschen Müller wäre bei so einem Effekt doch komplett verloren. Und ohne eure Hilfe würde ich mir ebenfalls den Wolf suchen.
- die Qualität mancher HM Geräte ist doch "schwankend". Ich habe nun z.B. den zweiten, defekten Aussentemp Sensor (HM-WDS30-TO). Der erste war nach einem Jahr (!) innen drin komplett vergammelt, da es keinerlei Entlüftung gibt und sich somit Kondenswasser bildet und die Antenne einfach abrostet. Den zweiten habe ich dann mit einer kleinen Neopren Entlüftung versehen und mit Gussmasse verfüllt. der ist letzte Woche einfach so gestorben und lässt sich nicht mehr zum Leben erwecken. Ich habe nun bereits drei Rolladne-Unterputz Aktoren neu gekauft, da die bestehenden Geräte nach ca. 9 Monaten dauernd nicht mehr erreichbar waren. Neue gekauft gut ist. Andere Geräte laufen seit Jahren mit immer noch dem ersten Satz Batterien einwandfrei.
- last but not least werde ich bei HM immer den Eindruck nicht los, dass das von Ingenieuren für Ingenieure ist (bin selber einer) und wir Ing. haben ja oftmals die unschöne Angewohnheit dass wir einen Fachbegriff mit einem anderen Fachbegriff erklären. Eigentlich will ich ja nur meine Rolläden hoch und runter fahren und, Achtung Ironie, nicht auf dem Thema "HM Systemarchitektur" promovieren
Hilft aber alles nix: die Alternativen haben alle noch mehr Nachteile (z.B. keinen Rückkanal) und Kabelgebundene Anbindung habe ich bei mir im Haus halt nicht. Sprich ich fuchse mich da halt weiter rein.
Zitatjetzt warten wir aber schon ewig auf die Veröffentlichung der neuen Version
siehe meine Anmerkung zur Qualität der Firmware :-)
Hi,
ZitatSprich bei jedem HM Device habe ich die IOGrp und das IODev auf die VCCU umgestellt.
wie schon gesagt ->
ZitatMit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr. Vielmehr setzt die VCCU das IODev automatisch je nach Verfügbarkeit und Funklage. Es ist jedoch nicht erforderlich angelegte IODev Attribute zu entfernen.
Da muss man nix tun.
Der folgende Befehl macht es relativ einfach und eine 1 minütige nicht Reaktion habe ich bei mir nicht gemerkt
attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp VCCUMan muss nur die 6 Punkte verstehen :D was mir als nicht regExp(erte) nicht auf Anhieb gelang.
Jetzt wo Du eine VCCU hast kannst Du doch einfach einen zweiten IO dazu tun, das mit der Firmware wird sowieso nix mehr, der HMLAN ist "durch" und die Firmware trug nie eine 1 :-X
Gruß Otto
ZitatMan muss nur die 6 Punkte verstehen :D was mir als nicht regExp(erte) nicht auf Anhieb gelang.
die drei Punkte waren so ziemlich das Einzige, was ich in dem WIKI Artikel auf Anhieb verstanden hatte :-)
Zitatjetzt wo Du eine VCCU hast kannst Du doch einfach einen zweiten IO dazu tun,
ist schon bestellt :-) Great minds think alike
Zitat von: bugster_de am 04 Januar 2017, 10:03:13
Weiterer Grund kann natürlich auch am Netzwerk liegen (Auslastung / Überlastung), oder?
Ein bekanntes Problem sind Multicasts di z.B. beim IP-TV verwendet werden ... bei den von mir gesnifften Problemen war es ein Timingproblem wo der HMLAN auf dem LAN auf etwas von der Zentrale, also Fhem, wartete und dann ein anderes Paket dazwischen kam wodurch der HMLAN abstürzte
soderle
1. kein disconnetc seit 23:30h letzte Nacht. Also fast 24h !
2. Uptime zeigt bereits 27h an. Also auch kein reset
Sieht mal sehr gut aus.
ZitatEin bekanntes Problem sind Multicasts di z.B. beim IP-TV verwendet werden
naja, dann wäre ich aber ganz vorne dabei. Wir schauen seit Jahren nur noch per IPTV (TVHeadend Server im Keller und KODIs and den TVs); da ist es nicht so selten, dass auf bis zu drei Geräten TV geschaut wird. Hatte ich bisher keine Probleme
Zitat von: bugster_de am 04 Januar 2017, 22:23:36
Wir schauen seit Jahren nur noch per IPTV (TVHeadend Server im Keller und KODIs and den TVs); da ist es nicht so selten, dass auf bis zu drei Geräten TV geschaut wird. Hatte ich bisher keine Probleme
Dann hast du vermutlich einen Switch, der Multicasts richtig handelt und IGMP richtig unterstützt ... nach Austausch eines Switches ging bei mir die Rebootrate von ca. alle 5 Minuten (aber nicht 24 h am Tag sondern nur zu bestimmten Zeiten) auf alle paar Wochen mal zurück.
ja, bei dem zentralen Switch habe ich mich nicht Lumpen lassen. Ist ein Semi-Profi, managable switch mit 16 Ports. Bringt mir ja nichts, wenn ich schon den Aufwand mache im Haus Ethernet Kabel zu verlegen und dann mit einem 10,- € Switch vom Elektronik-Discounter wieder alles zu Nichte mache. Ehrlicherweise hatte ich mich aber nicht damit beschäftigt, ob der Switch das nun alles richtig kann sondern habe mich eher auf das Prinzip "höherer Preis wird schon auch besser sein" verlassen :-)
Interessanterweise hatte aber wohl die Fritzbox bei den Versionsnummer 5.x der FW einige Probleme mit Multicast vorallem ins WLAN. Ist aber seit den >V6.2 Versionen auch alles gut.
Hallo Leute,
ich wollte mal kurz den Stand der Dinge berichten:
- ich habe mir jetzt zwei Funk-LAN Gateways zugelegt. Einen für OG, einen für EG
- ich habe wie hier beschrieben alles auf eine VCCU umgestellt
Das Ding läuft jetzt seit Wochen wie geschnitten Brot. Keine disconnects, alles gut ! Sogar die Rollaend Aktoren, die im Laufe der Zeit immer wieder Probleme mit MISSING ACK hatten laufen einfach durch.
Danke für die Tips hier !