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

Begonnen von DS_Starter, 19 Mai 2016, 22:52:13

Vorheriges Thema - Nächstes Thema

RalfRog

Link zum Beitrag: https://forum.fhem.de/index.php/topic,53584.msg1191355.html#msg1191355

Zitat von: DS_Starter am 05 Dezember 2021, 21:12:32
Beitrag #1535

Offen ist noch, dass bei average die letzte Stunde nicht auf den Halbstundenwert reduziert wird und bei average=day der letzte
Tag nicht auf den 12:00 Wert reduziert wird. Aber da bin ich dran
--------------------------------------------------------------------
Beitrag #1536

Ist nun auch erledigt und die Version ins contrib geladen.

LG

Ich weiss nicht mehr wie intensiv ich mir das damals angeschaut habe....  mir ist jetzt bei der Suche nach einem Eintag aufgefallen, dass die letzte Stunde nicht stimmt.
Ich schau am Freutag nochmal rein (bin zwar in Holland müsste aber klappen).
Aktuell hier das Ergebnis des Laufs vom vergangenen Freitag - es sieht aus als würde der average berechnet und nur die Einträge nicht gelöscht.


TIMESTAMP             DEVICE       TYPE    EVENT         READING VALUE  UNIT
2022-06-07  20:30:00  shelly_plug  SHELLY  rl_av_h       power   0.890
2022-06-07  20:26:22  shelly_plug  SHELLY  power: 0      power   0
2022-06-07  20:21:22  shelly_plug  SHELLY  power: 0.34   power   0.34
2022-06-07  20:17:09  shelly_plug  SHELLY  power: 0.55   power   0.55
2022-06-07  20:12:09  shelly_plug  SHELLY  power: 0.63   power   0.63
2022-06-07  20:07:04  shelly_plug  SHELLY  power: 1.47   power   1.47
2022-06-07  19:30:00  shelly_plug  SHELLY  rl_av_h       power  12.223
2022-06-07  18:30:00  shelly_plug  SHELLY  rl_av_h       power  13.427


Da ich wöchentlich mit einem Tag Uberlappung arbeite, wird es beim neuen Lauf korrigiert. Der mögliche Berechnungsfehler spielt bei mir auch keine Rolle, da es historisch nur um die Größenordnung geht.

Gruß Ralf
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

RalfRog

Heute Nacht wurde bei der Bereinigung die letzte Stunde nicht auf den Halbstundenwert reduziert und die regulären Datenbankeinträge sind noch da.


2022-06-14 21:31:00 shelly_plug_s_df2674 manual manual power 0
2022-06-14 21:14:31 shelly_plug_s_df2674 SHELLY power: 0 power 0
2022-06-14 21:12:15 shelly_plug_s_df2674 SHELLY power: 0.5 power 0.5
2022-06-14 21:07:15 shelly_plug_s_df2674 SHELLY power: 0.91 power 0.91
2022-06-14 21:04:23 shelly_plug_s_df2674 SHELLY power: 1.08 power 1.08
2022-06-14 21:02:15 shelly_plug_s_df2674 SHELLY power: 1.04 power 1.04
2022-06-14 20:30:00 shelly_plug_s_df2674 SHELLY rl_av_h power 2.816
2022-06-14 19:30:00 shelly_plug_s_df2674 SHELLY rl_av_h power 5.472


Es liegt doch nicht an dem "manual" Eintrag, den ich 21.31 und 5.31 Uhr setze um die Kurve auf Null zu bringen.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

DS_Starter

Kannst du nochmal genau schreiben wie du den Befehl (mit / ohne Optionen im Befehl) aufrufst ?
Und am Besten ein List vom Device noch dazu. Ich muß versuchen es bei mir nachzustellen. Vllt. habe ich dann noch eine Idee.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

RalfRog

Zunächst das fragliche Rep-Device (DBRep_reduPower):

