Verbindungsabbruch CUNO <=> FHEM
1,233 views
Skip to first unread message
doubh
Jul 18, 2012, 4:37:40 AM7/18/12
to fhem-...@googlegroups.com
Hallo,
ich habe hin und wieder (ca. 5-10 pro Tag) Verbindungsabbrüche zwischen CUNO und FHEM-Server. Dies hat zur Folge, dass nicht alle CUNO Meldungen empfangen werden.
Zurerst ein paar Informationen zu meinem Aufbau:
Der FHEM-Server (SVN Rev. 1680) läuft auf einer ASUS wl500gpv2 Box, die als WLAN-Client angemeldet ist.
Der CUNO (modified FW v1.44 / 868MHz) hängt über ein Netzwerkkabel an einem zweiten WLAN-Client und ist somit im gleichen Netz und vom wl500 erreichbar.
Der CUNO steuert einen 4-fach HomeMatic Funkaktor (Hutschiene) und sendet alle zwei Minuten Daten von zwei angeschlossenen DS2438 One-Wire Sensoren (Temp + Spannung) an den FHEM-Server.
Es kommt leider - wie eingangs erwähnt - täglich zu ca. 5-10 Verbindungsabbrüchen zwischen CUNO und FHEM. Der Fehler ist im Log-File mit folgende Meldung zu sehen:
2012.07.17 16:30:46.219 1: 192.168.2.8:2323 disconnected, waiting to reappear
2012.07.17 16:30:55.997 1: 192.168.2.8:2323 reappeared (CUNO)
Im Regelfall sendet der CUNO nur Daten (die der One-Wire Sensoren) an den FHEM und nur selten werden Daten / Befehle vom FHEM an den CUNO gesendet.
Verbindungsabbrüche, wie der Auszug aus dem Log, sind nur festzustellen, wenn Daten vom FHEM an den CUNO gesendet werden.
Nach meiner Analyse returned der Aufruf my $nfound = select($rout=$rin, undef, undef, $timeout); in fhem.pl NICHT, wenn die TCP-Verbindung tot ist. Somit wird nie versucht Daten von diesem FileDescriptor zu lesen und der Abbruch der Verbindung wird nicht erkannt.
Erst wenn ein Befehl zum CUNO gesendet und somit der FD-Ptr benutzt wird, wird der Fehler der TCP-Verbindung erkannt.
Um den Fehler zu umgehen, habe ich eine Notify eingefügt, dass alle 3 Minuten einer Versionsabfrage am CUNO startet.
Leider ist das meiner Meinung nach ein unschöner Workaround.
Ich hab alternativ an die Socket-Option Keepalive gedacht, bin mir aber nicht sicher, ob das den gewünschten Erfolg hätte.
Hat Jmd damit Erfahrung?
Hat Jmd eine bessere Idee oder kann man mit Hilfe der Exception-Abfrage im select-Befehl den Fehler erkennen?
Desweiteren habe ich noch ein zweites Thema festgestellt:
Schlägt beim ReOpen der Init des CUNO fehl (Zeile 236 in DevIo.pm), wird durch den Aufruf von DevIo_CloseDev($hash); der FD-Ptr geschlossen, aber der State des Devices bleibt auf "open". Somit wird bis zu einem FHEM-Neustart, dass Device (in meinem Fall der CUNO) nicht wieder initialisiert und kann nicht verwendet werden.
Mein Vorschlag: besser DevIo_Disconnected($hash); anstelle DevIo_CloseDev($hash);. Somit würde beim nächsten ReOpen ein neuer Init versucht.
Danke für Eure Ratschläge.
Rudolf Koenig
Jul 18, 2012, 5:35:20 AM7/18/12
to fhem-...@googlegroups.com
> Ich hab alternativ an die Socket-Option Keepalive gedacht, bin mir aber
> nicht sicher, ob das den gew�nschten Erfolg h�tte.
Das wuerde das Gleiche auf OS ebene erledigen, wie das notify auf APP ebene,
vorausgesetzt die Timeouts sind gleich.
> oder kann man mit Hilfe der Exception-Abfrage im select-Befehl den Fehler
> erkennen?
Alle diese Punkte sind Workarounds, man muesste eigentlich feststellen, wieso
das Problem auftritt (reboot der CUNO, etc).
> Mein Vorschlag: besser *DevIo_Disconnected($hash);* anstelle *
> DevIo_CloseDev($hash);*. Somit w�rde beim n�chsten ReOpen ein neuer Init
> versucht.
Das ist aber problematisch: Falls das Geraet gar kein CUNO/CUL ist, dann wuerde
fhem es in 1Minuten/5-Sekunden Abstand versuchen wieder zu oeffnen. Ich
fuerchte wir muessen hier eine differenziertere Loesung finden.
doubh
Jul 18, 2012, 8:05:03 AM7/18/12
to fhem-...@googlegroups.com
Am Mittwoch, 18. Juli 2012 11:35:20 UTC+2 schrieb Rudolf Koenig:
> Ich hab alternativ an die Socket-Option Keepalive gedacht, bin mir aber
> nicht sicher, ob das den gew�nschten Erfolg h�tte.
Das wuerde das Gleiche auf OS ebene erledigen, wie das notify auf APP ebene,
vorausgesetzt die Timeouts sind gleich.
> oder kann man mit Hilfe der Exception-Abfrage im select-Befehl den Fehler
> erkennen?
Nicht solange das OS davon nichts mitkriegt.
Alle diese Punkte sind Workarounds, man muesste eigentlich feststellen, wieso
das Problem auftritt (reboot der CUNO, etc).
Einen Reboot des CUNO kann ich ausschließen, da die Messwerte, die alle zwei Minuten gesendet werden, immer exakt zur gleichen Sekunde eintreffen. Gäbe es Reboots während des zwei Minuten Intervalls, würden die Messwerte nicht immer zur gleichen Sekunde eintreffen. Der WLAN-Client des CUNO zeigt im Webinterface auch eine korrekte Uptime an...
Ich denke eher, dass es ein WLAN-Problem ist. Von einer langen Pingserie kommen nur ca. 98% an und da das WLAN in ein Nachbargebäude geht, könnte auch das Wetter das WLAN kurz aussetzen lassen.
Rudi, weißt du, wie FHEM reagieren würde, wenn das OS den Verbindungsabbruch mitbekommt?
Wie könnte man die Abbruchinformation an FHEM weiterreichen oder geschieht das schon?
Das Notify auf App-Ebene versucht ja aktiv die Verbindung im Anschluss wiederherzustellen. Würde das FHEM auch von sich aus tun, wenn das OS den Abbruch mitbekommt?
> Mein Vorschlag: besser *DevIo_Disconnected($hash);* anstelle *
> DevIo_CloseDev($hash);*. Somit w�rde beim n�chsten ReOpen ein neuer Init
> versucht.
Das ist aber problematisch: Falls das Geraet gar kein CUNO/CUL ist, dann wuerde
fhem es in 1Minuten/5-Sekunden Abstand versuchen wieder zu oeffnen. Ich
fuerchte wir muessen hier eine differenziertere Loesung finden.
Könnte man eine Unterscheidung anhand des ReOpen-Flags machen?
Findet ein ReOpen statt, war das Device ja schon mal offen u es ist ein CUNO/CUL Device (außer es wurde vom User die IP oder das Gerät getauscht).
Gruß
Rudolf Koenig
Jul 18, 2012, 8:41:44 AM7/18/12
to fhem-...@googlegroups.com
> Rudi, wei�t du, wie FHEM reagieren w�rde, wenn das OS den
> Verbindungsabbruch mitbekommt?
Ja, das OS gibt es direkt an dem select in fhem.pl weiter, daraufhin versucht
fhem zu lesen (kommt Fehler), schliesst die Verbindung, versucht es in 1 Minute
wieder. Die eine Minute ist fuer TCP/IP ein Sonderfall (USB ist 5 Sekunden),
weil ein erfolgloser connect() schon 3-5 Sekunden dauert.
Deswegen ist ein notify und ein Keepalive ziemlich identisch. Und einen anderen
Weg als keepalive hat das OS auch nicht, ein Verbindungsabbruch mitzukriegen.
Mir ist aber immer noch schleierhaft, wieso die TCP Verbindung abbricht,
Paketaussetzer reichen fuer ein TCP/IP Abbruch nicht, insb. wenn nix gesendet wird.
Eine Erklaerung fuer mich waere, dass das CUNO rebootet, oder sein TCP/IP Stack
neu initialisiert. Oder letzteres ist fehlerhaft.
Ich habe mal fuer die sehr unzuverlaessige Initialisierung des LAN Chips ein
workaround eingebaut: wenn dieser zu lange Pakete empfaengt (> 1.5k), dann wird
das Chip neu initialisert. Evtl. fuehrt das als Nebeneffekt zu solchen
Abbruechen.
Btw. reboot: da wuerde ich das CUNO direkt fragen (get CUNO uptime).
> Verbindungsabbruch mitbekommt?
Ja, das OS gibt es direkt an dem select in fhem.pl weiter, daraufhin versucht
fhem zu lesen (kommt Fehler), schliesst die Verbindung, versucht es in 1 Minute
wieder. Die eine Minute ist fuer TCP/IP ein Sonderfall (USB ist 5 Sekunden),
weil ein erfolgloser connect() schon 3-5 Sekunden dauert.
Deswegen ist ein notify und ein Keepalive ziemlich identisch. Und einen anderen
Weg als keepalive hat das OS auch nicht, ein Verbindungsabbruch mitzukriegen.
Mir ist aber immer noch schleierhaft, wieso die TCP Verbindung abbricht,
Paketaussetzer reichen fuer ein TCP/IP Abbruch nicht, insb. wenn nix gesendet wird.
Eine Erklaerung fuer mich waere, dass das CUNO rebootet, oder sein TCP/IP Stack
neu initialisiert. Oder letzteres ist fehlerhaft.
Ich habe mal fuer die sehr unzuverlaessige Initialisierung des LAN Chips ein
workaround eingebaut: wenn dieser zu lange Pakete empfaengt (> 1.5k), dann wird
das Chip neu initialisert. Evtl. fuehrt das als Nebeneffekt zu solchen
Abbruechen.
Btw. reboot: da wuerde ich das CUNO direkt fragen (get CUNO uptime).
Mitch
Jul 18, 2012, 3:35:18 PM7/18/12
to fhem-...@googlegroups.com
Hab zwar keinen CUNO sondern eine FHZ1300, aber auch seit dem Wiederaufbau von fhem (bin umgezogen) das Problem, dass er andauernd die FHZ verliert.
Geänder wurde eigentlich nichts, ausser dem Standort.
Am Mittwoch, 18. Juli 2012 14:41:44 UTC+2 schrieb Rudolf Koenig:
Geänder wurde eigentlich nichts, ausser dem Standort.
2012.07.18 21:32:32 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.18 21:32:37 1: USB device /dev/ttyUSB0 reappeared 2012.07.18 21:32:40 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.18 21:32:45 1: USB device /dev/ttyUSB0 reappeared 2012.07.18 21:32:47 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.18 21:32:52 1: USB device /dev/ttyUSB0 reappeared 2012.07.18 21:32:57 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.18 21:33:09 1: Trying again get FHZ_0 serial (2 out of 3)
Am Mittwoch, 18. Juli 2012 14:41:44 UTC+2 schrieb Rudolf Koenig:
> Rudi, wei�t du, wie FHEM reagieren w�rde, wenn das OS den
Rudolf Koenig
Jul 18, 2012, 3:41:37 PM7/18/12
to fhem-...@googlegroups.com
> Geaendert wurde eigentlich nichts, ausser dem Standort.
Auch kein fhem-Update?
Auch kein fhem-Update?
Mitch
Jul 18, 2012, 3:45:18 PM7/18/12
to fhem-...@googlegroups.com
doch Update gestern, hat aber vorher mit der "normalen" 7.2 das gleiche Problem.
Hatte extra fhem runter geschmissen und dann aus der deb neu installiert.
Hatte extra fhem runter geschmissen und dann aus der deb neu installiert.
Fiedel
Jul 19, 2012, 1:30:00 AM7/19/12
to FHEM users
Hallo,
habe exakt das gleiche Problem wie doubh, nur seltener (1-2 Mal pro
Tag).
Mein CUNO (CUNO2 Ver 1.43) hängt direkt per LAN an einem Dreamplug mit
Squeeze, auf dem auch FHEM läuft.
Die 2 LAN- Ports laufen im Bridge- Mode mit einer festen IP und der
zweite LAN- Port ist mit dem DSL- Router verbunden.
Es ist übrigens noch nie passiert, dass der CUNO nach dem reconnect
nicht mehr initialisiert wurde.
Der CUNO rebootet definitiv nicht, da ich die 1-Wire- HMS- Emulation
nutze und diese nicht verloren geht.
Mich hat die Sache bisher nicht gestört, aber vielleicht kann ich ja
etwas zur Lösung beitragen.
Gruß Frank
> > Auch kein fhem-Update?- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -
habe exakt das gleiche Problem wie doubh, nur seltener (1-2 Mal pro
Tag).
Mein CUNO (CUNO2 Ver 1.43) hängt direkt per LAN an einem Dreamplug mit
Squeeze, auf dem auch FHEM läuft.
Die 2 LAN- Ports laufen im Bridge- Mode mit einer festen IP und der
zweite LAN- Port ist mit dem DSL- Router verbunden.
Es ist übrigens noch nie passiert, dass der CUNO nach dem reconnect
nicht mehr initialisiert wurde.
Der CUNO rebootet definitiv nicht, da ich die 1-Wire- HMS- Emulation
nutze und diese nicht verloren geht.
Mich hat die Sache bisher nicht gestört, aber vielleicht kann ich ja
etwas zur Lösung beitragen.
Gruß Frank
>
> - Zitierten Text anzeigen -
Steffen
Jul 19, 2012, 2:38:15 AM7/19/12
to fhem-...@googlegroups.com
Hallo!
Habe jetzt auch das Problem...
Habe jetzt auch das Problem...
2012.07.19 07:07:53 1: 192.168.178.26:1000 disconnected, waiting to reappear 2012.07.19 07:07:58 1: 192.168.178.26:1000 reappeared (HMLAN1) 2012.07.19 07:28:13 1: 192.168.178.26:1000 disconnected, waiting to reappear 2012.07.19 07:28:18 1: 192.168.178.26:1000 reappeared (HMLAN1) 2012.07.19 07:48:33 1: 192.168.178.26:1000 disconnected, waiting to reappear 2012.07.19 07:48:38 1: 192.168.178.26:1000 reappeared (HMLAN1) 2012.07.19 08:08:53 1: 192.168.178.26:1000 disconnected, waiting to reappear 2012.07.19 08:08:58 1: 192.168.178.26:1000 reappeared (HMLAN1) 2012.07.19 08:29:13 1: 192.168.178.26:1000 disconnected, waiting to reappear 2012.07.19 08:29:18 1: 192.168.178.26:1000 reappeared (HMLAN1)
FB7170 mit HMLAN direkt an FB!!!
doubh
Jul 19, 2012, 3:59:56 AM7/19/12
to fhem-...@googlegroups.com
Einen Reboot des CUNO kann ich auch ausschließen, da die Uptime kontinuierlich hochzählt; schon seit Tagen.
Ich werde aber versuchen, die Re-Inits des CUNO Ethernetchips zu protokollieren.
Mitch
Jul 19, 2012, 3:12:42 PM7/19/12
to fhem-...@googlegroups.com
Mittlerweile habe ich das ganze minütlich:
2012.07.19 21:06:07 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:06:07 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:06:12 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:06:14 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:06:19 1: Trying again get FHZ_0 serial (2 out of 3) 2012.07.19 21:06:19 1: Trying again get FHZ_0 serial (2 out of 3) 2012.07.19 21:06:26 1: Trying again get FHZ_0 serial (3 out of 3) 2012.07.19 21:06:27 1: Trying again get FHZ_0 serial (3 out of 3) 2012.07.19 21:06:35 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:06:40 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:06:41 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:06:42 1: Trying again get FHZ_0 init2 (3 out of 3) 2012.07.19 21:06:43 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:06:48 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:06:50 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:06:51 1: Trying again get FHZ_0 init2 (3 out of 3) 2012.07.19 21:06:53 1: Trying again get FHZ_0 serial (2 out of 3) 2012.07.19 21:06:55 1: Trying again get FHZ_0 serial (3 out of 3) 2012.07.19 21:07:20 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:07:25 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:07:26 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:07:28 1: Trying again get FHZ_0 init2 (3 out of 3) 2012.07.19 21:07:30 1: Trying again get FHZ_0 serial (2 out of 3) 2012.07.19 21:07:31 1: Trying again get FHZ_0 serial (3 out of 3) 2012.07.19 21:07:55 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:08:00 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:08:02 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:08:03 1: Trying again get FHZ_0 init2 (3 out of 3) 2012.07.19 21:08:06 1: Trying again get FHZ_0 serial (2 out of 3) 2012.07.19 21:08:07 1: Trying again get FHZ_0 serial (3 out of 3) 2012.07.19 21:08:10 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:08:15 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:08:16 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:08:18 1: Trying again get FHZ_0 init2 (3 out of 3) 2012.07.19 21:08:20 1: Trying again get FHZ_0 serial (2 out of 3) 2012.07.19 21:08:21 1: Trying again get FHZ_0 serial (3 out of 3) 2012.07.19 21:08:22 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:08:27 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:08:28 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:08:30 1: Trying again get FHZ_0 init2 (3 out of 3) 2012.07.19 21:08:33 1: Trying again get FHZ_0 serial (2 out of 3) 2012.07.19 21:08:34 1: Trying again get FHZ_0 serial (3 out of 3) 2012.07.19 21:09:15 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:09:20 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:09:21 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:09:23 1: Trying again get FHZ_0 init2 (3 out of 3) 2012.07.19 21:09:25 1: Trying again get FHZ_0 serial (2 out of 3) 2012.07.19 21:09:26 1: Trying again get FHZ_0 serial (3 out of 3) 2012.07.19 21:09:53 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:09:58 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:09:59 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:10:02 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:10:04 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:10:05 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:10:10 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:10:11 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:10:13 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:10:14 1: Trying again get FHZ_0 init2 (3 out of 3) 2012.07.19 21:10:18 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:10:18 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:10:23 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:10:24 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:10:26 1: Trying again get FHZ_0 init2 (3 out of 3) 2012.07.19 21:10:28 1: Trying again get FHZ_0 serial (2 out of 3) 2012.07.19 21:10:29 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.19 21:10:34 1: USB device /dev/ttyUSB0 reappeared 2012.07.19 21:10:35 1: Trying again get FHZ_0 init2 (2 out of 3) 2012.07.19 21:10:36 1: Trying again get FHZ_0 init2 (3 out of 3) 2012.07.19 21:10:39 1: Trying again get FHZ_0 serial (2 out of 3) 2012.07.19 21:10:40 1: Trying again get FHZ_0 serial (3 out of 3)
Hab auch mal gerade einen Update gemacht und fhem, sowie meine Linuxkiste neu gestartet. Leider ohne Erfolg :-(
Mitch
Jul 20, 2012, 2:30:57 PM7/20/12
to fhem-...@googlegroups.com
So, habe jetzt nochmal rumprobiert.
Wenn ich frisch die 5.2 downloade und installiere, geht fhem one Probleme und Abbrüche.
Sobald ich update mache, reagiert fhem kaum mehr, weil es nur noch mit der FHZ beschäftigt ist.
Habe das ganze 5 mal durchgespielt.
Wenn ich frisch die 5.2 downloade und installiere, geht fhem one Probleme und Abbrüche.
Sobald ich update mache, reagiert fhem kaum mehr, weil es nur noch mit der FHZ beschäftigt ist.
Habe das ganze 5 mal durchgespielt.
Rudolf Koenig
Jul 21, 2012, 8:49:48 AM7/21/12
to fhem-...@googlegroups.com
> Sobald ich update mache, reagiert fhem kaum mehr, weil es nur noch mit der
> FHZ besch�ftigt ist.
Kann nicht nachvollziehen:
- hab auf einem fb7390 fhemupdate durchgefuehrt
- FHZ1300 angeschlossen
- HMLAN angeschlossen
- laeuft seit eine Stunde ohne Probleme, empfaengt Daten wie erwartet, schalten
kann ich auch normal.
Btw. das FHZ Code hat sich seit 5.2 nicht geaendert (nur das kosmetische
FHZ_SetState wurde entfernt), und es werden auch (noch) nicht die externe
Routinen aus DevIo fuer die Kommunikation verwendet, alles ist lokal.
Fuer das Schliessen/Oeffnen des GeraeteKnotens ist das Modul selbst (00_FHZ.pm)
zustaendig. HMLAN verwendet genauso wie CUL/CUNO DevIo.pm, sollte sich also
aehnlich verhalten.
-> Kann nicht weiterhelfen, ohne bessere/genauere Fehlerhinweise.
Fiedel
Jul 21, 2012, 6:27:44 PM7/21/12
to fhem-...@googlegroups.com
doubh und ich haben vermutlich auch ein anderes (wenn auch ähnliches) Problem. Bei mir ist das Verhalten des CUNO schon über mehrere FHEM- Versionen völlig gleich. An FHEM liegt es höchstwahrscheinlich nicht. Am Anfang hatte ich den CUNO über eine USB- Buchse des Dreamplug mit Strom versorgt. Da hat er am Tag relativ oft disconnected. Nachdem ich die Stromversorgung "verbessert" hatte (direkt aus USB- Netzteil), disconnected er nun nur noch 1 bis 2 mal am Tag. Aber ob da die Ursache liegt...?
Ich kann leider die Programmierung der FW nicht lesen, geschweige denn verstehen. ;o)
Am Samstag, 21. Juli 2012 14:49:48 UTC+2 schrieb Rudolf Koenig:
> Sobald ich update mache, reagiert fhem kaum mehr, weil es nur noch mit der
> FHZ besch�ftigt ist.
doubh
Jul 22, 2012, 2:11:38 PM7/22/12
to fhem-...@googlegroups.com
Ich kann
mittlerweile ziemlich sicher ausschließen, dass der Fehler von FHEM kommt.
Testweise
habe ich einen TCP-Proxy (C# .NET3.5) dazwischen gehängt, den ganzen Verkehr
belauscht und festgestellt, dass die Verbindung CUNO <> Proxy zuerst tot
ist.
Ich habe
desweiteren einen einfachen TCP-Client geschrieben, der sich connected, die
Meldungen der Temperatursensoren (die alle zwei Minuten kommen) ausgibt sowie
alle vier Minuten die Uptime abfrägt. Auch in diesem Setup ohne FHEM war der
Fehler vorhanden.
Ich kann
ausschließen, dass der CUNO rebootet, denn die Uptime zählt immer schon brav
hoch.
Desweiteren habe ich verschiedene Stellen in der CUNO-Firmware, die nach meiner Einschätzung den Fehler hätten verursachen können, "überwacht".
# network.c[111]: network_read(): if (rpv.received_packet_size
> NET_MAX_FRAME_LENGTH
|| rpv.received_packet_size < 14
|| rpv.received_packet_size > UIP_BUFSIZE) {
# network.c[228]: ethernet_process(): if (EIR & _BV(LINKIF)) {
# network.c[290]: ethernet_process(): if (EIR & _BV(TXERIF)) {
# sowie aus Testgründen ethernet.c[129] eth_func(): if(in[1] == 'i') {
Einzig ein paar RX-Errors erscheinen, jedoch ganz unabhängig von den Aussetzern der TCP-Verbindung.
# network.c[276]: ethernet_process(): if (EIR & _BV(RXERIF)) {
Es handelt sich übrigens um die v1.44 SVN rev 267.
Hat Jmd noch Ideen was man überwachen bzw. testen könnte?
Dirk Tostmann
Jul 22, 2012, 6:23:32 PM7/22/12
to fhem-...@googlegroups.com
Am 22.07.2012 um 20:11 schrieb doubh:
> Hat Jmd noch Ideen was man überwachen bzw. testen könnte?
Rudolf Koenig
Jul 23, 2012, 9:00:36 AM7/23/12
to fhem-...@googlegroups.com
> Hat Jmd noch Ideen was man �berwachen bzw. testen k�nnte?
Man koennte das CUNO zusaetzlich per USB anschliessen, und falls die Verbindung
nicht mehr funktioniert, die TCP/IP bzw. Ethernet Einstellungen pruefen. Leider
Stecke ich nicht mehr so tief in dem CUNO Netzwerk-Software drin, dass ich
konkretere Vorschlaege geben koennte.
Man koennte das CUNO zusaetzlich per USB anschliessen, und falls die Verbindung
nicht mehr funktioniert, die TCP/IP bzw. Ethernet Einstellungen pruefen. Leider
Stecke ich nicht mehr so tief in dem CUNO Netzwerk-Software drin, dass ich
konkretere Vorschlaege geben koennte.
Message has been deleted
ullrichit
Jul 24, 2012, 9:33:34 AM7/24/12
to fhem-...@googlegroups.com
Hallo Rudolf,
Am Montag, 23. Juli 2012 15:00:36 UTC+2 schrieb Rudolf Koenig:
besitze auch ein FHZ1350 + Fritz-Box 7390 und stelle auch seit einigen Tagen im LOG die FHZ-Verbindungsabbrüche fest obwohl außer Fhem-Updates nichts verändert wurde. Dies führt m.E. dazu, daß meine FS20-Peripherie nur noch sporadisch funktioniert (Morgens bleiben die Rollos unten und ich verschlafe dadurch den ganzen Tag ;-) )
2012.07.24 15:26:27 1: USB device /dev/ttyUSB0 disconnected, waiting to reappear 2012.07.24 15:26:31 2: dummy set AndreasatHome 0 2012.07.24 15:26:32 1: USB device /dev/ttyUSB0 reappeared 2012.07.24 15:26:34 1: Trying again get FHZ1 init2 (2 out of 3) 2012.07.24 15:26:35 1: Trying again get FHZ1 init2 (3 out of 3)
Am Montag, 23. Juli 2012 15:00:36 UTC+2 schrieb Rudolf Koenig:
> Hat Jmd noch Ideen was man �berwachen bzw. testen k�nnte?
Rudolf Koenig
Jul 24, 2012, 9:41:18 AM7/24/12
to fhem-...@googlegroups.com
> besitze auch ein FHZ1350 + Fritz-Box 7390 und stelle auch seit einigen
> Tagen im LOG die FHZ-Verbindungsabbr�che fest obwohl au�er Fhem-Updates
> nichts ver�ndert wurde.
Mag sein, ich kann es aber nicht reproduzieren, und werde erstmal nichts
unternehmen. Es sei denn jemand leifert mir eine reproduzierbare Anleitung.
Mitch
Jul 24, 2012, 1:13:18 PM7/24/12
to fhem-...@googlegroups.com
Ich habe es heute nochmal reprodiziert:
1. fhem 5.2 downloaden und installieren
2. Cfg mit einem FS20 erstellen
Alles funktioniert
3. Updatefhem housekeeping
4. Update
Nur noch Verbindungsabbrüche, somit ist der FS20 nicht mehr schaltbar
1. fhem 5.2 downloaden und installieren
2. Cfg mit einem FS20 erstellen
Alles funktioniert
3. Updatefhem housekeeping
4. Update
Nur noch Verbindungsabbrüche, somit ist der FS20 nicht mehr schaltbar
Rudolf Koenig
Jul 24, 2012, 4:07:06 PM7/24/12
to fhem-...@googlegroups.com
Mitch
Jul 24, 2012, 4:10:43 PM7/24/12
to fhem-...@googlegroups.com
fhem.de
ABER, ich habe gerade manuell mein Ubuntu nochmal upgedated, danach manuell fhem aus dem SVN "gespeigelt" und von dort installiert.
Danach updatefhem housekeeping und update ausgeführt.
Jetzt läuft es stabil *freu*
Ich kann jetzt nicht sicher sagen, ob es am Ubuntu lag, oder an fhem, nur wie ich es hinbekommen habe.
ABER, ich habe gerade manuell mein Ubuntu nochmal upgedated, danach manuell fhem aus dem SVN "gespeigelt" und von dort installiert.
Danach updatefhem housekeeping und update ausgeführt.
Jetzt läuft es stabil *freu*
Ich kann jetzt nicht sicher sagen, ob es am Ubuntu lag, oder an fhem, nur wie ich es hinbekommen habe.
Steffen
Jul 26, 2012, 11:05:01 PM7/26/12
to fhem-...@googlegroups.com
Guten Morgen!
Ich wollte jetzt kein neues Thema extra aufmachen, denn mein Problem ist auch Verbindungsabbruch aber noch ein paar andere Probleme die ich seit gestern habe,
hier mal mein log:
2012.07.26 21:54:26 1: backup done: FHEM-20120726_212323.tar.gz (10920527 Bytes)
2012.07.26 21:54:29 1: updatefhem updated ./fhem.pl
2012.07.26 21:54:30 1: updatefhem updated FHEM/01_FHEMWEB.pm
2012.07.26 21:54:39 1: updatefhem updated www/pgm2/commandref.html
2012.07.26 21:54:40 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
2012.07.26 21:55:03 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 21:55:08 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 21:55:47 0: Server shutdown
2012.07.26 21:56:42 1: Including fhem.cfg
2012.07.26 21:57:06 1: reload: Error:Modul 99_email deactivated:
2012.07.26 21:57:06 1: reload: Error:Modul 99_myFloorplanList deactivated:
Can't modify constant item in predecrement (--) at ./FHEM/99_myFloorplanList.pm line 6, near "ViewVC :: http"
syntax error at ./FHEM/99_myFloorplanList.pm line 6, near "ViewVC :: http"
"no" not allowed in expression at ./FHEM/99_myFloorplanList.pm line 19, at end of line
syntax error at ./FHEM/99_myFloorplanList.pm line 22, near "36px"
Unmatched right curly bracket at ./FHEM/99_myFloorplanList.pm line 23, at end of line
syntax error at ./FHEM/99_myFloorplanList.pm line 37, near "-->"
syntax error at ./FHEM/99_myFloorplanList.pm line 43, near "END:"
syntax error at ./FHEM/99_myFloorplanList.pm line 59, near "" class="logo"
syntax error at ./FHEM/99_myFloorplanList.pm line 86, near ">"
syntax error at ./FHEM/99_myFloorplanList.pm line 103, near "<a href="/viewvc"
./FHEM/99_myFloorplanList.pm has too many errors.
2012.07.26 21:57:06 1: reload: Error:Modul 99_myUtils deactivated:
2012.07.26 21:57:16 3: WEB: port 8083 opened
2012.07.26 21:57:16 3: WEBphone: port 8084 opened
2012.07.26 21:57:16 3: WEBtablet: port 8085 opened
2012.07.26 21:57:22 3: Opening HMLAN1 device 192.168.178.26:1000
2012.07.26 21:57:22 3: HMLAN1 device opened
2012.07.26 21:57:27 3: telnetPort: port 7072 opened
2012.07.26 21:57:33 1: Including ./log/fhem.save
2012.07.26 21:57:40 3: Opening CUL device /dev/ttyACM0
2012.07.26 21:57:42 3: Can't open /dev/ttyACM0: No such device or address
2012.07.26 21:57:42 3: Opening CUL device /dev/ttyACM1
2012.07.26 21:57:42 3: Can't open /dev/ttyACM1: No such device or address
2012.07.26 21:57:42 3: Opening TCM310 device /dev/ttyUSB0
2012.07.26 21:57:42 3: Can't open /dev/ttyUSB0: No such device
2012.07.26 21:57:42 3: Opening TCM310 device /dev/ttyUSB1
2012.07.26 21:57:42 3: Can't open /dev/ttyUSB1: No such device
2012.07.26 21:57:42 3: Opening TCM310 device /dev/ttyUSB2
2012.07.26 21:57:42 3: Can't open /dev/ttyUSB2: No such device
2012.07.26 21:57:42 3: Opening TCM310 device /dev/ttyUSB3
2012.07.26 21:57:42 3: Can't open /dev/ttyUSB3: No such device
2012.07.26 21:57:42 0: Server started (version Fhem 5.2 (DEVELOPMENT), $Id: fhem.pl 1757 2012-07-23 13:16:02Z rudolfkoenig $, pid 1745)
2012.07.26 21:57:47 1: HMLAN setting owner to 123ABC from 11A172
2012.07.26 22:00:49 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:00:54 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:03:59 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:04:04 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:07:09 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:07:15 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:10:19 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:10:25 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:13:30 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:13:35 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:16:40 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:16:45 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:19:50 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:19:55 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:23:00 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:23:05 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:26:10 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:26:15 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:29:20 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:29:25 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:32:30 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:32:35 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:35:40 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:35:45 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:38:50 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:38:55 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:42:00 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:42:06 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:45:10 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:45:16 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:48:21 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:48:26 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:51:31 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:51:36 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:54:41 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:54:46 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.26 22:57:52 1: 192.168.178.26:1000 disconnected, waiting to reappear
2012.07.26 22:57:58 1: 192.168.178.26:1000 reappeared (HMLAN1)
2012.07.27 04:23:26 2: CUL_HM set Fl_LampeDecke off
2012.07.27 04:36:42 2: CUL_HM set Fl_LampeDecke off
da sind viele Fehler aber wüsste garnicht wo ich da anfangen sollte;-).
Ich habe mal meine Fs20dummy entfernt weil ich dachte hat was damit zu tun aber die gleiche Fehler!
Würde mich freuen wenn jemand mal rüber schauen könnte und mir ein paar Tips geben könnte in welche Richtung ich da gehen müsste?!?
Mfg Steffen
doubh
Jul 28, 2012, 3:12:46 AM7/28/12
to fhem-...@googlegroups.com
Ich konnte den Fehler bei meinem Aufbau finden und fixen. Seit >48h keine Reconnects!
Es gibt einen Fehler im Netzwerkcode der culfw.
Aktuell habe ich nur einen dirty-hack zum Testen bei mir eingefügt, aber eine schöne Lösung sowie genaue Erklärung wird die nächsten Tage folgen (wenns mal wieder regnet u nicht so schönes Wetter ist :).
Message has been deleted
doubh
Jul 28, 2012, 8:50:46 AM7/28/12
to fhem-...@googlegroups.com
Kann mir bitte Jmd den Sinn eines solchen Posts erklären?
Hr. Prof. Dr. Peter A. Henning, wo liegt denn der Fehler? Dass es einen gibt, wird jeder vermuten.
So sinnlose "hab ich doch gesagt" Kommentare ohne auch nur in irgendeiner Form hilfreiche Tipps sind nutzlos. Die helfen nicht dem TE u auch nicht dem, der den Thread verfolgt, denn dadurch wir er nur unnötig aufgebläht.
Ebenso hier: "FileLog Filter" https://groups.google.com/forum/?hl=de&fromgroups#!topic/fhem-users/DP3Ia1909AY
Hr. Prof. Dr. Peter A. Henning, wo liegt denn der Fehler? Dass es einen gibt, wird jeder vermuten.
So sinnlose "hab ich doch gesagt" Kommentare ohne auch nur in irgendeiner Form hilfreiche Tipps sind nutzlos. Die helfen nicht dem TE u auch nicht dem, der den Thread verfolgt, denn dadurch wir er nur unnötig aufgebläht.
Ebenso hier: "FileLog Filter" https://groups.google.com/forum/?hl=de&fromgroups#!topic/fhem-users/DP3Ia1909AY
Einfach mal ein Kommentar u Hinweis, der überhaupt nicht stimmt oder weiterhilft.
Am Samstag, 28. Juli 2012 09:27:35 UTC+2 schrieb Prof. Dr. Peter A. Henning:
Habe ich ja oben geschrieben ...
LG
pah
Message has been deleted
Fiedel
Jul 29, 2012, 7:40:20 AM7/29/12
to FHEM users
Freue mich schon auf die elegante Lösung! ;o)
Dann ist der CUNO noch ein Stückchen perfekter.
Könnte sowieso mal wieder regnen... ;o)
Gruß
Frank
On 28 Jul., 09:12, doubh <g.do...@gmail.com> wrote:
> Ich konnte den Fehler bei meinem Aufbau finden und fixen. Seit >48h keine
> Reconnects!
> *Es gibt einen Fehler im Netzwerkcode der culfw.*
> > Nach meiner Analyse returned der Aufruf *my $nfound = select($rout=$rin,
> > undef, undef, $timeout);* in fhem.pl NICHT, wenn die TCP-Verbindung tot
> > DevIo_CloseDev($hash);*. Somit würde beim nächsten ReOpen ein neuer Init
> > versucht.
>
> > Danke für Eure Ratschläge.- Zitierten Text ausblenden -
Dann ist der CUNO noch ein Stückchen perfekter.
Könnte sowieso mal wieder regnen... ;o)
Gruß
Frank
On 28 Jul., 09:12, doubh <g.do...@gmail.com> wrote:
> Ich konnte den Fehler bei meinem Aufbau finden und fixen. Seit >48h keine
> Reconnects!
> > undef, undef, $timeout);* in fhem.pl NICHT, wenn die TCP-Verbindung tot
> > ist. Somit wird nie versucht Daten von diesem FileDescriptor zu lesen und
> > der Abbruch der Verbindung wird nicht erkannt.
> > Erst wenn ein Befehl zum CUNO gesendet und somit der FD-Ptr benutzt wird,
> > wird der Fehler der TCP-Verbindung erkannt.
>
> > Um den Fehler zu umgehen, habe ich eine Notify eingefügt, dass alle 3
> > Minuten einer Versionsabfrage am CUNO startet.
> > Leider ist das meiner Meinung nach ein unschöner Workaround.
>
> > Ich hab alternativ an die Socket-Option Keepalive gedacht, bin mir aber
> > nicht sicher, ob das den gewünschten Erfolg hätte.
> > Hat Jmd damit Erfahrung?
> > Hat Jmd eine bessere Idee oder kann man mit Hilfe der Exception-Abfrage im
> > select-Befehl den Fehler erkennen?
>
> > Desweiteren habe ich noch ein zweites Thema festgestellt:
> > Schlägt beim ReOpen der Init des CUNO fehl (Zeile 236 in DevIo.pm), wird
> > durch den Aufruf von *DevIo_CloseDev($hash);* der FD-Ptr geschlossen,
> > der Abbruch der Verbindung wird nicht erkannt.
> > Erst wenn ein Befehl zum CUNO gesendet und somit der FD-Ptr benutzt wird,
> > wird der Fehler der TCP-Verbindung erkannt.
>
> > Um den Fehler zu umgehen, habe ich eine Notify eingefügt, dass alle 3
> > Minuten einer Versionsabfrage am CUNO startet.
> > Leider ist das meiner Meinung nach ein unschöner Workaround.
>
> > Ich hab alternativ an die Socket-Option Keepalive gedacht, bin mir aber
> > nicht sicher, ob das den gewünschten Erfolg hätte.
> > Hat Jmd damit Erfahrung?
> > Hat Jmd eine bessere Idee oder kann man mit Hilfe der Exception-Abfrage im
> > select-Befehl den Fehler erkennen?
>
> > Desweiteren habe ich noch ein zweites Thema festgestellt:
> > Schlägt beim ReOpen der Init des CUNO fehl (Zeile 236 in DevIo.pm), wird
> > aber der State des Devices bleibt auf "open". Somit wird bis zu einem
> > FHEM-Neustart, dass Device (in meinem Fall der CUNO) nicht wieder
> > initialisiert und kann nicht verwendet werden.
> > Mein Vorschlag: besser *DevIo_Disconnected($hash);* anstelle *
> > FHEM-Neustart, dass Device (in meinem Fall der CUNO) nicht wieder
> > initialisiert und kann nicht verwendet werden.
> > DevIo_CloseDev($hash);*. Somit würde beim nächsten ReOpen ein neuer Init
> > versucht.
>
> > Danke für Eure Ratschläge.- Zitierten Text ausblenden -
Olaf Droegehorn
Jul 29, 2012, 8:18:32 AM7/29/12
to fhem-...@googlegroups.com
Hi und guten Tag,
kannst Du den Fehler benennen und sagen, wie Du ihn gefixt hast ?
Dann k�nnen wir anderen das auch testen, bevor wir es final in die
Firmware einbauen.
Danke,
Gru�,
Olaf
Am 28.07.2012 09:12, schrieb doubh:
> Ich konnte den Fehler bei meinem Aufbau finden und fixen. Seit >48h
> keine Reconnects!
> *Es gibt einen Fehler im Netzwerkcode der culfw.*
> Aktuell habe ich nur einen dirty-hack zum Testen bei mir eingef�gt, aber
> eine sch�ne L�sung sowie genaue Erkl�rung wird die n�chsten Tage folgen
> (wenns mal wieder regnet u nicht so sch�nes Wetter ist :).
>
------------------------------------------------------------------------
Prof. Dr. Olaf Droegehorn
General Manager Tel. : +49-2244-918-4080
DHS - Computertechnik GmbH Fax. : +49-2244-918-4082
Wilhelm-Liebertz-Str. 2c E-Mail: O.Droegehorn@dhs-
computertechnik.de
D-53639 Koenigswinter WEB: www.dhs-computertechnik.de
------------------------------------------------------------------------
kannst Du den Fehler benennen und sagen, wie Du ihn gefixt hast ?
Dann k�nnen wir anderen das auch testen, bevor wir es final in die
Firmware einbauen.
Danke,
Gru�,
Olaf
Am 28.07.2012 09:12, schrieb doubh:
> Ich konnte den Fehler bei meinem Aufbau finden und fixen. Seit >48h
> keine Reconnects!
> Aktuell habe ich nur einen dirty-hack zum Testen bei mir eingef�gt, aber
> eine sch�ne L�sung sowie genaue Erkl�rung wird die n�chsten Tage folgen
> (wenns mal wieder regnet u nicht so sch�nes Wetter ist :).
>
------------------------------------------------------------------------
Prof. Dr. Olaf Droegehorn
General Manager Tel. : +49-2244-918-4080
DHS - Computertechnik GmbH Fax. : +49-2244-918-4082
Wilhelm-Liebertz-Str. 2c E-Mail: O.Droegehorn@dhs-
computertechnik.de
D-53639 Koenigswinter WEB: www.dhs-computertechnik.de
------------------------------------------------------------------------
doubh
Jul 29, 2012, 2:30:19 PM7/29/12
to fhem-...@googlegroups.com
Es gibt in der culfw einen Fehler, der auftritt, wenn ein TCP-Paket retransmittet werden soll. Er führt dazu, dass die culfw meint, dass die Verbindung tot ist und diese dann schließt.
Der Fehler liegt NICHT am TCP/IP-Stack, sondern an der Verwendung des Stacks in den Dateien tcplink.c/h.
Der TCP/IP Stack erwartet im Fall eines Rexmits, dass die App die Daten erneut kopiert und über die Funktion uip_send() die Längenvariablen (uip_slen) korrekt setzt.
Im der App wird im Falle eines Rexmit die Funktion senddata() aufgerufen, die sofort returned, weil beim vorherigen Aufruf, mit dem die Daten das erste Mal versendet werden sollten, der Offset auf 0 zurückgesetzt wurde.
Werden während der 8 Rexmits (8 lt. Define) neue Daten mit Hilfe der Funktion tcp_putchar() in den Puffer gelegt, werden bei einem Rexmit die neuen Daten versendet (da Offset !=0). Dies hat zur Folge, dass der TCP/IP Stack die Rexmit-Schleife wieder verlässt und die ürsprünglichen Daten nicht übertragen werden (da beim Rexmit ja die neuen Daten kopiert wurden).
Werden aber während der Rexmits keine neuen Daten kopiert, werden auch keine TCP-Pakete versendet, aber der TCP/IP Stack zählt seinen Rexmit-Counter herab, bis schließlich die Verbindung für tot erklärt und geschlossen wird.
uip.c[739] = Rexmits sind erforderlich
uip.c[745] = Sind alle Rexmits "fehlgeschlagen" wird die Verbindung geschlossen.uip.c[790] = Hier wird die App aufgerufen, die die Daten wieder kopieren und die zurückgesetzen Len-Variablen (uip.c[722+733]) setzen müsste (über uip_send())
uip.c[1707] = Ist die Längenvariable == 0 wird das Paket in Zeile 1723 verworfen und es findet in Wirklichkeit gar kein Rexmit statt!
Meine Lösung kostet etwas RAM, aber es ist die beste mit wenig Eingriffen in bestehenden Code. Evtl. hat Jmd auch eine bessere Lösung...
In tcplink.h die Struktur erweitern:
struct tcplink_state {
u8_t state;
u8_t offset;
char buffer[250];
u8_t offsetlast;
char bufferlast[250];
};
u8_t state;
u8_t offset;
char buffer[250];
u8_t offsetlast;
char bufferlast[250];
};
In tcplink.c die Funktion tcplink_appcall() wie folgt ändern:
if(uip_rexmit() ||
uip_newdata() ||
uip_acked() ||
uip_connected() ||
uip_poll()) {
senddata(uip_rexmit());
}
uip_newdata() ||
uip_acked() ||
uip_connected() ||
uip_poll()) {
senddata(uip_rexmit());
}
Und die geänderte Funktion senddata() einfügen:
static void
senddata(u8_t rexmit)
{
struct tcplink_state *s = (struct tcplink_state *)&(uip_conn->appstate);
if (rexmit != 0) {
if(s->offsetlast == 0)
return;
// in case of rexmit, use bufferlast and offsetlast
// do not touch current data in s->buffer
memcpy(uip_appdata, s->bufferlast, s->offsetlast);
uip_send(uip_appdata, s->offsetlast);
} else {
if(s->offset == 0)
return;
memcpy(uip_appdata, s->buffer, s->offset);
uip_send(uip_appdata, s->offset);
// copy current offset and data to bufferlast to be able rexmit identical data
memcpy(s->bufferlast, s->buffer, s->offset);
s->offsetlast = s->offset;
s->offset = 0;
}
}
senddata(u8_t rexmit)
{
struct tcplink_state *s = (struct tcplink_state *)&(uip_conn->appstate);
if (rexmit != 0) {
if(s->offsetlast == 0)
return;
// in case of rexmit, use bufferlast and offsetlast
// do not touch current data in s->buffer
memcpy(uip_appdata, s->bufferlast, s->offsetlast);
uip_send(uip_appdata, s->offsetlast);
} else {
if(s->offset == 0)
return;
memcpy(uip_appdata, s->buffer, s->offset);
uip_send(uip_appdata, s->offset);
// copy current offset and data to bufferlast to be able rexmit identical data
memcpy(s->bufferlast, s->buffer, s->offset);
s->offsetlast = s->offset;
s->offset = 0;
}
}
Zusätzlich natürlich Zeile 23 anpassen:
static void senddata(u8_t rexmit);
Mit dieser Änderung werden die Daten immer in einen zweiten Puffer für den Rexmit Fall zwischengespeichert.
Tritt ein Rexmit-Fall auf, werden die alten Daten erneut kopiert und evtl. neu in den Puffer eingefügte Daten müssen warten, bis alle Rexmits abgeschlossen sind.
Am Sonntag, 29. Juli 2012 14:18:32 UTC+2 schrieb Olaf:
Hi und guten Tag,
kannst Du den Fehler benennen und sagen, wie Du ihn gefixt hast ?
Dann k�nnen wir anderen das auch testen, bevor wir es final in die
Firmware einbauen.
Danke,
Gru�,
Olaf
Am 28.07.2012 09:12, schrieb doubh:
> Ich konnte den Fehler bei meinem Aufbau finden und fixen. Seit >48h
> keine Reconnects!
> *Es gibt einen Fehler im Netzwerkcode der culfw.*
> Aktuell habe ich nur einen dirty-hack zum Testen bei mir eingef�gt, aber
> eine sch�ne L�sung sowie genaue Erkl�rung wird die n�chsten Tage folgen
> (wenns mal wieder regnet u nicht so sch�nes Wetter ist :).
doubh
Jul 30, 2012, 4:09:19 AM7/30/12
to fhem-...@googlegroups.com
Ich hatte ganz vergessen zu erwähnen, dass ich den Fix zusammen mit v1.46 (SVN rev 303) für CUNO2 kompiliert und getestet habe.
Message has been deleted
Rudolf Koenig
Jul 30, 2012, 6:46:25 AM7/30/12
to fhem-...@googlegroups.com
> Selbstverst�ndlich geh�rt dieser Fehler in das TCP/IP-Schichtenmodell, den
> so genannten TCP/IP-Stack.
Mag sein, dass es _nach der reinen Lehre_ dahin gehoert, diese TCP/IP
Implementation (uIP) geht aber ungewohnliche Wege, und erfordert aktiven
Support vom user-level Programm. Dafuer laeuft es auf einem 8-bit Controller
mit wenig RAM (<= 1kb) und Programmspeicher.
> so genannten TCP/IP-Stack.
Mag sein, dass es _nach der reinen Lehre_ dahin gehoert, diese TCP/IP
Implementation (uIP) geht aber ungewohnliche Wege, und erfordert aktiven
Support vom user-level Programm. Dafuer laeuft es auf einem 8-bit Controller
mit wenig RAM (<= 1kb) und Programmspeicher.
doubh
Jul 30, 2012, 7:39:48 AM7/30/12
to fhem-...@googlegroups.com
Hier ein Auszug aus der Beschreibung des uIP TCP/IP-Stacks (1.6.1.5 Retransmitting Data):
The application must check the uip_rexmit() flag and produce the same data that was previously sent. From
the application’s standpoint, performing a retransmission is not different from how the data originally was
sent. Therefor, the application can be written in such a way that the same code is used both for sending data
and retransmitting data. Also, it is important to note that even though the actual retransmission operation is
carried out by the application, it is the responsibility of the stack to know when the retransmission should
be made. Thus the complexity of the application does not necessarily increase because it takes an active
part in doing retransmissions
the application’s standpoint, performing a retransmission is not different from how the data originally was
sent. Therefor, the application can be written in such a way that the same code is used both for sending data
and retransmitting data. Also, it is important to note that even though the actual retransmission operation is
carried out by the application, it is the responsibility of the stack to know when the retransmission should
be made. Thus the complexity of the application does not necessarily increase because it takes an active
part in doing retransmissions
Am Montag, 30. Juli 2012 12:31:10 UTC+2 schrieb Prof. Dr. Peter A. Henning:
Selbstverständlich gehört dieser Fehler in das TCP/IP-Schichtenmodell, den so genannten TCP/IP-Stack.
Lies hier: https://learningnetwork.cisco.com/thread/5769
LG
pah
Message has been deleted
puschel74
Jul 30, 2012, 4:20:50 PM7/30/12
to fhem-...@googlegroups.com
Hallo,
hauptsache behoben und wieder gut hier.
Grüße
Am Montag, 30. Juli 2012 22:00:39 UTC+2 schrieb Prof. Dr. Peter A. Henning:
hauptsache behoben und wieder gut hier.
Grüße
Am Montag, 30. Juli 2012 22:00:39 UTC+2 schrieb Prof. Dr. Peter A. Henning:
Soso, da gibt es einen unvollständigen TCP/IP-Stack, und darum gehört ein Fehler im TCP/IP-Stack doch nicht zum Stack ?
Meine Güte, sonst keine Probleme ?
pah
Rudolf Koenig
Jul 30, 2012, 5:04:38 PM7/30/12
to fhem-...@googlegroups.com
> Soso, da gibt es einen unvollst�ndigen TCP/IP-Stack, und darum geh�rt ein
der Stack die Daten nicht merkt (um kein RAM zu verschwenden), muss ein Resend
im User-Level geloest werden, da man hier mehr Moeglichkeiten Daten
platzsparend zu regenerieren.
Ich weiss das, ich habe den User-Level Code verbockt. :)
> Fehler im TCP/IP-Stack doch nicht zum Stack ?
Genau, da das Problem in diesem Fall im User-Level behandelt werden muss. Da
der Stack die Daten nicht merkt (um kein RAM zu verschwenden), muss ein Resend
im User-Level geloest werden, da man hier mehr Moeglichkeiten Daten
platzsparend zu regenerieren.
Ich weiss das, ich habe den User-Level Code verbockt. :)
Steffen
Jul 30, 2012, 11:47:51 PM7/30/12
to fhem-...@googlegroups.com
Guten Morgen!
Kann man diese Lösung auch für HMLAN nehmen, da ich das gleiche problem bei meinem HMLAN habe?!
Mfg Steffen
Message has been deleted
PanTau
Jul 31, 2012, 4:15:28 PM7/31/12
to fhem-...@googlegroups.com
> Aber patziges Verhalten gehört in den Kindergarten...
Na endlich, doch noch Selbstkritik nach dem ganzen "Bockmist". :-)
Weiter so!
Am Dienstag, 31. Juli 2012 12:42:32 UTC+2 schrieb Prof. Dr. Peter A. Henning:
Na endlich, doch noch Selbstkritik nach dem ganzen "Bockmist". :-)
Weiter so!
Am Dienstag, 31. Juli 2012 12:42:32 UTC+2 schrieb Prof. Dr. Peter A. Henning:
Ich habe ja kein Problem damit, dass so etwas gemacht wird - auch ich habe schon Mikro-Webserver auf 8-Bit-Prozessoren implementiert. Aber patziges Verhalten gehört in den Kindergarten...
LG
pah
Message has been deleted
domi
Aug 2, 2012, 4:38:27 PM8/2/12
to fhem-...@googlegroups.com
Hallo,
betrifft dies auch den CUN?
Wenn ja, würde ich mich über einen Bugfix freuen. Ich habe meinen CUN seit längerem außer Betrieb gestellt da ich öfters Verbindungsabbrüche hatte. Nach einem Neustart war's dann immer wieder gut.
Grüße
Domi
Rudolf Koenig
Aug 3, 2012, 2:32:23 AM8/3/12
to fhem-...@googlegroups.com
> betrifft dies auch den CUN?
Sehr wahrscheinlich betrifft es alle culfw geraete mit Netzwerk, also CUN, CUNO
und CUNO2.
> Wenn ja, w�rde ich mich �ber einen Bugfix freuen.
Im Moment fuehlt sich niemand Zustaendig den Fix einzuspielen. Das Problem ist
auch nicht das Einspielen/Uebersetzen, sondern das Testen, und ich teste
ausschliesslich mit CULs. Waer nett wenn jemand sich melden wuerde, ich kann
bei Bedarf gerne SVN Schreibrechte vergeben.
Btw. das ist ein Thema fuer die cul-fans Gruppe.
Martin Fischer
Aug 3, 2012, 2:12:29 PM8/3/12
to fhem-...@googlegroups.com
Am Mittwoch, 18. Juli 2012, 01:37:40 schrieb doubh:
> [...]
CUNO ist noch nicht betroffen..
gruss martin
> [...]
> ich habe hin und wieder (ca. 5-10 pro Tag) Verbindungsabbrüche zwischen
> CUNO und FHEM-Server. Dies hat zur Folge, dass nicht alle CUNO Meldungen
> empfangen werden.
mittlerweile hat es auch mich erwischt, allerding mit einem CUN.
> CUNO und FHEM-Server. Dies hat zur Folge, dass nicht alle CUNO Meldungen
> empfangen werden.
CUNO ist noch nicht betroffen..
gruss martin
PanTau
Aug 3, 2012, 5:00:02 PM8/3/12
to fhem-...@googlegroups.com
Naja den Fix einspielen sollte der "Erfinder"?!
Ich war/bin mit einem CUN0 auch betroffen -und wie - im Urlaub hat dadurch meine Bewässerung den Garten 48h am Stück "beregnet"....
Habe nun den Fix auf die Rev 304 des SVN angewand und meinen kompletten Satz "CUxx" geflasht.
Allerdings hängt nur der CUNO am Netzwerk, den CUNO2 betreibe ich momentan über den USB Anschluß und die CULs kann ich nur auf Nebenwirkungen untersuchen, sind aber eher ausgeschlossen...
Ich werde in ein paar Tagen berichten.
Am Freitag, 3. August 2012 08:32:23 UTC+2 schrieb Rudolf Koenig:
Ich war/bin mit einem CUN0 auch betroffen -und wie - im Urlaub hat dadurch meine Bewässerung den Garten 48h am Stück "beregnet"....
Habe nun den Fix auf die Rev 304 des SVN angewand und meinen kompletten Satz "CUxx" geflasht.
Allerdings hängt nur der CUNO am Netzwerk, den CUNO2 betreibe ich momentan über den USB Anschluß und die CULs kann ich nur auf Nebenwirkungen untersuchen, sind aber eher ausgeschlossen...
Ich werde in ein paar Tagen berichten.
Am Freitag, 3. August 2012 08:32:23 UTC+2 schrieb Rudolf Koenig:
> betrifft dies auch den CUN?
Sehr wahrscheinlich betrifft es alle culfw geraete mit Netzwerk, also CUN, CUNO
und CUNO2.
> Wenn ja, w�rde ich mich �ber einen Bugfix freuen.
Olaf Droegehorn
Aug 3, 2012, 5:33:25 PM8/3/12
to fhem-...@googlegroups.com, doubh
Hi all,
ich hab den Fix heute in meinen CUN, CUNO und CUNO2 eingespielt. Alle
davon mit eigenen Modifikationen (IR, etc.) also etwas �ber den Standard
hinaus.
Werde auch berichten, wie sie sich machen. Aufgrund meiner 4 CUN(Os),
die alle Reconnects haben, wegen vollem Netzwerk und teilweise
PowerLine, werden sich Auswirkungen sicher schnell zeigen.
Gru�,
Olaf
ich hab den Fix heute in meinen CUN, CUNO und CUNO2 eingespielt. Alle
davon mit eigenen Modifikationen (IR, etc.) also etwas �ber den Standard
hinaus.
Werde auch berichten, wie sie sich machen. Aufgrund meiner 4 CUN(Os),
die alle Reconnects haben, wegen vollem Netzwerk und teilweise
PowerLine, werden sich Auswirkungen sicher schnell zeigen.
Gru�,
Olaf
doubh
Aug 4, 2012, 8:19:03 AM8/4/12
to fhem-...@googlegroups.com
Ich habe den Fix selbstverständlich auch in Verwendung u seitdem (>1 Woche) keinen einzigen Reconnect mehr in den Logs entdeckt.
Wenn ich für das Repository Schreibrechte bekomme, werde ich die Änderungen gerne einchecken.
Rudi, kannst du mir einen SVN Zugang erstellen?
Rudolf Koenig
Aug 4, 2012, 10:52:48 AM8/4/12
to fhem-...@googlegroups.com
> Rudi, kannst du mir einen SVN Zugang erstellen?
Gerne, brauche Sourceforge id (nicht Nummer!), am besten per PM. Bitte mit
Olaf koordinieren, er hat schon oefters CUN* Aenderungen durchgefuehrt, und
seinem Beitrag oben klang so, als ob er das einchecken wollte.
Olaf Droegehorn
Aug 5, 2012, 8:26:28 AM8/5/12
to fhem-...@googlegroups.com
Hi all,
ich hab den Fix drin, aber die Reconnects tauchen trotzdem wieder auf.
War also wohl nicht das einzige Problem. Habs zun�chst beim CUNOv1 getestet.
Gru�,
Olaf
Am 04.08.2012 14:19, schrieb doubh:
> Ich habe den Fix selbstverst�ndlich auch in Verwendung u seitdem (>1
> �nderungen gerne einchecken.
> momentan �ber den USB Anschlu� und die CULs kann ich nur auf
> To unsubscribe from this group, send email to
> fhem-users+...@googlegroups.com
--
ich hab den Fix drin, aber die Reconnects tauchen trotzdem wieder auf.
War also wohl nicht das einzige Problem. Habs zun�chst beim CUNOv1 getestet.
Gru�,
Olaf
Am 04.08.2012 14:19, schrieb doubh:
> Ich habe den Fix selbstverst�ndlich auch in Verwendung u seitdem (>1
> Woche) keinen einzigen Reconnect mehr in den Logs entdeckt.
> Wenn ich f�r das Repository Schreibrechte bekomme, werde ich die
> �nderungen gerne einchecken.
> Rudi, kannst du mir einen SVN Zugang erstellen?
>
> Am Freitag, 3. August 2012 23:00:02 UTC+2 schrieb PanTau:
>
> Naja den Fix einspielen sollte der "Erfinder"?!
>
> Ich war/bin mit einem CUN0 auch betroffen -und wie - im Urlaub hat
> dadurch meine Bew�sserung den Garten 48h am St�ck "beregnet"....
>
> Am Freitag, 3. August 2012 23:00:02 UTC+2 schrieb PanTau:
>
> Naja den Fix einspielen sollte der "Erfinder"?!
>
> Ich war/bin mit einem CUN0 auch betroffen -und wie - im Urlaub hat
>
> Habe nun den Fix auf die Rev 304 des SVN angewand und meinen
> kompletten Satz "CUxx" geflasht.
> Allerdings h�ngt nur der CUNO am Netzwerk, den CUNO2 betreibe ich
> Habe nun den Fix auf die Rev 304 des SVN angewand und meinen
> kompletten Satz "CUxx" geflasht.
> momentan �ber den USB Anschlu� und die CULs kann ich nur auf
> Nebenwirkungen untersuchen, sind aber eher ausgeschlossen...
> Ich werde in ein paar Tagen berichten.
>
> Am Freitag, 3. August 2012 08:32:23 UTC+2 schrieb Rudolf Koenig:
>
> > betrifft dies auch den CUN?
>
> Sehr wahrscheinlich betrifft es alle culfw geraete mit Netzwerk,
> also CUN, CUNO
> und CUNO2.
>
> > Wenn ja, w�rde ich mich �ber einen Bugfix freuen.
> Ich werde in ein paar Tagen berichten.
>
> Am Freitag, 3. August 2012 08:32:23 UTC+2 schrieb Rudolf Koenig:
>
> > betrifft dies auch den CUN?
>
> Sehr wahrscheinlich betrifft es alle culfw geraete mit Netzwerk,
> also CUN, CUNO
> und CUNO2.
>
>
> Im Moment fuehlt sich niemand Zustaendig den Fix einzuspielen.
> Das Problem ist
> auch nicht das Einspielen/Uebersetzen, sondern das Testen, und
> ich teste
> ausschliesslich mit CULs. Waer nett wenn jemand sich melden
> wuerde, ich kann
> bei Bedarf gerne SVN Schreibrechte vergeben.
>
> Btw. das ist ein Thema fuer die cul-fans Gruppe.
>
> --
> Im Moment fuehlt sich niemand Zustaendig den Fix einzuspielen.
> Das Problem ist
> auch nicht das Einspielen/Uebersetzen, sondern das Testen, und
> ich teste
> ausschliesslich mit CULs. Waer nett wenn jemand sich melden
> wuerde, ich kann
> bei Bedarf gerne SVN Schreibrechte vergeben.
>
> Btw. das ist ein Thema fuer die cul-fans Gruppe.
>
> To unsubscribe from this group, send email to
> fhem-users+...@googlegroups.com
--
fossy
Sep 8, 2012, 3:59:49 AM9/8/12
to fhem-...@googlegroups.com
Hallo alle zusammen,
irgendwie habe ich auch (in unregelmäßigen Abständen) eine Art "Verbindungsabbrüche" zum CUNO.
Ich verwende eine FB7390 und das CUNO ist über Netzwerk/Switch mit der FB verbunden (also kein WLAN).
Das Problem zeigt sich dadurch, dass vom KS300 und von den FHTs keine Daten mehr ankommen.
Analog zu einem Beitrag weiter oben lasse ich nun - um die Verindung zu prüfen - die Uptime des CUNO ins Log schreiben. Dies geschieht aber ohne Unterbrechung. Die Firmware auf dem CUNO1 ist die Version 1.45.
Nach einem Restart von FHEM kommen dann sofort wieder Meldungen von KS300 und FHT.
Hat jemand eine Erklärung für dieses Verhalten? Ist es möglich, eine Art "Watchdog" zu definieren, der FHEM neu startet, für den Fall dass - sagen wir 30 Minuten - keine Daten vom KS300 angekommen sind? Wenn ja wie?
Vielen Dank für Eure Unterstützung.
cu
fossy
irgendwie habe ich auch (in unregelmäßigen Abständen) eine Art "Verbindungsabbrüche" zum CUNO.
Ich verwende eine FB7390 und das CUNO ist über Netzwerk/Switch mit der FB verbunden (also kein WLAN).
Das Problem zeigt sich dadurch, dass vom KS300 und von den FHTs keine Daten mehr ankommen.
Analog zu einem Beitrag weiter oben lasse ich nun - um die Verindung zu prüfen - die Uptime des CUNO ins Log schreiben. Dies geschieht aber ohne Unterbrechung. Die Firmware auf dem CUNO1 ist die Version 1.45.
Nach einem Restart von FHEM kommen dann sofort wieder Meldungen von KS300 und FHT.
Hat jemand eine Erklärung für dieses Verhalten? Ist es möglich, eine Art "Watchdog" zu definieren, der FHEM neu startet, für den Fall dass - sagen wir 30 Minuten - keine Daten vom KS300 angekommen sind? Wenn ja wie?
Vielen Dank für Eure Unterstützung.
cu
fossy
Ralf
Oct 29, 2012, 11:51:06 AM10/29/12
to fhem-...@googlegroups.com
Hallo!
Am Freitag, 3. August 2012 20:12:29 UTC+2 schrieb Martin Fischer:
Am Freitag, 3. August 2012 20:12:29 UTC+2 schrieb Martin Fischer:
mittlerweile hat es auch mich erwischt, allerding mit einem CUN.
+1
Bei mir reconnected sich der HM-CFG-LAN in unregelmäßigen Abständen (aber eigentlich schon, seitdem das System in Betrieb ist):
2012.10.28 23:36:22 1: 192.168.178.222:1000 disconnected, waiting to reappear2012.10.28 23:36:27 1: 192.168.178.222:1000 reappeared (hmlan1)2012.10.29 00:14:07 2: dummy set Smartphone Abwesend2012.10.29 00:14:10 3: Mail sent to XXX2012.10.29 01:48:32 1: 192.168.178.222:1000 disconnected, waiting to reappear2012.10.29 01:48:37 1: 192.168.178.222:1000 reappeared (hmlan1)2012.10.29 02:08:52 1: 192.168.178.222:1000 disconnected, waiting to reappear2012.10.29 02:08:57 1: 192.168.178.222:1000 reappeared (hmlan1)2012.10.29 02:39:22 1: 192.168.178.222:1000 disconnected, waiting to reappear2012.10.29 02:39:27 1: 192.168.178.222:1000 reappeared (hmlan1)2012.10.29 03:40:23 1: 192.168.178.222:1000 disconnected, waiting to reappear2012.10.29 03:40:28 1: 192.168.178.222:1000 reappeared (hmlan1)2012.10.29 05:01:43 1: 192.168.178.222:1000 disconnected, waiting to reappear2012.10.29 05:01:48 1: 192.168.178.222:1000 reappeared (hmlan1)
Viele Grüße,
Ralf
Uwe
Dec 1, 2012, 3:31:01 PM12/1/12
to fhem-...@googlegroups.com
Ich möchte mich heute auch mal zu dem Thema äußern:
Ich habe einen CUNO2 über LAN an der FB7390. Seit Oktober habe ich immer mal folgende Meldung nach einem Reload bzw. Restart: "Can't connect to 192.168.178.100:2323: Connection timed out".
Ich konnte die Ursache nicht finden und auch ein Update der Firmware des CUNO" von 1.44 auf 1.46 hat das Problem nicht behoben.
Das erste Mal hatte ich den Fehler am 8.10.:
2012.10.08 16:28:47 1: Including fhem.cfg
2012.10.08 16:28:47 3: telnetPort: port 7072 opened
2012.10.08 16:28:47 1: Including /var/InternerSpeicher/fhem/FHEM/00_Webinterface.cfg
2012.10.08 16:28:48 3: WEB: port 8083 opened
2012.10.08 16:28:48 3: WEBphone: port 8084 opened
2012.10.08 16:28:48 3: WEBtablet: port 8085 opened
2012.10.08 16:28:48 1: Including /var/InternerSpeicher/fhem/FHEM/02_Autocreate.cfg
2012.10.08 16:28:48 1: Including /var/InternerSpeicher/fhem/FHEM/04_Funkinterface.cfg
2012.10.08 16:28:48 3: Opening CUNO2 device 192.168.178.100:2323
2012.10.08 16:31:56 3: Can't connect to 192.168.178.100:2323: Connection timed out
2012.10.08 16:31:56 2: Switched CUNO2 rfmode to HomeMatic
2012.10.08 16:31:56 2: Switched IRDEV irReceive to NoAnswer
2012.10.08 16:31:56 1: Including /var/InternerSpeicher/fhem/FHEM/06_Devices.cfg
2012.10.08 16:31:56 1: define: HMid DEF already used by WZ_Rolali
2012.10.08 16:31:56 3: Please define WZ_Rolali first
2012.10.08 16:31:56 3: Please define WZ_Rolali first
Dann werden alle HM-Geräte als fehlend aufgelistet. Leider lässt sich der CUNO erst mit einem Neustart der FB wieder ansprechen; aber das ist ja nur ein "Herumdocktern" an den Symptomen und auch keine Lösung (beim Restart der FB kein Internet und somit z.B. auch kein VoIP usw.).
Die damalige Fhem-Version war: Server started (version Fhem 5.2 (DEVELOPMENT), $Id: fhem.pl 1764 2012-07-28 06:27:09Z rudolfkoenig $, pid 5743)
Jetzt habe ich die aktuelle laufen: 2012.12.01 16:46:53 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2236 2012-12-01 02:24:26Z mfr69bs $, pid 22203)
Ein erstes Shutdown restart verlief fehlerfrei, ein späteres Rereadcfg brachte wieder den Fehler. Ich habe meine cfg in mehrere Teile gesplittet, die allgemeine Initialisierung entspricht der in der Standardconfig.
In der Includedatei "04_Funkinterface.cfg" wird der CUNO initialisiert:
define CUNO2 CUL 192.168.178.100:2323 1234
define IRDEV CUL_IR CUNO2
attr IRDEV irReceive ON_NR
attr IRDEV learncount 0
attr IRDEV learnprefix A
attr IRDEV loglevel 5
Hat noch jemand dieses Problem (und evtl. gelöst)?
Danke im Voraus für die Hilfe, Uwe
Ich habe einen CUNO2 über LAN an der FB7390. Seit Oktober habe ich immer mal folgende Meldung nach einem Reload bzw. Restart: "Can't connect to 192.168.178.100:2323: Connection timed out".
Ich konnte die Ursache nicht finden und auch ein Update der Firmware des CUNO" von 1.44 auf 1.46 hat das Problem nicht behoben.
Das erste Mal hatte ich den Fehler am 8.10.:
2012.10.08 16:28:47 1: Including fhem.cfg
2012.10.08 16:28:47 3: telnetPort: port 7072 opened
2012.10.08 16:28:47 1: Including /var/InternerSpeicher/fhem/FHEM/00_Webinterface.cfg
2012.10.08 16:28:48 3: WEB: port 8083 opened
2012.10.08 16:28:48 3: WEBphone: port 8084 opened
2012.10.08 16:28:48 3: WEBtablet: port 8085 opened
2012.10.08 16:28:48 1: Including /var/InternerSpeicher/fhem/FHEM/02_Autocreate.cfg
2012.10.08 16:28:48 1: Including /var/InternerSpeicher/fhem/FHEM/04_Funkinterface.cfg
2012.10.08 16:28:48 3: Opening CUNO2 device 192.168.178.100:2323
2012.10.08 16:31:56 3: Can't connect to 192.168.178.100:2323: Connection timed out
2012.10.08 16:31:56 2: Switched CUNO2 rfmode to HomeMatic
2012.10.08 16:31:56 2: Switched IRDEV irReceive to NoAnswer
2012.10.08 16:31:56 1: Including /var/InternerSpeicher/fhem/FHEM/06_Devices.cfg
2012.10.08 16:31:56 1: define: HMid DEF already used by WZ_Rolali
2012.10.08 16:31:56 3: Please define WZ_Rolali first
2012.10.08 16:31:56 3: Please define WZ_Rolali first
Dann werden alle HM-Geräte als fehlend aufgelistet. Leider lässt sich der CUNO erst mit einem Neustart der FB wieder ansprechen; aber das ist ja nur ein "Herumdocktern" an den Symptomen und auch keine Lösung (beim Restart der FB kein Internet und somit z.B. auch kein VoIP usw.).
Die damalige Fhem-Version war: Server started (version Fhem 5.2 (DEVELOPMENT), $Id: fhem.pl 1764 2012-07-28 06:27:09Z rudolfkoenig $, pid 5743)
Jetzt habe ich die aktuelle laufen: 2012.12.01 16:46:53 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2236 2012-12-01 02:24:26Z mfr69bs $, pid 22203)
Ein erstes Shutdown restart verlief fehlerfrei, ein späteres Rereadcfg brachte wieder den Fehler. Ich habe meine cfg in mehrere Teile gesplittet, die allgemeine Initialisierung entspricht der in der Standardconfig.
In der Includedatei "04_Funkinterface.cfg" wird der CUNO initialisiert:
define CUNO2 CUL 192.168.178.100:2323 1234
define IRDEV CUL_IR CUNO2
attr IRDEV irReceive ON_NR
attr IRDEV learncount 0
attr IRDEV learnprefix A
attr IRDEV loglevel 5
Hat noch jemand dieses Problem (und evtl. gelöst)?
Danke im Voraus für die Hilfe, Uwe
Uwe
Dec 1, 2012, 4:33:55 PM12/1/12
to fhem-...@googlegroups.com
Die "04 Funkinterface" beinhaltet natürlich:attr CUNO2 rfmode HomeMatic
define IRDEV CUL_IR CUNO2
attr IRDEV irReceive ON_NR
attr IRDEV learncount 0
attr IRDEV learnprefix A
attr IRDEV loglevel 5
Die zweite Zeile ist irgendwo verschütt gegangen beim Kopieren.
define IRDEV CUL_IR CUNO2
attr IRDEV irReceive ON_NR
attr IRDEV learncount 0
attr IRDEV learnprefix A
attr IRDEV loglevel 5
Reply all
Reply to author
Forward
0 new messages