Merkwürdig Schaltverzögerungen bei notify

[Guest]

Originally posted by: <email address deleted>

Manchmal, vor allem morgens, reagiert mein Rolladen erst mit einer
Verzögerung von variabel 3-10s auf den Funkschaltbefehl.
Der 2. Befehl (z.B. zum Stoppen) wird sofort ausgeführt, so als ob FHEM
erst mal "aufwachen" mußte.

Ich schalte meine Rolladen mit einem 4-fach FS20 Schalter bei dem alle
Tasten auf toggle eingestellt sind, der Rolladen wird von einem FS20 RSU
gesteuert.
FHEM läuft auf einem Intel Atom Server, die Konfiguration ist ziemlich
groß, es hängt ein CUL, ein CUL_HM und ein CUL_RFR dran.

fhem.cfg
define n25 notify Bad_2:toggle set RollBad on
define n26 notify Bad_4:toggle set RollBad off
IODev ist das mit USB direkt angeschlossene CUL
 
Ich habe versucht das Problem zu debuggen. Im fhem.log sind nur solche
Paare zu finden:
2012.08.26 22:42:09 2: FS20 Bad_2 toggle
2012.08.26 22:42:09 2: FS20 set RollBad on
2012.08.26 22:42:15 2: FS20 Bad_2 toggle
2012.08.26 22:42:15 2: FS20 set RollBad on
d.h. der Trigger und der Befehl werden laut log gleichzeitig ausgeführt.

Ich habe mich nun mit dem Sender vor die Konsole gesetzt und das Log mit
tail -f fhem.log angezeigt.
Dabei kam es vor, das der Logeintrag mit deutlicher Verzögerung geschrieben
wurde. Und dann auch verzögert geschaltet wurde.

Weiter bin ich noch nicht gekommen, mit verbose 5 sind keine
Auffälligkeiten zu erkennen, allerdings versagt da auch die tail -f
Methode, da das Log dann "durchrauscht".

Irgendwelche Ideen, wie ich das noch weiter debuggen kann?
Oder ist das Problem evtl. sogar bekannt?

Danke

Peter

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

[rudolfkoenig]

                                                   

> Irgendwelche Ideen, wie ich das noch weiter debuggen kann?

Mit attr global verbose 5 (und msecloc) muesste man genauer sehen, an welcher
Stelle der Klemmer ist.

> Oder ist das Problem evtl. sogar bekannt?

Mir nicht.

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

[Guest]

Originally posted by: <email address deleted>

Wie oben geschrieben hatte ich verbose 5 schon ausprobiert und nichts
auffälliges gefunden. Der Befehl wird empfangen, alle notifys durchgenudelt
(sind viele bei mir) und dann der Rolladen geschaltet. Laut log alles in
der selben Sekunde.
Von mseclog hatte ich mir nichts versprochen, da ich ja 5-10 Sekunden
suche....
Zugegeben ist die Suche schwierig, weil es nicht immer zu den Verzögerungen
kommt und garantiert nicht, wenn man drauf wartet ...
Allerdings geht mein Verdacht in eine andere Richtung:
- Könnte das Filelog oder der mysql Zugriff FHEM blockieren, wenn z.B. die
Festplatte im sleep ist oder ähnliches?
Wie kann man das debuggen? Filelog und mysql Zugriffe habe ich nicht im Log
(auch bei verbose 5) gefunden.
- Ein 2. Verdacht:
2012.08.27 08:50:10 2: FS20 Kueche_4 toggle
2012.08.27 08:50:11 2: FS20 set RollKue off
2012.08.27 08:50:21 2: FS20 HZ_S2 on
2012.08.27 08:50:21 2: FS20 Kueche_4 toggle
2012.08.27 08:50:21 2: FS20 set RollKue off
2012.08.27 08:50:21 2: FS20 Kueche_4 toggle
2012.08.27 08:50:21 2: FS20 set RollKue off
2012.08.27 08:50:28 2: FS20 HZ_S2 on
2012.08.27 08:50:28 2: FS20 Kueche_4 toggle
2012.08.27 08:50:28 2: FS20 set RollKue off
Hier ist zwischen dem 1. Kuche_4 toggle und dem 2. 10 sec. Pause.
Tatsächlich habe ich beide Befehle aber mit kurzem Abstand gesendet.
Wie ist denn der Empfangspuffer (insbesondere bei mehreren CULs) verwaltet?
In welchem Modul steht das und besteht da evtl. die Möglichkeit eines
"Schluckaufs"?

Übrigens habe ich das Problem schon sehr lange und wollte es immer mal
angehen, wenn ich Zeit habe oder es (meine Frau) zu sehr nervt.
Eines von beiden ist nun passiert ...

Am Montag, 27. August 2012 07:55:47 UTC+2 schrieb Rudolf Koenig:
>
> > Irgendwelche Ideen, wie ich das noch weiter debuggen kann?
>
> Mit attr global verbose 5 (und msecloc) muesste man genauer sehen, an
> welcher
> Stelle der Klemmer ist.
>
> > Oder ist das Problem evtl. sogar bekannt?
>
> Mir nicht.
>

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

[rudolfkoenig]

                                                   

> - Könnte das Filelog oder der mysql Zugriff FHEM blockieren, wenn z.B. die
> Festplatte im sleep ist oder ähnliches?

FileLog ruft $fh->sync auf, was die Festplatte aufwecken sollte, jedenfalls mit
den default Linux-Kernel-Parameter.  Mysql sollte sowas aehnliches auch tun.


> In welchem Modul steht das

00_CUL.pm bzw. fhem.pl mit dem select()


> ...und besteht da evtl. die Möglichkeit eines "Schluckaufs"?

Komplett Bugfrei waere ein Wunder, aber mir ist bisher nichts in diesem
Zusammenhang bekannt.

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