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

[ch.eick]

Hmm, bei mir nicht.....

Sorry, ich hatte ne ältere version

[ch.eick]

Moin,
ich habe das executeAfterProc jetzt auch mal ausprobiert und es läuft prima. Bei Fehlermeldungen kommt auch eine Rückmeldung, jedoch nicht beim Erfolg.
Wäre es eventuell möglich Meldungen vom Skript oder zumindest einen Return Code als reading zu liefern?

Bei den Beispielen könnte man auch noch eins für z.B. Python mit aufnehmen.

Code Auswählen Erweitern

"/opt/fhem/python/Prognose_KI/PV-KI-21_batch.py"

In meinem Test konnte ich so für meine KI Leistungsprognose eine MySQL Procedur im Anschluss mit einem Python Skript koppeln.
Ich bin immer wieder begeistert, was man mit FHEM so alles machen kann.

Einige Fragen wären da dann noch:
1) Läuft das executeAfterProc dann blocking, oder asyncron im Hintergrund?
2) Werden im auszuführenden Kommando auch noch Variablen ersetzt, z.B. $NAME, bevor es ausgeführt wird?

EDIT:
Für die Überwachung des Skriptes habe ich zu Beginn ein setreading mit "running" in das DbRep gemacht, am Ende wird das dann mit "done" erneut gesetzt. Bisher läuft das jetzt ohne Probleme.

VG   Christian

[DS_Starter]

Hallo Christian,

Wäre es eventuell möglich Meldungen vom Skript oder zumindest einen Return Code als reading zu liefern?

Das ist schon so.
Es wird das Reading after_<Funktion>_message geschrieben. Zum Beispiel ist bei mir gesetzt:

    executeAfterProc = set LogDB reopen

Nach einem tableCurrentFillup wird der Befehl ausgeführt und das Reading mit der Rückmeldung des ausgeführten Befehls geschrieben:

  after_tableCurrentFillup_message = Reopen executed.

(Der ausgeführte Befehl oder die sub muss natürlich eine Rückmeldung zurückgeben.)

1) Läuft das executeAfterProc dann blocking, oder asyncron im Hintergrund?

Nein, zumindest nicht durch DbRep gesteuert.
Aber der Nutzer kann natürlich eine Perl-Routine hinterlegen, die ihrerseits non-Blocking (z.B. mit BlockingCall) arbeitet.

2) Werden im auszuführenden Kommando auch noch Variablen ersetzt, z.B. $NAME, bevor es ausgeführt wird?

Ersetzt nicht, aber der User kann seiner Routine die Struktur "$hash" mitgeben und daraus $hash->{NAME} herausziehen und selbst Ersetzungen vornehmen und vieles mehr.

Grüße,
Heiko

[ch.eick]

Es wird das Reading after_<Funktion>_message geschrieben. Zum Beispiel ist bei mir gesetzt:

    executeAfterProc = set LogDB reopen

Nach einem tableCurrentFillup wird der Befehl ausgeführt und das Reading mit der Rückmeldung des ausgeführten Befehls geschrieben:

  after_tableCurrentFillup_message = Reopen executed.

(Der ausgeführte Befehl oder die sub muss natürlich eine Rückmeldung zurückgeben.)
Nein, zumindest nicht durch DbRep gesteuert.
Aber der Nutzer kann natürlich eine Perl-Routine hinterlegen, die ihrerseits non-Blocking (z.B. mit BlockingCall) arbeitet.
Ersetzt nicht, aber der User kann seiner Routine die Struktur "$hash" mitgeben und daraus $hash->{NAME} herausziehen und selbst Ersetzungen vornehmen und vieles mehr.

Hallo Heiko,
Du überforderst mich wieder
Geht das mit dem $hash auch zu Python? Hättest Du da ein Beispiel?

Wenn ich aus dem Python mit print() eine Meldung schreibe ist die nicht sichtbar. Ich versuche es dann mal mit einen return Code.

[DS_Starter]

