HMLAN disconnected sporadisch

[Guest]

Originally posted by: <email address deleted>

Hallo,
ich wühle in fhem users und finde für meinen Fehler keine Erklärung. Also
frag ich mal los...
Meine Hardware: Fritzbox 7390 mit fhem 5.3, Homematic LAN Konfigurator,
eine HM-LC-SW1-FM zum Testen, CUL ist bestellt.

Die Einrichtung war soweit keine Schwierigkeit und durch die vielen
Anleitungen auch keine große Sache und jetzt kommt das ABER:
Ich bekomme disconnects alle 4 Stunden für 5 sec. und später dann ist die
Verbindung von der 7390 zum HMLAN ganz weg.
Ein Netz aus/ein hilft dann nur kann ich so kein system aufbauen was unter
den Augen der Weiblichkeit besteht.
Hier ein log:

2012.12.11 23:07:43 1: Including fhem.cfg

2012.12.11 23:07:44 3: telnetPort: port 7072 opened

2012.12.11 23:07:45 3: WEB: port 8083 opened

2012.12.11 23:07:45 3: WEBphone: port 8084 opened

2012.12.11 23:07:45 3: WEBtablet: port 8085 opened

2012.12.11 23:07:46 3: Opening Lankonf1 device 192.168.1.116:1000

2012.12.11 23:07:46 3: Lankonf1 device opened

2012.12.11 23:07:46 1: Including ./log/fhem.save

2012.12.11 23:07:47 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id:
fhem.pl 1996 2012-10-20 07:11:56Z rudolfkoenig $, pid 14269)

2012.12.11 23:08:11 1: HMLAN setting owner to 245202 from C7AF02

2012.12.12 00:53:41 1: 192.168.1.116:1000 disconnected, waiting to reappear

2012.12.12 00:53:46 1: 192.168.1.116:1000 reappeared (HMLAN1)

2012.12.12 04:52:25 1: 192.168.1.116:1000 disconnected, waiting to reappear

2012.12.12 04:52:31 1: 192.168.1.116:1000 reappeared (HMLAN1)

2012.12.12 08:51:33 1: 192.168.1.116:1000 disconnected, waiting to reappear

2012.12.12 08:51:38 1: 192.168.1.116:1000 reappeared (HMLAN1)

2012.12.12 12:50:41 1: 192.168.1.116:1000 disconnected, waiting to reappear

2012.12.12 12:50:46 1: 192.168.1.116:1000 reappeared (HMLAN1)

2012.12.12 16:49:48 1: 192.168.1.116:1000 disconnected, waiting to reappear

Diese Regelmäßigkeit ist schon auffällig.

Gruß

Matthias



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

[Guest]

Originally posted by: <email address deleted>

Hallo Matthias,

kannst mal einen Blick
in https://groups.google.com/forum/#!topic/fhem-users/y_rlL8POnlY werfen.
Dein Problem wurde dort durch UliM und dem HM-Martin analysiert. Die
Quintessenz ist, das durch Sleep-Befehle in mehreren FHEM Modulen der
Keep-Alive Timer für das HMLAN irgendwann statt nach 25 Sekunden erst nach
30 Sekunden geschickt werden und dadurch das HMLAN die Verbindung abbricht.

z.B. das Modul WOL führt einen Ping Befehl durch, wodurch das gesamte FHEM
Programm bis zur Rückmeldung wartet (ping -c1 dauert ca. 1 Sekunde) und
dadurch sämtliche at Befehle sich ebenfalls um 1 Sekunde verzögern. In dem
Modul Twilight soll es wohl auch irgendwas verzögerndes geben (sleep?).

Aber ich denke da kann Martin mehr zu sagen, da er das zusammen mit Uli
sehr intensiv untersucht hatte.

VIele Grüße

Markus  

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

[Guest]

Originally posted by: <email address deleted>

Hallo Markus,

ja das sieht leider nach genau dem Fehler aus.

Dank dir

Gruß

Matthias

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

[Guest]

Originally posted by: <email address deleted>

Hallo Matthias,

das Problem liegt in WOL. Twilight ist unschuldig.
Generell kann es noch weitere Module geben, die solche Vezögerungen
auslösen - auch eine kombination aus mehreren ist möglich. Aber
identifiziert ist bisher nur die eine.

Lösen kannst du es indem du im Modul 98_WOL.pm die Zeile
  if (`ping -c 1 $ip` =~ m/100/)
ersetzt gegen
  if (`ping -c 1 -w 1 $ip` =~ m/100/)

