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

ch.eick · 28 Februar 2021, 12:42:29

Zitat von: DS_Starter am 28 Februar 2021, 11:58:28
Die Meldungen sind nicht so gut.
Es bedeutet folgendes. Du startest eine Aktivität und während die läuft (und noch nicht fertig ist) startest du mit dem gleichen Device wieder eine neue Aktion. Das Device bricht daraufhin seine laufende Aktivität ab was zu der Meldung führt "WARNING - old process 31994 will be killed now to start a new BlockingCall".

Da solltest du mal schauen wieso diese Überschneidungen auftreten und ggf. die Abläufe ändern oder verschiedene DbReps nutzen wenn möglich.

Okay, ich habe es behoben, danke.

Ich hatte ein sqlCmd abgesetzt und etwas später ein sqlCmdBlocking.
Jetzt ist beides auf sqlCmdBlocking und die Meldungen sind weg.

Gruß
Christian

DS_Starter · 28 Februar 2021, 14:24:33

ZitatIch hatte ein sqlCmd abgesetzt und etwas später ein sqlCmdBlocking.

Ah das ist interessant. Gut dass du das erwähnst. Diese beiden Kommandos können parallel laufen.
Im kommenden Release werde ich es entkoppeln. Dann können solche Konstrukte ablaufen.

DS_Starter · 28 Februar 2021, 16:57:37

Hallo Christian,

ich habe mal den Code gecheckt und auch ausprobiert. Auch jetzt schon sind sqlCmd und sqlCmdBlocking voneinander entkoppelt.
D.h. die von dir erwähnten Meldungen müssen einen anderen Zusammenhang haben.

ch.eick · 28 Februar 2021, 17:01:52

Zitat von: DS_Starter am 28 Februar 2021, 16:57:37
ich habe mal den Code gecheckt und auch ausprobiert. Auch jetzt schon sind sqlCmd und sqlCmdBlocking voneinander entkoppelt.
D.h. die von dir erwähnten Meldungen müssen einen anderen Zusammenhang haben.

Das sqlCmd war ein "DELETE" und das zweite ein "INSERT", die DB läuft mit cache.
Ich versuche es nochmal nachzustellen.

ch.eick · 03 März 2021, 16:45:27

Hallo Heiko,
ich habe jetzt die Version aus dem contrib einige tage laufen und es nichts weiter aufgetreten.
Hattest Du das schon eingechecked?

VG Christian

DS_Starter · 03 März 2021, 17:16:45

Habe sie noch nicht eingecheckt weil ich erst noch auf weitere Rückinfod zu meiner Erweiterung in DbLog -> https://forum.fhem.de/index.php/topic,118817.0.html
gewartet hatte.

Aber da dort nichts weiter gekommen ist, werde ich DbRep / DbLog heute oder morgen einchecken.
Will es beides zusammen erledigen.

Grüße,
Heiko

DS_Starter · 04 März 2021, 21:02:14

Die neue DbRep-Version ist jetzt eingecheckt.

LG,
Heiko

cwagner · 10 März 2021, 17:50:24

Bin jetzt auf GTS gestoßen, gerade noch rechtzeitig bevor ich mir mit DOIF einen eigenen Zähler mit allen Schmerzen gebaut hätte. Seit langem benutze ich schon die Aufzeichnung der DWD-gerechten Tagesmitteltemperatur AVGDMGWS, starte einmal kurz vor Mitternacht zeitgesteuert

Code Auswählen

set RP.T.Aussen.MinMax averageValue writeTODBSingle und habe den jeweiligen Tageswert sauber als Event "calculated" in der Datenbank.

Nun ist mir unklar, warum dasselbe mit dem Attribut averageCalcForm für avgDailyMeanGWSwithGTS nicht funktioniert und ich wie im tollen Wiki-Eintrag beschrieben den Umweg über eine user-definierte Funktion gehen muss.

Mir ist es jedenfalls nicht gelungen, die Werte mit writeTODB oder writeTODBSingle in die Datenbank zu bekommen - über die userEXITFn geht es zwar, ist aber für mich verwirrend.

Danke für eine Aufklärung, wenn möglich

