Hallo,
ich bastle im Moment an einem größeren HTTPMOD_Device,
doch leider greifen meine Regexp oft nicht da die Datei teilweise Sonderzeichen und Newlines enthält (die mich gar nicht interessieren!!).
Da ich jedoch mehrere Matchgruppen in einem Regexp benötige, sollte ich zuvor das internal "buf" bereinigen.
Kann mir jemand sagen, wie das geht? Ich dachte, dass vielleicht das "parseFunction1" dafür benutzt werden kann,
aber Beispiel habe ich leider keines gefunden. Kann mir jemand auf die Sprünge helfen?
Hallo,
Vielleicht löst ja auch ein RegOpt-Attribut mit s Dein Problem ...
Dann matcht . auch newlines.
Gruß
Stefan
Danke, werds versuchen, leider ist meine Quelle gerade down.. ein erster Versuch an anderer Stelle war nicht erfolgreich, dieser ist bei Binärdaten ausgestiegen.
Ab liebsten würde ich den Buffer komplett mit einem Filer ähnlich wie [a-zA-Z0-9<>"=] bereinigen... aber ich versuch nachher diese Lösung nochmals...
Hallo,
die parseFunction wird dabei nicht sehr hilfreich sein. Die wird erst nach der Verarbeitung der definierten Parse-Features aufgerufen (siehe HTTPMOD_Read im Quelltext). Mit ein wenig Übung bei den Regexes sollte das aber in jedem Fall auch ohne Vorfilterung gut funktionieren.
Sonst kannst Du ja auch noch mal einen Ausschnitt aus der HTTP-Response posten, dann kann ich Dir vielleicht bei der Regex-Formulierung helfen.
Gruss
Stefan
Hallo Stefan,
danke fürs Angebot! Mein Regex ist sehr komplex, er ist fast eine Din A4-Seite lang und extrahiert 233 Gruppen!
Das meiste konnte ich korrigieren, indem ich statt . \p{Any} verwende, aber irgendwie klappt es mit dem s auch nicht ganz zuverlässig... im gegensatz zu meinem reinen perl-testscript...
naja.
Frage: Eine über define konfigurierte URL kann ich mit readingXX mit mehreren regex auslesen,.
Kann ich bei get... aBeispieluch mehrere regex angeben, ohne die URL mehrmals downloaden zu müssen? Wenn ich es richtig verstehe muss ich ja bei jedem get eine URL angeben, da er sonst die URL aus dem define verwendet. Somit würde bei mir die selbe langsame URL 233 mal downgeloadet.... daher habe ich mich für 1 get mit 233 Regex-Gruppen entschieden.
Folgende Wünsche hätte ich, sie so denke ich SEHR viel Sinn machen würden.!
1. Die Namen der Regex-Gruppen sollten unbedingt aus benanntne Gruppen direkt aus dem Regex übernommen werden können! Vorallem bei verschachtelten Gruppen erhöht das erheblich die Übersichtlichkeit.
Beispiel:
"11.12.2013 12:13" =~ (?<GesamtTimestamp>(?<Datum>\d\d.\d\d.\d\d\d?\d?)\s(?<Zeit>\d\d:\d\d))
Da ist doch alles enthalten, und ich benötige nicht 233 extra Attribute in der Form get01-233Name XXYY
So erhalte ich direkt für alle 3 Gruppen die korrekten und gewünschten Namen, ohne aufwändig gruppen zählen zu müssen....
2. Wenn das Mehrfachverwenden der URL bei get nicht geht, würde ich mir genau das wünschen!
Beispielsyntax: get02Url $get01Url
3. Mehr Hinweis als Wunsch: Für mich wäre eine Schreibweise beim Regex "get01Regex m/(.*)/ms"
intuitiver und einfacher zu verwenden als das aufzusplitten in ein eigenes get01RegOpt... aber dafür gabs bestimmt Gründe ;-)
Ein Großartiges Modul hast Du da, vielen herzlichen Dank dafür!!
Hallo,
Jedes Get erzeugt einen eigenen HTTP-Request, aber wenn ein Get keine eigenen parse-Attribute hat oder wenn das entsprechende checkAllReadings gesetzt ist, werden die readingXXregex Attribute etc. verwendet.
Du könntest also auch ein Get und viele einzelne Regexes haben, was die Lesbarkeit erhöhen könnte.
Das mit den benannten Gruppen werde ich mir mal ansehen.
Gruß
Stefan
Danke Stefan, bei mir funktioniert es jetzt, wenn auch etwas kompliziert.
Der Wunsch mit den benannten Gruppen ist noch sehr stark ;-)
Und noch einen Wunsch hätte ich: Kann man (ggf. mit Parameter) die Anzeigegröße von "buf" begrenzen?
Die Seite die ich Parse ist sehr sehr groß, und blockiert immer den ganzen Anzeigeschirm des Devices in FHEM enorm. Am Handy ist die Anzeige damit gar nicht mehr möglich!
Vielen Dank!
Hallo,
das mit den benannten Gruppen hab ich auf die Wunschliste gesetzt. Klingt vernünftig, aber bevor ich das angehe hab ich noch ein paar offene Baustellen im Modbus-Modul.
Die Anzeige von buf ist ein anderes Thema. Das macht Fhemweb. Ich könnte allenfalls das Modul komplett umbauen und den Buffer nicht direkt als sichtbares Internal verwenden, aber das könnte andere Dinge kaputt machen...
Gruss
Stefan