Neue Version von HTTPMOD mit neuen Features zum Testen

[StefanStrobel]

Hi Ronny,

Kann ich das alles in ein Define stecken?
Nehme ich dafür set01Data, set02Data (um das Input Field eines vorherigen Requests zu nutzen)? Werden die nacheinander abgearbeitet?
Ist set01Data genau so zu benutzen wie requestData?
Muss ich dann für jedes set einen Header (Content-Type etc.) set01Header etc. bauen, auch wenn der gleich ist?
Kann ich das extrahierte Input irgendwie on-the-fly als url-encoded abspeichern zur weiteren Nutzung?

die Attribute set01... gehören zum ersten Set. set02 zu einem zweiten Set.
Wenn Du die POST-Daten für den ersten Set auf mehrere Attribute verteilen möchtest, kannst Du set01Data01, set01Data02 etc. verwenden, Die werden verkettet.
set01Data wird ansonsten wie requestData verwendet, gilt aber für den Set-Befehl.
Um die Header nicht immer wieder zu kopieren kannst Du auch statt set01Header setHeader verwenden. Diese Attribute werden dann für alle Sets verwendet.
Speichern in einer Datei habe ich eigentlich nicht vorgesehen. Die Idee wäre eher die relevanten Daten eines früheren Requets in Readings zu legen und beim nächsten Request über die Replacement-Attribute wieder einzubauen.

Gruss / viel Erfolg
   Stefan

[ares]

Gibt es die Möglichkeit mit einem attribut HTTPMOD zu sagen, dass es nur einen Teil einer HTTP-Seite abrufen soll? Ich möchte eine Webseite parsen, die ziemlich lang ist, benötige aber eigentlich nur die ersten 2kbyte. Optimal wäre, wenn ich ihm sagen könnte, er soll nur die ersten 2 kbyte abrufen...

Hallo FhemPiUser,

so eine Möglichkeit gibt es derzeit nicht.

Gruss
    Stefan

Hallo Stefan,

an langen HTTP-Seiten stört mich aktuell eher das laaaaaange Internal buf.
Kann man das vielleicht ohne großen Aufwand optional "nicht" bzw. mit ".buf" statt "buf" speichern oder hast Du andere Vorschläge für eine kürzere Anzeige?

Viele Grüße
Manfred

[BillyPbg]

Code Auswählen Erweitern