Internals:
   DATABASE   fhem
   DEF        DBLogging
   FUUID      60a6d173-f33f-a8ec-3be0-2e7e866eb54ed451
   FVERSION   93_DbRep.pm:v8.49.0-s25939/2022-04-09
   LASTCMD    reduceLog average
   MODEL      Client
   NAME       DBRep_reduPower
   NOTIFYDEV  global,DBRep_reduPower
   NR         486
   NTFY_ORDER 50-DBRep_reduPower
   ROLE       Client
   STATE      reduceLog of fhem finished
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE DBLogging
     GRANTS     UPDATE,FILE,DELETE,INSERT,SELECT
     IDRETRIES  2
     MINTS      2019-02-17 12:00:00
     PACKAGE    main
     VERSION    8.49.0
     CV:
       aggregation no
       aggsec     1
       destr      2022-06-21
       dsstr      2022-06-14
       epoch_seconds_end 1655848799
       mestr      06
       msstr      06
       testr      23:59:59
       tsstr      00:00:00
       wdadd      518400
       yestr      2022
       ysstr      2022
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2022-07-01 23:45:03   background_processing_time 3.40
     2022-07-01 23:45:03   reduceLogState  reduceLog finished. Rows processed: 1807, deleted: 1664, updated: 115
     2022-07-01 23:45:03   state           reduceLog of fhem finished
Attributes:
   device     shelly.*
   executeAfterProc msg push -1 [DBRep_reduPower:state] fuer shelly:power
   executeBeforeProc set DBLogging reopen 300
   reading    power
   room       Dbase
   timeDiffToNow d:17 FullDay
   timeOlderThan d:10 FullDay
   useAdminCredentials 0


Der Aufruf geschieht über ein AT am Freitag (das AT startet zusätzlich am Donnerstag ein ReduceLog mit DBRep_reduEnergy, hier nicht betrachtet)

Internals:
   COMMAND    { fhem ("msg push -1 Start reduceDBlog") ;
   if ($wday == 5) { fhem ("set DBRep_reduPower reduceLog average") }
elsif ($wday == 4) { fhem ("set DBRep_reduEnergy reduceLog") } }
   DEF        *23:45 { fhem ("msg push -1 Start reduceDBlog") ;
   if ($wday == 5) { fhem ("set DBRep_reduPower reduceLog average") }
elsif ($wday == 4) { fhem ("set DBRep_reduEnergy reduceLog") } }
   FUUID      60a6f4e0-f33f-a8ec-dc2e-bc1116a48f93ad37
   FVERSION   90_at.pm:0.252480/2021-11-21
   NAME       ReduceDB_weekly
   NR         488
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 23:45:00
   TIMESPEC   23:45
   TRIGGERTIME 1656798300
   TRIGGERTIME_FMT 2022-07-02 23:45:00
   TYPE       at
   READINGS:
     2022-07-01 23:45:00   state           Next: 23:45:00
Attributes:
   comment    Donnerstag und Freitag Datenbank für Shelly um 23:45 reduzieren (mit Device DBRep_reduEnergy und DBRep_reduPower)
   room       Dbase


Das Ergebnis in der Datenbank gestern - alles gut bis auf die letzte Stunde. Hier mal mit etwas mehr Daten um den Zeitpunkt herum.
Was zusätzlich auffällt ist, dass diesmal wieder um 20:30 eine Average Wert dabei  ist ohne die anderen Einträge zu löschen. Nicht immer ist dieser Wert da. Wovon das abhängt ist mir nicht ersichtlich. Vermutlich aber ein sekundäres (oder Folge-) Problem.

