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

[RalfRog]

Ich habe noch einen kleinen Fehler korrigiert.
Weiterhin wird nun bei sqlCmd.../Blocking der formatierte SQL Code im Reading sqlCmd ausgegeben wenn das Statement fehlerhaft war.
Das erleichtert das Editieren und neu ausführen des Codes.
-> contrib
LG

Wart mal mit dem einchecken. Eventuell hatte die Änderung vongestern Nebenwirkungen.

Habe heute Nachmittag versucht ein set dbrep changeValue old="%" new={"($VALUE,$UNIT) = ($VALUE,"kWh")"} zu machen.
Ergebnis ==> 2023.01.06 14:13:11.844 3: DbRep DBRep2_MT - WARNING - old value "%" not found in database "fhem"

Gestern vor der Verwendung der contrib-Version hat das noch geklappt 
==> 2023.01.05 16:50:06.491 3: DbRep DBRep2_MT - VALUE changed in "fhem" - old: "%", new: "($VALUE,$UNIT) = ($VALUE,"kWh")", number: 15
==> 2023.01.05 16:55:04.446 3: DbRep DBRep2_MT - VALUE changed in "fhem" - old: "%", new: "($VALUE,$UNIT) = ($VALUE,"kWh")", number: 3119

Ich  habe es gerade nochmal ohne Wildcard im reading mit gleichem fehlerhaftem Ergebnis versucht
==> 2023.01.06 23:55:08.031 3: DbRep DBRep2_MT - WARNING - old value "%" not found in database "fhem"

hmm...

[RalfRog]

Ja doof... Problem sitzt vor der Tastatur

Das ist keine Fehlermeldung sondern der Hinweis, dass im gewählten Teitraum keine Daten zu Anpassen da sind.
Kaum wählt man den passenden zeitraum schon geht es - oh Mann 

Gruß Ralf

[DS_Starter]

Hallo Ralf,

alles gut. Hatte heute Abend eh keine Zeit für Rep weil ich an anderer Stelle beschäftigt war.
Aber morgen dann .. jetzt erstmal gute Nacht. 

LG

[RalfRog]

....
So weit so schön - im zweiten (oder auch dritten) Schritt müssen dann noch die Originaleinträge reduziert werden sowie (je nach Parameter) noch einer der beiden berechneten Werte am Anfang/Ende des Intervalls reduziert und zusätzlich ggfs. auch noch die neuen Namen in den Readings angepasst werden.

Dann ist (wenn es reicht, dass die Werte ungefähr den Trend zeigen) eventuell ein einfaches "reduceLog average" einfacher (auch hinsichtlich der Wartbarkeit des Konstrukts).
...

Nur mal eine Idee ...

Bei den Funktionen maxValue und minValue gibt es neben dem einfachen writeToDB auch deleteOther.
An sich wäre das doch eine schöne Möglichkeit für averageValue (bei gewichtetem Mitttelwert) nur den erechneten Wert zu behalten und auf die anderen Werte zu verzichten.
Kommt einem reduceLog average nahe aber je nach Anwnedungsfall mit "besseren" Mittelwerten.

Gruß Ralf

[DS_Starter]

Hallo Ralf,

das ist nicht ganz so einfach weil  je nach Methode nicht immer die Datensätze einzeln selected und verarbeitet werden und
Die SQL AVG-Funktion genutzt wird.
Somit stehen die Datensätze nicht zur Verfügung um sie "in einem Rutsch" gleich mit löschen zu können.
Deswegen gibt es bei dem Setter diese Option nicht. 

[DS_Starter]

@all,
der aktuelle Entwicklungsstand ist eingecheckt und morgen früh im Update enthalten.

LG

[RalfRog]

@all,
der aktuelle Entwicklungsstand ist eingecheckt und morgen früh im Update enthalten.

LG

Ok zu naiv gedacht 

Der set averageValue erzeugt ja neue zusätzliche Readings. Dabei wird der Type nicht 1:1 übernommen. Z.B. aus SHELLY wird Shelly.
Keine Ahnung ob so was an anderen Stellen (außerhalb der DB) wegen Unterscheidung von Groß-/Kleinschreibung zu Problemem führen kann.

Ich hoffe ich wärme hier jetzt keine alten Hüte auf. Hab aber auch nicht wirklich was gefunden.

