Hallo,
ich habe ein Problem mit dem update über eine eigene controls Datei.
Ehrlich gesagt, bin ich ziemlich ratlos. Ich vermute es liegt an einem Fehler im httpsutils Modul aber so ganz sicher bin ich mir nicht.
Folgendes wird in FHEM aufgerufen:
update force https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/controls_signalduino.txt
In FHEM erscheint dann:
UPD FHEM/14_SIGNALduino_AS.pm
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
: empty file received
Den Link kann ich problemlos im Browser öffnen. Die Datei hat Daten.
Mit wget und curl bekomme ich die Datei auch auf meinem Raspberry Pi.
Auf der Konsole (getestet unter Windows) erscheint folgendes:
2015.09.06 22:30:57 4: HttpUtils url=https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/controls_signalduino.txt
2015.09.06 22:30:58 1: PERL WARNING: Use of uninitialized value in bitwise or (|) at Z:/Programme/perl/lib/IO/Socket/SSL.pm line 2181.
2015.09.06 22:31:00 4: https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/controls_signalduino.txt: HTTP response code 200
2015.09.06 22:31:00 4: HttpUtils https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/controls_signalduino.txt: Got data, length: 702
2015.09.06 22:31:00 4: Got remote controlfile with 12 entries.
2015.09.06 22:31:00 4: HttpUtils url=https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/CHANGED
2015.09.06 22:31:00 4: https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/CHANGED: HTTP response code 200
2015.09.06 22:31:00 4: HttpUtils https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/CHANGED: Got data, length: 2890
2015.09.06 22:31:00 1: UPD FHEM/14_SIGNALduino_AS.pm
2015.09.06 22:31:00 4: HttpUtils url=https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
: HTTP response code 400ttps://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
: Got data, length: 0: HttpUtils https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
: Zero length data, header follows:tps://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
: empty file received: https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/FHEM/14_SIGNALduino_AS.pm
2015.09.06 22:31:00 4: 19136:FHEMWEB:127.0.0.1:65329: /fhem&cmd=update+force+https%3A%2F%2Fraw.githubusercontent.com%2FRFD-FHEM%2FRFFHEM%2Fdev-cresta%2Fcontrols_signalduino.txt / RL:1236 / text/html; charset=UTF-8 / Content-Encoding: gzip
Irgendwie kann er also die Daten im Ordner FHEM nicht laden, bzw. mit dem Request stimmt was nicht, da der Server ja mit einem Code 400 antwortet.
Ich habe einfach keine Idee, woran es liegt. In einem anderen Branch habe ich eine funktionierende Konstellation. Prinzipiell ist mein Aufruf also nicht falsch.
Da ich nicht alleine mit dem Fehler bin, liegt es wohl nicht an meinen Systemen. Ich vermute den Fehler irgendwo in der controls Datei oder aber im httputils Modul.
Grüße Sidey
Statt force wuerde ich all verwenden, ist weniger martialisch.
Sonst handelt es sich um ein DOS-Line-Ending Problem in der control-Datei.
Hallo Rudolf,
jo verstehe... Zeilenumbruch.
Hmm, könnte man durch ne kleine Regex ja heraus filtern oder was meinst Du?
Grüße Sidey
Ich meine, dass CR+NL in FHEM nichts zu suchen hat. :)
Ja, habe ich gemerkt, aber httputils filtert aktuell nicht auf valide Zeichen in einer URL... :)
Hallo,
Obwohl ich die control Datei jetzt über ein Perl Script erstelle, läuft perl unter windows dann erzeugt es \r\n als Zeilenumbruch.
Da Perl aber beim Einlesen durchaus so schlau ist, beides als Zeilenumbruch erkennen zu können, schlage ich folgenden Patch vor um Update etwas robuster zu machen.
Grüße Sidey
Du brauchst doch in Deinem Skript einfach nur mit binmode zu arbeiten, dann klappts auch unter Windows *würg* mit den Zeilenumbrüchen.
Hallo Betateilchen,
okay das mit binmode funktioniert, das war mir so nicht bewusst.
Ich denke der Patch ist aber trotzdem nicht verkehrt.
Grüße Sidey
Doch, es ermutigt naemlich auch im Quellcode das einfuegen von DOS-Zeilenenden, was erstens in meinem Editor haesslich aussieht, und zweitens eine weitere Fehlerusache ist. Meiner Ansicht nach kann man einem Entwickler zumuten, Dateien ohne DOS-Zeilenenden zu produzieren, bei den FHEM-Modulen wird das auch untersagt.
Moin,
ich weiss nicht, wieso es jemanden ermutigt etwas verkehrt zu machen, wenn ein Programm etwas Fehler toleranter ist. Ich hatte es eher als Feature gesehen.
Mir war auch nicht bewusst, dass man keine Windows line Endings in irgend einer Art und weise mit Fhem verarbeiten soll. Bzw, dass man solche Daten gar nicht erst abfragen soll.
Ich habe einen Vorschlag gemacht, da ich nicht wusste, dass CR NL ein Problem Darstellen.
Eine Log Ausgabe mit dem Hinweis CR LF ist nicht supportet hätte mir sicher auch geholfen. Vielleicht steht es auch irgendwo im Wiki, aber den Punkt habe ich dann wohl übersehen. :(
Ich habe mir jetzt einen Workaround geschaffen und schreibe direkt mittels bin mode in eine Datei. Über die Umleitung der Konsole in eine Datei geht es ja unter Windows nicht.
Ich brauche den Patch nicht mehr, da ich mir mittlerweile der Problematik bewusst geworden bin und die Daten, welche ich für den HTTP Get bereitstelle angepasst habe.
Die Festlegung "CR NL ist nicht erlaubt" kommt mir aber schon etwas komisch vorkommt, da FHEM ja durchaus auch unter Windows funktioniert und die controls Datei von extern geladen wird.
Folgende Zeile aus 98_Update verstehe ich in dem Zusammenhang dann aber nicht mehr:
@locList = map { $_ =~ s/[\r\n]//; $_ } <FD>;
Wenn ich nicht ganz falsch liege, dann wird entweder doch was mit CR LN abgelegt, oder die Zeile ist nicht ganz korrekt.
Mag aber auch sein, das ich hier auf dem Schlauch stehe.
Grüße Sven
Es geht nicht darum, dass FHEM unter Windows nicht funktionieren soll, sondern darum, dass _Entwickler_ ProgrammCode nicht beliebig gestalten sollen. Die erwaehnte Zeile stammt vom vorherigen Modul-Maintainer, der offensichtlich meine Marotte nicht hatte, weiterhin liest sie lokale Dateien ein, die evtl. ein Benutzer unter Windows angefasst haben koennte. Wg. der fehlenden Fehlermeldung: ich weiss nicht genau, wieviele Leute, die fuer FHEM ThirdParty Module anbieten unter Windows arbeiten. Ich tippe auf eins. Der hat wiederum diese Marotte jetzt mitgekriegt.
Hi,
ich lese erstaunt mit, betrifft mich auch.
Bisher habe ich mich über gelegentliche, seltene, gleich lautende, Berichte gewundert und das immer als fhem-update Unzulänglichkeit abgetan ohne die Ursache zu kennen. Generell arbeite ich unter linux, benutze aber gelegentlich auch Orionhub.
Fehlerbild: "empty file received" (oder so) - im Browser wird dir control datei angezeigt.
Für die unter linux erstellten commits sollte das also eigentlich nicht die Ursache sein - das müsste man dann doch untersuchen ...
Auf Orionhub habe ich keinen Einfluss. Da ich auch selber die updates dann so beziehe und den Fehler (linux host(s) fhem) nicht erhalte ist doch vielleicht noch mehr. (?)
Ich würde es eigentlich ganz gut finden fhem-update in dieser Beziehung doch etwas zu "härten". Sind da Nachteile / Nebeneffekte zu erwarten ?
vg
joerg
Es geht hier um die (sinnvollerweise automatisch generierte) Datei controls.txt, welcher mAn nicht mit CR/NL verunstaltet sein sollte.
Wenn man die Generierung der Datei nicht unter Kontrolle hat, dann macht man mAn was falsch.
Aber bevor mir diese Diskussion zuviel Energie kostet, habe ich den von Sven vorgeschlagenen Patch eingespielt.
ja, hast recht. Danke.
Irgendwas (Bauchgefühl) sagt mir das da vmtl noch was ist. Bei mir lief das update immer was ja dann garnicht so gewesen sein dürfte ..
Ich warte mal ob nochmal Berichte dazu auftreten dann kann man ja nochmal graben :)
danke und vg
joerg
Zitat von: rudolfkoenig am 13 September 2015, 11:01:07
Meiner Ansicht nach kann man einem Entwickler zumuten, Dateien ohne DOS-Zeilenenden zu produzieren, bei den FHEM-Modulen wird das auch untersagt.
*unterschreib*
Es ist m.E. nicht die Aufgabe von fhem, jeden Mist, den irgendjemand ausserhalb von fhem produziert, wieder gradezubiegen.
Zitat von: rudolfkoenig am 13 September 2015, 12:43:35
Aber bevor mir diese Diskussion zuviel Energie kostet, habe ich den von Sven vorgeschlagenen Patch eingespielt.
Sehr bedauerlich.
ruhig Brauner. :)
a: Die Konvention ist völlig in Ordnung, sie war, zumindest mir, nicht so transparent.
b: natürlich darf fhem unterschiedliche Rahmenbedingungen gut behandelt, die Welt ist nicht nur Schwarz Weiß und DOS Konventionen sind, ob man das mag oder nicht, in der Welt. Wir alle (die meisten ? ;) ) wollen ein gut funktionierendes fhem. Alles Ausnahmen die fhem von sich aus behandelt sind eben kein support call hier. Ist ja auch schön.
c: lass uns die Grundsatzdiskussion beiseite legen, die lenkt nur von Thema ab. Da vermute ich, wie bereits geschrieben, noch offene Punkte weil:
Grundsätzlich "linuxe" ich, daher sollte mich das eigentlich kalt lassen. Tatsächlich habe ich aber schon vereinzelt solche Fehlerberichte erhalten, sollten wir im Auge behalten und dann einfach lösen :)
vg
joerg
Hi,
was habe ich da nur angestellt.
Ich sehr den von mir eingestellten Patch mittlerweile selbst etwas skeptisch.
Allerdings macht er ja nichts kaputt.
Ich habe jetzt noch mal über das Grundproblem nachgedacht.... Ich hatte Daten mit einem nicht supportetem Line Feed übergeben. Das führe dann dazu, dass die URL ein \r Zeichen enthielt.
Im httputils Modul gibt es eine Regex, die auf valide URLs prüft.
Im Netz habe ich eine wesentlich komplexere Variante gefunden:
^(http(?:s)?\:\/\/[a-zA-Z0-9]+(?:(?:\.|\-)[a-zA-Z0-9]+)+(?:\:\d+)?(?:\/[\w\-]+)*(?:\/?|\/\w+\.[a-zA-Z]{2,4}(?:\?[\w]+\=[\w\-]+)?)?(?:\&[\w]+\=[\w\-]+)*)$
Ich bin jetzt nicht der Regex Spezi, aber wenn am Ende ein \r teil der URL ist, dann ist das keine gültige URL nach RFC, denke ich.
Vielleicht ist Ziel führender, die Prüfung auf eine valide URL im httputils Modul zu erweitern.
Die oben gepostete Regex wird das aber wohl auch nicht erkennen vermute ich.
Grüße Sven