[gelöst] merkwürdiges warning

Begonnen von Nobbynews, 09 Juli 2021, 08:30:23

Vorheriges Thema - Nächstes Thema

Nobbynews

Guten Morgen,

ich habe heute Morgen in der Log-Datei folgenden Eintrag gefunden:
2021.07.09 05:00:00 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 8866699) line 1.
2021.07.09 05:00:00 3: eval: di_LampeKueche: warning in condition c01
2021.07.09 05:00:00 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 8866699) line 1.
2021.07.09 05:00:00 3: eval: di_LampeKueche: warning in condition c01

Ich gehe mal davon aus, dass das Warning durch folgendes doif erzeugt wurde:
Internals:
   CFGFN     
   DEF        (([MQTT2_Kueche:PIR_Kueche] eq "ON") and
([?ZWave_BWM_Garage_Lux:Helligkeit] < 200 and [?TasterKueche:channelA] eq "AI")
) (set Kueche on, setreading ZWave_BWM_Garage_Lux LampeKueche on)
DOELSEIF
(([MQTT2_Kueche:PIR_Kueche] eq "OFF") and
([?ZWave_BWM_Garage_Lux:LampeKueche] eq "on" and [?TasterKueche:channelA] eq "AI"))
(set Kueche off, setreading ZWave_BWM_Garage_Lux LampeKueche off)
   FUUID      60d6f3c5-f33f-8873-e2e5-9cdebb7f22c81837
   MODEL      FHEM
   NAME       di_LampeKueche
   NOTIFYDEV  global,MQTT2_Kueche
   NR         1280832
   NTFY_ORDER 50-di_LampeKueche
   STATE      cmd_2
   TYPE       DOIF
   VERSION    24595 2021-06-06 17:52:38
   READINGS:
     2021-07-08 21:45:19   Device          MQTT2_Kueche
     2021-07-08 21:45:19   cmd             2
     2021-07-08 21:45:19   cmd_event       MQTT2_Kueche
     2021-07-08 21:45:19   cmd_nr          2
     2021-07-08 21:45:19   e_MQTT2_Kueche_PIR_Kueche OFF
     2021-07-04 07:21:51   mode            enabled
     2021-07-08 21:45:19   state           cmd_2
   Regex:
     accu:
     collect:
     cond:
       MQTT2_Kueche:
         0:
           PIR_Kueche ^MQTT2_Kueche$:^PIR_Kueche:
         1:
           PIR_Kueche ^MQTT2_Kueche$:^PIR_Kueche:
   attr:
     cmdState:
     wait:
     waitdel:
   condition:
     0          (::ReadingValDoIf($hash,'MQTT2_Kueche','PIR_Kueche') eq "ON") and  (::ReadingValDoIf($hash,'ZWave_BWM_Garage_Lux','Helligkeit') < 200 and ::ReadingValDoIf($hash,'TasterKueche','channelA') eq "AI")
     1          (::ReadingValDoIf($hash,'MQTT2_Kueche','PIR_Kueche') eq "OFF") and  (::ReadingValDoIf($hash,'ZWave_BWM_Garage_Lux','LampeKueche') eq "on" and ::ReadingValDoIf($hash,'TasterKueche','channelA') eq "AI")
   devices:
   do:
     0:
       0          set Kueche on, setreading ZWave_BWM_Garage_Lux LampeKueche on
     1:
       0          set Kueche off, setreading ZWave_BWM_Garage_Lux LampeKueche off
     2:
   helper:
     DEVFILTER  ^global$|^MQTT2_Kueche$
     NOTIFYDEV  global|MQTT2_Kueche
     event      PIR_Kueche: OFF
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   MQTT2_Kueche
     timerevent PIR_Kueche: OFF
     triggerDev MQTT2_Kueche
     timerevents:
       PIR_Kueche: OFF
     timereventsState:
       PIR_Kueche: OFF
     triggerEvents:
       PIR_Kueche: OFF
     triggerEventsState:
       PIR_Kueche: OFF
   internals:
   readings:
     all         MQTT2_Kueche:PIR_Kueche
   trigger:
   uiState:
   uiTable:
