CUNO2: Disconnected – taucht aber nach wiederholten FS20-Nachrichten wieder auf

Begonnen von Baumi, 20 September 2014, 16:22:19

Vorheriges Thema - Nächstes Thema

Baumi

Hallo,

ich bin erst vor ein paar Wochen in die FHEM-Welt eingestiegen, um meine HUE-Lampen anzusteuern, das klappt auch erstaunlich gut. Ich hatte vorher lange auf eine Sammlung aus selbstgeschriebenen Skripten gesetzt, aber FHEM kann alles das, was die konnten, und noch viel, viel mehr. Also danke an alle für diese tolle Software.

Jetzt habe ich Blut geleckt und will mein System um FS20 erweitern, und da gibt es leider ein paar Probleme: Ich habe einen aktuelle CUNO via Ethernet angeschlossen. Allerdings hat er im Moment meist nichts zu tun hat. FS20-Empfänger habe ich noch gar keine, und mein einziger FS20-Sender (ein Erschütterungssensor ES1 von ELV) ist halb defekt: Ich kann per Programmiertasten Signale verschicken, aber der eigentliche Neigungssensor ist anscheinend kaputt. Daher ist der CUNO zwar angeschlossen aber i.d.R. untätig.

Der Status dieses unterforderten CUNO ändert sich nun regelmäßig (meist nach ca. 2 1/2 Stunden) auf "disconnected". Das Gerät ist dann per Telnet nicht mehr ansprechbar und lässt sich auch nicht über "set MY_CUNO raw B00"  zum Reset bewegen. Die Kommandos kommen anscheinend schlichtweg nicht an. (Ich habe leider noch nicht den Status der LEDs am Netzwerkport und auf der Platine überprüft.)

Wenn ich allerdings ein paar FS20 Funksignale sende (manuelles Auslösen des ES1 via Tastendruck) erwacht der CUNO wieder – aber nicht nach dem ersten Mal, sondern erst nach dem zweiten oder dritten Signal. Dann ist er wieder ansprechbar, sowohl via FHEM als auch via Telnet, bis das Spiel nach  ca. 2/12 Stunden von Neuem losgeht. Die Uptime wird dabei weiter hochgezählt, d.h. ich habe im Moment eine Uptime von fast 24 Stunden (da habe ich das Gerät das letzte Mal vom Strom genommen), obwohl der CUNO lt. FHEM die ganze Nacht "disconnected" war und auch am Morgen schon zwei Mal nicht ansprechbar war.

Die Eckdaten:

Ich benutze einen frisch vorn Busware gelieferten aktuellen CUNO, den ich mit der aktuellen culfw-Version für CUNO2 geflasht habe. (Falls das für die Bestimmung Hardware-Revision von Bedeutung sein sollte: Die Platinen-LED leuchtet im Programmier-Modus nicht durchgehend – wie anscheinend bei älteren Modellen – sondern blinkt ungefähr im Sekunden-Takt.)

Das Flashen verlief problemlos, V gibt als Antwort

V 1.61 CUNO868

Das Gerät ist via Ethernet am selben Hub wie der FHEM-Rechner (ein Mac Mini) angeschlossen, die IP wird per DHCP vergeben, aber so, dass sie immer gleich bleibt.

Hier die relevanten Auszüge aus den Logs (verbose 5):

CUNO verschwindet:
2014.09.20 13:35:13 1: 192.168.178.46:2323 disconnected, waiting to reappear (MY_CUNO)
2014.09.20 13:35:13 5: Triggering MY_CUNO (1 changes)
2014.09.20 13:35:13 5: Notify loop for MY_CUNO DISCONNECTED
2014.09.20 13:35:13 4: eventTypes: CUL MY_CUNO DISCONNECTED -> DISCONNECTED


Erfolgloser Versuch von mir, Kontakt aufzunehmen:

