Warnungen durch 10_MQTT_DEVICE.pm

Begonnen von Mario67, 14 März 2021, 20:36:53

Vorheriges Thema - Nächstes Thema

Mario67

Hallo,

nach dem ich wegen der in https://forum.fhem.de/index.php/topic,119525.0.html beschriebenen Probleme stacktrace eingeschaltet habe, sind im Log nun auch zuvor manchmal aufgetretene Warnungen besser sichtbar:

2021.03.14 18:18:20 1: PERL WARNING: Use of uninitialized value $1 in concatenation (.) or string at ./FHEM/10_MQTT_DEVICE.pm line 253, <GEN59> line 131.
2021.03.14 18:18:20 1: stacktrace:
2021.03.14 18:18:20 1:     main::__ANON__                      called by ./FHEM/10_MQTT_DEVICE.pm (253)
2021.03.14 18:18:20 1:     MQTT::DEVICE::onmessage             called by ./FHEM/00_MQTT.pm (550)
2021.03.14 18:18:20 1:     MQTT::__ANON__                      called by FHEM/GPUtils.pm (75)
2021.03.14 18:18:20 1:     GPUtils::GP_ForallClients           called by ./FHEM/00_MQTT.pm (560)
2021.03.14 18:18:20 1:     MQTT::Read                          called by fhem.pl (3847)
2021.03.14 18:18:20 1:     main::CallFn                        called by fhem.pl (773)


Mir ist an der Stelle nicht klar, ob es zur Warnung durch eine falsche Konfiguration oder nicht passende Payloads kommt. Ist die Meldung schon mal vorgekommen?
FHEM ist auf dem aktuellen Stand.

Grüße,
Mario
FHEM auf Raspberry Pi 4 mit CUL868, WMBUS,
FS20 ST, FS20 AS4-3, FS20 SU-2, FS20 DF, 1-Wire + RS-232: AB Electronics Com Pi RS232, Brandmelder + Fenster: AB Electronics IO Pi 32
BUDERUS GB142 über EMS/AVR-NET-IO, WESTAFLEX WAC250 über RS232, MySensors
mit fhem.cfg & includes glücklich

rudolfkoenig

Das hier gemeldete Problem hat nichts mit dem verlinkten Problem zu tun, sonst muessten wir die gleiche WARNING Zeile sehen.

Die WARNING-Zeile hier bemaengelt ein nicht gesetztes $1 in Zeile 253. In der aktuellen Modulversion wird in dieser Zeile kein $1 verwendet, d.h. FHEM/10_MQTT2_DEVICE.pm ist nicht aktuell. Bitte FHEM aktualisieren (update in der FHEM Kommandozeile ausfuehren), FHEM neu starten, und wenn immer noch Warnungen im Log auftreten, dann diese hier mit dem aktualisierten Zeilennummer melden. Ein "attr global verbose 5" Log-Auszug um die Warning Meldungen herum wuerde mir vmtl. beim Suchen des Fehlers helfen.

Beta-User

@Rudi: Die Frage bezog sich auch 10_MQTT_DEVICE.pm.
Dort gibt es in #253 schon ein $1, das kommt aus diesem Kontext:
251 } elsif ($topic =~ $hash->{'.autoSubscribeExpr'}) {
252    Log3($hash->{NAME},5,"calling readingsSingleUpdate($hash->{NAME},$1,$message,1)");
253    CommandAttr(undef,"$hash->{NAME} subscribeReading_$1 $topic");
254    readingsSingleUpdate($hash,$1,$message,1);


Das sieht mir danach aus, dass entweder die auto-subscription "komisch" konfiguriert ist, oder der Topic ist irgendwie "eigen", der da übermittelt wird (oder beides "undef"?)

@Mario67: Das sieht mir nach einem Konfigurationsproblem aus, der Code dürfte an der Stelle "schon ewig" so sein, ohne dass bisher Anlass bestand, diese Art Ursache abzufangen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rudolfkoenig

Sorry, war zu voreilig.
Wer verwendet heute noch MQTT_DEVICE?
Wird das ueberhaupt supported? :)

Mario67

Hallo,

Danke für die Antworten.

"Das hier gemeldete Problem hat nichts mit dem verlinkten Problem zu tun, sonst muessten wir die gleiche WARNING Zeile sehen."
--> War mir klar darum ja auch neuer Thread.

"Wer verwendet heute noch MQTT_DEVICE?"
--> Ich will nicht FHEM zum MQTT-Broker machen. Dan ist doch die Kombination MQTT + MQTT_DEVICE passend, oder?

Die Definitionen checke ich nochmal.

Gruß,
Mario
FHEM auf Raspberry Pi 4 mit CUL868, WMBUS,
FS20 ST, FS20 AS4-3, FS20 SU-2, FS20 DF, 1-Wire + RS-232: AB Electronics Com Pi RS232, Brandmelder + Fenster: AB Electronics IO Pi 32
BUDERUS GB142 über EMS/AVR-NET-IO, WESTAFLEX WAC250 über RS232, MySensors
mit fhem.cfg & includes glücklich

rudolfkoenig

Zitat--> Ich will nicht FHEM zum MQTT-Broker machen. Dan ist doch die Kombination MQTT + MQTT_DEVICE passend, oder?
Ich wuerde bei diesen Anforderungen MQTT2_CLIENT+MQTT2_DEVICE empfehlen.

Mario67

O.K. schaue ich mir an. Ist irgendwie an mir vorbei gegangen...
FHEM auf Raspberry Pi 4 mit CUL868, WMBUS,
FS20 ST, FS20 AS4-3, FS20 SU-2, FS20 DF, 1-Wire + RS-232: AB Electronics Com Pi RS232, Brandmelder + Fenster: AB Electronics IO Pi 32
BUDERUS GB142 über EMS/AVR-NET-IO, WESTAFLEX WAC250 über RS232, MySensors
mit fhem.cfg & includes glücklich