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

flummy1978 · 20 März 2020, 00:23:12

WOW

Ich bin wirklich beeindruckt. Mal abgesehen davon, dass ich (ein wenig) weiß wie umfangreich manche Sachen zu programmieren sind, finde ich die Geschwindigkeit mit der Du etwas umsetzt schon genial. *Daumenhoch* Noch dazu, weil es auch entsprechend zu funktionieren scheint ...

Ich kann natürlich nicht alles testen, aber das was ich bisher getestet hab ... läuft und zwar so wie es für mich perfekt ist. Ich habe die Option einzelne Devices anzulegen ( dazu eine Frage unten ) und ich habe auch die Möglichkeit mit den Optionen Speziell bei ReduceLog mich an die Grenzen heran zu tasten, wenn die Datenbank mal zu groß werden sollte (Was ich zu vermeiden hoffe ).

Nun eine Funktionsfrage, ob ich das richtig verstanden habe:

In beiden Fällen habe ich das Attribut timeDiffToNow auf 3600und 86400 geändert, ansonsten nur noch das Reading attribut drin.....

Code Auswählen

2020-03-19 23:42:41 Global global ATTR SQL_Rep timeDiffToNow 3600
2020-03-19 23:42:42 HP1000 Wetterstation wind_speed: 0.4
2020-03-19 23:42:44 DbRep SQL_Rep running
2020-03-19 23:42:44 DbRep SQL_Rep 2020-03-19__/__wemoszaehler_OG_current_5min__AVGAM__no_aggregation: 9.8150
2020-03-19 23:42:44 DbRep SQL_Rep done

2020-03-19 23:43:02 Global global ATTR SQL_Rep timeDiffToNow 86400
2020-03-19 23:43:09 DbRep SQL_Rep running
2020-03-19 23:43:09 DbRep SQL_Rep 2020-03-19__/__wemoszaehler_OG_current_5min__AVGAM__no_aggregation: 4.7490

List (zur Sicherheit)

Code Auswählen

Internals:
   DATABASE   testsystem_fhem
   DEF        SQL_Log
   FUUID      5e6bf086-f33f-8d79-ce6c-1037df4f23ecb31c
   FVERSION   93_DbRep.pm:v8.32.4-s21429/2020-03-15
   LASTCMD    averageValue display
   MODEL      Client
   NAME       SQL_Rep
   NOTIFYDEV  global,SQL_Rep
   NR         40
   NTFY_ORDER 50-SQL_Rep
   ROLE       Client
   STATE      done
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE SQL_Log
     GRANTS     TRIGGER,REPLICATION SLAVE,EXECUTE,CREATE,DROP,CREATE TEMPORARY TABLES,EVENT,PROCESS,DELETE,REFERENCES,INDEX,RELOAD,INSERT,REPLICATION CLIENT,SHOW VIEW,CREATE VIEW,LOCK TABLES,ALTER ROUTINE,FILE,SELECT,CREATE ROUTINE,ALTER,UPDATE
     IDRETRIES  3
     MINTS      2020-01-26 00:00:00
     PACKAGE    main
     SQLHIST    
     VERSION    8.32.4
     CV:
       aggregation no
       aggsec     1
       destr      2020-03-19
       dsstr      2020-03-19
       epoch_seconds_end 1584658549
       mestr      03
       msstr      03
       testr      23:55:49
       tsstr      01:09:09
       wdadd      345600
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
     REDUCELOG:
       SQL_Rep
       reduceLog
       52:53
       average
       INCLUDE=Nebenzaehler:wemoszaehler_EG_current_5min
   OLDREADINGS:
   READINGS:
     2020-03-19 23:55:49   2020-03-19__/__wemoszaehler_OG_current_5min__AVGAM__no_aggregation 4.7837
     2020-03-19 23:55:49   state           done
Attributes:
   allowDeletion 1
   reading    wemoszaehler_OG_current_5min
   room       DB Log_Rep,
   timeDiffToNow 86400
   verbose    3

Verstehe ich die Doku und entsprechende Einstellungen richtig, dass in meinem Fall der Durchschnitt für den Zeitraum aktuelleZeit-3600(bzw 86400)sek -> BIS aktuelleZeit berechnet wird ?

