Modul Calendar blockiert FHEM

[SirUli]

Hi zusammen,

ich habe die letzten Tage versucht herauszufinden weshalb ab und an Wartesituationen auf meinem FHEM (auf Raspberry PI Model B) entstehen. Als Übeltäter hat sich neben SYSMON auch Calendar herausgestellt. Via apptime hat sich gezeigt, dass der Kalender, welcher von mir und meiner Holden benutzt wird (Google Calendar / aktuell 294kb groß  / Download via VDSL50), wohl zu recht langen Ausführungszeiten neigt.

Via "attr...*verbose 5" konnte ich auch nachweisen, dass das Modul genau zu der zeit (wenn FHEM hängt) die Daten abruft.

Code Auswählen Erweitern

                                name             function    max  count    total  average maxDly
                 tmr-Calendar_Wakeup      HASH(0x13f0e18)  59531      1    59531 59531.00      5 HASH(GA_CalWohnung)

Kann es sein, dass das Modul standardmäßig mit "blocking" die Daten abruft? (Edit: Kann ich mir selber beantworten: Ja). Wenn ja, gibt es ein Setting, das in non-blocking umzusetzen, was ich übersehen habe? Ansonsten würde ich den Download mal abkoppeln (cronjob mit wget) und das lokal einlesen lassen - der WAF leidet momentan ein wenig, wenn die Schalter nicht immer reagieren

Vielen Dank im Voraus!

Viele Grüße,
Uli
PS: Praktisch wäre übrigens, wenn man das Modul mit attr .... disable 1 kurzfristig ausschalten könnte

[betateilchen]

PS: Praktisch wäre übrigens, wenn man das Modul mit attr .... disable 1 kurzfristig ausschalten könnte

Stimmt. Aber testweise kannst Du auch einfach das Aktualisierungsinterval auf 1000000 setzen.

[SirUli]

Da hast du recht - hatte ich dankbarerweise erstmal so gemacht - alle 24h aktualisierung, dann kratzt es mich net ganz so.

[tuxbox]

Hi,

ich habe mir bei Zugriffen nach "außen" teils so auf die schnelle beholfen, dass ich z.B. über einen Cronjob
im System die externen Inhalte regelmäßig geholte habe und dann in FHEM auf die lokalen Kopien zugegriffen
habe.
Wobei Du die lokale ical Datei als Beispiel dann nicht direkt überschreiben solltest, sondern erst in eine
temporäre Datei und dann damit die bisherige ersetzen (der move/rename ist atomar; so kann ein Auslesen
einer erst halb geschriebenen Datei vermieden werden).

Gruß,
tuxbox

[Doggiebert]

ich hab's auch über wget gelöst. Sooo aktuell muss der Kalender in FHEM ja nicht sein.

[SirUli]

ich hab's auch über wget gelöst.

Was war dein Hintergrund? Weil es blockiert?

[Doggiebert]

jo, hat blockiert.

[eldrik]

Hi,

ich habe trotz manuellen holens meiner Kalender via wget (ca. 400 - 500kb ics Files) bei der Aktualisierung des Kalender Gerätes dieselben Verarbeitungszeiten resultierend in Timouts von bis zu 19 Sekunden als wenn ich den Kalender direkt per url Definition vom Modul holen lasse.

Beim Fhem Host handelt es sich um eine ESX VM basierend auf Debian mit 2x 2Ghz CPU und 4GB Ram, daher sollte eigentlich genug Computing Power vorhanden sein, besteht die Hoffnung, dass das Modul noch auf nonblocking umgestellt wird oder eine Möglichkeit, die Verarbeitung meiner Kalender zu beschleunigen?

Greetz
Eldrik

[SirUli]

Hi Eldrik das sieht bei mir genauso aus - ich habe das nun so gelegt dass das Modul explizit um 04 Uhr morgens aktualisiert. Ist leider nicht optimal aber das war zumindest ein Workaround.

[PatrickR]

Dito. Keine Chance, ohne alte Termine zu löschen oder das iCal nach dem Download zu filtern.


Von unterwegs gesendet.

[eldrik]

@SirUli

meine Alternative wird wohl darauf hinauslaufen, auf dem selben Host eine weitere FHEM Instanz hochzuziehen, (bereits erfolgt) welche meine sämtlichen Kalenderdefinitionen (bereits erfolgt) und notifys Events und sonstige Abhängigkeiten (to be done) etc. erhält und diese per fhem2fhem,an die Hauptinstanz, in clonedummy Geräte, überträgt.

Ich habe derzeit Aktualisierungsfrequenzen von 3  und 3 1/2 Stunden, für die Kalendar, welche eigentlich noch erhöht werden sollen, um kurzfristige Eintragsänderungen (z.B. aktivieren/deaktivieren des Tageszugangscodes, der Alarmanlage, für die Haushaltshilfe) auch zeitnah einfließen lassen zu können.

Greetz
Eldrik

[PatrickR]

@SirUli, eldrik:
Schaut Euch doch alternativ mal das angehängte Skript an. Das läd die ics-Datei herunter und filtert sie an Hand des Datums. Alle Termine, die mehr als 7 Tage in der Vergangenheit liegen, werden herausgefiltert. Einfach einen Cronjob anlegen und die Datei dann in FHEM als lokale Datei einbinden.

Die Konfiguration passiert in Konstanten im Skript selbst:

Code Auswählen Erweitern


use constant BACKLOG_DAYS => 7;
use constant SYSLOG_LEVEL => LOG_INFO;
use constant CACHE_PATH => '/opt/fhem/pr/cache';
use constant SOURCES => (
{
'url' => 'https://www.google.com/calendar/ical/xxxxx.ics',
'local_name' => 'xxxxx.ics',
}
);


Die Konstanten CACHE_PATH und SOURCES (mehrere Quellen sind möglich) müssen in jedem Fall angepasst werden.

Patrick

[eldrik]

@PatrickR
danke für das Skript evtl. adaptier und test ich es in Kürze einmal, ob sich hierdurch meine Verarbeitungszeiten reduzieren lassen, auf den ersten Blick gibt es nämlich keine Authentifizierung für den Download oder?

Ich habe meine Kalender und darauf aufbauenden Kalenderevents, Dummys für Urlaub, Feiertage etc. nun in eine zweite Fhem Instanz ausgelagert und hole mir die notwendigen Events per fhem2fhem, reagiere so über lokale notifys, auf die Events der neuen Fhem Instanz und bilde z.B. das CALVIEW Device für meine Readingsgroup via cloneDummy ab.

Ergebnis keine Verzögerungen mehr in der Hauptinstanz, die irgendwelche Timing kritischen Events überlagern könnten

Greetz
Eldrik

[SirUli]

Alle Termine, die mehr als 7 Tage in der Vergangenheit liegen, werden herausgefiltert.

Vielen Dank erstmal! Hört sich sinnvoll an, ich habe da momentan eh einen Anzeigefehler, wo mir immer aus dem Februar ein Event als erstes angezeigt wird. Schaue ich mir mal an, das dürfte die Datei stark verkleinern.

Viele Grüße, Uli

[PatrickR]

@eldrik
Jup. Authentication habe ich nicht drin. Lässt sich aber nachrüsten, habe allerdings leider aktuell einen monströsen Rückstau an Projekten :/.

@SirUli
Bei mir ist die Verarbeitungszeit in FHEM von 4200ms auf 30ms gefallen. Das ist ganz ok . Die 7 Tage kannst Du übrigens anpassen.

Patrick