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.
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 :D
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 :)
Zitat von: SirUli am 26 November 2014, 11:40:55
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.
Da hast du recht - hatte ich dankbarerweise erstmal so gemacht - alle 24h aktualisierung, dann kratzt es mich net ganz so.
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
ich hab's auch über wget gelöst. Sooo aktuell muss der Kalender in FHEM ja nicht sein.
Zitat von: Doggiebert am 26 November 2014, 16:02:10
ich hab's auch über wget gelöst.
Was war dein Hintergrund? Weil es blockiert?
jo, hat blockiert.
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
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.
Dito. Keine Chance, ohne alte Termine zu löschen oder das iCal nach dem Download zu filtern.
Von unterwegs gesendet.
@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
@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:
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
@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
Zitat von: PatrickR am 09 Juni 2015, 20:09:23
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
@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
Hm, das ist schon doof :-\
Ich hatte grad nach nem reboot folgendes im Log:
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 :o
Kann man das Modul nicht so korrigieren, dass das Laden asynchron läuft?
Zitat von: Virsacer am 11 Juni 2015, 11:26:44
Kann man das Modul nicht so korrigieren, dass das Laden asynchron läuft?
Probier mal das hier.
Hey, danke :D
Scheint zu funktionieren:
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
Hallo Zusammen,
ich habe folgendes Problem:
ich hole mir aus 3 Kalendern (ownloud) per
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.
get <Kalendername> full all
bringt bereits noch ältere Einträge mit ! Nach einem manuellen
set <Kalendername> reload
sind die alten Termin weg !
kvo1
Zitat von: Markus M. am 13 Juni 2015, 02:17:45
Probier mal das hier.
Wenn ich die Version verwende, stürzt Fhem beim anlegen eines ICS Kallenders ab. Wenn ich das Kommando
define Abfall Calendar ical file Muellkalender.icseingebe, stürzt Fhem mit der Meldung
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.
Zitat von: Reiner am 26 Juli 2015, 22:49:37
Wenn ich die Version verwende, stürzt Fhem beim anlegen eines ICS Kallenders ab. Wenn ich das Kommando
define Abfall Calendar ical file Muellkalender.ics
eingebe, stürzt Fhem mit der Meldung
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:
Zitatsub 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
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".
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.
Zitat von: Markus M. am 28 Juli 2015, 00:43:38
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
Zitat von: PatrickR am 09 Juni 2015, 20:09:23
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!
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
Hallo,
ich habe die Erweiterung von Markus M. in die aktuelle Modulversion integriert uns ins SVN eingecheckt.
Viele Grüße
Boris
Danke. Das Update wartet dann jetzt darauf... ;o)
Gesendet von iPhone mit Tapatalk - Tippfehler sind gratis.
Zitat von: Dr. Boris Neubert am 08 August 2015, 08:54:48
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
Bei mir kommt auch der gleiche Fehler, der fhem komplett blockiert:
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:
http://sourceforge.net/p/fhem/code/9039/tree/trunk/fhem/FHEM/57_Calendar.pm?format=raw
die Version von gestern behebt das - bitte nachher update aufrufen.
Boris
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?
Spiele doch einfach das alte Calendar-Modul wieder ein (restore Verzeichnis) und starte FHEM.
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..
:P
Zitat von: Franz Tenbrock am 10 August 2015, 13:34:27
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:
Zitat von: AitschPi am 10 August 2015, 01:33:51
...
Abhilfe schaffte die vorherige Version vom 09.08.2015, 10:01:32 (sourceforge), download hier:
http://sourceforge.net/p/fhem/code/9039/tree/trunk/fhem/FHEM/57_Calendar.pm?format=raw
Dann passiert auch nix mit der cfg. ;o)
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 ..
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 !
Mann, echt super das ich diesen Eintrag gefunden habe.
Ich war schon am Verzweifeln, weil ich meinen vermeintlichen Fehler nicht gefunden habe.
Gruß Ingo
Ich habe ebenfalls diese Fehlermeldungen.
http://forum.fhem.de/index.php/topic,29622.30/topicseen.html
da haben wir die meldungen zu calview erörtert
Hallo,
es gibt eine neue Version im alpha-Test. Lies bitte hier:
http://forum.fhem.de/index.php/topic,46609.0.html (http://forum.fhem.de/index.php/topic,46609.0.html)
Diese Version lädt Kalender nicht blockierend von einer URL.
Viele Grüße
Boris