HMLAN - Lan-Interface startet dauernd neu

Begonnen von Guest, 27 November 2012, 21:18:48

Vorheriges Thema - Nächstes Thema

UliM

                                                 

Hi,
bisher keine neuen dosconnect/reapperaed -Meldungen von HMLAN :)

Anbei die verwendete Version von Twilight.pm mit Korrekturen des
http-Aufrufs und bulkupdate.

=8-)

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

UliM

                                                 

Am Dienstag, 4. Dezember 2012 00:23:34 UTC+1 schrieb UliM:
>
> bisher keine neuen dosconnect/reapperaed -Meldungen von HMLAN :)
>
>
Wohl zu früh gefreut :(

2012.12.04 01:46:51.194 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 01:46:56.281 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 01:55:33.743 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 01:57:01.221 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 01:57:06.308 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 02:07:11.256 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 02:07:16.339 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 02:10:33.745 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 02:25:33.814 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 02:27:31.306 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 02:27:36.393 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 02:40:33.743 2: FS20 set hzg_HeizungFreigabeBrenner
off-for-timer 1920
2012.12.04 02:47:51.380 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 02:47:56.459 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 02:55:33.736 2: FS20 set hzg_HeizungFreigabeBrenner
off-for-timer 1920
2012.12.04 02:58:01.414 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 02:58:06.498 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 03:08:11.429 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 03:08:16.513 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 03:10:33.741 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 03:18:21.460 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 03:18:26.556 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 03:25:33.798 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 03:28:31.495 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 03:28:36.579 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 03:38:41.534 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 03:38:46.618 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 03:40:33.736 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 03:55:33.734 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 03:59:01.585 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 03:59:06.672 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 04:10:33.739 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 04:19:21.682 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 04:19:26.766 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 04:25:33.820 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 04:29:31.764 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 04:29:36.844 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 04:40:33.733 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 04:49:51.770 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 04:49:56.853 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 04:55:33.742 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 05:00:01.797 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 05:00:06.880 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 05:10:33.751 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 05:20:21.859 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 05:20:26.942 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 05:25:33.800 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 05:40:41.928 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 05:40:47.024 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 05:40:47.131 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 05:50:51.967 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 05:50:57.047 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 05:55:33.731 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 06:01:02.006 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 06:01:07.090 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 06:10:33.748 2: FS20 set hzg_HeizungFreigabeBrenner on
2012.12.04 06:11:12.033 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 06:11:17.120 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 06:21:22.068 1: 192.168.2.111:1000 disconnected, waiting to
reappear
2012.12.04 06:21:27.151 1: 192.168.2.111:1000 reappeared (HMLAN)
2012.12.04 06:25:33.809 2: FS20 set hzg_HeizungFreigabeBrenner on

 Hmmmmm...
Der gute Teil der Nachricht: Es beliben kosntant 5s, scheinbar kein
Aufschaukeln auf >1 Minute mehr.
=8-)

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

Guest

Originally posted by: <email address deleted>

Da ich im aktuellen SVN im Twilight kein Problem finde was da auslösen
könnte, so denke ich zumindest:

könnst du das Twilight mal ganz rausnehmen und schauen ob es noch auftritt
???

Danke und VG

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

UliM

                                                 

Hi,
werde heute Abend das disabled-Attribut reinbauen - sonst laufen mir zu viele abhängige notifies& Progrämmchen auf Poller.
Gruß, Uli

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

UliM

                                                 

... Bzw: kannst Du mir bitte sagen, an welcher Stelle das ziehen muss,
damit auch die Timer nicht starten.
Gruß Uli

Am Dienstag, 4. Dezember 2012 schrieb UliM :

> Hi,
> werde heute Abend das disabled-Attribut reinbauen - sonst laufen mir zu
> viele abhängige notifies& Progrämmchen auf Poller.
> Gruß, Uli
>
> --
> 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
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

Guest

Originally posted by: <email address deleted>

Hi,

ich bin noch einmal alle timer durchgegangen, die ich gesehen habe.

