72_FRITZBOX.pm: Patch gegen Perl Warning bei fehlendem DECT

Begonnen von loescher, 04 Mai 2018, 17:45:35

Vorheriges Thema - Nächstes Thema

loescher

Hallo tupol!

Ich bekomme bei einer FritzBox 7170 (ohne DECT!) bei jedem "set FritzBox update" diese Meldungen im FHEM Log:

2018.05.04 16:53:15 1: PERL WARNING: Use of uninitialized value $dectUserID in hash element at ./FHEM/72_FRITZBOX.pm line 1494.
2018.05.04 16:53:15 1: PERL WARNING: Use of uninitialized value $dectUserID in hash element at ./FHEM/72_FRITZBOX.pm line 1495.


Nach meinen Tests würde dieser Patch das beheben:


--- 72_FRITZBOX.pm 2018-05-04 17:16:01.222978102 +0200
+++ 72_FRITZBOX.pm.NEW 2018-05-04 17:23:34.292828550 +0200
@@ -1491,8 +1491,12 @@
# Handset der internen Nummer zuordnen
    foreach ( @{ $result->{handset} } ) {
       my $dectUserID = $_->{User};
-      my $dectUser = $dectFonID{$dectUserID}{User};
-      my $intern = $dectFonID{$dectUserID}{Intern};
+      my $dectUser = '';
+      my $intern   = '';
+      if (defined $dectUserID) {
+         $dectUser = $dectFonID{$dectUserID}{User};
+         $intern   = $dectFonID{$dectUserID}{Intern};
+      }
       
       if ($dectUser) {
          FRITZBOX_Readout_Add_Reading $hash, \@roReadings, "dect".$dectUser."_manufacturer", $_->{Manufacturer};


Könntest dir das bitte anschauen und wenn OK dann offiziell einbauen?

LG,
Stephan.

tupol

Interessant. Laut Statistik gibt es nur eine Box mit 7170 (von 2069) ;-)
Bei den Repeatern gibt es diesen Fehler nicht.
Ich schau es mir mal genauer an. Ich vermute, es gibt auch eine Möglichkeit festzustellen, ob es DECT auf der Box gibt oder nicht.
Was spuckt die Box den aus, wenn Du folgende Befehle absetzt

get <device> luaQuery dect:settings/Handset/list(User,Manufacturer,Model,FWVersion)

get <device> luaQuery telcfg:settings/Foncontrol/User/list(Id,Name,Intern,IntRingTone,AlarmRingTone0,RadioRingID,ImagePath,G722RingTone,G722RingToneName)
FHEM 5.5 auf RPi B Rev.2 (mit LCD4Linux, BMP180 und CUL v3 868.35 MHz), FB7490, Fritz!DECT 200, FS20, FHT80TF-2, S300TH, KS300, Homematic, PRESENCE
Modul-Entwickler von: FRITZBOX, statistics, PROPLANTA, OPENWEATHER, JSONMETER, LUXTRONIK2

loescher

Naja, diese eine Box ist dann wohl meine  ;) Aber die erfüllt genau ihren Zweck.

Dabei bin ich gleich noch über etwas "gestolpert":
Das "get ... luaQuery ..." geht erst nach einem

attr FritzBox3 allowTR064Command 1

Ansonsten kommt nur:

Unknown argument luaquery, choose one of ringTones:noArg

In der Hilfeseite taucht leider weder luaquery noch die Abhängigkeit zum allowTR064Command auf.
Könntest du bitte bei Gelegenheit noch dazuschreiben.

Hier die Ausgaben:

Result of query = 'dect:settings/Handset/list(User,Manufacturer,Model,FWVersion)'
----------------------------------------------------------------------
$VAR1 = [
          {}
        ];

und

Result of query = 'telcfg:settings/Foncontrol/User/list(Id,Name,Intern,IntRingTone,AlarmRingTone0,RadioRingID,ImagePath,G722RingTone,G722RingToneName)'
----------------------------------------------------------------------
$VAR1 = [
          {
            'Name' => '',
            'Intern' => '',
            'G722RingTone' => '',
            'G722RingToneName' => '',
            'AlarmRingTone0' => '',
            'Id' => '0',
            'IntRingTone' => '0',
            'ImagePath' => '',
            'RadioRingID' => ''
          }
        ];


Wenn du noch mehr Infos brauchst, dann einfach sagen.

LG,
Stephan.

tupol