Gruß Ralf

[DS_Starter]

Hallo Relf,

bei dem neuen Readingsnamen wird nicht der TYPE verwendet, sondern (aus ComRef):


Der neue Readingname wird aus einem Präfix und dem originalen Readingnamen gebildet, wobei der originale Readingname durch das Attribut "readingNameMap" ersetzt werden kann. Der Präfix setzt sich aus der Bildungsfunktion und der Aggregation zusammen.


Diesen Namen findest du auch nur in der DB, sonst nirgendwo.

[RalfRog]

Hallo
Das hatte ich in der CommandRef gelesen.
Ich hatte es so verstanden (passiert ja auch so), dass für das Feld 'READING' aus dem Readingnamen "power" standardmäßig (aggregation hour) "avgtwm_hour_power" gebildet und eingetragen wird ('EVENT' wird "calculated" und 'UNIT' (Null)).

Zum Feld 'TYPE' wird doch eigentlich nichts gesagt?

"TIMESTAMP"                   "DEVICE"                      "TYPE"       "EVENT"      "READING"                   "VALUE"  "UNIT"
"2023-01-08 16:59:59"   "shelly_plug_s_df2674"   "Shelly"   "calculated"   "avgtwm_hour_power"   "1"   \N
"2023-01-08 16:17:02"   "shelly_plug_s_df2674"   "SHELLY"   "power: 0"   "power"                       "0"  "W"


Gruß

[DS_Starter]

Achso, jetzt verstehe ich was du meinst. Da muss ich mal in den Code schauen ....

[DS_Starter]

Also .... DbRep macht das richtig. Aber ... DbLog schreibt den Device TYPE generell in Großbuchstaben in die DB.
Jetzt bin ich mit mir am hadern ob ich DbRep an DbLog anpasse oder DbLog ändere.

Ich tendiere zu ersterem. Die Auswirkungen das Verhalten von DbLog zu ändern kann ich nicht abschätzen. Vllt. haben sich User Auswertungen über den TYPE gebaut etc.

[RalfRog]

oh sorry hättte direkt etwas präziser sein können.

Ne Frage am Rande.
Wenn man regelmäßig (z.B. täglich) die DB etwas aufbereiten will (z.B. mit Average und Max o.ä.) dafür jeweils mehrere einzelne DBRep's braucht.

Wie verkettet man die denn am geschicktesten (Blocking, non_Blocking), dass die schön nacheinander abgearbeiet werden.
Dafür noch jeweils ein AT zu kreiern führt ja durchaus auch zu Unübersichtlichkeit.

Gruß Ralf

[DS_Starter]

Mit einer Chain. Das hatte ich letztens hier beschrieben:

https://forum.fhem.de/index.php/topic,114815.msg1255834.html#msg1255834

(Wollte ich noch ins Wiki packen ... komme einfach zu nix  )

[RalfRog]

Also .... DbRep macht das richtig. Aber ... DbLog schreibt den Device TYPE generell in Großbuchstaben in die DB.
Jetzt bin ich mit mir am hadern ob ich DbRep an DbLog anpasse oder DbLog ändere.

Ich tendiere zu ersterem. Die Auswirkungen das Verhalten von DbLog zu ändern kann ich nicht abschätzen. Vllt. haben sich User Auswertungen über den TYPE gebaut etc.

Stimmt. Hatte ich noch gar nicht gesehen. Der Type im Modul ist "Shelly".

Ich habe zwar das Problem mit der Groß-/Kleinschreibung noch nicht aber das genau war der Hintergrund die Frage aufzuwerfen.

DBLog gibts ja schon länger....   Gefühlt denke ich auch, dass die User eher auf die "Eigenheitheiten" von DBLog bei den Auswertungen Rücksicht genommen haben und sich daher auf Großschreibung des Moduls eingestellt haben.
Kann man bisher ja nur über SQLbeeinflussen (Ich hatte zunächst analog zu readingRename nach typeRename  geschaut).

[RalfRog]

Mit einer Chain. Das hatte ich letztens hier beschrieben:

https://forum.fhem.de/index.php/topic,114815.msg1255834.html#msg1255834

(Wollte ich noch ins Wiki packen ... komme einfach zu nix  )

Danke