Verbindungsabbruch CUNO <=> FHEM

[tostmann]

                                                 

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

[rudolfkoenig]

                                                   

> 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

[Guest]

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

[Guest]

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

[rudolfkoenig]

                                                   

> 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

[Mitch]

                                                     

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

[rudolfkoenig]

                                                   

> 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

[Mitch]

                                                     

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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

[Guest]

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