2014.09.20 14:15:25 4: HTTP FHEMWEB:192.168.178.49:59527 GET /fhem?cmd={ReadingsVal(%22MY_CU
NO%22,%22bWidth%22,%22%22)}&XHR=1
2014.09.20 14:15:25 5: Cmd: >{ReadingsVal("MY_CUNO","bWidth","")}<
2014.09.20 14:15:25 4: /fhem?cmd={ReadingsVal(%22MY_CUNO%22,%22bWidth%22,%22%22)}&XHR=1 / RL
:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2014.09.20 14:15:25 4: HTTP FHEMWEB:192.168.178.49:59527 GET /fhem?cmd={AttrVal(%22MY_CUNO%2
2,%22room%22,%22%22)}&XHR=1
2014.09.20 14:15:25 5: Cmd: >{AttrVal("MY_CUNO","room","")}<
2014.09.20 14:15:25 4: /fhem?cmd={AttrVal(%22MY_CUNO%22,%22room%22,%22%22)}&XHR=1 / RL:21 /
text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2014.09.20 14:15:25 4: HTTP FHEMWEB:192.168.178.49:59527 GET /fhem?XHR=1&inform=type=status;filter=MY_CUNO&timestamp=1411215325515
2014.09.20 14:15:29 4: HTTP FHEMWEB:192.168.178.49:59528 GET /fhem?cmd={ReadingsVal(%22MY_CUNO%22,%22raw%22,%22%22)}&XHR=1
2014.09.20 14:15:29 5: Cmd: >{ReadingsVal("MY_CUNO","raw","")}<
2014.09.20 14:15:29 4: /fhem?cmd={ReadingsVal(%22MY_CUNO%22,%22raw%22,%22%22)}&XHR=1 / RL:34 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/


Und nachdem ich zwei oder drei mal eine Funksignal via ES1 abgeschickte habe:

2014.09.20 14:17:16 1: 192.168.178.46:2323 reappeared (MY_CUNO)
2014.09.20 14:17:16 5: SW: V
2014.09.20 14:17:16 5: CUL/RAW (ReadAnswer): V 1.61 CUNO868

2014.09.20 14:17:16 5: SW: ?
2014.09.20 14:17:16 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of m B C F Z i A G M R T V W X O e f l t u H x E c q

2014.09.20 14:17:16 3: MY_CUNO: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq
2014.09.20 14:17:16 5: SW: X21
2014.09.20 14:17:16 5: SW: T01
2014.09.20 14:17:16 5: CUL/RAW (ReadAnswer): 0000

2014.09.20 14:17:16 5: GOT CUL fhtid: 0000
2014.09.20 14:17:16 5: Triggering MY_CUNO (1 changes)
2014.09.20 14:17:16 5: Notify loop for MY_CUNO CONNECTED
2014.09.20 14:17:16 4: eventTypes: CUL MY_CUNO CONNECTED -> CONNECTED


Für mich sieht das aus, als ob die Netzwerk-Verbindung nach einer gewissen Zeit (wegen Untätigkeit?) "einschläft", alle ankommenden Signale ignoriert und erst wieder "wach" wird, wenn Funksignale eintreffen. Im Moment habe ich einen at-Job in FHEM laufen, der jede Minute ein "get version" sendet, in der Hoffnung dass regelmäßige Aktivität auf der Ethernet-Seite das Gerät davon abhält, sich zu verabschieden. Noch ist es allerdings zu früh, um zu sagen, ob das etwas gebracht hat – wenn ich innerhalb der nächsten 24 Stunden keinen "disconnect" mehr haben sollte, würde ich es mal als funktionierenden Workaround werten. Sollte das Problem tatsächlich mit der geringen Auslastung des CUNO zusammenhängen, kann ich mir auch vorstellen, dass es sich von selbst erledigen würde, sobald ich ich mehr FS20-Geräte habe, so dass ein reglmäßiger Funkverkehr stattfindet.

Allerdings zögere ich natürlich, mir weitere Hardware zuzulegen, solange der UNO nicht einwandfrei läuft, und es wäre wohl sowieso schöner, die Ursache des Problems zu finden. Da das Gerät auch via Telnet nicht erreichbar ist, gehe ich mal davon aus, dass der Fehler nicht in FHEM sondern in culfw liegen dürfte. Ich hab' leider selber null Erfahrung in Firmware-Programmierung, bin aber gerne bereit mögliche Bugfixes und Patches zu testen. Immerhin scheint das Problem zumindest auf meinem Gerät leicht reproduzierbar zu sein. Sollte es noch andere Dinge geben, die ich ausprobieren oder vom Gerät abfragen kann, sagt bitte Bescheid.

