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

[Virsacer]

Hm, das ist schon doof

Ich hatte grad nach nem reboot folgendes im Log:

Code Auswählen Erweitern

2015.06.11 10:55:26 2: Switched CUL rfmode to HomeMatic
2015.06.11 10:55:55 1: Calendar Calendar_Example: Could not retrieve file at URL. <hidden>: Can't connect(1) to https://www.example.com:443: IO::Socket::INET: connect: timeout
2015.06.11 10:55:58 3: Opening Phone device 192.168.1.1:1012

Ne halbe Minute, in der nix passiert

Kann man das Modul nicht so korrigieren, dass das Laden asynchron läuft?

[Markus M.]

Kann man das Modul nicht so korrigieren, dass das Laden asynchron läuft?

Probier mal das hier.

[Virsacer]

Hey, danke

Scheint zu funktionieren:

Code Auswählen Erweitern

2015.06.13 20:05:44 0: Server started with 84 defined entities (version $Id: fhem.pl 8690 2015-06-04 16:47:20Z rudolfkoenig $, os linux, user fhem, pid 490)
2015.06.13 20:05:44 1: Calendar_Example: URL error: connect to https://www.example.com:443 timed out
2015.06.13 20:05:44 1: Calendar_Google: URL error: connect to https://www.google.com:443 timed out

[kvo1]

Hallo Zusammen,
ich habe folgendes Problem:

ich hole mir aus 3 Kalendern (ownloud) per

Code Auswählen Erweitern

ical url http://USER:PASSWORT@SERVER/owncloud/remote.php/caldav/calendars/ocadmin/KALENDERNAME?export 3600

die Daten und stelle diese (über CALVIEW) mittels readingsGroup dar.
Jetzt habe ich das Problem, das immer wieder mal ältere Termine noch angezeigt werden. Nach einiger Suche hat sich
herausgestellt, das es bereits beim "Modul Calendar" klemmt.

Code Auswählen Erweitern

get <Kalendername> full all

bringt bereits  noch ältere Einträge mit ! Nach einem manuellen

Code Auswählen Erweitern

set <Kalendername> reload

sind die alten Termin weg !

kvo1

[reibuehl]

Probier mal das hier.

Wenn ich die Version verwende, stürzt Fhem beim anlegen eines ICS Kallenders ab. Wenn ich das Kommando

Code Auswählen Erweitern

define Abfall Calendar ical file Muellkalender.ics

eingebe, stürzt Fhem mit der Meldung

Code Auswählen Erweitern

Can't call method "updateFromCalendar" on an undefined value at ./FHEM/57_Calendar.pm line 1024.

ab. Das ICS File liegt in /opt/fhem und ist für fhem lesbar. Mit der 57_Calender.pm Version aus Fhem tritt dieser Fehler nicht auf.

[Markus M.]

Wenn ich die Version verwende, stürzt Fhem beim anlegen eines ICS Kallenders ab. Wenn ich das Kommando

Code Auswählen Erweitern

define Abfall Calendar ical file Muellkalender.ics
eingebe, stürzt Fhem mit der Meldung

Code Auswählen Erweitern

Can't call method "updateFromCalendar" on an undefined value at ./FHEM/57_Calendar.pm line 1024.
ab. Das ICS File liegt in /opt/fhem und ist für fhem lesbar. Mit der 57_Calender.pm Version aus Fhem tritt dieser Fehler nicht auf.

Ich kann dir meine Version leider nicht schicken da ich das Modul aktuell ziemlich verändert habe, aber probier mal diese Zeile einzufügen:

sub Calendar_ParseUpdate($$$) {

  my ($param, $errmsg, $data) = @_;
  my $hash = $param->{hash};
  my $name = $hash->{NAME};
  my $removeall = $param->{removeall};
  $removeall = false if(!defined($removeall));
  my $ics = $data;

Ungetestet und aus dem Bauch heraus...
Wenn es klappt, das funktionierende Modul wieder hier hochladen und dann kann das vielleicht auch mal jemand ins SVN einchecken.

Gruss, Markus

[reibuehl]

Mit der eingefügten Zeile stürzt Fhem zwar nicht mehr ab, ich bekomme aber als Rückgabe auf das define in Fhem die Meldung "Cannot load module Calendar".

[Markus M.]

Das hier sollte den Absturz beheben.
Aus unerfindlichen Gründen verschwindet ein interner Hash - sollte sich mal ein Perl-Experte ansehen.
Ob das so funktioniert kann ich nicht sagen, ich nutze keine lokalen Files.

[kvo1]

Das hier sollte den Absturz beheben.
Aus unerfindlichen Gründen verschwindet ein interner Hash - sollte sich mal ein Perl-Experte ansehen.
Ob das so funktioniert kann ich nicht sagen, ich nutze keine lokalen Files.

Hallo Markus,
Ich halte es für sinnvoll, derartige Anpassungen mit Boris abzustimmen, ich meine er betreut das Modul!

Danke und Gruß
Klaus

[AitschPi]

Schaut Euch doch alternativ mal das angehängte Skript an...

Genau so etwas wollte ich schon selber schreiben. Also hab ich mir das angeschaut und gleich so wie es ist eingebunden. Danke!

[dominik]

Hi,
ich habe noch immer das Problem, dass das Calendar Modul meine ganze FHEM Instanz blockiert. Wäre hier nicht die beste Lösung das über einen Blocking Call innerhalb des Calendar Moduls zu beheben? http://www.fhemwiki.de/wiki/Blocking_Call

Was meint ihr? Möchte gerne eine vernünftige Lösung dafür finden und keine Workarounds.

Gruß
dominik

[Dr. Boris Neubert]

Hallo,

ich habe die Erweiterung von Markus M. in die aktuelle Modulversion integriert uns ins SVN eingecheckt.

Viele Grüße
Boris

[AitschPi]

Danke. Das Update wartet dann jetzt darauf... ;o)