#3
Hallo Stephan,
jetzt habe ich wieder etwas mehr Zeit mir das Problem anzuschauen. So richtig ist es mir noch nicht klar. Ich dachte eigentlich, dass die Schleife
   foreach ( @{ $result->{handset} } ) {
übersprungen wird, da laut Deiner Rückmeldung $result->{handset} = undefined. Evtl. habe ich vielleicht Perl noch nicht durchschaut.

Kannst Du das ganze mal als if in Klammer setzen?
# Handset der internen Nummer zuordnen  if defined (result->{handset}) {      foreach ( @{ $result->{handset} } ) {      ...  }   }
FHEM 5.5 auf RPi B Rev.2 (mit LCD4Linux, BMP180 und CUL v3 868.35 MHz), FB7490, Fritz!DECT 200, FS20, FHT80TF-2, S300TH, KS300, Homematic, PRESENCE
Modul-Entwickler von: FRITZBOX, statistics, PROPLANTA, OPENWEATHER, JSONMETER, LUXTRONIK2

loescher

Hallo tupol,

Das funktioniert leider auch nicht.
Das $result->{handset} ist ja nicht undefined, sondern ist eine Liste mit einem leeren Hash.
Man muss also testen, ob der Hash in der Liste leer ist.
Dieser Patch behebt das Problem:


--- 72_FRITZBOX.pm 2018-05-04 17:37:47.189697441 +0200
+++ 72_FRITZBOX.pm.NEW2 2018-06-14 22:42:21.261149973 +0200
@@ -1490,6 +1490,7 @@
   
# Handset der internen Nummer zuordnen
    foreach ( @{ $result->{handset} } ) {
+      last if (!%{$_}); # End this loop, if Hash is empty
       my $dectUserID = $_->{User};
       my $dectUser = $dectFonID{$dectUserID}{User};
       my $intern = $dectFonID{$dectUserID}{Intern};


LG,
Stephan.

christian66

Hallo,
ich habe das gleiche Problem, wann gibt es denn eine offizielle Lösung?? Zum anpassen der .pm fehlt mir die Erfahrung. :-\

Gruß
Christian

tupol

Habe eine neue Version hochgespielt. Bitte in ein paar Stunden mal testen.
FHEM 5.5 auf RPi B Rev.2 (mit LCD4Linux, BMP180 und CUL v3 868.35 MHz), FB7490, Fritz!DECT 200, FS20, FHT80TF-2, S300TH, KS300, Homematic, PRESENCE
Modul-Entwickler von: FRITZBOX, statistics, PROPLANTA, OPENWEATHER, JSONMETER, LUXTRONIK2

pcollins

Update gerade gemacht und bekomme folgenden Fehler:

2018.07.31 09:41:27 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at ./FHEM/72_FRITZBOX.pm line 1468.
2018.07.31 09:41:27 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at ./FHEM/72_FRITZBOX.pm line 1468.


Jamo

Gleiches hier. Ich habe einen FRITZ!WLAN Repeater DVB‑C, den ich als Repeater betreibe. Der hat auch keinen DECT.
Nach einem "set FritzRep update" bekomme ich auch die Fehlermeldung, allerdings erzeugt das ganze notify, in dem das "set FritzRep update" steht, dann einen Fehler, und schreibt den LOG voll.
2018.08.01 07:46:28 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at ./FHEM/72_FRITZBOX.pm line 1468.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

tupol

Danke für die Rückmeldung. Neuer Versuch. Bitte in ein paar Stunden testen.
FHEM 5.5 auf RPi B Rev.2 (mit LCD4Linux, BMP180 und CUL v3 868.35 MHz), FB7490, Fritz!DECT 200, FS20, FHT80TF-2, S300TH, KS300, Homematic, PRESENCE
Modul-Entwickler von: FRITZBOX, statistics, PROPLANTA, OPENWEATHER, JSONMETER, LUXTRONIK2

Jamo

Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

loescher

Ich bin inzwischen auch dazu gekommen, es zu testen.
Es funktioniert!
Danke!
LG,
Stephan.

wolfram

#12
Hallo zusammen,

ich bin gerade in meinem Logfile über genau diese Einträge gestolpert:

2018.11.16 10:54:20 1: PERL WARNING: Argument "15256 Wh" isn't numeric in division (/) at (eval 9965) line 1.
2018.11.16 10:54:20 1: PERL WARNING: Argument "51.21 W" isn't numeric in numeric ge (>=) at (eval 9981) line 1.
2018.11.16 10:54:20 1: PERL WARNING: Argument "51.21 W" isn't numeric in numeric gt (>) at (eval 9982) line 1.
2018.11.16 10:54:20 1: PERL WARNING: Argument "51.21 W" isn't numeric in numeric le (<=) at (eval 9983) line 1.


Ich vermute(!) dass es von meinen FB-Dect-Steckdosen kommt, allerdings ist ja der Patch inzwischen offiziell eingecheckt und der Fehler sollte doch behoben sein?!

Mein fhem ist eigentlich aktuell:


72_FB_CALLLIST.pm    16433 2018-03-18 08:20:35Z markusbloch
72_FB_CALLMONITOR.pm 16709 2018-05-08 20:14:58Z markusbloch
72_FRITZBOX.pm       17437 2018-09-30 18:24:58Z tupol
72_XiaomiDevice.pm   17667 2018-11-03 21:53:19Z moises


Hat jemand eine Idee?

Danke und viele Grüße
wolf

tupol

FHEM 5.5 auf RPi B Rev.2 (mit LCD4Linux, BMP180 und CUL v3 868.35 MHz), FB7490, Fritz!DECT 200, FS20, FHT80TF-2, S300TH, KS300, Homematic, PRESENCE
Modul-Entwickler von: FRITZBOX, statistics, PROPLANTA, OPENWEATHER, JSONMETER, LUXTRONIK2

wolfram

Danke für Deine Antwort tupol,

das war/ist mir nicht klar. Die Werte kommen definitiv von den DECT-Steckdosen, deshalb mein Rückschluss, dass es daher kommt.

wolf