[quote author=StefanStrobel link=topic=45176.msg608865#msg608865 date=1490046826]
...
ich verstehe zwar nicht was Dein Abfallkalender mit HTTPMOD zu tun hat,
aber spontan würde ich die entsprechenden Zeilen in Deine MyUtils.pm fixen.
...


Hallo Stefan,

was HTTPMOD mit dem ('MUELL'-)Calendar-Modul zu tun hat, versteh' ich auch nicht.
Ich kann Dir jedoch mein Recherche-Ergebnis mitteilen...

Nachdem ich nicht vom Fach bin, habe ich nach der Methode "Try and Error", unterstützt durch 'Winmerge' das Folgende herausgefunden:

Die Meldungen werden ausgelöst, unabhägig voneinander, in Zeile 473, 503, 539 und 1685:  Jeweils " $SIG{__WARN__} = 'DEFAULT'; " (Siehe Anlage, mit '#Bi' versehene Zeilen)
Seitdem ich diese Zeilen ausge-'#' hatte, war alles unauffällig.
Ich hoffe, Du kannst damit was anfangen...

Wenn ich Dir mit weiteren Zulieferungen zum Nachbau weiterhelfen kann, gerne.

VG.
BillyPbg

PS:
Danke für Deinen Fix-Vorschlag, wurde sofort umgesetzt, hatte aber keine Auswirkung auf das Fehlerbild.

[StefanStrobel]

Hallo,

das ist vermutlich die falsche Stelle.
Ich definiere vor der Evaluation von Perl-Code aus Attributen einen eigenen Handler für Warnings um eben diese Warnings besser ins Log zu packen. Direkt danach setze ich den Handler zurück auf Default.
Wenn Du diese Zeilen auskommentierst ist es klar dass die Warnings nach wie vor abgefangen werden. Damit bekämpfst Du aber nur das Symptom und nicht die Ursache...

Wenn Du wie von mir empfohlen den Code in Deiner MyUtils an allen relevanten Stellen änderst, so dass ein undef als Rückgabewert des Get-Aufrufs erkannt wird, wäre das am saubersten.
Die Änderung in Zeile 411 alleine reicht natürlich noch nicht.

Gruss
    Stefan

[StefanStrobel]

Hallo Manfred,

wegen der langen Anzeige von buf werde ich mir was überlegen.

Gruss
   Stefan

[JoeALLb]

Hallo Manfred,

wegen der langen Anzeige von buf werde ich mir was überlegen.

Gruss
   Stefan

An diesen Wunsch hänge ich mit dran, mein buf bringt einen Handybrowser zum Absturz.

Danke, SG Joe

[FHEMAN]

Hi Ronny,

die Attribute set01... gehören zum ersten Set. set02 zu einem zweiten Set.
Wenn Du die POST-Daten für den ersten Set auf mehrere Attribute verteilen möchtest, kannst Du set01Data01, set01Data02 etc. verwenden, Die werden verkettet.
set01Data wird ansonsten wie requestData verwendet, gilt aber für den Set-Befehl.
Um die Header nicht immer wieder zu kopieren kannst Du auch statt set01Header setHeader verwenden. Diese Attribute werden dann für alle Sets verwendet.
Speichern in einer Datei habe ich eigentlich nicht vorgesehen. Die Idee wäre eher die relevanten Daten eines früheren Requets in Readings zu legen und beim nächsten Request über die Replacement-Attribute wieder einzubauen.

Gruss / viel Erfolg
   Stefan

Okay, ich habe es nun in zwei separate Defines gepackt und lese die Readings mit notify aus. Das klappt ganz gut.
Nun ist es so, dass wenn ein readingXRegex nicht matcht, dass dann trotzdem etwas im Reading stehen bleibt. Ich würde es gerne leer haben, um mit einem Event darauf zu reagieren. Also wenn die Seite nichts anzeigt, dann soll das Reading gelöscht werden.
Gibt es dafür eine Einstellung?

Viele Grüße
Ronny

PS: Schöner Timestamp übrigens von Deinem Posting

[ares]

Hallo Ronny,

hast Du MaxAgeReplacementMode "delete" schon versucht?
https://wiki.fhem.de/wiki/HTTPMOD#replacing_reading_values_when_they_have_not_been_updated_.2F_the_device_did_not_respond

Viele Grüße
Manfred

[frank]

Okay, ich habe es nun in zwei separate Defines gepackt und lese die Readings mit notify aus. Das klappt ganz gut.
Nun ist es so, dass wenn ein readingXRegex nicht matcht, dass dann trotzdem etwas im Reading stehen bleibt. Ich würde es gerne leer haben, um mit einem Event darauf zu reagieren. Also wenn die Seite nichts anzeigt, dann soll das Reading gelöscht werden.
Gibt es dafür eine Einstellung?

get|reading[0-9]*DeleteIfUnmatched
If set to 1 this attribute causes certain readings to be deleted when the parsing of the website does not match the specified reading. Internally HTTPMOD remembers which kind of operation created a reading (update, Get01, Get02 and so on). Specified readings will only be deleted if the same operation does not parse this reading again. This is especially useful for parsing that creates several matches / readings and this number of matches can vary from request to request. For example if reading01Regex creates 4 readings in one update cycle and in the next cycle it only matches two times then the readings containing the remaining values from the last round will be deleted.
Please note that this mechanism will not work in all cases after a restart. Especially when a get definition does not contain its own parsing definition but ExtractAllJSON or relies on HTTPMOD to use all defined reading.* attributes to parse the responsee to a get command, old readings might not be deleted after a restart of fhem.

[mahowi]

Kann ich eigentlich auch irgendwie ein "HTTP DELETE" mit HTTPMOD abschicken? Ich kann bei meiner Heizungssteuerung (tado°) per PUT in den manuellen Modus mit einer bestimmten Temperatur schalten. Um aber wieder in den Automatikmodus zu gehen, muß ich die manuelle Kontrolle per "DELETE" wieder löschen. Die Beschreibung gibt es unter /api/v2/homes/<homeID>/zones/1/overlay auf The Tado API v2 in Stephen C Phillips' Blog.

Weiß dafür jemand ne Antwort? Oder vielleicht eine Möglichkeit, das mit FHEM Mitteln anders zu machen?

[frank]

Weiß dafür jemand ne Antwort? Oder vielleicht eine Möglichkeit, das mit FHEM Mitteln anders zu machen?

hast du mal versucht den angegebenen curl-befehl auf perl-ebene mit dem befehl system oder qx zu senden?

[mahowi]

Stimmt, daran hatte ich gar nicht gedacht. Das müsste gehen. Sollte auch mit Perl und

Code Auswählen Erweitern

HTTP::Request->new(DELETE => $url); funktionieren.

Schön wäre natürlich, wenn das auch direkt in HTTPMOD möglich wäre.

[StefanStrobel]

HTTPMOD verwendet bisher die HttpUtils von Fhem als Basis.
Um Delete zu unterstützen, müssten diese erweitert werden.
Da der Anwendungsfall aber extrem selten ist, vermute ich dass es sinnvoller ist in so einem Fall eine individuelle Lösung zu suchen (externer Aufruf oder Perl code ...)

Gruss
    Stefan

[mahowi]

Ok. Ich hatte mir die HttpUtils.pm noch nicht so genau angesehen. Im Wiki habe ich nur den Eintrag über $param->{method} gefunden:

Die HTTP-Methode, welche zur Abfrage verwendet werden soll. Sofern keine Daten übertragen werden ist dies standardmäßig "GET", ansonsten "POST". Es können aber auch andere Methoden verwendet werden.
Standardwert: "GET"

Den Parameter scheint es aber nur bei HttpUtils_BlockingGet zu geben, zumindest laut Wiki.

Aber Du hast recht, der Anwendungsfall für was anderes als POST oder GET ist wirklich selten.

[FHEMAN]

Hallo Manfred, hallo Frank, danke für Eure Hinweise. (Ich hatte mich zuletzt am veralteten Wiki aufgehalten) Mit readingXDeleteIfUnmatched funktioniert es nun.

Gibt es so eine Funktion auch für das LAST_RERROR Reading? Ich möchte gerne, dass sich das bei erfolgreichem Response löscht.

Gruß
Ronny