Vielen Dank für jede Unterstützung. Und nochmal danke für die insgesamt wirklich tolle Software!

Baumi

Update nach fast 24 Stunden:

Seitdem der FHEM-Rechner regelmäßig die Firmware-Version abfragt, ist der CUNO online geblieben. Also scheint der Hänger tatsächlich dann aufzutreten, wenn über zu lange Zeit keine Daten über die Ethernet-Schnittstelle ausgetauscht werden.

rudolfkoenig

Kannst du die Intervalle sukzessive verlaengern, und so den notwendigen Intervall feststellen?
Das koennte beim debuggen behilflich sein.
Vermutlich ist das Problem bei anderen nicht relevant, weil diverse Sender (tempratur/heizungsregler/etc) regelmaessig senden.

Baumi

Danke für die Rückmeldung.

Ich kann gerne versuchen, die Zeit weiter einzugrenzen. Ein paat Näherungswerte habe ich auch jetzt schon, falls die was helfen.

Hier die bisherigen Intervalle:


2014.09.19 21:08:43 1: 192.168.178.46:2323 reappeared (MY_CUNO)
[...]
2014.09.19 23:23:23 1: 192.168.178.46:2323 disconnected, waiting to reappear (MY_CUNO)


Leider keine weiteren Informationen, da der Loglevel noch niedrig war. Zwischen den Einträgen liegen 8080 Sekunden.

Nächster Intervall (ebenfalls noch bei verbose 1):

2014.09.19 23:52:33 1: 192.168.178.46:2323 reappeared (MY_CUNO)
[...]
2014.09.20 02:10:57 1: 192.168.178.46:2323 disconnected, waiting to reappear (MY_CUNO)


Das sind 8304 Sekunden.

Beim nächsten Mal hab' ich dann endlich den Loglevel hochgeschraubt:

2014.09.20 11:04:43 1: 192.168.178.46:2323 reappeared (MY_CUNO)
2014.09.20 11:04:43 3: MY_CUNO: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq
2014.09.20 11:04:43 5: Triggering MY_CUNO (1 changes)
2014.09.20 11:04:43 5: Notify loop for MY_CUNO CONNECTED
2014.09.20 11:04:43 4: eventTypes: CUL MY_CUNO CONNECTED -> CONNECTED
2014.09.20 11:04:43 4: CUL_Parse: MY_CUNO F11BB003A4F0D -67.5
2014.09.20 11:04:43 5: MY_CUNO dispatch 810c04xx0101a00111bb00003a4f
[...]
2014.09.20 11:17:14 4: HTTP FHEMWEB:192.168.178.49:56423 GET /fhem?XHR=1&inform=type=status;filter=MY_CUNO&timestamp=1411204634014
2014.09.20 11:17:17 4: HTTP FHEMWEB:192.168.178.49:56424 GET /fhem&detail=MY_CUNO&dev.getMY_CUNO=MY_CUNO&cmd.getMY_CUNO=get&arg.getMY_CUNO=uptime
2014.09.20 11:17:17 5: Cmd: >get MY_CUNO uptime<
2014.09.20 11:17:17 4: /fhem&detail=MY_CUNO&dev.getMY_CUNO=MY_CUNO&cmd.getMY_CUNO=get&arg.getMY_CUNO=uptime / RL:1021 / text/html; charset=UTF-8 / Content-Encoding: gzip
[...]
2014.09.20 13:35:13 1: 192.168.178.46:2323 disconnected, waiting to reappear (MY_CUNO)


Zwischen der letzten Interaktion mit den CUNO (11:17:17) und dem Disconnect (13:35:13) liegen hier 8276 Sekunden.