Geht das mit dem $hash auch zu Python? Hättest Du da ein Beispiel?

Wahrscheinlich nicht, aber sicherlich kann man Python (habe aber noch nie etwas damit gemacht!) Variablen übergeben.
Wie zum Beispiel

my $name = $hash->{NAME};

$name dann an Python übergeben. In $hash steckt ja z.B. alles drin was das aufrufende DbRep-Device enthält.
Es gibt ja auch ein FHEM-Modul für Python (oder umgedreht). Wahrscheinlich bekommst du in diesem Unterforum fundiertere Informationen.

[ch.eick]

Das ist ja lustig, wenn ich im Python Skript ein print() mache wird das dann direkt ins FHEM Log geschrieben.
Mit dem Fhem Modul im Python schreibe ich direkt in das Fhem Device, damit bekomme ich es jetzt erstmal synchronisiert und kann auf den Event reagieren.

[RalfRog]

Hallo DS_Starter

Mach schon seit ein paar Wochen nächtllich eine Mittelwertbildung mit dem Modul per avgtim.
=> Ein FHEM Update lief am 7.3 und seit 9.3 treten "plötzlich" PERL-Warnings auf.

Update erfolgte am 7.3 ca. 13 Uhr

Code Auswählen Erweitern

pi@raspi-2:~/log$ grep shutdown fhem-2023-10.log
2023.03.06 17:02:12.499 0: Server shutdown
2023.03.07 12:58:23.380 1: [b]update finished[/b], "shutdown restart" is needed to activate the changes.
2023.03.07 13:00:00.983 0: Server shutdown
2023.03.07 18:34:27.558 0: Server shutdown


Warnings erstmaling am 9.3 bei der Mittelwertbildung   
Im Editor fiel es erst gar nicht so auf. Bei einem grep bin ich dann über die mehrzeilige Info hinter eval gestolpert.

Code Auswählen Erweitern


2023.03.09 03:30:00.048 3: msg globalMsg: ID=1678329000.00468.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='Start Mittelwerte in DB schreiben'
2023.03.09 03:30:00.581 3: DbRep DBRep_avgtim_MT691_power - number of lines updated in >DBLogging<: 0
2023.03.09 03:30:00.583 3: DbRep DBRep_avgtim_MT691_power - number of lines inserted into >DBLogging<: 15
2023.03.09 03:30:00.625 3: DbRep DBRep_avgtim_MT691_power - execute command after averageValue: 'set DBRep_avgtim_power averageValue writeToDBSingleStart'
2023.03.09 03:30:00.781 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
2023.03.09 03:30:00.784 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0wOF8wMCMzODcyLjIzNDQ0NDQ0NDQ0IzIwMjMtMDMtM................$
2023.03.09 03:30:00.790 1: PERL WARNING: Use of uninitialized value $val1 in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3658.
2023.03.09 03:30:00.792 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0wOF8wMCMzODcyLjIzNDQ0NDQ0NDQ0IzIwMjMtMDMtMDhfMDB8MjAyMy0wMy0wOF8wMSM................$
2023.03.09 03:30:01.214 3: DbRep DBRep_avgtim_power - number of lines updated in >DBLogging<: 0
2023.03.09 03:30:01.215 3: DbRep DBRep_avgtim_power - number of lines inserted into >DBLogging<: 9
2023.03.09 03:30:01.259 3: DbRep DBRep_avgtim_power - execute command after averageValue: 'set DBRep_avgtim_total_power averageValue writeToDBSingleStart'
2023.03.09 03:30:01.995 3: DbRep DBRep_avgtim_total_power - number of lines updated in >DBLogging<: 0
2023.03.09 03:30:01.997 3: DbRep DBRep_avgtim_total_power - number of lines inserted into >DBLogging<: 24
2023.03.09 03:30:02.048 3: DbRep DBRep_avgtim_total_power - execute command after averageValue: 'set DBRep_avgtim_unit changeValue old="%" new={"($VALUE,$UNIT) = ($VALUE,"W")"}'
2023.03.09 03:30:02.388 3: DbRep DBRep_avgtim_unit - execute command after changeval: 'msg push -1 [DBRep_avgtim_total_power:state] taegliche Chain abgearbeitet fuer Mittelwerte Plug:power 3EM:tot$
2023.03.09 03:30:02.442 3: msg globalMsg: ID=1678329002.39269.1 TYPE=push ROUTE=teleBot STATUS=OK PRIORITY=-1(Low) TITLE='' MSG='done taegliche Chain abgearbeitet fuer Mittelwerte Plug:power 3EM:t$
2023.03.09 03:30:02.459 3: DbRep DBRep_avgtim_unit - VALUE changed in "fhem" - old: "%", new: "($VALUE,$UNIT) = ($VALUE,"W")", number: 48


