Seit dem Update heute morgen funktioniert set ... addLog bei mir nicht mehr. Weder per at getriggert noch manuell.
In der svn-history sehe ich, dass an addLog rumgeschraubt wurde.
Hab ich irgendwas verpaßt?
Mit der vorherigen Version #16577 von DbLog ist alles prima.
Hallo betateilchen,
in den letzten 1-2 Wochen sind beim addlog Funktionalitäten hinzugekommen, wie die Berücksichtigung von DbLogExclude, siehe:
https://forum.fhem.de/index.php/topic,65860.msg785073.html#msg785073
Wenn es daran liegt, dann einfach "!useExcludes" in den Aufruf des addLog mit einfügen.
Ansonsten zeig mal deinen Aufruf und ich schaue heute Abend nochmal danach.
LG,
Heiko
- bei mir gibt es keine DbLogExcludes, weil das für mich eine der sinnlosesten Funktionalitäten in FHEM überhaupt ist.
- ich will nicht 224 addLog Aufrufe ändern müssen
Meine Aufrufe sehen alle so aus
set fhemDbLog addLog <device>:<reading> und haben bis gestern einwandfrei funktioniert.
Welchen Nutzen hätte es eigentlich, bei einem explizit auszuführenden Befehl addLog, mit dem ich als Anwender (!) einen Wert
ausdrücklich in das Log bekommen will, nochmal zu prüfen, ob der Wert über Exclude ausgeschlossen ist? Das ist doch völlig absurd.
Wenn ich als Anwender diesen Befehl aufrufe, dann hat der gefälligst ausgeführt zu werden.
Wenn eh keine DbLogExcludes bei dir drin sind ist auch nichts zu ändern.
Natürlich wundert es mich dass dein doch simpler Aufruf nicht mehr funktioniert, da schaue ich heute Abend gleich danach.
Die Berücksichtigung der evtl. gesetzten DbLogExcludes war vor allem dafür gedacht wenn der addLog Aufruf statt device devspec verwendet bzw. Regex im Reading und dann die per se nicht gewünschten Excludes berücksichtigt werden.
Komisch ist eben dass bei den ganzen Tests es nicht aufgefallen ist, wie gesagt ich schaue nachher gleich ...
Zitat von: DS_Starter am 11 April 2018, 16:15:42
Komisch ist eben dass bei den ganzen Tests es nicht aufgefallen ist, wie gesagt ich schaue nachher gleich ...
Das Problem dürfte darin liegen, dass der Event ohne TimeStamp in die Datenbank geschrieben wird.
Das heißt, es gibt zwar einen Datensatz in der Datenbank, aber der wird von einem get() aus SVG nicht gefunden.
2018.04.11 17:24:34.460 4: DbLog fhemDbLog -> Addlog known devices by devspec: wz_FuBo
2018.04.11 17:24:34.460 4: DbLog fhemDbLog -> Readings extracted from Regex: level
2018.04.11 17:24:34.461 3: DbLog fhemDbLog -> addLog created - TS: , Device: wz_FuBo, Type: CUL_HM, Event: addLog, Reading: level, Value: 0, Unit:
2018.04.11 17:24:34.461 4: DbLog fhemDbLog -> ################################################################
2018.04.11 17:24:34.461 4: DbLog fhemDbLog -> ### New database processing cycle - synchronous ###
2018.04.11 17:24:34.461 4: DbLog fhemDbLog -> ################################################################
2018.04.11 17:24:34.461 4: DbLog fhemDbLog -> DbLogType is: History
2018.04.11 17:24:34.462 4: DbLog fhemDbLog -> AutoCommit mode: OFF, Transaction mode: ON
2018.04.11 17:24:34.466 5: DbLog fhemDbLog -> Primary Key used in /opt/fhem/sqldb/logDBprodfhem.db.history: none
2018.04.11 17:24:34.466 5: DbLog fhemDbLog -> Primary Key used in /opt/fhem/sqldb/logDBprodfhem.db.current: none
2018.04.11 17:24:34.467 4: DbLog fhemDbLog -> processing event Timestamp: , Device: wz_FuBo, Type: CUL_HM, Event: addLog, Reading: level, Value: 0, Unit:
2018.04.11 17:24:34.468 4: DbLog fhemDbLog -> 1 of 1 events inserted into table history
2018.04.11 17:24:34.470 4: DbLog fhemDbLog -> insert table history committed by autocommit
2018.04.11 17:24:34.471 5: DbLog fhemDbLog -> DbLog_Push Returncode: 0
In der vorherigen Version von 93_DbLog.pm (16577) sieht das Ganze so aus:
2018.04.11 17:28:06.936 4: DbLog fhemDbLog -> Addlog known devices by devspec: wz_FuBo
2018.04.11 17:28:06.937 4: DbLog fhemDbLog -> Readings extracted from Regex: level
2018.04.11 17:28:06.937 3: DbLog fhemDbLog -> addLog created - TS: 2018-04-11 17:28:06, Device: wz_FuBo, Type: CUL_HM, Event: addLog, Reading: level, Value: 0, Unit:
2018.04.11 17:28:06.938 4: DbLog fhemDbLog -> ################################################################
2018.04.11 17:28:06.938 4: DbLog fhemDbLog -> ### New database processing cycle - synchronous ###
2018.04.11 17:28:06.938 4: DbLog fhemDbLog -> ################################################################
2018.04.11 17:28:06.938 4: DbLog fhemDbLog -> DbLogType is: History
2018.04.11 17:28:06.938 4: DbLog fhemDbLog -> AutoCommit mode: OFF, Transaction mode: ON
2018.04.11 17:28:06.943 5: DbLog fhemDbLog -> Primary Key used in /opt/fhem/sqldb/logDBprodfhem.db.history: none
2018.04.11 17:28:06.943 5: DbLog fhemDbLog -> Primary Key used in /opt/fhem/sqldb/logDBprodfhem.db.current: none
2018.04.11 17:28:06.943 4: DbLog fhemDbLog -> processing event Timestamp: 2018-04-11 17:28:06, Device: wz_FuBo, Type: CUL_HM, Event: addLog, Reading: level, Value: 0, Unit:
2018.04.11 17:28:06.944 4: DbLog fhemDbLog -> 1 of 1 events inserted into table history
2018.04.11 17:28:06.947 4: DbLog fhemDbLog -> insert table history committed by autocommit
2018.04.11 17:28:06.948 5: DbLog fhemDbLog -> DbLog_Push Returncode: 0
Wenn Du die Warnungen für "uninitialized" nicht deaktiviert hättest, bekäme man auch eine PERL WARNING im Log, in der genau die Ursache für das Problem stünde 8)
# Anwender spezifische Funktion anwenden
if($value_fn ne '') {
$ts = TimeNow();
Du initialisierst die Variable $ts nur dann mit einem Wert, wenn es eine anwenderspezifische Funktion gibt.
Setzt man die Initialisierung vor die Prüfung, funktioniert alles wie gewünscht.
fhem-rpi3:/opt/fhem/FHEM# svn diff 93_DbLog.pm
Index: 93_DbLog.pm
===================================================================
--- 93_DbLog.pm (Revision 16585)
+++ 93_DbLog.pm (Arbeitskopie)
@@ -3638,9 +3638,10 @@
$defs{$dev_name}{Helper}{DBLOG}{$dev_reading}{$hash->{NAME}}{TIME} = $now;
$defs{$dev_name}{Helper}{DBLOG}{$dev_reading}{$hash->{NAME}}{VALUE} = $read_val;
+$ts = TimeNow();
# Anwender spezifische Funktion anwenden
if($value_fn ne '') {
- $ts = TimeNow();
+# $ts = TimeNow();
my $TIMESTAMP = $ts;
my $DEVICE = $dev_name;
my $DEVICETYPE = $dev_type;
@@ -7212,4 +7213,4 @@
</ul>
=end html_DE
-=cut
\ No newline at end of file
+=cut
Danke Udo, korrigiere ich gleich 8)
Dann korrigiere bitte das fehlende Zeilenende am Ende der Moduldatei auch gleich :)
So, sollte nun passen und eingecheckt.
Habe noch den Fehler gefunden/korrigiert den Joe in dem allg. dblog-Thread gemeldet hatte.
Danke und Grüße,
Heiko
sieht erstmal gut aus, was den von mir festgestellten Fehler angeht. Danke.