57_Calendar - mal wieder Probleme beim Abruf der Kalenderdaten

[cornelius fillmore]

Darf man hier noch was mitteilen, oder kommt man dann unter die emotionalen Räder?

Also bei mir ist es auch so, das ich an die Daten der Google Kalender nicht mehr rankomme.
"Could not retrive..."
Dies von zwei Raspi mit aktuellen Fhem
Egal ob http oder https

Wobei andere ics Dateien z.B. Ferienkalender gehen uneingeschränkt

[rudolfkoenig]

Das bedeutet für mich, dass die Zeile
    my $len = sysread($hash->{conn},$buf,65536);
aus welchen Gründen auch immer, keine Rückgabe liefert.

Sehe ich auch so, allerdings der select() direkt davor sagt, dass Daten zur Verfuegung stehen.
Koenntest Du bitte testweise:
  $hash->{conn} = IO::Socket::INET->new(Proto=>'tcp', Blocking=>0);
durch
  $hash->{conn} = IO::Socket::INET->new(Proto=>'tcp', Blocking=>1);
ersetzen? Waere fuer mich immer noch nicht logisch, aber vielleicht koennen wir damit einen workaround bauen.

Deshalb hatte ich bereits zweimal nach weiteren möglichen/denkbaren Ursachen gefragt,
die vielleicht irgendwo in der Abhängigkeitenkette zu suchen wären?

Mir faellt nichts ein, bzw. kenne fuer alles in der folgenden Liste ein "aber". Aber vlt. inspiriert das jemanden:
- router/etc wirft Pakete weg
- Debian/Kernel-Version ist buggy
- Irgendwer stoert fhem per Signalen (SIGHUP/etc).
Allerdings ist HttpUtils _AUCH_ fehlerhaft, wenn die alte Version funktioniert, und die Neue nicht.

Mich nervt vielmehr die überhebliche Art von Rudi

Ich habe mich in dieser Diskussion schon viermal zurueckgehalten, und auf deine Provokationen nicht reagiert. Einmal ist das mir durchgerutscht, wo du scheinbar meinen Vorschlag ignoriert hast, und habe danach festgestellt, dass nicht alle, die provozieren, auch einstecken koennen.
Zu meinem "unspezifisch": wenn ich schon irgendetwas konstenfrei zur Verfuegung stelle und supporte (d.h. Zeit investiere), dann erwarte ich von der anderen Seite auch eine nicht unerhebliche Mitwirkung bei der Problemloesung, es ist ja nicht mein Problem. Es geht nicht um wissen/koennen/etc, sondern zeigen, dass man den Anderen nicht als einen Diener wahrnimmt, und man gemeinsam die Loesung sucht.
Wenn in einem Fall, wo jemand sich wirklich bemueht hat, ich ueberheblich sein sollte, dann moechte ich mich hiermit entschuldigen.

[justme1968]

ich habe bei einem device bemerkt das ich genau eine solche leere antwort bekomme wenn ich das shutdown auf das socket mache bevor ich select aufrufe. ich vermute das es irgend eine timing geschichte ist.

wenn ich den code richtig interpretiere passiert das in den HttpUtils normalerweise auch. das sollte sich schnell mit setzen von $hash->{noshutdown} testen lassen.

gruss
  andre

[betateilchen]

Den von Dir vorgeschlagenen Test werde ich heute abend machen und Dir hier Rückmeldung geben.

wenn ich schon irgendetwas konstenfrei zur Verfuegung stelle und supporte (d.h. Zeit investiere),

Alle Entwickler investieren hier ihre (Frei-)Zeit und supporten die bereitgestellten Module (kostenfrei), da bist Du nicht der einzige. Und alle tun das freiwillig.

dann erwarte ich von der anderen Seite auch eine nicht unerhebliche Mitwirkung bei der Problemloesung, es ist ja nicht mein Problem.

Doch, es ist "Dein" Problem, denn Du hast die  HttpUtils geändert, und das ist ein zentrales Modul, von dem andere Module (auch von anderen Entwicklern) abhängen. Du betonst immer, dass fhem ein "offenes System" sei, an dem sich viele Leute beteiligen können und das auch tun. Dann muss man aber auch darauf bauen können, dass solche zentralen Dinge wie z.B. die HttpUtils funktionieren. Und mangelnde Mitwirkung bei Problemlösungen und Fehlersuchen sollte man mir hier eigentlich nicht vorwerfen können. Immerhin war ich schon soweit vorgedrungen, bei der Fehlersuche sowohl Google selbst als auch das Calendar-Modul ausschließen zu können.

Hauptberuflich bin ich 10-12 Stunden pro Tag u.a. damit beschäftigt, Softwarefehler in von anderen Leuten erstellter Software zu suchen (und im Notfall, z.B. Produktionsstillstand auch ad-hoc zu beheben). Erste Regel dabei ist IMMER: "versuche, den gemeldeten Fehler nachzustellen" und diese Regel führt in den allermeisten Fällen auch zum Erfolg. Aber von Dir höre ich in den allermeisten Fällen nur immer "ich will das nicht nachbauen, ich will das nicht einrichten, ich will das nicht testen" Und genau DAS ist der Punkt, den ich mit "überheblich" meine. Ich schätze Deine Arbeit und Dein Engagement für fhem uneingeschränkt. Aber in der Frage "Wie gehe ich mit Supportanfragen um, damit dem Fragesteller wirklich geholfen wird?" werden wir wohl nie einer Meinung werden.

Und nicht jede von Deiner Meinung abweichende andere Meinung sollte für Dich zwangsläufig eine Provokation darstellen.

In diesem Sinne, lass uns einfach gemeinsam an der Weiterentwicklung von fhem arbeiten.

[betateilchen]

Koenntest Du bitte testweise:
  $hash->{conn} = IO::Socket::INET->new(Proto=>'tcp', Blocking=>0);
durch
  $hash->{conn} = IO::Socket::INET->new(Proto=>'tcp', Blocking=>1);
ersetzen?

Hab ich getestet, hat aber (wie eigentlich aus der Modullogik zu erwarten) nichts gebracht.

wenn ich den code richtig interpretiere passiert das in den HttpUtils normalerweise auch. das sollte sich schnell mit setzen von $hash->{noshutdown} testen lassen.

Jepp. Das war wohl der entscheidende Hinweis.  Ich habe jetzt im Kalendermodul den Abruf in Zeile 832 wie folgt geändert:

Code Auswählen Erweitern

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

Damit funktioniert der Kalenderabruf jetzt auch auf dem Beaglebone und dem RaspberryPi wieder fehlerfrei.

Scheint also letztendlich auch ein hardwareabhängiges Thema zu sein, was meine Vermutung bezüglich außerhalb fhem denkbarer Ursachen bestätigt und mich maßlos beruhigt.

Nun müßte man nur noch

1. entweder das Ganze irgendwie parametrierbar machen (vielleicht als globales Attribut, da es installationsabhängig ist, damit aber die gesamte fhem-Installation betrifft)
2. oder das shutdown in HttpUtils einfach komplett weglassen
3. oder HttpUtils dazu bringen, im Falle eines darauf beruhenden Fehlers irgendwie (korrigierend) zu reagieren

Variante 1 halte ich persönlich für die sinnvollste.
Variante 2 wäre die simpelste
Variante 3 steht da nur der Vollständigkeit halber *g*


Ich hoffe, diese Testergebnisse helfen irgendwie weiter.

[Dr. Boris Neubert]

Ich hätte da übrigens gleich noch einen kleinen Patch unterzubringen, um eine unschöne Konsolenmeldung zu unterdrücken, falls $keep größer ist als die tatsächlich gefundene Anzahl Kalendereinträge.

Kommt am Wochenende dran, wenn ich wach bin 
BN

[Dr. Boris Neubert]

Ich hätte da übrigens gleich noch einen kleinen Patch unterzubringen, um eine unschöne Konsolenmeldung zu unterdrücken, falls $keep größer ist als die tatsächlich gefundene Anzahl Kalendereinträge.

Kommt am Wochenende dran, wenn ich wach bin
BN

[betateilchen]

hm...

[rudolfkoenig]

- per default wird nach dem die Daten uebertragen wurden, die Schreibseite der TCP Verbindung zugemacht. Das noshutdown Flag verhindert das -> Es sollte je nach Server einen Unterschied machen, ob man den Flag setzt oder nicht, aber nicht je nach Client.
- ich habe gerade getestet, und ich sehe keinen Unterschied bezueglich noshutdown zwischen der alten und der neuen Version.
- wenn man das shutdown weglaesst, dann funktioniert HttpUtils mit manchen Webservern (z.Bsp. FHEM selbst) nicht. Ich habe das gefixed, siehe Anhang. Waere nett, wenn jemand es testet, bevor ich es einchecke.
- gegen ein globales Attribut wehre ich mich (noch): erstens will ich diese Attribute ausrotten, nicht vermehren, zweitens wuerde es das FHEM-Client komplett betreffen, und ich behaupte immer noch, dass das Flag Serverabhaengig ist.

Bevor ich was aendere, wuerde ich gerne die Ursache besser verstehen, vielleicht kann mich jemand erhellen.

[rudolfkoenig]

@betateilchen: kann es sein, dass die beiden "Problemkinder" hinter einem Proxy sitzen, der mit solchen TCP/IP Semantiken wie Schreibseite einseitig schliessen Probleme hat? Erklaert aber immer noch nicht, wieso die alte Version funktioniert.

[LaLeLu]

Also leider kann ich nicht viel helfen,
aber ich habe Rudolfs geänderte Version von httputils.pm eingespielt, restart und leider weiterhin folgende Fehlermeldung:


2014.01.29 00:52:51.270 1: Calendar FHEMKalender: Could not retrieve file at URL
Nach dem Umzug von der FritzBox auf einen Raspberry funktioniert es bei mir nicht mehr.

[betateilchen]

@betateilchen: kann es sein, dass die beiden "Problemkinder" hinter einem Proxy sitzen, der mit solchen TCP/IP Semantiken wie Schreibseite einseitig schliessen Probleme hat?

Nein, kein Proxy.

[rudolfkoenig]

@LaLeLu: Das hier angehaengte HttpUtils.pm behebt ein Problem z.Bsp. mit FHEM als Server, falls shutdown per Aufruf-Parameter abgeschaltet wird. Besteht das Problem bei dir, fallst du die Zeile mit shutdown auskommentierst?

[betateilchen]

@betateilchen: kann es sein, dass die beiden "Problemkinder" hinter einem Proxy sitzen,

Nochmal kurz zur Proxy-Frage: Interessanterweise war bei mir genau das System, das hinter einem (Firmen-)Proxy sitzt (Debian in VMware) das einzige System, das von dem Problem NICHT betroffen war.

[LaLeLu]

Hallo Rudolf,


ich hoffe, es richtig gemacht zu haben. In httputils.pm habe ich Zeile 187 auskommentiert:



185  syswrite $hash->{conn}, $hdr;
186  syswrite $hash->{conn}, $hash->{data} if(defined($hash->{data}));
187  #  shutdown $hash->{conn}, 1 if(!$hash->{noshutdown});


Nach Restart von fhem habe ich leider immer noch den Fehler:
2014.01.29 19:41:42.652 1: Calendar FHEMKalender: Could not retrieve file at URL