Hab ich heute irgendeinen Problem-Thread übersehen? Seit dem Update heute läuft mein Log über.
2014-01-22 21:32:07 HMLAN HMUSB DISCONNECTED
2014-01-22 21:32:07 HMLAN HMUSB cond: disconnected
2014-01-22 21:32:07 HMLAN HMUSB Xmit-Events: disconnected:1
2014-01-22 21:32:07 HMLAN HMUSB prot_disconnected: last
2014-01-22 21:32:07 HMLAN HMUSB cond: init
2014-01-22 21:32:07 HMLAN HMUSB Xmit-Events: init:1
2014-01-22 21:32:07 HMLAN HMUSB prot_init: last
2014-01-22 21:32:07 HMLAN HMUSB CONNECTED
2014-01-22 21:32:26 HMLAN HMUSB DISCONNECTED
2014-01-22 21:32:26 HMLAN HMUSB cond: disconnected
2014-01-22 21:32:26 HMLAN HMUSB Xmit-Events: disconnected:1
2014-01-22 21:32:26 HMLAN HMUSB prot_disconnected: last
2014-01-22 21:32:26 HMLAN HMUSB cond: init
2014-01-22 21:32:26 HMLAN HMUSB Xmit-Events: init:1
2014-01-22 21:32:26 HMLAN HMUSB prot_init: last
2014-01-22 21:32:26 HMLAN HMUSB CONNECTED
2014-01-22 21:32:27 HMLAN HMUSB DISCONNECTED
2014-01-22 21:32:27 HMLAN HMUSB cond: disconnected
2014-01-22 21:32:27 HMLAN HMUSB Xmit-Events: disconnected:1
2014-01-22 21:32:27 HMLAN HMUSB prot_disconnected: last
2014-01-22 21:32:27 HMLAN HMUSB cond: init
2014-01-22 21:32:27 HMLAN HMUSB Xmit-Events: init:1
2014-01-22 21:32:27 HMLAN HMUSB prot_init: last
2014-01-22 21:32:27 HMLAN HMUSB CONNECTED
Zusatzinfo:
# $Id: 00_HMLAN.pm 4685 2014-01-18 14:06:50Z martinp876 $
Mit dieser vorherigen Version sind die Fehlermeldungen verschwunden und alles funktioniert.
Ich hatte ebenfalls Probleme nach dem Update.
2014.01.22 21:13:48 1: 192.168.2.46:1000 disconnected, waiting to reappear
2014.01.22 21:13:48 1: HMLAN_Parse: HMLAN new condition disconnected
2014.01.22 21:13:48 1: 192.168.2.46:1000 reappeared (HMLAN)
2014.01.22 21:13:48 5: HMLAN_Send: HMLAN I:A639087
2014.01.22 21:13:48 5: HMLAN_Send: HMLAN I:C
2014.01.22 21:13:48 5: HMLAN_Send: HMLAN I:Y01,00,
2014.01.22 21:13:48 5: HMLAN_Send: HMLAN I:Y02,00,
2014.01.22 21:13:48 5: HMLAN_Send: HMLAN I:Y03,00,
2014.01.22 21:13:48 5: HMLAN_Send: HMLAN I:Y04,00,
2014.01.22 21:13:48 5: HMLAN_Send: HMLAN I:Y05,00,
2014.01.22 21:13:48 1: HMLAN_Parse: HMLAN new condition init
2014.01.22 21:13:48 5: HMLAN_Send: HMLAN S:SBB965695 stat: 00 t:00000000 d:01 r:BB965695 m:99 8112 639087 000001
2014.01.22 21:13:49 1: 192.168.2.46:1000 disconnected, waiting to reappear
2014.01.22 21:13:49 1: HMLAN_Parse: HMLAN new condition disconnected
2014.01.22 21:13:49 1: 192.168.2.46:1000 reappeared (HMLAN)
2014.01.22 21:13:49 5: HMLAN_Send: HMLAN I:A639087
2014.01.22 21:13:49 5: HMLAN_Send: HMLAN I:C
2014.01.22 21:13:49 5: HMLAN_Send: HMLAN I:Y01,00,
2014.01.22 21:13:49 5: HMLAN_Send: HMLAN I:Y02,00,
2014.01.22 21:13:49 5: HMLAN_Send: HMLAN I:Y03,00,
2014.01.22 21:13:49 5: HMLAN_Send: HMLAN I:Y04,00,
2014.01.22 21:13:49 5: HMLAN_Send: HMLAN I:Y05,00,
2014.01.22 21:13:49 1: HMLAN_Parse: HMLAN new condition init
2014.01.22 21:13:49 5: HMLAN_Send: HMLAN S:SBB965A70 stat: 00 t:00000000 d:01 r:BB965A70 m:99 8112 639087 000001
2014.01.22 21:13:50 5: HMLAN_Parse: HMLAN V:03C3 sNo:JEQ0700622 d:1EBD8A O:639087 t:00000283 IDcnt:0000
2014.01.22 21:14:07 1: 192.168.2.46:1000 disconnected, waiting to reappear
Hallo
Bei mir fing das gestern nach einem Update so an
http://forum.fhem.de/index.php/topic,19112.0.html (http://forum.fhem.de/index.php/topic,19112.0.html)
Seit einem erneuten Update heute morgen exakt das gleiche wie bei euch beiden.
Die gestrigen totalen Abstürze von fhem haben einen ganz schön nervös gemacht zumal man neue
Komponenten pairen wollte und nichts wie gewohnt funktionierte.
Aber da es hier im Forum Leute gibt, die exakt das gleiche Problem haben, kann es nur am Update liegen.
Gruß Rainer
Same Problem here. Jede Minute disconnected der HMLAN. Es beginnt nach dem Neustart des Servers. Wenn man aber ein anderes Gerät über das Netzwerk schaltet, hört es auf. Sehr komisch.
Gruß
G.
Hi,
ich habe einen update rein gestellt.
Der Unterschied den ich sehe liegt in der Anzahl der AES keys, die ich von 3 auf 5 erhöht habe.
Mein HMLAN nimmt die ohne Probleme... seltsam.
ich hoffe, dass dies das Problem war.
hat es Probleme nur mit hmUSB gebeben oder auch mit HMLAN? wenn ja, welche FW version läuft im HMLAN?
Gruss Martin
Hallo Martin, hatte eine andere Auswirkung. Siehe http://forum.fhem.de/index.php/topic,19106.msg127898.html#msg127898
Habe ein HMLAN.
Hi Olaf,
kann ich mir nicht erklären.... hatte ich nicht beobachtet.
mache doch einmal einen update - einfach alle files. Oder - falls du immer teil-updates machst besser einen update force .
Lass hören ob es dann geht .
Gruss Martin
Hallo und einen wunderbaren schönen Morgen.
Nach dem Update läuft alles wieder wie es soll.
Schönen Dank noch.
MfG Rainer
Der letzte Stand den ich sehe, ist die r4718. Bei mir besteht damit das Problem weiterhin.
Gibt es einen neueren Stand?
Viele Grüße,
Veit
4718 ist der letzte.
kannst du ein log machen?
So lief das auch nach dem Update und shutdown restart im Sekundentakt:
2014.01.23 08:52:21 1: 127.0.0.1:1234 disconnected, waiting to reappear
2014.01.23 08:52:21 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 08:52:21 1: 127.0.0.1:1234 reappeared (hmusb)
2014.01.23 08:52:21 1: HMLAN_Parse: hmusb new condition init
2014.01.23 08:52:22 1: 127.0.0.1:1234 disconnected, waiting to reappear
2014.01.23 08:52:22 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 08:52:22 1: 127.0.0.1:1234 reappeared (hmusb)
2014.01.23 08:52:22 1: HMLAN_Parse: hmusb new condition init
2014.01.23 08:52:23 1: 127.0.0.1:1234 disconnected, waiting to reappear
2014.01.23 08:52:24 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 08:52:24 1: 127.0.0.1:1234 reappeared (hmusb)
2014.01.23 08:52:24 1: HMLAN_Parse: hmusb new condition init
2014.01.23 08:52:24 1: 127.0.0.1:1234 disconnected, waiting to reappear
2014.01.23 08:52:25 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 08:52:25 1: 127.0.0.1:1234 reappeared (hmusb)
2014.01.23 08:52:25 1: HMLAN_Parse: hmusb new condition init
Ichhabe jetzt den Releasestand 4685 nach betateilchens finding wieder eingespielt, komplette Fritzbox einmal durchgestartet und alles ist schick.
Vielleicht komme ich heute abend dazu ein paar weitere Tests und Logs zu machen.
Gruß,
Veit
Hallo Martin,
ZitatHi Olaf,
kann ich mir nicht erklären.... hatte ich nicht beobachtet.
mache doch einmal einen update - einfach alle files. Oder - falls du immer teil-updates machst besser einen update force .
Lass hören ob es dann geht .
wie oben im Link geschrieben war der Fehler nach einem kompletten update behoben.
VG
Olaf
hi Veit,
ich habe eine weitere Version eingescheckt - die dortige timerüberwachung hat erst einmal nichts mit deinem Problem zu tun.
Ich gehe davon aus, dass es ein Problem den 00_HMLAN ist -aber ich verstehe, dass du die gesamte Version zurückgedreht hast.
Der Unterschied in HMLAN war, dass 5 AES keys übertragen wurden, das sollte heute Morgen wieder auf 3 zurückgestellt sein.
Der einzige Unterschied ist dann noch, dass das setzen der Zeit gefehlt hat... ist in V4721 auch wieder drin.
Du hast also ein USB... vielleicht können die weniger - oder arbeiten einfach anders in einigen Details...
Offensichtlich verabschiedet sich dein Device von USB interface. Seltsam, dass kein init gesendet wird.
Zum Test: Die Rohmessages sind natürlich wichtig
Gruss Martin
Hallo,
ich schlage mich auch seit gestern Abend mit dem gleichen Problem rum. Das update (+neustart) von heute Vormittag (4718) hat daran leider nichts geändert...
Arbeite mit USB und fhem 5.5, debian und einem alten sheevaPlug auf ARM-Basis.
seltsam...
kannst du die neue Version benutzen und ausschließlich das HMLAN auf 4685
http://sourceforge.net/p/fhem/code/4685/tree/trunk/fhem/FHEM/00_HMLAN.pm?format=raw
zurückdrehen?
Hast du die Version aus dem Update von heute Morgen V4718 (HMLAN) ?
http://sourceforge.net/p/fhem/code/4718/tree/trunk/fhem/FHEM/00_HMLAN.pm?format=raw
die aktuelle von heute Morgen (noch nicht im Update) ist 4721
http://sourceforge.net/p/fhem/code/4721/tree/trunk/fhem/FHEM/00_HMLAN.pm?format=raw
kannst du vom Fehler loggen?
Gruss Martin
Zitatkannst du die neue Version benutzen und ausschließlich das HMLAN auf 4685
http://sourceforge.net/p/fhem/code/4685/tree/trunk/fhem/FHEM/00_HMLAN.pm?format=raw
zurückdrehen?
laut update war ich aktuell. Habe dann die 00_HMLAN.pm durch die 4685 Version ersetzt und shutdown restart durchgeführt.
Auf den ersten Blick keine Verbesserung
das Log (verb 4) wird im sekundentakt mit
Zitat2014.01.23 13:51:25 1: 127.0.0.1:1234 disconnected, waiting to reappear
2014.01.23 13:51:25 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 13:51:25 1: 127.0.0.1:1234 reappeared (hmusb)
überschwemmt. Von meinen Sensoren empfange ich nichts.
Was für Daten sind für dich interesant? Was soll ich loggen?
Edit:
version **18 und 21 ergab keine Veränderung. Eine zufällige uralt-version (3802) ebenfalls nicht.
Vielleicht liegt das Problem woanders? Ist das möglich?
Zitat von: Alex am 23 Januar 2014, 13:57:10laut update war ich aktuell. Habe dann die 00_HMLAN.pm durch die 4685 Version ersetzt und shutdown restart durchgeführt.
Hast Du auch den
hmland neugestartet oder nur fhem?
Ein "shutdown restart" tut dies nämlich nicht und ich denke, dass irgendwas von der 00_HMLAN an den hmland geschickt wird, was der nicht verkraftet.
Das kann dann zumindest bei mir der Fall sein. Check ich heute Abend.
oh ... mist....
na klar... hmland habe ich nicht explizit neu gestartet. Gleiches spiel nochmal:
4721 - läuft, keine Fehlermeldungen
4718 - scheint auch zu laufen
sieht sehr gut aus!
Nach dem ersten verhängnisvollen Update gestern Abend hatte ich aber das komplette System neugestartet (mehrfach) -- ohne Erfolg.
seltsam, das nach dem disconnect kein init aufgerufen wird.
kommt ein hmusb wieder in die Gänge wenn man den restarted? also z.B. zeiht und steckt?
Das init könnte man auch aus der kommandozeile nachtriggern.
{HMLAN_DoInit($defs{HMLAN1})}
HMLAN1 ist der Name des io
Zitat von: martinp876 am 23 Januar 2014, 14:31:57kommt ein hmusb wieder in die Gänge wenn man den restarted? also z.B. zeiht und steckt?
Darauf würde ich mich nicht verlassen. Aber er kommt auf jeden Fall wieder in die Gänge, wenn der hmland beendet und neu gestartet wird.
Gezogen (bzw. vom Strom getrennt) habe ich meinen HM-USB-Stick schon mehrere Monate nicht mehr.
mal zusammenfassen:
1) AES codes
HMLAN kann min 5 AES codes (zumindest stürzt er bei deren Eingabe nicht ab)
HMUSB kann 3 , aber stürzt bei 5 ab (4 ist unklar...)
2) HMUSB disconnect
in den Logs habe ich disconnect/reconnect gesehen - aber HMLAN_init wurde nicht aufgerufen. Bei LAN klappt das - irgendwelche Ideen warum dies nicht so ist/sein soll? Das init wird von devio getriggert.
wenn das nicht passiert läuft der WD nicht los.
Gruss Martin
Vielleicht sollte man das Thema mal zusammen mit Michael (mgernoth) diskutieren? Ich denke, er kennt die Verhaltensmuster des USB-Sticks am besten.
Andererseits: Wenn ich die Fehlermeldung bei mir im Log von gestern richtig deute, wurde doch dort das init aufgerufen, oder?
2014-01-22 21:32:07 HMLAN HMUSB DISCONNECTED
2014-01-22 21:32:07 HMLAN HMUSB cond: disconnected
2014-01-22 21:32:07 HMLAN HMUSB Xmit-Events: disconnected:1
2014-01-22 21:32:07 HMLAN HMUSB prot_disconnected: last
2014-01-22 21:32:07 HMLAN HMUSB cond: init
2014-01-22 21:32:07 HMLAN HMUSB Xmit-Events: init:1
2014-01-22 21:32:07 HMLAN HMUSB prot_init: last
2014-01-22 21:32:07 HMLAN HMUSB CONNECTED
wenn der USB abgezogen wird passiert gar nichts.
Das Log zeigt weiter disconnect/reconect an.
Das ganze auch ohne USB-Stick.
Übrigens ist es bei mir auch nicht ganz in Ordnung.
Alle paar Minuten kommt immer noch folgendes
2014.01.23 14:34:51 1: 192.168.169.253:1250 disconnected, waiting to reappear
2014.01.23 14:34:51 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 14:34:51 1: 192.168.169.253:1250 reappeared (hmusb)
2014.01.23 14:34:51 1: HMLAN_Parse: hmusb new condition init
2014.01.23 14:34:52 1: 192.168.169.253:1250 disconnected, waiting to reappear
2014.01.23 14:34:52 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 14:34:52 1: 192.168.169.253:1250 reappeared (hmusb)
2014.01.23 14:34:52 1: HMLAN_Parse: hmusb new condition init
2014.01.23 14:34:53 1: 192.168.169.253:1250 disconnected, waiting to reappear
2014.01.23 14:34:53 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 14:34:53 1: 192.168.169.253:1250 reappeared (hmusb)
2014.01.23 14:34:53 1: HMLAN_Parse: hmusb new condition init
2014.01.23 14:34:54 1: HMLAN_Parse: hmusb new condition ok
2014.01.23 14:43:06 1: 192.168.169.253:1250 disconnected, waiting to reappear
2014.01.23 14:43:06 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 14:43:06 1: 192.168.169.253:1250 reappeared (hmusb)
2014.01.23 14:43:06 1: HMLAN_Parse: hmusb new condition init
2014.01.23 14:43:07 1: 192.168.169.253:1250 disconnected, waiting to reappear
2014.01.23 14:43:07 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 14:43:07 1: 192.168.169.253:1250 reappeared (hmusb)
2014.01.23 14:43:07 1: HMLAN_Parse: hmusb new condition init
2014.01.23 14:43:08 1: 192.168.169.253:1250 disconnected, waiting to reappear
2014.01.23 14:43:08 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 14:43:08 1: 192.168.169.253:1250 reappeared (hmusb)
2014.01.23 14:43:08 1: HMLAN_Parse: hmusb new condition init
2014.01.23 14:43:09 1: HMLAN_Parse: hmusb new condition ok
2014.01.23 14:45:15 1: 192.168.169.253:1250 disconnected, waiting to reappear
2014.01.23 14:45:15 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 14:45:15 1: 192.168.169.253:1250 reappeared (hmusb)
2014.01.23 14:45:15 1: HMLAN_Parse: hmusb new condition init
2014.01.23 14:45:16 1: 192.168.169.253:1250 disconnected, waiting to reappear
2014.01.23 14:45:16 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 14:45:16 1: 192.168.169.253:1250 reappeared (hmusb)
2014.01.23 14:45:16 1: HMLAN_Parse: hmusb new condition init
2014.01.23 14:45:17 1: 192.168.169.253:1250 disconnected, waiting to reappear
2014.01.23 14:45:17 1: HMLAN_Parse: hmusb new condition disconnected
2014.01.23 14:45:17 1: 192.168.169.253:1250 reappeared (hmusb)
2014.01.23 14:45:17 1: HMLAN_Parse: hmusb new condition init
2014.01.23 14:45:19 1: HMLAN_Parse: hmusb new condition ok
Gruß Rainer
Dito billy-boy.
Gleiches Fehlermuster bei mir.
Zitat von: billy-boy am 23 Januar 2014, 15:25:46wenn der USB abgezogen wird passiert gar nichts.
Das Log zeigt weiter disconnect/reconect an.
Das ganze auch ohne USB-Stick.
Ein Ziehen des USB Sticks beendet nicht den laufenden hmland. Und 00_HMLAN.pm kommuniziert mit dem hmland und NICHT mit dem Stick direkt!
Zitat
Ein Ziehen des USB Sticks beendet nicht den laufenden hmland. Und 00_HMLAN.pm kommuniziert mit dem hmland und NICHT mit dem Stick direkt!
Korrekt. Allerdings sollte 00_HMLAN.pm wenn hmland einwandfrei arbeitet schon merken ob der Stick eingesteckt ist oder nicht.
Man müsste auch ausprobieren ob die Fehlermeldung bei gestopptem hmland bleibt oder nicht.
Ist das der Fall findet keine Korrespondenz zwischen 00_HMLAN.pm und hmland statt.
Rainer
Zitat von: billy-boy am 23 Januar 2014, 15:58:33
Korrekt. Allerdings sollte 00_HMLAN.pm wenn hmland einwandfrei arbeitet schon merken ob der Stick eingesteckt ist oder nicht.
Man müsste auch ausprobieren ob die Fehlermeldung bei gestopptem hmland bleibt oder nicht.
Ist das der Fall findet keine Korrespondenz zwischen 00_HMLAN.pm und hmland statt.
Warum sollte 00_HMLAN.pm das merken? HMLAN kennt keinen USB-Stick. Die Kommunikation mit HMLAN funktioniert über
IP.
Ich gehe davon aus, dass hmlan einwandfrei funktioniert, da er seit Wochen läuft und FHEM immer mitbekommen hat
wenn der USB-Stick abgezogen wurde oder nicht. Er hat mir immer gesagt ob ein Stick dran war oder nicht.
Seit dem Update liegt in der Korrespondenz zwischen 00_HMLAN.pm und hmlan das Übel begraben.
Durch die IP-Adresse weis 00_HMLAN.pm nur mit wem er korrespondieren soll.
ZitatWarum sollte 00_HMLAN.pm das merken?
korrekt. HMLAN kennt noch nicht einmal TCP.
Für LAN wir es über DevIo angebunden. Und es ist dessen Aufgabe die socket-kommunication zu terminieren. fehler auf diesem level (z.B. disconnect) werden nach oben (HMLAN) mitgeteilt.
Eine entsprechende Überwachung für USB sollte dann in hmland stattfinden denke ich. oder bindet der USB auch über DevIo an?
ZitatSeit dem Update liegt in der Korrespondenz zwischen 00_HMLAN.pm und hmlan das Übel begraben.
da hat sich aber nichts geändert.
ZitatDurch die IP-Adresse weis 00_HMLAN.pm nur mit wem er korrespondieren soll.
nein - der socket wird nicht von HMLAN gehandelt sondern von DevIo
Zitat von: martinp876 am 23 Januar 2014, 16:22:27oder bindet der USB auch über DevIo an?
öhm???
Für die Anbindung wird doch in fhem die gleiche Methode verwendet wie für den "echten" HMLAN-Adapter auch:
define hmusb HMLAN 127.0.0.1:1234
attr hmusb hmId 424242
Damit sollte doch auch die Kommunikation die gleiche sein. Oder verstehe ich grade Deine Frage falsch?
da hast du wohl recht...
habe einmal mit einer CUL getestet - fhem.pl ruft periodisch die Ready-funktion auf so ein IO device nicht lebt (alle 5 für linux) - dort wird dann ein DevIo_OpenDev probiert.
Bei einer CUNO hatte ich übrigens ganz schöne delays, wenn die nicht geantwortet hat - auf dauer ein timig-killer.
Aus FHEM sicht sollte das alles passen.
Es muss natürlich bei einem disconnect auch der Socket abgebaut werden - sonst merkt es DevIo nicht...