Beim ersten Mal ging das Gerät also auf jeden Fall nach spätestens 8080 Sekunden offline (evtl. noch etwas früher, schließlich wurde die Kommunikation FHEM<->CUNO nicht im Detail geloggt), während es beim letzten Mal mit höherem Loglevel 8276 Sekunden durchhielt.

Ich weiß ich nicht, wie oft FHEM den Verbindungsstatus aktualisiert und welchen Timeout es hat, bevor ein Gerät als disconnected eingestuft wird, insofern ist es gut möglich, dass der CUNO sich immer nach derselben Anzahl von Sekunden verabschiedet, und  die unterschiedlichen Log-Zeiten nur dadurch zustande kommen, dass FHEM es erst nach einer gewissen Zeit mitbekommt.

Ich weiß nicht, ob ich die Zeiten noch viel genauer hinbekomme, aber ich versuche mal, das Ganze etwas einzugrenzen – zunächst einmal mit einem Intervall von +*02:13:20 (= 8000) Sekunden.

rudolfkoenig

Bauchgefuehl:
- neuerdings wird im DevIo automatisch SO_KEEPALIVE bestellt, was ca nach 2 Stunden zuschlaegt.
- das im CUNO verwendete uip kann KEEPALIVE nicht korrekt beantworten, oder culfw hat uip nicht richtig konfiguriert.

Baumi

So, bei einem Intervall von 2:13:20 gab es keinen Disconnect. Ich bin jetzt auf 2:15:00 hoch gegangen, mal gucken, ob das reicht, um einen Fehler zu provozieren.

Noch was: Wenn das Gerät wieder hängen sollte, gibt es dann noch irgendwelche Tests, die ich durchführen könnte, um den Fehler weiter einzugrenzen?

Danke für die Unterstützung!

rudolfkoenig

Ich fuerchte die naechste Runde wird haerter: man muesste auf Netwerkebene feststellen, welche Pakete gesendet werden, und irgendwo nachschlagen, was eigentlich haette passieren sollen.

Wenn du Spass daran hast mir ein culfw oder CUL Patch zu bauen, dann nur zu, aber fuer mich waere ein Workaround mit get, oder noch einfacher, irgendwelche Sensoren auf SlowRF Basis (EM/FHT/HMS/TX) auch ok.

Baumi

Ist wieder aufgetreten:

2014.09.21 15:32:10 4: HTTP FHEMWEB:192.168.178.49:58245 GET /fhem&detail=pingCUNO&detail=pingCUNO&val.modifypingCUNO=%2B*02%3A15%3A00+get+MY_CUNO+version&cmd.modifypingCUNO=modify+pingCUNO
2014.09.21 15:32:10 5: Cmd: >modify pingCUNO +*02:15:00 get MY_CUNO version<
[...]
2014.09.21 15:32:18 4: HTTP FHEMWEB:192.168.178.49:58247 GET /fhem&detail=MY_CUNO&dev.getMY_CUNO=MY_CUNO&cmd.getMY_CUNO=get&arg.getMY_CUNO=version
2014.09.21 15:32:18 5: Cmd: >get MY_CUNO version<
2014.09.21 15:32:18 4: /fhem&detail=MY_CUNO&dev.getMY_CUNO=MY_CUNO&cmd.getMY_CUNO=get&arg.getMY_CUNO=version / RL:1025 / text/html; charset=UTF-8 / Content-Encoding: gzip
[...]
2014.09.21 17:45:41 1: 192.168.178.46:2323 disconnected, waiting to reappear (MY_CUNO)
2014.09.21 17:45:41 5: Triggering MY_CUNO (1 changes)
2014.09.21 17:45:41 5: Notify loop for MY_CUNO DISCONNECTED
2014.09.21 17:45:41 4: eventTypes: CUL MY_CUNO DISCONNECTED -> DISCONNECTED
[...]
2014.09.21 17:47:10 5: Cmd: >get MY_CUNO version<
2014.09.21 17:47:10 3: pingCUNO: MY_CUNO version => No answer
2014.09.21 17:47:10 5: redefine at command pingCUNO as +*02:15:00 get MY_CUNO version