Attributes:
   room       ZWave

Die Ursache kann ich mir aber überhaupt nicht erklären.
Das Reading Helligkeit ist korrekt vorhanden und wir über folgendes User-Reading erzeugt:
userReadings Helligkeit:luminance:.* {ReadingsNum($name,'luminance',0)}
Die zugehörigen Log-Einträge lauten:
2021-07-09_04:59:08 ZWave_BWM_Garage_Lux luminance: 2 Lux
2021-07-09_05:01:52 ZWave_BWM_Garage_Lux luminance: 3 Lux

Damit hat das reading Helligkeit den Wert "2".
Die anderen readings sehen so aus:
     2021-07-08 21:45:19   LampeKueche     off
     2021-07-08 21:44:43   channelA        AI


Wie gesagt, einen Fehler kann ich nicht erkennen.
Übersehe ich etwas, oder hat sich fhem bzw. doif nur "verhaspelt"?

Norbert

Damian

Deine abgefragten Readings haben zwischendurch nicht numerische Werte. Du kannst aber nach numerischen Werten filtern: https://fhem.de/commandref_DE.html#DOIF_Filtern_nach_Zahlen

hier: [?ZWave_BWM_Garage_Lux:Helligkeit:d]
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Nobbynews

Zitat von: Damian am 09 Juli 2021, 08:43:02
Deine abgefragten Readings haben zwischendurch nicht numerische Werte.
Das da irgendetwas nicht numerisches die Ursache ist, sagt ja schon das warning.
Ich kann  mir halt nur nicht erklären warum.
Durch das User-Reading sollte aus "2 Lux" doch eigentlich "2" und damit ein numerischer Wert werden.
Oder?
Leider habe ich kein Log-File des readings "Helligkeit" sondern nur das Original, also "...: 2 Lux".
Ich logge jetze auch mal das reading "Helligkeit". Vielleicht ergibt sich ja durch Zufall daraus etwas.
Die Sache mit der Filterung schaue ich mir mal an.

Norbert

Otto123

Hallo Norbert,

Die "Fehlermeldung" ist eigentlich nicht zufällig sondern gezielt:

ZitatArgument "" isn't numeric in numeric gt (>) at (eval 8866699) line 1.
Argument "" isn't numeric in numeric eq (==) at (eval 8866699) line 1.
Ich sehe in Deinem Ausdruck kein "größer als" und ich sehe keinen numerischen Vergleich mit "gleich".
mMn stimmt da etwas nicht. Dein gezeigter Code passt nicht zur Meldung.

BTW: die ganzen inneren Klammern sind unnütz!

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Nobbynews

#4
Hallo Otto,
Zitat von: Otto123 am 09 Juli 2021, 09:30:37
Ich sehe in Deinem Ausdruck kein "größer als" und ich sehe keinen numerischen Vergleich mit "gleich".
mMn stimmt da etwas nicht. Dein gezeigter Code passt nicht zur Meldung.
Das ist mir auch aufgefallen, aber ich habe keinen weiteren Hinweis hierzu.
Es gibt zwar noch mehrere doif wie z.B.:
defmod di_Rolladen_Fenster DOIF ([05:00-09:00|7] and \
([ZWave_BWM_Garage_Lux:Helligkeit] >= [ZWave_BWM_Garage_Lux:Fenster]) and \
([ZWave_BWM_Garage_Lux:RolladenFenster] == 0)) \
(set IRBlaster _send Taste1,\
set IRBlaster _send rauf1,\
setreading ZWave_BWM_Garage_Lux RolladenFenster 1,\
set pushHandyNorbert message We Rolladen Fenster hochgefahren)

