93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

Icebear · 06 April 2017, 13:47:18

Hi joe,
und wie finde ich nun raus ob's noch gewartet wird ?
Habe mir die Split Funktion gerade mal angesehen. Scheint relativ einfach (auch wenn ich kein PERL mensch bin) aber es müssten noch andere Änderungen zum Einchecken gemacht werden (hilfe usw).
Gibts ne entsprechende Hilfe was ich tun muss um Maintainer des Moduls zu werden, falls es keinen mehr gibt / der nicht mehr aktiv ist ?!

JoeALLb · 06 April 2017, 13:53:57

Puh, das ist jetzt nicht mein Spezialgebiet...

Generell schau mal in diese Liste:
https://svn.fhem.de/trac/browser/trunk/fhem/MAINTAINER.txt

Wenn bei deinem Modul niemand steht, schreib Rudi an uns sag ihm, dass du gerne Maintainer sein möchtest.
Wenn du es vom dort eingetragenen Maintainer "übernehmen" möchtest, schreib den bisherigen an. Wenn er sich nicht meldet,
sag wieder Rudi bescheid.

Icebear · 06 April 2017, 14:00:31

hi joe,

Habe ich gemacht, der eine Maintainer ist nicht auffindbar. Den anderen habe ich angeschrieben ...
Allerdings war der seit 23. März nicht Online ...
Ich wart mal 2-3 Tage ...
und nu schluss mit OT ..
Grüße aus Dinslaken
Holger ak Icebear.

DS_Starter · 06 April 2017, 20:01:44

Hallo miteinander,

hier nun die finalisierte Version 2.16.3.
Diese Version ist für den check-in vorgesehen.
Hier nochmal zusammengefasst die Neuerungen seit der eingecheckten V 2.14.4:

* neues Attribut valueFn um eine anwenderspezifische Funktion auf die Werte anwenden zu können
@Joe, $TIMESTAMP funktioniert nun auch veränderlich ... nur zum Beispiel:

Code Auswählen

{ if ($DEVICE eq "MyWetter" && $READING eq "wind"){ $TIMESTAMP="2017-04-06 19:00:00"; } }

Es wird beim Timestamp die Form "yyyy-mm-dd hh:mm:ss" geprüft. Ist Timestamp nicht valide, wird er nicht übernommen und der alte verwendet

* neues set addLog Kommando. Es hat die Form:

Code Auswählen

set <device> addLog <devspec>,<Reading>,[Value]

Value ist optional, kann aber gesetzt werden um einen spezifischen Wert in die DB einzufügen.
In der DB wird nur noch der Feldwert von "Event" auf "addLog" gesetzt. TYPE wird devspec-spezifisch geloggt.
Reading wird als regulärer Ausdruck ausgewertet.

* Verbesserte Sortierung von listCache

* ein paar kleinere Verbesserungen (ZWAVE split, Logging mit verbose 4/5)

* Commandref ist ergänzt

Bitte testet die Version, speziell die neuen Features und gebt bitte Feedback.

@Joe ...

ZitatVielleicht wäre diese Ergänzung im Log hilfreich um weitere Maintainer dazu zu bekommen, ihre Module um splitFn zu ergänzen?

Die Idee ist Klasse, nur die Stelle nicht. Dort würden wir jedes Logfile zuspammen weil jeder Event dieses Schleife durchläuft.
Wenn wir eine nicht so "brachiale" Stelle finden würden wäre das eine feine Sache um da mal weiter zu kommen.

Grüße
Heiko

JoeALLb · 07 April 2017, 08:41:42

Hallo Heiko,

bin gerade am Testen und jetzt weiß ich, warum meine Tests für die Ersetzung von TIMESTAMP nicht funktioniert haben:
in set sql cacheList habe ich die Einträge mit addLog gesehen, weshalb ich davon ausging, diese auch ändern zu können.
Dieser Code matched jedoch nie. Im Nachhinein auch verständlich, doch gestern hat mich das einiges an Testzeit gekostet.
Ich frage mich, ob wir hier das Event schon rechtzeitig ersetzen sollten oder ob wir das als Hinweis vermerken sollen?

Code Auswählen

