Stacktrace beim Update von Readings

Begonnen von zap, 08 Juli 2022, 10:07:40

Vorheriges Thema - Nächstes Thema

zap

Beim Update eines Readings in HMCCU wird folgender Stacktrace generiert:

2022.07.07 20:32:28 1: PERL WARNING: Use of uninitialized value $minInt in numeric lt (<) at fhem.pl line 5070.
2022.07.07 20:32:28 1: stacktrace:
2022.07.07 20:32:28 1:     main::__ANON__                      called by fhem.pl (5070)
2022.07.07 20:32:28 1:     main::readingsBulkUpdate            called by ./FHEM/88_HMCCU.pm (9224)
2022.07.07 20:32:28 1:     main::HMCCU_BulkUpdate              called by ./FHEM/88_HMCCU.pm (4838)
2022.07.07 20:32:28 1:     main::HMCCU_UpdateParamsetReadings  called by ./FHEM/88_HMCCU.pm (4957)
2022.07.07 20:32:28 1:     main::HMCCU_UpdateMultipleDevices   called by ./FHEM/88_HMCCURPCPROC.pm (878)
2022.07.07 20:32:28 1:     main::HMCCURPCPROC_Read             called by fhem.pl (3950)
2022.07.07 20:32:28 1:     main::CallFn                        called by fhem.pl (781)


Die Variable $minInt wird in fhem.pl ein paar Zeilen vor 5070 in einem split() Statement initialisiert. Aus dem Gedächtnis:

my (undef, $minInt) = split(':', $v[0])

Was könnte die Ursache sein? Ich vermute, dass ein Readingname oder Wert schuld ist. Leider kann ich es nicht nachvollziehen/reproduzieren. Ein Nutzer von HMCCU hat das Problem gemeldet.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Beta-User

Laienhafter Versuch meinerseits:
$v[0] enthält keinen Doppelpunkt, an dem gesplittet werden könnte?

Sowas würde zwangsweise auf 0 setzen:
my (undef, $minInt) = split m{:}x, $v[0];
$minInt //= 0;
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

rudolfkoenig

Bin auch der Ansicht, dass jemand bei einem event-min-interval ein gueltiges Reading, aber kein Intervall angegeben hat.
Statt zwangsweise auf 0 zu setzen sollte mAn eher beim Setzen ueberprueft werden, dass was Numerisches vorhanden ist.

zap

ok, danke! Also das Attribut event-min-reading ist falsch gesetzt.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Beta-User

Zitat von: rudolfkoenig am 08 Juli 2022, 10:34:55
Bin auch der Ansicht, dass jemand bei einem event-min-interval ein gueltiges Reading, aber kein Intervall angegeben hat.
Statt zwangsweise auf 0 zu setzen sollte mAn eher beim Setzen ueberprueft werden, dass was Numerisches vorhanden ist.
Das mit der 0 ist in dem Fall in der Tat in diesem Fall keine gute Idee :-[ .

Da es hier um die Syntaxprüfung der $readingFnAttriubutes (und ggf. ergänzend um disabledForIntervals etc?) geht: Wäre es nicht sinnvoll, das zu zentralisieren (ähnlich SetExtensions)? Also am Ende der AttrFn() eine Funktion aufrufen, die checkt, ob es sich um ein solches globales Attribut handelt und ggf. "laut" gibt, wenn irgendwas schräg ist?
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

rudolfkoenig

ZitatWäre es nicht sinnvoll, das zu zentralisieren (ähnlich SetExtensions)? Also am Ende der AttrFn() eine Funktion aufrufen, die checkt, ob es sich um ein solches globales Attribut handelt und ggf. "laut" gibt, wenn irgendwas schräg ist?
Es wird bereits gecheckt, ob der Regexp sinnvoll ist, die Zahl aber noch nicht.
Ich habe das jetzt fuer event-min-interval eingebaut.