Ich frage aus dem Grund, weil ich Daten mit großen Mengen gerne von vorne herein korrekt machen würde und ich gerade wie erwähnt auf meinem Testsystem Stromzähler und ein eigenes Wetter Device (Modul) teste. In beiden Fällen gibt es eine richtige Datenflut, die ich (idealerweise) quasi on the fly im zaun halten möchte, als sie hinterher zu korrigieren.

Beide Devices ansich sind schon mit Event-Beschränkungen eingesetzt (even-aggregator event-on-change usw) Beim Stromzähler übernimmt der event-aggregator einen 5 und 30 Minuten Schnitt, der allerdings natürlich dennoch für viele Events sorgt und nicht alle 5 Minuten den Aktuellen 5 Min Schnitt bringt. Jetzt ist mir mit dem (halb)Wissen durch das Lesen hier und die Erkenntnis, dass eine DB sich besser zum Rechnen eignet als eine Heimautomatisierungssoftware auf einem RaspberryPi, die Idee gekommen sämtliche Mittelwert Berechnung von der Datenbank(Synology Diskstation) und nicht vom Raspberry(Fhem) übernehmen zu lassen.

OFF TOPIC:

Meine Idee wäre dann 1-7 Tage mit ungefilterten Werten arbeiten (anzeigen)
Der 5 und 30 Minuten Schnitt wird "live" von der DB erzeugt
Livedaten werden alle 7-x Tage mit Reduce Log dann auf Stunden Schnitt verringert und die 5-30 Minuten Schnittwerte sind ja immernoch vorhanden

Was halten die Datenbankexperten von der Idee ? Macht es Sinn ? Oder mache ich mir zu viel Gedanken um Performance / Speicher, bei solch einer "kleinen" Aufgabe ? (auch im Hinblick auf die Zukunft... Denn je besser die Sachen in FHEM funktionieren, kommt auch immer mehr dazu - Wobei ich mit ca 50 Geräten und 150 Devices sicherlich nicht am Anfang der Automatisierung hänge ... )

Würde mich aber sehr freuen, wenn jemand zum OffTopic auch Stellung nehmen könnte.Falls es mehr Sinn macht dafür einen neuen Beitag zu erstellen, mache ich das

Vielen Dank für Deine Arbeit Heiko und auch die Ideen / Vorschläge der anderen mit "Bastler"

und auch wenn ich den Spruch selbst nicht mehr so oft hören mag - er aber umso wichtiger ist:
Viele Grüße und bleibt gesund
Andreas

ch.eick · 20 März 2020, 07:53:58

Zitat von: DS_Starter am 19 März 2020, 21:54:19
* der Spezial SQL von Christian ist eingebaut. Aufruf mit

set <name> sqlSpecial recentReadingsOfDevice

Wow, damit hatte ich jetzt nicht gerechnet, ich hatte gerade mal eine Stunde ueber etwas nachgedacht und schon scheint es zu einer interessanten Abfrage geworden zu sein.
Der Test war erfolgreich...

Vielen Dank fuer die Amerkennung
Christian

DS_Starter · 20 März 2020, 09:37:57

Moin zusammen,

@Andreas ... freut mich dass deine Test auch erfolgreich waren und wow ... herzlichen Dank! War überrascht und freue mich natürlich sehr über die Anerkennung !

ZitatVerstehe ich die Doku und entsprechende Einstellungen richtig, dass in meinem Fall der Durchschnitt für den Zeitraum aktuelleZeit-3600(bzw 86400)sek -> BIS aktuelleZeit berechnet wird ?

Ja, ist richtig.
Allgemein gilt ... wenn ihr euch unsicher seid ob die Attribut-Einstellungen im Device richtig sind und richtig umgesetzt werden, dann stellt verbose 4
ein und führt z.B. countEntries aus. Im Log seht ihr dann das ausgeführte SQL Statement. Ihr könnt dort ablesen ob die Zeitgrenzen richtig eingesetzt werden,
die richtigen Devices und Readings includiert/excludiert werden usw.
Sollte etwas noch nicht so eingestellt sein wie gewünscht, könnt ihr es leicht korrigieren. Ein countEntries tut nicht weh.

ZitatOFF TOPIC:

Meine Idee wäre dann 1-7 Tage mit ungefilterten Werten arbeiten (anzeigen)
Der 5 und 30 Minuten Schnitt wird "live" von der DB erzeugt
Livedaten werden alle 7-x Tage mit Reduce Log dann auf Stunden Schnitt verringert und die 5-30 Minuten Schnittwerte sind ja immernoch vorhanden

