Verbindungsabbruch CUNO <=> FHEM

Begonnen von Guest, 18 Juli 2012, 10:37:40

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten1 2 3 4 Alle
Benutzer-Aktionen

Guest

18 Juli 2012, 10:37:40
Originally posted by: <email address deleted>

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.
 
 
 

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

rudolfkoenig

#1
18 Juli 2012, 11:35:20
                                                   

> 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).


> 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

#2
18 Juli 2012, 14:05:03
Originally posted by: <email address deleted>

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ß

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

rudolfkoenig

#3
18 Juli 2012, 14:41:44
                                                   

> 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).

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Mitch

#4
18 Juli 2012, 21:35:18
                                                     

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.

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
> > 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).
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM im Proxmox Container

rudolfkoenig

#5
18 Juli 2012, 21:41:37
                                                   

> Geaendert wurde eigentlich nichts, ausser dem Standort.

Auch kein fhem-Update?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Mitch

#6
18 Juli 2012, 21:45:18
                                                     

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.

Am Mittwoch, 18. Juli 2012 21:41:37 UTC+2 schrieb Rudolf Koenig:
>
> > Geaendert wurde eigentlich nichts, ausser dem Standort.
>
> Auch kein fhem-Update?
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM im Proxmox Container

Guest

#7
19 Juli 2012, 07:30:00
Originally posted by: <email address deleted>

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

On 18 Jul., 21:45, Mitch wrote:
> 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.
>
> Am Mittwoch, 18. Juli 2012 21:41:37 UTC+2 schrieb Rudolf Koenig:
>
>
>
>
>
> > > Geaendert wurde eigentlich nichts, ausser dem Standort.
>
> > Auch kein fhem-Update?- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

#8
19 Juli 2012, 08:38:15
Originally posted by: <email address deleted>

Hallo!

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!!!


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

#9
19 Juli 2012, 09:59:56
Originally posted by: <email address deleted>

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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Mitch

#10
19 Juli 2012, 21:12:42
                                                     

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 :-(



Am Donnerstag, 19. Juli 2012 09:59:56 UTC+2 schrieb doubh:
>
> 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.
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM im Proxmox Container

Mitch

#11
20 Juli 2012, 20:30:57
                                                     

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.



Am Donnerstag, 19. Juli 2012 21:12:42 UTC+2 schrieb Mitch:
>
> 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 :-(
>
>
>
> Am Donnerstag, 19. Juli 2012 09:59:56 UTC+2 schrieb doubh:
>>
>> 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.
>>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
FHEM im Proxmox Container

rudolfkoenig

#12
21 Juli 2012, 14:49:48
                                                   

> 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

#13
22 Juli 2012, 00:27:44
Originally posted by: <email address deleted>

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.
>
> 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.
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

#14
22 Juli 2012, 20:11:38
Originally posted by: <email address deleted>

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?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Drucken
Nach oben Seiten1 2 3 4 Alle
Benutzer-Aktionen