TIMESTAMP;DEVICE;TYPE;EVENT;READING;VALUE;UNIT
2022-06-22 06:19:00;shelly_plug_s_df2674; SHELLY; power: 3.53; power; 3.53;
2022-06-22 06:14:00;shelly_plug_s_df2674; SHELLY; power: 3.44; power; 3.44;
2022-06-22 06:09:00;shelly_plug_s_df2674; SHELLY; power: 3.51; power; 3.51;
2022-06-22 06:04:00;shelly_plug_s_df2674; SHELLY; power: 3.2;  power; 3.2;
2022-06-22 06:00:45;shelly_plug_s_df2674; SHELLY; power: 2.59; power; 2.59;
2022-06-22 05:55:44;shelly_plug_s_df2674; SHELLY; power: 1.87; power; 1.87;
2022-06-22 05:50:44;shelly_plug_s_df2674; SHELLY; power: 1.43; power; 1.43;
2022-06-22 05:45:44;shelly_plug_s_df2674; SHELLY; power: 1.03; power; 1.03;
2022-06-22 05:43:37;shelly_plug_s_df2674; SHELLY; power: 0.87; power; 0.87;
2022-06-22 05:39:55;shelly_plug_s_df2674; SHELLY; power: 0.57; power; 0.57;
2022-06-22 05:29:00;shelly_plug_s_df2674; manual; manual;      power; 0;
2022-06-21 21:31:00;shelly_plug_s_df2674; manual; manual;      power; 0;
2022-06-21 20:49:07;shelly_plug_s_df2674; SHELLY; power: 0;    power; 0;
2022-06-21 20:44:58;shelly_plug_s_df2674; SHELLY; power: 1.2;  power; 1.2;
2022-06-21 20:39:58;shelly_plug_s_df2674; SHELLY; power: 2.57; power; 2.57;
2022-06-21 20:34:58;shelly_plug_s_df2674; SHELLY; power: 2.49; power; 2.49;
2022-06-21 20:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 1.605;
2022-06-21 20:29:58;shelly_plug_s_df2674; SHELLY; power: 2.12; power; 2.12;
2022-06-21 20:26:20;shelly_plug_s_df2674; SHELLY; power: 1.48; power; 1.48;
2022-06-21 20:21:20;shelly_plug_s_df2674; SHELLY; power: 1.41; power; 1.41;
2022-06-21 20:16:20;shelly_plug_s_df2674; SHELLY; power: 0.97; power; 0.97;
2022-06-21 20:09:40;shelly_plug_s_df2674; SHELLY; power: 1.68; power; 1.68;
2022-06-21 19:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 8.699;
2022-06-21 18:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 22.230;
2022-06-21 17:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 40.975;
2022-06-21 16:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 81.578;
2022-06-21 15:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 109.965;
2022-06-21 14:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 171.117;
2022-06-21 13:30:00;shelly_plug_s_df2674; SHELLY; rl_av_h;     power; 133.009;


Sowie der entsprechenden Bereich aus dem Logfile. Leider nur Verbose 3.
Am 14. sieht man schön, dass die 5 verbaselten Einträge von letzter Woche bereinigt wurden (damit ist die Vorwoche dann glatt).