Gesendet von iPhone mit Tapatalk - Tippfehler sind gratis.

[kvo1]

Hallo,

ich habe die Erweiterung von Markus M. in die aktuelle Modulversion integriert uns ins SVN eingecheckt.

Viele Grüße
Boris

Hallo Boris,
hatte heute ein Update Deines Moduls gemacht und mir hat es beide Systeme blockiert 
Habe wieder auf #8986 zurück gedreht.

Das erst System startete garnicht mehr...
Can't call method "updateFromCalendar" on an undefined value at ./FHEM/57_Calendar.pm line 1026.


Beim zweiten System waren die Kalender (state) nicht aktiv.

gruss klaus

[AitschPi]

Bei mir kommt auch der gleiche Fehler, der fhem komplett blockiert:

Code Auswählen Erweitern

Can't call method "updateFromCalendar" on an undefined value at ./FHEM/57_Calendar.pm line 1026.
Abhilfe schaffte die vorherige Version vom 09.08.2015, 10:01:32 (sourceforge), download hier:

Code Auswählen Erweitern

http://sourceforge.net/p/fhem/code/9039/tree/trunk/fhem/FHEM/57_Calendar.pm?format=raw

[Dr. Boris Neubert]

die Version von gestern behebt das - bitte nachher  update aufrufen.
Boris

[Franz Tenbrock]

Hallo
komme auch nicht mehr an mein System, kann also auch kein update mehr machen
Post 20
http://forum.fhem.de/index.php?topic=39353.msg320993#msg320993

mit welchem Befehl über Putty kann ich trotzdem ein update machen?

[marvin78]

Spiele doch einfach das alte Calendar-Modul wieder ein (restore Verzeichnis) und starte FHEM.

[Franz Tenbrock]

das war doch mal ein vorschlag, in der Zwischnezeit hab ich aus rausgefunden wie das geht
und auch gemacht
die fhem.cfg hab ich mir wohl bei dem mist zerschossen.
teste jetzt erst mal mit der fhem.demo.cfg
die startet zumindestens schon mal

Das wichtigste vom System läuft wieder

calendar scheint nach updae gerade ok zu sein..

[AitschPi]

Hallo
komme auch nicht mehr an mein System, kann also auch kein update mehr machen
...
mit welchem Befehl über Putty kann ich trotzdem ein update machen?

Warum so kompliziert?! Wenn es nur an einem Modul hakt, das vorher ging, dann das einfach aus der History von sourceforge nehmen und überschreiben. Sauber und einfach. Also putty anwerfen, wget, Rechte und Besitzer ändern und dann defektes überschreiben. Hier konkret schon mal beschrieben:

...
Abhilfe schaffte die vorherige Version vom 09.08.2015, 10:01:32 (sourceforge), download hier:

Code Auswählen Erweitern

http://sourceforge.net/p/fhem/code/9039/tree/trunk/fhem/FHEM/57_Calendar.pm?format=raw

Dann passiert auch nix mit der cfg. ;o)

[kvo1]

hab die neue Version geladen, System stürzt auch nicht mehr ab , aber im calview habe ich keine Anzeige mehr. Im Fhem.log gibt es folgende Meldungen......


2015.08.10 18:09:52 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/57_CALVIEW.pm line 93.
2015.08.10 18:09:52 1: PERL WARNING: Use of uninitialized value $M in concatenation (.) or string at ./FHEM/57_CALVIEW.pm line 94.
2015.08.10 18:09:52 1: PERL WARNING: Use of uninitialized value $D in concatenation (.) or string at ./FHEM/57_CALVIEW.pm line 94.
2015.08.10 18:09:52 1: PERL WARNING: Use of uninitialized value $Y in concatenation (.) or string at ./FHEM/57_CALVIEW.pm line 94.
2015.08.10 18:09:52 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/57_CALVIEW.pm line 94.
2015.08.10 18:09:52 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at ./FHEM/57_CALVIEW.pm line 111.
2015.08.10 18:09:52 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/57_CALVIEW.pm line 127.
2015.08.10 18:09:52 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/57_CALVIEW.pm line 137.

Es scheit also ein Problem der aktualisierung (per at) zu sein !? das schaut so aus ..

Code Auswählen Erweitern

define at_KalenderTermine at +*02:00 {\
  my $i;;\
  my $modtext = "<Datum>,<Uhrzeit>,<Text>,<Kalender> ";;\
  for($i= 1;;$i<=20;;$i++){\
  $modtext .= "vocalview2:t_".sprintf('%03d',$i)."_bdate,t_".sprintf('%03d',$i)."_btime,t_".sprintf('%03d',$i)."_summary,t_".sprintf('%03d',$i)."_source "               ;;}\
  fhem("modify Termine2 $modtext");;\
}


also alle 2 Stunden wird die readingsgroup aktualisiert !

[2ktrouble]

Mann, echt super das ich diesen Eintrag gefunden habe.
Ich war schon am Verzweifeln, weil ich meinen vermeintlichen Fehler nicht gefunden habe.

Gruß Ingo

[Invers]

Ich habe ebenfalls diese Fehlermeldungen.

[chris1284]

http://forum.fhem.de/index.php/topic,29622.30/topicseen.html
da haben wir die meldungen zu calview erörtert

[Dr. Boris Neubert]

Hallo,

es gibt eine neue Version im alpha-Test. Lies bitte hier:

http://forum.fhem.de/index.php/topic,46609.0.html

Diese Version lädt Kalender nicht blockierend von einer URL.

Viele Grüße
Boris