Ob die Werte in der Datenbank in Ordnung sind habe ich nicht geprüft. Der DBRep_avgtim_MT691_power macht Probleme die beiden DBRep_avgtim_power & DBRep_avgtim_total_power laufen durch.

Die beiden eval-Zeilen in voller Länge:

Code Auswählen Erweitern


2023.03.09 03:30:00.784 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0wOF8wMCMzODcyLjIzNDQ0NDQ0NDQ0IzIwMjMtMDMtMDhfMDB8MjAyMy0wMy0wOF8wMSMxNjc5NC4wNiMyMDIzLTAzLTA4XzAxfDIwMjMtMDMtMDhfMDIjMTQ4OTYuNTk2NjY2NjY2NyMyMDIzLTAzLTA4XzAyfDIwMjMtMDMtMDhfMDMjNjkwMC4xMDMzMzMzMzMzMyMyMDIzLTAzLTA4XzAzfDIwMjMtMDMtMDhfMDQjMTg1NC42NTQ0NDQ0NDQ0NCMyMDIzLTAzLTA4XzA0fDIwMjMtMDMtMDhfMDUjMTg1OC41OTc3Nzc3Nzc3OCMyMDIzLTAzLTA4XzA1fDIwMjMtMDMtMDhfMDYjMzguNTcjMjAyMy0wMy0wOF8wNnwyMDIzLTAzLTA4XzA3I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8wN3wyMDIzLTAzLTA4XzA4I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8wOHwyMDIzLTAzLTA4XzA5IzkuMTY2NjY2NjY2NjY2NjcjMjAyMy0wMy0wOF8wOXwyMDIzLTAzLTA4XzEwI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMHwyMDIzLTAzLTA4XzExI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMXwyMDIzLTAzLTA4XzEyI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMnwyMDIzLTAzLTA4XzEzI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xM3wyMDIzLTAzLTA4XzE0I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNHwyMDIzLTAzLTA4XzE1I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNXwyMDIzLTAzLTA4XzE2I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNnwyMDIzLTAzLTA4XzE3IzguMTc5MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xN3wyMDIzLTAzLTA4XzE4IzYuNDA0MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xOHwyMDIzLTAzLTA4XzE5IzcuMTc5MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xOXwyMDIzLTAzLTA4XzIwIzEuNDkxMzg4ODg4ODg4ODkjMjAyMy0wMy0wOF8yMHwyMDIzLTAzLTA4XzIxIzAuOTI1IzIwMjMtMDMtMDhfMjF8MjAyMy0wMy0wOF8yMiMxMi4xMDUjMjAyMy0wMy0wOF8yMnwyMDIzLTAzLTA4XzIzIzcuNTU1NDMyMDY0NDYyMzUjMjAyMy0wMy0wOF8yM3w=|TVFUVDJfRVNQXzI=|MT691_power|0.295909,0.395488|15||')}
2023.03.09 03:30:00.792 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0wOF8wMCMzODcyLjIzNDQ0NDQ0NDQ0IzIwMjMtMDMtMDhfMDB8MjAyMy0wMy0wOF8wMSMxNjc5NC4wNiMyMDIzLTAzLTA4XzAxfDIwMjMtMDMtMDhfMDIjMTQ4OTYuNTk2NjY2NjY2NyMyMDIzLTAzLTA4XzAyfDIwMjMtMDMtMDhfMDMjNjkwMC4xMDMzMzMzMzMzMyMyMDIzLTAzLTA4XzAzfDIwMjMtMDMtMDhfMDQjMTg1NC42NTQ0NDQ0NDQ0NCMyMDIzLTAzLTA4XzA0fDIwMjMtMDMtMDhfMDUjMTg1OC41OTc3Nzc3Nzc3OCMyMDIzLTAzLTA4XzA1fDIwMjMtMDMtMDhfMDYjMzguNTcjMjAyMy0wMy0wOF8wNnwyMDIzLTAzLTA4XzA3I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8wN3wyMDIzLTAzLTA4XzA4I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8wOHwyMDIzLTAzLTA4XzA5IzkuMTY2NjY2NjY2NjY2NjcjMjAyMy0wMy0wOF8wOXwyMDIzLTAzLTA4XzEwI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMHwyMDIzLTAzLTA4XzExI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMXwyMDIzLTAzLTA4XzEyI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xMnwyMDIzLTAzLTA4XzEzI2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xM3wyMDIzLTAzLTA4XzE0I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNHwyMDIzLTAzLTA4XzE1I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNXwyMDIzLTAzLTA4XzE2I2luc3VmZmljaWVudCB2YWx1ZXMjMjAyMy0wMy0wOF8xNnwyMDIzLTAzLTA4XzE3IzguMTc5MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xN3wyMDIzLTAzLTA4XzE4IzYuNDA0MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xOHwyMDIzLTAzLTA4XzE5IzcuMTc5MTY2NjY2NjY2NjcjMjAyMy0wMy0wOF8xOXwyMDIzLTAzLTA4XzIwIzEuNDkxMzg4ODg4ODg4ODkjMjAyMy0wMy0wOF8yMHwyMDIzLTAzLTA4XzIxIzAuOTI1IzIwMjMtMDMtMDhfMjF8MjAyMy0wMy0wOF8yMiMxMi4xMDUjMjAyMy0wMy0wOF8yMnwyMDIzLTAzLTA4XzIzIzcuNTU1NDMyMDY0NDYyMzUjMjAyMy0wMy0wOF8yM3w=|TVFUVDJfRVNQXzI=|MT691_power|0.295909,0.395488|15||')}