Einbauen möchte ich dies nicht, da ich das Modul WOL nicht verstehe. Dieses
"Ping" ist systemabhaengig und funktioniert nicht auf allen systemen.
Windows sollte ausscheiden und die Parameter funktionieren nicht bei allen
Unix/Linux distributionen.
Auf eine FB funktioniert es.

Den Wert -w 1 kannst du hoch setzen bis '-w 3'. Mehr solltest du nicht
riskieren.

Nachteil ist: es wird nicht mehr 10sec auf ein device gewartet - könnte
also zu Probleme führen, falls das device oder das Netzwert langsam ist -
im heimnetz eher unwarscheinlich.

Ausserdem: WOL sollte nicht funktionierne, falls euere IP die 100 enthält -
das ist ein Bug. z.B. 192.168.178.100

Übrigens - das Problem verschärft sich mit jedem Device, das ihr hier
eintragt. Es wird für jedes device ein eigener timer gestartet.

Gruss
Martin

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

[Zrrronggg!]

                                                     

Aeh... was macht WOL?

Also ich meine was ist der Sinn des Moduls?



On 13 Dez., 07:55, Martin wrote:
> Hallo Matthias,
>
> das Problem liegt in WOL. Twilight ist unschuldig.
> Generell kann es noch weitere Module geben, die solche Vezögerungen
> auslösen - auch eine kombination aus mehreren ist möglich. Aber
> identifiziert ist bisher nur die eine.
>
> Lösen kannst du es indem du im Modul 98_WOL.pm die Zeile
>   if (`ping -c 1 $ip` =~ m/100/)
> ersetzt gegen
>   if (`ping -c 1 -w 1 $ip` =~ m/100/)
>
> Einbauen möchte ich dies nicht, da ich das Modul WOL nicht verstehe. Dieses
> "Ping" ist systemabhaengig und funktioniert nicht auf allen systemen.
> Windows sollte ausscheiden und die Parameter funktionieren nicht bei allen
> Unix/Linux distributionen.
> Auf eine FB funktioniert es.
>
> Den Wert -w 1 kannst du hoch setzen bis '-w 3'. Mehr solltest du nicht
> riskieren.
>
> Nachteil ist: es wird nicht mehr 10sec auf ein device gewartet - könnte
> also zu Probleme führen, falls das device oder das Netzwert langsam ist -
> im heimnetz eher unwarscheinlich.
>
> Ausserdem: WOL sollte nicht funktionierne, falls euere IP die 100 enthält -
> das ist ein Bug. z.B. 192.168.178.100
>
> Übrigens - das Problem verschärft sich mit jedem Device, das ihr hier
> eintragt. Es wird für jedes device ein eigener timer gestartet.
>
> Gruss
> Martin

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

[Guest]

Originally posted by: <email address deleted>

Am Freitag, 14. Dezember 2012 00:18:30 UTC+1 schrieb Zrrronggg!:
>
> Aeh... was macht WOL?
>
> Also ich meine was ist der Sinn des Moduls?
>
>
> etwas magere Beschreibung - aber es ist ein WakeOnLan. Details kenne ich
nicht, ich benutze es auch nicht.  
Es prüft jedenfalls regelmaessig, ob das eingetragene device wach ist.
Probleme gibt es übrigens nur, wenn es schläft

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

[Guest]

Originally posted by: <email address deleted>

>
>
> Hallo Martin,
>
>
die Änderung im WOL- Modul auf w -1 hat erstmal keine Veränderung gebracht.
Ich werde jetzt mit -2 weiter testen und berichten.
Der inzwischen eingetroffene CUL läuft ohne Probleme.
Ich denke es werden noch 2 weitere CUL´s an die Fritzbox kommen und der LAN
Konfigurationsadapter landet bei ibähh.
 

> Gruß
>
> Matthias
>
>
> 2012.12.14 15:02:19 1: 192.168.1.116:1000 reappeared (HMLAN1)
> 2012.12.14 16:38:12 1: 192.168.1.116:1000 disconnected, waiting to reappear
> 2012.12.14 16:38:17 1: 192.168.1.116:1000 reappeared (HMLAN1)
> 2012.12.14 20:37:17 1: 192.168.1.116:1000 disconnected, waiting to reappear
> 2012.12.14 20:37:22 1: 192.168.1.116:1000 reappeared (HMLAN1)
> 2012.12.15 00:36:21 1: 192.168.1.116:1000 disconnected, waiting to reappear
> 2012.12.15 00:36:26 1: 192.168.1.116:1000 reappeared (HMLAN1)
> 2012.12.15 04:35:24 1: 192.168.1.116:1000 disconnected, waiting to reappear
> 2012.12.15 04:35:29 1: 192.168.1.116:1000 reappeared (HMLAN1)
> 2012.12.15 08:34:27 1: 192.168.1.116:1000 disconnected, waiting to reappear
> 2012.12.15 08:34:32 1: 192.168.1.116:1000 reappeared (HMLAN1)
>
>
>

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