Darin ist aber auch kein reines ">" enthalten.
Aber ich werde diese mal ändern, da die Abfragen eingentlich nicht triggern sollen.
Zitat von: Otto123 am 09 Juli 2021, 09:30:37
BTW: die ganzen inneren Klammern sind unnütz!
Stimmt natürlich wegen der "and" Verknüpfung.

Norbert

Damian

Welches DOIF betroffen ist, wird in der Warnung angezeigt:

2021.07.09 05:00:00 3: eval: di_LampeKueche: warning in condition c01
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

kumue

aber der Logeintrag ist von Punkt 5Uhr, dem Triggerbeginn von di_Rolladen_Fenster.......

Nobbynews

Zitat von: kumue am 09 Juli 2021, 11:31:18
aber der Logeintrag ist von Punkt 5Uhr, dem Triggerbeginn von di_Rolladen_Fenster.......
Daran dürfte es eigentlich nicht liegen, da ich zwei weitere im Prinzip identische DOIF ebenfalls um 5.00 Uhr starte.

Nobbynews

Heute Morgen war es wieder soweit.
In der Log-Datei wieder die warnings:
2021.07.10 05:00:00 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 9210353) line 1.
2021.07.10 05:00:00 3: eval: di_LampeKueche: warning in condition c01
2021.07.10 05:00:00 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 9210353) line 1.
2021.07.10 05:00:00 3: eval: di_LampeKueche: warning in condition c01

Die Log-Datei vom reading Helligkeit als einzige numerische Abfrage innerhalb des DOIF di_LampeKueche sieht so aus:
2021-07-10_04:55:38 ZWave_BWM_Garage_Lux Helligkeit: 2
2021-07-10_04:59:17 ZWave_BWM_Garage_Lux Helligkeit: 3
2021-07-10_05:01:53 ZWave_BWM_Garage_Lux Helligkeit: 4
2021-07-10_05:03:49 ZWave_BWM_Garage_Lux Helligkeit: 5

Das sollte also eigentlich nicht die Ursache für die Warnungen sein.
Was habe ich jetzt gemacht?
- DOIF di_LampeKueche gelöscht und neu angelegt
- die anderen DOIF von 5:00Uhr als Startzeitpunkt auf 5:01, 5:02 und 5:03 geändert.
So langsam gehen mir die Ideen aus.

Norbert

Nobbynews

#9
Guten Morgen zusammen,