Zeit zwischen letztem Kommando (15:32:18) und Disconnect (17:45:41): 8003 Sekunden. Also scheint die magische Grenze wirklich irgendwo bei 8000 Sekunden zu liegen.

Was das weitere Debugging angeht: Beim Patchbau muss ich leider passen – ich kann zwar ganz ordentliche Perl-Skripte schreiben und mich sicher auch einigermaßen in die Grundlagen von C reinfuchsen, aber in Sachen Low-Level-TCP-Kommunikation und Firmware-Programmierung müsste ich wirklich bei Null anfangen. Außerdem tritt der Fehler ja anscheinend wirklich nur unter sehr spezifischen Umständen auf und lässt sich auch leicht umgehen, falls es nochmal jemand anderen treffen sollte. Ich fänd's also auch nicht schlimm, das bis auf Weiteres einfach über einen at-Job zu regeln. Sobald ich ein paar mehr FS20-Geräte installiert habe, wird sich das Problem wohl eh von selbst erledigen.

Nur eine Frage interessehalber noch: Der CUNO ist nach dem Disconnect ja auch nicht mehr via Telnet zu erreichen, weder vom FEHM-System noch von anderen Rechnern. (Anpingen lässt er sich aber noch.) Passt so ein Verhalten zu einem Bug beim Keepalive? Wie gesagt, ich kenn' mich überhaupt nicht aus, was Low-Level-TCP angeht.


ojb

Hallo Leute,

ich scheine ein ähnliches Problem zu haben.

Ich habe am Wochenende meinen CUNO in Betrieb genommen und ich bekomme auch ähnliche Meldungen

Setup:
- FHEM auf Lubuntu-Maschine im Keller.
- CUNO am LAN im Wohnzimmer

Über den CUNO werden im Moment nur Funksteckdosen gesteuert, das heisst er idle'd auch die meiste Zeit rum.

Folgendes passiert:

2014.10.20 12:59:53 1: 192.168.178.56:2323 disconnected, waiting to reappear (cuno)
2014.10.20 13:02:20 1: 192.168.178.56:2323 reappeared (cuno)
2014.10.20 13:02:20 3: cuno: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq
2014.10.20 13:57:54 1: 192.168.178.56:2323 disconnected, waiting to reappear (cuno)
2014.10.20 14:38:54 1: 192.168.178.56:2323 reappeared (cuno)
2014.10.20 14:38:54 3: cuno: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq


Man sieht er hat sich um 12:59 verabschiedet, war aber 13:02 wieder da und wurde auch wieder von FHEM erkannt.
Trotzdem ist es hier oft so, dass er dann nicht mehr reagiert. 'get cuno uptime' ergibt dann 'no answer'

Um 13:57 war er wieder weg, wurde dann aber überhaupt nicht mehr erkannt.
Erst als ich um 14:38 manuell 'set cuno reopen' ausführte war er für FHEM wieder da.

Anpingen konnte ich den CUNO immer.

Ich habe jetzt mal einen at-Job eingebaut der alle 15 Minuten die uptime abfrägt. Mal sehen ob das was bringt.

Ist das reopen eigentlich "schädlich". Sonst könnte man ja auch alle 15 Minuten ein reopen durchführen oder in meinem Fall zur Sicherheit bevor man Funkbefehle für die Funksteckdosen absetzt.

Der CUNO ist übrigens ca. 20 cm von einer FritzBox weg. Daran kann es doch nicht liegen, oder?

Um jede Hilfe dankbar.

Liebe Grüße
Oli
FHEM unter Debian auf Asus EEBox: KNX (Wetterstation, Rollläden, Beleuchtung), Maple-CUN (Temperatur und Feuchte über 1-Wire, Intertechno-Funksteckdosen), PV-Anlage mit Plenticore und BYD, Viessmann Wärmepumpe, 1-Wire (Temperatur, Feuchte, Stromverbrauch), Husquarna-Automower, ...

ojb

Hallo Leute,

ich habe ja gestern den Versuch gemacht mit 15-minütigen Alive Nachrichten. Ergebnis war ein erneuter Ausstieg.

