Verbindungsabbruch CUNO <=> FHEM

[Guest]

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

[Guest]

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

[Guest]

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

[rudolfkoenig]

                                                   

> 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

[Guest]

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

[Guest]

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

[locodriver]

                                                         

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

[locodriver]

                                                         

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

[Guest]

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