AT Ausführung Minuten zu spät

[arweic]

Hallo zusammen

ich betreibe seit eingen Wochen FHEM mit einem Raspberry 3
und bin noch ein ziemlicher Neuling im FHEM und kein Unix-Experte.
FHEM funktioniert soweit gut.

Allerdings tritt nun folgendes Problem auf:
Mit
#define nShuttersUp at *07:30:00 set sShuttersAll Auf
will ich meine Rolläden um 7:30 Uhr öffnen.
Nun wird dieser Befehl aber nur an manchen Tagen pünktlich, also um 7:30 Uhr, ausgeführt,
an anderen wird er teilweise um Minuten verzögert ausgeführt.
Im Logfile steht dannwenn alles pünkltich erledigt wird
#2017-12-17_07:30:00 aShuttersAll Auf
und wenn der Befehl zu spät ausgeführt wird z.B.
#2017-12-18_07:33:44 aShuttersAll Auf
Tatsächlich war die Ausführung am 18.12. um diese Uhrzeit kurz vor 7:34.
Ähnliches gilt auch für andere AT Befehle, z.B. auch das Runterfahren am Abend mit sunset().

Uptime liefert für die CPU Belastung 0,0, Top listet FHEM entweder unter ferner liefen oder mit wenigen Prozent.
An einer zu hohen Auslastung des Raspberry kann es also nicht liegen. Auch die Uhrzeit des Raspberry stimmt, sonst würde ja das Log nicht die tatsächliche Uhrzeit loggen.

Woran kann es liegen, dass die Befehle mal pünktlich, mal erst Minuten später ausgeführt werden?
Diese Verzögerung variiert übrigens und geht teilweise über 5 Minuten.

Danke für eure Antworten
Armin

[Beta-User]

Bist du sicher, dass nichts fhem blockiert?
Apptime, perfmon...

[Thorsten Pferdekaemper]

Hi,
vermutlich blockiert da irgendwas. Das muss ja nicht bedeuten, dass die CPU belastet wird. Wenn Dein System z.B. auf's Netzwerk wartet, dann siehst Du das nicht unbedingt in Top. Da FHEM aber single-threaded ist geht es trotzdem erstmal nicht weiter.
Hast Du sonst noch Sachen (vor Allem in FHEM), die (ungefähr) um 07:30 laufen (sollen)?
Gruß,
   Thorsten

[arweic]

Danke für die schnelle Antwort.

Ich glaube, ich bin jetzt ein Stück weiter.
Es liegt vermutlich an der I2C-Schnittstelle.
Ich habe einen SHT3x eingebunden über das Modul I2C_SHT3x, das alle 10 Minuten den Sensor pollt.
Es verwendet den i2cbus1, der über RPII2C angebunden ist.
Im Log fand ich die Fehlermeldung:
#2017.12.18 07:23:44 3: i2cbus1: HWaccess blockweise von 0x44 lesen, -> sysread failure: Remote I/O error
Als dann die nächste Abfrage um 7:33:44 Uhr kam, die ohne Fehler durchlief,
arbeitete FHEM plötzlich wieder korrekt.
D.h. dieser Aufruf, bzw. diese Modul muss wohl einen Teil von FHEM blockiert haben.
(Die Werteaufnahme eines Funksensors wurde in der Zwischenzeit problemlos bearbeitet.)
Leider ist die Abfrage des Sensors öfter fehlerbehaftet. Warum weiß ich nicht. (Leitungen sind überprüft,
zu ca. 20% funktioniert die Abfrage nicht, zu 80% schon ...)

Daraus resultiert natürlich gleich die nächste Frage: Gibt es eine Möglichkeit, den Fehler abzufangen und das I2C_SHT3x Modul zu beenden, so dass FHEM wieder regulär weiter machen kann oder muss ich auf dieses Modul verzichten?

Danke schon mal
Armin

[Beta-User]

U.a. deswegen nutze ich keine pi-gpio. Sowas dürfen arduinos tun...

[Thorsten Pferdekaemper]

Daraus resultiert natürlich gleich die nächste Frage: Gibt es eine Möglichkeit, den Fehler abzufangen und das I2C_SHT3x Modul zu beenden, so dass FHEM wieder regulär weiter machen kann oder muss ich auf dieses Modul verzichten?

Hi,
also entweder siehe Antwort von Beta-User oder Du fragst mal im entsprechenden Forenbereich nach. Im Prinzip sollen die FHEM-Module im Fehlerfall nicht blockieren, aber oft konzentriert man sich beim Entwickeln eher auf die "schönen" Sachen.
Gruß,
   Thorsten

[arweic]

Alles klar. Dann danke ich nochmals für eure schnelle Antwort.