Warnungen durch 10_MQTT_DEVICE.pm

[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

[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:

Code Auswählen Erweitern

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...

[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

[rudolfkoenig]

--> 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...