Finde ich einen interessanten Ansatz und ich persönlich würde es so machen.
Hat aber auch ein bisschen damit zu tun, dass ich ein wenig Datenbank affin bin und gerne die Rohdaten in der originären Form vorliegen habe sie dann nach
Lust und Laune(Notwendigleit) auswerten zu können. Ich finde allein schon die Beschäftigung damit interssant und lehrreich und man wird dadurch auch nicht dümmer.
Sollten die Daten doch mal zu viel werden ... naja, ein beherztes deleteEntries macht dem Spuk ein Ende

. Mit einer DB kann man seine Daten ja sehr gut
verwalten.
So wie ich hast du deine DB auch auf der Synology laufen. Ich habe ja einige davon am Start, bedingt durch die DbLog/DbRep-Entwicklung. Die sind jetzt teilweise
bis 8 GB groß (Daten zum Testen) und das FHEM-System lässt das kalt.

Nicht so DB affine User sehen das vielleicht anders, machen einen Bogen um die DB-Nutzung und nutzen lieber FHEM-Mittel.
Wie immer wird es verschiedene Vorlieben und Meinungen geben.

@Christian , prima ... danke für den tollen Input.

ZitatWow, damit hatte ich jetzt nicht gerechnet, ich hatte gerade mal eine Stunde ueber etwas nachgedacht und schon scheint es zu einer interessanten Abfrage geworden zu sein.

Abgesehen davon, dass ich diese Abfrage nützlich/hilfreich finde, ist es vllt. ein Anregung für andere User. Wie oben schon angedeutet, kann man sich mit verbose 4
das SQL anschauen was DbRep generiert und daraus Ideen für eigene Auswertungen ziehen.
Unter diesem Aspekt sehe ich die Rubrik "sqlSpecial" auch als "Fundgrube" und baue da gerne noch etwas ein was für andere User interessant sein könnte.
Erweiterungen sind recht leicht möglich, weil das Rahmenwerk ja vorhanden ist. Blöd ist immer, dass die Syntax zw. MySQL, SQLite, PostgreSQL teilweise nicht
identisch ist. Gerade bei solchen specials ...

Ich finalisiere den Stand noch und checke die Version im laufe des Tages ein wenn nichts mehr auffallen sollte.
Danach schaue ich mir noch die Sache mit der Funktion an, die einen Wert direkt in ein anderes Reading schreibt. Das dauert dann ein bisschen

LG,
Heiko

flummy1978 · 20 März 2020, 15:16:13

Tach,

Zitat von: DS_Starter am 20 März 2020, 09:37:57
@Andreas ... freut mich dass deine Test auch erfolgreich waren und wow ... herzlichen Dank! War überrascht und freue mich natürlich sehr über die Anerkennung !

Halte das eigentlich immer so: Wenn ich merke dass jemand nicht nur insg. viel Zeit in die Entwicklung eines Moduls / Erweiterung was auch immer, gesteckt hat und auch weiterhin versucht es für alle so zu machen, dass möglichst vieles vereinfacht wird, haben sie es sich auch mehr als verdient, dass man eben auch mal Anerkennung zeigt. Mal davon ab, wenn es JEDER machen würde der die Module eines Devs häufiger nutzt, würden die Devs sich freuen, weil ihre Arbeit (auch wenn es Hobbyarbeit ist) honorriert wird und User würden von der steigernden Motivation der Devs profitieren, weil sie einfach mehr Mittel und Möglichkeiten haben etwas zu entwickeln / programmieren. Ich für meinen Teil freue mich, dass es Leute wie Dich und andere Devs gibt, mit deren Hilfe ich eben viele besser / schneller / einfacher oder auch nur schöner erledigen kann.

OnTopic:
Ich denke mal das wird eine schön komplizierte Nummer, bis ich mich da mal wieder hinein gelesen hab (meine ersten SQL Gehversuche sind ca 15-18 Jahre her -.- ) Aber ich glaube auch, dass es mehr Sinn macht, komplexere Berechnungen von einer Datenbank übernehmen zu lassen und dafür eben die Rohdaten zur Verfügung zu haben.

Verbose 4 ist n guter Tipp, werde ich auf jeden Fall bei der nächsten Bastelei mal testen und sehen an was ich mich alles erinnern kann, was die SQL Befehle angeht

