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
> 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
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
> 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
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
> Geaendert wurde eigentlich nichts, ausser dem Standort.
Auch kein fhem-Update?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@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.
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
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
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
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
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
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
> 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
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
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
Am 22.07.2012 um 20:11 schrieb doubh:
> Hat Jmd noch Ideen was man überwachen bzw. testen könnte?
Könnt ihr mal die MAC Adresse ansehen und sicherstellen, dass diese nur einmal vorkommt? Der Suffix der CUNO MAC Adressen werden zufällig erzeugt und sind somit nicht zwangsläufig eindeutig. (Ist aber nur relevant wenn man mehr als ein CUNO im Netz hat)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich tippe auf ein Problem des TCP/IP-Stack in der CUNO Firmware.
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo Rudolf,
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?
>
> 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.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 1. fhem 5.2 downloaden und installieren
Woher downloaden? AVM oder fhem.de?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@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.
Am Dienstag, 24. Juli 2012 22:07:06 UTC+2 schrieb Rudolf Koenig:
>
> > 1. fhem 5.2 downloaden und installieren
>
> Woher downloaden? AVM oder fhem.de?
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 "
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 :).
Am Mittwoch, 18. Juli 2012 10:37:40 UTC+2 schrieb doubh:
> 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
Originally posted by: <email address deleted>
Habe ich ja oben geschrieben ...
LG
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
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
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Bockmist.
Mein Hinweis war eine korrekte Lokalisierung des Fehlers.
Für Nachhilfe im Programmieren bin ich nicht zuständig.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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 wrote:
> 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 :).
>
> Am Mittwoch, 18. Juli 2012 10:37:40 UTC+2 schrieb doubh:
>
>
>
> > 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.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
------------------------------------------------------------------------
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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];
};*
In tcplink.c die Funktion *tcplink_appcall()* wie folgt ändern:
* if(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;
}
}*
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 :).
> >
> ------------------------------------------------------------------------
> 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
> ------------------------------------------------------------------------
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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.
Am Sonntag, 29. Juli 2012 20:30:19 UTC+2 schrieb doubh:
> 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];
> };*
>
>
> In tcplink.c die Funktion *tcplink_appcall()* wie folgt ändern:
> * if(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;
> }
> }*
>
> 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.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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*
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
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@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:
>
> 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
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Soso, da gibt es einen unvollständigen TCP/IP-Stack, und darum gehört ein
> 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. :)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Guten Morgen!
Kann man diese Lösung auch für HMLAN nehmen, da ich das gleiche problem bei
meinem HMLAN habe?!
Mfg Steffen
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
> 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:
>
> 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
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Sehr guter inhaltlicher Beitrag.
pah
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am Mittwoch, 18. Juli 2012, 01:37:40 schrieb doubh:
> [...]
> 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 ist noch nicht betroffen..
gruss martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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:
>
> > 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.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
------------------------------------------------------------------------
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
------------------------------------------------------------------------
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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"....
>
> 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.
>>
>> 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+unsubscribe@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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
> 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"....
>
> 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.
>
> 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+unsubscribe@googlegroups.com
--
------------------------------------------------------------------------
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
------------------------------------------------------------------------
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@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
Am Montag, 29. Oktober 2012 16:51:07 UTC+1 schrieb Ralf:
>
> Hallo!
>
>
> 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
> reappear
> 2012.10.28 23:36:27 1: 192.168.178.222:1000 reappeared (hmlan1)
> 2012.10.29 00:14:07 2: dummy set Smartphone Abwesend
> 2012.10.29 00:14:10 3: Mail sent to XXX
> 2012.10.29 01:48:32 1: 192.168.178.222:1000 disconnected, waiting to
> reappear
> 2012.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
> reappear
> 2012.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
> reappear
> 2012.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
> reappear
> 2012.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
> reappear
> 2012.10.29 05:01:48 1: 192.168.178.222:1000 reappeared (hmlan1)
>
>
> Viele Grüße,
> Ralf
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Die "04 Funkinterface" beinhaltet natürlich:
define CUNO2 CUL 192.168.178.100:2323 1234
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.
Am Samstag, 1. Dezember 2012 21:31:01 UTC+1 schrieb Uwe:
>
> 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
>
>
> Am Montag, 29. Oktober 2012 16:51:07 UTC+1 schrieb Ralf:
>>
>> Hallo!
>>
>>
>> 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
>> reappear
>> 2012.10.28 23:36:27 1: 192.168.178.222:1000 reappeared (hmlan1)
>> 2012.10.29 00:14:07 2: dummy set Smartphone Abwesend
>> 2012.10.29 00:14:10 3: Mail sent to XXX
>> 2012.10.29 01:48:32 1: 192.168.178.222:1000 disconnected, waiting to
>> reappear
>> 2012.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
>> reappear
>> 2012.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
>> reappear
>> 2012.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
>> reappear
>> 2012.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
>> reappear
>> 2012.10.29 05:01:48 1: 192.168.178.222:1000 reappeared (hmlan1)
>>
>>
>> Viele Grüße,
>> Ralf
>>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo!
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
reappear
2012.10.28 23:36:27 1: 192.168.178.222:1000 reappeared (hmlan1)
2012.10.29 00:14:07 2: dummy set Smartphone Abwesend
2012.10.29 00:14:10 3: Mail sent to XXX
2012.10.29 01:48:32 1: 192.168.178.222:1000 disconnected, waiting to
reappear
2012.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
reappear
2012.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
reappear
2012.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
reappear
2012.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
reappear
2012.10.29 05:01:48 1: 192.168.178.222:1000 reappeared (hmlan1)
Viele Grüße,
Ralf
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com