[Guest]

Originally posted by: <email address deleted>

Hi,

ich habe im WOL-Modul den Test mit -2 gemacht und leider gibt es keinen
reconnect mehr:

2012.12.15 12:44:17 1: Including fhem.cfg
2012.12.15 12:44:18 3: telnetPort: port 7072 opened
2012.12.15 12:44:19 3: WEB: port 8083 opened
2012.12.15 12:44:19 3: WEBphone: port 8084 opened
2012.12.15 12:44:19 3: WEBtablet: port 8085 opened
2012.12.15 12:44:19 3: Opening HMLAN1 device 192.168.1.116:1000
2012.12.15 12:44:19 3: Can't connect to 192.168.1.116:1000: Connection refused
2012.12.15 12:44:20 3: Opening CUL_0 device /dev/ttyACM0
2012.12.15 12:44:21 3: Setting CUL_0 baudrate to 9600
2012.12.15 12:44:21 3: CUL_0 device opened
2012.12.15 12:44:21 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2012.12.15 12:44:21 3: No I/O device found for schalter1
2012.12.15 12:44:21 1: Including ./log/fhem.save
2012.12.15 12:44:22 1: usb create starting
2012.12.15 12:44:22 1: usb create end
2012.12.15 12:44:22 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 1996 2012-10-20 07:11:56Z rudolfkoenig $, pid 25942)
2012.12.15 13:07:46 0: Server shutdown
2012.12.15 13:07:49 1: Including fhem.cfg
2012.12.15 13:07:51 3: telnetPort: port 7072 opened
2012.12.15 13:07:51 3: WEB: port 8083 opened
2012.12.15 13:07:51 3: WEBphone: port 8084 opened
2012.12.15 13:07:51 3: WEBtablet: port 8085 opened
2012.12.15 13:07:52 3: Opening HMLAN1 device 192.168.1.116:1000
2012.12.15 13:07:52 3: Can't connect to 192.168.1.116:1000: Connection refused
2012.12.15 13:07:53 3: Opening CUL_0 device /dev/ttyACM0
2012.12.15 13:07:53 3: Setting CUL_0 baudrate to 9600
2012.12.15 13:07:53 3: CUL_0 device opened
2012.12.15 13:07:53 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2012.12.15 13:07:54 3: No I/O device found for schalter1
2012.12.15 13:07:54 1: Including ./log/fhem.save
2012.12.15 13:07:54 1: usb create starting
2012.12.15 13:07:54 1: usb create end
2012.12.15 13:07:54 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 1996 2012-10-20 07:11:56Z rudolfkoenig $, pid 26256)

Ich werde nochmal mit -3 testen...


Matthias


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

[Guest]

Originally posted by: <email address deleted>

@ Matthias, verwendest du denn auch das WOL Modul? Bei mir tritt der Fehler
auf auch ohne WOL Modul.

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

[Guest]

Originally posted by: <email address deleted>

Hi Markus,
ich verwende WOL nicht, habe aber jetzt seit gestern mit -3 den Effekt, dass nach dem Neustart von fhem der Adapter gleich geöffnet wird und bis heute morgen geöffnet blieb.
Es scheint also bei der Anbindung eines Hm Lan cfg Adapters an die Fritzbox 7390 notwendig den WOL auf -3 zu setzen. Sieht im Moment gut aus.
Ich werde weiter berichten.

Gruss

Matthias

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

[Guest]

Originally posted by: <email address deleted>

Hallo Matthias,

ich verwende WOL nicht, habe aber jetzt seit gestern mit -3 den Effekt,
> dass nach dem Neustart von fhem der Adapter gleich geöffnet wird und bis
> heute morgen geöffnet blieb.
> Es scheint also bei der Anbindung eines Hm Lan cfg Adapters an die
> Fritzbox 7390 notwendig den WOL auf -3 zu setzen. Sieht im Moment gut aus.
>
> verstehe ich nicht. das ist -3?  Die Zeit im WOL.pm für den Ping? Wenn du
WOL aber nicht verwendest und keinen Entity eingebunden hast sollte es
wirklich keinen effekt haben.
Falls es noch auftritt sollten wir den Fehler eingrenzen und dazu die Logs
ziehen - also die messages vom HMLAN - wie gewohnt
attr gloval verbose 1
attr gloval mseglog 1
attr loglevel 1

Gruss
Martin

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

[Guest]

Originally posted by: <email address deleted>

Hi,
  denke das sollte nicht

> attr gloval verbose 1
> attr gloval mseglog 1

sondern

attr global verbose 1
attr global mseclog 1

sein?!

lG
Martin



Am 17.12.2012 09:12, schrieb Martin:
> Hallo Matthias,
>
>     ich verwende WOL nicht, habe aber jetzt seit gestern mit -3 den
>     Effekt, dass nach dem Neustart von fhem der Adapter gleich
>     geöffnet wird und bis heute morgen geöffnet blieb.
>     Es scheint also bei der Anbindung eines Hm Lan cfg Adapters an die
>     Fritzbox 7390 notwendig den WOL auf -3 zu setzen. Sieht im Moment
>     gut aus.
>
> verstehe ich nicht. das ist -3?  Die Zeit im WOL.pm für den Ping? Wenn
> du WOL aber nicht verwendest und keinen Entity eingebunden hast sollte
> es wirklich keinen effekt haben.
> Falls es noch auftritt sollten wir den Fehler eingrenzen und dazu die
> Logs ziehen - also die messages vom HMLAN - wie gewohnt
> attr gloval verbose 1
> attr gloval mseglog 1
> attr loglevel 1
>
> Gruss
> Martin
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

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

[Guest]

Originally posted by: <email address deleted>

Hi,
ich hatte den Wert im Modul WOL auf -w 3 erhöht:

Generell kann es noch weitere Module geben, die solche Vezögerungen auslösen - auch eine kombination aus mehreren ist möglich. Aber identifiziert ist bisher nur die eine.

Lösen kannst du es indem du im Modul 98_WOL.pm die Zeile
  if (`ping -c 1 $ip` =~ m/100/)
ersetzt gegen
  if (`ping -c 1 -w 1 $ip` =~ m/100/)

Einbauen möchte ich dies nicht, da ich das Modul WOL nicht verstehe. Dieses "Ping" ist systemabhaengig und funktioniert nicht auf allen systemen. Windows sollte ausscheiden und die Parameter funktionieren nicht bei allen Unix/Linux distributionen.

und nun scheint die Verbindung dauerhaft zu sein.
Andere Veränderungen hatte ich noch nicht vorgenommen. Ich kann aber gerne mal loggen.

Gruß
Matthias

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

[Guest]

Originally posted by: <email address deleted>

Hi,

ich hatte den Wert im Modul WOL auf -w 3 erhöht:
>
ok - verstanden. Per default sind es 10 - also wenn kein Parameter
angegeben wird.
Gefuehlsmaesig sind 3sec ausreichend fuer einen ping-test in einem
Hausnetzwerk.
Fragen:
 - Hattest du Probleme. wenn du -w 1 angibst?
 - du hast gschrieben. dass du dies modul nicht 'in betrieb' hast. Wenn du
keinen entity aus 'WOL' definiert hast sollte das alles ohne Bedeutung
sein. Stimmt dies so?

>
> und nun scheint die Verbindung dauerhaft zu sein.
> Andere Veränderungen hatte ich noch nicht vorgenommen. Ich kann aber gerne
> mal loggen.
>

Wenn alles funktioniert ist loggen der Messages nicht notwendig.  Um das
timerverhalten zu pruefen sind andere Logs notwendig

Gruss
Martin

>
>

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

[Guest]

Originally posted by: <email address deleted>

Hi Martin,

leider muss ich das mit dem kein disconnect mehr zurück nehmen:

2012.12.17 08:23:19 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.17 08:23:24 1: 192.168.1.116:1000 reappeared (HMLAN1)
2012.12.17 12:22:22 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.17 12:22:27 1: 192.168.1.116:1000 reappeared (HMLAN1)
2012.12.17 16:21:26 1: 192.168.1.116:1000 disconnected, waiting to reappear
2012.12.17 16:21:31 1: 192.168.1.116:1000 reappeared (HMLAN1)

Also ist klar - ohne WOL Nutzung bringt auch Veränderung der pingwaittime nichts.
Ich hatte mit -w 1 die gleichen disconnects.
Die regelmäßigen Abstände machen mich stutzig. Alle 4 h für 5 sec..

Ich werde also mal loggen, um zu sehen was wirklich passiert.

Gruß

Matthias

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