Bei der Analyse des Logfiles fiel mir allerdings auf dass der 'disconnect' ein paar Sekunden vor meiner Alive Abfrage kam.

Ich vermute jetzt dass mein CUNO bei 15 Minuten Inaktivität die Verbindung kappt.

Daraufhin habe ich den Alive-Counter auf 5 Minuten Intervall verkürzt und nun läuft es seit 18,5 Stunden stabil.

Liebe Grüße
Oli
FHEM unter Debian auf Asus EEBox: KNX (Wetterstation, Rollläden, Beleuchtung), Maple-CUN (Temperatur und Feuchte über 1-Wire, Intertechno-Funksteckdosen), PV-Anlage mit Plenticore und BYD, Viessmann Wärmepumpe, 1-Wire (Temperatur, Feuchte, Stromverbrauch), Husquarna-Automower, ...

ojb

Hallo Leute,

neuer Zwischenstand:

Mit oben beschriebener Vorgehensweise hat es 2 Tage und 34 Minuten funktioniert. Dann kam ein Abbruch und es ging nicht mehr weiter. Ein manueller Reopen reparierte alles wieder.

So etwas müsste doch am Besten das CUL Modul abfangen, oder?


2014.10.22 18:48:12 3: Timer_CUNO_Alive: cuno uptime => 2 00:34:37
2014.10.22 18:53:12 3: Timer_CUNO_Alive: cuno uptime => 2 00:39:37
2014.10.22 18:58:12 3: Timer_CUNO_Alive: cuno uptime => 2 00:44:37
2014.10.22 19:03:12 3: Timer_CUNO_Alive: cuno uptime => 2 00:49:37
2014.10.22 19:08:15 1: 192.168.178.56:2323 disconnected, waiting to reappear (cuno)
2014.10.22 19:08:15 3: Timer_CUNO_Alive: cuno uptime => No answer
2014.10.22 19:13:12 3: Timer_CUNO_Alive: cuno uptime => No answer
2014.10.22 19:18:12 3: Timer_CUNO_Alive: cuno uptime => No answer
2014.10.22 19:23:12 3: Timer_CUNO_Alive: cuno uptime => No answer
2014.10.22 19:28:12 3: Timer_CUNO_Alive: cuno uptime => No answer
2014.10.22 19:33:12 3: Timer_CUNO_Alive: cuno uptime => No answer
2014.10.22 19:36:28 1: 192.168.178.56:2323 reappeared (cuno)
2014.10.22 19:36:29 3: cuno: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq
2014.10.22 19:38:12 3: Timer_CUNO_Alive: cuno uptime => 2 01:24:38
2014.10.22 19:43:12 3: Timer_CUNO_Alive: cuno uptime => 2 01:29:38


Liebe Grüße
Oli
FHEM unter Debian auf Asus EEBox: KNX (Wetterstation, Rollläden, Beleuchtung), Maple-CUN (Temperatur und Feuchte über 1-Wire, Intertechno-Funksteckdosen), PV-Anlage mit Plenticore und BYD, Viessmann Wärmepumpe, 1-Wire (Temperatur, Feuchte, Stromverbrauch), Husquarna-Automower, ...

rudolfkoenig

Nach einem disconnect-Meldung versucht das CUL-Modul alle 5 Sekunden ein reconnect.

ojb

Das funktioniert aber bei mir scheinbar nicht. Wie in dem Log zu sehen ist gibt der CUNO fast eine halbe Stunde keine Antwort. Erst als ich um 19:36 manuell 'set cuno reopen' schicke, geht wieder alles.

Woran könnte das liegen? Was ist der Unterschied zwischen einem Reconnect und einem Reopen?
FHEM unter Debian auf Asus EEBox: KNX (Wetterstation, Rollläden, Beleuchtung), Maple-CUN (Temperatur und Feuchte über 1-Wire, Intertechno-Funksteckdosen), PV-Anlage mit Plenticore und BYD, Viessmann Wärmepumpe, 1-Wire (Temperatur, Feuchte, Stromverbrauch), Husquarna-Automower, ...

rudolfkoenig

