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

[DS_Starter]

Das steht schon bzw. Noch auf meiner ToDo. Mache grad erwas Urlaub. Aber im Herbst und Winter hab ich wieder mehr Zeit für FHEM.

LG

[RalfRog]

Ich schau regelmäßig nach und bin echt gespannt.... 

Ich wäre halt mal interessiert ob Andere dies auch beobachten.
Ich muss aber tatsächlich zugeben, dass bei automatisierter Reduzierung und größeren Datenbestände es nicht mehr auffällt  - es sein denn man schaut sich zufälling die Daten des entsprechenden Tages an.

Gruß Ralf

[frober]

Ich habe mal die Tage angefangen Min- und Maxwert der Temperatur vom Vortag abzufragen.
Nun bin ich überrascht, dass die Werte nicht einfach durchgereicht werden:

aus

Code: [Auswählen]

setstate KS300 2021-10-05 18:12:16 temperature 14.8
wird

Code: [Auswählen]

setstate KS300 2021-10-05 00:10:00 MAXTemp 15.3000
setstate KS300 2021-10-05 00:10:01 MINTemp 11.7000
wo kommen die Stellen hinter dem Komma her?

Muss/kann ich hier noch etwas konfigurieren?

Code: [Auswählen]

defmod MinMaxTemp DbRep logdb
attr MinMaxTemp allowDeletion 1
attr MinMaxTemp autoForward {\
  ".*MAX.*" => "KS300 => MAXTemp",  \
  ".*MIN.*" => "KS300 => MINTemp",\
}
attr MinMaxTemp device KS300
attr MinMaxTemp fastStart 1
attr MinMaxTemp limit 300
attr MinMaxTemp reading temperature
attr MinMaxTemp room System->DbLog
attr MinMaxTemp showproctime 1
attr MinMaxTemp timestamp_begin previous_day_begin
attr MinMaxTemp timestamp_end previous_day_end
attr MinMaxTemp verbose 1
Danke und Grüße
Bernd

[DS_Starter]

Hallo Bernd,

numerische Ergebnisse werden in DbRep aktuell immer auf 4 Stellen nach dem Komme genau ausgegeben bzw. in deinem Fall mit dieser Genauigkeit übertragen.
Stört es dich oder war es nur eine Frage weil es dir aufgefallen ist ?

Grüße,
Heiko

[frober]

Hallo Heiko,

aktuell stört es mich nicht.
Es hat mich eher verwirrt, da ja kein neuer Wert berechnet wird.

Änderst du das irgendwann? Wenn man die Daten weiterverarbeitet, ist es evtl. unschön.

Grüße Bernd

[DS_Starter]

Ich hatte eine Änderung jetzt nicht direkt auf dem Schirm, aber nach meinem Urlaub will ich mir die Erweiterung bezüglich Platzhalter/Ersetzungen von §device§, §reading§ (im Thread bisschen weiter oben) nochmal vornehmen. In dem Zusammenhang könnte ich auch ein Attribut für die Anpassung der Nachkommagenauigkeit einführen.

Die Version würde ich zum Testen erstmal im contrib bereitstellen sobald ich dazu gekommen bin.

[frober]

Das Attribut würde ich begrüßen, aber wie gesagt, ich habe keine Eile.

Danke schon einmal für deinen Support.

[oldscout]

Hallo,
darf ich mich hier mit dranhängen:
Problem mit dem Dbrep-Modul:
Einfache CountEntries-Abfrage mit device: TYPE=AMADDEVICE ergibt hier die komplette Anzahl der Datensätze der DB, obwohl mein SQL-Manager nur ca. 10% davon zählt, dieses Problem gibt es auch bei anderen TYPEs. Es sind Abweichung von manchmal mehr als das Doppelte.
Stellt sich jetzt die Frage, wenn man Datensätze löschen will nach TYPE. Werden dann vielleicht alle gelöscht? Das wäre fatal.

Vielleicht könntest Du Dir das mal anschauen.
Danke schön.

 

[DS_Starter]

Moin,

ich weiß jetzt nicht wie du mit SQL-Manager diese Abfrage mit TYPE=AMADDEVICE aufbaust.
Aber DbRep löst zunächst die relevanten Devices aus TYPE über FHEM auf und erstellt daraus eine Liste der Device-Selekts in der DB.
Du siehst das resultierende Statement wenn du verbose 4 im Device einstellst und den Befehl ausführst:

2021.10.31 09:43:56.874 4: DbRep Rep.SSCam - -------- New selection ---------
2021.10.31 09:43:56.874 4: DbRep Rep.SSCam - Command: countEntries history
2021.10.31 09:43:56.875 4: DbRep Rep.SSCam - timeDiffToNow - year: , day: 10, hour: , min: , sec:
2021.10.31 09:43:56.875 4: DbRep Rep.SSCam - startMonth: 9 endMonth: 9 lastleapyear:  baseYear: 2021 diffdaylight:1 isdaylight:0
2021.10.31 09:43:56.876 4: DbRep Rep.SSCam - FullDay option: 0
2021.10.31 09:43:56.876 4: DbRep Rep.SSCam - Time difference to current time for calculating Timestamp begin: 867601 sec
2021.10.31 09:43:56.877 4: DbRep Rep.SSCam - Timestamp begin human readable: 2021-10-21 09:43:55
2021.10.31 09:43:56.877 4: DbRep Rep.SSCam - Timestamp end human readable: 2021-10-31 09:43:56
2021.10.31 09:43:56.878 4: DbRep Rep.SSCam - Aggregation: no
2021.10.31 09:43:56.952 4: DbRep Rep.SSCam - SQL execute: SELECT COUNT(*) FROM history where ( DEVICE = 'SMA_Energymeter' ) AND TIMESTAMP >= '2021-10-21 09:43:55' AND TIMESTAMP <= '2021-10-31 09:43:56' ;

In dem Beispiel ist TYPE=SMAEM eingestellt und es wird daraus das device SMA_Energymeter ermittelt was im SQL verwendet wird.
Deswegen schaue erstmal wie das SQL bei dir aussieht.

[oldscout]

Hallo DS_Starter,
hier bitte das Log:

Code: [Auswählen]

2021.11.02 17:48:24 4: DbRep dbdel_Handy - -------- New selection ---------
2021.11.02 17:48:24 4: DbRep dbdel_Handy - Command: countEntries history
2021.11.02 17:48:24 4: DbRep dbdel_Handy - Timestamp begin human readable: not set
2021.11.02 17:48:24 4: DbRep dbdel_Handy - Timestamp end human readable: not set
2021.11.02 17:48:24 4: DbRep dbdel_Handy - Aggregation: no
2021.11.02 17:48:25 4: DbRep dbdel_Handy - SQL execute: SELECT COUNT(*) FROM history where 1 ;
hier bitte der Screenshot im Anhang,

und hier bitte auch die SQL-Abfrage, aber im Log sieht man ja schon den Fehler:

SELECT * FROM fhem.history where type like "%AMADDEVICE%";

Danke für die Mühen.

Nachtrag:

Ich sehe gerade, das per Definition der Type so geschrieben wird: AMADDevice, jetzt funktioniert es, das habe ich übersehen. In der DB steht es in Großbuchstaben drin, da habe ich nicht aufgepasst und die Abfrage so gebaut.
Aber warum ist dann die select-Abfrage so ... where = 1 ? Weil das Device nicht gefunden wird? so muss es natürlich alle Datensätze anzeigen.
Könnte man das noch abfangen?

Naja.... ich habe die falsche Brille aufgehabt :=)) ....

[DS_Starter]

Hallo oldscout,

Aber warum ist dann die select-Abfrage so ... where = 1 ? Weil das Device nicht gefunden wird? so muss es natürlich alle Datensätze anzeigen.
Könnte man das noch abfangen?

Weil das ein Fehler ist und der Logik geschuldet ist was FHEM zurückgibt wenn es den in TYPE= angegebenen devspec nicht gibt.
Ich konnte es bei mir nachstellen und das muß ich natürlich beheben.
Werde einen fix einbauen und hier Bescheid geben.

Grüße,
Heiko

[DS_Starter]

Habe das Problem gefixt und wird morgen früh mit dem update verteilt.

LG

[oldscout]

Sehr schön, danke. Funktioniert.

[DS_Starter]

Hallo Bernd, @all,

ich habe deinen Request umgesetzt und ein neues Attr zur Einstellung der Nachkommastellen eingebaut:

numDecimalPlaces- Legt die Anzahl der Nachkommastellen bei Readings mit numerischen Ergebnissen fest.
Ausgenommen sind Ergebnisse aus userspezifischen Abfragen (sqlCmd).
(default: 4)

Ist morgen früh im Update enthalten.

Grüße,
Heiko

[frober]

Hallo Bernd, @all,

ich habe deinen Request umgesetzt und ein neues Attr zur Einstellung der Nachkommastellen eingebaut:

numDecimalPlaces- Legt die Anzahl der Nachkommastellen bei Readings mit numerischen Ergebnissen fest.
Ausgenommen sind Ergebnisse aus userspezifischen Abfragen (sqlCmd).
(default: 4)

Hallo Heiko,

super, danke dir.
Funktioniert wie erwartet und sieht im Reading wesentlich besser aus.

Grüße Bernd