Gruß Ralf

[alkazaa]

Moin Ralf,
die perl warning

Code Auswählen Erweitern

Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694
hängt offensichtlich mit der von mir 'verbrochenen' Änderung des gewichteten Mittelwertalgorithmus zusammen (s. ab Beitrag #1849). Dort wird durch ein 'peek-back-in-time' versucht, den letzten Messwert VOR Begin des eigentlichen Mittelwert-Zeitraums zu ermitteln. Beim schnellen Blick über den Code fiel mir jetzt auf, dass $to undefiniert bleibt, wenn kein voriger Wert gefunden wird. Die for-Schleife ab Zeile 3670 (in der $to erstmals definiert wird) wird dann gar nicht durchlaufen. Alles weitere sind dann evtl. Folgefehler.

Ich versuche mal, das zu simulieren (und den bug zu korrigieren). Aber DS_Starter wird vermutlich schneller sein.

Gruss
Franz

[RalfRog]

Ok dazu passt vermutlich, dass am 10. kein Fehler kam um dann am 11. wieder aufzutreten.

Muss gleich nochmal schauen, ob das identisch war oder etwas anderes angemeckert.

Gruß Ralf

Edit 14.3 9.20 Uhr

Ne ist das gleiche wie oben ($to in subtraction und $val1 in concatenation):

Code Auswählen Erweitern

2023.03.11 03:30:00.609 3: DbRep DBRep_avgtim_MT691_power - execute command after averageValue: 'set DBRep_avgtim_power averageValue writeToDBSingleStart'
2023.03.11 03:30:00.755 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
2023.03.11 03:30:00.758 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0xMF8wMCMxNS40MjI1MzUyMTEyNjc2IzIwMjMtMDMtMTBfMDB8MjAyMy0wMy0xMF8wMSMxMC4zNTA1NTU1NTU1NTU2IzIwMjMtMDMtMTBfMDF8MjAyMy0wMy0xMF8wMiMzLjU4MzMzMzMzMzMzMzMzIzIwMjMtMDMtMTBfMDJ8MjAyMy0wMy0xMF8wMyMxNDg5My45NDY2NjY2NjY3IzIwMjMtMDMtMTBfMDN8MjAyMy0wMy0xMF8wNCMxNDM1MS4zOTY2NjY2NjY3IzIwMjMtMDMtMTBfMDR8MjAyMy0wMy0xMF8wNSM2MjM1LjgxMzMzMzMzMzMzIzIwMjMtMDMtMTBfMDV8MjAyMy0wMy0xMF8wNiM0MS40MjY2NjY2NjY2NjY3IzIwMjMtMDMtMTBfMDZ8MjAyMy0wMy0xMF8wNyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDd8MjAyMy0wMy0xMF8wOCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDh8MjAyMy0wMy0xMF8wOSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDl8MjAyMy0wMy0xMF8xMCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTB8MjAyMy0wMy0xMF8xMSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTF8MjAyMy0wMy0xMF8xMiNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTJ8MjAyMy0wMy0xMF8xMyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTN8MjAyMy0wMy0xMF8xNCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTR8MjAyMy0wMy0xMF8xNSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTV8MjAyMy0wMy0xMF8xNiNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTZ8MjAyMy0wMy0xMF8xNyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTd8MjAyMy0wMy0xMF8xOCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTh8MjAyMy0wMy0xMF8xOSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTl8MjAyMy0wMy0xMF8yMCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMjB8MjAyMy0wMy0xMF8yMSMxMS42NDU4MzMzMzMzMzMzIzIwMjMtMDMtMTBfMjF8MjAyMy0wMy0xMF8yMiM2LjI3MDgzMzMzMzMzMzMzIzIwMjMtMDMtMTBfMjJ8MjAyMy0wMy0xMF8yMyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMjN8|TVFUVDJfRVNQXzI=|MT691_power|0.244824,0.342877|9||')}
2023.03.11 03:30:00.764 1: PERL WARNING: Use of uninitialized value $val1 in concatenation (.) or string at ./FHEM/93_DbRep.pm line 3658.
2023.03.11 03:30:00.766 3: eval: {DbRep_avervalDone('DBRep_avgtim_MT691_power||MjAyMy0wMy0xMF8wMCMxNS40MjI1MzUyMTEyNjc2IzIwMjMtMDMtMTBfMDB8MjAyMy0wMy0xMF8wMSMxMC4zNTA1NTU1NTU1NTU2IzIwMjMtMDMtMTBfMDF8MjAyMy0wMy0xMF8wMiMzLjU4MzMzMzMzMzMzMzMzIzIwMjMtMDMtMTBfMDJ8MjAyMy0wMy0xMF8wMyMxNDg5My45NDY2NjY2NjY3IzIwMjMtMDMtMTBfMDN8MjAyMy0wMy0xMF8wNCMxNDM1MS4zOTY2NjY2NjY3IzIwMjMtMDMtMTBfMDR8MjAyMy0wMy0xMF8wNSM2MjM1LjgxMzMzMzMzMzMzIzIwMjMtMDMtMTBfMDV8MjAyMy0wMy0xMF8wNiM0MS40MjY2NjY2NjY2NjY3IzIwMjMtMDMtMTBfMDZ8MjAyMy0wMy0xMF8wNyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDd8MjAyMy0wMy0xMF8wOCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDh8MjAyMy0wMy0xMF8wOSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMDl8MjAyMy0wMy0xMF8xMCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTB8MjAyMy0wMy0xMF8xMSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTF8MjAyMy0wMy0xMF8xMiNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTJ8MjAyMy0wMy0xMF8xMyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTN8MjAyMy0wMy0xMF8xNCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTR8MjAyMy0wMy0xMF8xNSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTV8MjAyMy0wMy0xMF8xNiNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTZ8MjAyMy0wMy0xMF8xNyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTd8MjAyMy0wMy0xMF8xOCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTh8MjAyMy0wMy0xMF8xOSNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMTl8MjAyMy0wMy0xMF8yMCNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMjB8MjAyMy0wMy0xMF8yMSMxMS42NDU4MzMzMzMzMzMzIzIwMjMtMDMtMTBfMjF8MjAyMy0wMy0xMF8yMiM2LjI3MDgzMzMzMzMzMzMzIzIwMjMtMDMtMTBfMjJ8MjAyMy0wMy0xMF8yMyNpbnN1ZmZpY2llbnQgdmFsdWVzIzIwMjMtMDMtMTBfMjN8|TVFUVDJfRVNQXzI=|MT691_power|0.244824,0.342877|9||')}
2023.03.11 03:30:01.108 3: DbRep DBRep_avgtim_power - number of lines updated in >DBLogging<: 0

[alkazaa]

Das allein

Beim schnellen Blick über den Code fiel mir jetzt auf, dass $to undefiniert bleibt, wenn kein voriger Wert gefunden wird. Die for-Schleife ab Zeile 3670 (in der $to erstmals definiert wird) wird dann gar nicht durchlaufen.

war's nicht.

Aber wenn ich weder im gesamten Mittelungszeitraum, noch in dem 'peek-back' Zeitraum irgendwelche Daten habe, kann ich die zwei perl-warnings reproduzieren.

Gruß Franz

[DS_Starter]

Hallo zusammen,

ich schaue heute oder morgen mal danach.
War bei mir auch schon aufgefallen, hatte aber bisher noch keine Zeit.
Hatte mich intensiv mit dem Einbau Solarbatterie befasst. 

Grüße,
Heiko

[RalfRog]

Hi
Weiss nicht ob es Sinn macht... oder zufällig in den letzten paar Wochen vor dem 8.3 geklappt hat.

Der Fehler ist erstmalig am 8.3 aufgetreten (lt. den Logs seit Januar 2023). Hab das Archiv mal gerade durchgegrept. Und diese Mittelwertchain läuft seit 14. Januar.
FHEM Updates am 7.3 & 12.1 (nur DBRep/DBLog Update mit spätem Restart 6 Stunden später) & 14.1 (vermutlich die Version mit dem neuen Mittelwertcode).

Code Auswählen Erweitern

pi@raspi-2:/opt/fhem/log $ grep "subtraction" fhem-2023-*
fhem-2023-10.log:2023.03.08 03:30:01.044 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-10.log:2023.03.09 03:30:00.781 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-10.log:2023.03.10 03:30:01.106 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-10.log:2023.03.11 03:30:00.755 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-10.log:2023.03.12 03:30:00.266 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-10.log:2023.03.12 03:30:00.861 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-11.log:2023.03.13 03:30:00.764 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-11.log:2023.03.14 03:30:00.268 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.
fhem-2023-11.log:2023.03.14 03:30:00.734 1: PERL WARNING: Use of uninitialized value $to in subtraction (-) at ./FHEM/93_DbRep.pm line 3694.

Muss mich hinsichtlich der Aussage oben korrigieren. Liegt eventuell ja an den Daten die da gemittelt werden und manchmal nicht zum Fehler führen.
=> die Meldung kommt z.B. für die Variable $to ab 8.3
=> es sind alle drei  avgtim betroffen mit den Readings "DBRep_avgtim_MT691_power" & "DBRep_avgtim_power" & "DBRep_avgtim_total_power".
=> das geloggte "eval" ist beim "DBRep_avgtim_MT691_power" besonders lang und daher auffällig.

Klingt aus meiner naiven Sicht danach, dass es Codeteile nach dem 14.1 sind.

[alkazaa]

Von den Daten her passt es: Am 22.1. ist die neue Routine "sub _DbRep_avgTimeWeightMean" im SVN vom contrib Verzeichnis in das FHEM Verzeichnis übernommen worden. Seit Deinem update vom 7.3. benutzt Du sie dann bei Dir.

Aber wie gesagt: ich kann die beiden perl-warnings (mit meinen Daten)  bei mir nur provozieren, wenn ich erwinge, dass im betrachteten Zeitraum KEINE Daten vorliegen. Allerdings musste ich dazu aggregation=minute und das Zeitfenster (timestamp_begin und timestamp_end) sehr kurz wählen und auch im code die peek-back Zeit auf wenige Sekunden einstellen.

Wie ist den bei Dir aggregation eingestellt, und wieviele Daten liegen zwischen timestamp_begin und timestamp_end?

-Franz

[RalfRog]

Hi ich lass mal im ersten Step Lists etc. weg.

Zu den Fragen, das ist bei allen drei gleich:
=> "aggregation  hour"
=> "timestamp_begin  previous_day_begin"    "timestamp_end  previous_day_end"
       dazwischen am 13.3:
       40 Werte für 1)  / 230 Werte für 2) / 740 Werte für 3)


