Hallo zusammen,
ich hab ein kleines Problem, das ich auch mit lesen im Forum noch nicht lösen konnte. Einige Threats habe ich zwar gefunden aber irgendwie haben mir die alle noch nicht so wirklich weitergeholfen.
Konfiguriert habe ich einen Dummy, der meinen Öltank darstellt.
Dann gibt es ein Notify, das basierend auf Informationen von der Heitzung (HTTPMOD) den aktuellen Ölverbrauch berechnet und in den Dummy schreibt. Dazu gibt es dann auch einen Statistik, die die Verbräuch auf Tages, Wochen und Monatsbasis berechnet. All diese Werte würde ich nun gerne in mein DBlog schreiben, damit ich sie am Ende auch auswerten kann.
Insgesamt funktioniert das Zusammenspiel gut und ich bekomme alle Werte die ich haben möchte. Ich bekomme sie nur nicht in das DBlog geschrieben :(
Konfiguriert ist alles so, dass alle Werte Devices geloggt werden aber nur Readings, die in DBLogInclude stehen.
Jetzt habe ich auch bei dem Dummy einfach alle Readings, die ich im Log haben möchte, in DBLogInclude geschrieben aber das Log bleibt leer :(
Hat jemand eine Idee, was falsch ist?
Hier noch die Listings von den Devices:
Oeltank:
Internals:
NAME Oeltank
NR 152
STATE Ölstand: 4573.615 Liter
TYPE dummy
Helper:
DBLOG:
Oelstand:
LogDB:
TIME 1517830281.344
VALUE 4573.615
last_consumption:
LogDB:
TIME 1517830281.36672
VALUE 0.391
statistik_OelstandDay1:
LogDB:
TIME 1517785195.04212
VALUE -13.495
statistik_OelstandDay30:
LogDB:
TIME 1517785195.04212
VALUE -356.078
statistik_OelstandDay5:
LogDB:
TIME 1517785195.04212
VALUE -71.434
READINGS:
2018-02-05 12:31:21 Oelstand 4573.615
2017-12-30 12:11:07 Oeltank_aufgefuellt 29.12.2017
2018-02-05 12:31:21 last_Runtime1 838259
2018-02-05 12:31:21 last_Runtime2 310147
2018-02-05 12:31:21 last_consumption 0.391
2017-12-29 16:16:23 state ""
2018-02-05 12:59:55 statistik_Oelstand Hour: 0.000 Day: -8.193 Month: -58.861 Year: -403.015
2018-02-04 23:59:55 statistik_OelstandDay1 -13.495
2018-02-04 23:59:55 statistik_OelstandDay30 -356.078
2018-02-04 23:59:55 statistik_OelstandDay5 -71.434
2018-02-05 12:59:55 statistik_OelstandLast Hour: -0.391 Day: -13.495 Month: -344.154 Year: -4.861 (since: 2017-12-31_08:59:55 )
2018-02-05 12:31:21 verbrauch_seit_auffuellen 422.423
helper:
_98_statistics myStatistics
Attributes:
DbLogInclude Oelstand,last_consumption,statistik_OelstandDay1,statistik_OelstandDay30,statistik_OelstandDay5
event-min-interval .*:300
event-on-change-reading .*
readingList Oeltank_aufgefuellt verbrauch_seit_auffuellen Oelstand last_Runtime1 last_Runtime2 last_consumption
room Heizung
setList Oelstand Oeltank_aufgefuellt
stateFormat Ölstand: Oelstand Liter
userReadings {
my $last_Runtime1_timestamp = ReadingsTimestamp('Oeltank','last_Runtime1','01.01.2001');
my $Oelstand_timestamp = ReadingsTimestamp('Oeltank','Oelstand','01.01.2001');
Log 3,"Time last_runtime1: $last_Runtime1_timestamp";
Log 3,"Time Oelstand: $Oelstand_timestamp";
if (ReadingsTimestamp('Oeltank','last_Runtime1','01.01.2001') ne ReadingsTimestamp('Oeltank','Oelstand','01.01.2001'))
{
my ($day, $month, $year) = (localtime)[3..5];
$year +=1900;
my $datestr = join '-', ++$month, $day, $year;
return $datestr;
} else
{
my $Oelstand = ReadingsVal("Oeltank","Oeltank_aufgefuellt", "0");
return $Oelstand;
}
}
Oelverbrauch:
Internals:
DEF Heizung_kessel:BrennerStufe1:.* {
if (ReadingsVal("Heizung_kessel","BrennerStufe1", "6") eq 0)
{
my $oldRuntime1 = ReadingsVal("Oeltank","last_Runtime1", "0");
my $oldRuntime2 = ReadingsVal("Oeltank","last_Runtime2", "0");
my $currentRuntime1 = ReadingsVal("Heizung_kessel","LaufzeitStufe1", "0");
my $currentRuntime2 = ReadingsVal("Heizung_kessel","LaufzeitStufe2", "0");
my $diffRuntime1 = $currentRuntime1 - $oldRuntime1;
my $diffRuntime2 = $currentRuntime2 - $oldRuntime2;
Log 5,"diffRuntime1: $diffRuntime1";
Log 5,"diffRuntime2: $diffRuntime2";
Log 5,"oldRuntime1: $oldRuntime1";
Log 5,"oldRuntime2: $oldRuntime2";
if ($diffRuntime1 > 0 or $diffRuntime2 > 0)
{
my $verbrauch = sprintf("%.3f",(($diffRuntime1 * 1.5) + ($diffRuntime2 * 2))/3600);
my $old_oelstand = ReadingsVal("Oeltank","Oelstand", "0");
my $new_oelstand = $old_oelstand - $verbrauch;
my $aktueller_verbrauch = ReadingsVal("Oeltank","verbrauch_seit_auffuellen","0");
my $new_verbrauch = $aktueller_verbrauch + $verbrauch;
Log 5,"verbrauch: $verbrauch";
Log 5,"currentRuntime1: $currentRuntime1";
Log 5,"currentRuntime2: $currentRuntime2";
Log 5,"old_oelstand: $old_oelstand";
Log 5,"new_oelstand: $new_oelstand";
fhem "setreading Oeltank Oelstand $new_oelstand";
fhem "setreading Oeltank last_Runtime1 $currentRuntime1";
fhem "setreading Oeltank last_Runtime2 $currentRuntime2";
fhem "setreading Oeltank last_consumption $verbrauch";
fhem "setreading Oeltank verbrauch_seit_auffuellen $new_verbrauch";
}
}
}
NAME Oelverbrauch
NOTIFYDEV Heizung_kessel
NR 153
NTFY_ORDER 50-Oelverbrauch
REGEXP Heizung_kessel:BrennerStufe1:.*
STATE 2018-02-05 13:13:21
TYPE notify
READINGS:
2018-02-02 21:17:15 state active
Attributes:
room Heizung
LogDB:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db.conf
DEF ./db.conf .*:.*
MODE asynchronous
MODEL MYSQL
NAME LogDB
NR 161
NTFY_ORDER 50-LogDB
PID 486
REGEXP .*:.*
STATE connected
TYPE DbLog
UTF8 1
VERSION 2.22.14
dbconn mysql:database=FHEM;host=li2nas1.fire.fly;port=3306
dbuser FHEM
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
READINGS:
2018-02-05 13:14:12 CacheUsage 0
2018-02-05 13:14:12 NextSync 2018-02-05 13:14:42 or if CacheUsage 500 reached
2018-01-19 16:32:55 countCurrent 15
2018-01-19 16:32:55 countHistory 43
2018-02-05 13:14:12 state connected
cache:
index 7785
memcache:
Attributes:
DbLogSelectionMode Include
DbLogType Current/History
asyncMode 1
icon edit_save
room System
Kann es sein, dass überhaupt keine Events generiert werden ?
Es gibt im Zusammnspiel von Devices, notify und setreading eine Besonderheit zu beachten die in der commandref zu setreading beschrieben ist:
Zitat
Achtung: setreading generiert kein Event für ein Gerät X, falls es aus einem notify für Gerät X aufgerufen wurde. In so einem Fall könnte man auf "sleep 0.1; setreading X Y Z" ausweichen.
Checke doch mal ob das evtl. bei dir zutrifft.
Grüße,
Heiko
Ich würde an dieser Stelle lieber auf die (eigentlich für Entwickler gedachten) Funktionen readingsBeginUpdate/readingsBulkUpdate/readingsEndUpdate verweisen. Das ist beim Setzen von mehreren Readings einfach sinnvoller und er kann im readingsEndUpdate auch angeben das Events ausgelöst werden sollen.
Es erzeugt alles in allem auch durch die Nichtverwendung von sleep weniger Last in FHEM.
Also am Ende statt:
fhem "setreading Oeltank Oelstand $new_oelstand";
fhem "setreading Oeltank last_Runtime1 $currentRuntime1";
fhem "setreading Oeltank last_Runtime2 $currentRuntime2";
fhem "setreading Oeltank last_consumption $verbrauch";
fhem "setreading Oeltank verbrauch_seit_auffuellen $new_verbrauch";
lieber:
readingsBeginUpdate($defs{Oeltank});
readingsBulkUpdate($defs{Oeltank},"Oelstand",$new_oelstand);
readingsBulkUpdate($defs{Oeltank},"last_Runtime1",$currentRuntime1);
readingsBulkUpdate($defs{Oeltank},"last_Runtime2",$currentRuntime2);
readingsBulkUpdate($defs{Oeltank},"last_consumption",$verbrauch;
readingsBulkUpdate($defs{Oeltank},"verbrauch_seit_auffuellen",$new_verbrauch);
readingsEndUpdate($defs{Oeltank},1)
Gruß
Dan
Zitat von: DeeSPe am 05 Februar 2018, 19:40:48
Ich würde an dieser Stelle lieber auf die (eigentlich für Entwickler gedachten) Funktionen readingsBeginUpdate/readingsBulkUpdate/readingsEndUpdate verweisen. Das ist beim Setzen von mehreren Readings einfach sinnvoller und er kann im readingsEndUpdate auch angeben das Events ausgelöst werden sollen.
Hallo Dan,
die Konstellation mit mehreren aufeinanderfolgenden setreadings habe ich auch. Werden mit dem
readingsBulkUpdate die setreadings gesammelt und mit dem readingsEndUpdate mit geringerer Last
in einem Rutsch ausgefuehrt?
Wenn nichts dagegen spricht, dass auch "normale" Nutzer diesen Mechanismus einsetzen, lohnt es
sich fuer mich, wenigstens die "Development Introduction" durchzuarbeiten?
Gruss Helmut
Zitat von: helmut am 05 Februar 2018, 20:32:27Werden mit dem
readingsBulkUpdate die setreadings gesammelt und mit dem readingsEndUpdate mit geringerer Last
in einem Rutsch ausgefuehrt?
So ist es. ;)
Zitat von: helmut am 05 Februar 2018, 20:32:27
Wenn nichts dagegen spricht, dass auch "normale" Nutzer diesen Mechanismus einsetzen, lohnt es
sich fuer mich, wenigstens die "Development Introduction" durchzuarbeiten?
Da spricht absolut nichts dagegen wenn Du eh gern Deine notify(s)/Funktionen in Perl schreibst.
Helfen wird das Lesen der Doku immer.
Gruß
Dan
Zitat von: DeeSPe am 05 Februar 2018, 20:39:21
wenn Du eh gern Deine notify(s)/Funktionen in Perl schreibst.
Hallo Dan,
auf jeden Fall. Das erschliesst mir doch erst das maechtige Potential von fhem.
Mein perl ist zwar nicht so gut, als dass ich hier aktiv etwas dazu beitragen koennte,
aber wenn Du die Developer-Doku auch fuer Nichtentwickler als sinnvoll erachtest,
fange ich damit mal an. Danke fuer den Hinweis.
Gruss Helmut
Herzlichen Dank schon mal für die Antworten.
Aber ich geh mal wieder zurück zu dem eigentlichen Topic :)
Zitat von: DS_Starter am 05 Februar 2018, 19:18:42
Kann es sein, dass überhaupt keine Events generiert werden ?
Im Event-Monitor sehe ich schon Events - also würde ich mal davon ausgehen, dass es die gibt:
2018-02-05 15:07:21 statistics myStatistics Updated stats for: Heizung_kessel
2018-02-05 15:07:21 statistics myStatistics Updated stats for: Oeltank
2018-02-05 15:07:21 dummy Oeltank Oelstand: 4571.998
2018-02-05 15:07:21 dummy Oeltank statistik_Oelstand: Hour: -0.401 Day: -9.810 Month: -60.478 Year: -404.632
2018-02-05 15:07:21 statistics myStatistics Updated stats for: Oeltank
2018-02-05 15:07:21 dummy Oeltank last_Runtime1: 841695
2018-02-05 15:07:21 statistics myStatistics Updated stats for: Oeltank
2018-02-05 15:07:21 dummy Oeltank last_Runtime2: 310482
2018-02-05 15:07:21 statistics myStatistics Updated stats for: Oeltank
2018-02-05 15:07:21 dummy Oeltank last_consumption: 0.401
2018-02-05 15:07:21 statistics myStatistics Updated stats for: Oeltank
2018-02-05 15:07:21 dummy Oeltank verbrauch_seit_auffuellen: 424.04Zitat von: DeeSPe am 05 Februar 2018, 19:40:48
Ich würde an dieser Stelle lieber auf die (eigentlich für Entwickler gedachten) Funktionen readingsBeginUpdate/readingsBulkUpdate/readingsEndUpdate verweisen. Das ist beim Setzen von mehreren Readings einfach sinnvoller und er kann im readingsEndUpdate auch angeben das Events ausgelöst werden sollen.
Das werde ich gleich mal einbauen und hoffentlich hilft das.
Irgendwie habe ich so das Gefühl, das in dem Modul LogDB die dummy-Devices einfach ignoriert werden.
Statt mit setreading würde ich lieber mit setList und readingsList beim Dummy arbeiten. Ist sauberer.
ZitatIrgendwie habe ich so das Gefühl, das in dem Modul LogDB die dummy-Devices einfach ignoriert werden.
Ganz bestimmt nicht ;)
egal mit welcher methode man die readings aktualisiert: am ende werden immer die Begin/Bulk/End update funktionen verwendet. der overhead durch set/setreading selber ist vermutlich zu vernachlässigen wenn es um einige wenige readings geht, aber bei direktem Begin/Bulk/End wird geht intern einiges in einem rutsch. das hat auswirkung auf userReadings, loging, clonedummy und ähnliches.
unabhängig wie die readings geschrieben werden gilt die anmerkung bezüglich sleep aber immer. die zusätzlichen readings erzeugen nur dann zuvetlässig events wenn man mit sleep oder InternalTimer aus dem context des aktuellen notify ausbricht und die readings verzögert setzt.
Hallo Zusammen!
Schön mal vielen Dank für eure Hilfe!
Ich hab jetzt das Setzen der Readings auf Begin/Bulk/End umgebaut - aber leider auch ohne Erfolg. Es gibt immer noch keine Einträge im DBlog.
Kann es sein, dass ich noch irgendwo einen sleep setzen muss, wie es justme1968 erwähnt hat?
Zitat von: justme1968 am 07 Februar 2018, 13:49:03
unabhängig wie die readings geschrieben werden gilt die anmerkung bezüglich sleep aber immer. die zusätzlichen readings erzeugen nur dann zuvetlässig events wenn man mit sleep oder InternalTimer aus dem context des aktuellen notify ausbricht und die readings verzögert setzt.
Zitat von: DS_Starter am 06 Februar 2018, 18:58:30
Zitat
Irgendwie habe ich so das Gefühl, das in dem Modul LogDB die dummy-Devices einfach ignoriert werden.
Ganz bestimmt nicht ;)
So ein wenig Verwunderung darfst Du mir aber nicht aberkennen.
Bei identischer Konfiguration für das DBLog funktioniert ein HTTPMOD Device aber kein DUMMY Device - das ist doch schon seltsam - oder?
eigentlich ist es ganz einfach :)
wenn ein device events generiert werden diese in eine interne struktur gesteckt und dann nacheinander alle 'listener' mit dieser struktur aufgerufen. listener sind alle dinge die auf die events reagieren. d.h. filelog, dblog, notify, ...
diese struktur gibt es in fhem nur genau ein mal. da fhem nicht multithreaded ist reicht das normalerweise.
wenn jetzt innerhalb eines notify durch das erzeugen neuer readings zusätzliche events erzeugt werden, landen die in genau der gleichen struktur. die listener die danach kommen sehen die zusätzlichen events, die losender die schon dran waren haben pech gehabt.
die reihenfolge der listener hängt unter anderem von den device namen bzw. deren alphabetischer reihenfolge ab. wenn dein httpmod device vor dem dblog device kommt passt es zufällig, wenn dein dummy device alphabetisch danach kommt passt es nicht. das ist vereinfacht und es gibt noch ein paar andere randbedingungen.
das ganze problem umgeht man in dem man das setzen der reading vom aktuellen durchlauf aller listener entkoppelt. da geht am einfachsten in dem man es mit einem winzigen sleep auf verzögert und einen eigenen event durchlauf anstößt statt im aktuellen durchlauf noch zusätzliche events hinten dran zu hängen.
danke für die ausführliche Erklärung.
Wenn ich das richtig verstanden habe, dann wird nicht überprüft ob jeder Listener auch alle Events erhält. Ergo werden Events, die später im Event-Zyklus generiert werden von den Listenern, die vorher schon "dran" waren, nicht wahrgenommen.
Oder vielleicht nochmal anders ausgedrückt - die Events, die innerhalb eines Event-Zyklus erzeugt werden (z.B. in meinem Notify), werden immer im gleichen Event-Zyklus behandelt und nicht in eine Warteschlange geschoben die dann im nächsten Event-Zyklus abgearbeitet werden.
Das mit dem Sleep leuchtet ein, da man die generierten Events auf den nächsten Event-Zyklus verschiebt. Allerdings hast Du auch geschrieben, dass FHEM nicht multithreaded ist. Würde ich dann nicht den kompletten Thread schlafen schicken und dann genau dort (also innerhalb des aktuellen Event-Zyklus) weitermachen wo ich das Sleep aufgerufen habe?
Unabhängig dieser Diskussion habe ich mal ein kurzes Sleep vor den readingsBeginUpdate-Block geschrieben - wäre das die richtige Stelle oder muss das vor das readingsEndUpdate?
wichtig: das sleep um das es hier geht ist ein fhem sleep. kein perl sleep!
ein fhem sleep startet einen nicht blockierenden internen timer und führt dann nach timer ablauf etwas aus.
d.h. wenn du auf perl ebene bist musst du das selber mit InternalTimer machen. wenn du auf fhem ebene mit setreading bist reicht ein sleep 0.1; setreading
OK, dann habe ich ja zumindest das Prinzip richtig verstanden :)
Jetzt scheitere ich aber an meinen Programmierkenntnissen.
Auf FHEM Ebene müsste das ja in etwas so aussehen:
fhem "sleep 0.1; setreading Oeltank Oelstand $new_oelstand";
fhem "sleep 0.1; setreading Oeltank last_Runtime1 $currentRuntime1";
fhem "sleep 0.1; setreading Oeltank last_Runtime2 $currentRuntime2";
fhem "sleep 0.1; setreading Oeltank last_consumption $verbrauch";
fhem "sleep 0.1; setreading Oeltank verbrauch_seit_auffuellen $new_verbrauch";
Wenn ich aber jetzt auf Perl-Ebene mit Begin und End Update bleiben möchte, muss ich alle Update-Anweisungen ja in ein "InternalTimer($timestamp, $functionName, $arg);" Statement packen.
Als $functionName kann ich da doch schlecht die Liste mit Anweisungen reinpacken und muss wohl eine eigenen Funktion dafür bauen.
In etwa so:
.
.
.
InternalTimer(gettimeofday()+1, "UpdateMyReadings", $arg);
}
sub UpdateMyReadings($)
{
readingsBeginUpdate($defs{Oeltank});
readingsBulkUpdate($defs{Oeltank},"Oelstand",$new_oelstand);
readingsBulkUpdate($defs{Oeltank},"last_Runtime1",$currentRuntime1);
readingsBulkUpdate($defs{Oeltank},"last_Runtime2",$currentRuntime2);
readingsBulkUpdate($defs{Oeltank},"last_consumption",$verbrauch;
readingsBulkUpdate($defs{Oeltank},"verbrauch_seit_auffuellen",$new_verbrauch);
readingsEndUpdate($defs{Oeltank},1)
}
Was mir hier noch nicht so klar ist, was ich als $arg übergeben muss, damit die Funktion bei späterer Ausführung auch noch die Variablen mit den passenden Werten hat?
denke nicht zu umständlich, du bist doch heute schon fast dran mit deinem notify , lösche einfach den Block
fhem "setreading Oeltank Oelstand $new_oelstand";
fhem "setreading Oeltank last_Runtime1 $currentRuntime1";
fhem "setreading Oeltank last_Runtime2 $currentRuntime2";
fhem "setreading Oeltank last_consumption $verbrauch";
fhem "setreading Oeltank verbrauch_seit_auffuellen $new_verbrauch";
und setzte dafür dein Beispiel von oben ein
readingsBeginUpdate($defs{Oeltank});
readingsBulkUpdate($defs{Oeltank},"Oelstand",$new_oelstand);
readingsBulkUpdate($defs{Oeltank},"last_Runtime1",$currentRuntime1);
readingsBulkUpdate($defs{Oeltank},"last_Runtime2",$currentRuntime2);
readingsBulkUpdate($defs{Oeltank},"last_consumption",$verbrauch;
readingsBulkUpdate($defs{Oeltank},"verbrauch_seit_auffuellen",$new_verbrauch);
readingsEndUpdate($defs{Oeltank},1)
beim EndUpdate fehlt allerdings auf jeden Fall das ; am Ende -> readingsEndUpdate($defs{Oeltank},1);
kein sleep oder timer notwendig, das ,1 am Ende von EndUpdate sorgt schon für die Events
Zitat von: Wzut am 08 Februar 2018, 12:49:30
denke nicht zu umständlich, du bist doch heute schon fast dran mit deinem notify , lösche einfach den Block
...
kein sleep oder timer notwendig, das ,1 am Ende von EndUpdate sorgt schon für die Events
Wenn das so einfach wäre.
Den Block hatte ich gestern schon ausgetauscht - aber der hat auch keine Logeinträge im DBLog erzeugt.
Heute habe ich dann auf die FHEM-Variante mit sleep umgebaut und ein paar Stunden laufen lassen.
fhem "sleep 0.1; setreading Oeltank Oelstand $new_oelstand";
fhem "sleep 0.1; setreading Oeltank last_Runtime1 $currentRuntime1";
fhem "sleep 0.1; setreading Oeltank last_Runtime2 $currentRuntime2";
fhem "sleep 0.1; setreading Oeltank last_consumption $verbrauch";
fhem "sleep 0.1; setreading Oeltank verbrauch_seit_auffuellen $new_verbrauch";Aber auch mit der bekomme ich keine Logeinträge im DBLog :(
Parallel hab ich mittlerweile immer ein Fenster mit dem Event-Monitor offen und beobachte die Events. Da kommen regelmäßig Events zu meinem Oeltank - die werden übrigens auch in das Filelog geschrieben - aber eben nicht in das DBLog.
Hat vielleicht noch jemand eine Idee woran das noch liegen kann?
Dann schau dir mal das an in deiner config aus dem ersten Post :
Attributes:
DbLogSelectionMode Include stell das mal um auf Exclude/Include oder Exclude , denn laut command.ref :
ZitatInclude: Nothing will be logged, except the readings specified via regex in the DbLogInclude attribute
Das wäre ja auch das gewünschte Verhalten.
Ich möchte generell keine Logeinträge und an jedem Device festlegen, welche Werte in das Log geschrieben werden. Und bei meinen HTTPMOD Devices funktioniert das so bestens.
In den Attributen meines Oeltanks hab ich folgendes stehen:
DbLogInclude
Oelstand,last_consumption,statistik_OelstandDay1,statistik_OelstandDay30,statistik_OelstandDay5
event-min-interval
.*:300
event-on-change-reading
.*
damit sollte er eigentlich wenn eines der Readings geändert wird aber spätestens alle 300 Sekunden ein Event getriggert werden das dann geloggt wird.
Das mit den 300 Sekunden funktioniert überhaupt nicht (auch nicht im FileLog) aber bei Änderungen gibt es die Events.
Aber da fällt mir noch was anderes ein. Könnte es sein, das das DbLogInclude auf dem falschen Device ist. Müsste das an dem Notify hängen??
event-min-interval hast du falsch interpretiert. Das ist der geringste Abstand in dem Events generiert werden. Kommt also nach 150 Sekunden ein geänderter Wert, dann wird kein Event generiert. Erst wenn die 300 Sekundenn rum sind, werden bei Änderungen (bei gemeinsamer verwendung mit event-on-change-reading) wieder Events erzeugt.
Zitat von: litronics am 08 Februar 2018, 15:44:55
Das wäre ja auch das gewünschte Verhalten.
Ich möchte generell keine Logeinträge und an jedem Device festlegen, welche Werte in das Log geschrieben werden. Und bei meinen HTTPMOD Devices funktioniert das so bestens.
In den Attributen meines Oeltanks hab ich folgendes stehen:
DbLogInclude
Oelstand,last_consumption,statistik_OelstandDay1,statistik_OelstandDay30,statistik_OelstandDay5
event-min-interval
.*:300
event-on-change-reading
.*
damit sollte er eigentlich wenn eines der Readings geändert wird aber spätestens alle 300 Sekunden ein Event getriggert werden das dann geloggt wird.
Das mit den 300 Sekunden funktioniert überhaupt nicht (auch nicht im FileLog) aber bei Änderungen gibt es die Events.
Aber da fällt mir noch was anderes ein. Könnte es sein, das das DbLogInclude auf dem falschen Device ist. Müsste das an dem Notify hängen??
Am besten erstmal ohne Modifikation testen um zu sehen das es überhaupt geht.
Zitat von: automatisierer am 08 Februar 2018, 15:58:16
event-min-interval hast du falsch interpretiert. Das ist der geringste Abstand in dem Events generiert werden. Kommt also nach 150 Sekunden ein geänderter Wert, dann wird kein Event generiert. Erst wenn die 300 Sekundenn rum sind, werden bei Änderungen (bei gemeinsamer verwendung mit event-on-change-reading) wieder Events erzeugt.
Danke für den Hinweis - das hatte ich tatsächlich falsch verstanden.
Zitat von: CoolTux am 08 Februar 2018, 16:39:04
Am besten erstmal ohne Modifikation testen um zu sehen das es überhaupt geht.
Grundsätzlich funktioniert das DBlog - ich hab ja HTTPMOD Devices (drei Stück an der Zahl) und die loggen fein säuberlich in das FileLog und das DBlog parallel. Nur so lange das DBlog noch nicht so funktioniert, wie ich das mit dem FileLog habe, möchte ich das nicht abschalten.
Ich hab jetzt mal event-min-interval gelöscht und DbLogInclude auf .* gesetzt.
Hoffentlich funktioniert das...
Wenn nicht, werde ich im DBlog mal den DbLogSelectionMode auf exclude stellen. Wenn ich die commandref richtig interpretiere, dann müssten damit ALLE Events in der LogDB landen. OK so lange sie nicht mit DbLogExclude am Device ausgeschlossen werden - aber nachdem es dieses Attribut nicht ein einziges Mal in meiner Config gibt, müsste jedes Event im Log landen.
Bin gespannt ob spätestens dann das Dummy geloggt wird...
Sorry ich meinte damit das du event-on-* Mal komplett vom Dummy weg nehmen solltest.
Nachdem die letzten Änderungen auch nicht die Lösung gebracht haben, hab ich jetzt alle event-on* Attribute gelöscht.
Danach bleibt mir jetzt nur noch DbLogSelectionMode auf Exclude zu stellen und zu hoffen, dass zumindest dann was geloggt wird.
Jetzt bin ich komplett ratlos und brauche eure Hilfe!
Gestern Aband habe ich noch mein DBlog auf DbLogSelectionMode Exclude gestellt.
Heute Morgen schaue ich rein und siehe da im DBlog sind so ziemlich (ich hab die nicht nachgezählt) alle anderen Readings enthalten - aber nicht ein Einziges von dem Oeltank!
Ich verwende zu meiner Rolladensteuerung auch Dummies - sogar für die wurde der State geloggt.
Der Unterschied ist, dass ich bei den Rolladen-Dummies nur den State verwende und keine Userreadings. Bei dem Oeltank verwende ich NUR Userreadings und der State ist mir egal.
An der Stelle bin ich jetzt mit meinem Latein echt am Ende - hat von euch noch jemand eine Idee?
Jetzt benötigt man etwas mehr Einblick.
Setze dir bitte das Attr "verbose4Devs = Oeltank", also den Deviceamen und danach verbose 5 im DbLog. Das Attribut erhöht die Übersichtlichkeit um nur das interessierende Device im Log zu finden.
Dann schau mal nach solchen Abschnitten:
2018.02.09 12:31:30.722 4: DbLog LogDB -> ################################################################
2018.02.09 12:31:30.724 4: DbLog LogDB -> ### start of new Logcycle ###
2018.02.09 12:31:30.724 4: DbLog LogDB -> ################################################################
2018.02.09 12:31:30.725 4: DbLog LogDB -> number of events received: 5 for device: MySTP_5000
2018.02.09 12:31:30.729 4: DbLog LogDB -> check Device: MySTP_5000 , Event: modulstate: normal
2018.02.09 12:31:30.730 5: DbLog LogDB -> parsed Event: MySTP_5000 , Event: modulstate: normal
2018.02.09 12:31:30.731 4: DbLog LogDB -> check Device: MySTP_5000 , Event: etotal: 18701.847
2018.02.09 12:31:30.732 5: DbLog LogDB -> parsed Event: MySTP_5000 , Event: etotal: 18701.847
2018.02.09 12:31:30.733 4: DbLog LogDB -> added event - Timestamp: 2018-02-09 12:31:30, Device: MySTP_5000, Type: SMAINVERTER, Event: etotal: 18701.847, Reading: etotal, Value: 18701.847, Unit:
2018.02.09 12:31:30.734 4: DbLog LogDB -> check Device: MySTP_5000 , Event: etoday: 10.374
2018.02.09 12:31:30.735 5: DbLog LogDB -> parsed Event: MySTP_5000 , Event: etoday: 10.374
2018.02.09 12:31:30.736 4: DbLog LogDB -> added event - Timestamp: 2018-02-09 12:31:30, Device: MySTP_5000, Type: SMAINVERTER, Event: etoday: 10.374, Reading: etoday, Value: 10.374, Unit:
2018.02.09 12:31:30.737 4: DbLog LogDB -> check Device: MySTP_5000 , Event: total_pac: 4.549
2018.02.09 12:31:30.738 5: DbLog LogDB -> parsed Event: MySTP_5000 , Event: total_pac: 4.549
2018.02.09 12:31:30.739 4: DbLog LogDB -> added event - Timestamp: 2018-02-09 12:31:30, Device: MySTP_5000, Type: SMAINVERTER, Event: total_pac: 4.549, Reading: total_pac, Value: 4.549, Unit:
2018.02.09 12:31:30.740 4: DbLog LogDB -> check Device: MySTP_5000 , Event: 4.549
2018.02.09 12:31:30.741 5: DbLog LogDB -> parsed Event: MySTP_5000 , Event: 4.549
2018.02.09 12:31:30.741 4: DbLog LogDB -> added event - Timestamp: 2018-02-09 12:31:30, Device: MySTP_5000, Type: SMAINVERTER, Event: 4.549, Reading: state, Value: 4.549, Unit:
"check Device:" heißt DbLog hat einen Event von Device x erhalten.
"parsed Event:" zeigt das was nach dem Eventparserdurchlauf vom Event geblieben ist.
"added Event:" heißt der Eintrag wurde nach Regex-Bewertung, Exlude/Include-Bewertung dem Cache zugefügt und wird demnächst in die DB geschrieben.
(Die Meldungen setzen ein recht aktuelles DbLog voraus, am Besten updaten falls recht lange her)
Das ist ein Beispiel für den asynchronen Betriebsmodus. Schau mal ob deine Events vom Öltank hier auftauchen.
Ich selbst logge genügend Dummy-Events, also am Dummy-Device als solches liegt es sicher nicht.
Hier noch ein Beispiel für einen Dummy-Eintrag:
2018.02.09 12:56:30.487 4: DbLog LogDB -> ################################################################
2018.02.09 12:56:30.488 4: DbLog LogDB -> ### start of new Logcycle ###
2018.02.09 12:56:30.488 4: DbLog LogDB -> ################################################################
2018.02.09 12:56:30.489 4: DbLog LogDB -> number of events received: 2 for device: Dum.Energy
2018.02.09 12:56:30.492 4: DbLog LogDB -> check Device: Dum.Energy , Event: PV: 1412.0
2018.02.09 12:56:30.493 5: DbLog LogDB -> parsed Event: Dum.Energy , Event: PV: 1412.0
2018.02.09 12:56:30.493 4: DbLog LogDB -> added event - Timestamp: 2018-02-09 12:56:30, Device: Dum.Energy, Type: DUMMY, Event: PV: 1412.0, Reading: PV, Value: 1412.0, Unit:
2018.02.09 12:56:30.494 4: DbLog LogDB -> check Device: Dum.Energy , Event: T: 614.5
2018.02.09 12:56:30.495 5: DbLog LogDB -> parsed Event: Dum.Energy , Event: T: 614.5
2018.02.09 12:56:30.495 4: DbLog LogDB -> added event - Timestamp: 2018-02-09 12:56:30, Device: Dum.Energy, Type: DUMMY, Event: T: 614.5, Reading: T, Value: 614.5, Unit:
Grüße
Heiko
Hallo Heiko,
ich hab jetzt wieder ein paar neue Erkenntnisse gewonnen :)
Tatsächlich ist es so, dass DBlog meinen Oeltank Dummy NUR in die history-Tabelle schreibt und NICHT in die current-Tabelle.
Ich hab immer in der current-Tabelle gesucht, weil da laut Doku immer die letzten Werte drin stehen (was ja bei den anderen Readings auch so ist).
Gerade habe ich meine beiden Tabellen mal wieder geleert und werde das nochmal beobachten.
Das Logging schraube ich dann auch mal hoch - vielleicht sieht man ja darin was.
Ok, und jetzt mach bitte noch einen set configCheck. Schön wäre es wenn du die aktellste Version einsetzt.
Achja ... damit in die current geschrieben wird, musst du das Attr "DbLogType = Current/History" setzen !
EDIT: mit version 3.2.0 am 6.12.2017 hatte ich mal einen Bugfix bzgl. current-Update eingebaut. Vllt. ist es das bei dir weil du nach 2.x.x hattest
# 3.2.0 06.12.2017 change attribute "autocommit" to "commitMode", activate choice of autocommit/transaction in logging
# Addlog/addCacheLine change $TIMESTAMP check,
# rebuild DbLog_Push/DbLog_PushAsync due to bugfix in update current (Forum:#80519),
Grüße
Heiko
Ich hatte DbLogType auf Current/History gesetzt und bin eben davon ausgegangen, dass die Werte in beide geschrieben werden.
Der ConfigCheck hat auch bei allen Punkten sein OK gegeben und da sollte auch kein Problem gewesen sein.
Was jetzt aber mega seltsam ist...
Es funktioniert jetzt aktuell anscheinend einwandfrei - genau so, wie ich es eigentlich ursprünglich haben wollte.
Um die Änderungen und die Ergebnisse nochmal chronologisch zusammenzufassen:
1. Ändern von DbLogSelectionMode von Internal auf External --> es wurden alle Events geloggt - aber der Oeltank (und evtl. noch ein paar andere Events) NUR in die history nicht in current
2. Ändern von DbLogSelectionMode zurück auf Internal, verbose Logging aktiviert und SQL Tabellen geleert (mit DELETE * from history / current where timestamp >1)
3. Jetzt wird das Dummy in Current und History geloggt - aber es sind noch nicht alle anderen Readings (die vorher auch da waren) in current.
Das mit dem Versionshinweis war auch nicht falsch. Da war tatsächlich eine uralte Version (2.22.14) installiert - kann es sein, dass die im Installations-Repository nicht aktuell ist? Im November hatte ich erst ein update all gemacht und bin eigentlich davon ausgegangen, dass ich recht aktuell unterwegs bin.
Wie auch immer - jetzt läuft die 3.8.4.
Welchen Einfluss jetzt die alte Version hatte, kann ich natürlich nicht sagen - aber ich hoffe, dass jetzt alles funktioniert, auch wenn ich nicht verstehe, wo das Problem war.
Da sich das Problem eigentlich nur auf das Update der current bezogen hat (wie wir ja nun festgestellt hatten), tendiere ich sehr dazu, dass es mit dem gefixten Bug in 3.2.0 zu tun hatte. Ich weiß nicht mehr genau wie die Zusammnhänge waren und habe nicht nochmal nachgelesen, aber es kam in ganz bestimmten Konstellationen dazu dass die current keine Einträge erhielt.... nicht generell !
Mit verbose 5 siehst du sehr genau im Database write Cycle wie das Modul die Date in history und ggf. current hineinschreibt oder updated.
Grüße
Herzlichen dank für eure Hilfe!
Wenn der Fehler damals sporadisch aufgetreten ist, dann wird das vermutlich damit zusammenhängen. Tatsächlich ging es am Ende dann auch ohne das Update - aber sicherheitshalber hab ich es mal installiert und hoffe, dass jetzt alles funktioniert.
Schöne Grüße!