57_Calendar - mal wieder Probleme beim Abruf der Kalenderdaten

[betateilchen]

Seit kurzem müllen mir die definierten Kalender wieder mal das Logfile zu - Ursache bisher unbekannt, eine Fehlermeldung taucht nicht auf. Aber irgendwie scheinen keine Kalenderdaten von Google geliefert zu werden.

Wieso geht Calendar eigentlich immer in eine Endlosschleife, sobald der Kalenderabruf mal nicht funktioniert? Ich fände es logischer, wenn der angegebene Abrufzeitraum immer eingehalten würde.

Eventuell könnte man auch darüber nachdenken, das Attribut disable zu unterstützen, um den Kalender manuell vorübergehend stilllegen zu können.

EDIT - EDIT - EDIT - EDIT - EDIT - EDIT - EDIT - EDIT - EDIT - EDIT

Ursache für das Problem sind einmal mehr die fhem-internen HttpUtils!

Ich habe die Datenbeschaffung in 57_Calendar jetzt ab Zeile 825 wie folgt geändert:

Code Auswählen Erweitern


  if($type eq "url"){
#    $ics= GetFileFromURLQuiet($url) if($type eq "url");
require LWP::UserAgent;
my $ua = LWP::UserAgent->new;
$ua->timeout(10);
$ics = $ua->get($url);
$ics = $ics->decoded_content if ($ics->is_success);
  } elsif($type eq "file") {


und alle Kalender funktionieren wieder wie sie sollen.

[schka17]

Hallo Betateilchen,

Habe zwei google calender konfigutriert und beide funktionieren ohne fehlermeldung, also wohl kein generelles Problem.

Gruss

Karl

[betateilchen]

Wie gesagt - eine Fehlermeldung habe ich auch nicht. Aber eine Endlosschleife im Sekundentakt beim Abruf, weil keine Daten gefunden werden.

Die Kalender-URL selbst läßt sich im Browser aber aufrufen.

(http://up.picr.de/17086635ah.jpg)

[betateilchen]

Code Auswählen Erweitern

2014.01.18 16:17:23 1: Calendar k2: Could not retrieve file at URL

Entweder in FHEM wurde mal wieder irgendwas an den HttpUtils geschraubt oder Google hat irgendwas geändert.
Interessanterweise bleibt der state des Kalenders auf "Initialized" stehen und zeigt die Fehlermeldung nicht an.

(http://up.picr.de/17087820xv.jpg)

[betateilchen]

Ursache für das Problem sind einmal mehr die fhem-internen HttpUtils!

Ich habe die Datenbeschaffung in 57_Calendar jetzt ab Zeile 825 wie folgt geändert:

Code Auswählen Erweitern


  if($type eq "url"){
#    $ics= GetFileFromURLQuiet($url) if($type eq "url");
require LWP::UserAgent;
my $ua = LWP::UserAgent->new;
$ua->timeout(10);
$ics = $ua->get($url);
$ics = $ics->decoded_content if ($ics->is_success);
  } elsif($type eq "file") {


und alle Kalender funktionieren wieder wie sie sollen.

[betateilchen]

Ich wünsche mir ein Attribut in 57_Calendar, mit dem ich zwischen der Nutzung von HttpUtils und UA für die Datenbeschaffung umschalten kann. Es ist nicht das erste Mal, dass die Kalender wegen irgendwelchen Krämpfen in den HttpUtils nicht mehr funktionieren.

[Dr. Boris Neubert]

Hallo,

bei mir funktioniert es. Habe gerade die allerneusten Dateien aus dem SVN ausgecheckt und kann auf meinen Kalender mit http:// und https:// zugreifen.

Wie kamst Du denn darauf, daß die HttpUtils schuld sind? Hast Du mal die Antworten angesehen? Bei mir kommt (mit http://) so was:

Code Auswählen Erweitern

2014.01.19 19:59:37 5: Cmd: >define C Calendar ical url http://www.google.com/calendar/ical/.../basic.ics<
2014.01.19 19:59:37 5: Loading /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/57_Calendar.pm
Smartmatch is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/57_Calendar.pm line 366, <$fh> line 11.
Smartmatch is experimental at /users/neubert/Development/Perl/fhem-code/trunk/fhem/FHEM/57_Calendar.pm line 542, <$fh> line 11.
2014.01.19 19:59:37 4: Calendar C: Wakeup
2014.01.19 19:59:37 4: Calendar C: Updating...
2014.01.19 19:59:37 4: HttpUtils url=<hidden>
2014.01.19 19:59:37 4: <hidden>: HTTP response code 301
2014.01.19 19:59:37 4: HttpUtils <hidden>: Redirect to <hidden>
2014.01.19 19:59:37 4: HttpUtils url=<hidden>
2014.01.19 19:59:37 4: <hidden>: HTTP response code 200
2014.01.19 19:59:37 4: HttpUtils <hidden>: Got data, length: 15768
2014.01.19 19:59:37 5: Next time of ... is: start 25.01.2014 13:00:00, end 25.01.2014 14:00:00
2014.01.19 19:59:37 5: Next time of .. is: start 02.11.2013 13:00:00, end 02.11.2013 13:30:00
...
2014.01.19 19:59:37 4: Calendar C: Checking times...


Viele Grüße
Boris

[betateilchen]

Wie kamst Du denn darauf, daß die HttpUtils schuld sind? Hast Du mal die Antworten angesehen?

Ich kam da drauf, weil ich gestern fast zwei Stunden debugged habe und letztendlich feststellen musste, dass das GetFileFromURLQuiet() einfach NICHTS zurücklieferte. Ich habe dann weiter in den HttpUtils debugged und konnte den Fehler bis zur Socket-Kommunikation zurückverfolgen.

Nachdem ich auf UA gewechselt hatte, war plötzlich alles wieder in Ordnung.

Wieder zurück auf HttpUtils -> Nix.

[Dr. Boris Neubert]

Hallo,

ich kann nicht sagen, warum GetFileFromURLQuiet() nichts zurückliefert. Allerdings reagiert der Code in 57_Calendar jetzt anders auf Fehler:

1. Sowohl wenn GetFileFromURLQuiet() undef als auch "" zurückliefert, ist das ein Fehlerzustand (Meldung auf Loglevel 1).
2. Es wird auf jeden Fall erst nach dem festgelegten Intervall wieder versucht, den Kalender zu lesen, unabhängig vom Fehlerzustand.
3. Im Fehlerfall ist der STATE "No data", sonst "Active".

Ab sofort im SVN, morgen im Update.

Grüße
Boris

[Dr. Boris Neubert]

Ich kam da drauf, weil ich gestern fast zwei Stunden debugged habe und letztendlich feststellen musste, dass das GetFileFromURLQuiet() einfach NICHTS zurücklieferte. Ich habe dann weiter in den HttpUtils debugged und konnte den Fehler bis zur Socket-Kommunikation zurückverfolgen.

Nachfrage: was meldet denn das Log zu dem, was in HttpUtils_BlockingGet() oder darin passiert?

Grüße
Boris

[betateilchen]

Ich kam da drauf, weil ich gestern fast zwei Stunden debugged habe und letztendlich feststellen musste, dass das GetFileFromURLQuiet() einfach NICHTS zurücklieferte. Ich habe dann weiter in den HttpUtils debugged und konnte den Fehler bis zur Socket-Kommunikation zurückverfolgen.

Nachdem ich auf UA gewechselt hatte, war plötzlich alles wieder in Ordnung.

Wieder zurück auf HttpUtils -> Nix.

Hallo Boris,

ich habe heute aus  lauter Langeweile Dein Update eingespielt - das funktioniert bei mir auch nicht. Ich bekomme damit keine Daten von Google. Dann habe ich den Abruf der Daten in Deiner neuen Modulversion wieder auf LWP::UA umgestellt und alles funktioniert wie gewünscht.

Im Logfile bekomme ich bei Verwendung von 57_Calender mit den HttpUtills die Fehlermeldung

Code Auswählen Erweitern

2014.01.25 19:49:11 1: Calendar Kalender_Schalter: Could not retrieve file at URL

und zwar bei ALLEN Kalender. Mit LWP::UA funktionieren ALLE Kalender problemlos.

Viele Grüße
Udo

[Dr. Boris Neubert]

Im Logfile bekomme ich bei Verwendung von 57_Calender mit den HttpUtills die Fehlermeldung

Code Auswählen Erweitern

2014.01.25 19:49:11 1: Calendar Kalender_Schalter: Could not retrieve file at URL

Kannst Du mal bitte in Zeile 832 in 57_Calendar.pm die folgenden Argumente beim GetFileFromURLQuiet() ergänzen und dann posten, was im Log von HttpUtils berichtet wird?

Code Auswählen Erweitern


    $ics= GetFileFromURLQuiet($url,10,undef,0,1) if($type eq "url");


Danke.
Boris

[betateilchen]

Code Auswählen Erweitern


2014.01.26 12:37:06 1: HttpUtils url=<hidden>
2014.01.26 12:37:06 1: CustomGetFileFromURL <hidden>: empty answer received
2014.01.26 12:37:06 1: Calendar Kalender_Heizung: Could not retrieve file at URL


[betateilchen]

Hallo Boris,

hier noch ein vielleicht wichtiger Nachtrag:

Code Auswählen Erweitern

# $Id: HttpUtils.pm 4497 2013-12-29 09:37:08Z rudolfkoenig $

damit funktioniert der Kalender auch mit den HttpUtils. Ich habe allerdings jetzt nicht alle dazwischenliegenden Versionen der HttpUtils getestet. Allerdings sehe ich damit meine Feststellung bestätigt, dass die Ursache für die Probleme definitiv in den HttpUtils liegt.

Und das erhärtet auch meinen Wunsch, die Benutzung von LWP::UA in 57_Calendar per Attribut aktivieren zu können, falls mal wieder jemand an den HttpUtils rumschraubt und damit Module lahmlegt, die davon abhängig sind...

Das Kalendermodul ist neben dem RSS für mich das zweitwichtigste Modul in fhem überhaupt - da muss ich mich einfach drauf verlassen können.

Viele Grüße
Udo

Edit: Ab dieser Version funktioniert es nicht mehr:

Code Auswählen Erweitern

# $Id: HttpUtils.pm 4514 2013-12-31 08:09:40Z rudolfkoenig $

[rudolfkoenig]

Unabhaengig davon, ob Calendar umgestellt wird oder nicht, wuerde ich gerne das Problem in HttpUtils fixen, und waere dankbar fuer etwas, was ich reproduzieren kann.