2022.07.01 23:45:00.106 3: DbRep DBRep_reduPower - ################################################################
2022.07.01 23:45:00.107 3: DbRep DBRep_reduPower - ###                    new reduceLog run                     ###
2022.07.01 23:45:00.107 3: DbRep DBRep_reduPower - ################################################################
2022.07.01 23:45:00.139 3: DbRep DBRep_reduPower - execute command before reduceLog: 'set DBLogging reopen 300'
2022.07.01 23:45:00.145 2: DbLog DBLogging: Connection closed until 23:50:00 (300 seconds).
2022.07.01 23:45:00.289 3: DbRep DBRep_reduPower - reduce data older than: 2022-06-22 00:59:59 (logical corrected), newer than: 2022-06-14 00:00:00
2022.07.01 23:45:00.290 3: DbRep DBRep_reduPower - reduceLog requested with options:
AVERAGE=HOUR
INCLUDE -> Devs: shelly_plug_s_df2674 Readings: power
2022.07.01 23:45:00.460 3: DbRep DBRep_reduPower - reduceLog deleting 5 records of day: 2022-06-14
2022.07.01 23:45:00.476 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 1 records of day: 2022-06-14
2022.07.01 23:45:00.517 3: DbRep DBRep_reduPower - reduceLog deleting 190 records of day: 2022-06-15
2022.07.01 23:45:00.679 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-15 is: 100
2022.07.01 23:45:00.814 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 17 records of day: 2022-06-15
2022.07.01 23:45:00.892 3: DbRep DBRep_reduPower - reduceLog deleting 193 records of day: 2022-06-16
2022.07.01 23:45:01.042 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-16 is: 100
2022.07.01 23:45:01.178 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 17 records of day: 2022-06-16
2022.07.01 23:45:01.277 3: DbRep DBRep_reduPower - reduceLog deleting 265 records of day: 2022-06-17
2022.07.01 23:45:01.409 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-17 is: 100
2022.07.01 23:45:01.587 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-17 is: 200
2022.07.01 23:45:01.694 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 17 records of day: 2022-06-17
2022.07.01 23:45:01.774 3: DbRep DBRep_reduPower - reduceLog deleting 169 records of day: 2022-06-18
2022.07.01 23:45:01.934 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-18 is: 100
2022.07.01 23:45:02.041 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 16 records of day: 2022-06-18
2022.07.01 23:45:02.131 3: DbRep DBRep_reduPower - reduceLog deleting 297 records of day: 2022-06-19
2022.07.01 23:45:02.274 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-19 is: 100
2022.07.01 23:45:02.416 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-19 is: 200
2022.07.01 23:45:02.581 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 16 records of day: 2022-06-19
2022.07.01 23:45:02.681 3: DbRep DBRep_reduPower - reduceLog deleting 264 records of day: 2022-06-20
2022.07.01 23:45:02.823 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-20 is: 100
2022.07.01 23:45:02.967 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-20 is: 200
2022.07.01 23:45:03.071 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 15 records of day: 2022-06-20
2022.07.01 23:45:03.161 3: DbRep DBRep_reduPower - reduceLog deleting 281 records of day: 2022-06-21
2022.07.01 23:45:03.303 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-21 is: 100
2022.07.01 23:45:03.439 3: DbRep DBRep_reduPower - reduceLog deletion progress of day: 2022-06-21 is: 200
2022.07.01 23:45:03.564 3: DbRep DBRep_reduPower - reduceLog (hourly-average) updating 16 records of day: 2022-06-21
2022.07.01 23:45:03.628 3: DbRep DBRep_reduPower - reduceLog finished. Rows processed: 1807, deleted: 1664, updated: 115
2022.07.01 23:45:03.698 3: msg globalMsg: ID=1656711903.6422.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='reduceLog database is running - be patient and see Logfile ! fuer shelly:power'


FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

DS_Starter

Hallo Ralf, @all,

ich habe die reduceLog Funktion komplett überarbeitet und dabei deine Kritikpunkte berücksichtigt und auch beseitigt.
Die Überarbeitung habe ich auch unter dem Aspekt einer kommenden Funktionserweiterung von reduceLog vorgenommen, die in diesem Thread andiskutiert wurde.

In der neuen Version wird auch das Attr numDecimalPlaces zur Festlegung der Nachkommastellen der average-Ergebnisse berücksichtigt.
Die neue Version liegt zunächst im contrib zum Test bereit.Zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

RalfRog

Oh, danke.

Werde mir den Thread mal zu Gemüte führen und dann updaten.
Dauert nur ne Weile bis ich die Ergebnisse dann auch in der DB sehe.
Ich berichte!
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

DS_Starter

Ich habe jetzt noch die Möglichkeit eingebaut reduceLog mit den Optionen
   
    max

bzw.

   max=day

aufzurufen.

Die Commandref habe ich im Deutschen schon angepasst:

reduceLog [<no>[:<nn>]] [mode] [EXCLUDE=device1:reading1,device2:reading2,...] [INCLUDE=device:reading]
Reduziert historische Datensätze.


Arbeitsweise ohne Angabe von Befehlszeilenoperatoren

