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:
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.
Hallo Betateilchen,
Habe zwei google calender konfigutriert und beide funktionieren ohne fehlermeldung, also wohl kein generelles Problem.
Gruss
Karl
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)
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)
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:
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.
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.
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:
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
Zitat von: Dr. Boris Neubert am 19 Januar 2014, 20:03:45Wie 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.
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
Zitat von: betateilchen am 19 Januar 2014, 20:44:46
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
Zitat von: betateilchen am 19 Januar 2014, 20:44:46
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
2014.01.25 19:49:11 1: Calendar Kalender_Schalter: Could not retrieve file at URLund zwar bei ALLEN Kalender. Mit LWP::UA funktionieren ALLE Kalender problemlos.
Viele Grüße
Udo
Zitat von: betateilchen am 25 Januar 2014, 19:57:02
Im Logfile bekomme ich bei Verwendung von 57_Calender mit den HttpUtills die Fehlermeldung
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?
$ics= GetFileFromURLQuiet($url,10,undef,0,1) if($type eq "url");
Danke.
Boris
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
Hallo Boris,
hier noch ein vielleicht wichtiger Nachtrag:
# $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:
# $Id: HttpUtils.pm 4514 2013-12-31 08:09:40Z 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.
richte Dir halt einen Kalender ein...
ausserdem solltest Du doch eigentlich am besten wissen, was Du in den HttpUtils zwischen der genannten Version und heute geändert hast?
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.
# svn diff 57_Calendar.pm
Index: 57_Calendar.pm
===================================================================
--- 57_Calendar.pm (revision 4753)
+++ 57_Calendar.pm (working copy)
@@ -962,7 +962,7 @@
if(defined($a[3])) {
my $keep= $a[3];
return "Argument $keep is not a number." unless($keep =~ /\d+/);
- splice @texts, $keep if($#texts>= 0);
+ splice @texts, $keep if($#texts>= 0 && $#texts >= $keep);
}
return join("\n", @texts);
Zitatrichte Dir halt einen Kalender ein...
Falsch. Ich will nicht solange raten, bis was nicht geht, und danach weiter raten, ob das das ist, was auch bei dir nicht geht.
Zitatausserdem solltest Du doch eigentlich am besten wissen, was Du in den HttpUtils zwischen der genannten Version und heute geändert hast?
Sicher. Ich habe es vor ca einem Monat komplett neugebaut, damit es auch asynchron funktioniert, siehe http://forum.fhem.de/index.php/topic,17804.msg119720.html#msg119720
Und danach auf 4 Platformen mit jeweils 6 Testfaellen probiert. Und gehofft, dass wenn es Probleme gibt, nicht nur: "geht nicht, such selber" als Meldung kriege, sondern was besseres.
Wenn Du diesen Thread einfach mal von Anfang bis jetzt gelesen hättest (es sind noch nicht einmal zwei Seiten!), hättest Du nicht fragen brauchen, denn es steht schon alles hier drin.
HttpUtils_BlockingGet() bzw. GetFileFromURLQuiet() liefert hier an 57_Calendar.pm kein Ergebnis zurück, wenn die Version 4514 oder neuer der HttpUtils verwendet wird.
HttpUtils_BlockingGet() bzw. GetFileFromURLQuiet() funktioniert hier ohne jegliche Änderung prima bis zur Version 4497.
57_Calendar mit LWP::ua anstatt der HttpUtils funktioniert immer.
Nehmen wir einmal an, das Problem liege NICHT in der 57_Calendar.pm und NICHT in der HttpUtils.pm - wo könnte es sonst noch zu suchen sein? Diese Frage ist ernstgemeint.
Ein weiteres Problem (57_Calendar unterschlägt wiederkehrende Termine) muss ich erst noch weiter analysieren.
Ich habe diesen Thread gelesen, ich fasse ma zusammen:
- bei dir funktioniert Calendar seit dem Umbau von HttpUtils nicht.
- bei zwei anderen Benutzern funktioniert Calendar mit dem umgebauten HttpUtils.
D.h. wenn ich jetzt bei Google ein Kalender anlege, und nach eine Stunde ungefaehr weiss, wie das Calendar-Modul funktioniert, werde ich wahrscheinlich (66%) keine Probleme haben. Da ich mangels Kenntnisse einen Trivialfall testen werde, ist die Wahrscheinlichkeit noch hoeher. Diese erfolglose Stunde wollte ich mir sparen.
Version 4497 ist vor dem Umbau (und auch noch ohne HttpUtils_BlockingGet), Version r4514 ist nach dem Umbau, der Rest sind Bugfixes fuer Sonderfaelle.
Vorschlag: Du setzt ein Calender-Request mit maximalen loglevel ab, parallel fuehrst du strace durch, und ich versuche aus den beiden Logs schlauer zu werden.
Kalender bei Google aufsetzen = 1 Minute, diesen Kalender in fhem einbinden = 1 Minute, keine Ahnung, wofür Du da eine Stunde brauchen willst. Der Kalender selbst braucht noch nichtmal Einträge zu besitzen. Aber in einem hast Du recht - vielleicht tritt das Problem bei Dir gar nicht auf.
Kommen wir deshalb noch einmal auf diese Frage zurück:
Zitat von: betateilchen am 27 Januar 2014, 13:23:35Nehmen wir einmal an, das Problem liege NICHT in der 57_Calendar.pm und NICHT in der HttpUtils.pm - wo könnte es sonst noch zu suchen sein?
Ich frage das nicht zum Spaß, denn ich bestreite nicht, dass es Installationen geben kann, bei denen das Problem nicht auftritt.
Zum Logging komme ich frühstens heute abend zu Hause.
Zitatkeine Ahnung, wofür Du da eine Stunde brauchen willst
Wenn man sich auskennt, klar. Wenn man nicht so recht weiss, wo/wie/was man machen soll, dann dauert das laenger.
Da es bei dir mit LWP und mit der alten Version der HttpUtils funktioniert, ist es ganz klar ein Bug in der neuen Version.
Hallo Rudi,
meine Recherchen deuten auch auf die Ursache in HttpUtils.pm hin. Wenn es Dir hilft, baue ich Dir in den nächsten Tagen eine Teststellung auf, die das Problem lokalisieren hilft - allerdings ohne reproduzierbaren Fehler :-)
Grüße
Boris
@Boris: Wenn die Daten von betateilchen nicht reichen, dann bitte.
ich habe doch gerade eben hier eine Antwort gepostet???
Habe nun alles auf verbose=5 gestellt und ein Kalenderupdate abgerufen. Mehr als das, was ich hier im Thread schon an Logging gepostet habe, ist fhem nicht zu entlocken. Es werden von den HttpUtils einfach keine Daten zurückgeliefert. Und 57_Calender gibt dann die korrekte Fehlermeldung für nicht gefundene Daten aus.
Ich versuchs mit rot und fett, blinken gibts leider nicht:
Vorschlag: Du setzt ein Calender-Request mit maximalen loglevel ab, parallel fuehrst du strace durch, und ich versuche aus den beiden Logs schlauer zu werden.
Schrei mich nicht an, ich hatte das durchaus schon heute nachmittag gelesen. Aber im Moment habe ich grade wichtigere Probleme, als mich um Dein von Dir (!) verkorkstes HttpUtils-Modul zu kümmern.
Udo,
mir gefällt Dein Ton nicht.
Ich kann gut verstehen, daß Dich das Problem nervt. Für ein Projekt auf freiwilliger Basis bieten wir hier super Support in unserer Freizeit. Bitte dies bei künftigen Antworten stets zu bedenken.
Viele Grüße
Boris
Hallo Boris,
mir gefällt Rudis Ton auch nicht. Der muss mich hier im Forum nicht dauernd (und immer wieder!) hinstellen wie den letzten Deppen, der die einfachsten Dinge nicht versteht, um die man ihn bittet. Ich bin mindestens 14 Stunden pro Tag außerhalb unterwegs und kann deshalb nicht immer alles sofort und genau so testen, wie er das möchte. Bisher habe ich immer alle gewünschten Informationen bereitgestellt, ebenfalls auf freiwilliger Basis und auch nicht im 24/7 Support, den hier niemand erwartet und niemand geben kann!
Ich bitte, auch DAS zu berücksichtigen.
Zusätzliches Debugging in HttpUtils_BlockingGet
sub
HttpUtils_BlockingGet($)
{
my ($hash) = @_;
my $err = HttpUtils_Connect($hash);
Debug "err after Connect: $err";
return ($err, undef) if($err);
my ($buf, $ret) = ("", "");
$hash->{conn}->timeout($hash->{timeout});
for(;;) {
Debug "entered for;; ret: $ret";
my ($rout, $rin) = ('', '');
vec($rin, $hash->{conn}->fileno(), 1) = 1;
my $nfound = select($rout=$rin, undef, undef, $hash->{timeout});
Debug "nfound: $nfound";
if($nfound <= 0) {
undef $hash->{conn};
return ("$hash->{displayurl}: Select timeout/error: $!", undef);
}
my $len = sysread($hash->{conn},$buf,65536);
Debug "len: $len";
last if(!defined($len) || $len <= 0);
$ret .= $buf;
}
return HttpUtils_ParseAnswer($hash, $ret);
}
liefert
2014.01.27 23:39:19 1: DEBUG>err after Connect:
2014.01.27 23:39:19 1: DEBUG>entered for;; ret:
2014.01.27 23:39:19 1: DEBUG>nfound: 1
2014.01.27 23:39:19 1: DEBUG>len: 0
2014.01.27 23:39:19 1: Calendar testkalender: Could not retrieve file at URL
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.
Ich hoffe, das hilft erstmal irgendwie weiter.
Mehr (insbesondere das strace) kann ich im Moment mit den Möglichkeiten, die mir aktuell zur Verfügung stehen, nicht machen!
Zurück zum sachlichen Inhalt dieses Threads...
Auch wenn ich diese Frage
Zitat von: betateilchenNehmen wir einmal an, das Problem liege NICHT in der 57_Calendar.pm und NICHT in der HttpUtils.pm - wo könnte es sonst noch zu suchen sein?
bereits zweimal gestellt habe, muss ich sie noch ein drittes Mal in den Raum stellen.
Der Hintergrund ist nämlich der, dass ich insgesamt drei fhem Installationen habe, bei denen fhem überall auf dem aktuellsten Stand ist:
1. Beaglebone Black mit Debian
2. RaspberryPi mit Debian
3. fhem auf Debian in einer VMware Workstation unter Windows7
Auf allen drei Systemen wird der gleiche Kalender abgefragt.
Auf den Systemen 1 + 2 tritt der beschriebene Fehler mit den aktuellen HttpUtils auf.
Auf den Systemen 1 + 2 funktioniert alles mit der alten HttpUtils Version.
Auf System 3 funktioniert der Kalender mit den aktuellen HttpUtils problemlos.Es scheint mir so, dass es irgendwelche Abhängigkeiten gibt, die ausserhalb von fhem zu suchen sind.
Deshalb hatte ich bereits zweimal nach weiteren möglichen/denkbaren Ursachen gefragt,
die vielleicht irgendwo in der Abhängigkeitenkette zu suchen wären?
57_Calendar hängt ab von HttpUtils
HttpUtils hängt ab von IO::Socket::INET + fhem.pl (?)
fhem.pl hängt ab von IO::Socket + ... (?)
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
ZitatDas 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.
ZitatDeshalb 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.
ZitatMich 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.
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
Den von Dir vorgeschlagenen Test werde ich heute abend machen und Dir hier Rückmeldung geben.
Zitat von: rudolfkoenig am 28 Januar 2014, 11:28:40wenn 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.
Zitat von: rudolfkoenig am 28 Januar 2014, 11:28:40dann 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.
Zitat von: rudolfkoenig am 28 Januar 2014, 11:28:40Koenntest 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.
Zitat von: justme1968 am 28 Januar 2014, 12:48:16wenn 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:
$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.
Zitat von: betateilchen am 27 Januar 2014, 12:09:59
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
Zitat von: betateilchen am 27 Januar 2014, 12:09:59
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
hm...
- 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.
@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.
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.
Zitat von: rudolfkoenig am 28 Januar 2014, 22:25:53@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.
@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?
Zitat von: rudolfkoenig am 28 Januar 2014, 22:25:53@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.
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
So, ich habe die Ursache bei mir gefunden.
Als ich fhem zum Raspberry umzog, funktionierte das Senden von (Google-)Emails mittels DebianMail nicht. Es verursachte die Fehlermeldung:
"invalid SSL_version specified at /usr/share/perl5/IO/Socket/SSL.pm line 332"
Nach einer Anleitung habe ich folgendes mit Erfolg geändert:
In der Datei /usr/share/perl5/IO/Socket/SSL.pm
ersetzte ich die Zeile 1490
m{^(!?)(?:(SSL(?:v2|v3|v23|v2/3))|(TLSv1[12]?))$}i
durch:
m{^(!?)(?:(SSL(?:v2|v3|v23|v2/3))|(TLSv1[12]?))}i
Danach funktioniert der Versand der Emails. In meiner Logdatei konnte ich aber rekonstruieren, dass ab diesem Zeitpunkt der Abruf des Google-Kalenders mittels 57_Calendar nicht mehr funktioniert.
Nachdem ich heute die Änderung zurückgenommen habe, funktioniert der Abruf des Google-Kalenders, aber wie zu Erwarten das Senden der Google-Mails nicht mehr.
Leider verstehe ich zu wenig von den Zusammenhängen, dass ich wirklich weiß, was ich da tue.
Ich hoffe, dass dies zur Klärung beiträgt und dass auch mir geholfen werden kann. Falls ich für dieses Problem besser einen neuen Thread eröffne, sagt es mir bitte.
wie hast Du denn das SSL Paket auf den Raspberry installiert?
Mein Vorgehen war:
lt.: http://www.fhemwiki.de/wiki/E-Mail_senden#Raspberry_Pi
sudo apt-get update
sudo apt-get install sendEmail
in der 99_myUtils folgende Unterroutine einfügen:
sub
DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $ret = "";
my $sender = "Email\@gmail.com";
my $konto = "Email\@gmail.com";
my $passwrd = "pwegal123";
my $provider = "smtp.gmail.com";
Log 1, "sendEmail RCP: $rcpt";
Log 1, "sendEmail Subject: $subject";
Log 1, "sendEmail Text: $text";
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -s '$provider':587 -xu '$konto' -xp '$passwrd' -o tls=yes);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}
Der Test durch Eingabe in Terminal möglich:
sendEmail -f 'plalelula@gmail.com' -t 'peter.kansy@gmail.com' -u 'Test' -m 'Testbody' -s 'smtp.gmail.com' -xu 'plalelula@gmail.com' -xp 'pwegal123' -o tls=yes
Anmerkung: Ich habe im Code tls=no auf tls=yes geändert.
Vielleicht habe ich falsch geantwortet:
Vor dem gerade beschriebenen Vorgehen habe ich durchgeführt:
########################################################################################################
## Raspberry Pi Allgemein
##
## Das Debian-System allgemein auf den neuesten Stand bringen:
## (hier nur als allgemeine Beschreibung eingefügt)
## sudo apt-get update
## sudo apt-get upgrade
## sudo apt-get autoremove
## Die erste Anweisung holt sich ein Verzeichnis der aktuelle Pakete, die zweite Anweisung lädt neuere Versionen
## runter und installiert sie. Die letzte Anweisung sorgt dafür, dass unbenötigte Packete deinstalliert werden.
########################################################################################################
@betateilchen: kannst du bitte bestaetigen, dass du HTTPS (und nicht HTTP) benoetigst? Diese Schicht kenne ich nicht so genau, kann aber vorstellen, dass in so einem Fall shutdown kontraproduktiv ist. Erklaert immer noch nicht, wieso alt tut, und neu nicht oder wieso es bei anderen tut und bei dir nicht.
@LeLeLu: um das Problem zu verstehen wuerde ich in SSL.pm den String ausgeben
Zitat von: rudolfkoenig am 30 Januar 2014, 06:39:51
@LeLeLu: um das Problem zu verstehen wuerde ich in SSL.pm den String ausgeben
Sorry, aber der Hinweis ist mir zu knapp. Soll ich tracen?
Als Gegenleistung kann ich gerne mal eine knifflige Excel-Frage beantworten ;D
Zitat von: rudolfkoenig am 30 Januar 2014, 06:39:51
@betateilchen: kannst du bitte bestaetigen, dass du HTTPS (und nicht HTTP) benoetigst?
Ich benötige https nicht, aber Google will es so 8) Die URL der privaten ICAL Adresse ist immer eine https Adresse. Und dann passieren beim Aufruf oft auch noch 30x-redirects von Google-Seite.
Aber es erklärt nicht nur nicht, warum es bei "alt" tut und bei "neu" nicht mehr, sondern auch nicht, warum es bei "neu" manchmal (auf bestimmten Plattformen) tut und auf anderen nicht.
Zitat von: betateilchen am 29 Januar 2014, 22:21:39wie hast Du denn das SSL Paket auf den Raspberry installiert?
Hier jetzt hoffentlich die richtige Antwort:Ich hatte schon Deinem Tipp (aus diesem Forum) folgend libwww-perl installiert:root@FHEMRPI:/usr/share/perl5/IO/Socket# sudo apt-get install libwww-perlReading package lists... DoneBuilding dependency tree Reading state information... Donelibwww-perl is already the newest version.0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.Damit müsste die richtige ssl.pm installiert sein?
Heute hab ich mal mit unseren Crypto-Spezialisten gesprochen, dabei kam folgendes raus: Es gab/gibt wohl Probleme mit einer bestimmten Version der SSL-Bibliotheken unter Linux, die zu genau solchen Problemen in der https-Kommunikation führen können. Empfohlen wird ein Downgrade der libssl von Version 1.0.1 (falls installiert) auf 1.0.0.
Jetzt muss ich mal suchen, ob ich irgendwo die passenden Pakete für mein Beaglebone finde, dann kann ich weitertesten.
ZitatSorry, aber der Hinweis ist mir zu knapp. Soll ich tracen?
Ich meinte in der Zeile 1490 in SSL.pm (vor dem erwaehnten regexp-check) die Zeile
print "SSL: $_\n";
einfuegen, und fhem mit
attr global logfile -
im terminal starten.
Bei mir kommen dann fuer jede telnet/FHEMWEB Verbindung zwei Zeilen:
SSL: SSLv23
SSL: !SSLv2
Danke Rudolf!
das Ergebnis ist gleich Deinem. Ich poste mal die Meldungen bis Calendar. Vielleicht hilft dies:
pi@FHEMRPI~ $ sudo /etc/init.d/fhem start Starting fhem...
2014.02.01 17:56:37.083 1: Including fhem.cfg
2014.02.01 17:56:37.673 2: Perfmon: ready to watch out for delays greater than one second
2014.02.01 17:56:37.847 2: eventTypes: loaded 1774 events from ./log/eventTypes.txt
2014.02.01 17:56:37.986 3: Opening myCUL device /dev/ttyACM0
2014.02.01 17:56:38.180 3: myCUL device opened
2014.02.01 17:56:38.305 3: myCUL: Possible commands: BCFiAGMRTVWXefmltux
2014.02.01 17:56:38.451 1: HMLAN_Parse: myHMLAN new condition disconnected
2014.02.01 17:56:38.453 3: Opening myHMLAN device 192.168.2.34:1000
2014.02.01 17:56:38.481 3: myHMLAN device opened
2014.02.01 17:56:38.485 1: HMLAN_Parse: myHMLAN new condition init
2014.02.01 17:56:39.083 3: WEB: port 8083 opened
2014.02.01 17:56:39.128 3: WEBphone: port 8084 opened
2014.02.01 17:56:39.137 3: WEBtablet: port 8085 opened
2014.02.01 17:56:39.312 3: telnetPort: port 7072 opened
2014.02.01 17:56:39.318 1: Including ./PKDevices.cfg
2014.02.01 17:56:39.370 3: FHEM2FHEM opening FB2RPi at 192.168.2.1:7072
2014.02.01 17:56:39.375 3: FHEM2FHEM device opened (FB2RPi)
SSL: SSLv23
SSL: !SSLv2
2014.02.01 17:56:40.195 1: Calendar FHEMKalender: Could not retrieve file at URL
2014.02.01 17:56:42.854 3: [HourCounter] HourCounter_Initialize.156 Init Done with Version 0.99.d - 03.12.2013 (john)
2014.02.01 17:56:42.856 2: [Kueche_Licht_HC] HourCounter_Define.165 parameters: Kueche_Licht_HC HourCounter Kueche_Licht.on Kueche_Licht.off
Bedeutet dies nun das die Google-Kalender Abfragen wieder funktionieren?
Oder was muss der Laie nun tun, das es funktioniert?
Bei mir funktionieren die G-Calendar auf zwei von drei Systemen nur deshalb, weil ich im 57_Calendar die HttpUtils nicht mehr verwende.
Die Lösung mit noshutdown hat auch nicht dauerhaft funktioniert, dadurch ergaben sich reproduzierbare Probleme an anderen Stellen.
Zitat von: betateilchen am 04 Februar 2014, 09:58:25
Bei mir funktionieren die G-Calendar auf zwei von drei Systemen nur deshalb, weil ich im 57_Calendar die HttpUtils nicht mehr verwende.
Wie hast du dies denn gemacht?
Bitte Info
einfach nachlesen, das steht im vierten oder fünften Beitrag dieses Threads.
Also bei mir war es nicht genau die Zeile 825 sondern 831 aber egal
Ich habe es jetzt wie folgt geändert
Zitatif($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") {
if(open(ICSFILE, $url)) {
leider ohne Erfolg.
Immer noch "Calendar xx: Not an ical file at URL"
Hab ich denn sonst noch was zu tun?
In welcher Zeile das steht, hängt von der Version des Kalendermoduls ab. Weitere Aktivitäten sind nicht notwendig.
Funktioniert denn der Abruf des ics-Files, wenn Du die URL im Browser aufrufst?
Zitat von: betateilchen am 05 Februar 2014, 20:08:55
Funktioniert denn der Abruf des ics-Files, wenn Du die URL im Browser aufrufst?
Ja geht, sowohl http als auch https
Zitat von: betateilchen am 27 Januar 2014, 12:09:59
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.
Ein Fix ist eingecheckt.
Wegen Disaster Recovery schubse ich derzeit ein paar Terabytes hin und her und komme nicht zu produktiver Arbeit :(
Grüße
Boris
Gibt es denn zu dem Kalenderthema etwas neues ??
Nö, irgendwie scheint sich niemand dafür verantwortlich zu fühlen, funktionierende HttpUtils zu schaffen.
Hast Du schonmal die alten HttpUtils wieder eingespielt, die vor dem großen Umbau "aktuell" waren? Die funktionieren bei mir ganz klaglos und ich habe die HttpUtils in die Liste "excluded_from_update" aufgenommen, damit sie nicht automatisch überschrieben werden.
Zitat von: betateilchen am 24 Februar 2014, 13:19:38
Nö, irgendwie scheint sich niemand dafür verantwortlich zu fühlen, funktionierende HttpUtils zu schaffen.
Laut maintainer.txt
ZitatFHEM/HttpUtils.pm rudolfkoenig http://forum.fhem.de Automatisierung
Kannst du mir die version / das updatedatum nennen von deiner die funktioniert? habe auch ein problem mit dem calender, weiss aber nicht obs an den utils liegt oder am kalender
@chris1284: Kannst Du mir einen konkreten Fall zum nachstellen geben?
@chris: http://forum.fhem.de/index.php/topic,18968.msg129617.html#msg129617
Da steht drin, welche Version bei mir funktioniert
# $Id: HttpUtils.pm 4497 2013-12-29 09:37:08Z rudolfkoenig $
und ab wann es nicht mehr klappt.
# $Id: HttpUtils.pm 4514 2013-12-31 08:09:40Z rudolfkoenig $
@rudolfkoenig: ich weiß wie gesagt nicht ob mein Problem mit httutils oder calendar zu tun hat.
Kurz umschrieben: nach erstem Einlesen der ics erfolgt nur noch eine Aktualisierung neuer Termine oder von Einzelterminen. Serientermine vom ersten Einlesen werden scheinbar nicht eingelesen/aktualisiert und zu falschen Daten dargestellt (1 Tag später, falsche Wiederholung usw.).
Das andere sind die vielen unnötigen Einträge im Log http://forum.fhem.de/index.php/topic,20190.msg139343.html#msg139343
Zitat2014.02.13 20:37:26 1: HttpUtils url=<hidden>
2014.02.13 20:37:26 1: <hidden>: HTTP response code 200
2014.02.13 20:37:26 1: HttpUtils <hidden>: Got data, length: 16737
2014.02.13 20:42:26 1: HttpUtils url=<hidden>
2014.02.13 20:42:26 1: <hidden>: HTTP response code 200
2014.02.13 20:42:26 1: HttpUtils <hidden>: Got data, length: 16737
2014.02.13 20:47:26 1: HttpUtils url=<hidden>
2014.02.13 20:47:26 1: <hidden>: HTTP response code 200
2014.02.13 20:47:26 1: HttpUtils <hidden>: Got data, length: 16737
2014.02.13 20:52:26 1: HttpUtils url=<hidden>
2014.02.13 20:52:26 1: <hidden>: HTTP response code 200
2014.02.13 20:52:26 1: HttpUtils <hidden>: Got data, length: 16737
ps wenn du mal wieder Zeit hats, kannst du hier nochmal rein schauen http://forum.fhem.de/index.php/topic,20621.0.html :-)
Zitat von: chris1284 am 24 Februar 2014, 14:33:49Kurz umschrieben: nach erstem Einlesen der ics erfolgt nur noch eine Aktualisierung neuer Termine oder von Einzelterminen. Serientermine vom ersten Einlesen werden scheinbar nicht eingelesen/aktualisiert und zu falschen Daten dargestellt (1 Tag später, falsche Wiederholung usw.).
Das hat mit den HttpUtils vermutlich nichts zu tun, denn die Daten werden ja bei Dir wenigstens noch gelesen.
Got data, length: 16737
Zitat von: betateilchen am 24 Februar 2014, 13:19:38
Hast Du schonmal die alten HttpUtils wieder eingespielt, die vor dem großen Umbau "aktuell" waren? Die funktionieren bei mir ganz klaglos und ich habe die HttpUtils in die Liste "excluded_from_update" aufgenommen, damit sie nicht automatisch überschrieben werden.
Wo bekommen ich die HttpUtils her und wo befindet sich die Liste mit dem "excluded" bzw. wie sieht denn dein Eintrag aus.
Danke
Die HttpUtils bekommst Du z.B. aus SVN und excludefromupdate ist ein Attribut von "global"
Interessante Erkenntnis:
- Auf meinem Cubietruck im Netzwerk bei meiner Lebensgefährtin funktionierten die HttpUtils am Wochenende völlig problemlos.
- Der gleiche Cubietruck in meinem Netzwerk liefert mir mit den aktuellen HttpUtils keine Daten, wohl aber mit den alten HttpUtils (Version Ende Dezember 2013)
Welchen Einfluss kann denn die Art der Internetverbindung haben?
Bei mir in Mönchengladbach: Unitymedia -> Fritzbox 6360 als Kabelmodem
Bei meiner Partnerin in Heidelberg: Kabel BW -> Fritzbox 6340 als Kabelmodem
Kannst du da, wo es nicht funktioniert, ein strace mitlaufen lassen?
Noch schoener waere, wenn man zwei logs haette, einmal funktionierend, und einmal nicht.
Hier das strace von einer nicht funktionierenden Konstellation. Da es bei Dir ja zu funktionieren scheint, kannst Du ja das positiv-trace sicher selbst erstellen.
Ich denke, der spannende Teil beginnt so um Zeile 2930.
Die gesamte fhem-Konfiguration für diesen Test sieht so aus:
attr global logfile ./log/fhem-%Y-%m-%d.log
attr global modpath .
attr global motd none
attr global userattr devStateIcon devStateStyle icon sortby webCmd
attr global verbose 3
define Logfile FileLog ./log/fhem-%Y-%m-%d.log fakelog
define telnetPort telnet 7072 global
define testkalender Calendar ical url https://www.google.com/calendar/ical/.../basic.ics
define WEB FHEMWEB 8083 global
ZitatIch denke, der spannende Teil beginnt so um Zeile 2930.
Ab da wird das SSL Modul geladen. Ab Zeile 3256 wird die SSL Verbindung zu google initiiert, und nach etwas schreiben und lesen macht FHEM mit shutdown(1) die Schreibseite zu. Danach will noch jemand schreiben, vmtl. das Perl-SSL Framework, was mit EPIPE+SIGPIPE schiefgeht. Daten bekommt HttpUtils von google (vermutlich) nicht.
Kannst Du bitte den Aufruf
shutdown $hash->{conn}, 1 if(!$hash->{noshutdown});
in HttpUtils.pm, Zeile 202 durch
shutdown $hash->{conn}, 1 if(!$hash->{noshutdown} && $hash->{protocol} ne "https");
ersetzen, um zu sehen, ob es nur an shutdown liegt?
Änderungen getestet auf Systemen, die bisher das Fehlverhalten zeigten:
RaspberryPi => funktioniert nach Änderung
CubieTruick => funktioniert nach Änderung
Über Langzeitverhalten kann ich natürlich noch nichts sagen.
Bedeutet dies Hoffnung für aller Calender-Benutzer?
Nicht fuer alle, da es fuer manche laut Aussagen hier auch ohne die Aenderung funktioniert hat.
Btw. die Aenderung sollte mit dem heutigen update verfuegbar sein.
Wie schon beschrieben: Auch bei mir hat es ohne die Änderung, allerdings an einem anderen Internetanschluß auf der unveränderten Hardware funktioniert.
Die bereits heute nacht eingebaute Änderung führte heute morgen dazu, dass mein Cubietruck, auf dem fhem läuft, während des Updates komplett abgestürzt ist - ohne jegliche Fehlermeldung seitens fhem.
2014.03.27 08:24:24 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2014.03.27 08:24:53 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2014.03.27 08:25:00 3: update get http://fhem.de/fhemupdate4/svn/FHEM/FhemUtils/release.pm
2014.03.27 08:25:00 1: update check Releases => local: Fhem 5.5 (DEVELOPMENT) remote: Fhem 5.5 (DEVELOPMENT)
2014.03.27 08:25:00 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2014.03.27 08:28:52 3: telnetPort: port 7072 opened
Keine Ahnung, ob es da einen Zusammenhang gibt, aber komisch finde ich das schon, zumal https beim Update kein Thema ist.
Der nächste Updateversuch direkt nach dem Neustart hat problemlos funktioniert.
2014.03.27 08:29:28 3: update get http://fhem.de/fhemupdate4/svn/FHEM/FhemUtils/release.pm
2014.03.27 08:29:28 1: update check Releases => local: Fhem 5.5 (DEVELOPMENT) remote: Fhem 5.5 (DEVELOPMENT)
2014.03.27 08:29:28 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2014.03.27 08:29:29 1: update excluded by configuration: HttpUtils.pm
2014.03.27 08:29:29 1: update saving statefile
2014.03.27 08:29:29 3: update get http://fhem.de/fhemupdate4/svn/./CHANGED
...
2014.03.27 08:29:38 1: update 32 file(s) have been updated.
Nachtrag:
Auch im syslog ist kein Hinweis auf eine Absturzursache zu finden:
Mar 27 08:24:06 cubie dhclient: No DHCPOFFERS received.
Mar 27 08:24:06 cubie dhclient: No working leases in persistent database - sleeping.
Mar 27 08:28:49 cubie kernel: imklog 5.8.11, log source = /proc/kmsg started.
Mar 27 08:28:49 cubie rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="2308" x-info="http://www.rsyslog.com"] start
Mar 27 08:28:49 cubie kernel: [ 0.000000] Booting Linux on physical CPU 0