Hallo Heiko,
ich habe momentan mit einem OneWire-Device Probleme. Bis ist das gelöst habe, wollte ich die "schlechten" Werte filtern, also nicht in die Datenbank schreiben.
Die Werte alle um die -60:
Zitat
2023-01-22_15-04-12__1__USV_Batterie__temperature -62.8 °C
2023-01-22_15-05-12__1__USV_Batterie__temperature 21.4 °C
2023-01-22_15-16-12__1__USV_Batterie__temperature -60.8 °C
2023-01-22_15-17-12__1__USV_Batterie__temperature 21.5 °C
2023-01-22_15-21-12__1__USV_Batterie__temperature -61.8 °C
2023-01-22_15-22-12__1__USV_Batterie__temperature 21.6 °C
im entsprechenden Device habe ich DbLogValueFn gesetzt, zu erst mit <0, ohne Auswirkung.
{if ($READING eq "temperature" && $VALUE < 1) {
$IGNORE=1;
}Das hat aber keine Auswirkung. Kann es sein, dass bei '<' negative Zahlen nicht berücksichtigt werden?
Ich habe auch D18B20, da filtere ich mit $VALUE == -127, was funktioniert.
Nachtrag:
93_DbLog.pm:v5.6.0-s27029/2023-01-11
LG
Bernd
Schonmal einen Blick ins Logfile geworfen?
Spontan würde ich sagen, da fehlt eine schließende geschweifte Klammer am Ende.
Zitat von: betateilchen am 22 Januar 2023, 17:37:04
Schonmal einen Blick ins Logfile geworfen?
Spontan würde ich sagen, da fehlt eine schließende geschweifte Klammer am Ende.
Du hast Recht, danke.
Trotz mehrfacher Kontrolle nicht aufgefallen und die Syntax-Überprüfung von Fhem hat es auch nicht bemerkt. :o
Zitat von: frober am 22 Januar 2023, 17:54:07
die Syntax-Überprüfung von Fhem hat es auch nicht bemerkt.
Das wird von FHEM nicht geprüft.
Zitat von: betateilchen am 22 Januar 2023, 17:54:59
Das wird von FHEM nicht geprüft.
Ok, wusste ich nicht. Werde ich mir merken, hoffentlich. ;)
Nachtrag: Im Log stand nichts, habe aber auch alles auf Verbose 1. Scheinbar kein kritischer Fehler...
Zitat von: frober am 22 Januar 2023, 17:56:51
Scheinbar kein kritischer Fehler...
Naja, es ist ein Syntaxfehler. Allerdings weiß ich nicht, ob DbLog das überhaupt logged.
Ah ja ...
das Attr valueFn prüfe ich beim Setzen, aber die Prüfung von DbLogValueFn ist mir durchgerutscht. :o
Das hole ich jetzt nach.
Edit: Geht zumindest im DbLog selbst. Ansonsten ist es ja ein globales Attribut welches Device spezifisch gesetzt wird. Blöd, dann kann ich es ja nicht prüfen.
Beim Setzen kannst Du das vermutlich nicht prüfen. Aber die Ausführung der DbLogValueFn() müsste doch nach meinem Verständnis in DbLog erfolgen - und wenn dabei ein Fehler auftritt, sollte er zumindest im Log auftauchen.
Ja das stimmt. Das schaue ich mir an.
Zitat von: DS_Starter am 22 Januar 2023, 18:22:48
Ja das stimmt. Das schaue ich mir an.
Dann hat meine "Blödheit" doch was bewirkt. ;)
Danke
Die Praxis im täglichen Umgang ist immer der Prüfstein Bernd. :D
Zitat von: DS_Starter am 22 Januar 2023, 18:27:33
Die Praxis im täglichen Umgang
nette Umschreibung für "DAU" 8)
Ich habe den Syntaxcheck im DbLog erweitert.
Die Attr valueFn und DbLogValueFn werden bei der Eingabe direkt gepfüft (sofern DbLogValueFn im DbLog-Device selbst gesetzt wird).
Das Attr DbLogValueFn in einem Quellendevice kann ich, wie geschrieben, nicht direkt bei der Eingabe prüfen.
Aber jetzt erfolgt in diesem Fall eine Prüfung der Syntax vor der Anwendung des Codes.
Bei einem Fehler erfolgt die Ausgabe im Log unter Angabe welches Device die fehlerhafte Attributsyntax enthält:
2023.01.22 20:59:23.704 1: DbLog LogSQLITE3 - Syntaxcheck <MySTP_5000> attribute DbLogValueFn:
Bareword "failureval" not allowed while "strict subs" in use at (eval 3739) line 7.
Die V liegt zunächst in meinem contrib zum Gegencheck wenn Bernd oder ein anderer User es mal ausprobieren möchte.
LG
Danke Heiko, das war jetzt aber schnell. :)
Gerne werde ich es Morgen Abend testen.
Grüße und schönen Sonntag noch.
Hatte gerade nichts besseres vor. ;)
Danke und dir/euch auch noch einen schönen Abend.
Zitat von: DS_Starter am 22 Januar 2023, 21:08:57
Ich habe den Syntaxcheck im DbLog erweitert.
Die Attr valueFn und DbLogValueFn werden bei der Eingabe direkt gepfüft (sofern DbLogValueFn im DbLog-Device selbst gesetzt wird).
Das Attr DbLogValueFn in einem Quellendevice kann ich, wie geschrieben, nicht direkt bei der Eingabe prüfen.
Aber jetzt erfolgt in diesem Fall eine Prüfung der Syntax vor der Anwendung des Codes.
Bei einem Fehler erfolgt die Ausgabe im Log unter Angabe welches Device die fehlerhafte Attributsyntax enthält:
2023.01.22 20:59:23.704 1: DbLog LogSQLITE3 - Syntaxcheck <MySTP_5000> attribute DbLogValueFn:
Bareword "failureval" not allowed while "strict subs" in use at (eval 3739) line 7.
Die V liegt zunächst in meinem contrib zum Gegencheck wenn Bernd oder ein anderer User es mal ausprobieren möchte.
LG
Hallo Heiko,
getestet und für gut befunden, danke. :)
Bei valueFn und DbLogValueFn direkt im DbLog-Device erfolgt eine Warnmeldung und das attr wird nicht gesetzt.
Im Quellendevice ergibt...
...die vergessene Klammer folgendes im Log:
2023.01.23 18:22:09 1: ERROR evaluating my $CN= $evalSpecials->{'%CN'};my $DEVICE= $evalSpecials->{'%DEVICE'};my $DEVICETYPE= $evalSpecials->{'%DEVICETYPE'};my $EVENT= $evalSpecials->{'%EVENT'};my $EVTPART0= $evalSpecials->{'%EVTPART0'};my $IGNORE= $evalSpecials->{'%IGNORE'};my $LASTTIMESTAMP= $evalSpecials->{'%LASTTIMESTAMP'};my $LASTVALUE= $evalSpecials->{'%LASTVALUE'};my $READING= $evalSpecials->{'%READING'};my $TIMESTAMP= $evalSpecials->{'%TIMESTAMP'};my $UNIT= $evalSpecials->{'%UNIT'};my $VALUE= $evalSpecials->{'%VALUE'};{return undef; {if ($READING eq "temperature" && $VALUE < 10) {
$IGNORE=1;
}
elsif ($READING eq "voltage" && ($VALUE < 0 || $VALUE > 20)) {
$IGNORE=1;
}
elsif ($READING eq "current" && ($VALUE < -1000 || $VALUE > 1000)) {
$IGNORE=1;
}
elsif ($READING eq "capacity" && ($VALUE < 0 || $VALUE > 2600)) {
$IGNORE=1;
}}: Missing right curly or square bracket at (eval 4575) line 12, at end of line
syntax error at (eval 4575) line 12, at EOF
2023.01.23 18:22:09 1: DbLog syncdb - Syntaxcheck <USV_Batterie> attribute DbLogValueFn:
Missing right curly or square bracket at (eval 4575) line 12, at end of line
syntax error at (eval 4575) line 12, at EOF
...ein Tippfehler:
Zitat2023.01.23 18:14:09 1: ERROR evaluating my $CN= $evalSpecials->{'%CN'};my $DEVICE= $evalSpecials->{'%DEVICE'};my $DEVICETYPE= $evalSpecials->{'%DEVICETYPE'};my $EVENT= $evalSpecials->{'%EVENT'};my $EVTPART0= $evalSpecials->{'%EVTPART0'};my $IGNORE= $evalSpecials->{'%IGNORE'};my $LASTTIMESTAMP= $evalSpecials->{'%LASTTIMESTAMP'};my $LASTVALUE= $evalSpecials->{'%LASTVALUE'};my $READING= $evalSpecials->{'%READING'};my $TIMESTAMP= $evalSpecials->{'%TIMESTAMP'};my $UNIT= $evalSpecials->{'%UNIT'};my $VALUE= $evalSpecials->{'%VALUE'};{return undef; {if ($READING eq "temperature" && $VALUE < 10) {
$IGNORE=1;
}
elif ($READING eq "capacity" && ($VALUE < 0 || $VALUE > 2600)) {
$IGNORE=1;
}
}}: syntax error at (eval 1307) line 10, near ") {"
Ist etwas verwirrend, liegt aber am Syntaxcheck und nicht an deinem Code, denke ich.
LG
Bernd
Zitat von: frober am 23 Januar 2023, 18:44:10
Zitat
elif ($READING eq "capacity" && ($VALUE < 0 || $VALUE > 2600)) {
...
}}: syntax error at (eval 1307) line 10, near ") {"
Tippfehler: Ist etwas verwirrend, liegt aber am Syntaxcheck und nicht an deinem Code, denke ich.
Nein, das ist völlig ok so. Perl erkennt erst an den beiden rot markierten Klammern, dass irgendwo davor ein Fehler aufgetreten ist.
Deshalb sagt die Fehlermeldung ja auch "near" und nicht "at" - die genaue Stelle kann von perl in diesem Fall nicht ermittelt werden.
Danke für das Gegenchecken.
Mir war es wichtig dem User die Quelle des Fehlers auszugeben:
DbLog ..... - Syntaxcheck <USV_Batterie> attribute DbLogValueFn ...
weil es ansonsten schwierig werden kann die Quelle zu finden wenn viele DbLogValueFn gesetzt sind.
Sonst hätte die im fhem.pl eingebaute Ausgabe:
ERROR evaluating ....
ausgereicht.
Aber ich denke der User wird normalerweise umgehend versuchen seinen Fehler zu beseitigen.
Ich checke die Version ein und ist morgen im Update enthalten.
Danke euch.
LG,
Heiko
Zitat von: DS_Starter am 23 Januar 2023, 19:29:09
Ich checke die Version ein und ist morgen im Update enthalten.
Danke euch.
dann hast Du ja jetzt Zeit, als nächstes Log2Syslog gegen Rudis heutige Änderung zu fixen 8)
Das ist der Plan :D