seltsame Aussetzer im Plot

[AlexMuc]

Hallo zusammen,
bei mehreren Plots sind seit einigen Tage Lücken. Irgendwas hab ich irgendwo kaputt gemacht.

Der Inhalt des Logs sieht wie folgt aus:

Code Auswählen Erweitern

2022-06-30_23:59:30 ED300L energy_Netz: 000000.000 92.888 2022 Juni
2022-07-31_23:59:30 ED300L energy_Netz: 000000.000 117.405 2022 Juli
2022-08-31_23:59:30 ED300L energy_Netz: 000000.000 107.583 2022 August
2022-09-30_23:59:30 ED300L energy_Netz: 000000.000 101.386 2022 September
2022-10-31_23:59:30 ED300L energy_Netz: 216278.062 90.49 2022 Oktober
2022-11-30_23:59:30 ED300L energy_Netz: 216357.362 79.3 2022 November
2022-12-31_23:59:30 ED300L energy_Netz: 216466.19 108.828 2022 Dezember
2023-01-31_23:59:30 ED300L energy_Netz: 216567.844 100.654 2023 Januar
2023-02-28_23:59:30 ED300L energy_Netz: 216636.287 68.443 2023 Februar
2023-03-31_23:59:30 ED300L energy_Netz: 216713.86 77.573 2023 März
2023-04-30_23:59:30 ED300L energy_Netz: 216779.823 65.963 2023 April
2023-05-31_23:59:30 ED300L energy_Netz: 216861.811 81.988 2023 Mai
2023-06-30_23:59:30 ED300L energy_Netz: 216957.919 96.108 2023 Juni
2023-07-31_23:59:30 ED300L energy_Netz: 217052.171 95.252 2023 Juli
2023-08-31_23:59:30 ED300L energy_Netz: 217140.509 87.338 2023 August
2023-09-30_23:59:30 ED300L energy_Netz: 217228.477 87.968 2023 September
2023-10-31_23:59:30 ED300L energy_Netz: 217310.892 82.415 2023 Oktober
2023-11-30_23:59:30 ED300L energy_Netz: 217375.052 64.16 2023 November
2023-12-31_23:59:30 ED300L energy_Netz: 21741.291 56.239 2023 Dezember
2024-01-31_23:59:30 ED300L energy_Netz: 217484.115 52.825 2024 Januar
2024-02-29_23:59:30 ED300L energy_Netz: 217530.75 46.635 2024 Februar
Das sieht für mich, sofern ich keine Tomaten auf den Augen habe, erstmal gut aus.
Im Plot habe ich allerdings lediglich Balken für das Jahr 2022. 2023 zeigt nur den April und 2024 hat nur im Februar einen Balken (bei fixedrange year).
Wenn ich mir mit "show preprocessed input" die Werte für die 3 Jahre anzeigen lasse, dann stimmen die bei 2022 (da ist ja auch der Plot ok). In 2023 kommt nur eine Zeile für den Aril und 2024 eine für Februar (passend zum Plot, aber da fehlen halt Monate
In der Konsole habe ich nun für
2022

Code Auswählen Erweitern

get FileLog_Strom_Usage_Monthly CURRENT INT 2022-01-01_00:00:00 2022-12-31_23:59:59 eingegeben und es kommen alle 7 Zeilen für 2022.
Die Suche für 2023 mit

Code Auswählen Erweitern

get FileLog_Strom_Usage_Monthly CURRENT INT 2023-01-01_00:00:00 2023-12-31_23:59:59 ergibt dagegen nichts (im Plot war wenigstens der April drin) und für
2024 mit

Code Auswählen Erweitern

get FileLog_Strom_Usage_Monthly CURRENT INT 2024-01-01_00:00:00 2024-12-31_23:59:59 wird auch nichts gefunden.

Ändere ich aber die Startzeit in 2023 und 2024 von 00:00:00 auf 00.00:01, so werden alle 12 Monate in 2023 bzw 2 in 2024 gefunden.

Diese Aussetzer treten noch in 2 anderen Plots auf und dort werden die fehlenden Zeilen ebenfalls gefunden, wenn ich in der Konsole die Startzeit auf :01 ändere. Irgendwo ist der Wurm drin.
In meiner Verzweiflung hab ich mir die Logdatei schon mit einem Hexeditor angeschaut, aber da ist nix auffälliges zu sehen. Und wenn da was wäre, warum funktioniert die Suche mit der um eine Sekunde veränderten Startzeit? Ich kapier es leider nicht. Hat wer eine Idee, wonach ich suchen muß?

das list vom SVG lautet

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        FileLog_Strom_Usage_Monthly:SVG_FileLog_Strom_Usage_Monthly_1:CURRENT
   FUUID      65ef6c9d-f33f-0381-05ba-31f612d4e58eb57c
   GPLOTFILE  SVG_FileLog_Strom_Usage_Monthly_1
   LOGDEVICE  FileLog_Strom_Usage_Monthly
   LOGFILE    CURRENT
   NAME       SVG_FileLog_Strom_Usage_Monthly_1
   NR         815
   STATE      initialized
   TYPE       SVG
   eventCount 1
Attributes:
   fixedrange year

das GPLOTFILE lautet

Code Auswählen Erweitern

# Created by FHEM/98_SVG.pm, 2024-03-12 13:10:16
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid ytics
set ylabel "kWh"
set y2label ""
set yrange [0:120]

#FileLog_Strom_Usage_Monthly 5:ED300L.energy_Netz\x3a::

plot "<IN>" using 1:2 axes x1y1 title 'Line 1' ls l0fill lw 1 with bars nur der April 2023 wie im Plot. Suche ich dagegen

Code Auswählen Erweitern

get FileLog_Strom_Usage_Monthly CURRENT INT 2023-01-01_00:00:[color=red]01[/color] 2023-12-31_23:59:59 so erhalte ich alle 12 Zeilen aus 2023


Update:
in der ersten Abfrage die Jahreszahlen ausgebessert

[betateilchen]

In der Konsole habe ich nun für 2022

Code Auswählen Erweitern

get FileLog_Strom_Usage_Monthly CURRENT INT 2023-01-01_00:00:00 2023-12-31_23:59:59
                                            ^^^^                ^^^^

eingegeben und es kommen alle 7 Zeilen für 2022.

schwer zu glauben...

Und wäre der Thread nicht im richtigen Unterforum zu SVG besser aufgehoben?

[AlexMuc]

Danke, hoch lebe Copy & Paste... Mal sehen, ob ich diesen Tippfehler noch wegputzen kann. Immerhin ist der Plot ausgerechnet da ja noch korrekt.

Wenn es bei den SVGs besser liegt, dann schieb ich es eben dort hin

[betateilchen]

Wenn es bei den SVGs besser liegt,

auf jeden Fall besser als in den Anfängerfragen 

Mich würde mal noch die Definition des FileLog-device interessieren. Sind das Jahreslogs?
Hast Du schonmal getestet, ob das Setzen des Attributes createGluedFile im FileLog das Verhalten ändert?

Grundsätzlich hättest Du solche Probleme wahrscheinlich nicht, wenn Du mit DbLog anstatt FileLog arbeiten würdest, insbesondere, wenn Du Daten aus so lange zurückliegenden Perioden brauchst.

[AlexMuc]

Also das ist momentan der komplette Inhalt der Logdatei. Mehr ist da noch nicht drin und da dort auch nur 14 Zeilen pro Jahr dazu kommen, dachte ich mir, das da eine Datei reicht
Daher sollten Abriße an Jahreswechseln eigentlich kein Problem darstellen. Die sollen ja, soweit ich das verstanden haben, durch createGluedFile verhindert werden. Und daher "nur eine Datei".

Da ich mich noch als Anfänger bezeichne, sind mir die reinen Textdateien noch lieber. Um in DbLog mal was nachzuschauen oder in ganz üblen Fällen ein paar Zeilen nachzutragen, braucht es doch SQL-Wissen. Das hab ich nun noch überhaupt nicht.

[AlexMuc]

So, hier noch die gewünschte Definition vom FileLog

Code Auswählen Erweitern

Internals:
   DEF        ./log/ED300L_Verbrauch.log ED300L:energy_Info:.*
   FD         81
   FUUID      65d0cbef-f33f-0381-ff4c-bb0a4909ce0a94f1
   NAME       FileLog_Strom_Usage_Monthly
   NOTIFYDEV  ED300L
   NR         775
   NTFY_ORDER 50-FileLog_Strom_Usage_Monthly
   REGEXP     ED300L:energy_Info:.*
   STATE      active
   TYPE       FileLog
   currentlogfile ./log/ED300L_Verbrauch.log
   eventCount 1
   logfile    ./log/ED300L_Verbrauch.log
   READINGS:
     2024-03-12 08:56:21   linesInTheFile  21
   pos:
Attributes:
   group      Strom_Monthly
   logtype    text:linesInTheFile
   room       0_Stromzähler,5_Stromzähler_Logs

[betateilchen]

oder in ganz üblen Fällen ein paar Zeilen nachzutragen, braucht es doch SQL-Wissen.

Braucht es nicht. Dafür gibt es in FHEM DbRep, um genau solche Aufgaben möglichst einfach zu lösen.

Zu Deinem Problem fällt mir spontan nichts ein. Ausser, dass ich es aus Erfahrung heraus tunlichst vermeide, Logwerte exakt um 00:00:00 zu schreiben.

Wenn es tatsächlich nur eine Datei ist, hilft createGluedFile nicht weiter.

[AlexMuc]

Danke,
für den Moment scheine ich einen Fix gefunden zu haben: ich lösche das File
Log Device und lege es mit den zuvor aus den Rawdaten kopierten Zeilen gleich wieder an... scheinbar ist irgendwo ein Cache aktiv den ich auf diese Weise aktualisiert oder gelöscht wird. Ist zumindest meine Vermutung.
Vielleicht hätte ich auch bei meiner Frage oben erwähnen sollen, das ich die Logs zu Beginn manuell mit nano um fehlende Daten ergänzt habe. Die mußte ich mit erst aus anderen Logs ,,besorgen". Vermutlich war das auch die Ursache, das dann der Cache, so es ihn gibt, verwirrt war.

Wenn es eine bessere Lösung gibt, um nach einer ,,Manipulation" des Logfiles ein ,,Update" anzustoßen, so wäre es gut zu wissen, wie das geht. Ansonsten muss ich mich doch irgendwann mit DbLog beschäftigen und hoffe, das mir dort nicht das gleiche Problem begegnen würde.