Viele Grüße
Andreas

DS_Starter · 20 März 2020, 15:29:48

Hallo miteinander,

die Version 8.36.0 ist eingecheckt und morgen früh im Regelupdate.

@Andreas ... wenn du Unterstützung bei SQL's brauchst, bist du hier https://forum.fhem.de/index.php/topic,65860.0.html wahrscheinlich ganz gut aufgehoben denke ich.
Habe mir inzwischen auch ein SQL-Buch zugelegt, SQL ist sehr mächtig wenn man es gut/richtig anzuwenden vermag.

LG,
Heiko

ch.eick · 20 März 2020, 16:07:30

Hallo Heiko,

hast so etwas schon?

Das rechnet die Differenz zwischen aufeinanderfolgenden Werten eines Readings aus inklusive der Zeitdifferenz in Minuten

Ich wollte mal sehen wie der Temperaturverlust meines Pufferspeichers ist, also wieviel Kelvin pro Zeit. Das ist noch nicht ganz fertig, da ich lieber noch die
Abkuehl- und Aufheizphasen als komplette Zeitspanne sehen moechte. Hier sind es teilweise nur 5 Minuten und manchmal halbe oder ganze Stunden,
was natuerlich Zeiten sind in denen Wasser gezapft wurde.
Ich meine zu erkennen, das es ca, 0,1 Kelvin in 15 Minuten sind, wobei fuer solch kurze Zeiten einfach die Temperaturmessung zu ungenau ist.

Device und Reading waeren noch als Variable zu verwenden.

Code Auswählen


MySQL [fhem]> SET @diff=0;
Query OK, 0 rows affected (0.001 sec)

MySQL [fhem]> SET @delta=NULL;
Query OK, 0 rows affected (0.001 sec)

MySQL [fhem]> SELECT t1.TIMESTAMP,t1.READING,t1.VALUE,t1.DIFF,t1.DELTA
    ->   FROM
    ->     (
    -> SELECT TIMESTAMP,READING,VALUE,
    ->        cast((VALUE-@diff) AS DECIMAL(3,1))    AS DIFF,
    ->        @diff:=VALUE                           AS curr_V,
    ->        TIMESTAMPDIFF(MINUTE,@delta,TIMESTAMP) AS DELTA,
    ->        @delta:=TIMESTAMP                      AS curr_T
    ->   FROM  history
    ->   WHERE DEVICE = 'Heizung'              AND
    ->         READING = 'hotWaterTemperature' AND
    ->         TIMESTAMP >= NOW() - INTERVAL 1 DAY
    ->   ORDER BY TIMESTAMP
    ->     ) t1;
