Neue Version von HTTPMOD mit neuen Features zum Testen

[Elektrolurch]

Hallo,

seit dem letzten Update:

Code Auswählen Erweitern


Can't call method "Auth" on unblessed reference at ./FHEM/98_HTTPMOD.pm line 1328.


Elektrolurch

[StefanStrobel]

Hallo,

ich habe gerade eine neue Version eingecheckt, die einen Tippfehler behebt (Auth statt DoAuth) sowie den Kontext bei Expressions auf das package main setzt.
Ich hoffe das behebt die neuen Fehler.

Gruss
   Stefan

[Harry47]

Hallo,

Seit dem letzten Update gibt es einen Fehler, wenn ich eine Sub in meiner "99_myUtils.pm" im Modul HTTPMOD aufrufen will.

Beispiel im HTTPMOD Modul
"reading01OExpr" entspricht "CorrectNumber($val,-1,1,1,0)"

"CorrectNumber" ist eine Funktion in meiner "99_myUtils.pm"

Fehlermeldung im Log (DDAX2 ist das HTTPMOD Modul):
DDax2: perl expression eval with expression my $timeDiff = $oRef->{'$timeDiff'};CorrectNumber($val,-1,1,1,0) on 12.628 created error: Undefined subroutine &FHEM::HTTPMOD::Utils::CorrectNumber called at (eval 3882) line 1.

Die von StefanStrobel vorgeschlagene Lösung war dann erfolgreich.
Angepasstes Beispiel im HTTPMOD Modul
"reading01OExpr" entspricht "main::CorrectNumber($val,-1,1,1,0)"

[Elektrolurch]

Leider nicht:

Code Auswählen Erweitern


Undefined subroutine &HTTPMOD::Auth called at ./FHEM/98_HTTPMOD.pm line 1328.

...und dann starb fhem...

Elektrolurch

[betateilchen]

Ändere in Zeile 1328 den Aufruf von Auth($hash) in DoAuth($hash).

Die Stelle wurde vermutlich einfach übersehen.

die einen Tippfehler behebt (Auth statt DoAuth) s

[StefanStrobel]

so ist es.
Neue Version ist jetzt eingecheckt.

zu dem Problem mit Funktionen aus 99_myUtils.pm:
ich habe jetzt vor den Eval-String noch ein "package Main;" eingefügt. Damit sollte die Expression im Main-Kontext ablaufen und Funktionsaufrufe benötigen hoffentlich kein Main:: mehr.
@Harry: könntest Du kurz testen ob es wieder so wie vorher funktioniert?

Gruss / Thanks
   Stefan

[betateilchen]

es scheint noch ein paar mehr Probleme mit nicht passenden Namensraumangaben zu geben, z.B. hier:

https://forum.fhem.de/index.php/topic,115250.0.html

[jkriegl]

Bekomme nach update (24.10.) Logeintragungen

Code Auswählen Erweitern

2020.10.25 13:10:05 3: Bajuw: error while parsing JSON data: malformed UTF-8 character in JSON string, at character offset 116 (before "\x{fffd}C","sensorTy...") at lib/FHEM/HTTPMOD/Utils.pm line 640.
List Device

Code Auswählen Erweitern

Internals:
   BUSY       0
   DEF        https://api.opensensemap.org/boxes/5982d708e3b1fa001049ddb5/sensors 3600
   FUUID      5e9c38e8-f33f-9f96-b11d-8677b9e240645104
   Interval   3600
   MainURL    https://api.opensensemap.org/boxes/5982d708e3b1fa001049ddb5/sensors
   ModuleVersion 4.0.12 - 24.10.2020
   NAME       Bajuw
   NOTIFYDEV  global
   NR         60
   NTFY_ORDER 50-Bajuw
   STATE      13:10 19.7 °C 80 % 1018.0 hPa + PM: 0.70 0.40 µg/m³
   TYPE       HTTPMOD
   value     
   HttpUtils:
     NAME       
     addr       https://api.opensensemap.org:443
     auth       0
     buf       
     code       200
     compress   1
     conn       
     data       
     displayurl https://api.opensensemap.org/boxes/5982d708e3b1fa001049ddb5/sensors
     header     
     host       api.opensensemap.org
     httpheader HTTP/1.0 200 OK