reopen macht explizit zu und auf.
In diesem Zusammenhang ist fuer mich "aufmachen" und "reconnect" gleich, es wird versucht ein Netzwerkport via tcp/ip/connect zu erreichen.

ojb

Verstehe, aber warum funktioniert das dann bei mir nicht? Wie kann ich das herausfinden/debuggen?

Nachtrag 1:
Ich bin jetzt auf 'verbose 5' hoch gegangen. Hoffentlich kann man hier etwas herausfinden.

Nachtrag 2:
Fehler wieder aufgetreten mit 'verbose 5'.

So sieht es aus, wenn uptime geht:
2014.10.24 01:15:02 5: exec at command Timer_CUNO_Alive
2014.10.24 01:15:02 5: Cmd: >get cuno uptime<
2014.10.24 01:15:02 5: SW: t
2014.10.24 01:15:02 5: CUL/RAW (ReadAnswer): 000593C9
2014.10.24 01:15:02 3: Timer_CUNO_Alive: cuno uptime => 0 00:48:44
2014.10.24 01:15:02 5: redefine at command Timer_CUNO_Alive as +*00:05:00 get cuno uptime

und hier der Aussetzer:
2014.10.24 13:36:15 5: exec at command Timer_CUNO_Alive
2014.10.24 13:36:15 5: Cmd: >get cuno uptime<
2014.10.24 13:36:15 5: SW: t
2014.10.24 13:36:18 1: 192.168.178.56:2323 disconnected, waiting to reappear (cuno)
2014.10.24 13:36:18 5: Triggering cuno (1 changes)
2014.10.24 13:36:18 5: Notify loop for cuno DISCONNECTED
2014.10.24 13:36:18 4: eventTypes: CUL cuno DISCONNECTED -> DISCONNECTED
2014.10.24 13:36:18 3: Timer_CUNO_Alive: cuno uptime => No answer
2014.10.24 13:36:18 5: redefine at command Timer_CUNO_Alive as +*00:05:00 get cuno uptime

Seitdem kommen nur noch 'no answers':
2014.10.24 13:41:15 5: exec at command Timer_CUNO_Alive
2014.10.24 13:41:15 5: Cmd: >get cuno uptime<
2014.10.24 13:41:15 5: SW: t
2014.10.24 13:41:15 3: Timer_CUNO_Alive: cuno uptime => No answer
2014.10.24 13:41:15 5: redefine at command Timer_CUNO_Alive as +*00:05:00 get cuno uptime

Der CUNO lässt sich auf der Kommandozeile anpingen und ich kann auch per Telnet auf ihn zugreifen.

Das heisst doch, dass FHEM seine telnet-Verbindung nicht offen hat.

Sobald ich 'set cuno reopen' durchführe geht wieder alles.

Warum verbindet sich FHEM nicht automatisch mit dem CUNO? Wo genau in den Sourcen findet man denn den 'reconnect'. Ich habe zwar nur rudimentärste Perl-Kenntnisse, aber vielleicht finde ich ja was?

@rudolfkoenig:
Du hast geschrieben: "Nach einem disconnect-Meldung versucht das CUL-Modul alle 5 Sekunden ein reconnect."
Warum sieht man davon nichts im Log?

Ich habe jetzt einige weitere Versuche gemacht, wie z.B. den CUNO abstecken und auch an eine andere Netzwerkdose. Hierbei fiel auf, dass wenn ich den CUNO ab- und wieder anstecke, FHEM ihn nicht mehr findet.

Für mich sieht das so aus, als würde der reconnect-Versuch von FHEM nicht stattfinden.

Kann man als Workaround eigentlich einen notify auf das DISCONNECT machen? Wenn ja, wie?

Um jede Hilfe dankbar.

Oli
FHEM unter Debian auf Asus EEBox: KNX (Wetterstation, Rollläden, Beleuchtung), Maple-CUN (Temperatur und Feuchte über 1-Wire, Intertechno-Funksteckdosen), PV-Anlage mit Plenticore und BYD, Viessmann Wärmepumpe, 1-Wire (Temperatur, Feuchte, Stromverbrauch), Husquarna-Automower, ...