Daten der readings

• HitchiLesekopf am Zähler (Nachtstromheizung) per ESP mit TASMOTA und MQTT, Daten schickt der ESP alle 300 Sekunden sowie ein einschränkendes "DbLogInclude MT691_power:120
  Werte kommen wenn der Stromversorger per Rundsteuerempfänger nachts einschaltet alle 300 Sekunden . Sowie tagsüber ggfs. durch kleine Leistungen der Steuerelektronik, können dann aber ggfs. nur 2 Werte in der Stunde sein, oder auch keine.
• Shelly PlugS am Balkonkraftwerk mit dem Reading "power"; Daten über Shelly_Monitor 2 bis etwa 6 Minuten
  nachts keine Daten (max. alle 120 Sekunden per DbLogInclude  power:120)
  
• Shelly 3EM am Zähler mit dem Reading "total_power";  Daten im 2 Minutenraster auch nachts (aufgrund attribut interval 120)

Edit:
Ich häng als Textdatei mal die relevanten Daten an: Log und 3) mit avgtwm_hour_MT691_power   vom 13. 

Edit2:
Irgendwie sieht es so aus, dass die Mittelwertberechnung durch ist und die Zeilen in der Datenbank eingefügt sind.
Die Warnings und der eval-Eintrag kommt erst wenn es um das nächste Kommando der Chain geht "execute command after averageValue: 'set DBRep_avgtim_power averageValue writeToDBSingleStart'"

[alkazaa]

Irgendwie sieht es so aus, dass die Mittelwertberechnung durch ist und die Zeilen in der Datenbank eingefügt sind.
Die Warnings und der eval-Eintrag kommt erst wenn es um das nächste Kommando der Chain geht "execute command after averageValue: 'set DBRep_avgtim_power averageValue writeToDBSingleStart'"

Das sieht für mich danach aus, dass beim zweiten 'averageValue' der chain die Datenbank noch mit dem Rückschreiben der Ergebnisse des ersten Teils beschäftigt ist. Bei den ganzen DB Aktivitäten in 93_DbRep und 93_DbLog wurde zuletzt einiges geändert (z.B. asynchrone Prozesse eingeführt), was der Grund dafür sein könnte dass Du den Effekt erst jetzt beobachtest. DS_Starter kann das sicher im Detail erklären, falls meine Vermutung stimmt.

Als pragmatiche Lösung würde ich mal testen, die chain zeitlich zu entzerren, z.B. mit  "execute command after averageValue: 'define chain_delay at +00:05:00 set DBRep_avgtim_power averageValue writeToDBSingleStart'"

Statt der hier gewählten 5 Minuten als delay würde vermutlich auch schon 1 Minute reichen.

Gruss
Franz