stacktrace readingsgroup - welche ist es?

Begonnen von shamal2008, 17 Oktober 2021, 10:57:36

Vorheriges Thema - Nächstes Thema

shamal2008

Hello zusammen,

ich habe seit einiger Zeit mein Log vollgekübelt mit folgender Meldung:
PERL WARNING: Argument "ok" isn't numeric in numeric le (<=) at (eval 732832) line 3.
2021.10.11 22:10:09 1: stacktrace:
2021.10.11 22:10:09 1:     main::__ANON__                      called by (eval 732832) (1)
2021.10.11 22:10:09 1:     (eval)                              called by ./FHEM/33_readingsGroup.pm (357)
2021.10.11 22:10:09 1:     main::lookup2                       called by ./FHEM/33_readingsGroup.pm (1441)
2021.10.11 22:10:09 1:     main::readingsGroup_Notify          called by fhem.pl (3894)
2021.10.11 22:10:09 1:     main::CallFn                        called by fhem.pl (3811)
2021.10.11 22:10:09 1:     main::DoTrigger                     called by fhem.pl (4909)
2021.10.11 22:10:09 1:     main::readingsEndUpdate             called by ./FHEM/88_HMCCU.pm (4633)
2021.10.11 22:10:09 1:     main::HMCCU_UpdateParamsetReadings  called by ./FHEM/88_HMCCU.pm (4746)
2021.10.11 22:10:09 1:     main::HMCCU_UpdateMultipleDevices   called by ./FHEM/88_HMCCURPCPROC.pm (825)
2021.10.11 22:10:09 1:     main::HMCCURPCPROC_Read             called by fhem.pl (3894)
2021.10.11 22:10:09 1:     main::CallFn                        called by fhem.pl (773)


Was hat sich geändert:
- Heizungssystem von Max! auf Hm-IP (mit ccu und neuem hmccu 4.4 bzw. 5.0) im Betrieb
- div. Heizungsroutinen auf die neuen Geräte geändert
- die Readingsgroups (da gibt es 1 Gesamt, 1 für jedes Zimmer, 1 für die Ventilpositionen) angepasst bzw. neu erstellt

Wo zum Henker finde ich heraus WELCHE Readingsgroup den Stacktrace verursacht? Ist ja nett, wenn der jede Minute mit völlig wertlosen Infos (in Readingsgroup, mit HMCCU) kommt. Wenn bei dem Teil wenigstens der VERURSACHER (also welche Readingsgroup) genannt würde und nicht nur jedes Mal "fhem.pl" - wäre das mehr als hilfreich.

Wie kann ich auslesen, wo der Fehler herkommt? - (es gibt noch einen zweiten mit "le" <= - noch weniger hilfreich, weil man ja kaum irgendwo was vergleicht...

Danke für eure Hilfe,
shamal2008
FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;

Beta-User

"ok" klingt nach irgendwas mit Batterie...

(OT: Das "Gemaule" kannst du dir sparen >:( . stacktrace hast du selbst eingeschaltet, und stacktrace dann auch noch alle möglichen Rahmenbedingungen erfassen zu lassen, ist zwar vielleicht möglich, aber meistens nicht erforderlich). Der eigentliche Wert kommt jedenfalls von einem HMCCU.*-Gerät.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

shamal2008

Hallo,

zuerst mal danke für die Antwort, soweit bin ich gestern auch schon gekommen. Das steht ja drin. Aber die auslösende RG wird nirgends dokumentiert, oder sehe ich das falsch? Heißt mangels weiterer Informationen, mal alle Homematic-RG mit Batterie rauszunehmen.

(OT: Ich maule nicht, sondern hab mich eigentlich gewundert, das das Stacktrace nicht mehr Infos bringt). Wenn ich nur die ursprüngliche Fehlermeldung poste, kann ich mir von dir und den anderen Forums-Heros wieder anhören, dass ich gefälligst die Suchfunktion bemühen und mal Stacktrace einschalten soll, weil man sonst ja (was noch mehr stimmt) überhaupt nichts sagen kann.).

FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;

frank

#3
"le" ist doch ein guter hinweis, und ebenso die zeilennummern von readingsgroup.

ich hätte zunächst fhem.cfg nach "le" durchsucht.

edit: eventuell attr valueStyle/Format
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

shamal2008

Hallo Frank,

die Suche nach "le" war nicht erfolgreich, jedoch bin dein Hinweis mit "ValueStyle".

Habe festgestellt, dass (offenbar seit einem Update) meine Temperatur-Einfärbung der HmIP Geräte nicht mehr funktioniert und diese Meldung auslöst.

Ich hatte bis jetzt diesen Code

{if($READING eq "measured-temp" && $VALUE > 25) {'style="color:red"'}
elsif ($READING eq "measured-temp" && $VALUE <= 18) {'style="color:blue"'}
elsif ($READING eq "measured-temp" && $VALUE >= 19 || $VALUE <= 25) {'style="color:green"'}
elsif ($READING eq "deviation" && $VALUE > 1.5) {'style="color:red"'}
elsif ($READING eq "deviation" && $VALUE <= -1.5) {'style="color:blue"'}
elsif ($READING eq "deviation" && $VALUE >= -1.5 || $VALUE <= 1.5) {'style="color:green"'}
elsif ($READING eq "humidity" && $VALUE >= 45 || $VALUE <= 55) {'style="color:green"'}
elsif ($READING eq "humidity" && $VALUE > 56 ) {'style="color:red"'}
elsif ($READING eq "humidity" && $VALUE < 44 ) {'style="color:blue"'}
else {'style="color:black"'}}


für die WTH und die e-TRV-C-2 verwendet und gut funktioniert. Nun meckert das Teil, weil "ok" kein NUM ist, sehe ich ja glatt ein. Allerdings soll das Valuestyle ja auch nur "vergleichen" wenn ein Reading mit deviation,humidity oder measured-temp kommt. Offenbar stört der Batteriestatus und der Heizungs-Modus.

Ich frag mich, was ich hier falsch mache, denn oben werden ja nur die 3 Readings ausgewertet, alles andere bleibt schwarz.

Vielleicht hat jemand noch eine Idee,
Danke,
FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;