Hi,
ich habe ein Geofancy Device und würde gern nur Zeiten loggen wenn ich die Arbeit (work) verlasse.
Mich interessiert also die Readings "lastPosArr_rr_Stefan", "lastPosDep_rr_Stefan" und "lastPosDur_rr_Stefan", aber nur wenn das Reading "lastDep" = rr_Stefan work.
Kann man irgendwie mit einer Bedingung, also Reading "lastDep" = rr_Stefan work die anderen oben erwähnten readings zu diesem Event mitloggen?
Zur Veranschaulichung hier mal ein Auszug aus DbLog der zurzeit entsteht mit:
2019-11-26 19:25:59 geofancy GEOFANCY lastArr: rr_Stefan home lastArr rr_Stefan home
2019-11-26 19:25:59 geofancy GEOFANCY lastPosArr_rr_Stefan: 2019-11-26 19:09:00 lastPosArr_rr_Stefan 2019-11-26 19:09:00
2019-11-26 19:25:59 geofancy GEOFANCY lastPosDep_rr_Stefan: 2019-11-26 19:25:57 lastPosDep_rr_Stefan 2019-11-26 19:25:57
2019-11-26 19:25:59 geofancy GEOFANCY lastPosDur_rr_Stefan: 1017 lastPosDur_rr_Stefan 1017
2019-11-26 19:09:03 geofancy GEOFANCY lastArr: rr_Stefan wayhome lastArr rr_Stefan wayhome
2019-11-26 19:09:03 geofancy GEOFANCY lastPosArr_rr_Stefan: 2019-11-26 18:42:39 lastPosArr_rr_Stefan 2019-11-26 18:42:39
2019-11-26 19:09:03 geofancy GEOFANCY lastPosDep_rr_Stefan: 2019-11-26 19:09:00 lastPosDep_rr_Stefan 2019-11-26 19:09:00
2019-11-26 19:09:03 geofancy GEOFANCY lastPosDur_rr_Stefan: 1581 lastPosDur_rr_Stefan 1581
2019-11-26 18:42:43 geofancy GEOFANCY lastDep: rr_Stefan work lastDep rr_Stefan work
2019-11-26 18:42:43 geofancy GEOFANCY lastPosArr_rr_Stefan: 2019-11-26 09:12:44 lastPosArr_rr_Stefan 2019-11-26 09:12:44
2019-11-26 18:42:43 geofancy GEOFANCY lastPosDep_rr_Stefan: 2019-11-26 18:42:39 lastPosDep_rr_Stefan 2019-11-26 18:42:39
2019-11-26 18:42:43 geofancy GEOFANCY lastPosDur_rr_Stefan: 34195 lastPosDur_rr_Stefan 34195
2019-11-26 09:12:47 geofancy GEOFANCY lastArr: rr_Stefan work lastArr rr_Stefan work
2019-11-26 09:12:47 geofancy GEOFANCY lastPosArr_rr_Stefan: 2019-11-26 09:06:35 lastPosArr_rr_Stefan 2019-11-26 09:06:35
2019-11-26 09:12:47 geofancy GEOFANCY lastPosDep_rr_Stefan: 2019-11-26 09:12:44 lastPosDep_rr_Stefan 2019-11-26 09:12:44
2019-11-26 09:12:47 geofancy GEOFANCY lastPosDur_rr_Stefan: 369 lastPosDur_rr_Stefan 369
2019-11-26 09:06:37 geofancy GEOFANCY lastArr: rr_Stefan waywork lastArr rr_Stefan waywork
2019-11-26 09:06:37 geofancy GEOFANCY lastPosArr_rr_Stefan: 2019-11-26 08:23:21 lastPosArr_rr_Stefan 2019-11-26 08:23:21
2019-11-26 09:06:37 geofancy GEOFANCY lastPosDep_rr_Stefan: 2019-11-26 09:06:35 lastPosDep_rr_Stefan 2019-11-26 09:06:35
2019-11-26 09:06:37 geofancy GEOFANCY lastPosDur_rr_Stefan: 2594 lastPosDur_rr_Stefan 2594
2019-11-26 08:23:26 geofancy GEOFANCY lastDep: rr_Stefan home lastDep rr_Stefan home
2019-11-26 08:23:26 geofancy GEOFANCY lastPosArr_rr_Stefan: 2019-11-26 07:56:10 lastPosArr_rr_Stefan 2019-11-26 07:56:10
2019-11-26 08:23:26 geofancy GEOFANCY lastPosDep_rr_Stefan: 2019-11-26 08:23:21 lastPosDep_rr_Stefan 2019-11-26 08:23:21
2019-11-26 08:23:26 geofancy GEOFANCY lastPosDur_rr_Stefan: 1631 lastPosDur_rr_Stefan 1631
2019-11-26 07:56:13 geofancy GEOFANCY lastArr: rr_Stefan home lastArr rr_Stefan home
2019-11-26 07:56:13 geofancy GEOFANCY lastPosArr_rr_Stefan: 2019-11-26 01:58:38 lastPosArr_rr_Stefan 2019-11-26 01:58:38
2019-11-26 07:56:13 geofancy GEOFANCY lastPosDep_rr_Stefan: 2019-11-26 07:56:10 lastPosDep_rr_Stefan 2019-11-26 07:56:10
2019-11-26 07:56:13 geofancy GEOFANCY lastPosDur_rr_Stefan: 21452 lastPosDur_rr_Stefan 21452
Danke und Gruß,
Stefan
Hallo Stefan,
ja, sowas geht mit dem Attribut valueFn im DbLog.
Hier ein Beispiel ohne es getestet zu haben und die Fehlerfreiheit garantieren zu können (valueFn so setzen):
{
if ($DEVICE eq "geofancy" && $READING =~ /lastPosArr_rr_Stefan|lastPosDep_rr_Stefan|lastPosDur_rr_Stefan/) {
$IGNORE=1 if(ReadingsVal($DEVICE, "lastDep", "") ne "rr_Stefan work");
}
}
Es geht darum das Prinzip zu verstehen. Wenn der Event mit Reading lastPosArr_rr_Stefan oder lastPosDep_rr_Stefan oder lastPosDur_rr_Stefan geloggt werden soll, wird der Wert des Readings lastDep geprüft und der Event ignoriert (d.h. nicht geloggt) wenn dessen Wert nicht "rr_Stefan work" ist.
Grüße,
Heiko
Hi Heiko,
ich danke dir vielmals.
Das Attribut hatte ich schon gesehen, da bin ich aber nicht drauf gekommen.
Ist aber eigentlich ganz klar :-)
Sag mal brauch ich das $DEVICE eq "geofancy" wenn ich das Attribut DbLogValueFn am geofency Gerät definiere?
Danke und Gruß,
Stefan
ZitatSag mal brauch ich das $DEVICE eq "geofancy" wenn ich das Attribut DbLogValueFn am geofency Gerät definiere?
Nicht zwangsläufig. Aber es dient zur genauen Abgrenzung dass die besagten Readings auch die des Device geofancy sind.
Könnte ja sein andere Devices haben auch diese Readingnamen.
Unsinn, ist schon spät ... nein in diesem Fall brauchst du es nicht. Gibt es dort auch garnicht als Parameter.
Grüße,
Heiko
Ok,
hat mit dem Device auch nicht funktioniert im Gerät.
Habs mal rausgemacht.
Mal sehen ob es nun klappt.
Gruß und Danke,
Stefan
Also ich würde hier instinktiv mit notify oder doif auf das eine Reading triggern und dann mit addlog die gewünschten readi gs loggen.
Gesendet von meinem S60 mit Tapatalk
Hi,
ich würde schon das dafür vorgesehene valueFn nehmen.
Leider tut es nicht.
Ich habe jetzt folgendes in valueFn:
{
if ($READING =~ /lastPosArr_rr_Stefan|lastPosDep_rr_Stefan|lastPosDur_rr_Stefan/) {
$IGNORE=1 if(ReadingsVal($DEVICE, "lastDep", "") ne "rr_Stefan work");
}
}
Folgendes wurde im Filelog gespeichert:
019-11-28_19:07:16 geofancy lastDep: rr_Stefan work
2019-11-28_19:07:16 geofancy lastPosArr_rr_Stefan: 2019-11-28 11:28:58
2019-11-28_19:07:16 geofancy lastPosDep_rr_Stefan: 2019-11-28 19:07:14
2019-11-28_19:07:16 geofancy lastPosDur_rr_Stefan: 27496
Für mich sieht das ja eigentlich gut aus.
Hat aber nicht gezogen. Irgendeine Idee?
Benötige ich zusätzlich ein DBLogInclude? Ich habe DBLog im DbLogSelectionMode Include laufen.
Wie könnte ich das denn ordentlich testen. Leider sendet die geofanc app das ja immer nur wenn ich einen 'Bereich wirklich verlasse.
Gruß,
Stefan
Hi Stefan,
genaueres sieht man nur wenn du verbose 4 oder 5 im DbLog einschaltest.
Aber es könnte auch sein dass das Reading "rr_Stefan work" erst NACH den Readings lastPosArr_rr_Stefan,lastPosDep_rr_Stefan,lastPosDur_rr_Stefan gesetzt wird. Dann klappt das nicht so. Dann wäre das Verfahren wie von Frank genannt besser. :)
DBLogInclude muss natürlich alle Readings beinhalten, die ausgewertet werden sollen, also alle die oben genannten.
Ok danke.
Ich hatte LogInclude entfernt.
Ich teste mal.
Gruß,
Stefan
So, es hat leider noch nicht geklappt.
Erstmal möchte ich lastDep auch nur loggen wenn es "rr_Stefan work" ist.
Scheinbar hat auch das Freizeichen einen einfluss auf das "ne"
Ich habe jetzt mal folgendes
DbLogInclude
lastDep,lastPosArr_rr_Stefan,lastPosDep_rr_Stefan,lastPosDur_rr_Stefan
DbLogValueFn
{
if ($READING =~ /lastPosArr_rr_Stefan|lastPosDep_rr_Stefan|lastPosDur_rr_Stefan|lastDep/) {
$IGNORE=1 if(ReadingsVal("geofancy", "lastDep", "") !~ /work/);
}
}
Ich hoffe so funktioniert es. Muss es noch testen.
Danke und Gruß,
Stefan
Wenn es nicht klappt prüfe bitte was
{ ReadingsVal("geofancy", "lastDep", "") }
eigegeben in der Befehlszeile im FEHEMWEB ausgibt.
Außerdem ist dann DbLog verbose 4 oder 5 ein Hilfsmittel um herauszubekommen was nicht funktioniert.
Hi Heiko,
es geht nun wunderbar. Ich hätte da aber noch eine Frage dazu.
Ich logge nun meine Arbeitszeit beim Verlassen der Arbeit mit dieser Bedingung:
DbLogInclude
lastDep,lastPosArr_rr_Stefan,lastPosDep_rr_Stefan,lastPosDur_rr_Stefan,rr_Stefan
DbLogValueFn
{
if ($READING =~ /lastPosArr_rr_Stefan|lastPosDep_rr_Stefan|lastPosDur_rr_Stefan|lastDep|rr_Stefan/) {
$IGNORE=1 if(ReadingsVal("geofancy", "rr_Stefan", "") !~ /left work/ or
(ReadingsVal("geofancy", "rr_Stefan", "") =~ /left work/ and
ReadingsVal("geofancy", "lastPosDur_rr_Stefan", 0) < 1200));
}
}
Das ist schonmal sehr cool. Jetzt habe ich einen SVG Plot erzeugt und dabei ist mir aufgefallen dass er das Wochenende mit dem Freitagswert einzeichnet.
Ist ja auch klar, der letzte Wert wurde Freitag gelogged und am Wochenende gab es gar keinen Eintrag.
Das könnte ich natürlich mit einem "AT" das SA und SO einen 0 Wert einträgt beheben.
Aber was ist mit Urlaub?
Ist es möglich einen 0 Wert zu erzeugen wenn lastPosDur_rr_Stefan an einem Tag nicht erzeugt wurde?
Ich bräuchte also eine Abfrage auf das DBlog ob an diesem Tag ein Log Eintrag mit lastPosDur_rr_Stefan erzeugt wurde und wenn nicht würde ich gern einen mit 0 als Wert erzeugen.
Ich kann mir gut vorstellen dass man das mit at oder notify irgendwie lösen kann, mir fehlt aber etwas das wissen wir ich hier die logdb abfrage ob ein Wert vorhanden ist.
Etwas störend ist auch dass die Zeit sich immer zum Logzeitpunkt im Graph ändert.
Somit wäre am besten eine Logik die jeden Tag um 23:59 ins DB Log schaut und wenn ein lastPosDur_rr_Stefan vorhanden ist den Timestamp auf 00:01 am Tag vorverlegt und falls lastPosDur_rr_Stefan nicht vorhanden ist einen Eintrag mit 00:01 timestamp und Wert 0 erzeugt.
Was wäre da denn der beste Weg für?
Gruß,
Stefan
Hallo Stefan,
so etwas kann man natürlich machen. Ein Hilfsmittel dafür ist DbRep.
Folgendes Vorgehen wäre zum Beispiel möglich, ohne es jetzt bis ins kleinste ausgearbeitet zu haben. Ich bin heute eher müde und nicht so sehr kreativ. ;)
Also:
1. definiere DbRep Device
2. grenze immer auf einen Tag ein (timestamp_begin/end auf current_day_begin/end) und natürlich auf das device und das reading lastPosDur_rr_Stefan
3. erstelle ein at um dieses Dbrep-Device um 23:59 ein "set dbrep countEntries" ausführt.
Im Ergebnis wird, wenn kein Eintrag in der DB gefunden wurde, ein Reading erzeugt welches z.B. so aussieht:
2019-12-17__COUNT_history__no_aggregation -
Jetzt gibt es die Option mit einem notify zu reagieren und mit "set DbRep insert .... " einen entsprechenden Eintrag mit "0" in die DB zu schreiben, also mit timestamp 00:01 wenn ich dich richtig verstanden habe. Oder eleganter mit der userExitFn. Da bei kann ich dir auch helfen, nur heute nicht mehr.
In dem anderen Fall, also wenn ein lastPosDur_rr_Stefan vorhanden it (das Reading würde dann eine Zahl enthalten), könnte man auf dem gleichen Weg einen Eintrag ungleich 0 um 00:001 erzeugen.
Umverlegen, d.h. den Timestamp ändern, geht so einfach nicht mit Bordmitteln. Geht natürlich auch, indem man sich ein passendes SQL-Statement überlegt welches den timestamp des letzten Eintrag des laufenden Tages selektiert und ihn dann auf 00:01 ändert. Dieses SQL kann man immer täglich 23:59 im DbRep mit "set DbRep sqlCmd" ausführen.
Damit wäre alles erreicht was du machen wolltest denke ich.
Ob es nun der beste Weg ist, möchte ich momentan nicht bewerten, aber er fiel mir ein und ist sicherlich so umsetzbar. ;)
Grüße,
Heiko
Ok, vielen Dank Heiko.
Ich schaue mir DBRep mal an und melde mich dann nochmal falls ich Rückfragen habe.
Eilig ist das ja sowieso nicht, wäre nur echt cool wenn ich meine Arbeitszeit darüber erfassen könnt und auch noch in FHEM aufbereiten.
Danke schonmal,
Stefan
Guten Morgen,
DbRep ist am Anfang sicherlich etwas gewöhnungsbedürftig. Es ist ein Datenbankfrontend und hat Attribute, die teilweise generell und teilweise nur im Kontext des jeweiligen Befehls wirken.
Deswegen zögere nicht zu fragen wenn du Unterstützung benötigst.
Zumindest bis Freitag kann ich noch helfen, dann ist erstmal Weihnachtspause. :)
Grüße,
Heiko
Ok alles klar,
ein kurze Frage ob ich das alles richtig verstehe.
Ich habe ein DBRep Device für allgemeine Aufgaben wie z.B. Vacuum der DB.
Für diesen neuen Task lege ich mir ein neues DBRep device an das ich mit den Attributen auf mein Device und Reading einschränke.
Habe ich das soweit richtig verstanden?
Nur damit ich nicht in eine total falsche Richtung loslege.
Danke und Gruß,
Stefan
Hallo Stefan,
ja genau richtig. Lege dir ein neues an.
Ich habe sehr viele Devices für die verschiedensten Aufgaben. Um sich die Arbeit zu erleichtern, kopiere ich ein vorhandenes Device und passe es dann nur noch den Bedürfnissen an.
Das geht nach ein bisschen Einarbeitung sehr flott von der Hand.
Ein Device benutze ich z.B. immer um mit set .... fetchrows einen schnellen Blick in die DB zu haben um zu sehen was dort so los ist oder zu schauen ob die Datenmanipulationen erfolgreich waren.
Grüße,
Heiko
Ok, danke.
Dann probiere ich das mit countEntries pro Tag und ergänze wen kein Eintrag da ist einen mit 0.
Das sollte eigentlich erstmal für meine Zwecke ausreichen.
Vielen Dank,
Stefan
Hi Heiko,
das ist ja alles einfacher als gedacht!
Ich habe eine Sub angelegt die ich als user exit rufe:
sub arbeitszeit {
my ($name,$reading,$value) = @_;
my $hash = $defs{$name};
my $device = "geofancy";
my $model = "GEOFANCY";
my $readingdef = "lastPosDur_rr_Stefan";
if($reading =~ /^.*_COUNT_history__no_aggregation.*$/) {
$reading =~ /^(\d+)-(\d+)-(\d+)_.*$/;
my $pmts = "$1-$2-$3";
my $fmtDateTime = FmtDateTime(gettimeofday());
setReadingsVal($hash,"heute",$value,$fmtDateTime);
setReadingsVal($hash,"heute_ts",$pmts,$fmtDateTime);
if ($value = 1) {
# Start der 3. Operation (update)
CommandSet(undef,"logdbRepArbeitszeit sqlCmd update history set timestamp=\"$pmts 00:00:01\", EVENT=\"dayentry\" where DEVICE=\"$device\" and READING=\"$readingdef\" and timestamp > \"$pmts\";");
Log3 $name, 1, "$name - timestamp updated to $pmts 00:00:01";
} else {
CommandSet(undef,"logdbRepArbeitszeit sqlCmd insert into history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT)
values (\"$pmts 00:00:01\", \"$device\", \"$model\", \"dayentry\", \"$readingdef\", \"0\", \"\")");
Log3 $name, 1, "$name - insert for today $pmts";
}
}
return;
}
Die macht schon alles wie gewünscht. Richtig cool.
Jetzt hätte ich noch eine Frage an dich.
Wie würdest du Summen der Arbeitszeit bilden?
Also ich hätte gern auch die Summe der Zeiten pro Woche und pro Monat.
Gibts da auch einen einfachen weg über DBRep oder lieber statistiks oder so verwenden?
Vielen Dank,
Stefan
Hallo Stefan,
wow, gleich die userExitFn benutzt ... perfekt. :D
Genau für solche Zwecke habe ich diese Möglichkeit vorgesehen. Ich freue mich, dass du es gleich hinbekommen hast.
Zitat
Wie würdest du Summen der Arbeitszeit bilden?
Also ich hätte gern auch die Summe der Zeiten pro Woche und pro Monat.
Sofern diese Rohdaten als Zahlen vorliegen ist es mit DbRep auch ganz einfach.
Setze dir die Attribute time* auf current_week_begin/current_week_end bzw. current_month_begin/current_moth_end
und führe dann ein "set ... sumValue" aus. Dann hast du die Summe die du weiterverarbeiten kannst. Zum Beispiel auch über einen user Exit diesen Wert in einen Dummy übertragen oder was auch immer.
Über diesen Weg gibt es quasi alle erdenklichen Möglichkeiten.
EDIT: Naja, das war etwas kurz gedacht von mir, du hast sicherlich nur einen Anfangs- und Endzeitpunkt der Arbeitszeit in der DB. In dem Fall hilft dir bestimmt der Beitrag im Wiki: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#.C3.96ffnungszeiten_von_Fenster.2FT.C3.BCren_aus_der_Datenbank_ermitteln
Hier werden Öffnungszeiten berechnet, das Verfahren lässt sich aber bestimmt auf deine Anwendung umsetzen.
Ich berechne bei mir bis jetzt immer alles aus den in der Datenbank vorhandenen Werten. Dafür ist die DB ja da und man kann deutlich mehr damit machen als nur Plots zeichnen.
LG,
Heiko
Noch ein kleiner Hinweis.
Das
if ($value = 1) {
sollte
if ($value == 1) {
sein.
Ok, super, vielen Dank.
Oh das == muss ich noch berichtigen.
Ich habe tatsächlich duration in sekunden.
Kann ich also über deinen tip super summieren und per insert wieder in die DB schreiben.
Dazu muss ich denke ich noch zwei neue DBRep anlegen.
Eins mit current_week_begin/current_week_end und eins mit current_month_begin/current_moth_end wie von dir beschrieben.
Ich glaub ich habe es jetzt kapiert wie das geht.
Danke dir vielmals.
Gruß,
Stefan
Zitat
Dazu muss ich denke ich noch zwei neue DBRep anlegen.
Eins mit current_week_begin/current_week_end und eins mit current_month_begin/current_moth_end wie von dir beschrieben.
Ja genau.
Wenn du den summierten Wert nicht umwandeln willst/musst, gibt es auch eine ganz einfache Möglichkeit:
set ... sumValue writeToDB
schreibt dir die Summe als neues Reading (neuer Readingname!) automatisch in die DB zurück. Die comref beschreibt genau wie das Verfahren ist.
Vielleicht das Richtige für dich ...
LG
Ok klingt super.
Ich probiere das mal aus.
Ich muss das mal einfach noch genauer lesen.
Am Anfang erschlägt einem die Wiki, aber eigentlich ist es gar nicht so schwer und alles gut beschrieben.
Sollte ich irgendwo probleme bekommen melde ich mich nochmal, aber ich glaub ich bekomme das jetzt hin.
Wie gesagt vielen Dank für die Hilfe und die tollen möglichkeiten mit DB Log.
Gruß,
Stefan
Danke Stefan und noch viel Erfolg/Freude beim Probieren und Entdecken.
Ich bin überzeugt du kriegst das hin. 8)
Schönen Abend noch ...
Heiko
Ach ... noch einen Hinweis.
Solltest du mal sehr viele DbRep Devices definiert haben, könnte es sich lohnen überall das Attribut
fastStart = 1
zu setzen.
Das bewirkt, dass die DEvices beim Start von FHEM sich nicht sofort mit der DB verbinden sondern erst bei der ersten Benutzung. -> Spart Zeit beim Start.
Aber wie gesagt, macht sich erst ab einer deutlichen Menge bemerkbar, schadet aber auch nicht es generell zu setzen.
Hi Heiko,
ich habe das ganze nun nochmal überarbeitet.
Das ganze geht ja auch komplett ohne user Exit.
SumValue mit writetoDB langt für mich völlig.
Als Attribute habe ich aggragation day und timestamp_begin current_week_begin.
So berechnet er mir für jeden Tag 23:59:58 die Summe der Zeiten, und wenn keine da ist schreibt er 0 (fürs WE oder Urlaub).
Das ganze nochmal für die Summe der Wochenzeit.
Ein at dass die dbRp SumValue mit writetoDB alle 15 minuten ausführt und ich habe immer ein aktuelle anzeige der Arbeitszeit im Graph.
Wusste nicht dass es so mächtig ist.
Super!
Vielen Dank nochmal für die tollen Möglichkeiten.
Frohe Weihnachten und einen guten Rutsch.
Stefan
Hi Stefan,
danke für deine Rückmeldung.
Freut mich, dass du für deine Anwendung das richtige Werkzeug gefunden hast. :)
Wünsche dir ebenfalls schöne Weihnachtsfeiertage,
Heiko
Hi Heiko,
habe nun doch noch eine kurze frage.
Ich mache auch eine Summen aggregation für Wochen.
Leider schreibt er dann den Wert immer Montags mit Zeitstempel 23:59 weg.
Siehe: 2020-01-06 23:59:58 geofancy GEOFANCY calculated sum_week_lastPosDur_rr_Stefan 134813.0000
Kannst du mir erklären warum Montagabends die Woche endet?
Kann ich das beeinflussen?
Danke und Gruß,
Stefan
Hallo Stefan,
dazu müsste man sich die SQLs anschauen die die Summation machen.
verbose 4 im DbRep Device sollte es zeigen.
Grüße,
Heiko
Hi Heiko,
super. Da bekomme ich folgendes:
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - -------- New selection ---------
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - Command: sumValue writeToDB
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - FullDay option: 0
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - Timestamp begin human readable: 2020-01-01 00:00:00
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - Timestamp end human readable: 2020-01-15 22:01:06
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - Aggregation: week
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - SQL execute: SELECT SUM(VALUE) FROM history where ( DEVICE = 'geofancy' ) AND ( READING = 'lastPosDur_rr_Stefan' ) AND TIMESTAMP >= '2020-01-01 00:00:00' AND TIMESTAMP < '2020-01-06' ;
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - SQL execute: SELECT SUM(VALUE) FROM history where ( DEVICE = 'geofancy' ) AND ( READING = 'lastPosDur_rr_Stefan' ) AND TIMESTAMP >= '2020-01-06' AND TIMESTAMP < '2020-01-13' ;
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - SQL execute: SELECT SUM(VALUE) FROM history where ( DEVICE = 'geofancy' ) AND ( READING = 'lastPosDur_rr_Stefan' ) AND TIMESTAMP >= '2020-01-13' AND TIMESTAMP <= '2020-01-15 22:01:06' ;
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - data prepared to db write:
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - 2020-01-01 23:59:58|geofancy|GEOFANCY|calculated|sum_week_lastPosDur_rr_Stefan|86909.0000|
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - 2020-01-06 23:59:58|geofancy|GEOFANCY|calculated|sum_week_lastPosDur_rr_Stefan|163613.0000|
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - 2020-01-13 23:59:58|geofancy|GEOFANCY|calculated|sum_week_lastPosDur_rr_Stefan|97656.0000|
2020.01.15 22:01:06 3: DbRep logdbRepArbeitszeitWeek - number of lines updated in "logdb": 3
2020.01.15 22:01:06 3: DbRep logdbRepArbeitszeitWeek - number of lines inserted into "logdb": 0
TIMESTAMP >= '2020-01-01 00:00:00' AND TIMESTAMP < '2020-01-06' ; bzw.
TIMESTAMP >= '2020-01-06' AND TIMESTAMP < '2020-01-13' ;
und sollte passen. Immer von begin Montag bis Sonntag.
Das Problem ist dass er den Wert dann aber mit dem Zeitstempel 06.01. bzw 13.01. 23:59 schreibt.
2020-01-13 23:59:58 geofancy GEOFANCY calculated sum_week_lastPosDur_rr_Stefan 65256.0000 NULL
Das ist blöd da ich so, wenn ich es in einem Plot Ausgabe die Ausgabe immer von Montag Abend bis Montag Abend hab.
Der Summierte Wert ist aber von Montag Morgen bis Sonntag Abend, oder verstehe ich da was nicht?
Mein Plot sieht auf jedenfall komisch aus.
Danke und Gruß,
Stefan
Hi Stefan,
ZitatDer Summierte Wert ist aber von Montag Morgen bis Sonntag Abend, oder verstehe ich da was nicht?
Nein, so ist es. Passt alles wenn ich dein Log anschaue.
Es wird offensichtlich immer der Anfang der Aggregationsperiode genutzt:
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - data prepared to db write:
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - 2020-01-01 23:59:58|geofancy|GEOFANCY|calculated|sum_week_lastPosDur_rr_Stefan|86909.0000|
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - 2020-01-06 23:59:58|geofancy|GEOFANCY|calculated|sum_week_lastPosDur_rr_Stefan|163613.0000|
2020.01.15 22:01:06 4: DbRep logdbRepArbeitszeitWeek - 2020-01-13 23:59:58|geofancy|GEOFANCY|calculated|sum_week_lastPosDur_rr_Stefan|97656.0000|
Nun ist natürlich die Frage ob man es für den Nutzer irgendwie einstellbar machen könnte.
Aber da bin ich gerade ein bisschen ratlos wie es evtl. umsetzbar wäre.
Hmm,
ich verstehe noch nicht ganz warum der Zeitstempel den Anfang darstellen soll?
Zeitstempel in der DB: 2020-01-13 23:59:58
Abfrage: TIMESTAMP >= '2020-01-13'
d.h. aber dich 13.01.2020 00:00:01 und nicht 23:59:58.
Was übersehe ich?
Für mich sieht das aus als ob der Zeitstempel (also speziell die Uhrzeit) ein Tag zu spät kommt.
Gruß,
Stefan
Zitat
ich verstehe noch nicht ganz warum der Zeitstempel den Anfang darstellen soll?
Da müsste ich nochmal genauer nachschauen. Aber es scheint mir auch Abhängigkeiten vom Select zu geben.
Habe bei mir mal einen Lauf gemacht.
Hier die kalkulierten Readings:
READINGS:
2020-01-15 23:16:40 2019-12-22_23-59-27__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__DIFF__week_51 27.1135
2020-01-15 23:16:40 2019-12-29_23-59-07__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__DIFF__week_52 20.6342
2020-01-15 23:16:40 2020-01-05_23-59-17__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__DIFF__week_01 40.7822
2020-01-15 23:16:40 2020-01-12_23-59-02__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__DIFF__week_02 17.7276
2020-01-15 23:16:40 2020-01-15_23-14-55__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__DIFF__week_03 17.3299
Und hier die DB-writes:
2020.01.15 23:16:39.998 4: DbRep Rep.LogDB1 - data prepared to db write:
2020.01.15 23:16:40.269 4: DbRep Rep.LogDB1 - 2019-12-22 23:59:27|SMA_Energymeter|SMAEM|calculated|diff_week_Einspeisung_Wirkleistung_Zaehler|27.1135|
2020.01.15 23:16:40.272 4: DbRep Rep.LogDB1 - 2019-12-29 23:59:07|SMA_Energymeter|SMAEM|calculated|diff_week_Einspeisung_Wirkleistung_Zaehler|20.6342|
2020.01.15 23:16:39.998 4: DbRep Rep.LogDB1 - 2020-01-05 23:59:17|SMA_Energymeter|SMAEM|calculated|diff_week_Einspeisung_Wirkleistung_Zaehler|40.7822|
2020.01.15 23:16:40.263 4: DbRep Rep.LogDB1 - 2020-01-12 23:59:02|SMA_Energymeter|SMAEM|calculated|diff_week_Einspeisung_Wirkleistung_Zaehler|17.7276|
2020.01.15 23:16:40.266 4: DbRep Rep.LogDB1 - 2020-01-15 23:14:55|SMA_Energymeter|SMAEM|calculated|diff_week_Einspeisung_Wirkleistung_Zaehler|17.3299|
Sehen identisch aus.
Wie hast du deine Zeitgrenzen Attribute gesetzt ?
Ich habe nur:
timestamp_begin current_year_begin
und
aggregation week
Ich möchte das immer nochmal für alle Wochen rechnen da ich eventuell Urlaube usw nachtrage. Dafür habe ich einen dummy der ein insert auslöst.
Für mich passt einfach die selektion im select nicht zum zeitstempel.
Die selektion beginnt am TIMESTAMP >= '2020-01-13' bzw hört mit TIMESTAMP < '2020-01-13' auf.
Dann sollte doch die Summe nicht mit dem Zeitstempel 2020-01-13 23:59:58 geschrieben werden.
Das ist doch 23:59:58 später als es die SQL selektion abfragt.
Gruß und Danke,
Stefan
ZitatDann sollte doch die Summe nicht mit dem Zeitstempel 2020-01-13 23:59:58 geschrieben werden.
Die Uhrzeit wird nicht aus den Zeitgrenzen in den Attributen abgeleitet, sondern aus den Werten die die DB tatsächlich liefert.
Habe einen Lauf genau mit deinen Einstellungen gemacht (timestamp_begin current_year_begin).
Die Readings:
2020-01-15 23:44:45 2020-01-05_23-59-17__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__DIFF__week_01 26.8284
2020-01-15 23:44:45 2020-01-12_23-59-02__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__DIFF__week_02 17.7276
2020-01-15 23:44:45 2020-01-15_23-43-54__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__DIFF__week_03 17.3299
Die writes sind:
2020.01.15 23:44:44.024 4: DbRep Rep.LogDB1 - data prepared to db write:
2020.01.15 23:44:44.024 4: DbRep Rep.LogDB1 - 2020-01-05 23:59:17|SMA_Energymeter|SMAEM|calculated|diff_week_Einspeisung_Wirkleistung_Zaehler|26.8284|
2020.01.15 23:44:44.026 4: DbRep Rep.LogDB1 - 2020-01-12 23:59:02|SMA_Energymeter|SMAEM|calculated|diff_week_Einspeisung_Wirkleistung_Zaehler|17.7276|
2020.01.15 23:44:44.027 4: DbRep Rep.LogDB1 - 2020-01-15 23:43:54|SMA_Energymeter|SMAEM|calculated|diff_week_Einspeisung_Wirkleistung_Zaehler|17.3299|
Das passt und ist so wie es sein soll.
Ist mir jetzt schleierhaft wieso die writes bei dir anders sind.
Grüße,
Heiko
Ach jetzt sehe ich es erst, bei dir wird
05.01.
12.01.
15.01.
geschrieben was super passt.
Und bei mir
01.01.
06.01.
13.01.
was leider nicht passt.
Meine Readings sind auch so verkehrt:
2020-01-01__geofancy__lastPosDur_rr_Stefan__SUM__week_01 86909.0000 2020-01-15 23:56:42
2020-01-06__geofancy__lastPosDur_rr_Stefan__SUM__week_02 163613.0000 2020-01-15 23:56:42
2020-01-13__geofancy__lastPosDur_rr_Stefan__SUM__week_03 97656.0000 2020-01-15 23:56:42
das ist ja absolut seltsam. Hab da eigentlich nichts weiter eingestellt.
Irgendetwas mit Zeitzonen oder so auf dem Raspberry?
Gruß und Danke,
Stefan
Ja, ist mir auch noch ein Rätsel. Wir können nochmal mit verbose 5 schauen.
Allerdings muss man dann die Zeiträume etwas verkürzen, sonst erschlägt einen die Menge.
Schauen wir morgen oder so nochmal genauer, für heute reichts erstmal bei mir ... war noch am coden ... ;)
Lg und gN,
Heiko
Alles klar,
ich denk auch erst nochmal drüber nach.
Vielleicht fällt mir noch was ein.
Dank dir auf jedenfall schonmal für deine Hilfe.
Gruß,
Stefan
Hi Heiko,
ich habe jetzt eine Vermutung woran es bei mir liegt.
Ich mache ja immer eine Tagessumme aus den readings lastPosDur_rr_Stefan. Dies wird dann jeweils an dem Tag mit Zeitstempel 23:59:58 geschrieben.
Aus diesen mache ich dann die Wochensummen aus den readings sum_day_lastPosDur_rr_Stefan. Samstag und Sonntag ist da immer null. Und Montags der erste Wert ist mit Zeitstempel 23:59:58.
Kann es sein dass er dann den Zeitstempel des ersten Wertes von Montag übernimmt.
Dieser ist aber auch wieder versucht durch die Tagessumme und diese wird bei aggregation day als 23:59:58 in den Tag geschrieben.
2020-01-06 23:59:58 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 28800.0000 NULL
2020-01-06 23:59:58 geofancy GEOFANCY calculated sum_week_sum_day_lastPosDur_rr_Stefan 163613.0000 NULL
2020-01-06 17:01:01 geofancy Feiertag manuell lastPosDur_rr_Stefan 28800 NULL
2020-01-05 23:59:58 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 0.0000 NULL
2020-01-04 23:59:58 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 0.0000 NULL
2020-01-03 23:59:58 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 29309.0000 NULL
Ich glaube die Werte der Berechnung stimmen, nur ist der Wert für eine Woche bei mir unter Montag 23:59:58 gelogged.
Um es ordentlich im SVG anzuzeigen bräuchte ich aber 00:00:01.
Irgendwie sollte die Wochen aggregation doch immer Montag 00:00:01 geschrieben werden und nicht mit dem Zeitstempel des ersten Eintrags des aggregierten readings am Montag.
Gibts eine Möglichkeit das anzupassen oder nach zu massieren?
Gruß,
Stefan
P.S.:
Nach etwas testen scheint es aber nicht an dem Timestamp des Dayreadings zu liegen.
Hier die Ausgabe mit Verbose 5 für die aktuelle Woche:
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - -------- New selection ---------
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - Command: sumValue writeToDB
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - FullDay option: 0
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - Timestamp begin epocheseconds: 1578870000
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - Timestamp begin human readable: 2020-01-13 00:00:00
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - Timestamp end epocheseconds: 1579176359
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - Timestamp end human readable: 2020-01-16 13:05:59
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - weekday start for selection: Mo -> wdadd: 604800
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - Daylight savings changed: 0 (on Mon Jan 20 00:00:00 2020)
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - Aggregation: week
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - IsTimeSet: 1, IsAggrSet: 1
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - Timestamp-Array:
week_03#2020-01-13 00:00:00#2020-01-16 13:05:59
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - Devices for operation -
included (1): geofancy
included with wildcard:
excluded (0):
excluded with wildcard:
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - Readings for operation -
included (1): sum_day_lastPosDur_rr_Stefan
included with wildcard:
excluded (0):
excluded with wildcard:
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - SQL execute: SELECT SUM(VALUE) FROM history where ( DEVICE = 'geofancy' ) AND ( READING = 'sum_day_lastPosDur_rr_Stefan' ) AND TIMESTAMP >= '2020-01-13 00:00:00' AND TIMESTAMP <= '2020-01-16 13:05:59' ;
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - SQL result: 97656
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek -> Primary Key used in /opt/fhem/fhem.db.history: none
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek -> Primary Key used in /opt/fhem/fhem.db.current: none
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - data prepared to db write:
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - 2020-01-13 23:59:58|geofancy|GEOFANCY|calculated|sum_week_sum_day_lastPosDur_rr_Stefan|97656.0000|
2020.01.16 13:05:59 3: DbRep logdbRepArbeitszeitWeek - number of lines updated in "logdb": 1
2020.01.16 13:05:59 3: DbRep logdbRepArbeitszeitWeek - number of lines inserted into "logdb": 0
Er startet also mit der selection am TIMESTAMP >= '2020-01-13 00:00:00' , also Montag 00 Uhr, das ist super.
Aber das Ergebnis wird mit 2020-01-13 23:59:58 weggeschrieben?
Mir wird aus dem Log aber nicht klar warum. Ich sehe hier:
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - Timestamp begin epocheseconds: 1578870000 => Zeitstempel begin, Montag 00:00
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - Timestamp begin human readable: 2020-01-13 00:00:00
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - Timestamp end epocheseconds: 1579176359 => Zeitstempel ende, Zeitpunkt der Selektionsausführung
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - Timestamp end human readable: 2020-01-16 13:05:59
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - weekday start for selection: Mo -> wdadd: 604800 => Montag stimmt, wdadd sind genau 7 Tage also bis nächsten Montag 00:00
2020.01.16 13:05:59 5: DbRep logdbRepArbeitszeitWeek - Daylight savings changed: 0 (on Mon Jan 20 00:00:00 2020)
2020.01.16 13:05:59 4: DbRep logdbRepArbeitszeitWeek - Aggregation: week
Woher nimmt er denn den Zeitstempel für den Insert?
Der Kommt doch nirgends vor?
Diesen 23:59:58 nimmt er bei mir bei jeder Aggregation, sowohl Tag als auch Woche.
Wenn ich für heute den Tag die Aggregation laufen lasse bekomme ich auch für heute um 23:59:58 einen Wert in die DB. Also einen Zukunftswert.
Hast du eine Ahnung wo dieser Zeitstempel her kommt? Den gab ich nicht vor.
Gruß,
Stefan
Hallo Stefan,
jetzt habe ich mir den Code zu Gemüte geführt.
Die Angabe xxxxx 23:59:58 wird von mir als Korrektur eingeführt, wenn das resultierende Ergebnis einer Funktion keinen exakten Zeitpunkt angibt.
Als Beispiel hat "maxValue" immer einen konkreten Zeitpunkt des Auftretens des Maximalwertes. sumValue oder diffValue nicht weil der Zeitpunkt des Ergebnisses nicht exakt determiniert.
Soweit der Grund. Warum ich allerdings 23:59:58 statt z.B. 00:00:01 gewählt habe, kann ich jetzt nicht mehr sagen. Ich gehe aber davon aus, dass ich es nicht absolut willkürlich gewählt habe, sondern sicherlich einen Grund dafür gab.
Ich habe ein Attribut "timeAdjust" eingebaut. Wenn du es auf "beginDay" setzt, sollte in solchen Fällen immer 00:00:01 als Time in die DB geschrieben werden.
Liegt in meinem contrib, probiers mal bitte aus.
Download:
"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"
LG,
Heiko
Hi Heiko,
das ist super und funktioniert bei mir. Vielen Dank.
Warum wars bei dir denn ein Tag früher? Hast du kein Sum verwendet?
Jetzt ist mir aber leider doch noch ein Problem aufgefallen.
Er summiert ja alle folgenden 7 Tage.
Also
bearbeiten 2020-01-12 23:59:58 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 0.0000 NULL
bearbeiten 2020-01-11 23:59:58 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 0.0000 NULL
bearbeiten 2020-01-10 23:59:58 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 37168.0000 NULL
bearbeiten 2020-01-09 23:59:58 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 36000.0000 NULL
bearbeiten 2020-01-08 23:59:58 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 25700.0000 NULL
bearbeiten 2020-01-07 23:59:58 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 35945.0000 NULL
bearbeiten 2020-01-06 23:59:58 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 28800.0000 NULL
bearbeiten 2020-01-06 00:00:01 geofancy GEOFANCY calculated sum_week_sum_day_lastPosDur_rr_Stefan 163613.0000 NULL
Der SVG Graph sieht dann aber wie im Anhang aus.
Also die Wochenzeit wird dann nur bis zum 06.01. angezeigt, obwohl die Tage ja vom 06.01 - 12.01. gehen.
Das finde ich jetzt komisch.
Bei der Summe pro Tag schreibst du das Endergebnis um 23:59:58,
müsste das Wochenergebnis nicht dann konsequenterweise mit dem Datum des letzten Wochentags und 23:59:58 geschrieben werden?
Dann würde es auch bei mir passen.
D.h. für die Daten oben müsste die Wochensumme mit diesem Zeitstempel geschrieben werden: 2020-01-12 23:59:58
Sorry für das ganze durcheinander, ich glaube aber so passt es eher.
Gruß und Danke für deine Hilfe,
Stefan
Hi Stephan,
das ist schonmal gut. Den Attributnamen muss ich nochmal ändern. Der muss etwas sprechender zum verwendeten Kontext werden. Muss es ja auch dokumentieren und es muss für den Nutzer nachvollziehbar sein wofür das gut ist.
Sum habe ich verwendet, aber kein writeToDb. Diese Korrektur wird in dieser Unterfunktion eingesetzt.
Welchen Timestamp ich verwende, also entweder Anfang des Wochenzeitraums oder das Ende oder 00 bzw 23 Uhr, ist immer mehr oder weniger problematisch weil je nach Verwendung durch den User unterschiedliche Anforderungen vorhanden sind.
Also ich denke nochmal drüber nach, ob ich das Attribut weiter fassen kann, also beginXXX wird 00:00:01 der Periode, bzw. 23:59:58 mit endeXXX am Ende der Periode damit der Nutzer flexibel ist.
Melde mich vermutlich am WE nochmal dazu.
Jetzt kommst du erstmal klar denke ich.
LG,
Heiko
Ja, super das klingt gut.
Ich danke dir vielmals!
Hallo Stefan,
ich habe mir das Ganze nochmal in Ruhe angeschaut und bin zu der Überzeugung gekommen den Timestamp für writeDB generell auf 00:00:01 zu ändern.
Es ist mir nach vielen Tests in unteschiedlichen Konstellationen nichts negatives aufgefallen.
Das Attribut habe ich wieder gelöscht. Man braucht es dadurch nicht mehr und auch Ausweitung der Funktionalität dieses Attributs hätte programmtechnisch zu viel Aufwand generiert um alles anzupassen.
Zieh dir die Version gerne wieder aus meinem contrib wie in #40 beschrieben.
Grüße,
Heiko
Hi Heiko,
habe es gezogen und für die Tage ist es klasse (siehe Bild),
aber für die Woche past es einfach nicht.
Ich schau mir das jetzt schon sicher ne Stunde an und kapier nicht wo der Fehler liegt.
Ich habe so das Gefühl dass es ein Problem im Plot gibt.
Wenn ich die Woche 13(Montag) - 19(Sonntag) anschaue beginnt sie im Tages Plot (oben) am 13.,
im Wochenplot (unten) aber am 12.? Was ist da los? Warum sind die Tage vom Tagesplot nicht gleich denen im Wochenplot?
Das 2. Problem das es dann noch gäbe ist, dass die Wochenzeiten, im unteren SVG in blau:
1. Diese verschiebung um eine Tag nicht haben und wirklich am 13. angezeigt werden,
2. dies aber um eine Woche zu früh.
2. Kann ich verstehen weil der Wochenwert für meinen Plot wohl eher am 19. 23:59 oder am 20. 00:01 geschrieben werden müsste.
Vielleicht könnte ich das irgendwie in den Daten nach massieren.
Ich denke mittlerweile auch das die Daten so stimmen. Aber die Plotanzeige von Tag und Woche verstehe ich einfach nicht.
Hast du da noch eine Idee?
Gruß und vielen Dank,
Stefan
Hi Stefan,
mit Plots anschauen alleine kommt man da wahrscheinlich nicht weiter.
Du müsstest mal im DbRep ein fetchRows ausführen und posten welche (im SVG anzuzeigenden) Datensätze tatsächlich in der DB vorhanden sind.
Ich habe zum Beispiel seit Anfang des Jahres Energiedaten mit aggregation week aufsummiert und die die DB geschrieben.
Die erstellten Readings aus diem Lauf sind:
2020-01-18 18:18:01 2020-01-01__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__SUM__week_01 108781989.9649
2020-01-18 18:18:01 2020-01-06__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__SUM__week_02 153251990.8751
2020-01-18 18:18:01 2020-01-13__SMA_Energymeter__Einspeisung_Wirkleistung_Zaehler__SUM__week_03 126413825.6330
Die Wochenabgrenzungen sind richtig wie man sieht.
Die daraus resultierenden in die DB zu schreibenden Ergebnsisreadings sind diese (sieht man mit verbose 4):
2020.01.18 18:18:00.839 4: DbRep Rep.LogDB1 - 2020-01-01 00:00:01|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|108781989.9649|
2020.01.18 18:18:00.953 4: DbRep Rep.LogDB1 - 2020-01-06 00:00:01|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|153251990.8751|
2020.01.18 18:18:00.955 4: DbRep Rep.LogDB1 - 2020-01-13 00:00:01|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|126413825.6330|
Du siehst, dass nunmehr der Timestamp am Begin der Periode, z.B. 2020-01-06 00:00:01, geschrieben werden.
Mit fetchrows der Readings "sum_week_Einspeisung_Wirkleistung_Zaehler" (in einem anderen DbRep) müssen sich diese Sätze wiederfinden.
Schau mal bitte ...
Hi Heiko,
ja die Sätze stimmen bei mir jetzt auch. Ich denke ja an den Zeitstempeln liegt es gar nicht aber bei den Plots ist etwas seltsam.
Hier mal die Daten der letzten 14 Tage:
1. Datenbank:
2020-01-18 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 0.0000 NULL
2020-01-17 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 32404.0000 NULL
2020-01-16 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 28585.0000 NULL
2020-01-15 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 32400.0000 NULL
2020-01-14 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 31036.0000 NULL
2020-01-13 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 34220.0000 NULL
2020-01-13 00:00:01 geofancy GEOFANCY calculated sum_week_sum_day_lastPosDur_rr_Stefan 158645.0000 NULL
2020-01-12 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 0.0000 NULL
2020-01-11 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 0.0000 NULL
2020-01-10 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 37168.0000 NULL
2020-01-09 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 36000.0000 NULL
2020-01-08 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 25700.0000 NULL
2020-01-07 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 35945.0000 NULL
2020-01-06 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan 28800.0000 NULL
2020-01-06 00:00:01 geofancy GEOFANCY calculated sum_week_sum_day_lastPosDur_rr_Stefan 163613.0000 NULL
Hier vom Tagesplot die preprocessed Input Werte ( ich teile die Sekunden durch /3600 um auf Minuten zu kommen):
get logdb HISTORY INT 2020-01-13_00:00:00 2020-01-19_23:59:59 geofancy:sum_day_lastPosDur_rr_Stefan:::$val=$val/3600
2020-01-13_00:00:01 9.50555555555556
2020-01-14_00:00:01 8.62111111111111
2020-01-15_00:00:01 9
2020-01-16_00:00:01 7.94027777777778
2020-01-17_00:00:01 9.00111111111111
2020-01-18_00:00:01 0
#geofancy:sum_day_lastPosDur_rr_Stefan:::$val=$val/3600
Und hier vom Wochenplot:
get logdb HISTORY INT 2020-01-01_00:00:00 2020-01-31_23:59:59 geofancy:sum_week_sum_day_lastPosDur_rr_Stefan:::$val=$val/3600 geofancy:sum_day_lastPosDur_rr_Stefan:::$val=$val/3600
2020-01-01_00:00:01 24.1413888888889
2020-01-06_00:00:01 45.4480555555556
2020-01-13_00:00:01 44.0680555555556
#geofancy:sum_week_sum_day_lastPosDur_rr_Stefan:::$val=$val/3600
2020-01-01_00:00:01 8
2020-01-02_00:00:01 8
2020-01-03_00:00:01 8.14138888888889
2020-01-04_00:00:01 0
2020-01-05_00:00:01 0
2020-01-06_00:00:01 8
2020-01-07_00:00:01 9.98472222222222
2020-01-08_00:00:01 7.13888888888889
2020-01-09_00:00:01 10
2020-01-10_00:00:01 10.3244444444444
2020-01-11_00:00:01 0
2020-01-12_00:00:01 0
2020-01-13_00:00:01 9.50555555555556
2020-01-14_00:00:01 8.62111111111111
2020-01-15_00:00:01 9
2020-01-16_00:00:01 7.94027777777778
2020-01-17_00:00:01 9.00111111111111
2020-01-18_00:00:01 0
#geofancy:sum_day_lastPosDur_rr_Stefan:::$val=$val/3600
Ich verstehe nicht warum der Wochenplot bei den Tageswerten am 12.01. einen Wert anzeigt. Da kommt doch 0.
Ist die skala da verrutscht?
P.S.:
Man sieht das gut gerade am 12. und 13. da habe ich einen Tageswert und eine Wochenwert, da es ja ein Montag ist und der Wochenplot bekommt:
2020-01-13_00:00:01 44.0680555555556 => Wochenwert
2020-01-13_00:00:01 9.50555555555556 => Tageswert
Aber doch fängt der Tageswert am 12. an, blauer kasten und der Wochenwert würde am 13. anfangen?
Gruß,
Stefan
Hi Stefan,
also die Werte in der DB stimmen nun wirklich und sind so wie sie sein sollen.
D.h. die Datenbasis ist korrekt, was ich nur nochmal sicherstellen wollte.
Alles andere ist nun eine Geschichte der Anzeige / Auswertung.
ZitatIch verstehe nicht warum der Wochenplot bei den Tageswerten am 12.01. einen Wert anzeigt. Da kommt doch 0.
Ja stimmt. Es müsste eigentlich eine Linie von 0 am 12. beginnend nach 9,5 am 13. schräg von unten nach rechts oben sein wie ich es im angehängten Bild habe versucht darzustellen :)
Ich bin kein SVG Experte, aber vielleicht gibt es eine Linieart die das kann ... evtl. bei den SVG Spezialisten mal fragen.
EDIT: Alternativ müsste dieser Wert am 12.01. nicht 00:00:01 geschrieben werden, sondern um 23:59:58. Dann würde sich die Darstellung nicht überlappen.
Zitat... und der Wochenwert würde am 13. anfangen?
Ja, richtig. Das Problem ist aber dass SVG ja nur einen Wert bis zum 13.01. bekommt, obwohl der Wert für den ganzen Zeitraum 13.01. bis 19.01. (bzw. bis zum gegenwärtigen Tag) gilt. Aber das weiß SVG ja nicht.
Zur kompletten Darstellung fehlt noch der Endwert der aktuellen Periode.
Hmm, damit der User eine Möglichkeit hat auf die zu schreibenden Werte in die DB EInfluss zu nehmen, kann ich mir vorstellen eine valueFn (wie ich es in DbLog gemacht habe) einzubauen. Dann kann der User eine Logik einfügen um Timestamps, Readingnamen und Werte beeinflussen zu können die in die DB geschrieben werden sollen.
So wäre es zum Beispiel möglich, beim Wochenwert, der ja durch "week" im Readingsnamen gekennzeichnet ist, einen weiteren Datensatz für die aktuelle Zeit in die DB zu schreiben. Das würde der PLot dann auch zeigen.
Das wäre auf jeden Fall etwas für den "advanced" Anwender, aber sehr flexibel um allle möglichen Aufgabenstellungen zu erschlagen.
Was denkst du ?
Hi Heiko,
ah ja richtig.
Wenn am 12.01. (Sonntag) der 0 Wert um 23:59 geschrieben wird siehts gut aus :-)
So langsam wirds mir klar.
Eigentlich bräuchte ich wohl immer für eine range einen Wert am Anfang und am Ende.
Also für einen Tag bräuchte ich einen Eintrag um 00:01 und 23:59.
Für eine Woche Montag um 00:01 und Sonntag um 23:59.
Mit einer user funktion bekomme ich das hin.
Würde es Sinn machen das auch irgendwie als standard anzubieten?
So etwas wie aggregate_begin_end?
Gruß,
Stefan
Zitat
Mit einer user funktion bekomme ich das hin.
Würde es Sinn machen das auch irgendwie als standard anzubieten?
So etwas wie aggregate_begin_end?
Ich denke mal drüber nach. Die Tücke steckt im Detail weil das unter allen theoretisch vorkommenden Auswertungsvarianten, Aggregationen und Zeitabgrenzungen funktionionieren muss. Die Tücke steckt wir immer im Detail. ;)
Melde mich hier wieder ...
LG,
Heiko
Alles klar,
dank dir vielmals!
Gruß,
Stefan
Hallo Stefan,
jetzt habe ich die Write-Back Funktion für die setter averageValue und sumValue ziemlich umgebaut. Diese Setter bringen keinen definierten Zeitpunkt im Ergebnis.
Nun werden die Ergebnisse jeweils zum Begin und zum Ende der jeweiligen Aggregationsperiode in die DB geschrieben.
Also so z.B. für eine aggregation = hour:
2020-01-22 23:23:43 2020-01-01_00-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_00-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_01-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_01-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_02-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_02-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_03-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_03-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_04-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_04-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_05-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_05-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_06-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_06-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_07-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_07-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2480
2020-01-22 23:23:43 2020-01-01_08-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2954
2020-01-22 23:23:43 2020-01-01_08-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 913966.2954
2020-01-22 23:23:43 2020-01-01_09-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 898751.7360
2020-01-22 23:23:43 2020-01-01_09-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 898751.7360
2020-01-22 23:23:43 2020-01-01_10-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 914081.0231
2020-01-22 23:23:43 2020-01-01_10-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 914081.0231
2020-01-22 23:23:43 2020-01-01_11-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 914235.4951
2020-01-22 23:23:43 2020-01-01_11-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 914235.4951
2020-01-22 23:23:43 2020-01-01_12-00-01__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 914377.0826
2020-01-22 23:23:43 2020-01-01_12-59-59__1__SMA_Energymeter__sum_hour_Einspeisung_Wirkleistung_Zaehler 914377.0826
Ich habe jeweils eine Sekunde am Anfang/Ende versetzt um eine gute Abgrenzung zu haben.
Probier mal wie es nun aussieht. Liegt wieder in meinem contrib.
LG,
Heiko
Oh cool, das ist genau was ich brauche.
Ich teste es heute Abend.
Danke,
Stefan
Hi Heiko,
habs gerade getestet.
Hatte noch ein Problem, das aber einfach zu beheben war.
Hatte die Wochensummen aus den Tagessummen gebildet, anstatt die Einzelwerte zu nehmen.
Somit war die Wochensumme doppelt. Da die Tagessummen ja 2 x geschrieben werden.
Habe bei der Wochensummen nun nicht mehr die Tagessummen sondern die Einzelwerte und es geht.
Das ist wirklich toll!
Eine Sache fällt mir immer noch auf, aber eventuell lese ich den Plot auch falsch. (siehe Bild)
Der Tagesplot (diese Woche) sieht super aus (Montag - Donnerstag).
Unten im Wochenplot sieht es für mich so aus als wären die Tage (rot) und auch der Wochenbeginn (blau) um einen Tag verschoben.
Also starten erst Dienstag.
Die gestrichelte linie im Plot zeigt doch Ende Sonntag und Anfang Montag, oder?
Hier mal die Werte der Plots:
Tagesplot (dort ist alles gut, Montag ist Montag):
2020-01-20_00:00:01 8.85388888888889
2020-01-20_23:59:59 8.85388888888889
2020-01-21_00:00:01 8.33833333333333
2020-01-21_23:59:59 8.33833333333333
2020-01-22_00:00:01 10.6536111111111
2020-01-22_23:59:59 10.6536111111111
2020-01-23_00:00:01 9
2020-01-23_23:59:59 9
Wochenplot
2020-01-01_00:00:01 24.1413888888889
2020-01-05_23:59:59 24.1413888888889
2020-01-06_00:00:01 45.4480555555556
2020-01-12_23:59:59 45.4480555555556
2020-01-13_00:00:01 44.0680555555556
2020-01-19_23:59:59 44.0680555555556
2020-01-20_00:00:01 36.8458333333333
2020-01-23_23:59:59 36.8458333333333
#geofancy:sum_week_lastPosDur_rr_Stefan:::$val=$val/3600
2020-01-01_00:00:01 8
2020-01-01_23:59:59 8
2020-01-02_00:00:01 8
2020-01-02_23:59:59 8
2020-01-03_00:00:01 8.14138888888889
2020-01-03_23:59:59 8.14138888888889
2020-01-04_00:00:01 0
2020-01-04_23:59:59 0
2020-01-05_00:00:01 0
2020-01-05_23:59:59 0
2020-01-06_00:00:01 8
2020-01-06_23:59:59 8
2020-01-07_00:00:01 9.98472222222222
2020-01-07_23:59:59 9.98472222222222
2020-01-08_00:00:01 7.13888888888889
2020-01-08_23:59:59 7.13888888888889
2020-01-09_00:00:01 10
2020-01-09_23:59:59 10
2020-01-10_00:00:01 10.3244444444444
2020-01-10_23:59:59 10.3244444444444
2020-01-11_00:00:01 0
2020-01-11_23:59:59 0
2020-01-12_00:00:01 0
2020-01-12_23:59:59 0
2020-01-13_00:00:01 9.50555555555556
2020-01-13_23:59:59 9.50555555555556
2020-01-14_00:00:01 8.62111111111111
2020-01-14_23:59:59 8.62111111111111
2020-01-15_00:00:01 9
2020-01-15_23:59:59 9
2020-01-16_00:00:01 7.94027777777778
2020-01-16_23:59:59 7.94027777777778
2020-01-17_00:00:01 9.00111111111111
2020-01-17_23:59:59 9.00111111111111
2020-01-18_00:00:01 0
2020-01-18_23:59:59 0
2020-01-19_00:00:01 0
2020-01-19_23:59:59 0
2020-01-20_00:00:01 8.85388888888889
2020-01-20_23:59:59 8.85388888888889
2020-01-21_00:00:01 8.33833333333333
2020-01-21_23:59:59 8.33833333333333
2020-01-22_00:00:01 10.6536111111111
2020-01-22_23:59:59 10.6536111111111
2020-01-23_00:00:01 9
2020-01-23_23:59:59 9
#geofancy:sum_day_lastPosDur_rr_Stefan:::$val=$val/3600
Also wenn ich mir die Werte anschaue ist das eindeutig verschoben. Oder ist die gestrichelte linie der Anfang vom Sonntag?
Mit dieser Verschiebung könnte ich aber auch leben :-)
Gruß und vielen vielen Dank,
Stefan
Hallo Stefan,
sieht für mich gut aus. Die preprocessed Wochenwerte habe ich verglichen und die stimmen.
Im Anhang noch ein Bild, wo ich dir den Beginn der Tage mal eingezeichnet habe.
Das einzige was mich stört ist, dass die blaue Wochenlinie am Anfang vom Samstag 18.01. nicht auf 0 geht so wie die preprocessed Werte es zeigen. Aber das ist eine Anzeigesache.
Denke das können wir als Standard einchecken. :)
LG,
Heiko
Ok,
dann habe ich das falsch gesehen. Ich dachte an der gestrichelten Linie beginnt die Woche, also Anfang Montag.
So wie du es eingezeichnet hast passt es. Dann find ich aber die gestrichelte Linie falsch. Warum sollte die Anfang Sonntag sein?
Die blaue Woche kann nicht SA auf 0 gehen da sie von Montag 00:01 bis Sontag 23:59 gespeichert ist.
Das sind die 4 Werte oben im preprocesed bei den Wochen Werten.
Die unten sind die Tageswerte da ist am 18.01. eine 0.
Der Wochenwert der über den 18en geht ist das:
2020-01-13_00:00:01 44.0680555555556
2020-01-19_23:59:59 44.0680555555556
Von der DB Seite stimmt aber alles, die Werte passen perfekt. Das kannst du einchecken.
Wie gesagt, ich weiß garnicht wie ich dir danken kann.
Gruß,
Stefan
Bitte Stefan, wieder ein Mehrwert für den User ...
Ich habe hier https://forum.fhem.de/index.php/topic,53584.msg1016388.html#msg1016388 noch eine Nachbesserung für PostgreSQL. Wenn ich damit durch bin checke ich die neue Version ein.
Grüße,
Heiko
Alles klar,
hat ja keine Eile, zumal ich ja deine Repo Version jetzt erstmal benutzen kann :-)
Danke für deine Mühe,
Stefan
Hi Heiko,
hab doch noch ein kleines Problem entdeckt.
Beim Wochenzeit berechnen setzt er den Ende Zeitstempel auf den Tag der Abfrage und nicht aufs Ende der Woche.
Was dazu führt wenn man für die aktuelle Woche Montags, Dienstags, Mittwochs, ... jeweils einen lauf macht um eine aktuelle Summe zu bekommen, man jeden Tag einen Wert um 23:59 hat.
Beispiel:
2020-01-20_00:00:01 45.7069444444444 => Anfang der Woche (Montag)
2020-01-23_23:59:59 36.8458333333333 => Ein Lauf am Donnerstag mit aggregation week
2020-01-24_23:59:59 45.7069444444444 => Ein Lauf am Freitag mit aggregation week
Ich denke bei aggregation week müsste immer der kommende Sonntag 23:59 als Endpunkt genommen werden.
Also im Beispiel sollte es nur einen Wert geben und zwar 26.01. 23:59
Richtig?
Gruß,
Stefan
Hi Stefan,
naja, das entspricht dem generellen Vorgehen bei den Zeitabgrenzungen im Modul. Wenn du mit timeDiffToNow arbeitest bzw. kein timestamp_end gesetzt ist, wird immer die Zeit des Kommandostarts als Endezeit genommen. Die Zeitscheiben ergeben sich dann entsprechend.
Du könntest also beispielsweise timestamp_end auf current_year_end setzen. Dann würdest du so etwas bekommen:
2020.01.24 22:10:06.478 4: DbRep Rep.LogDB1 - data prepared to db write:
2020.01.24 22:10:06.478 4: DbRep Rep.LogDB1 - 2020-01-01 00:00:01|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|108781989.9649|
2020.01.24 22:10:06.662 4: DbRep Rep.LogDB1 - 2020-01-05 23:59:59|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|108781989.9649|
2020.01.24 22:10:06.664 4: DbRep Rep.LogDB1 - 2020-01-06 00:00:01|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|153251990.8751|
2020.01.24 22:10:06.666 4: DbRep Rep.LogDB1 - 2020-01-12 23:59:59|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|153251990.8751|
2020.01.24 22:10:06.668 4: DbRep Rep.LogDB1 - 2020-01-13 00:00:01|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|153643135.9409|
2020.01.24 22:10:06.669 4: DbRep Rep.LogDB1 - 2020-01-19 23:59:59|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|153643135.9409|
2020.01.24 22:10:06.671 4: DbRep Rep.LogDB1 - 2020-01-20 00:00:01|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|108673132.8991|
2020.01.24 22:10:06.673 4: DbRep Rep.LogDB1 - 2020-01-26 23:59:59|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|108673132.8991|
2020.01.24 22:10:06.675 4: DbRep Rep.LogDB1 - 2020-01-27 00:00:01|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|0.0000|
2020.01.24 22:10:06.676 4: DbRep Rep.LogDB1 - 2020-02-02 23:59:59|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|0.0000|
2020.01.24 22:10:06.678 4: DbRep Rep.LogDB1 - 2020-02-03 00:00:01|SMA_Energymeter|SMAEM|calculated|sum_week_Einspeisung_Wirkleistung_Zaehler|0.0000|
....
Nachteilig ist, dass es dann für die zukünftigen Wochen, die es noch nicht gibt 0 in die DB geschrieben wird.
Vielleicht kann man das durch eine geschickte Wahl der Zeiteingrenzung oder eine dynamische Änderung in deinen at-Scripten eine Optimierung finden.
Naja, man kann nicht alles haben ;)
LG,
Heiko
Hi Heiko,
das kling aber gut.
Also timestamp_end nur weit genug in die Zukunft setzen?
Finde ich praktikabel. Eigentlich müsste ich es nur immer auf Sonntag setzen im at.
Da bekomme ich sicher was hin.
P.S.: Current_Week_End kling perfekt für mich. Ich probiers gleich mal.
P.P.S: Perfekt! Es klappt!
Danke,
Stefan
Ah ja ... Current_Week_End. Das ist mir nicht eingefallen ???
Super Stefan .... geht doch (fast) alles :D
LG,
Heiko
Hi Heiko,
soweit läuft alles bestens.
Eine Sache hätte ich noch, wenn die SUM laufen bekomme ich immer diese Meldung:
2020.02.08 01:28:07 1: PERL WARNING: Argument "" isn't numeric in sprintf at ./FHEM/93_DbRep.pm line 10708.
2020.02.08 01:28:07 3: DbRep logdbRepArbeitszeitWeek - number of lines updated in "logdb": 12
2020.02.08 01:28:07 3: DbRep logdbRepArbeitszeitWeek - number of lines inserted into "logdb": 0
2020.02.08 01:28:07 3: DbRep logdbRepArbeitszeit - number of lines updated in "logdb": 78
2020.02.08 01:28:07 3: DbRep logdbRepArbeitszeit - number of lines inserted into "logdb": 0
Ich habe schon bei den Werten gesucht die ich summiere es ist aber kein nich Zahlenwert dabei?
Irgendeine Idee?
Kann ich etwas in Zeile 10708 einbauen um zu sehen worum es sich handelt?
Danke und Gruß,
Stefan
Hallo Stefan,
schön zu lesen. :)
Habe es mir angeschaut. Kann m.M. nur dann auftreten wenn in einem ausgewerteten Zeitraum keinerlei MAX auftriit, also ein leerer String zurückgeliefert wird. Würde auch zur Meldung passen.
Ich habe es (hoffentlich) gefixt. Teste mal bitte die Version aus meinem contrib.
LG,
Heiko
Reload 93_DbRep.pm bringt:
syntax error at ./FHEM/93_DbRep.pm line 61, near ""08.02.2020 fix PERL WARNING: Argument "" isn't numeric in sprintf at ./FHEM/93_DbRep.pm line 10708 ""
BEGIN not safe after errors--compilation aborted at ./FHEM/93_DbRep.pm line 1709.
Gruß,
Stefan
Sorry ... bitte nochmal ziehen.
Jetzt hats geklappt.
Ich schaue ob der Fehler weg ist und melde mich wieder.
Danke!
Keine Meldungen mehr im Log.
Alles Super.
Dank dir!
Gruß,
Stefan
Danke Stefan !
Werde die Version morgen einchecken ....
LG,
Heiko
Ist im Repo und morgen früh im Update.
Grüße,
Heiko
Hallo Heiko,
werden bei SUM keine 0 Werte mehr in die DB geschrieben?
Ich bekomme für eine Woche das hier:
2020-02-24__geofancy__lastPosDur_rr_Stefan__SUM__2020-02-24 29429.0000
2020-02-25__geofancy__lastPosDur_rr_Stefan__SUM__2020-02-25 33811.0000
2020-02-26__geofancy__lastPosDur_rr_Stefan__SUM__2020-02-26 35323.0000
2020-02-27__geofancy__lastPosDur_rr_Stefan__SUM__2020-02-27 30600.0000
2020-02-28__geofancy__lastPosDur_rr_Stefan__SUM__2020-02-28 31904.0000
2020-02-29__geofancy__lastPosDur_rr_Stefan__SUM__2020-02-29 -
2020-03-01__geofancy__lastPosDur_rr_Stefan__SUM__2020-03-01 -
Und für die Tage mit "-" werden keine Werte in die DB geschrieben.
Das führt bei mir dann dazu, dass der Wert des letzten Tages mit einem Wert, hier 2020-02-28, über die nächsten 2 Tage im Plot geht.
Ich weiß das ist wieder eine Besonderheit meiner Zeitaufzeichnung.
Keine 0 Werte schreiben ist wohl schon richtig.
Kann ich mit einer User funktion wenn "-" ausgerechnet wird einen "0" in die DB schreiben?
Gruß,
Stefan
Hi Stefan,
Zitatwerden bei SUM keine 0 Werte mehr in die DB geschrieben?
Also geändert ist nichts. 0 wird geschrieben, wenn die Summe = 0 ist.
Für Tage mit "-" gibt es offenbar keine Werte bzw. kein Ergebnis.
ZitatKann ich mit einer User funktion wenn "-" ausgerechnet wird einen "0" in die DB schreiben?
Nicht direkt wenn du "sumValue writeToDB" ausführst.
Aber es gibt ein paar Workarounds die mir adhoc einfallen ...
* changeValue im DbRep drüber laufen lassen ->
set <name> changeValue "-","0" , du must natürlich darauf achten in dem benutzten DbRep das Device und Reading richtig einzustellen damit nur die "-" umgesetzt werden die umgesetzt werden sollen
* im SVG-Editor mit Regex arbeiten und das "-" in "0" umwandeln -> $val=~s/-/0/
Habe die Vorschläge jetzt nicht ausgetestet, aber sollte so klappen. Gibt bestimmt noch mehr Möglichkeiten.
Grüße,
Heiko
Hi Heiko,
danke für deine Antwort.
Völlig Richtig, an den Tagen bei denen "-" erzeugt wird gibt es keine Werte zum Summieren.
Mein Problem ist dass sumValue display die "-" anzeigt aber sumValue writeToDB nichts in die DB schreibt.
In der DB landet also bei "-" garnichts. Ich bräuchte für die tage aber ein "0" Eintrag.
Somit gehen denke ich die beiden Lösungsvorschläge weiter nicht.
Ich habe auch versucht einen 0 Wert einzufügen den der SUM dann hätte auswerten können.
Es kam aber weiter "-".
Erst wenn ein Wert > 0 da war hat er auch den Wert in die DB summiert.
Das ganze ist irgendwie seltsam, da ich am Anfang als wir das ganze hier besprochen und getestet haben durchaus 0 Werte hatte.
Wenn dir auf anhieb nichts einfällt schaue ich mir das näher an und versuche mal herauszufinden was da genau passiert.
Gruß und Danke,
Stefan
Da fällt mir tatsächlich erstmal nichts weiter ein. Auf jeden Fall hat sich seit unserer initialen Einrichtung bzw. dem letten Fix nichts im Modul geändert.
ZitatMein Problem ist dass sumValue display die "-" anzeigt aber sumValue writeToDB nichts in die DB schreibt.
Ja, die Anzeige soll dem User verdeutlichen, dass eben nichts selektiert werden konnte. In der DB müssen in dem betrachteten Zeitraum irgendwelche Werte vorhanden sein damit DbRep etwas auswerten kann.
Wenn 0 in der DB steht, müssen aber Ergebnisse kommen !
Guck dir mal mit verbose 4/5 an was genau selektiert wird.
Hallo Stefan,
möglicherweise hat der letzte Fix vom 8.2. doch Auswirkungen.
Mach mal bitte einen Negativtest mit der angehängten Version.
Hi,
ja gerade getstet. Mit der alten Version von dir funktioniert es noch und 0 Werte werden geschrieben.
Was nun besser ist bei Tagen an denen nichts zu summieren ist weiß ich nicht genau.
Mit der alten Version sieht mein Plot wieder gut aus.
Gruß und Danke,
Stefan
Hmm, allerdings hast du dann wieder unter Umständen die Warnings aus #63.
Fragt sich was besser ist ... ich überlege ob ich vllt. noch eine bessere Variante finde.
Hi Stefan,
probier mal die Version aus meinem contrib.
"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"
Hi Heiko,
sieht gut aus.
Logfile ohne Fehler:
2020.03.01 18:38:08 3: DbRep logdbRepArbeitszeit - number of lines updated in "logdb": 122
2020.03.01 18:38:08 3: DbRep logdbRepArbeitszeit - number of lines inserted into "logdb": 0
Und in der DB schreibt er jetzt "Null" was im Plot gut funktioniert.
2020-02-29 23:59:59 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan NULL NULL
2020-02-29 00:00:01 geofancy GEOFANCY calculated sum_day_lastPosDur_rr_Stefan NULL NULL
Perfekt, vielen Dank!
Stefan
Sehr schön, danke Stefan.
Ich checke es ein, ist morgen früh im Update.
LG,
Heiko
Super,
dank dir vielmals!
Gruß,
Stefan
Hi Heiko,
hab nun doch noch ein kleines Problem.
Wenn ich Plots zu den Summen aufrufe erscheint folgendes im Log:
2020.03.07 01:00:48 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1570.
Das passiert da an den Tagen an denen es nichts zu summieren gab in der Value spalte bei der Summe nichts steht.
Also auch keine 0.
Ich habe jetzt schon versucht mit allem möglichen drum herum zu kommen.
z.B.
$val=($val>0?$val/3600:0)
$val=($val=~/[\d.-]?$val/3600:0)
All das führt aber nur wieder zu Fehlern.
PERL WARNING: Use of uninitialized value $val in pattern match (m//) at (eval 41071) line 1.
Auf defined kann ich im Plot so glaub ich nicht abfragen.
Zumindest zerreist es mir die Plot definition wenn ich
$val=(defined $val?$val/3600:0)
schreibe.
Hast du da noch eine Idee?
Gruß und Danke,
Stefan
Morgen Stefan,
versuchs mal so:
$val=(defined$val?$val/3600:0)
Diese Definition im Plotfile darf keine Leerzeichen enthalten.
Grüße,
Heiko
Hi,
danke. Wusste nicht dass man das so hinschreiben kann.
Leider kommt trotzdem:
2020.03.07 15:30:32 1: PERL WARNING: Argument "" isn't numeric in division (/) at (eval 171891) line 1.
Scheint nicht zu ziehen.
Ein Verbose=5 am Plot zeigt leider nicht mehr.
Gruß,
Stefan
Hi Stefan,
dann müsste man es z.B. so erweitern denke ich:
$val=((defined$val&&$val=~/\d*.\d*/)?$val/3600:0)
Grüße,
Heiko
Wow,
das tut!
Ich dank dir vielmals.
Gruß,
Stefan