Christian

DS_Starter · 10 März 2021, 19:21:38

Hallo Christian,

Zitat
Mir ist es jedenfalls nicht gelungen, die Werte mit writeTODB oder writeTODBSingle in die Datenbank zu bekommen - über die userEXITFn geht es zwar, ist aber für mich verwirrend.

Das hat programmtechnische Ursachen. Die Berechnung des GTS über die CalcForm avgDailyMeanGWSwithGTS ist lediglich eine "Erweiterung" von avgDailyMeanGWS. Die Berechnung habe ich wegen eines Userwunsches später "aufgepfropft".
Ich bin diesbezüglich intern an eine Designgrenze gestoßen und diese aufzulösen hätte mir zuviel Arbeit bereitet (aktuell).
Deswegen dieser im Wiki beschriebene Workaround. Damit kommt man als User aber auch gut klar denke ich.

Grüße,
Heiko

cwagner · 10 März 2021, 22:42:51

Vielen Dank für die schnelle und offene Antwort. Immerhin bist Du ja auf den Wunsch eingegangen und hast dieses spannende Thema programmatisch umgesetzt. - ok, dann werde ich mal Erfahrung sammeln mit der Lösung - spontan hatte ich die Sorge, das ich mir mit jedem Lauf praktisch die bereits errechneten Werte zurückliegender Tage erneut in die Datenbank hole...

Herzliche Grüße

Christian

cwagner · 12 März 2021, 12:28:12

Darf ich doch noch einmal auf das Thema zurückkommen? Der im Wiki vorgeschlagene Weg mit einer User-Funktion funktioniert prima mit einem herben Aspekt: Wenn ich täglich auf dem Laufenden bleiben will, erzeuge ich jeden Tag für alle zurückliegenden Tage in der Datenbank einen neuen, gleichen Eintrag. Hätte ich am 1.1. angefangen, wären das heute am 71. Tag des Jahres bereits 2556 Datenbankeinträge statt 71.
Siehst Du eine Option, die Ausgabe auf den jeweils letzten Tag einzugrenzen oder im GTSSave nur das letzte Reading zu verarbeiten?

BG Christian

DS_Starter · 12 März 2021, 12:46:07

Hallo Christian,

adhoc mehre Möglichkeiten:

1. in der DB einen primarary Key anlegen. Der verhindert generell doppelte Datensätze. Im Nachhinein nicht einfach zu implementieren, deswegen eher für Neuanfang

2. Im DbLog das Attr valueFn benutzen und mit einer kleinen Perl-Routine nur den Wert des aktuellen Tages durchlassen (Stichwort $IGNORE)

3. einfach ein DbRep device benutzen und mit delDoublets regelmäßig evtl. doppelt vorkommende Datensätze löschen

Gibt sicherlich noch mehr, aber 3. ist simpel und schnell eingerichtet.

Grüße,
Heiko

ch.eick · 12 März 2021, 13:36:23

Zitat von: DS_Starter am 12 März 2021, 12:46:07
1. in der DB einen primarary Key anlegen. Der verhindert generell doppelte Datensätze. Im Nachhinein nicht einfach zu implementieren, deswegen eher für Neuanfang

2. Im DbLog das Attr valueFn benutzen und mit einer kleinen Perl-Routine nur den Wert des aktuellen Tages durchlassen (Stichwort $IGNORE)

3. einfach ein DbRep device benutzen und mit delDoublets regelmäßig evtl. doppelt vorkommende Datensätze löschen

3 wäre ne gute Vorbereitung für 1

cwagner · 12 März 2021, 18:40:30

Zitat von: ch.eick am 12 März 2021, 13:36:23
3 wäre ne gute Vorbereitung für 1

Das habe ich beim Einlesen und Umsetzen auch gemerkt

und vermutlich war das auch der Hintersinn "Im Nachhinein nicht so einfach..."
Gut die ersten 41.000 Doubletten aus anderen Devices werden gerade getilgt...

Danke für die Bestärkung, dass ich auf einem zielführenden Weg bin.

Christian

Mumpitz · 27 März 2021, 09:48:34