+---------------------+---------------------+-------+------+-------+
| TIMESTAMP           | READING             | VALUE | DIFF | DELTA |
+---------------------+---------------------+-------+------+-------+
| 2020-03-19 15:11:15 | hotWaterTemperature | 60.7  | 60.7 |  NULL |
| 2020-03-19 15:16:15 | hotWaterTemperature | 60.9  |  0.2 |     5 |
| 2020-03-19 15:21:15 | hotWaterTemperature | 60.7  | -0.2 |     5 |
| 2020-03-19 16:16:15 | hotWaterTemperature | 60.6  | -0.1 |    55 |
| 2020-03-19 16:21:15 | hotWaterTemperature | 60.7  |  0.1 |     5 |
| 2020-03-19 16:26:15 | hotWaterTemperature | 60.6  | -0.1 |     5 |
| 2020-03-19 17:21:15 | hotWaterTemperature | 60.4  | -0.2 |    55 |
| 2020-03-19 18:11:15 | hotWaterTemperature | 60.0  | -0.4 |    50 |
| 2020-03-19 18:35:20 | hotWaterTemperature | 59.9  | -0.1 |    24 |
| 2020-03-19 18:41:15 | hotWaterTemperature | 59.7  | -0.2 |     5 |
| 2020-03-19 18:46:15 | hotWaterTemperature | 59.5  | -0.2 |     5 |
| 2020-03-19 19:01:15 | hotWaterTemperature | 59.4  | -0.1 |    15 |
| 2020-03-19 19:31:15 | hotWaterTemperature | 59.2  | -0.2 |    30 |
| 2020-03-19 19:56:21 | hotWaterTemperature | 59.0  | -0.2 |    25 |
| 2020-03-19 20:16:21 | hotWaterTemperature | 58.9  | -0.1 |    20 |
| 2020-03-19 20:21:21 | hotWaterTemperature | 59.0  |  0.1 |     5 |
| 2020-03-19 20:26:21 | hotWaterTemperature | 58.9  | -0.1 |     5 |
| 2020-03-19 20:46:24 | hotWaterTemperature | 58.7  | -0.2 |    20 |
| 2020-03-19 21:11:24 | hotWaterTemperature | 58.5  | -0.2 |    25 |
| 2020-03-19 21:16:24 | hotWaterTemperature | 58.7  |  0.2 |     5 |
| 2020-03-19 21:21:24 | hotWaterTemperature | 58.5  | -0.2 |     5 |
| 2020-03-19 21:41:24 | hotWaterTemperature | 58.4  | -0.1 |    20 |
| 2020-03-19 21:46:24 | hotWaterTemperature | 58.5  |  0.1 |     5 |
| 2020-03-19 21:51:24 | hotWaterTemperature | 58.4  | -0.1 |     5 |
| 2020-03-19 22:11:24 | hotWaterTemperature | 58.2  | -0.2 |    20 |
| 2020-03-19 22:35:20 | hotWaterTemperature | 58.0  | -0.2 |    23 |
| 2020-03-19 22:36:24 | hotWaterTemperature | 57.9  | -0.1 |     1 |
| 2020-03-19 22:41:25 | hotWaterTemperature | 57.7  | -0.2 |     5 |
| 2020-03-19 22:51:24 | hotWaterTemperature | 57.6  | -0.1 |     9 |
| 2020-03-19 23:10:00 | hotWaterTemperature | 57.4  | -0.2 |    18 |
| 2020-03-19 23:16:24 | hotWaterTemperature | 57.2  | -0.2 |     6 |
| 2020-03-19 23:21:24 | hotWaterTemperature | 56.9  | -0.3 |     5 |
| 2020-03-19 23:31:24 | hotWaterTemperature | 56.8  | -0.1 |    10 |
| 2020-03-19 23:36:24 | hotWaterTemperature | 56.9  |  0.1 |     5 |
| 2020-03-19 23:41:24 | hotWaterTemperature | 56.8  | -0.1 |     5 |
| 2020-03-20 00:01:24 | hotWaterTemperature | 56.6  | -0.2 |    20 |
| 2020-03-20 00:26:24 | hotWaterTemperature | 56.5  | -0.1 |    25 |
| 2020-03-20 00:46:24 | hotWaterTemperature | 56.3  | -0.2 |    20 |
| 2020-03-20 01:06:25 | hotWaterTemperature | 56.1  | -0.2 |    20 |
| 2020-03-20 01:26:25 | hotWaterTemperature | 56.0  | -0.1 |    20 |
| 2020-03-20 01:56:25 | hotWaterTemperature | 55.8  | -0.2 |    30 |
| 2020-03-20 02:16:25 | hotWaterTemperature | 55.7  | -0.1 |    20 |
| 2020-03-20 02:36:25 | hotWaterTemperature | 55.5  | -0.2 |    20 |
| 2020-03-20 03:01:25 | hotWaterTemperature | 55.4  | -0.1 |    25 |
| 2020-03-20 03:36:25 | hotWaterTemperature | 55.2  | -0.2 |    35 |
| 2020-03-20 03:51:25 | hotWaterTemperature | 55.1  | -0.1 |    15 |
| 2020-03-20 04:11:25 | hotWaterTemperature | 54.9  | -0.2 |    20 |
| 2020-03-20 04:41:25 | hotWaterTemperature | 54.8  | -0.1 |    30 |
| 2020-03-20 05:06:25 | hotWaterTemperature | 54.6  | -0.2 |    25 |
| 2020-03-20 05:26:25 | hotWaterTemperature | 54.5  | -0.1 |    20 |
| 2020-03-20 05:30:20 | hotWaterTemperature | 54.3  | -0.2 |     3 |
| 2020-03-20 05:36:25 | hotWaterTemperature | 53.9  | -0.4 |     6 |
| 2020-03-20 05:41:25 | hotWaterTemperature | 53.7  | -0.2 |     5 |
| 2020-03-20 05:56:25 | hotWaterTemperature | 53.6  | -0.1 |    15 |
| 2020-03-20 06:00:20 | hotWaterTemperature | 53.4  | -0.2 |     3 |
| 2020-03-20 06:01:25 | hotWaterTemperature | 53.3  | -0.1 |     1 |
| 2020-03-20 06:06:25 | hotWaterTemperature | 52.9  | -0.4 |     5 |
| 2020-03-20 06:11:25 | hotWaterTemperature | 52.7  | -0.2 |     5 |
| 2020-03-20 06:21:25 | hotWaterTemperature | 52.6  | -0.1 |    10 |
| 2020-03-20 06:31:25 | hotWaterTemperature | 52.4  | -0.2 |    10 |
| 2020-03-20 06:46:25 | hotWaterTemperature | 52.3  | -0.1 |    15 |
| 2020-03-20 06:56:25 | hotWaterTemperature | 52.2  | -0.1 |    10 |
| 2020-03-20 07:11:25 | hotWaterTemperature | 52.0  | -0.2 |    15 |
| 2020-03-20 07:26:25 | hotWaterTemperature | 51.9  | -0.1 |    15 |
| 2020-03-20 07:41:25 | hotWaterTemperature | 51.7  | -0.2 |    15 |
| 2020-03-20 07:56:25 | hotWaterTemperature | 51.6  | -0.1 |    15 |
| 2020-03-20 08:05:20 | hotWaterTemperature | 51.3  | -0.3 |     8 |
| 2020-03-20 08:06:25 | hotWaterTemperature | 51.2  | -0.1 |     1 |
| 2020-03-20 08:11:25 | hotWaterTemperature | 50.8  | -0.4 |     5 |
| 2020-03-20 08:16:25 | hotWaterTemperature | 50.7  | -0.1 |     5 |
| 2020-03-20 08:21:25 | hotWaterTemperature | 50.5  | -0.2 |     5 |
| 2020-03-20 08:35:20 | hotWaterTemperature | 50.2  | -0.3 |    13 |
| 2020-03-20 08:36:25 | hotWaterTemperature | 50.1  | -0.1 |     1 |
| 2020-03-20 08:41:25 | hotWaterTemperature | 49.7  | -0.4 |     5 |
| 2020-03-20 08:46:25 | hotWaterTemperature | 49.4  | -0.3 |     5 |
| 2020-03-20 09:06:25 | hotWaterTemperature | 49.3  | -0.1 |    20 |
| 2020-03-20 09:11:25 | hotWaterTemperature | 49.4  |  0.1 |     5 |
| 2020-03-20 09:16:25 | hotWaterTemperature | 49.3  | -0.1 |     5 |
| 2020-03-20 09:36:25 | hotWaterTemperature | 49.2  | -0.1 |    20 |
| 2020-03-20 09:56:26 | hotWaterTemperature | 49.0  | -0.2 |    20 |
| 2020-03-20 10:06:26 | hotWaterTemperature | 48.9  | -0.1 |    10 |
| 2020-03-20 10:11:26 | hotWaterTemperature | 48.5  | -0.4 |     5 |
| 2020-03-20 10:16:26 | hotWaterTemperature | 45.4  | -3.1 |     5 |
| 2020-03-20 10:21:26 | hotWaterTemperature | 43.6  | -1.8 |     5 |
| 2020-03-20 10:26:26 | hotWaterTemperature | 44.1  |  0.5 |     5 |
| 2020-03-20 10:31:26 | hotWaterTemperature | 45.5  |  1.4 |     5 |
| 2020-03-20 10:36:26 | hotWaterTemperature | 47.5  |  2.0 |     5 |
| 2020-03-20 10:41:26 | hotWaterTemperature | 49.7  |  2.2 |     5 |
| 2020-03-20 10:46:26 | hotWaterTemperature | 51.6  |  1.9 |     5 |
| 2020-03-20 10:51:26 | hotWaterTemperature | 53.4  |  1.8 |     5 |
| 2020-03-20 10:56:26 | hotWaterTemperature | 54.9  |  1.5 |     5 |
| 2020-03-20 11:01:26 | hotWaterTemperature | 56.5  |  1.6 |     5 |
| 2020-03-20 11:06:26 | hotWaterTemperature | 58.0  |  1.5 |     5 |
| 2020-03-20 11:11:26 | hotWaterTemperature | 59.5  |  1.5 |     5 |
| 2020-03-20 11:16:26 | hotWaterTemperature | 60.7  |  1.2 |     5 |
| 2020-03-20 11:21:26 | hotWaterTemperature | 61.1  |  0.4 |     5 |
| 2020-03-20 11:41:26 | hotWaterTemperature | 61.3  |  0.2 |    20 |
| 2020-03-20 11:56:26 | hotWaterTemperature | 61.1  | -0.2 |    15 |
| 2020-03-20 12:01:26 | hotWaterTemperature | 61.3  |  0.2 |     5 |
| 2020-03-20 13:06:26 | hotWaterTemperature | 61.1  | -0.2 |    65 |
| 2020-03-20 14:51:26 | hotWaterTemperature | 60.9  | -0.2 |   105 |
| 2020-03-20 15:21:26 | hotWaterTemperature | 60.7  | -0.2 |    30 |
+---------------------+---------------------+-------+------+-------+
102 rows in set (0.017 sec)

