Hallo Seit ein paar Tagen habe ich jede Nacht zur gleichen Zeit ein HMLan disconnected. Der HMLan hängt an einer Fritzbox der als Server im Netzwerk dient.
Kann mir jemand helfen?
Danke
Hm. Meiner laeuft durch. Hast du einen job laufen, der um die zeit das system blockiert ?
Danke für Den Tip. Ich lasse um diese Zeit die Sicherung der MySQL laufen. Aber nicht aus Fhem heraus! Aber warum kommt es zu einem disconnect?
Passiert bei mir auch immer, wenn in der Nacht das Backup läuft.....
Aber nicht erst seit kurzem, sondern das hab ich schon immer, seit das Backup läuft.
lg, Ici
ZitatAber warum kommt es zu einem disconnect?
wenn für 30 sekunden keine verbindung zwischen hmlan und fhem hergestellt werden kann.
Schaut euch mal das Internal uptime vom HMLAN an ... bei mir macht der HMLAN regelmäßig einen reboot. Ich vermute, dass das an bestimmten Paketen auf dem LAN bzw. hohem Traffic liegt ... aus meiner Sicht ein Firmware-Bug des HMLAN >:(
das HMLAN macht einen reboot, wenn es 30sec keine Zentrale findet. FHEM sendet das keepalive nach 25 sec. Bleiben also noch 5 sec zum reagieren - im schlechtesten Fall
Zitat von: martinp876 am 14 Juni 2015, 19:54:41
das HMLAN macht einen reboot, wenn es 30sec keine Zentrale findet. FHEM sendet das keepalive nach 25 sec. Bleiben also noch 5 sec zum reagieren - im schlechtesten Fall
Wie kommst du darauf ?
Mach mal folgenden Test: schau dir die Uptime vom HMLAN an (war bei mir 01:56:12.365) ... dann stoppe FHEM ... warte 1 Minute starte FHEM wieder
Was zeigt die uptime von HMLAN bei dir jetzt an ? bei mir waren es eben 1:58.32.735 ... also kein reboot obwohl deutlich länger als 30 Sekunden die Zentrale nicht erreichbar war
Und wer bitte soll ein keepalive schicken wenn du fhem stoppst??? Das ist ein völlig anderer Sachverhalt. Lass fhem mal laufen und trenn die Netzwerkverbindung zum HMLAN, dass kommt der Sache schon näher.
VG
Frank
Genau das ist ja der Sinn gewesen ... wenn FHEM nicht läuft wird KEIN keepalive gesendet ... ich wollte damit zeigen, dass der HMLAN NICHT bootet wenn er kein keepalive erhält
Aber mit Abziehen der LAN-Verbindung (für 1 Minute) verhält er sich genauso: uptime vorher 12:42:57.545, nachher 12:44:46.586
@nobby1805,
ein echter reboot ist bisher nur durch netzstecker ziehen bekannt. dann wird auch uptime resettet. wenn du auch ohne stecker ziehen reboots erlebst, hast du vielleicht einen wackelkontakt in der spannungsversorgung. ansonsten solltest du das verhalten vielleicht mal im netzwerk sniffen. dann könnte man vielleicht auch einen echten reboot über fhem forcieren.
Zitat von: frank am 15 Juni 2015, 10:51:52
ein echter reboot ist bisher nur durch netzstecker ziehen bekannt. dann wird auch uptime resettet. wenn du auch ohne stecker ziehen reboots erlebst,
definitiv habe ich den Netzstecker nicht gezogen
Zitat von: frank am 15 Juni 2015, 10:51:52
hast du vielleicht einen wackelkontakt in der spannungsversorgung.
hmmm ... halte ich für eher unwahrscheinlich ... hängt am selben Verteiler wie der Server, muss ich mal drüber nachdenken wie ich das evt. messen kann
Zitat von: frank am 15 Juni 2015, 10:51:52
ansonsten solltest du das verhalten vielleicht mal im netzwerk sniffen. dann könnte man vielleicht auch einen echten reboot über fhem forcieren.
Sniffer läuft ... aber was soll es bringen einen reboot über FHEM zu forcieren ?
Zitataber was soll es bringen einen reboot über FHEM zu forcieren ?
dann könnte man auch einen overload (1% sendelimit) automatisch über fhem zurücksetzen.
Zitat von: frank am 15 Juni 2015, 13:09:26
dann könnte man auch einen overload (1% sendelimit) automatisch über fhem zurücksetzen.
ich glaube nicht, dass so ein overload der Grund ist ... bei mir wird vom HMLAN fast nur empfangen (msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0 )
ich meine nicht, dass
dein problem damit gelöst werden könnte. sondern, ...
Zitat von: Nobby1805 am 14 Juni 2015, 11:48:22
Schaut euch mal das Internal uptime vom HMLAN an ... bei mir macht der HMLAN regelmäßig einen reboot. Ich vermute, dass das an bestimmten Paketen auf dem LAN bzw. hohem Traffic liegt ... aus meiner Sicht ein Firmware-Bug des HMLAN >:(
... ,wenn deine vermutung stimmt, könnte man das ja ausnutzen. ;)
btw. kannst du mir folgendes Internal erläutern ?
msgParseDly min:-4952 max:42110 last:-3 cnt:10214
prinzipiell weiß ich (vermutlich) schon was das sein soll, aber woher kommen die negativen Werte ?
Kann ich gerade nicht sagen. Es wird aus den alten empfangswerten, timestamps des io und den altuellen uhrzeiten generiert.
Wenn du grosse delays hast, worauf die delays hindeuten koennte es zu seltsamen werten kommen
Ich habe mein Problem in den letzten Wochen weiter verfolgt und bin jetzt an einer Stelle, wo ich Hilfe zu Fhem benötige. Aber zuerst einmal ein kurze Zusammenfassung der letzten Wochen
Ich habe das Problem im ELV-Forum beschrieben http://www.elv.de/topic/hm-lan-reboots.html (http://www.elv.de/topic/hm-lan-reboots.html) und als Antwort bekommen, dass der HMLAN vermutlich defekt ist und mir ein Austausch angeboten worden ist. Da ich den HMLAN nicht bei ELV gekauft hatte und auch eine Modifikation (externe Antenne) durchgeführt habe war das so nicht möglich und ich habe eine neuen HMLAN bei ELV bestellt.
Der wurde schon am nächsten Tag geliefert und ich habe ihn sofort in mein System integriert. Bereits nach wenigen Stunden trat das Problem an beiden HMLANs auf >:( Das Problem ist nie gleichzeitig bei beiden aufgetreten, aber ich habe den Eindruck, dass oft (aber nicht immer) zwischen dem Reboot der beiden HMLANs nur wenige Minuten lagen.
Ich habe dann im nächsten Schritt den neuen HMLAN wieder aus dem Fhem entfernt aber am Netzwerk gelassen. Mit einem Netzwerk-Scanner Monitore ich die Reboots bei denen bestimmte Broadcast-Pakete gesendet werden ... der 2. HMLAN läuft seit dem ohne Reboot durch, der andere (am Fhem) wurde seit dem ca 15-20 mal rebootet.
Seit gestern suche ich im Netz nach Dokumentation zum HMLAN und habe inzwischen gefunden, wie man per Telnet zugreifen kann. Dort kann man die einzelnen Datagramem sehr gut sehen und mir sind ZWEI Stellen aufgefallen zu denen ich einen Bestätigung meiner Vermutung bzw. Interpretationshilfe benötige
1. Bei folgender Nachricht gibt es einen kleinen Unterschied zwischen HMLAN1 und HMLAN2 HHM-LAN-IF,03C4,LEQ0579416,2BA0A8,2AEDA2,042C271D,000C,01HHM-LAN-IF,03C4,LEQ0579235,2BB5AD,2AEDA2,0CE1F2D2,0000,00
Die Bedeutung der ersten Zeile ist mir (glaube ich) klar ... der vorletzte Wert gibt m.E. die Anzahl der dem HMLAN zugeordneten IDs an, 12 beim HMLAN1 und keine ID beim HMLAN2, richtig? Aber was bedeutet der letzte Wert, 1 bzw. 0 ?
2. im Telnet-Log treten ab und zu, manchmal nach mehreren Minuten, manchmal sehr schnell nacheinander, Nachrichten auf, die keine bekannte ID enthalten.
E3141E8,0000,0CE78D93,FF,FFA3,34865A3141E8000000A8F232
E1DB9FF,0000,0CE79F5F,FF,FF96,52A1121DB9FF1D8F02
E1DB9FF,0000,0CE7A06E,FF,FF94,33A0111DB9FF1D8F02020200
E2BBF2B,0000,0CE7B137,FF,FFD1,2A86702BBF2B00000000A456
3141E8 und 2BBF2B sind bekannt und assignedIDs des HMLAN1, aber was ist 1DB9FF? Wie kann man das herausfinden?
Einmal habe ich zufällig bei erhöhtem verbose im Log etwas zeitgleich gefunden, dass ein I:K gesendet worden ist ... aber ich dachte, das passiert nicht so häufig und auch regelmäßig.
Alles normal. 01 ist die msgload.
Die k sind interessant. Kommen die antworten praezise ?
Was sagt apptime ?
Zitat von: martinp876 am 08 Juli 2015, 21:24:57
Die k sind interessant. Kommen die antworten praezise ?
Der Zusammenhang zwischen der unbekannten ID 1DB9FF und dem k ist ja nur eine Vermutung? Die Frage ist doch, woher kommen die 1DB9FF?
Wenn ich mit einem Netzwerk-Scanner schaue dann finde ich die K-Pakete mit einem Abstand zwischen 24,3 und 25,81 Sekunden ...
Zitat von: martinp876 am 08 Juli 2015, 21:24:57
Was sagt apptime ?
alles sauber
ZitatDie Frage ist doch, woher kommen die 1DB9FF?
frage mal deinen nachbarn. das könnte seine zentrale sein. sorgen musst du dir machen, wenn 1D8F02 zu dir gehört.
Zitat von: frank am 09 Juli 2015, 00:06:44
frage mal deinen nachbarn. das könnte seine zentrale sein. sorgen musst du dir machen, wenn 1D8F02 zu dir gehört.
Wieso Zentrale? Könnte es nicht irgendein Sensor sein?
... und wie kommst du auf 1D8F02?
Edit: Hmm, ich glaube ich ahne jetzt was du meinst ....
Die beiden Datagramme etwas formatiert ...
E1DB9FF,0000,0CE79F5F,FF,FF96,52A112 1DB9FF 1D8F02
E1DB9FF,0000,0CE7A06E,FF,FF94,33A011 1DB9FF 1D8F02 020200und da ist auch die 1D8F02 8)
Gibt es irgendwo eine Doku mit der man den Rest verstehen kann ?
ZitatGibt es irgendwo eine Doku mit der man den Rest verstehen kann ?
00_HMLAN.pm, 10_CUL_HM.pm, AskSin-lib. sniffe mit fhem und setze das attr hmlan hmProtocolEvents zum testen. dann werden die messages in fhem.log etwas lesbarer.
frag bei eq3 nach. angeblich wollten die sich ja mal "öffnen". ;)
Ist eine zentrale, die infos loswerden will. Den partner scheinst du nicht zu empfangen. Auf der anderen hausseite ?
Zitat von: martinp876 am 09 Juli 2015, 21:52:59
Ist eine zentrale, die infos loswerden will.
und woran erkennt man das?
Zitat von: martinp876 am 09 Juli 2015, 21:52:59
Den partner scheinst du nicht zu empfangen. Auf der anderen hausseite ?
Das würde dann auch erklären, warum der andere HMLAN diese Daten nicht empfängt ... da muss ich mal die Nachbarn befragen
Also vermutlich alles kein Grund für die andauernden Boots des HMLAN? :(
Man muss die messages verstehen ..
Die messages sollten kein grund fuer ein disconnect sein.
Zitat von: Nobby1805 am 08 Juli 2015, 20:09:00
Ich habe mein Problem in den letzten Wochen weiter verfolgt und bin jetzt an einer Stelle, wo ich Hilfe zu Fhem benötige. Aber zuerst einmal ein kurze Zusammenfassung der letzten Wochen
Ich habe das Problem im ELV-Forum beschrieben http://www.elv.de/topic/hm-lan-reboots.html (http://www.elv.de/topic/hm-lan-reboots.html) und als Antwort bekommen, dass der HMLAN vermutlich defekt ist und mir ein Austausch angeboten worden ist. Da ich den HMLAN nicht bei ELV gekauft hatte und auch eine Modifikation (externe Antenne) durchgeführt habe war das so nicht möglich und ich habe eine neuen HMLAN bei ELV bestellt.
Der wurde schon am nächsten Tag geliefert und ich habe ihn sofort in mein System integriert. Bereits nach wenigen Stunden trat das Problem an beiden HMLANs auf >:( Das Problem ist nie gleichzeitig bei beiden aufgetreten, aber ich habe den Eindruck, dass oft (aber nicht immer) zwischen dem Reboot der beiden HMLANs nur wenige Minuten lagen.
Ich habe dann im nächsten Schritt den neuen HMLAN wieder aus dem Fhem entfernt aber am Netzwerk gelassen. Mit einem Netzwerk-Scanner Monitore ich die Reboots bei denen bestimmte Broadcast-Pakete gesendet werden ... der 2. HMLAN läuft seit dem ohne Reboot durch, der andere (am Fhem) wurde seit dem ca 15-20 mal rebootet.
Ich habe inzwischen ein Ticket bei ELV eröffnet weil auch der neue HMLAN nach einigen Tagen das selbe Problem gezeigt hat.
Auf Bitte von ELV habe ich den 2. HMLAN in ein anderes LAN gesetzt, er ist jetzt nur noch mit einem freien LAN-Port eines PCs verbunden auf dem ein Monitor läuft der alle Messages vom HMLAN protokolliert ... seit über 300 Stunden kein Reboot.
ELV hat inzwischen ein Ticket bei eQ3 eröffnet und ich habe weitere Informationen zum Problem geliefert ... immerhin: es tut sich etwas ;)
Heute kam folgende Info von ELV
Zitatdas Verhalten konnte nun doch vom Hersteller eQ-3 reproduziert werden und wird in einem kommenden Update behoben. Wir empfehlen Ihnen, in regelmäßigen Abständen im eQ-3 Download-Bereich nach dem Update zu schauen, da aktuell leider noch kein Release-Termin vorliegt.
das hört sich ja erst einmal vielversprechend an. fw update, obwohl der hmlan schon fast ausgemustert ist und der fehler wohl hauptsächlich in fhem installationen aufzutreten scheint.
eben war noch kein update zu finden. ;)
Zitat von: frank am 10 November 2015, 11:34:32
... und der fehler wohl hauptsächlich in fhem installationen aufzutreten scheint.
ich habe den Fehler auch ohne FHEM reproduzieren können ... ok "reproduzieren" ist nicht ganz richtig ... regelmässig erleiden können ;)
Zitat
eben war noch kein update zu finden. ;)
vielleicht liegt der Patch dann unter der Tanne ;)
Zitat... regelmässig erleiden können
im einsatz mit ccu?