Hallo zusammen

Ich bräuchte mal euer Schwarmwissen. Ich bin stolzer Besitzer eine PV Anlage inkl. Stromspeicher. Die Anlage habe ich in fhem eingebunden. Die Statistiken dazu werden jede Stunde per HTTPMOD abgerufen und in das Device WR_Plenticore_API geschrieben. Die Readings werden in ein DBLog geschrieben.

Nun ist es so, dass natürlich diverse Tagesreadings mitgeloggt werden, welche allesamt auf *._Day enden. Diesbezüglich ist jedoch historisch gesehen nur der letzte Wert am Ende des Tages massgebend. Daher möchte ich die Werte unter Tage jeweils einmal die Woche oder Monat löschen.

Dafür gibt es bekanntlich die Funktion des maxValue. Ich könnte natürlich nun ein Device anlegen und des Reading einzeln mittels maxValue bearbeiten lassen. Ich bin aber der Meinung das dies sicherlich auch über alle Readings des entpsrechenden Devices gehen wird. Ich habe folgendes versucht:

Code Auswählen

defmod LogDBRep_delete_Statistic_Day_max_Day DbRep DBLogging
attr LogDBRep_delete_Statistic_Day_max_Day DbLogExclude .*
attr LogDBRep_delete_Statistic_Day_max_Day aggregation day
attr LogDBRep_delete_Statistic_Day_max_Day allowDeletion 1
attr LogDBRep_delete_Statistic_Day_max_Day device WR_Plenticore_API
attr LogDBRep_delete_Statistic_Day_max_Day group Delete_neu
attr LogDBRep_delete_Statistic_Day_max_Day reading *._Day
attr LogDBRep_delete_Statistic_Day_max_Day room Log
attr LogDBRep_delete_Statistic_Day_max_Day timestamp_begin previous_year_begin
attr LogDBRep_delete_Statistic_Day_max_Day timestamp_end previous_day_end

Das Resultat davon war, dass er gesamthaft nur ein Reading, welches auf *._Day geendet hat, behalten wurde.

Dann habe ich versucht, alle Readings unter Reading einzutragen:

Code Auswählen

attr LogDBRep_delete_Statistic_Day_max_Day reading Statistic_Autarky_Day,Statistic_CO2Saving_Day,Statistic_EnergyChargeGrid_Day,Statistic_EnergyChargeInvIn_Day,Statistic_EnergyChargePv_Day,Statistic_EnergyDischargeGrid_Day,Statistic_EnergyDischarge_Day,Statistic_EnergyFeedInGrid_Day,Statistic_EnergyHomeBat_Day,Statistic_EnergyHomeGrid_Day,Statistic_EnergyHomePvSum_Day,Statistic_EnergyHomePv_Day,Statistic_EnergyHome_Day,Statistic_EnergyPv1_Day,Statistic_EnergyPv2_Day,Statistic_EnergyPv3_Day,Statistic_OwnConsumptionRate_Day,Statistic_TotalConsumption_Day,Statistic_Yield_Day,Statistic_Yield_NoBat_Day,

Auch hier hat er nur ein Reading behalten.

Habt ihr eine Idee, wie die Readings auf einen rutsch bereinigt werden können?

Statistic_Autarky_Day,
Statistic_CO2Saving_Day,
Statistic_EnergyChargeGrid_Day,
Statistic_EnergyChargeInvIn_Day,
Statistic_EnergyChargePv_Day,
Statistic_EnergyDischargeGrid_Day,
Statistic_EnergyDischarge_Day,
Statistic_EnergyFeedInGrid_Day,
Statistic_EnergyHomeBat_Day,
Statistic_EnergyHomeGrid_Day,
Statistic_EnergyHomePvSum_Day,
Statistic_EnergyHomePv_Day,
Statistic_EnergyHome_Day,
Statistic_EnergyPv1_Day,
Statistic_EnergyPv2_Day,
Statistic_EnergyPv3_Day,
Statistic_OwnConsumptionRate_Day,
Statistic_TotalConsumption_Day,
Statistic_Yield_Day,
Statistic_Yield_NoBat_Day

Besten Dank!