Gruss
Christian

DS_Starter · 20 März 2020, 16:55:22

Hallo Christian,

nicht in dieser Form. Bestimmt wieder super brauchbar, cool und danke Christian

Ich übernehme es ins nächste Release und gebe es dir/euch vorher zum Test ...

LG,
Heiko

ch.eick · 20 März 2020, 17:40:31

Zitat von: DS_Starter am 20 März 2020, 16:55:22
nicht in dieser Form. Bestimmt wieder super brauchbar, cool und danke Christian

Wenn es das schon gibt, habe ich es nur noch nicht gefunden. Wenn es schon da ist, dann ist es auch gut.
Wo kann ich denn sowas finden, auch als Anregung fuer neue Projekte?

Gruss
Christian

DS_Starter · 20 März 2020, 18:05:11

Hi Christian,

das "nicht in dieser Form" bezog sich darauf, dass das Verfahren in einer ähnlichen Form für diffValue verwendet wird.
Aber das ist für den User ja nicht transparent und im Ergebnis ja auch etwas anders. Also insofern ist dieser Anwendungsfall wieder neu für den User und so nicht vorhanden.

Du findest es nur indirekt im Modul so ab Zeile 3773 (V8.36.0), musst dich aber in den verschachtelten Code reinlesen weil der SQL-Code nicht so einfach dasteht, sondern im Modul zusammengesetzt wird.

