DbRep - Aggregationen mit writeToDB und Verhalten nach löschen von Datensätzen

[Sany]

Hallo DbRep-Wissende,
Nach eineiger Zeit mit loggen in die Datenbank (statt FileLog) will ich nun (endlich) ein paar Auswertungen realisieren, um den Datenbestand (~40GB!!) früher oder später zu verkleinern. Die DB läuft hat schon ein paar Jahre...(immer noch sehr performant).
Im Moment geht es um folgendes: Diverse Stromzähler (PV-Erzeugung, Bezug, Einspeisung etc) werden per DbRep ausgewertet: Aggregation tägich, monatlich und jährlich. Die Aggregationen werden in die Db geschrieben (writeToDB). Die DbReps werden kurz nach Mitternacht gestartet (per multiCmd). Das klappt soweit. Nun möchte ich demnächst beginnen, "alte" Datensätze auszumisten. Was passiert nun, wenn DbRep wiederum eine Aggregation versucht, aber kein Ergebnis hinbekommt, weil da nun alte Datensätze fehlen?
Beispiel: Aggregation "year" mit timestamp_begin = previous_year_begin und timestamp_end = previous_day_end.
Das ergibt 2 Einträge, einen mit dem vollständigen letzten Jahr und einen mit dem Wert seit Jahresbeginn. Lösche ich nun z.B. alle Daten älter als Jahresbeginn würde diese Aggregation für das vorige Jahr kein Ergebnis liefern können ( ich meine, das wird dann "less_data_in_period"). Wie sieht es dann mit dem erzeugten Eintrag von vor dem Löschen aus? Wird der mit "-" überschrieben oder bleibt der bestehen?
Noch ne Frage (rein interessehalber) zu diffValue und aggregation: die commandref lese ich so, daß alle Differenzen vom angegebenen Start bis zum Ende aufaddiert werden. Ist das tatsächlich so? Beispiel wieder Aggregation "year" und minütlichen Werten in der DB wäre das ja eine ganze Menge Rechnerei. Hätte eher vermutet, das nur die Differenz zwischen erstem und letzten Wert im Zeitraum verrechnet werden.

Freue mich über neue Erkenntnisse.


weihnachtlichen Gruß


Sany

[ch.eick]

Hallo Sany,
sobald Du einmal aufgeräumt hast würde ich die DbRep Jobs für dynamische Zeiträume regelmäßig laufen lassen.
Also am Monatsanfang für den letzten Monat, das geht dann auch schneller.

Deine Fragen interessieren mich jedoch auch, weshalb ich mich hier mal rein klinke.

Bei meinen Zählern würde ich gerne den maxValue für jede 15 oder 30 Minuten behalten wollen.

Code Auswählen Erweitern

attr LogDBRep_Test aggregation minute

Erstellung der Funktionsergebnisse in Zeitscheiben innerhalb des Selektionszeitraumes.

    no - keine Aggregation (default)
    minute - die Funktionsergebnisse werden pro Minute zusammengefasst
    hour - die Funktionsergebnisse werden pro Stunde zusammengefasst
    day - die Funktionsergebnisse werden pro Kalendertag zusammengefasst
    week - die Funktionsergebnisse werden pro Kalenderwoche zusammengefasst
    month - die Funktionsergebnisse werden pro Kalendermonat zusammengefasst
    year - die Funktionsergebnisse werden pro Kalenderjahr zusammengefasst

Ich denke die Zählerrelevanten Aggregierungen werden jetzt zunehmen, wenn alle Ihr PV-Anlagen auswerten möchten

Über MySQL hätte ich da eins meiner Monster SELECTs in Vorbereitung, die ja einige bereits kennen

Code Auswählen Erweitern

-- Um die Uhrzeit auf 15 oder 30 Minuten zu runden wäre soetwas möglich
-- Bis 22' würde auf 15 und ab 23' auf 30 gerundet.

select from_unixtime(900 * round(unix_timestamp('2021-05-23 16:23:05')/900));

-- Hier mal mein Ergebnis bei einem WallBox Zähler, der für jedes neue Anspöpseln
-- wieder bei 0 beginnt. Momentan fehlt mir da noch der 0 Wert zu Beginn

select
  from_unixtime(900 * round(unix_timestamp(max(TIMESTAMP))/900)) AS TIMESTAMP,
  DEVICE,
  READING,
  max(VALUE) AS VALUE
from history
where DEVICE  = 'WB_1'
--  and READING = 'cp_7_get_imported'
  and READING = 'cp_7_set_log_imported_since_plugged'
  and TIMESTAMP BETWEEN '2024-01-01 00:00:00' AND '2024-02-01 00:00:00'
 GROUP BY UNIX_TIMESTAMP(TIMESTAMP) DIV 900
LIMIT 3000
;

# TIMESTAMP DEVICE READING VALUE
2024-01-08 17:30:00 WB_1 cp_7_set_log_imported_since_plugged 730
2024-01-08 17:45:00 WB_1 cp_7_set_log_imported_since_plugged 4320
2024-01-08 18:00:00 WB_1 cp_7_set_log_imported_since_plugged 7040
2024-01-08 18:15:00 WB_1 cp_7_set_log_imported_since_plugged 9750
2024-01-08 18:30:00 WB_1 cp_7_set_log_imported_since_plugged 12470
2024-01-08 18:45:00 WB_1 cp_7_set_log_imported_since_plugged 15180
2024-01-08 19:00:00 WB_1 cp_7_set_log_imported_since_plugged 17880
2024-01-08 19:15:00 WB_1 cp_7_set_log_imported_since_plugged 20640
2024-01-08 19:15:00 WB_1 cp_7_set_log_imported_since_plugged 21630


2024-01-16 17:15:00 WB_1 cp_7_set_log_imported_since_plugged 70
2024-01-16 17:30:00 WB_1 cp_7_set_log_imported_since_plugged 980
< snip >
2024-01-16 21:30:00 WB_1 cp_7_set_log_imported_since_plugged 48090


2024-01-21 19:45:00 WB_1 cp_7_set_log_imported_since_plugged 800
< snip >
2024-01-22 05:30:00 WB_1 cp_7_set_log_imported_since_plugged 50770
2024-01-22 05:30:00 WB_1 cp_7_set_log_imported_since_plugged 51680


2024-01-26 18:30:00 WB_1 cp_7_set_log_imported_since_plugged 990
2024-01-26 18:45:00 WB_1 cp_7_set_log_imported_since_plugged 3750
2024-01-26 19:00:00 WB_1 cp_7_set_log_imported_since_plugged 6550
< snip >
2024-01-26 23:00:00 WB_1 cp_7_set_log_imported_since_plugged 52350


2024-01-28 22:15:00 WB_1 cp_7_set_log_imported_since_plugged 0
2024-01-28 22:30:00 WB_1 cp_7_set_log_imported_since_plugged 260
2024-01-28 22:45:00 WB_1 cp_7_set_log_imported_since_plugged 4850
< snip >
2024-01-29 05:15:00 WB_1 cp_7_set_log_imported_since_plugged 26170
2024-01-29 05:30:00 WB_1 cp_7_set_log_imported_since_plugged 28340
Das ganze würde dann noch als INSERT erweitert werden und unter einem anderen READING Namen geschrieben.
Ein Delete für die alten Werte wäre denkbar, oder man aggregiert sie nochmals mit DbRep auf z.B. Tageswerte
und lässt dann die DbRep Logik löschen.


VG   Christian