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

[DS_Starter]

Habe die angepasste Version 4.13.5 im Eingang hinterlegt.
Eval sollte nun auch das prepare schützen.

VG

[DS_Starter]

Hallo Johannes, @all,

ich habe noch etwas geändert und zusammengefasst.
Es gibt nur noch das Command "sqlCmd".

Es umfasst alle Darstellungsformen:

* separated - als Einzelreadings (default)
* sline        - Singleline
* mline       - Multiline
* table        - als Tabelle

Das Attribut zur Formatierung heißt nun "sqlResultFormat" und das Reading "SqlResult".
Das letzte Kommando wird in Reading "sqlCmd" gespeichert. Damit ist es beim Set gleich wieder vorbelegt.
Ich denke das macht alles etwas übersichtlicher und man kann sich dennoch jede gewünschte Darstellungsform auswählen.
Die Commandref ist auch erstellt.

Diese neue Version 4.13.7 befindet sich wie gehabt im 1. Beitrag.

Wenn alles soweit passt werde ich die Version demnächst mal einchecken. Ich teste aber auch noch ein bisschen.

VG
Heiko

[viegener]

Die Änderungen klingen alle sinnvoll, klasse! Ich komme nur leider in den nächsten Tagen wohl nicht zum Testen.

[DS_Starter]

Hallo zusammen,

die Version 4.14.0 enthält nun einen UserExit mit dem Benutzer eigenen Code zur Auführung bringen können (im ersten Beitrag).
Die Schnittstelle wird über das Attr "userExitFn" eingeschaltet und funktioniert OHNE Events und ist dazu geeignet Ergebnisse von  DbRep weiterzubearbeiten die sonst wegen der zu hohen Eventgenerierung das System zu sehr belasten würden.

Hier die Zusammenfassung der geplanten Commandref und ein konkretes Beispiel wie es sich im Wiki wiederfinden soll.


Commandref

* '''userExitFn'''  : stellt eine Schnittstelle zur Ausführung eigenen Usercodes zur Verfügung

Um die Schnittstelle zu aktivieren, wird zunächst die aufzurufende Subroutine in 99_myUtls.pm nach folgendem Beispiel erstellt:

Code Auswählen Erweitern

sub UserExitFunction {
my ($name,$reading,$value) = @_;
my $hash = $defs{$name};
...
# z.B. übergebene Daten loggen
Log3 $name, 1, "UserExitFn $name called - transfer parameter are Reading: $reading, Value: $value " ;
...

return;
}

Die Aktivierung der Schnittstelle erfogt durch Setzen des Funktionsnames im Attribut.
Optional kann ein Reading:Value Regex als Argument angegeben werden. Wird kein Regex angegeben, sind alle Wertekombinationen wahr (entspricht .*:.*).

Beispiel:
attr <device> userExitFn UserExitFunction .*:.*
# "UserExit" ist die Subroutine in 99_myUtils.pm. Die Routine wird bei jeder Reading/Value Kombination aufgerufen.

Grundsätzlich arbeitet die Schnittstelle OHNE Eventgenerierung. Sofern das Attribut gesetzt ist, erfolgt Die Regexprüfung NACH der Erstellung eines Readings. Ist die Prüfung WAHR, wird die angegebene Funktion aufgerufen.
Zur Weiterverarbeitung werden der aufgerufenenen Funktion die folgenden Variablen übergeben:

* $hash - der Hash des DbRep-Devices
* $reading - der Namen des erstellen Readings
* $value - der Wert des Readings

---------------------------------------------------------------------------------------------------------------------------

Wiki-Beitrag

=== finden von alten Devices in der DB und versenden/loggen einer Negativliste ===

Wenn eine Datenbank längere Zeit gelaufen ist, Devices in FHEM hinzugefügt, geändert oder gelöscht wurden oder auch das DEF des DbLog-Devices angepasst wurde, werden sich aller Wahrscheinlichkeit nach Datensätze von Devices in der DB finden die nicht mehr gewünscht sind.

Dieses Beispiel soll einen Weg zeigen wie man mit Hilfe der DbRep-sqlCmd Funktion (ab Version 4.14.0) alle in der DB enthältenen Devicenamen ermitteln und mit einer Positivliste vergleichen kann.
Die Negativliste der der nicht gewünschten Devices wird im Logfile ausgegeben bzw. mit TelegramBot versendet.

Zunächst wird das Device wieder wie im Abschnitt [[#Definieren_eines_DbRep-Devices | "Definieren eines DbRep-Devices"]] beschrieben definiert.
Dadurch wird das DbRep-Device mit einem DbLog-Device assoziiert und mit der Datenbank des DbLog-Device verbunden. Alle weiteren Operationen werden mit dieser Datenbank durchgeführt. In diesem Beispiel heißt das DbRep-Device "Report" und das DbLog-Device "LogDB".

Nach der Definition setzen wir die Attribute:

Code Auswählen Erweitern

attr Report event-on-update-reading state
attr Report sqlResultFormat separated

Es werden nun nur noch Events für "state" generiert. Das Attribut "sqlResultFormat = separated" bewirkt, dass das Ergebnis des SQL-Statements zeilenweise mit Einzelreadings zur Verfügung gestellt wird.

Nun kann getestet werden ob die Abfrage grundsätzlich funktioniert. Dazu wird das benutzerspezifische Kommano "sqlCmd" verwendet.

Code Auswählen Erweitern

set Report sqlCmd select device, count(*) from history group by DEVICE;

Es sollte nun eine entsprechende Anzahl von Readings erzeugt werden (Browserrefresh), die als Wert eine Kombination aus <Device>|<Anzahl Datensätze in DB> enthalten wie in der Abbildung (Anhang) ersichtlich.

Wenn das Ergebnis wie gewünscht vorliegen, wird nun die Benutzerschnittstelle aktiviert.

Code Auswählen Erweitern

attr Report userExitFn NaDevs .*:.*

"NaDevs" ist die Funktion in 99_myUtils.pm die aufgerufen werden soll. Die Angabe des Regex ".*:.*" ist optional. Nähere Informationen zur der Funktionsweise sind in der [https://fhem.de/commandref_DE.html#DbRep Commandref] zu finden.

Die "Positivliste" der in der Datenbank erlaubten Devices wird für das Beispiel in dem Attribut "comment" für den späteren Vergleich als String angegeben. Es ist natürlich auch z.B. eine Ableitung der im DEF-Regex des zugeordneten DbLog-Devices enthaltenen Device-Definitionen vorstellbar, sodass immer der aktuelle Stand dieser Definition als Grundlage für den Vergleich herangezogen wird.

Code Auswählen Erweitern

attr Report comment (sysmon|MyWetter|SMA_Energymeter|STP_5000|Cam.*)

Es sollen die Devices "sysmon", "MyWetter", "SMA_Energymeter", "STP_5000" und alle Cam-Devices in der DB enthalten sein.
Alle anderen gefundenen Devices sollen in der Negativliste verzeichnet werden.

Im weiteren Schritt wird die aufzurufende Funktion in der vorhandenen 99_myUtils.pm ergänzt.

Code Auswählen Erweitern



############################################################################
# $Id: myUtilsTemplate.pm 7570 2015-01-14 18:31:44Z rudolfkoenig $
#
# Save this file as 99_myUtils.pm, and create your own functions in the new
# file. They are then available in every Perl expression.

package main;

use strict;
use warnings;

sub
myUtils_Initialize($$)
{
  my ($hash) = @_;
}

# Enter you functions below _this_ line.

my @dna;

...

######################################################
########    Not allowed Devs in DB ermitteln
########          UserExitFn in DbRep           
######################################################
sub NaDevs {
my ($name,$reading,$value) = @_;
my $hash   = $defs{$name};

# DB Namen ermitteln
my $dbconn = $hash->{dbloghash}{dbconn};
my $db = (split("=",(split(";",$dbconn))[0]))[1];

# Liste der erlaubten Devices aus Attribut "comment" lesen
my $adevs = AttrVal($name, "comment","-");

if($reading eq "state" && $value eq "running") {
     # der Select wurde gestartet
     Log3 $name, 1, "UserExitFn called by $name - new Select has been startet. Allowed devices in database are: $adevs";
     @dna=();
     return;
}

my $d = (split("\\|",$value))[0];

# das Selektionsergebnis bewerten und ggf. dem Ergebnisarray hinzufügen
if ( $reading =~ m/SqlResultRow.*/ && $d !~ m/$adevs/) {
   push(@dna,$d."\n")
}

if ($reading eq "state" && $value eq "done") {
     # Ergebnis versenden bzw. loggen
     Log3 $name, 1, "UserExitFn called by $name - Devices not allowd found in $db: @dna";
     fhem("set teleBot message Devices are not allowed found in $db: \n @dna");
}

return;
}

....
1;

Die Schnittstelle übergibt der aufgerufenen Funktion den Namen des DbRep-Devices, den Namen des erstellten Readings und dessen Wert.
Der Aufruf erfolgt nach jeder Readingserstellung. Die Schnittstelle arbeitet OHNE Eventgenerierung bzw. benötigt keine Events.
Über den Namen des DbRep-Devices kann auf dessen Hash zugegriffen werden bzw. über $hash->{dbloghash}{...} ebenfalls auf den Hash des angeschlossenen DbLog-Devices.

In der Funktion "NaDevs" wird der Device-Teilstring des erzeugten Readings mit dem Wertevorrat aus dem "comment"-Attribut verglichen und bei einem negativen Ergebnis der Negativliste @dna hinzugefügt.
Nach Abschluss der Operation (signalisiert durch Reading "state = done" wird die erzeugte Liste im Logfile ausgegeben bzw. ein TelgramBot-Device versendet.

VG
Heiko

[DS_Starter]

Guten Abend,

es gibt eine neue Version 4.15.0 (in #1).
Es wurde einiges an der Performanceschraube gedreht. Es sollten oft spürbar schneller Ergebnisse vorliegen.
Als Wildcard wird nun nur noch "%" verwendet. "_" wird nicht mehr als Wildcard ausgewertet.

Weiterhin gibt es bei fetchrows ein Limit der Ergebnizeilen von 1000 um den Browser und damit FHEMWEB nicht zu blockieren.
Man kann über das Attribut "limit" diesen Wert für seine Umgebung anpassen.

Die Version checke ich nach einigen weiteren Tests auch ein.

Grüße
Heiko

[crispyduck]

Hallo,

Hätte da mal eine Frage ob und wie sich mein Vorhaben mit DbRep realisieren lässt.

Ich möchte berechnen und darstellen wann meine Wärmepumpe mit wie viel Strom WW bereitet oder geheizt hat.

Hätte mir das wie folgt vorgestellt:
Aktueller Stromverbrauch der WP wird  alle 60 sec. von einem Modbus Zähler abgefragt und in die DB geschrieben.
Betrriebsstatus der Heizung wird ebenfalls alle 60 sec. abgefragt und bei Änderung aufgezeichnet.

Daraus lässt sich dann ja berechnen wie viel Strom pro Tag für WW und wie viel für Heizen verbraucht wurden.
Ausserdem lässt sich berechnen von wann bis wann mit wie viel Strom z.B. WW bereitet wurde.

Hätte dann gerne pro Tag einen Wert für WW erzeugung als auch einen für Heizen
Und die jeweiligen WW oder Heiz Phasen mit Start, Stop Zeit und verbrauchtem Strom.
Betriebsstunden für WW und Heizen ausrechnen wäre auch noch interessant.

Lässt sich das mit DbRep realisieren und macht es auch sinn das mit DbRep zu machen?

Danke,
Crispyduck

[DS_Starter]

Hallo crispyduck,

ja so etwas lässt sich realisieren. Ob das sinnvoll ist, hängt nicht zuletzt von den Alternativen ab die man noch hätte.

Was du beschrieben hast wird out-of-the-box nicht möglich sein. Es wird nötig sein eigene Berechnungsroutinen in der 99_myUtils zu erstellen.
Wie man eine Auswertung mit Berechnung prinzipiell machen kann, habe ich im Wiki hier https://wiki.fhem.de/wiki/Datenbankgest%C3%BCtzte_Erstellung_der_Energiebilanz_einer_SMA_PV-Anlage_mit_%C3%9Cberschu%C3%9Feinspeisung beschrieben.

In dem Artikel geht es zwar um ein ganz anderes Thema (Datenbankgestützte Erstellung der Energiebilanz einer SMA PV-Anlage mit Überschußeinspeisung), aber um eine mögliche Vorgehensweise darzustellen ist es wahrscheinlich gut geeignet.

Jetzt zu deiner Aufgabenstellung, die ich versuche ohne alles genau durchdacht zu haben als  Ansatz eines Ablaufplanes zu beschreiben . Ich weiß natürlich nicht genau wie die Daten in der DB vorliegen und mutmaße auch etwas.

Aktueller Stromverbrauch der WP wird  alle 60 sec. von einem Modbus Zähler abgefragt und in die DB geschrieben.
Betrriebsstatus der Heizung wird ebenfalls alle 60 sec. abgefragt und bei Änderung aufgezeichnet.

Wenn ich das richtig interpretiere, ist die Datenaufzeichnung alle 60s eine Momentanaufnahme der abgenommenen Leistung (W). 
Die WP bedient ja sowohl die Heizung als auch die WW-Erzeugung wenn ich das richtig sehe. Die Leistung müßte getrennt für die WW-Erzeugung und Heizung in der DB vorliegen damit es so funktioniert wie ich es mir überlegt habe.

Um die verbrauchte Energie zu errechnen, braucht man  noch die Laufzeiten für jedes Aggregat über den Tag.

Die Laufzeiten pro Tag lässt sich ermitteln, indem man "fetchrows" in einem DbRep1 mit geeigneten Einstellungen für device und reading ausführt. Die timestamp_begin und timestamp_ende setzt man günstig auf current_day_begin und current_day_end.

Man bekommt Reading/Values-Datensätze des ganzen Tages, die etwa so aussehen (hier ein Beispiel eines Bew-Melders):

Code Auswählen Erweitern


2017-05-22_07-23-35__MelderGW1__state  motion    2017-05-22 18:10:44
2017-05-22_07-24-07__MelderGW1__state  noMotion  2017-05-22 18:10:44
2017-05-22_08-38-59__MelderGW1__state  motion    2017-05-22 18:10:44
2017-05-22_08-39-30__MelderGW1__state  noMotion  2017-05-22 18:10:44
2017-05-22_11-35-21__MelderGW1__state  motion    2017-05-22 18:10:44
2017-05-22_11-35-53__MelderGW1__state  noMotion  2017-05-22 18:10:44


Die Laufzeiten wäre also die Zeitspanne zwischen "motion" und "nomotion", bei dir entsprechend der Betriebsstatus der Heizung / WW-Bereitung.
Die Berechnung lagert man in eine eigene Routine in der myUtils aus und aktiviert die Schnittstelle dorthin mit dem Attribut "exitUserFn" im DbRep1-Device.
Dadurch wird jeder erzeugte Datensatz nacheinander der Routine übergeben. In der Routine müßte dann folgendes ausprogrammiert werden:

* wenn state (DbRep1) = running (kann über den übermittelten Hash ausgewertet werden ) -> Start Aufzeichnung der Perioden in einem Hash_Perioden
   -> Aufzeichung der selektierten Perioden (Readings/Werte wie oben im Beispiel)

* Aufzeichnung abschließen bei state(DbRep2) = done -> Selektionen sind abgeschlossen.

Nun den Hash_Perioden mit den Datensätzen nach folgendem Schema auswerten: 

Periode1:
* den Timestamp des Readings extrahieren und als Startpunkt merken (z.B. 2017-05-22_07-23-35__ ) wenn Heizung / WW an -> umwandeln in "2017-05-22 07:23:35"
* den Timestamp des Readings extrahieren und als Endepunkt merken (z.B. 2017-05-22_07-24-07__ ) wenn Heizung / WW aus -> umwandeln in "2017-05-22 07:24:07"
* die ermittelten Zeitgrenzen in Unixzeit wandeln, Differenz bilden (Laufzeit der Periode1) und merken.

   -> für diese Periode in einem DbRep2-Device programmtechnisch Attr timestamp_begin auf "2017-05-22 07:23:35" setzen und timestamp_end auf "2017-05-22
       07:24:07" -> mit set-Funktion "averageValue" den Durchschnittsverbrauch von WW bzw. Heizung für Periode1 ermitteln lassen. Im zweiten DbRep-Device wieder mit
       userExitFn wieder diese Routine aufrufen und das Ergebnis mit der Laufzeit der Periode1 mutliplizieren = Energieverbrauch von WW / Heizung in Periode1.

* den ermittelten Wert in einem Dummy zur Visualisierung setzen

Periode2:
* den Timestamp des Readings extrahieren und als Startpunkt merken (z.B. 2017-05-22_08-38-59__ ) wenn Heizung / WW an -> umwandeln in "2017-05-22 08:38:59"
* den Timestamp des Readings extrahieren und als Endepunkt merken (z.B. 2017-05-22_08-39-30__ ) wenn Heizung / WW aus -> umwandeln in "2017-05-22 08:39:30"
* die ermittelten Zeitgrenzen in Unixzeit wandeln, Differenz bilden (Laufzeit der Periode2) und merken.

   -> für diese Periode in einem DbRep2-Device programmtechnisch Attr timestamp_begin auf "2017-05-22 08:38:59" setzen und timestamp_end auf "2017-05-22
       08:39:30" -> mit set-Funktion "averageValue" den Durchschnittsverbrauch von WW bzw. Heizung für Periode1 ermitteln lassen. Im zweiten DbRep-Device wieder mit
       userExitFn wieder diese Routine aufrufen und das Ergebnis mit der Laufzeit der Periode2 mutliplizieren = Energieverbrauch von WW / Heizung in Periode2.

* den ermittelten Wert in einem Dummy zur Visualisierung setzen

Für weitere Perioden (Wertepaare im Hash_Perioden) genauso verfahren. Am Ende die Energiewerte der einzelnen Perioden addieren = Energieverbrauch des ganzen Tages bzw. die gemerkten Laufzeiten addieren = Betriebsstunden (Minuten) für jedes Gerät pro Tag. Diese Werte wieder in dem Dummy setzen.

Am Ende hast du:

* den Energieverbrauch für WW / Heizung pro Tag
* die Laufzeiten (WW- bzw. Heizungsphasen) mit den jeweiligen (gemerkten) Start- / Stopzeiten mit der verbrauchten Energie in diesem Zeitraum
* die Betriebstunden pro Tag über die Summierung der ermittelten Laufperioden

Ich habe diesen Plan mal eben schnell entwickelt um einen möglichen Weg aufzuzeigen. Er ist in der jetzigen Form wahrscheinlich auch nicht fehlerfrei und optimal aber könnte gut zum Ziel führen und alle deine Wünsche soweit abdecken. Du müßtest dich natürlich ein bisschen tiefer in die Programmierung einarbeiten für die userExit-Funktion in myUtils.

Ob das so ein Weg für dich wäre kannst du nur selbst beurteilen. In dem oben genannten Wikibeitrag kann man sich recht schön das Prinzip nochmal verdeutlichen.

viele Grüße
Heiko

[crispyduck]

Danke DS_Starter!!!

Das ist ja schon sehr ausführlich und gibt mir vorallem schon einen Ansatz.

Als alternative könnte ich mir momentan nur vorstellen das ich es bei jeder Änderung der Betriebsart eine Berechnung durch ein Notify trigger.

Die Idee dahinter ist eigentlich das ich beim erstellen der Readings theoretisch doch nichts berechnen müsste und die Berechnung des Tagesverbrauchs,... dann 1x in der Nacht machen könnte.

Der Wert des Zählers ist nicht die aktuelle Leistung, sondern der Verbrauchte Strom in kWh.

Lassen wir Heizen mal weg. (Ist jetzt ohnehin mal abgedreht  )

Habe "theoretisch" Readings wie folgt:
StromHeizung:                   Betriebsart Heizung:
2347,35                               0                                       2017-05-22 11:55:00
2347,35                               2                                       2017-05-22 12:35:00
2350,22                               0                                       2017-05-22 12:48:00
2360,01                               2                                       2017-05-22 15:33:00
2362,13                               0                                       2017-05-22 15:47:00
....

Ich könnte bei jeder Änderung der Betriebsart ein Get an Strom Heizung senden um zeitgleiche Readings zu haben.  (Ist der Timestamp dann aber überhaupt gleich?) Zusätzlich gibt es für StromHeizung alle 60 sec ein Reading.

0 = Heizung aus, 2 = WW bereitung (1 wäre dann Heizen)

Zwischen 2 und 0 wird somit immer WW bereitet.

Timestamps bekomme ich also so wie du es bereits mit dem Bewegungsmelder beschrieben hast.

Verbrauch pro WW Bereitung wäre dann der SromHeizung Wert vom Timestamp 2 weniger dem Strom Heizung Wert vom Timestamp bei BetriebsartHeizung wieder 0.

Da die Timestamps der Readings aber nicht gleich sein werden, wie lässt sich das dann berechnen?

Oder lassen sich sonst eie zwei Readings miteinander verknüpfen?

Lg
Crispyduck

[viegener]

@crispyduck: Wenn Du das ganze in kleinere Teile zerteilen willst, wäre es möglich über userReadings z.B. den Stromverbrauch für die letzte Phase :WW,HZ,NA als userReading ablegen. Dieser findet sich dann auch in der Datenbank und kann es erleichtern Dauer und Stromverbräuche für eine Periode auszurechnen.

Ein Ansatz wäre jeweils ein userreading zu haben, dass den Stromverbrauch und die Dauer der letzten Phase (also bei Wechsel der Betriebsart ) zu speichern. Diese Readings können ja auch noch die Betriebsart mit beinhalten also z.B.

Code Auswählen Erweitern


lastUsage WW 2.87 kw
lastDuration WW 13 min
...


Als Hilfe braucht man dann noch jeweils ein Reading um die letzte Betriebsart und den letzten Stand des Zählers beim Wechsel zu merken.

[crispyduck]

Hallo viegener,

Beim fertig schreiben meines letzten Posts kam mir ein ähnlicher Gedanke; könnte ein Dummy device "Warmwasser" machen welches die Readings "Zählerstand_WW_bereitung_start" und "Zählerstand_WW_bereitung_ende" hat.

Start und Endzeit ist dann der Timestamp des Readings und der Zählerstand das value.

Würde es auf jeden Fall vereinfachen.

Die Variante von DS_Starter habe ich jetzt erst ganz verstanden. Müsste eben statt "averageValue", "diffValue" verwenden und erspare mir das Multiplizieren.
In der Berechnung müsste man dann wohl auch noch Mitternacht als eventuelles Start oder Stop berücksichtigen.
Um den ganzen Tag zu erfassen lässt man es wohl besser irgendwann in der Nacht am Folgetag laufen und nimmt previous_day_begin und previous_day_end.

Könnte man dies dann eigentlich auch statt scheduled zu berechnen und in der DB zu speichern einfach ausführen wenn man es benötigt? Also mit timestamp_begin/end eines Tages von welchem man die genauen Werte wissen will?
Nachdem ich die Summe pro Tag aber ohnehin berechnen und für einen plot speichern will, muss ich es wohl ohnehin 1x pro Tag laufen lassen, um an den gesamt Verbrauch+Laufzeit pro tag zu kommen, da loggt man wohl die par werte am besten gleich mit?!

Danke,
Crispyduck

[DS_Starter]

Noch zur Ergänzung von viegeners Hinweisen ....

Der Wert des Zählers ist nicht die aktuelle Leistung, sondern der Verbrauchte Strom in kWh.

Das macht es einfacher ...

Müsste eben statt "averageValue", "diffValue" verwenden und erspare mir das Multiplizieren.

Richtig.

in der Berechnung müsste man dann wohl auch noch Mitternacht als eventuelles Start oder Stop berücksichtigen.

In DbLog gibt es eine addlog-Funktion. Mit einem At kannst du dir damit immer z.B. um 00:00:00 und 23:59:59 einen definierten Messpunkt setzen.

Könnte man dies dann eigentlich auch statt scheduled zu berechnen und in der DB zu speichern einfach ausführen wenn man es benötigt? Also mit timestamp_begin/end eines Tages von welchem man die genauen Werte wissen will?

Es geht natürliches alles Mögliche. Wichtig nur dass du die Rohwerte für jedwede Auswertung in der DB vorhältst. Dann kannst du später nach Herzenslust verschiedene Perioden auswerten, darstellen etc. In meinem weiter oben angegeben Beispiel will ich die Energiebilanz noch um einen Jahreswert ergänzen ... geht ja problemlos da die zugrunde liegenden Daten in der DB vorhanden sind.  Das ist in meinen Augen der primäre Vorteil einer DB und deswegen auch DbRep entstanden.

Probiere einfach mal verschiedene Varianten aus die viegener und ich dir als Anregung gegeben haben, dann wird bestimmt vieles klarer und du kannst dich an dein Ziel rantasten.

Grüße
Heiko

[crispyduck]

Danke, für all die Infos und Anregungen.

So wie du sagst, sind die Vorteile einer DB ja vorallem das man die werte gut auswerten kann.

Deine Energiebilanz gefällt mir sehr und ich hoffe das ich ähnliches mal für meine zukünftige Anlage hin bekomme.
(Gerade am eigenbau einer kleinen PV Überdachung mit StecaGrid WR)

Lg
Crispyduck

[DS_Starter]

@ All,

ich habe etwas weiter gebaut und das Attribut sqlResultFormat noch um "json" erweitert (Version 4.16.1 im ersten Beitrag).
D.h., das Ergebnis der sqlCmd-Funktion wird als JSON-kodierter Hash im Reading SqlResult ausgegeben und auch an die userExitFn übergeben.
Die Weiterverarbeitung kann dann in 99_myUtils etwa so erfolgen:

Code Auswählen Erweitern


######################################################
########   Zugriff auf  Wert aus JSON formatiertes
########   SqlResult
########   (sqlResultFormat = json)   
######################################################
sub resfromjson {
my ($name,$reading,$value) = @_;
my $hash   = $defs{$name};

if ($reading eq "SqlResult") {
     # nur Reading SqlResult ist JSON formatiert
     my $data = decode_json($value);

     foreach my $k (keys(%$data)) {
             
       # ab hier eigene Verarbeitung für jedes Element
       # z.B. Ausgabe jedes Element welches "Cam" enthält
       my $ke = $data->{$k};
       if($ke =~ m/Cam/i) {
           my ($res1,$res2) = split("\\|", $ke);
           Log3($name, 1, "$name - extract element $k by userExitFn: ".$res1." ".$res2);
       }
    }
}

return;
}


WICHTIG ! : Es wird fhem.pl Version mindestens 14348 2017-05-22 20:25:06Z (also von gestern Abend) benötigt !

Jedes Hash-Element (Ergebnissatz von $value) setzt sich aus der laufenden Nummer des Datensatzes (=Key) und dessen Wert (Selektionsergebnis) zusammen.
Feedback und Testergebnisse wie immer gerne.

viele Grüße
Heiko

[DS_Starter]

Hallo miteinander,

ich habe in DbRep eine Backup/Dump-Funktion für MySQL implementiert. Version 5.0.1 im ersten Beitrag.

Hier die Funktionsbeschreibung:

Set-Kommandos
dumpMySQL  -  erstellt einen Dump der gesamten angeschlossenen MySQL-Datenbank.
                       Der Dump wird per default im log-Verzeichnis gespeichert. Das Zielverzeichnis kann mit dem
                       Attribut "dumpDir" verändert werden. Vor dem Dump kann eine Tabellenoptimierung  optional zugeschaltet werden.
                       Über weitere Attribute das Laufzeitverhalten der Funktion beeinflusst  werden um eine Optimierung bezüglich Performance und           
                       Ressourcenbedarf zu erreichen.               
                       Die für dumpMySQL relevanten Attribute sind "dumpComment", "dumpDir", "dumpMemlimit", "dumpSpeed ",
                       "dumpFilesKeep" und "optimizeTablesBeforeDump".
                       Das erzeugte Dumpfile <dbname>_<date>_<time>.sql" kann z.B. mit:
                        
                       

Code Auswählen Erweitern

mysql -u &lt;user&gt; -p &lt;dbname&gt; < &lt;filename&gt;.sql
                        
                       auf dem MySQL-Server ausgeführt werden um die Datenbank aus dem Dump wiederherzustellen.

cancelDump  -  bricht einen laufenden Dump ab.


Attribute:
dumpComment        - User-Kommentar. Wird im Kopf des erzeugten Dumpfile eingetragen. 
 
dumpDir                 - Zielverzeichnis für dumpMySQL-File (default: "{global}{modpath}/log/").
 
dumpMemlimit        - erlaubter Speicherverbrauch für SQL-Script zur Generierungszeit (default: 100000 Zeichen).
 
dumpSpeed            - Anzahl der in einem Call abgerufenen Selects aus der Quelldatenbank (default: 10000).
                                Dieser Parameter hat direkten Einfluß auf die Laufzeit und den Ressourcenverbrauch zur Laufzeit.

dumpFilesKeep       - Es wird die angegeben Anzahl Dumpfiles im Dumpdir gelassen (default: 3). Sind mehr (ältere) Dumpfiles
                                 vorhanden, werden diese gelöscht nachdem ein neuer Dump erfolgreich erstellt wurde. Das globale
                                 Attribut "archivesort" wird berücksichtigt.

optimizeTablesBeforeDump  - wenn "1", wird vor dem Datenbankdump ein "optimize table" ausgeführt (default: 0). 
                                          Dadurch verlängert sich die Laufzeit des Dump. <br><br>
                                         
                                          Hinweis:
                                          Die Tabellenoptimierung führt zur Sperrung der Tabellen und damit zur Blockierung von
                                          FHEM falls DbLog nicht im asynchronen Modus (DbLog-Attribut "asyncMode") betrieben wird !

Viel Spaß beim Testen und gern wieder Feedback.

Grüße
Heiko

[JoeALLb]

Hallo Heiko,

danke für das neue Modul, bin am Testen auf einem kleinen RPI 1 mit einer großen Datenbank.
Das Timeout musste ich stark erhöhen, dumpspeed habe ich im Moment auf 1000.

Ich werde berichten....