ich habe heute mal den Durchlauf mit stacktrace=1 und global verbose 5 machen lassen.
Ergebnis war wie erwartet, die Warnungen sind wieder im Log. An den anderen DOIF liegt es definitiv nicht, da ich diese ja zeitlich verschoben habe.
Hier das Log:
2021.07.11 04:59:59 5: Cmd: >{BlockingStart('651069')}<
2021.07.11 05:00:00 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 9554991) line 1.
2021.07.11 05:00:00 3: eval: di_LampeKueche: warning in condition c01
2021.07.11 05:00:00 1: stacktrace:
2021.07.11 05:00:00 1:     main::__ANON__                      called by (eval 9554991) (1)
2021.07.11 05:00:00 1:     (eval)                              called by ./FHEM/98_DOIF.pm (2339)
2021.07.11 05:00:00 1:     main::DOIF_CheckCond                called by ./FHEM/98_DOIF.pm (2683)
2021.07.11 05:00:00 1:     main::DOIF_Trigger                  called by ./FHEM/98_DOIF.pm (3052)
2021.07.11 05:00:00 1:     main::DOIF_TimerTrigger             called by fhem.pl (3425)
2021.07.11 05:00:00 1:     main::HandleTimeout                 called by fhem.pl (696)
2021.07.11 05:00:00 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 9554991) line 1.
2021.07.11 05:00:00 3: eval: di_LampeKueche: warning in condition c01
2021.07.11 05:00:00 1: stacktrace:
2021.07.11 05:00:00 1:     main::__ANON__                      called by (eval 9554991) (1)
2021.07.11 05:00:00 1:     (eval)                              called by ./FHEM/98_DOIF.pm (2339)
2021.07.11 05:00:00 1:     main::DOIF_CheckCond                called by ./FHEM/98_DOIF.pm (2683)
2021.07.11 05:00:00 1:     main::DOIF_Trigger                  called by ./FHEM/98_DOIF.pm (3052)
2021.07.11 05:00:00 1:     main::DOIF_TimerTrigger             called by fhem.pl (3425)
2021.07.11 05:00:00 1:     main::HandleTimeout                 called by fhem.pl (696)
2021.07.11 05:00:00 5: Cmd: >{SYSMON_blockingFinish('name|sysmon|eth0_speed|100|cpu_idle_stat|33.15 98.50 94.02|fhemuptime_text|27 days, 20

Hier fällt mir nur auf, dass unmittelbar zuvor ein Blocking Call von Sysmon startet und erst nach den Warnungen als beendet eingetragen ist.
Kann es daran liegen?

Jetzt probiere ich noch die Filteroption aus.

Edit:
Aktuell sieht das DOIF so aus:
defmod di_LampeKueche DOIF ([MQTT2_Kueche:PIR_Kueche] eq "ON" and\
[?ZWave_BWM_Garage_Lux:Helligkeit:d] < 200 and [?TasterKueche:channelA] eq "AI")\
(set Kueche on, setreading ZWave_BWM_Garage_Lux LampeKueche on)\
DOELSEIF\
([MQTT2_Kueche:PIR_Kueche] eq "OFF" and\
[?ZWave_BWM_Garage_Lux:LampeKueche] eq "on" and [?TasterKueche:channelA] eq "AI")\
(set Kueche off, setreading ZWave_BWM_Garage_Lux LampeKueche off)   

Triggern dürfte doch eigentlich nur ein Event von PIR_Kueche, oder?
Das Reading hat sich aber seit gestern 18:09 nicht mehr geändert.
Warum wurde also um 5:00 Uhr das DOIF angestoßen??

Norbert.

Damian

#10
Du musst immer ein komplettes List vom betroffenen Device kurz nach dem Fehlerfall liefert. Da kann man diverse Dinge sehen, die man an der Definition selbst nicht erkennen kann.

Edit: Irgendwie passen die Angaben nicht zum definierten Device, der Auslöser ist hier ein Timertrigger, di_LampeKueche hat aber keine Timer???
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Otto123

Moin,

ich will nochmal meine Aussage aus #3 untermauern! Dazu ein kleines Testszenario:
defmod di_test DOIF ([Test:willi] < 5)()

defmod Test dummy
attr Test readingList willi
attr Test setList willi

Man kann damit einfach mal verschiedene Werte ins Reading setzen (auch Leer lassen) und auch das < gegen > tauschen. Die Warnungen im Log sind präzise!
Da steht der gelesene Wert in Anführungszeichen drin.
Der Operator steht richtig da!
Damit sage ich nochmal:
Das gelesene Reading hier im Thread ist leer, das bedeutet mEn in 99% der Fälle: nicht vorhanden, meist sogar wegen Schreibfehler.
Die Warnungen haben nichts mit dem gezeigtem / untersuchten Device oder Code zu tun!!!

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Nobbynews

Zitat von: Damian am 11 Juli 2021, 09:57:20
Du musst immer ein komplettes List vom betroffenen Device kurz nach dem Fehlerfall liefert. Da kann man diverse Dinge sehen, die man an der Definition selbst nicht erkennen kann.
Edit: Irgendwie passen die Angaben nicht zum definierten Device, der Auslöser ist hier ein Timertrigger, di_LampeKueche hat aber keine Timer???
[/quote]
Das aktuelle List
Internals:
   CFGFN     
   DEF        ([MQTT2_Kueche:PIR_Kueche] eq "ON" and
[?ZWave_BWM_Garage_Lux:Helligkeit:d] < 200 and [?TasterKueche:channelA] eq "AI")
(set Kueche on, setreading ZWave_BWM_Garage_Lux LampeKueche on)
DOELSEIF
([MQTT2_Kueche:PIR_Kueche] eq "OFF" and
[?ZWave_BWM_Garage_Lux:LampeKueche] eq "on" and [?TasterKueche:channelA] eq "AI")
(set Kueche off, setreading ZWave_BWM_Garage_Lux LampeKueche off)
   FUUID      60e91217-f33f-8873-9b18-58b072e58192587c
   MODEL      FHEM
   NAME       di_LampeKueche
   NOTIFYDEV  global,MQTT2_Kueche
   NR         2643495
   NTFY_ORDER 50-di_LampeKueche
   STATE      cmd_2
   TYPE       DOIF
   VERSION    24595 2021-06-06 17:52:38
   READINGS:
     2021-07-11 09:57:02   Device          MQTT2_Kueche
     2021-07-11 06:48:13   cmd             2
     2021-07-11 06:48:13   cmd_event       di_LampeKueche
     2021-07-11 06:48:13   cmd_nr          2
     2021-07-11 09:57:02   e_MQTT2_Kueche_PIR_Kueche OFF
     2021-07-11 06:47:56   mode            enabled
     2021-07-11 06:48:13   state           cmd_2
   Regex:
     accu:
     collect:
     cond:
       MQTT2_Kueche:
         0:
           PIR_Kueche ^MQTT2_Kueche$:^PIR_Kueche:
         1:
           PIR_Kueche ^MQTT2_Kueche$:^PIR_Kueche:
   attr:
     cmdState:
     wait:
     waitdel:
   condition:
     0          ::ReadingValDoIf($hash,'MQTT2_Kueche','PIR_Kueche') eq "ON" and  ::ReadingValDoIf($hash,'ZWave_BWM_Garage_Lux','Helligkeit','','d') < 200 and ::ReadingValDoIf($hash,'TasterKueche','channelA') eq "AI"
     1          ::ReadingValDoIf($hash,'MQTT2_Kueche','PIR_Kueche') eq "OFF" and  ::ReadingValDoIf($hash,'ZWave_BWM_Garage_Lux','LampeKueche') eq "on" and ::ReadingValDoIf($hash,'TasterKueche','channelA') eq "AI"
   do:
     0:
       0          set Kueche on, setreading ZWave_BWM_Garage_Lux LampeKueche on
     1:
       0          set Kueche off, setreading ZWave_BWM_Garage_Lux LampeKueche off
     2:
   helper:
     DEVFILTER  ^global$|^MQTT2_Kueche$
     NOTIFYDEV  global|MQTT2_Kueche
     event      PIR_Kueche: OFF
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   
     timerevent
     timerevents
     timereventsState
     triggerDev MQTT2_Kueche
     triggerEvents:
       PIR_Kueche: OFF
     triggerEventsState:
       PIR_Kueche: OFF
   internals:
   readings:
     all         MQTT2_Kueche:PIR_Kueche
   trigger:
   uiState:
   uiTable:
Attributes:
   room       ZWave
   verbose    5

zeigt auch nur PIR_Kueche als trigger.

Norbert

Nobbynews

Zitat von: Otto123 am 11 Juli 2021, 10:06:15
Damit sage ich nochmal:
Das gelesene Reading hier im Thread ist leer, das bedeutet mEn in 99% der Fälle: nicht vorhanden, meist sogar wegen Schreibfehler.
Die Warnungen haben nichts mit dem gezeigtem / untersuchten Device oder Code zu tun!!!
Aber warum steht dann im Log
2021.07.09 05:00:00 3: eval: di_LampeKueche: warning in condition c01
Das die logischen Verknüpfungen nicht zum device passen ist klar.

Norbert

Damian

Die Angaben um 09:57:02 sind uninteressant. Um 05:00:00 Uhr war das Problem.

Du solltest in global mseclog setzen, damit man die zeitliche Reihenfolge erkennen kann.


Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF