DbLogInclude: Wie mehrere Readings loggen wenn ein Reading matched

Begonnen von stefanru, 26 November 2019, 21:01:08

Vorheriges Thema - Nächstes Thema

stefanru

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

DS_Starter

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.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

stefanru

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

DS_Starter

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 ?
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

stefanru

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

DS_Starter

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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

stefanru

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

DS_Starter

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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

stefanru

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

stefanru

#39
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

DS_Starter

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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

stefanru

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


DS_Starter

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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

stefanru


DS_Starter

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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter