Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[DS_Starter]

Hallo Tobias,

eine wahrscheinlich einfache Lösung wäre den Datensatz "2024-09-17 01:30:00-HT_WP_EnergyMeter-energy_sum" entweder zu löschen oder aber vorab den Timestamp des Datensatzes auf z.B. 2024-09-17 01:35:00" zu ändern damit er nicht kollidiert und den PK verletzt.

Das ist aber nur zielführend wenn es nur in Ausnahmefällen vorkommt.

Gibt es eine Möglichkeit ein "executeAfterProc" nur auszuführen, wenn der Lauf fehlerfrei beendet wurde?
Oder mach ich das am besten direkt in Perl in der art:...

Naja, du kannst in "executeAfterProc" statt des "Zielbefehls" auch den Perl-Code in der Form:

Code Auswählen Erweitern

{(ReadingsVal("$name", "state", "error") ne "error")?fhem("set ...."):""}

hinterlegen. Dann hast du die Abhängigkeit von bestimmten Ergebnissen.
"Fehlerfrei" ist auch relativ. Auch wenn kein techn. Fehler vorliegt kann ein Ergebnis trotzdem logisch falsch sein.

LG,
Heiko

[tobi01001]

Das ist aber nur zielführend wenn es nur in Ausnahmefällen vorkommt.

Ja eben, aber es ist doch nicht unwahrscheinlich, dass man genau zu diesem Zeitpunkt einen Wert in der DB hat und die average Variante da ein Update drauf machen möchte?

Ich frage mich eher, warum kann mit

Code Auswählen Erweitern

UPDATE history SET TIMESTAMP=2024-09-17 01:30:00, EVENT=rl_av_h, VALUE=4047409.5043 WHERE DEVICE=HT_WP_EnergyMeter AND READING=energy_sum AND TIMESTAMP=2024-09-17 01:01:01 AND VALUE=4047393
nicht das bestehende Reading aktualisiert werden kann?
Letztendlich will ich ja den Durchschnittswert der Stunde zu diesem Zeitpunkt dahinschreiben (lassen)?

Also warum gelingt das dem UPDATE Befehl nicht?

Das nächste Problem ist dann, dass der Vorgang an der Stelle abgebrochen wird.


Wenn ich das ricthig verstehe, berechnet das Modul den Durchschnitt und aktualisiert den ersten Eintrag innerhalb der Stunde auf xx:30:00 und den entsprechenden Durchschnittswert. Nachdem (TIMESTAMP, DEVICE, READING) bei mir primary key sind, darf es da keine doppelten Einträge geben (ein Reading eines DEVICE kann nicht zur selben Zeit unterschi9edliche Werte annehmen).

Wäre es da nicht besser den Wert um xx:30:00 zu aktualisieren (sofern er existiert) und andernfalls den ersten?
Bin mir nur nicht sicher, wie man das in der Datenbank realisieren sollte...

Ich würde mir jetzt wohl so helfen:

Code Auswählen Erweitern

UPDATE fhem.history SET TIMESTAMP = TIMESTAMP + INTERVAL 1 SECOND WHERE MINUTE(TIMESTAMP) = 30 AND SECOND(TIMESTAMP) = 00 AND TIMESTAMP BETWEEN '2024-09-01 00:00:00' AND '2024-09-30 23:59:59';
Das könnte man ja vorher über z.B. executeBeforeProc laufen lassen. Wie bekomme ich aber die entsprechenden Attribute im DbRep-Device bzw. die Parameter im Aufrud mit berücksichtigt?

Danke schonmal,
Tobias

Nachtrag:

Code Auswählen Erweitern

SELECT *
FROM fhem.history
WHERE (TIMESTAMP > "2024-09-01 00:01:00" AND TIMESTAMP < "2024-12-17 02:30:01" AND MINUTE(TIMESTAMP) = 30 AND SECOND(TIMESTAMP) = 00) AND EVENT!="rl_av_h"
LIMIT 1000;
liefert mir bereits 1000 Zeilen mit Werten die konkret zur halben Stunde geschrieben werden.

Nachtrag 2:

Macht es Sinn im DbRep mit valueFn den Timestamp vor dem Schreiben in die DB zu ändern?

Kommt mir alles wie eine Krücke vor....

[DS_Starter]

Hallo Tobias,

Ja eben, aber es ist doch nicht unwahrscheinlich, dass man genau zu diesem Zeitpunkt einen Wert in der DB hat und die average Variante da ein Update drauf machen möchte?

Nein, ist es nicht. Es macht auch kein Problem wenn man die FHEM Standard Datenbankkonfiguration ohne Primary Key verwendet.
Ist ein Primary Key definiert, verhindert der jedoch "Duplicate Keys". Das will der User ja in diesem Fall, sonst würde er den PK nicht setzen.

Ich frage mich eher, warum kann mit ... nicht das bestehende Reading aktualisiert werden kann?
Also warum gelingt das dem UPDATE Befehl nicht?

Wegen dem definierten Primary Key, der verhindert das. Hier konkret auf einen vorhandenen Datensatz mit identischen TIMESTAMP, DEVICE und READING.
Hast du ja selbst auch schon geschrieben.

Das nächste Problem ist dann, dass der Vorgang an der Stelle abgebrochen wird.

Du willst doch dass von 40000 zu verarbeitenden Datensätzen nicht nur 20000 korrekt ausgeführt werden und die anderen Daten zwar gelöscht werden, aber kein Update mit dem Ergebnis erfolgt, oder? 

Ich würde mir jetzt wohl so helfen ....
Das könnte man ja vorher über z.B. executeBeforeProc laufen lassen. Wie bekomme ich aber die entsprechenden Attribute im DbRep-Device bzw. die Parameter im Aufrud mit berücksichtigt?

executeBeforeProc wäre dafür ungeeignet. Um mehrere Abläufe seriell auf der Datenbank ausführen zu lassen, kann man den Set-Befehl "multiCmd" verwenden. Hier kann man verschiedene Attribut-Setzungen im jeweiligen Step definieren.

Macht es Sinn im DbRep mit valueFn den Timestamp vor dem Schreiben in die DB zu ändern?

Das kann man im DbLog entsprechend machen, ja das wäre ein Weg.

Kommt mir alles wie eine Krücke vor....

Nur wenn man vom FHEM Standard abweicht (hier Primary Key gesetzt). Sonst hat man da kein Problem.
Abweichen kan man, ist ja alles flexibel. Dann muß man aber auch mit eventuellen Nachteilen umgehen.

Ich verwende übrigens auch einen PK, schimpfe aber nicht auf die DB wenn die meine Anweisung umsetzt und nicht updated.
 

 

[tobi01001]

Hallo Heiko,

Danke für die ausführliche Rückmeldung.

Nur wenn man vom FHEM Standard abweicht (hier Primary Key gesetzt). Sonst hat man da kein Problem.

Ja, wobei an der Stelle der "Standard" etwas merkwürdig ist. Welche Information steckt denn in zwei Einträgen, die sich - wenn überhaupt - nur in Event und Wert unterscheiden? Welcher Wert stimmt denn dann? Das Problem habe ich zwar unbemekrt mit PK über zusätzlich TIMESTAMP auch - nur, dass eben einer der Werte gar nicht erst in der DB landet.

Dann muß man aber auch mit eventuellen Nachteilen umgehen.

Das versuche ich ja gerade.

ch verwende übrigens auch einen PK, schimpfe aber nicht auf die DB wenn die meine Anweisung umsetzt und nicht updated.

Ich schimpfe ja auch nicht auf die DB. Ich möchte nur verstehen bzw die DB davon überzeugen, dass man auch mit Primary Key über Timestamp Durchschnittswerte berechnen kann.

executeBeforeProc wäre dafür ungeeignet. Um mehrere Abläufe seriell auf der Datenbank ausführen zu lassen, kann man den Set-Befehl "multiCmd" verwenden. Hier kann man verschiedene Attribut-Setzungen im jeweiligen Step definieren.

Danke, das schaue ich mir mal an.


Mein aktuelles Vorgehen ist:
- Manuell die Werte in der DB mit TIMESTAMP zur halben Stunde und EVENT!="rl_av_h" um eine Sekunde schieben.
- über valueFn den TIMESTAMP von hh:30:00 auf xx:30:01 ändern. Damit sind alle Werte in der DB die eigentlich hätten um hh:30:00 geloggt werden müssen um eine Sekunde verschoben und ein darauffolgendes DEVICE:READING um hh:30:01 würde verloren gehen. Das ist für das logging aus meiner Sicht unkritisch (zumal sekündliches logging wohl etwas viel ist).
Dann sollte das in Zukunft funktionieren.

Vielleicht fällt mir nochwas "eleganteres" ein.

[cwagner]

Leider habe ich ein Brett vorm Kopf bei der Interpretation der commandref für changeValue. Ich möchte in einer durch timestamp.* begrenzten Zeitspanne für das Device Zaehler im Reading power die in der Datenbank gesammelten Werte durch den Faktor 1.5277 korrigieren. Alle Varianten, die ich als Beispiele durchgespielt habe, lieferten Fehler. Die letzte führte dann /(dank dbrep-Backup zum beherschbaren Gau). Nun steht in jedem Feld {$VALUE*1.5277}

Shit. Was mache ich falsch bzw. besser?

Christian

[Parallix]

Guten Morgen,

in meinem contrib liegt eine neue DbRep Version zunächst zum Test.
Folgende Punkte sind umgesetzt:

- das Attribut allowDeletion ist obsolet
...

Soeben ist mir aufgefallen, dass das o.g. Attribut im Wiki noch an mehreren Stellen in seiner ursprünglichen Form beschrieben wird.

[DS_Starter]

Leider hat das Forum mal wieder keine Mails geschickt ... passiert immer mal wieder.

@Christian,

Shit. Was mache ich falsch bzw. besser?

Nun hast du nicht geschriebn wie du es ausgeführt hast aber möglicherweise hast du die einschließenden "..." vergessen:

Code Auswählen Erweitern

new={"$VALUE = $VALUE * 1.5277"}

@Parallix,

danke für den Hinweis. Habe ich im Wiki entfernt.

LG

[cwagner]

Nun hast du nicht geschriebn wie du es ausgeführt hast aber möglicherweise hast du die einschließenden "..." vergessen:

Code Auswählen Erweitern

new={"$VALUE = $VALUE * 1.5277"}

Vielen Dank, für den Hinweis und ins "Schwarze" getroffen - danke!
Christian