es laeuft einer mit 3 min. wenn der drankommt wird der keepalive nach
hinter versetzt. Ich weiss noch nicht, wer den 3min timer betreibt.
Vermutung ist, dass etwas im sortiermechanismus des timerhandling den 3min
timer vorzieht.
fakt ist, wenn "3min" um 00:33:00 enden soll und keepalive um 00:28:00 dann
kommt erst "3min" um 00:33:00 und danach der keepalive - also auch um
00:33:00. das sind dann 5 sec zu spaet.

Twilight habe ich also zu unrecht verdaechting - sorry.

anbei ein fhem.pl mit mehr logs zum timer. Hier sollte zu sehen sein, wir
fhem seine timer sortiert.

Gruss
Martin



Am Dienstag, 4. Dezember 2012 07:54:11 UTC+1 schrieb UliM:
>
> Hi,
> werde heute Abend das disabled-Attribut reinbauen - sonst laufen mir zu
> viele abhängige notifies& Progrämmchen auf Poller.
> Gruß, Uli

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

Guest

Originally posted by: <email address deleted>

nochn update.
ich denke ich habe den Fehler. ist nicht das sortieren sondern das
dispatchen der timer-routine.

Die Datei im Anhang hat immer noch die Logs - und hoffentlich auch einen
fix.

Gruss
Martin

Am Dienstag, 4. Dezember 2012 10:55:07 UTC+1 schrieb Martin:
>
> Hi,
>
> ich bin noch einmal alle timer durchgegangen, die ich gesehen habe.
>
> es laeuft einer mit 3 min. wenn der drankommt wird der keepalive nach
> hinter versetzt. Ich weiss noch nicht, wer den 3min timer betreibt.
> Vermutung ist, dass etwas im sortiermechanismus des timerhandling den 3min
> timer vorzieht.
> fakt ist, wenn "3min" um 00:33:00 enden soll und keepalive um 00:28:00
> dann kommt erst "3min" um 00:33:00 und danach der keepalive - also auch um
> 00:33:00. das sind dann 5 sec zu spaet.
>
> Twilight habe ich also zu unrecht verdaechting - sorry.
>
> anbei ein fhem.pl mit mehr logs zum timer. Hier sollte zu sehen sein, wir
> fhem seine timer sortiert.
>
> Gruss
> Martin
>
>
>
> Am Dienstag, 4. Dezember 2012 07:54:11 UTC+1 schrieb UliM:
>>
>> Hi,
>> werde heute Abend das disabled-Attribut reinbauen - sonst laufen mir zu
>> viele abhängige notifies& Progrämmchen auf Poller.
>> Gruß, Uli
>
>

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

Guest

Originally posted by: <email address deleted>

habe noch einmal nachgesehen - sieht vielversprechend aus. Die
Timer-routine liefert keinen Rueckgabewert wenn eine funktion abgearbeitet
wurde. damit wird, wenn ein timer 'ausgetimed' ist immer 5 sec gewartet
(bei nicht MSDOS32!)

Somit kann ein timer um bis zu 5 sec spaeter kommen (plus verzoegerungen
durch andere Prozesse). Und damit kommt der HMLAN keepAlive in den
kritischen Bereich von 30sec. Es kann zu Ausfaellen kommen oder auch nicht,
je nach device.

Der Fehler ist nicht auf HMLAN oder HM beschraenkt. Timern koennen also um
0+5 schwanken....
das letzte files fhem.pl sollte es beheben.

Gruss
Martin

Am Dienstag, 4. Dezember 2012 11:35:41 UTC+1 schrieb Martin:
>
> nochn update.
> ich denke ich habe den Fehler. ist nicht das sortieren sondern das
> dispatchen der timer-routine.
>
> Die Datei im Anhang hat immer noch die Logs - und hoffentlich auch einen
> fix.
>
> Gruss
> Martin
>
> Am Dienstag, 4. Dezember 2012 10:55:07 UTC+1 schrieb Martin:
>>
>> Hi,
>>
>> ich bin noch einmal alle timer durchgegangen, die ich gesehen habe.
>>
>> es laeuft einer mit 3 min. wenn der drankommt wird der keepalive nach
>> hinter versetzt. Ich weiss noch nicht, wer den 3min timer betreibt.
>> Vermutung ist, dass etwas im sortiermechanismus des timerhandling den
>> 3min timer vorzieht.
>> fakt ist, wenn "3min" um 00:33:00 enden soll und keepalive um 00:28:00
>> dann kommt erst "3min" um 00:33:00 und danach der keepalive - also auch um
>> 00:33:00. das sind dann 5 sec zu spaet.
>>
>> Twilight habe ich also zu unrecht verdaechting - sorry.
>>
>> anbei ein fhem.pl mit mehr logs zum timer. Hier sollte zu sehen sein,
>> wir fhem seine timer sortiert.
>>
>> Gruss
>> Martin
>>
>>
>>
>> Am Dienstag, 4. Dezember 2012 07:54:11 UTC+1 schrieb UliM:
>>>
>>> Hi,
>>> werde heute Abend das disabled-Attribut reinbauen - sonst laufen mir zu
>>> viele abhängige notifies& Progrämmchen auf Poller.
>>> Gruß, Uli
>>
>>

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

Guest

Originally posted by: <email address deleted>

ok kein Problem. Es gibt sicher unabhängig davon Optimierungspotential im
Timer-Modul. Insbesondere die ständige Wetterabfrage. Ich habe es halt vor
allem nach meinen Bedürfnissen entwickelt um es dann anderen auch zur
Verfügung zu stellen.

VG

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

Guest

Originally posted by: <email address deleted>

Hallo unimatrix,

ah - das Timing modul ist von dir? Ist nur eine kleine Aenderung, dann
sollte es passen.
Das einzige, was dann nicht 100% funktionieren kann ist warten kleiner
5sec. Da liegt die Wartezeit irgenwo
'waitReq' < waitexecute <5sec
+ delays natuerlich
(ausser bei Windows)

muss man wissen, wenn man es benutzt.

Gruss
Martin

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

Guest

Originally posted by: <email address deleted>

sorry, ich habe mich verschrieben - ich meinte das Twilight-Modul....da
hatte ich zu viel "Timer" im Kopf.

VG

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

UliM

                                                 

Am 4. Dezember 2012 12:22 schrieb Martin :

> Der Fehler ist nicht auf HMLAN oder HM beschraenkt. Timern koennen also um
> 0+5 schwanken....
> das letzte files fhem.pl sollte es beheben.
>

Hab's jetzt reinkopiert, melde mich mit Log-Ergebnissen sobald/sofern
disconnect/reappear auftritt.
=8-)

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

UliM

                                                 

Hi,
Log anbei, 12x disconnect/reappered..
Gruß, Uli
PS: Habe auf die SVN-fhem.pl zurückgestellt, 1,1MB log in 2 Stunden sind
dann doch viel ;-)

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
RPi4/Raspbian, CUL V3 (ca. 30 HomeMatic-devices), LAN (HarmonyHub, alexa etc.).  Fördermitglied des FHEM e.V.

Guest

Originally posted by: <email address deleted>

ja, das waren viele traces - war auch nicht zum dauerbetrieb gedacht -
sorry.
Hat aber gezeigt, dass die Annahme des Fehlers korrekt ist - wenigstens das.

anbei ein besserer fix und weniger traces

Gruss
Martin

Am Dienstag, 4. Dezember 2012 21:37:07 UTC+1 schrieb UliM:
>
> Hi,
> Log anbei, 12x disconnect/reappered..
> Gruß, Uli
> PS: Habe auf die SVN-fhem.pl zurückgestellt, 1,1MB log in 2 Stunden sind
> dann doch viel ;-)
>
>

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

Guest

Originally posted by: <email address deleted>

sorry - war die falsche datei, bitte die korrigierte nehmen - ist langsam
spät...


>

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