Access-Control-Allow-Headers: authorization
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: content-disposition
Access-Control-Max-Age: 600
Content-Encoding: gzip
Content-Md5: yWOVCFxQhzjs5KgCDB55Cw==
Content-Type: application/json; charset=utf-8
Date: Sun, 25 Oct 2020 12:10:05 GMT
Request-Id: 7342908c-0f11-40a9-86d5-ee391c1bb73f
Response-Time: 2
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
Content-Length: 386
     httpversion 1.0
     hu_blocking 0
     hu_filecount 1
     hu_port    443
     hu_portSfx
     ignoreredirects 1
     loglevel   4
     path       /boxes/5982d708e3b1fa001049ddb5/sensors
     protocol   https
     redirects  0
     timeout    10
     url        https://api.opensensemap.org/boxes/5982d708e3b1fa001049ddb5/sensors
     sslargs:
   QUEUE:
   READINGS:
     2020-10-24 16:27:11   PM10            0.70
     2020-10-24 16:27:11   PM2.5           0.40
     2020-10-24 16:27:11   baro            1018.0
     2020-10-24 16:27:11   humidity        80
     2020-10-24 16:27:11   press-trend     +
     2020-10-25 13:10:05   stand           13:10
     2020-10-24 16:27:11   temperatur      19.7
   REQUEST:
     context    reading
     data       
     header     
     ignoreredirects 0
     num        0
     retryCount 0
     type       update
     url        https://api.opensensemap.org/boxes/5982d708e3b1fa001049ddb5/sensors
Attributes:
   event-on-change-reading .*
   group      Umwelt
   oldreadings baro
   reading01Format %.1f
   reading01JSON sensors_01_lastMeasurement_value
   reading01Name temperatur
   reading02Format %.1f
   reading02JSON sensors_02_lastMeasurement_value
   reading02Name baro
   reading02OExpr $val/94.1
   reading04Format %.0f
   reading04JSON sensors_04_lastMeasurement_value
   reading04Name humidity
   reading05JSON sensors_05_lastMeasurement_value
   reading05Name PM10
   reading06JSON sensors_06_lastMeasurement_value
   reading06Name PM2.5
   room       4.0 Wetter
   stateFormat stand temperatur °C humidity % baro hPa press-trend PM: PM10 PM2.5 µg/m³
   timeout    10
   userReadings stand {strftime "%R",localtime time;},

press-trend:baro:.* {my $val=ReadingsVal($name,"baro",0)
- OldReadingsVal($name,"baro",0);
$val > 0.2 ? "+" : $val < -0.2 ? "-" : "="},
   userattr   reading01Format reading01JSON reading01Name reading02Format reading02JSON reading02Name reading02OExpr reading04Format reading04JSON reading04Name reading05JSON reading05Name reading06JSON reading06Name
Der Verursacher scheint °C zu sein. Hat bis zum update funktioniert. (s. readings-timestamp) (Noch kein restore gemacht.)

[StefanStrobel]

Hallo jkriegl,

das liegt vermutlich daran, dass in der neuen Version ein Bug bei bodyDecode behoben ist.
Bisher hat die Dekodierung nicht funktioniert. Nun schon, was aber offensichtlich auch Seiteneffekte hat.
Wenn man bodyDecode auf none setzt, sollte das alte Verhalten wieder da sein.
probier das doch bitte mal aus.
Wenn es nicht funktioniert würde die Konfiguration und der komplette JSON-String helfen, damit ich das Problem eingrenzen kann.

Gruss / vielen Dank
   Stefan

[StefanStrobel]

Ich habe gerade eine neue Version der Utils.pm eingecheckt, die den Fehler mit getUniqueId beheben sollte.
@betateilchen: Danke für den Hinweis.

Gruss
   Stefan

[jkriegl]

@Stefan mit bodyDecode = none funktioniert es wieder.

Habe in meiner Anfrage oben ein device-List mit Link um den JSON String zu bekommen.

[gehlbel]

Die neue Version hat bei mir den getUniqueId Fehler behoben, Danke dafür.

Allerdings habe ich festgestellt das es 2 internals die ich bisher genutzt habe nicht mehr gibt:

- "addr" habe ich als replacement in GetxxURL/SetxxURL Attributen verwendet um auf den Hostenamen/Port zu refferenzieren ("MainURL" enthält die vollständige URL)
- "LASTSEND" habe ich verwendet um zu prüfen ob der letzte Aufruf fehlerfrei war (Timestamp LAST_ERROR > Timestamp LASTSEND)

Grüße
Béla

[StefanStrobel]

Hallo Bela,

Vielen Dank fürs Testen und das Feeback!
Ich habe versucht bei der Überarbeitung auch ein paar Altlasten auszumisten. Dazu gehört auch, dass ich ursprünglich beim Aufruf der HttpUtils einfach den HTTPMOD-Device-Hash verwendet habe und keinen eigenen Hash. Das habe ich jetzt geändert. Dadurch sind auch die ganzen Hash-Keys verschwunden, die HttpUtils gesetzt hat. Für den Fall, dass sie doch noch jemand sucht, habe ich den Übergabe-Hash für HttpUtils als $hash->{HttpUtils} referenziert.
Das bisherige $hash->{addr} ist daher jetzt immer noch als $hash->{HttpUtils}{addr} erreichbar, aber die Anzeige in Fhemweb ist nicht mehr voll mit Internals, die kaum jemand brauchen kann.
Ebenso habe ich Internals wie LASTSEND, von dem ich ausgegangen bin, dass es keiner braucht, in .LASTSEND umbenannt, so dass es nicht mehr angezeigt wird.
Wenn noch mehr Leute das benötigen, kann ich die Umbenennung auch rückgängig machen bzw. die Keys von HttpUtils wieder in den Device-Hash kopieren.

Gruss
    Stefan

[Beta-User]

Ebenso habe ich Internals wie LASTSEND, von dem ich ausgegangen bin, dass es keiner braucht, in .LASTSEND umbenannt, so dass es nicht mehr angezeigt wird.
Wenn noch mehr Leute das benötigen, kann ich die Umbenennung auch rückgängig machen bzw. die Keys [...]

Alternativ: Man kann solche "versteckten" Hashes ggf. auch durch das Attribut "showInternalValues" in "global" sichtbar machen, wenn man die braucht. Kann aber sein, dass das auf der obersten Ebene bzw. in helper sein muss (da habe ich sowas in diversen von mir betreuten Modulen untergebracht).

[Rudibarani]

Hallo Stefan,

ich nutzte HTTPMOD, um das Status-JSON meiner Lupus-Alarmanlage abzufragen. Da ist mir heute aufgefallen, dass ich seit dem 24.9. stets diesen Fehler im Logfile habe. An dem Tag habe ich ein Update laufen lassen.

Code Auswählen Erweitern


2020.10.27 15:40:37 3: Alarmanlage_SmartHome: error while parsing JSON data: malformed UTF-8 character in JSON string, at character offset 91 (before "\x{fffd}abgeschlosse...") at /opt/fhem/lib/FHEM/HTTPMOD/Utils.pm line 644.
2020.10.27 15:40:37 3: Alarmanlage_SmartHome: no parsed JSON structure available

Vorher lief es ohne Probleme. Ich weiß, dass mein JSON-File der Alarmanlage Tabulator-Symbole enthält, die nicht JSON-konform sind.
Diese lasse ich über preProcessRegex mit

Code Auswählen Erweitern

s/\t//g entfernen. Das lief auch immer gut.
Ich habe den regulären Ausdruck nach der Fehlermeldung auf

Code Auswählen Erweitern

s/([üÜäÄöÖ]|\t)/_/g erweitert, da das Wort vor der Fehlermeldung "Haustür" ist und ich auf das "ü" getippt habe. Das löst das Problem aber leider nicht.

Hast Du eine Idee, wo das Problem herkommen kann? Ist vielleicht bei einer der "Aufräumaktionen" eine Funktion in diesem Bereich weggefallen?

Danke für die Hilfe
Phillip