{
  if($EVENT eq "addLog"){
    $TIMESTAMP = "2017-04-04 00:00:01" ;;
  }

DS_Starter · 07 April 2017, 14:44:58

Hallo Joe,

du hast recht. Es macht Sinn, $EVENT in der addlog-Funktion vor dem Durchlaufen von valueFn auf "addlog" zu setzen.
Dann hat man die Möglichkeit innerhalb von valueFn $EVENT auf "addlog" zu prüfen und davon abhängig den $TIMESTAMP zu korrigieren.
Das wäre IMHO auch so ziemlich der einzige Fall wo man die Anpassung von $TIMESTAMP sinnvoll anwenden könnte.
Die anderen Felder hat man ja bereits gesplittet zur Auswertung zur Verfügung.

Ich habe die angehängte Version in #258 nochmal geringfügig dafür angepasst und in der Commandref deutlich gemacht.

Grüße
Heiko

erwin · 07 April 2017, 15:10:04

Hallo Heiko
Vorerst mal vielen, vielen Dank für den Aufwand den Ihr treibt um das Db Modul besser und funktioneller zu machen.

Ich erlaube mir dennoch einen Kommentar zu diesem Satz:

ZitatDas wäre IMHO auch so ziemlich der einzige Fall wo man die Anpassung von $TIMESTAMP sinnvoll anwenden könnte.
Die anderen Felder hat man ja bereits gesplittet zur Auswertung zur Verfügung.

Mir fallen da etliche Anwendungen ein, wo ein Timestamp NICHT die aktuelle Zeit sein muss/soll:
z.B. hab ich einen Stromzähler, der neben der aktuellen Last/Einspeisung auch werte wie: Monat-Zählerstand, Monats-Maximum-Verbrauch/Einspeisung, usw. ausgibt - und das für die letzten 12 Monate.
Das funktioniert dzt. (aus einem Modul heraus) nur durch massive Eingriffe in die internen Stukturen von fhem. (manipulieren von readingsUpdate)

Verallgemeinert könnte das eine Lösung für alle möglichen (offline-) Daten-Logger sein.

l.g & danke Erwin

DS_Starter · 07 April 2017, 15:16:34

Hi erwin,

an sowas hab ich natürlich wieder nicht gedacht.

Also danke und bringt eure Ideen gerne hier ein ... das hilft uns allen bei Verbesserungen und Lösungsmöglichkeiten.

LG
Heiko

JoeALLb · 07 April 2017, 15:22:53

Hm, für diesen Fall bräuchte man aber auch die Funktion "UPDATE" im SQL, da sich die Monatssumme ja im Monatsverlauf ändern kann....
Das ist im Moment nicht vorgesehen, wäre aber eine wunderbare Ergänzung, die ich auch sofort nutzen würde!

Damit könnte man sich zB auch einen Plot konfigurieren, der den Monatsverbrauch in einer Jahresdarstellung anzeigt,.....

wie $IGNORE=1; könnte man dies über $UPDATE=1; steuern... Ich nehm das mal als Wunsch in der ersten Seite mit auf!

EDIT1: Da fallen mir auf Anhieb zahlreiche weitere Möglichkeiten ein. zB wenn ich nur an einem Stundenschnitt des Verbrauchs interessiert bin, kann ich einen Logeintrag für jede Stunde in der Datenbank erhöhen(updaten)... und spare mich gleich zahlreiche andere Logeinträge, die ich später wieder löschen muss.... Die Idee gefällt mir, würde jedoch vorab vorschlagen, die aktuuelle Version in eine Veröffentlichung zu bringen!

DS_Starter · 07 April 2017, 15:31:22

ZitatDie Idee gefällt mir, würde jedoch vorab vorschlagen, die aktuuelle Version in eine Veröffentlichung zu bringen!

Unbedingt ... und es kommen auch bald Feiertage

JoeALLb · 07 April 2017, 15:54:59

@Heiko:

Noch eine Idee, im Moment würde mich jedoch nur eine grobe Einschätzung von Dir interessieren:
Ich habe meine DB ja in Partitionen eingeteilt, und eine Partition dabei heißt "Papierkorb".
Ich logge dort Werte, die ich nicht lange aufbewahren möchte. Die Partition kann ich verzögerungsfrei komplett löschen, egal ob 1000 oder 1 Mio Datensätze enthalten sind.

Nun die Frage: Wäre der Aufwand, in valueFN eine Möglichkeit zu integrieren, die den Wert einer Spalte nach der Units-Tabelle füllt/ändert, hoch?

Die Spalte wird im Moment per Tabellenlayout und Default auf 0 gesetzt. Manuell und per MySQL-Trigger ändere ich dies für gewisse Datensätze auf 1, also Papierkorb.
Mein Wunsch wäre nun praktisch in etwa so:

valueFn

Code Auswählen

{if ($DEVICE eq "Bewegungssensor" && $READING eq "moving" ){ $PAPIERKORB = 1; #oder $SPALTE8=1;}}

Die Grundüberlegung geht dahin, dass man so auch bei anderen Funktionen statt DELETE ein "update history set papierkorb=1 where XXX;" machen könnte, und die
zu löschenden Datensätze dann mit einem einzigen Befehl verzögerungsfrei löschen kann... So könnte man die Datensätze, die gelöscht werden auch nochmal vorab überprüfen..

schöne Grüße
Joe

Edit: Wunsch#2 Schön wäre, wenn <Reading> von addLog auch mit Regex angegeben werden könnte....

DS_Starter · 07 April 2017, 17:00:10

Hallo Joe,

ZitatNun die Frage: Wäre der Aufwand, in valueFN eine Möglichkeit zu integrieren, die den Wert einer Spalte nach der Units-Tabelle füllt/ändert, hoch?

Naja nur in valueFn noch eine Variable setzen zu lassen ist kein Akt. Aber dahinter muß ja noch etwas kommen. Die SQL-Statements müssen ein Insert/Update in eine normalerweise nicht existierende Spalte durchführen, oder sehe ich da etwas falsch ?

ZitatEdit: Wunsch#2 Schön wäre, wenn <Reading> von addLog auch mit Regex angegeben werden könnte

Das verstehe ich nicht. Es ist aber so dass geprüft wird ob das angegebene Reading tatsächlich im Device existiert, da ja der Readingswert abgefragt werden muß um hinterher die Splittingfunktionen zu durchlaufen. Vielleicht kannst du es nochmal genauer erläutern.

JoeALLb · 07 April 2017, 17:14:02

Zitat von: DS_Starter am 07 April 2017, 17:00:10
Die SQL-Statements müssen ein Insert/Update in eine normalerweise nicht existierende Spalte durchführen, oder sehe ich da etwas falsch ?

Nein, das ist korrekt! Darum vermute ich den Aufwand eher hoch?!?

Zitat von: DS_Starter am 07 April 2017, 17:00:10
Das verstehe ich nicht.

Ich habe ein Device, von welchem ich mehrere Readings per Addlog gleichzeitig schreiben möchte.

Statt

Code Auswählen

set <name> addLog Clima,measured-temp
set <name> addLog Clima,desired-temp
set <name> addLog Clima,humidity

wäre es elegant, es so zusammenfassen zu können...

Code Auswählen


set <name> addLog Clima,(.*?-temp|humidity)

Besonders bei dynamischen Readings wäre das hilfreich... , und würde vom System her zum <device> Parameter passen, den man per devspec auch als regex angeben kann

sG
Joe

DS_Starter · 07 April 2017, 22:27:43

Hallo Joe, @all,

ZitatEdit: Wunsch#2 Schön wäre, wenn <Reading> von addLog auch mit Regex angegeben werden könnte

Habe das nun auch noch umgesetzt und die Version 2.16.3 im Beitrag #258 hinterlegt.

ZitatNun die Frage: Wäre der Aufwand, in valueFN eine Möglichkeit zu integrieren, die den Wert einer Spalte nach der Units-Tabelle füllt/ändert, hoch?

Dazu habe ich auch inzwischen eine Idee. Muss die noch etwas weiter denken und ausprobieren wenn ich dazu komme....

Aber das mache ich erst wenn die Version 2.16.3 getestet und eingecheckt ist

Grüße
Heiko

JoeALLb · 08 April 2017, 11:43:50

Zitat von: DS_Starter am 07 April 2017, 22:27:43
Habe das nun auch noch umgesetzt und die Version 2.16.3 im Beitrag #258 hinterlegt.

Wow, welch tolles neues Feature!!

Anbei ein Beispiel, mit welchem man die in FHEM recht häufig benutzten Heizungsaktore "HM-CC-RT-DN"
um Mitternacht direkt loggen kann.
Vielleicht wäre das was für die COmmandref?

Code Auswählen

set sql addLog TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN:FILTER=subType!=(virtual|),(measured-temp|desired-temp|actuator)

Danke vielmals, schöne Grüße
Joe