Am einfachsten ist tatsächlich verbose 4 um das je nach ausgeführter Funktion erstellte SQL zu sehen.

LG,
Heiko

DS_Starter · 20 März 2020, 18:31:23

@Christian, ich bräuchte einen sprechenden Namen für diesen select in der sqlSpecial DropDown-Liste. Hast du eine Idee dafür ?

ch.eick · 20 März 2020, 19:07:15

Zitat
ich bräuchte einen sprechenden Namen für diesen select in der sqlSpecial DropDown-Liste. Hast du eine Idee dafür ?
Ich denk morgen wieder

Wie waere "readingsDifferenceByTimeDelta"
aber wie bereits geschrieben versuche ich es noch zu verbessern...

flummy1978 · 21 März 2020, 10:52:12

Holla,

ich muss mal mit nem kleinen Problem ankommen:

Ich hab folgenden Befehl auf der Testumgebung gefühlte 100 x angegeben (mit anderen Readings und Zeiten)

Code Auswählen

set DBRep reduceLog 120:150 average INCLUDE=read_OG_SZ_conditions:Humidity

Auf dem Testsystem funktionierte es einwandfrei auf dem Live System hab ich es heute Nacht noch mit dem händischen Update getestet, heute Morgendann mit dem LiveUpdate und leider mit dem gleichen Ergebnis: Mein Fhem stürzt komplett ab. Die einzige für mich erkennbare aber nicht verwertbare Fehlermeldung ist
Month '-1' out of range 0..11 at ./FHEM/93_DbRep.pm line 2086.
Sonst kommt auch mit verbose 5 nicht mehr bei raus ;(

Code Auswählen

2020.03.21 10:44:31.071 3: DbRep DBRep - ################################################################
2020.03.21 10:44:31.072 3: DbRep DBRep - ###                    new reduceLog run                     ###
2020.03.21 10:44:31.073 3: DbRep DBRep - ################################################################
2020.03.21 10:44:31.114 4: DbRep DBRep - -------- New selection --------- 
2020.03.21 10:44:31.114 4: DbRep DBRep - Command: reduceLog 
2020.03.21 10:44:31.116 4: DbRep DBRep - Timestamp begin human readable: not set
2020.03.21 10:44:31.116 4: DbRep DBRep - Timestamp end human readable: not set
Month '-1' out of range 0..11 at ./FHEM/93_DbRep.pm line 2086.

Hoffe Du hast da ne Idee, Heiko (oder vielleicht auch jemand anderes)

Viele Grüße
Andreas

DS_Starter · 21 März 2020, 12:27:02

Hallo Andreas,

böse Falle denke ich. Kann es sein dass du keines der time.*-Attribute gesetzt hast ?
Also timeDiffToNow usw. ....

Wenn nicht mach das. Ich baue eine Prüfung ein.

LG,
Heiko

flummy1978 · 21 März 2020, 12:47:43

Hey,

vielen Dank für die schnelle Rückmeldung...

Zitat von: DS_Starter am 21 März 2020, 12:27:02
böse Falle denke ich. Kann es sein dass du keines der time.*-Attribute gesetzt hast ?
Also timeDiffToNow usw. ....

Nein, habe ich nicht. Aber (jetzt bin ich verwirrt

)das war doch Sinn der Sache, wenn ich ....reduceLog 120:150... eingebe, oder ?

Wenn die beiden eingegeben werden müssen, dann könnte ich timeDiffToNow 370 und timeOlderThan 365 einstellen und davon ausgehen, dass aus Versehen schon mal nichts gelöscht wird, das jünger als 1 Jahr ist ?

teil list vom db Rep

Code Auswählen

Attributes:
   DbLogExclude .*
   allowDeletion 1
   group      FileLog
   icon       own-log@darkgrey
   room       System->Log & Web
[b]   timeDiffToNow d:155
   timeOlderThan d:150[/b]
   verbose    4

Damit funktioniert es dann, wie gewollt

Code Auswählen


2020.03.21 12:42:03.182 4 : DbRep DBRep - -------- New selection --------- 
2020.03.21 12:42:03.182 4 : DbRep DBRep - Command: reduceLog 
2020.03.21 12:42:03.185 4 : DbRep DBRep - timeDiffToNow - year: , day: 150, hour: , min: , sec: 
2020.03.21 12:42:03.185 4 : DbRep DBRep - Year 2020 is leap year
2020.03.21 12:42:03.186 4 : DbRep DBRep - startMonth: 9 endMonth: 2 lastleapyear: 2020 baseYear: 2019 diffdaylight:1 isdaylight:0
2020.03.21 12:42:03.187 4 : DbRep DBRep - timeOlderThan - year: 0, day: 120, hour: 0, min: 0, sec: 0
2020.03.21 12:42:03.188 4 : DbRep DBRep - Year 2020 is leap year
2020.03.21 12:42:03.189 4 : DbRep DBRep - startMonth: 8 endMonth: 10 lastleapyear: 2020 baseYear: 2019 diffdaylight:0 isdaylight:0
2020.03.21 12:42:03.189 4 : DbRep DBRep - FullDay option: 0
2020.03.21 12:42:03.190 4 : DbRep DBRep - Time difference to current time for calculating Timestamp begin: 13050001 sec
2020.03.21 12:42:03.191 4 : DbRep DBRep - Timestamp begin human readable: 2019-10-22 12:42:02
2020.03.21 12:42:03.192 4 : DbRep DBRep - Time difference to current time for calculating Timestamp end: 10454401 sec
2020.03.21 12:42:03.192 4 : DbRep DBRep - Timestamp end human readable: 2019-11-21 12:42:02
2020-03-21 12:42:03.263 DbRep DBRep reduceLog database is running - be patient and see Logfile !

Viele Grüße
Andreas

DS_Starter · 21 März 2020, 12:53:58

Zitatjetzt bin ich verwirrt )das war doch Sinn der Sache, wenn ich ....reduceLog 120:150... eingebe, oder ?

Das glaube ich dir, dass du jetzt verwirrt bist, sorry

Es gibt nur innerhalb des Programmablaufs eine Logik die mit den time.*-Attributen arbeitet. Die 120:150 übertseuern die Attribute wie gewollt, soweit so gut. Nur wenn keine Zeitattribute gesetzt sind, gibt auch nichts zu übersteuern ... Rest kannst du dir denken ...

Ich korrigiere das gerade ...