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
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]
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
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
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
Welches DOIF betroffen ist, wird in der Warnung angezeigt:
2021.07.09 05:00:00 3: eval: di_LampeKueche: warning in condition c01
aber der Logeintrag ist von Punkt 5Uhr, dem Triggerbeginn von di_Rolladen_Fenster.......
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.
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
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.
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???
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
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 5zeigt auch nur PIR_Kueche als trigger.
Norbert
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 c01Das die logischen Verknüpfungen nicht zum device passen ist klar.
Norbert
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.
Zitat von: Damian am 11 Juli 2021, 10:16:13
Die Angaben um 09:57:02 sind uninteressant. 05:00:00 Uhr war das Problem.
Na ja, das war mir schon klar, dass das nichts mit dem Zeitpunt der Warnungen zu tun hat.
mseclog werde ich mal setzen.
Zusätzlich habe ich in denDOIFtools mal set specialLog 1 gesetzt.
Norbert
Zitat von: Nobbynews am 11 Juli 2021, 10:19:48
Na ja, das war mir schon klar, dass das nichts mit dem Zeitpunt der Warnungen zu tun hat.
mseclog werde ich mal setzen.
Zusätzlich habe ich in denDOIFtools mal set specialLog 1 gesetzt.
Norbert
Die Warnung muss aus einem DOIF-Device kommen, welches ein > und == in der ersten Bedingung hat. Mit mseclog kann man erkennen, ob die beiden Meldungen im gleichen Evenblock sind, also aus dem gleichen Device kommen.
Zitat von: Damian am 11 Juli 2021, 10:23:12
Die Warnung muss aus einem DOIF-Device kommen, welches ein > und == in der ersten Bedingung hat.
Meine Rede seit #3 ihr jagt die falsche Sau ;)
Zitat von: Damian am 11 Juli 2021, 10:23:12
Die Warnung muss aus einem DOIF-Device kommen, welches ein > und == in der ersten Bedingung hat.
Ob ihr es glaubt oder nicht, ein solches DOIF habe ich nicht definiert.
Norbert
ich bin für "oder nicht" :) - definiere Dir mal den alias grep und suche nach ==
https://wiki.fhem.de/wiki/Cmdalias
Zitat von: Otto123 am 11 Juli 2021, 11:16:06
ich bin für "oder nicht" :) - definiere Dir mal den alias grep und suche nach ==
fhem.cfg:if (($hour >= 5 && $hour < 7) && (ReadingsNum("Ferien","state",1) == 1))\
fhem.cfg:if (($hour >= 5 && $hour < 7) && (ReadingsVal("Ferien","state",0) == 0))\
fhem.cfg: fhem("set Ferien $stat") if defined fhem('get '.$NAME.' events filter:uid=="'.\
fhem.cfg: if (ReadingsNum("Ferien","state",0) == 0){\
fhem.cfg:if ($EVENT == 1){\
fhem.cfg:elsif ($EVENT == 0){\
fhem.cfg:define Bogen_Schule_inSchule WeekdayTimer Bogen de 245|05:35|on 245|06:50:02|off (ReadingsVal("Ferien","state",0) == 0)
fhem.cfg:(ReadingsVal("Ferien","state",0) ==0)
fhem.cfg:(ReadingsVal("Ferien","state",0) == 1)
fhem.cfg:if ($wday == 1) {\
fhem.cfg:(ReadingsVal("Ferien","state",0) == 1)
fhem.cfg:attr MQTT2_Garagentor userReadings state:.* {if (ReadingsNum($name,"State",0) == 0){sprintf("off")} else {sprintf("on")}}
fhem.cfg:if ($EVTPART1 == 1){\
fhem.cfg:#if ($EVTPART1 == 1){\
fhem.cfg:if ($we == 1){\
fhem.cfg:if ($we == 0){\
fhem.cfg: [?ZWave_BWM_Garage_Lux:RolladenKueche] == 0)\
fhem.cfg:attr di_Rolladen_Kueche comment {if ([05:00-09:00|7] and ([ZWave_BWM_Garage_Lux:Helligkeit] >= [ZWave_BWM_Garage_Lux:Morgens_Kue_WE]) and ([ZWave_BWM_Garage_Lux:RolladenKue] == 0)) \
fhem.cfg:[?ZWave_BWM_Garage_Lux:RolladenFenster] == 0)\
fhem.cfg: [?ZWave_BWM_Garage_Lux:RolladenTuer] == 0)\
FHEM/99_SUNRISE_EL.pm: $sst -= $nh if($isrel == 1);
FHEM/99_SUNRISE_EL.pm: $x++ if($m > 2 && ($y%4) == 0);
FHEM/99_myUtils.pm:if ($gefunden == 0)
FHEM/99_myUtils.pm:if ($gefunden == 0 )Jedenfalls sehe ich da nichts, was ">" und "==" in einem device hat.
Oder habe ich Tomaten auf den Augen?
Edit: Sollte es etwa an dem 99_SUNRISE_EL liegen??
Norbert
bis auf >= würde es eher dazu passen:
di_Rolladen_Kueche comment {if ([05:00-09:00|7] and ([ZWave_BWM_Garage_Lux:Helligkeit] >= [ZWave_BWM_Garage_Lux:Morgens_Kue_WE]) and ([ZWave_BWM_Garage_Lux:RolladenKue] == 0))
Um 05:00 Uhr gibt es einen Zeittrigger und es gibt die anderen Vergleiche.
Zitat von: Damian am 11 Juli 2021, 11:29:26
bis auf >= würde es eher dazu passen:
di_Rolladen_Kueche comment {if ([05:00-09:00|7] and ([ZWave_BWM_Garage_Lux:Helligkeit] >= [ZWave_BWM_Garage_Lux:Morgens_Kue_WE]) and ([ZWave_BWM_Garage_Lux:RolladenKue] == 0))
Um 05:00 Uhr gibt es einen Zeittrigger und es gibt die anderen Vergleiche.
Das ist ein Eintrag im attr comment. Sollte also völlig außen vor sein.
Die Definition zu diesem DOIF habe ich gestern schon geändert in:
defmod di_Rolladen_Kueche DOIF ([05:02-09:00] and \
[ZWave_BWM_Garage_Lux:Helligkeit] >= [?ZWave_BWM_Garage_Lux:Kueche] and \
[?ZWave_BWM_Garage_Lux:RolladenKueche] == 0)\
(set MQTT2_Kueche rauf,\
setreading ZWave_BWM_Garage_Lux RolladenKueche 1,\
set pushHandyNorbert message We RolladenKueche hochgefahren)Norbert
grep liefert natürlich nur einzelne Zeilen, in dem Moment wo Struktur in der DEF ist (Zeilenumbrüche) wird es schwierig. Also da musst Du manuell nachsuchen ;)
Was aktuell im System definiert/aktiv ist, kann man immer mit list sehen, alles andere ist nicht aussagekräftig.
Guten Morgen,
was soll ich sagen, Murphy hat zugeschlagen.
Heute Morgen keine Warnungen im Log, kein Triggern. Das Debug-File der DOIFTools gibt auch nichts her.
Was habe ich zwischenzeitlich gemacht:
- die Option :d an die numerische Abfrage angefügt
- FHEM neu gestartet
Zum Test habe ich jetzt noch einmal die Option :d gelöscht.
Norbert
Zitat von: Otto123 am 11 Juli 2021, 11:33:27
grep liefert natürlich nur einzelne Zeilen, in dem Moment wo Struktur in der DEF ist (Zeilenumbrüche) wird es schwierig. Also da musst Du manuell nachsuchen ;)
Ach so und: diese Form des grep alias sucht in den Dateien, aber nicht in der aktiven config im Speicher die noch nicht gespeichert ist. -> Neustart?
Guten Morgen,
heute gab es auch ohne die Option :d keine Warnungen im Log.
Kann es sein, dass es tatsächlich nur am fehlenden Neustart von FHEM lag??
Norbert
Guten Morgen,
so wie es aussieht, hat sich das Thema mit den "merkwürdigen" Warnings erledigt.
Norbert