Hallo zusammen,
ich habe ein Update für das 98_update.pm Modul erstellt welches folgende Funktionen integriert:
- Wenn HttpUtils_BlockingGet fehl schlägt, wird 20x versucht dies zu wiederholen.
- Vor jeder Wiederholung ist ein sleep(2) eingebaut um etwas zu warten, da ich von einem temporären Problem ausgehe.
- Bei jedem Fehler wird ein Log Entry dazu geschrieben mit der Fehlerbeschreibung aus $err.
Wäre super wenn der Code seinen Weg ins Repository findet bzw. wenn etwas noch nicht zum Coding Style passt ich Feedback dazu erhalte.
Diff
--- /opt/fhem/FHEM/98_update.pm 2015-08-17 21:25:28.252974821 +0200
+++ /opt/fhem/FHEM/98_update.pm.bak 2015-08-17 21:17:10.799091282 +0200
@@ -371,8 +371,18 @@
upd_getUrl($)
{
my ($url) = @_;
+ my ($errcount) = 0;
+ my ($errmax) = 0;
$url =~ s/%/%25/g;
+
my ($err, $data) = HttpUtils_BlockingGet({ url=>$url });
+ while($err && $errcount<$errmax) {
+ uLog 2, "Retry $errcount/$errmax $url due to error: ".$err;
+ $errcount++;
+ sleep(2);
+ ($err, $data) = HttpUtils_BlockingGet({ url=>$url });
+ }
+
if($err) {
uLog 1, $err;
return "";
Hier der Ursprungsthread dazu:
http://forum.fhem.de/index.php/topic,39837.0.html
Gruß
dominik
Welches Problem wird damit geloest?
Und warum genau 2s sleep und 20-mal?
Problem: Update schlägt fehl, weil Verbindung immer wieder Probleme macht (aktuell unerklärlich, da ping funktionierte). In so einem Fall ist KEIN update möglich. Fhem bricht andauernd ab und ich muss wieder bei 0 starten.
Folgende Fehlermeldungen erhielt ich andauernd:
2015.08.09 11:25:03 1: UPD www/images/fhemSVG/rc_YELLOW.svg
2015.08.09 11:25:03 1: UPD www/images/fhemSVG/rc_dot.svg
2015.08.09 11:25:04 1: http://fhem.de/fhemupdate/www/images/fhemSVG/rc_dot.svg: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: No route to host
2015.08.09 11:25:18 1: UPD www/images/default/10px-kreis-gelb.png
2015.08.09 11:25:18 1: UPD www/images/default/10px-kreis-gruen.png
2015.08.09 11:25:18 1: UPD www/images/default/10px-kreis-rot.png
2015.08.09 11:25:18 1: UPD www/images/default/1px-spacer.png
2015.08.09 11:25:19 1: UPD www/images/default/FS20.off.png
2015.08.09 11:25:19 1: http://fhem.de/fhemupdate/www/images/default/FS20.off.png: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: No route to host
2015.08.09 11:25:29 1: UPD www/images/default/10px-kreis-gelb.png
2015.08.09 11:25:29 1: UPD www/images/default/10px-kreis-gruen.png
2015.08.09 11:25:29 1: UPD www/images/default/10px-kreis-rot.png
2015.08.09 11:25:29 1: http://fhem.de/fhemupdate/www/images/default/10px-kreis-rot.png: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: No route to host
Hatte nebenbei auch einen ping laufen, der ohne Probleme funktionierte. Da ich keine Möglichkeit hatte FHEM zu aktualisieren (tagelang probiert, immer wieder mit auch Router Neustart gemacht) versucht ich eine andere Lösung zu finden. Daher entstand dieser Patch.
Die 2s sleep sollten nur dazu da sein, dass der Http Request nicht sofort nochmals gemacht wird - da ja aktuell ein Problem mit der Verbindung besteht. Eventuell genügt auch 1s.
Als ich die Funktionalität das erste Mal testete, hatte ich teilweise bis zu 10 Http Requests die nicht funktionierten. Daher habe ich "sicherheitshalber" 20x genommen. Ich weiß, das ist nichts was irgendwo hergeleitet ist, aber mit irgendwas musste ich starten.
Die einzige Frage die sich in diesem Fall stellt, ist wie lange man nun wirklich "wartet" bis die Verbindung wieder steht.
Da könnte man sich auch bei anderen Projekten mit Update per Internet informieren.
z.B.
Gentoo eselect macht es 3 Mal mit 1 sec. "Pause"
debian/ubuntu apt-get probiert es auch mehrmals, gibt es nur nicht aus
......
Da es auch bei einem "guten" Anschluß zu Problemen kommen kann, würde ich normalerweise auf 3 Wiederholungen mit 1sec Pause gehen.
Nur mal meine 2cent aus Erfahrungen im Netzwerkbereich ..
Die andere Frage wäre, ob man nicht direkt in den HttpUtils.pm ansetzen sollte? Schlussendlich soll ja davon jeder profitieren und nicht nur 98_update.pm.
Ein großer Unterschied zu apt-get und eselect ist, dass diese Tools in vielen Fällen dort weitermachen wo der Verbindungsabbruch aufgetreten ist. update macht das nicht, es beginnt wieder bei 0 und damit war es bei mir unmöglich das Update durchzuführen.
Hier ein Update für HttpUtils.pm
HttpUtils.pm.patch
364a365,382
> # Parameters same as HttpUtils_NonblockingGet with additional maxretries parameter
> # Returns (err,data)
> sub
> HttpUtils_BlockingGetWithRetries($)
> {
> my ($hash) = @_;
> my ($errcount) = 0;
> my ($maxretries) = 20 if (!defined($hash->{maxretries}));
> my ($err, $data) = HttpUtils_BlockingGet($hash);
> while ($err && $errcount<$maxretries) {
> $errcount++;
> sleep(2);
> ($err, $data) = HttpUtils_BlockingGet($hash);
> }
> return ($err, $data);
> }
>
> #################
Änderungen
- Neue Funktion HttpUtils_BlockingGetWithRetries hinzugefügt.
- Standardmäßig werden 20 Retries mit 2s Pause gemacht wenn die Funktion verwendet wird
- Parameter maxretries definiert die Anzahl der retries
Diese Funktion könnte dann in jedem Modul verwendet werden. Wenn es keine Einwände gibt, könnte man natürlich auch gleich die Funktion in HttpUtils_BlockingGet umbenennen und die aktuelle Funktion auf eine interne ändern, so das automatisch alle Module die neue Retry Funktionalität nutzen.
Was meint ihr? Welcher Weg ist der richtige?
Interessant wäre dann zu einer möglichen Lösung wie der Benutzer sein Update lauffähig bekommt, damit er am Ende wieder einen sauberen Stand hat. Sozusagen einen Micro-Patch, den der Benutzer manuell ausführen muss mit einem kleinen How-To.
Zitat von: Celeritas am 13 August 2015, 12:50:56
Interessant wäre dann zu einer möglichen Lösung wie der Benutzer sein Update lauffähig bekommt, damit er am Ende wieder einen sauberen Stand hat. Sozusagen einen Micro-Patch, den der Benutzer manuell ausführen muss mit einem kleinen How-To.
Von How-Tos oder Micro-Patches die der User selber ausführen muss halte ich nichts. Das "Ding" (also FHEM :) ) muss funktionieren und im best case mit so wenig wie möglich Aufwand in der Konfiguration. Vor allem bei einem HttpGet soll der User nichts machen müssen.
Da ich das Thema hier nicht untergehen lassen will, frage ich mich wie wir hier weitermachen? HttpUtils oder 98_update?
Wer trifft eigentlich bei FHEM die Design/Architektur Entscheidungen?
ZitatDa ich das Thema hier nicht untergehen lassen will, frage ich mich wie wir hier weitermachen? HttpUtils oder 98_update?
Wer trifft eigentlich bei FHEM die Design/Architektur Entscheidungen?
Letztlich der Maintainer-> http://fhem.de/MAINTAINER.txt . Also der, der alles ausbaden muss.
Ansonsten bitte bedenken, dass hier keine Hauptamtlichen arbeiten. Darum mal abwarten...
Zitat von: dominik am 13 August 2015, 18:57:54
Von How-Tos oder Micro-Patches die der User selber ausführen muss halte ich nichts. Das "Ding" (also FHEM :) ) muss funktionieren und im best case mit so wenig wie möglich Aufwand in der Konfiguration. Vor allem bei einem HttpGet soll der User nichts machen müssen.
Würde ich dir im Normal-Fall zustimmen, jedoch gibt es im Moment genug Leute, die nicht in der Lage sind ein Update erfolgreich zu beenden. Somit kommt man um einen Workaround wohl nicht drum herum. Die Meldungen zu "Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: timeout" werden ja immer mehr.
Ich wusste nicht, dass die Meldungen dazu in letzter Zeit mehr werden. Wenn dem so ist, dann sollten wir zügig eine Lösung implementieren.
Du hast Recht, dass auch meine Lösung nur ein Workaround ist. Die richtige Lösung wäre wohl ein Retry inkl. speichern des Fortschritts beim Update. So könnte man das Update immer wieder Fortsetzen und muss im Fehlerfall nicht von vorne beginnen. Irgendwann sollte es dann klappen.
Ich hatte gestern auch nach langer Zeit ein Update gewagt. Auch ständig diese Abrüche. Habe dann mittels exclude sie Unterverzeichnisse und die einen Großteil der xx_yyyy.pm Dateien unterdrückt. Anschließend hatte er beim nächsten update mit Überprüfung der Dateigröße ohne exclude nur noch ein paar Dateien nachgezogen.
Gesendet von meinem GT-I9295
Also ich denke, dass der Patch aus dem ersten Post vorerst mal eingespielt werden sollte. Damit ermöglicht man zumindest den Usern wieder das Update. Danach kann man sich Gedanken dazu machen, ob nicht doch die HttpUtils.pm den Retry Mechanismus erhalten soll.
Grad eben auf meinem RasPi wieder ein update gemacht und - klappt.
ZitatAlso ich denke, dass der Patch aus dem ersten Post vorerst mal eingespielt werden sollte.
Solange es keine Nebenwirkungen mit funktionierenden updates gibt.
Edith: Bitte nicht falsch verstehen.
Wenn es eine Lösung gibt dann bitte für alle und nicht erst
ZitatDanach kann man sich Gedanken dazu machen,
ZitatWürde ich dir im Normal-Fall zustimmen, jedoch gibt es im Moment genug Leute, die nicht in der Lage sind ein Update erfolgreich zu beenden. Somit kommt man um einen Workaround wohl nicht drum herum.
Wozu workarounds?
Erstmal einfach ein
update 98_update.pm
reload 98_update ausführen, dann kann man den Rest schon mit dem "neuen" Modul machen.
lg, Ici
@Puschel74, klar, nur solange es keine Nebenwirkungen gibt. Deswegen habe ich den Patch auch extra klein gehalten um eventuelle Auswirkungen überschaubar zu halten.
Mich würde freuen, wenn mehr Leute das testen würden um sicher zu gehen dass es auch überall funktioniert.
@Icinger, korrekt. Man müsste nur vorher das Modul updaten und danach läuft es durch.
Zitat von: dominik am 17 August 2015, 20:37:50
@Puschel74, klar, nur solange es keine Nebenwirkungen gibt. Deswegen habe ich den Patch auch extra klein gehalten um eventuelle Auswirkungen überschaubar zu halten.
Mich würde freuen, wenn mehr Leute das testen würden um sicher zu gehen dass es auch überall funktioniert.
Wenn in Beitrag 1 die 98_update.pm inkl. deines DIFF enthalten ist zieh ich mir die runter und probier sie auf meinem Versuchssystem aus.
Natürlich auf dem System mit dem das letzte update geklappt hat ;)
Stell sie doch bitte zusätzlich als Datei in den ersten Beitrag - ich hasse copy&paste (damit kann es nur zu Fehler kommen die wir hier nicht brauchen).
Klar könnte ich auch das Diff einarbeiten - aber bei mir klappt das update ja 8)
Den Test werde ich dann am Mittwoch machen - ich kopier extra eine alte Sicherung ein um zu schauen was passiert.
Steht bereit Puschel74 :)
Siehe 1. Post.
Der Patch im ersten Post versucht mit einem primitiven Verfahren das immerhin seit 30 Jahren bewaehrte TCP/IP, was auch selbst retries kennt, zu verbessern. Bevor ich die Symptome mit solch kruden Mitteln ueberdecke, wuerde ich gerne wissen, wo die Probleme eigentlich herkommen.
Ein gebräuchliches Muster in der IT: wir implementieren schon mal eine Lösung für ein Symptom, dessen Ursache noch völlig unklar ist.
Ich hatte noch nie Probleme mit dem Update, und wenn es der Update sporadisch nicht schafft, einzelne kleine Dateien herunterzuladen - lt. Originalpost lustigerweise nur in einem bestimmten Ordner, dann ist irgendwas faul, das man vielleicht mit einem Workaround im update erstmal unsichtbar machen kann, dem man aber auf den Grund gehen sollte. Da stimme ich Rudi zu - bitte nicht solche Lösungen.
Danke Rudi - dann brauch ich auch nichts testen ;D
Ich bin bei euch, dass da eine gründlichere Ursachenforschung notwendig ist, da es vielleicht nicht NUR ein Problem der Internetverbindung ist, sondern eventuell auch noch ZUSÄTZLICH ein anderes Problem besteht. Das Problem einer schlechten Internetverbindung werden wir aber definitiv für den User (leider) nicht lösen können.
Und genau da setze ich an...Ursache: schlechte Internetverbindung in Verbindung mit einer Update Implementierung die keinen Status speichert. Daraus resultiert, dass solche User kein Update durchführen können.
Ich denke emerge, apt-get & co haben schon eine Berechtigung gefunden wieso man Retries bei solchen Updatefunktionalitäten einbaut. Gleiches war auch mein primitiver Ansatz in der Update Logik. Nicht mehr und nicht weniger...ich liefere einfach eine simple (und damit in den Auswirkungen überschaubare) Lösung für ein Problem welche defacto besteht (siehe auch http://forum.fhem.de/index.php?topic=34076.0).
Mag jemand, der das Update Problem hat, testweise mal versuchen die mtu size runterzusetzen und dann das Update noch einmal laufen lassen?
Ich vermute, dass Raspbian dazu folgende Syntax hat (habe keinen Pi im Zugriff):
sudo /sbin/ifconfig eth0 mtu 1000
Kann man nachher wieder mit 1500 zurücksetzen.
Falls ein anderes Interface als eth0 für den Internetzugriff genutzt wird, dann das bitte angeben.
/Uli
(Kopiert von: http://forum.fhem.de/index.php/topic,34076.msg323989.html#msg323989)
Hi, also ich habe die mtu size wie beschrieben herunter gesetzt:
sudo /sbin/ifconfig eth0 mtu 1000
Der update prozess schlägt aber leider wieder fehl, dieselbe fehlermeldung.
2015-08-18 22:33:11 Global global http://fhem.de/fhemupdate/FHEM/10_HXBDevice.pm: Can't connect(1) to http://fhem.de:80: IO::Socket::INET: connect: timeout
Schade, der Fehler wäre typisch dafür.
Zitat von: speex am 18 August 2015, 22:39:03
sudo /sbin/ifconfig eth0 mtu 1000
Laut Email Benachrichtigung (vor Edit) hast Du noch einen reboot vor dem Update durchgeführt. Das würde nicht funktionieren, da das ifconfig statement nicht bootfest ist, dazu müsstest du unter /etc/network/interfaces dem Interface ein "mtu 1000" mitgeben. Du hast das Update vor dem reboot getestet und eth0 ist sicher dein benutztes Interface? Wie schon geschrieben, die Problemtik würde sehr gut zu einer falschen mtu size passen.
Könntest Du das bitte noch einmal wiederholen und vor dem Update den Output von "sudo /sbin/ifconfig" (ohne Parameter) und "sudo /sbin/route -n" kopieren und anschiessend posten?
Hi,
danke für deine Aufmerksamkeit ich hatte es extra editiert da es ja gerade nicht die beschriebene Vorgehensweise war, sorry dafür.
root@raspberrypi:~# sudo /sbin/ifconfig eth0 mtu 1000
root@raspberrypi:~# sudo /sbin/ifconfig
eth0 Link encap:Ethernet Hardware Adresse b8:27:eb:1e:ff:ac
inet Adresse:192.168.1.101 Bcast:192.168.1.255 Maske:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1000 Metrik:1
RX packets:76667 errors:0 dropped:0 overruns:0 frame:0
TX packets:53111 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:8890511 (8.4 MiB) TX bytes:3762299 (3.5 MiB)
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metrik:1
RX packets:853 errors:0 dropped:0 overruns:0 frame:0
TX packets:853 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:70426 (68.7 KiB) TX bytes:70426 (68.7 KiB)
root@raspberrypi:~# sudo /sbin/route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Kein reboot des Systems und update befehl ausgeführt im FHEM backend selber fehler...
Was passiert, wenn du in FHEM/HttpUtils.pm Zeile 103, timeout erhoehst, von 4 auf z.Bsp. 15 Sekunden?
Zitat von: rudolfkoenig am 19 August 2015, 18:56:53
Was passiert, wenn du in FHEM/HttpUtils.pm Zeile 103, timeout erhoehst, von 4 auf z.Bsp. 15 Sekunden?
Ich habe das mal ausprobiert. Der Timeout Wert wird dann durch das Update selbst wieder überschrieben wenn ich das richtig sehe, oder?
Im Gegensatz zu manch anderen bricht bei mir das Update immer bei der folgenden Stelle ab:
2015.08.19 20:12:44 1: UPD www/images/openautomation/phone_ring_in.svg
Edit: FHEM hängt danach und ich muss den Prozess abschiessen und neu starten!
Mit welcher Fehlermeldung bricht es ab?
Wieso haengt FHEM, wenn update abbricht?
Laeuft bei dir update nicht in Background? Wenn nein, wieso nicht?
Zitat von: rudolfkoenig am 19 August 2015, 20:35:18
Mit welcher Fehlermeldung bricht es ab?
Wieso haengt FHEM, wenn update abbricht?
Laeuft bei dir update nicht in Background? Wenn nein, wieso nicht?
Keine Fehlermeldung, friert ein!
Background Update habe ich eben eingeschaltet (hatte ich testweise ausgeschaltet)
Test läuft nun.....
Nun es hört einfach auf! Sieht so aus, als ob der Update Prozess einfach stirbt!
2015.08.19 20:47:58 1: UPD www/images/openautomation/phone_call_out.svg
2015.08.19 20:47:58 1: UPD www/images/openautomation/phone_dial.svg
2015.08.19 20:47:59 1: UPD www/images/openautomation/phone_missed_in.svg
2015.08.19 20:47:59 1: UPD www/images/openautomation/phone_missed_out.svg
2015.08.19 20:47:59 1: UPD www/images/openautomation/phone_ring.svg
2015.08.19 20:47:59 1: UPD www/images/openautomation/phone_ring_in.svg
Noch mal mit verbose 5
2015.08.19 20:54:40 1: UPD www/images/openautomation/phone_ring.svg
2015.08.19 20:54:40 4: http://fhem.de/fhemupdate/www/images/openautomation/phone_ring.svg: HTTP response code 200
2015.08.19 20:54:40 4: HttpUtils http://fhem.de/fhemupdate/www/images/openautomation/phone_ring.svg: Got data, length: 2155
2015.08.19 20:54:40 5: Cmd: >{DoTrigger('global','UPD www/images/openautomation/phone_ring_in.svg','1')}<
2015.08.19 20:54:40 5: Triggering global (1 changes)
2015.08.19 20:54:40 4: HttpUtils url=http://fhem.de/fhemupdate/www/images/openautomation/phone_ring_in.svg
2015.08.19 20:54:40 5: Notify loop for global UPD www/images/openautomation/phone_ring_in.svg
2015.08.19 20:54:40 5: Cmd: >{Log('1','UPD www/images/openautomation/phone_ring_in.svg')}<
2015.08.19 20:54:40 1: UPD www/images/openautomation/phone_ring_in.svg
2015.08.19 20:54:41 4: http://fhem.de/fhemupdate/www/images/openautomation/phone_ring_in.svg: HTTP response code 200
2015.08.19 20:54:41 4: HttpUtils http://fhem.de/fhemupdate/www/images/openautomation/phone_ring_in.svg: Got data, length: 2917
2015.08.19 20:55:01 4: Closing inactive connection FHEMWEB:127.0.0.1:54895
2015.08.19 20:55:01 4: Connection accepted from FHEMWEB:127.0.0.1:55546
2015.08.19 20:55:01 4: HTTP FHEMWEB:127.0.0.1:55546 GET /fhem/rss/FrameRSS.jpg
2015.08.19 20:55:01 4: 2734:FHEMWEB:127.0.0.1:55546: /fhem/rss/FrameRSS.jpg / RL:5931 / image/jpeg; charset=utf-8 / /
2015.08.19 20:55:01 4: HTTP FHEMWEB:127.0.0.1:55546 GET /fhem/rss/.directory
2015.08.19 20:55:01 4: 2734:FHEMWEB:127.0.0.1:55546: /fhem/rss/.directory / RL:689 / text/html; charset=utf-8 / /
Nur zur Info, habe gerade mal ein update gemacht (das "Große", nach dem SVN Crash) und das lief vollkommen problemlos durch. Config: ADSL 25000, Telekom, FritzBox 7390, fhem 5.6 auf ZBOX nano.
VG
Frank
Auf meinem Cubie und der Fritte läuft das Update auch problemlos durch!
Ich habe HttpUtils.pm/98_update.pm erweitert, damit es "Connection: keep-alive" unterstuetzt.
Damit braucht das volle update (1545 Dateien/18MB) statt 100 Sekunden nur noch 50 auf meinem Rechner. Bei gesetzten keepalive unterbricht fhem.de nach 200 GETs die Verbindung, die Funktion fuehrt deswegen ein reconnect durch, wenn Dateien vorher erfolgreich geholt wurden.
Andere Modulauthoren koennen dieses Feature mit HttpUtils_BlockingGet oder HttpUtils_NonblockingGet verwenden, indem man $hash->{keepalive}=1 setzt. Zum Schluss sollte man HttpUtils_Close($hash) aufrufen.
Ich habe auch angefangen "Accept-Encoding: gzip,deflate" zu unterstuetzen, zu meinem grossen Erstaunen unterstuetzt fhem.de keine Komprimierung, siehe:
curl -I -H 'Accept-Encoding: gzip,deflate' http://fhem.de/fhemupdate/controls_fhem.txt
und ich kriege es mit den ueblichen .htaccess Methoden auch nicht eingeschaltet. Hat irgendwer eine Idee, wieso? Die compress-Implementierung in HttpUtils ist deswegen noch unvollstaendig, bitte nicht wundern.
Weißt Du, was alles per .htaccess auf dem Server einstellbar ist? bzw. kommst Du an i "Globale" Apache-config? Lesbar reicht.
Sonst ist Deine Anfrage schlecht beantwortbar :o(
Zitat von: rudolfkoenig am 20 August 2015, 19:18:28
Ich habe auch angefangen "Accept-Encoding: gzip,deflate" zu unterstuetzen, zu meinem grossen Erstaunen unterstuetzt fhem.de keine Komprimierung, siehe:
curl -I -H 'Accept-Encoding: gzip,deflate' http://fhem.de/fhemupdate/controls_fhem.txt
und ich kriege es mit den ueblichen .htaccess Methoden auch nicht eingeschaltet. Hat irgendwer eine Idee, wieso? Die compress-Implementierung in HttpUtils ist deswegen noch unvollstaendig, bitte nicht wundern.
Hallo Rudolf,
das deflate Modul ist ja bestimmt geladen?
Falls ja wie hast du es über die htaccess aktiviert?
Auf meinem Apache funktioniert folgende Direktive, welche du mal probieren könntest falls es bei dir anderst aussieht:
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript application/x-httpd-php
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
Header append Vary User-Agent env=!dont-vary
Zitatcurl -I -H 'Accept-Encoding: gzip,deflate' http://x0e.de/fhem.html
curl -I -H 'Accept-Encoding: gzip,deflate' http://x0e.de/controls_fhem.txt
Gruß
Claudiu
Zitatdas deflate Modul ist ja bestimmt geladen?
Wenn ich das wuesste.
ZitatFalls ja wie hast du es über die htaccess aktiviert?
# Enable GZIP
<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
# AddOutputFilterByType DEFLATE text/html text/css text/plain text/x-perl image/svg+xml text/css application/x-javascript application/javascript
</ifmodule>
Ich habe auch mit den langen Versionen schon experimentiert, mit und ohne BrowserMatch und Header Zeilen, oder exakt die Version von Claudiu, kein Unterschied. Und ich dachte, gzip ist an per default.
Zitatkommst Du an i "Globale" Apache-config?
Wuesste nicht wie. Habe auch bei 1und1 schon eine Anfrage gestellt.
O.K. also "reiner" VHost.
mal sehen was 1&1 antwortet, aber ich glaube das modul ist deaktiviert ...
Ja, hört sich wirklich so an als ob das Modul nicht geladen ist.
Du könntest das z.B. hierüber feststellen:
<IfModule mod_deflate.c>
Header set IsModuleLoaded "module loaded"
</IfModule>
<IfModule !mod_deflate.c>
Header set IsModuleLoaded "module not loaded"
</IfModule>
Anschließend sollte bei einer curl -I -H abfrage 'IsModuleLoaded' entsprechend gesetzt sein. (Ansonsten liegt noch irgendwo anders ein Problem vor)
Selber über reinen htaccess Zugriff nachladen ist leider nicht möglich :-(
Gruß
Claudiu
% curl -I -H 'Accept-Encoding: gzip,deflate' http://fhem.de/fhemupdate/controls_fhem.txt
HTTP/1.1 200 OK
Date: Thu, 20 Aug 2015 20:50:11 GMT
Server: Apache
Last-Modified: Thu, 20 Aug 2015 05:45:18 GMT
Accept-Ranges: bytes
Content-Length: 101947
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
IsModuleLoaded: module not loaded
Content-Type: text/plain
Na dann warten wir auf dem naechsten Server.
Mit keepalive dasgleiche Problem bei mir!
Aber!
fhem@raspberrypi:~/www/images/openautomation$ ls -l phone_ring*
prw-r--r-- 1 fhem dialout 0 Dez 22 2015 phone_ring_in.svg
srw-r--r-- 1 fhem dialout 0 Sep 1 2005 phone_ring_out.svg
-rw-r--r-- 1 fhem dialout 2155 Aug 21 19:20 phone_ring.svg
fhem@raspberrypi:~/www/images/openautomation$
UPDATE
Nach dem Löschen der 0 Byte Dateien lief das Update durch! Vermutlich ein FS Problem, oder?
Ich glaube bei mir ist es ein FS Problem! Ich lösche die beiden Dateien mal und dann schauen wir weiter!
Zitat von: rudolfkoenig am 20 August 2015, 19:18:28
Ich habe HttpUtils.pm/98_update.pm erweitert, damit es "Connection: keep-alive" unterstuetzt.
Damit braucht das volle update (1545 Dateien/18MB) statt 100 Sekunden nur noch 50 auf meinem Rechner. Bei gesetzten keepalive unterbricht fhem.de nach 200 GETs die Verbindung, die Funktion fuehrt deswegen ein reconnect durch, wenn Dateien vorher erfolgreich geholt wurden.
Andere Modulauthoren koennen dieses Feature mit HttpUtils_BlockingGet oder HttpUtils_NonblockingGet verwenden, indem man $hash->{keepalive}=1 setzt. Zum Schluss sollte man HttpUtils_Close($hash) aufrufen.
Ich habe auch angefangen "Accept-Encoding: gzip,deflate" zu unterstuetzen, zu meinem grossen Erstaunen unterstuetzt fhem.de keine Komprimierung, siehe:
curl -I -H 'Accept-Encoding: gzip,deflate' http://fhem.de/fhemupdate/controls_fhem.txt
und ich kriege es mit den ueblichen .htaccess Methoden auch nicht eingeschaltet. Hat irgendwer eine Idee, wieso? Die compress-Implementierung in HttpUtils ist deswegen noch unvollstaendig, bitte nicht wundern.
Hallo Rudi,
vielen Dank dafür, nur leider kann man den Keep-Alive Mechanismus nicht "Non-Blocking" verwenden. Insbesonders wenn man mehrere Requests nacheinander stellen will. In meinem Fall sende ich immer POST-Requests mit XML-Daten ab. Den HTTP-Parameter-Hash reiche ich dabei mit Zusatzinformationen an um am Ende bei der Bearbeitung durch die Callback-Funktion zu wissen wofür die Antwort eigentlich ist.
Wenn ich nun in einer Funktion mehrere HTTP Requests mit aktiviertem KeepAlive absetzen will, gerät der Parameter-Hash, den ich ja an einer zentralen Stelle im Device-Hash speichere, in eine Inkonsistenz weil ja die Werte vom vorhergehenden Request schonwieder überschrieben sind usw.
Beim Aufruf der Callback-Funktion bekomme ich ja dann die bereits mehrfach überschriebenen Daten zurück, die aber gar nicht mehr zu dem ursprünglichen Request passen.
Oder sehe ich da was falsch?
Gruß
Markus
Zitat
Wenn ich nun in einer Funktion mehrere HTTP Requests mit aktiviertem KeepAlive absetzen will, gerät der Parameter-Hash, den ich ja an einer zentralen Stelle im Device-Hash speichere, in eine Inkonsistenz weil ja die Werte vom vorhergehenden Request schonwieder überschrieben sind usw.
Ich meine das hat nichts mit keepalive zu tun: wenn man mehrere Requests parallelel absetzt (geht nur bei Nonblocking), dann muss man immer unterschiedliche Parameterbloecke (hash) verwenden, sonst werden die Daten ($conn, etc) ueberschrieben. Es mag aber sein, dass diese Probleme erst beim gesetzten keepalive merkbar werden.
mit dem aktuellen 98_update.pm stirbt mein fhem bei Verbindungsproblemen.
Zitat2015.08.23 11:18:13 1: http://fhem.de/fhemupdate/controls_fhem.txt (http://fhem.de/fhemupdate/controls_fhem.txt): Can't connect(1) to http://fhem.de:80 (http://fhem.de:80): IO::Socket::INET: connect: Connection refused
Can't call method "close" on an undefined value at FHEM/HttpUtils.pm line 65.
"Connection refused" kann ich nicht erklaeren. Die Warnung danach habe ich gerade behoben.
Das "Connection refused" hängt wohl mit meiner powerline verbindung zusammen. Da hat auch hmlan hin und wieder einen Disconnect.
Hallo,
dank dem Forum konnte ich FHEM ohne besondere Vorkenntnisse auf einem Raspberry Pi installlieren. Leider leide auch ich unter dem "timeout" Problem beim Update. Ich habe jetzt schon alle möglichen Hinweise und Tips aus diesem Forum versucht (update script, modifizierte 98_update.pm, manuelles update...) Bisher alles ohne Erfolg! Ich bekomme immer wieder die "timeout" Meldung.
Internet über Unitymedia mit Fritzbox Cable (6340). Heute war ein Techniker von Unitymedia bei mir. Dieser sagte dass alles bestens ist.
Kann mir jemand helfen? Was kann ich nocht tun. Seit 2 Wochen habe ich die ganze zu steuernde Hardware (Schalter, Sensoren, Heizungsthermostate) angehängt und komme mit Fhem nicht weiter weil ich nach der Installation kein Update durchführen kann.
Danke schonmal im Voraus!
@Boernie,
- du könntest etwas mehr dazu sagen wie GENAU du jeweils vorgegangen bist.
- du kannst dir falls alles nichts hilft fhem manuell aus dem svn laden, und anschließend schauen ob das nächste update mit einem aktuellen fhem funktioniert.
Gruß
Claudiu
so bin ich vorgangen:
1. Fhem auf Raspian installiert. Update gestartet und die bekannte "timeout" Fhelermeldung erhalten. Fhem lief dann nicht mehr. Neuinstallation und direkt ein backup und dann ein update durchgeführt. Fehler beim Update unverändert.
2. restore backup. Diesmal habe ich versucht die einzelnen backups gem. "update check" einzeln durchzuführen. Nach wenigen updates kam wieder ein "timeout". Auch nach einer neuinstallation hat es nicht geklappt.
3. Das Script aus diesem Forum mit root rechten durchgeführt. Ergebnis siehe "http://forum.fhem.de/index.php?topic=33481.0".
4. Neuinstallation und als erstes "update 98_update.pm" durchgeführt. Nach "shutdown restart" lief Fhem nicht mehr (mehrfach versucht)
5. Die am Anfang von diesem Threat erwähnte angepasste 98_update.pm nach einer Neuinstallation von Fhem im Verzeichnis opt/fhem/FHEM durch die vorhandene Datei ersetzt. Update funktionier noch immer nicht.
An dieser Stelle bitte nochmals um Rücksicht für evtl. dumme Fehler. Ich bin wie gesagt Anfänger. Danke!
Betreffend "fhem manuell aus dem svn laden" muss ich gestehen, dass ich nicht weiss wie ich dazu vorgehen muss. Damit werde ich mich am kommenden WE beschäftigen und berichten.
Danke!
Hmm, hört sich tatsächlich seltsam an...
Ich denke am einfachsten machst du es über diesen Link https://sourceforge.net/p/fhem/code/HEAD/tarball (https://sourceforge.net/p/fhem/code/HEAD/tarball)
Darüber kannst du das aktuellste fhem als zip-package runterladen,
dann einfach mal an die richtige stelle entpacken (evtl. noch Dateisystemberechtigungen setzen) und schauen obs gut is :)
Ich hatte vor wenigen Tagen mit
"sudo wget http://fhem.de/fhem-5.6.deb && sudo dpkg -i fhem-5.6.deb"
FHEM installiert. Das sollte doch dann die neueste Version sein oder?
Gerne würde ich es mit der Version gem. dem Downloadlink versuchen. Ich weiss aber ehrlich gesagt nicht wie ich das so in Raspbian installieren kann.
Ich habe mittlerweile Raspbian und Fhem 5.6 auf einer zweiten Karte komplett neu installiert. Beim Update erhalte ich immer wieder diese "timeout" Fehlermeldung. Auch habe ich den Raspberry bei meinem Bruder angeschlossen (auch Unitymedia aber ohne Fritzbox). Auch dort erhielt ich die timeout Meldung.
Wenn die FHEM Version gem. dem Link abhilfe schaffen kann, so wäre ich über ein kurzes "how-to" zur installation auf Raspbian sehr dankbar.
Vielen Dank! Ich gebe die Hoffnung nicht auf irgendwann ein update mit Eurer Hilfe durchführen zu können!
Nein, wie du hier http://fhem.de/fhem_DE.html (http://fhem.de/fhem_DE.html) lesen kannst, hast du die Version vom 2014-11-09 damit installiert.
Du lädst einfach das *.zip Package auf deinem raspi heruntern, unzip'st es, und fertig.
Mit dem Inhalt des un'gezipt'en package, also den "fhem"-Ordner kannst du einfach deine bisherige Installation (deinen bisherigen "fhem"-Ordner) überschreiben, damit hast du dann ein vollständiges Update gemacht und bist auf der aktuellen Version
Danke! So habe ich jetzt in den Griff bekommen:
Auch mit der neuesten FHEM Version ging das update nicht. Aber ein einzelnes update 98_update.pm hat nun gegenüber der älteren Version geholfen.
Jetzt funktioniert es endlich! Danke für die wirkliche gute Unterstützung!