Es werden die Daten innerhalb der durch die time.*-Attribute bestimmten Zeitgrenzen bereinigt. Es muss mindestens eines der time.*-Attribute gesetzt sein (siehe Tabelle unten). Die jeweils fehlende Zeitabgrenzung wird in diesem Fall durch das Modul ermittelt.
Der Arbeitsmodus wird durch die optionale Angabe von mode bestimmt:

    ohne Angabe von mode : die Daten werden auf den ersten Eintrag pro Stunde je Device & Reading reduziert
    average                        : numerische Werte werden auf einen Mittelwert pro Stunde je Device & Reading reduziert
                                         (nicht numerische Werte werden wie ohne mode Angabe behandelt)
    average=day                : numerische Werte werden auf einen Mittelwert pro Tag je Device & Reading reduziert
                                          Die FullDay-Option (es werden immer volle Tage selektiert) wird impliziert verwendet.
                                         (nicht numerische Werte werden wie ohne mode Angabe behandelt)
    max                            : numerische Werte werden auf den Maximalwert pro Stunde je Device & Reading reduziert
                                         (nicht numerische Werte werden wie ohne mode Angabe behandelt)
    max=day                    : numerische Werte werden auf den Maximalwert pro Tag je Device & Reading reduziert
                                         Die FullDay-Option (es werden immer volle Tage selektiert) wird impliziert verwendet.
                                         (nicht numerische Werte werden wie ohne mode Angabe behandelt)

...


Liegt im contrib zum Test.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Ich habe soeben noch ein update bzgl. reduceLog in mein contrib geladen.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Ich habe reduceLog noch um min und min=day erweitert.


...
min : numerische Werte werden auf den Minimalwert pro Stunde je Device & Reading reduziert, sonst wie ohne mode
min=day : numerische Werte werden auf den Minimalwert pro Tag je Device & Reading reduziert, sonst wie ohne mode
  Die FullDay-Option (es werden immer volle Tage selektiert) wird impliziert verwendet.
...


V liegt im contrib.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Und last but not least ist im reduceLog noch umgesetzt:


sum : numerische Werte werden auf die Summe pro Stunde je Device & Reading reduziert, sonst wie ohne mode
sum=day : numerische Werte werden auf die Summe pro Tag je Device & Reading reduziert, sonst wie ohne mode
  Die FullDay-Option (es werden immer volle Tage selektiert) wird impliziert verwendet.


Liegt im contrib.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Neue Version mit überarbeiteten reduceLog ist eingecheckt und morgen früh im Update.

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

RalfRog

Zitat von: RalfRog am 25 Juni 2022, 19:58:10
Heute Nacht wurde bei der Bereinigung die letzte Stunde nicht auf den Halbstundenwert reduziert und die regulären Datenbankeinträge sind noch da.
......


Zitat von: DS_Starter am 22 August 2022, 22:05:10
Neue Version mit überarbeiteten reduceLog ist eingecheckt und morgen früh im Update.
LG

Hat leider länger gedauert mit der Rückmeldung (dafür kam die Version über das reguläre Update  ;)) und die neuen Möglichkeiten habe ich auch nicht getestet.

Aber das Problem mit den unvollständigen Averages am Ende des jüngsten Tags ist weg.
Alle Stundenwerte zu x:30 werden korrekt geschrieben :) und es bleiben keine Datenbankeinräge stehen.


TIMESTAMP;          DEVICE;              TYPE;  EVENT;      READING;VALUE;UNIT
2022-08-17 07:26:14;shelly_plug_s_df2674;SHELLY;power: 3.3; power;3.3;
2022-08-17 07:21:14;shelly_plug_s_df2674;SHELLY;power: 2.82;power;2.82;
2022-08-17 07:16:16;shelly_plug_s_df2674;SHELLY;power: 1.62;power;1.62;
2022-08-17 07:13:45;shelly_plug_s_df2674;SHELLY;power: 1.04;power;1.04;
2022-08-17 07:08:45;shelly_plug_s_df2674;SHELLY;power: 0.75;power;0.75;
2022-08-17 05:29:00;shelly_plug_s_df2674;manual;manual;     power;0;
2022-08-16 21:31:00;shelly_plug_s_df2674;manual;manual;     power;0;
2022-08-16 20:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;0.2300;
2022-08-16 19:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;3.6157;
2022-08-16 18:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;12.2937;
2022-08-16 17:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;28.8400;
2022-08-16 16:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;91.1250;
2022-08-16 15:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;139.9095;
2022-08-16 14:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;121.1065;
2022-08-16 13:30:00;shelly_plug_s_df2674;SHELLY;rl_av_h;    power;159.1086;


FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

DS_Starter

Morgen Ralf,

danke für die Rückmeldung. Vllt. hast du ja für die neuen Möglichkeiten auch eine Verwendung.
Feedback ist auch dafür gerne willkommen.

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

frober

Hallo Heiko,

ich habe ein weiteres Notify mit insert angelegt, leider bekomme ich einen BlockingCall Timeout im Log und das Insert wird nicht geschrieben. Hast du eine Idee, wo ich suchen soll?

ZitatFVERSION  93_DbRep.pm:v8.49.0-s25939/2022-04-09
Fhem bringe ich noch auf den aktuellen Stand, denke aber nicht, dass das hilft, da meine erstes Insert-Notify einwandfrei funktioniert.

Notify:
defmod n_Zisterne_Plot notify Zisternenpumpe:power:.* {if ($EVTPART1 > 50 && ReadingsVal('Zisternenpumpe','plot',0) == 0) {my $e = $EVTPART0;; chop $e;; my $t = ReadingsTimestamp($NAME,$e,'undef');; my @T = split(/ /, $t);; Debug("$T[0],$T[1],$NAME,$e");; return fhem("setreading Zisternenpumpe plot 1;; set insertDB insert $T[0],$T[1],0,,$NAME,$e");;} elsif ($EVTPART1 < 50 && ReadingsVal('Zisternenpumpe','plot',1) == 1) {return fhem 'setreading Zisternenpumpe plot 0';;}}


Verbose 1:
2022.09.03 17:00:13 1: DEBUG>2022-09-03,17:00:13,Zisternenpumpe,power
2022.09.03 17:00:13 1: DbRep insertDB -> BlockingCall DbRep_insert pid:6878 Timeout: process terminated
2022.09.03 17:00:13 1: DbRep insertDB -> BlockingCall DbRep_insert pid:6879 Timeout: process terminated
2022.09.03 17:03:14 1: DbRep insertDB -> BlockingCall DbRep_insert pid:6964 Timeout: process terminated
2022.09.03 17:06:15 1: DbRep insertDB -> BlockingCall DbRep_insert pid:7058 Timeout: process terminated


Verbose 5 bringt auch nicht mehr:
2022.09.03 10:34:12 5: Triggering n_Zisterne_Plot
2022.09.03 10:34:12 4: n_Zisterne_Plot exec {if ($EVTPART1 > 50 && ReadingsVal('Zisternenpumpe','plot',0) == 0) {my $e = $EVTPART0;; chop $e;; my $t = ReadingsTimestamp($NAME,$e,'undef');; my @T = split(/ /, $t);; Debug("$T[0],$T[1],$NAME,$e");; return fhem("setreading Zisternenpumpe plot 1;; set insertDB insert $T[0],$T[1],0,,$NAME,$e");;} elsif ($EVTPART1 < 50 && ReadingsVal('Zisternenpumpe','plot',1) == 1) {return fhem 'setreading Zisternenpumpe plot 0';;}}
2022.09.03 10:34:12 1: DEBUG>2022-09-03,10:34:12,Zisternenpumpe,power
2022.09.03 10:34:12 1: DbRep insertDB -> BlockingCall DbRep_insert pid:27242 Timeout: process terminated
2022.09.03 10:34:12 1: DbRep insertDB -> BlockingCall DbRep_insert pid:27243 Timeout: process terminated




Wenn ich ein trigger Zisternenpumpe power: 60 absetze, funktioniert es.

Plot:
Zitat2022-09-03_17:34:23 0
2022-09-03_17:34:55 60

Log:
Zitat2022.09.03 17:34:55 1: DEBUG>2022-09-03,17:34:23,Zisternenpumpe,power




Danke und Grüße
Bernd

Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

DS_Starter

Hallo Bernd,

Bin unterwegs ... gucken wir uns morgen mal an.

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter