Moin Rudi,
ich gebe für HttpUtils_NonblockingGet($param); den loglevel des aufrufenden Moduls "weiter".
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_JsonMod.pm#L575
Bei verbose 3 landet aus HttpUtils dies im log:
2020.04.14 12:10:00 3: IP: update.homematic.com -> 81.14.202.206
2020.04.14 12:10:00 3: https://update.homematic.com/firmware/api/firmware/search/DEVICE: HTTP response code 200
2020.04.14 12:12:15 3: IP: update.homematic.com -> 81.14.202.206
2020.04.14 12:12:15 3: https://update.homematic.com/firmware/api/firmware/search/DEVICE: HTTP response code 200
Ist HttpUtils da einfach "geschwätzig", soll so oder verwende ich das falsch ?
Bei 3 würde ich diese Meldungen nicht erwarten .
Danke vg
Joerg
In HttpUtils.pm erfolgen die meisten Ausgaben mit "Log3 $hash, $hash->{loglevel}", und einige mit "Log3 $hash, $hash->{loglevel}+1".
Log3 prueft per AttrVal($hash->{NAME}, "verbose",...) um zu filtern.
Das was du erwartest, erreicht man, indem man
$param->{'loglevel'} = AttrVal($name, 'verbose', 3);
durch
$param->{NAME} = $name;
ersetzt, da loglevel per Voreinstellung 4 ist.
Ich kann dir nicht erklaeren, wozu loglevel in $hash gut sein soll.
Korrigiert mich, wenn ich mich täusche:
* Der Programmierer entscheidet mit $hash->{loglevel} im blocking bzw. einfach in der Log3 Anweisung welche "Kritikalität" eine Meldung hat
* Der Anwender entscheidet im verbose-Attribut, welche Meldungen (welcher Kritikalität) er sehen will.
Wenn man $hash->{loglevel} auf den AttrVal des verbose-Attributs setzt schafft man sich eine self-fulfilling prophecy, da dann genau mit der Kritikalität geloggt wird, die der Anwender sehen will.
Grüße,
Oli
Macht Sinn, danke.