Loxone Statistik Editor

**stefb** · 22.12.2024, 13:33

Hi liebe Lox-Community,

vorab herzlichen Dank für die Entwicklung von LoxStatEdit!
Leider habe ich einen Statistik-Ausreisser bei den ich schon lange mal korrigieren wollte.

Wenn ich das alles richtig interpretiere, muss ich vermutlich eine ordentliche Anzahl an Einträgen korrigieren, oder liege ich falsch?
Der Statistik-Fehler trat am 12.12.2023 zwischen 16-17 Uhr auf:

Schaue ich mir den Bereich im LoxStat an, ist vermutlich das Problem dass sich die Value im besagten Zeitraum von 4.052 auf 3.804 verkleinert?

Das würde bedeuten, ich müsste ab Zeile 281 alle Einträge einzeln nach unten anpassen (geht bis 744)?
Das ganze dann gleich zwei mal, da die Werte am besagten Tag 2x zu finden sind. Bzw. dann wohl auch in den Folgemonaten usw...?!
Im markierten Bereich 202312 & 2.202312. Die Einträge in 1.202312 sind hingegen alle mit Value 0.:

Vielen Dank für jede Hilfe und allen frohe Weihnachen!
Stef

**stefb** · 22.12.2024, 20:59

mein Problem ist scheinbar dass ich das Tool noch nicht im Detail kenne. Wie lassen sich mehrere Einträge gleichzeitig ändern? Das würde mir voll und ganz ausreichen - sofern sich evtl. auch eine Logik integrieren lässt? also zb. value + x

**stefb** · 22.12.2024, 23:54

okay, ich war blind wie Nachbars Lumpi! Alles geklärt damit 😉 Sorry und Danke

**Jan W.** · 05.01.2025, 00:34

Nach vielen Jahren wollte ich den Statistik Editor verwenden, um eine Statistik für den Stromverbrauch in diesem Jahr anzupassen. Leider kommt direkt nach dem Verbinden mit dem Miniserver folgende Fehlermeldung:

Das erste Datumsformat (MMM dd HH:mm) sollte eigentlich auf "Feb 29 23:00" passen, aber ich vermute ein Problem mit dem Schaltjahr, so dass der 29.02. nur mit Jahresangabe korrekt erkannt bzw. umgewandelt werden kann.

Es wundert mich etwas, dass der Fehler noch nicht bemerkt wurde, denn das Programm ist schon fast 10 Jahre alt und Schaltjahre kommen nicht sooo selten vor. Mein Miniserver Gen.1 läuft auf Version 14.5.2.12.

Mit Wireshark habe ich festgestellt, dass das Problem beim Lesen des Verzeichnisses "/stats" auftritt. Hier ein Ausschnitt aus dem Output vom Lesen des Verzeichnisses per FTP:

Code:

...
-rw-rw-rw-  1 0 0  69200 Nov 08 21:01 0c123ac9-00d0-e90a-ffffefc088fafadd.201706
-rw-rw-rw-  1 0 0  17360 Dec 01 00:30 11b877f0-02c5-4c1e-ffffbaa9891076ff.201811
-rw-rw-rw-  1 0 0 668224 Feb 29 23:00 169b87a0-0326-ef37-ffffefc088fafadd.202402
-rw-rw-rw-  1 0 0 708528 Nov 08 21:01 0c542aec-00ad-c9fc-ffff3b137504e77e.201703
...

In der Datei MsFileInfo.cs habe ich den zugehörigen Code gefunden (ab Zeile 40):

Code:

string pattern = @"[-rwx]{10}\s+[0-9]+\s+[0-9]+\s+[0-9]+\s+([0-9]+)\s+([A-Za-z]{3}\s+[0-9]{1,2}\s+[0-9:]+)\s+([0-9a-z_\-\.]+)";
var result = Regex.Match(line, pattern);

if (result.Success)
{
  var groups = result.Groups;
  int.TryParse(groups[1].Value, out int size);

  string dateString = Regex.Replace(groups[2].Value, @"\s+", " ");
  string[] formats = { "MMM dd HH:mm", "MMM dd yyyy", "MMM d HH:mm", "MMM d yyyy" };

  if (!DateTime.TryParseExact(dateString, formats, CultureInfo.InvariantCulture, DateTimeStyles.None, out dateTime))
  {
    // Handle the case where none of the formats match
    MessageBox.Show($"The date \"{dateString}\" could not be matched with one of the following formats:\n{string.Join("\n", formats)}", "Error", MessageBoxButtons.OK,        MessageBoxIcon.Error);

    return null;
  }

  var fileName = groups[3].Value;

Leider habe ich keine Info für die Erstellung des Programmes aus dem Quellcode gefunden und als Mac-User kenne ich mit Programmierung unter Windows mit C# ich nicht gut aus. Mit Programmierung generell kenne ich mich aber schon ganz gut aus und daher ein Vorschlag für Anpassungen, so dass das Datum mit Jahreszahl gelesen und dann hoffentlich korrekt erkannt wird.

Ich weiß leider nicht, ob alle Dateien dem o.a. Schema entsprechen (mit . und YYYYMM am Ende). In den Format-Strings sind sowohl Angaben mit Uhrzeit oder mit Jahreszahl enthalten. Eigentlich würde ich von einem Linux erwarten, dass für Dateien aus 2024 (bei Ausführung in 2025) die Jahreszahl statt der Uhrzeit ausgegeben wird, aber das war bei mir nicht der Fall. Zumindest im Verzeichnis "/stats" hatten alle Dateien einen Namen mit . und YYYYMM am Ende.

Code:

string pattern = @"[-rwx]{10}\s+[0-9]+\s+[0-9]+\s+[0-9]+\s+([0-9]+)\s+([A-Za-z]{3}\s+[0-9]{1,2}\s+[0-9:]+)\s+([0-9a-z_\-]+.)([0-9]{4})([0-9]{2})";
var result = Regex.Match(line, pattern);

if (result.Success)
{
  var groups = result.Groups;
  int.TryParse(groups[1].Value, out int size);

  DateTime dateTime;
  if (groups[2].Value.Contains(":")) {
    string dateString = groups[4].Value + " " + Regex.Replace(groups[2].Value, @"\s+", " ");
  } else {
    string dateString = Regex.Replace(groups[2].Value, @"\s+", " ");
  }
  string[] formats = { "yyyy MMM dd HH:mm", "MMM dd yyyy", "yyyy MMM d HH:mm", "MMM d yyyy" };

  if (!DateTime.TryParseExact(dateString, formats, CultureInfo.InvariantCulture, DateTimeStyles.None, out dateTime))
  {
    // Handle the case where none of the formats match
    MessageBox.Show($"The date \"{dateString}\" could not be matched with one of the following formats:\n{string.Join("\n", formats)}", "Error", MessageBoxButtons.OK,        MessageBoxIcon.Error);

    return null;
  }

  var fileName = groups[3].Value + groups[4].Value + groups[5].Value;

Falls MightyLox nicht mitliest oder keine Zeit hat, hat vielleicht jemand anderes einen Tipp für mich, wie man die Programmierumgebung für das Programm aufbaut.

**Jan W.** · 05.01.2025, 21:46

Ich habe mir Visual Studio 2022, .net 4.8 und das Paket für C# installiert und die o.a. Anpassungen im Editor durchgeführt. Der Scope für "dateString" musste noch geändert werden, aber ansonsten passte es und ich konnte etliche Fehler in meinen Statistiken korrigieren. Der Zeitstempel wird anscheinend nur für den Vergleich der Datei vom MS und FS (dem Windows PC) verwendet, also um festzustellen, welche neuer ist. Entscheidend ist wohl die Endung ".YYYYMM" im Dateinamen, die mit dem Zeitstempel in den Einträgen zusammenpassen muss.

Vielen Dank an mr-manuel und allen anderen, die an dem Tool mitgewirkt haben. Es hat etwas gedauert, bis ich das Kontextmenü zum einfachen Ändern mehrerer Wert gefunden hatte, daher hier ein Screenshot, falls jemand dies noch nicht gefunden hat:

Die Funktion "Calculate selected" war für mich sehr hilfreich, um viele Werte um ein Delta anzupassen, siehe #254.1. Das Problem trat mit einem Zähler für PV-Ertrag auf, er "relativ" arbeitet, so dass einmalig falsche (zu hohe) Werte beim Eingang "Pf" alle Zählerwerte ab dem Zeitpunkt verfälscht haben.

Als weiteres Problem hatte ich kurzzeitig falschen Einheiten bei einigen Zählern eingestellt. Statt kW bzw. kWh kamen die Werte falsch in W bzw. Wh an, so dass ich die Werte alle um "v * 0,001" korrigieren musste. Das ging mit der Funktion sehr einfach und schnell!

Leider läuft der Editor in meiner Windows VM unter VMware (auf Mac mini mit Intel CPU, 3GHz, 6-Core i5) sehr langsam. Die Zeilen bauen sich im Fenster so schnell auf, wie bei einem Terminal mit 2400 Baud. Es dauert also ca. 5-10 Sekunden, bis sich die Tabelle aufgebaut hat und erst dann kann ich Werte ändern. Bei jedem Scrollen das Fensters muss ich ebenfalls wieder warten. Andere Windows Programme laufen gut und schnell. Auch die Tabelle im Hauptfenster hat das Problem. Das Problem tritt schon mit der fertigen .exe Datei aus Version 1.0.5.1 auf. Daher konnte ich die Funktionen "Calculate downwards" nicht testen, weil das Fenster mit "LoxStatsEditor is working for you" eingefroren ist. Eine Beschreibung für "Fill and fix entries" habe ich ebenfalls noch nicht finden können.

Insgesamt hat das Tool aber funktioniert und ich konnte die Ausreißer beheben. Mit dem Umbau im letzten Jahr hatte ich die neuen Zähler in der Config verwendet. Jetzt versuche ich noch, die Werte aus den alten Zählern zu konvertieren. Wird ein Zählerwechsel eigentlich korrekt von Loxone verarbeitet? Ich hatte einen solchen in 2024 und die Statistiken sehen korrekt aus, obwohl die absoluten Zählerwerte von >20.000 auf 0 gingen.

**Jan W.** · 06.01.2025, 10:07

Hallo svethi,

ich habe die Antwort des Miniservers auf den FTP "LIST /stats directory" Befehl angehängt. Anscheinend verwendet mein Miniserver gar kein Jahr, sondern gibt nur den Monat und Tag aus. Vielleicht ist das aber bei FTP auch Standard? Ich habe mit FileZilla das Verzeichnis ausgelesen und alle Jahresangaben sind von 2024 und 2025. Das Jahr wird möglicherweise nur berechnet und das Vorjahr verwendet, wenn es kleiner ist, als der aktuelle Tag? Bsp. alles vom 01.01. bis 06.01. (heute) ist 2025, alles davor ist 2024. Ich werde zu FTP und Zeitstempel noch mal recherchieren.

FileZilla kann das Datum nicht am Dateinamen erkennen, so dass mein Fix nicht passt. Der 29.02. ist sicherlich ein Sonderfall, der nur selten vorkommt. Andere Dateien von Februar aus meinem /stats Verzeichnis hatten den Zeitstempel vom 28. Da ich die Datei mit dem Zeitstempel vom 29.02. nicht geändert hatte, gibt es die noch. Filezilla zeigt diese Datei mit dem 01.03.2024 an! Meine Vermutung ist, dass es sich um ein FTP "Problem" handelt. Wireshark zeigt, dass der gleiche "LIST /stats Befehl" von FileZilla verwendet wird und das Jahr daher nicht mit übertragen wird. Der 29.02. wird bei der Anzeige offenbar automatisch auf den 01.03. korrigiert.

Wg. der Geschwindigkeit: ja, das ist merkwürdig und wahrscheinlich ein Einzel-/Sonderfall, der mit meiner virtuellen Umgebung zusammenhängt. Andere Programme laufen aber flott, so dass es kein genereller Engpass mit CPU oder Speicher sein kann. VMware ist weit verbreitet und daher halte ich ein Bug in der Software für unwahrscheinlicher. Ich werde das noch mal analysieren.

Angehängte Dateien

Output LIST stats directory.txt (129,6 KB, 1 Hit)

**Jan W.** · 06.01.2025, 14:14

Zum Problem mit dem 29. Februar: Im FTP Protokoll ist das Datumsformat leider nicht festgelegt ("varies"). Eine gute Zusammenfassung bietet https://stackoverflow.com/questions/...p-list-command

Das Problem ist nicht unbekannt und trat in der Praxis schon mit diversen FTP Clients auf, siehe z.B. https://trac.filezilla-project.org/ticket/7885

Da ich anscheinend der Erste bin, bei dem das Problem auftritt, würde mich für ein PR interessieren, in welchem Format der Miniserver die Datumsangabe sendet und ob das bei allen Versionen und Generationen gleich ist?

Über ein FTP Tool, wie FileZilla kann man das gut überprüfen: FTP Verbindung zum MS herstellen und den Inhalt des /stats Verzeichnisses lesen. Wenn alle Datumsangaben nur das Jahr 2024 und 2025 enthalten, aber der MS schon älter ist, dann fehlt wahrscheinlich das Jahr bei der Ausgabe vom MS und wird vom FTP Client ergänzt.

Man kann auch parallel zum o.a. FTP Client das Tool Wireshark starten und als Filter ftp-data angeben. Dann mit Klick auf eines der Antwortpakete den Menüpunkt "Follow - TCP Stream" wählen. Wenn der MS schon länger als gut ein Jahr läuft, dann sollte es Dateien aus 2023 und früheren Jahren geben, die bei der Übermittlung des Verzeichnisses mit Jahreszahl vom MS ausgegeben werden.

Wer Dateien mit Jahresangabe von 2023 oder früher findet, möchte bitte einen kurzen Kommentar mit Version und Generation des MS schicken.

**Jan W.** · 07.01.2025, 20:06

Da das Programm für mich fast unbedienbar war, habe ich nach der Ursache gesucht. Da die CPU Last bei der Ausführung gering blieb und andere Programme wie Loxone Config flüssig liefen, war ein generelles Problem mit knappen Ressoucen eher unwahrscheinlich. Es betraf nur die Anzeige der Tabelle im Hauptfenster (die Liste der Statistikdateien) und bei der Datenbearbeitung (Edit einer Statistik). Das Problem hing aber nicht die Anzahl der Einträge in der Liste insgesamt ab, sondern nur mit den momentan angezeigten Einträgen. Das Scollen, insbesondere beim Festhalten des Scrollbalkens war fast unmöglich.

Damit man sich das besser vorstellen kann, habe ich ein Video erstellt: https://github.com/Jan21493/Loxone_L...tatsEditor.mp4

Dank Google und etwas Erfahrung war die wahrscheinliche Ursache schnell eingegrenzt: .Net Programme, die "DataGridView" verwenden, sollten bei langsamer Anzeige die Option "DoubleBuffering" einschalten, siehe https://stackoverflow.com/questions/...redraw-so-slow

Der entsprechende Code war zwar nicht ganz fertig, aber relativ schnell erstellt und zu den beiden Dateien MiniserverForm.cs und LoxStatFileForm.cs hinzugefügt. Der Unterschied in der Anzeige ist zumindest für mich wirklich krass. Jetzt läuft das Programm flüssig und scrollen funktioniert ohne eine merkbare Verzögerung bei der Anzeige. Zum Testen habe ich die .exe Datei zur Verfügung gestellt: https://github.com/Jan21493/Loxone_L...oxStatEdit.exe Ich könnte mir vorstellen, dass man vielleicht auch bei einem "native" Windows beim Scrollen in den Listen einen Unterschied merkt.

svethi und mr-manuel : Ich habe den geänderten Code in Github hochgeladen, aber kein PR erstellt, da ich kein .net Profi bin. Wenn Ihr meint, dass die Anpassungen für alle sinnvoll sind, dann nehmt die bitte mit auf:

Comparing mr-manuel:master...Jan21493:master · mr-manuel/Loxone_LoxStatEdit

https://github.com/mr-manuel/Loxone_LoxStatEdit/compare/master...Jan21493:Loxone_LoxStatEdit:master

This is an editor that allows you to edit Loxone Statistics. Many use it to remove peaks. - Comparing mr-manuel:master...Jan21493:master · mr-manuel/Loxone_LoxStatEdit

**svethi** · 07.01.2025, 21:31

Jan W. Hmm, jetzt hast Du noch was gefunden.
ich habe das Datehandling jetzt geändert. Wenn Du den 29.Feb 2024 noch in der Liste hast, könntest Du mal die neue Version probieren.
Diese habe ich hier mal angehängt. Musst nur txt durch exe ersetzen. Deine Änderung ist noch nicht drin.
Muss ich mir mal ansehen. Dass das was bei mir bringt, glaube ich nicht, da das eh flüssig geht ;-)

Angehängte Dateien

LoxStatEdit.txt (1,48 MB, 2x aufgerufen)

**Jan W.** · 07.01.2025, 23:57

Hi svethi,
ich habe die Version getestet und es gibt einen Unterschied: die Liste wird aufgebaut, aber beim Scrollen bekam ich den folgenden Fehler, als die markierte Zeile angezeigt wurde (nach Anzeige der "7" / Dateiname), daher ist der Rest noch nicht aktualisiert worden. Da das Programm natürlich noch genau so langsam ist, konnte ich die Zeile genau erkennen:

In der vorherigen Version wurde direkt nach dem Lesen des Verzeichnisses ein Fehler gemeldet und das Hauptfenster gar nicht angezeigt. Mit dem Fix von mir tritt der Fehler nicht auf, so dass ich den Dateinamen sehe. Der Dateiname ist schon etwas merkwürdig und die beiden Dateien mit kurzen Namen scheinen fehlerhafte bzw. unvollständige doppelte Logs zu sein. Die Einträge werde ich noch korrigieren, aber es könnte ja sein, dass ein nicht 100%ig konformer Name auch mal bei einem anderen Anwender auftritt. Vielleicht kommt der Fehler in Deiner Version durch den komplizierten Regex Ausdruck?

Da ich in meiner Config die Stromzähler im letzten Jahr auf das neue Format umgestellt habe, möchte ich versuchen, die alten Zählerstände in das neue Format zu konvertieren. Ich habe es noch nicht getestet, aber dachte, dass man die Ist-Stände relativ einfach alle 1h in die Datei mit "ID-neuer-Zähler_2.YYYYDD" übernehmen kann. Bei den gemittelten Werten für das Aufzeichnungsintervall für Durchfluss/Leistung (aus dem "Pf" Eingang) die ich im 30min Intervall vom neuen und im 10min Intervall vom alten habe (aus dem gleichen Monat), konnte ich noch keine Formel ableiten, wie die Mittelwerte berechnet werden. Ich bin mir nicht sicher, ob ich einfach die Werte von "value 2" aus dem alten Zähler 1:1 in die Datei mit "ID-neuer-Zähler_1.YYYYDD" als "value" übernehmen kann. Da ich das Aufzeichnungsintervall für Durchfluss/Leistung bei dem neuen Zähler zwischendurch geändert hatte, konnte ich feststellen, dass die App wohl kein Problem damit hat, wenn dies in verschiedenen Monaten unterschiedlich ist.

**svethi** · In den letzten 4 Wochen

Moin Jan W.
ja, da sind wohl falsche Dateien drin. Ich habe das Programm ja nicht geschrieben und wenn ich mr-manuel richtig verstanden habe, er auch nicht. Nein, an meinem RegEx liegt es nicht, ich hole mir nur zusätzlich die Datumsangaben in einzelnen Strings raus. Hier auch Uhrzeit und Jahr getrennt. Aber klar, der Dateiname wird ja nicht auf Plausibilität geprüft. Hier könnte man zur Sicherheit den Dateinamen noch prüfen. Zum Einen hatte ich schon gesehen, dass im org regex a-z erlaubt ist. Da sollte eigentlich a-f reichen und dann könnte man auf eine Mindestlänge prüfen. Dadurch dass das alles UUID‘s sein sollten, müsste die Länge eigentlich fest sein. Des Weiteren könnte man prüfen ob am Ende „.######“ ist. Das hattest Du ja quasi in Deiner Version ja schon drin.

Wie greifst Du denn auf Deine VM zu? Ich mache das auch remote per mstsc. Habe da keinerlei delay. Dein Video erinnert mich an den VNC (JPG) Bildaufbau wenn man über Internet zugreift.

**Jan W.** · In den letzten 4 Wochen

Moin svethi,
zur Prüfung der Namen auf Plausibilität: man könnte die Namen auf UUID's mit passender Endung ".YYYYMM" prüfen, aber dann sollten andere Dateien ignoriert werden und keine Exception auswerfen. Alternativ einfach nur irgendwas + Endung nehmen. Mein "Quick-Fix" das Jahr aus der Endung zu nehmen, ist nicht korrekt. Bei meinem MS wird IMMER der Monat und Jahr ausgegeben, nie das Jahr. Insofern gibt es mit dem 29. Feb. und den Datumsfunktionen von C# in Windows immer ein Fehler, wenn kein Schaltjahr vorliegt und das Jahr einfach ergänzt wird. Um das korrekt zu lösen, müsste man folgende Berechnung vornehmen:

wenn kein Jahr in der Datumsangabe enthalten ist: nehme "2024" (weil Schaltjahr) und rechne "Datum" - 1.1.2024 = Tag innerhalb des Jahres. Rechne das Datum als Zahl für den 1.1. dieses Jahres und addiere den Tag
rechne dann das Datum als Zahl für den aktuellen Tag des aktuellen Jahres aus (heute)
Wenn die Datumszahl aus 2. größer ist, als der aus 1., dann ist die Datei aus diesem Jahr anzunehmen. Rechne dann den Tag aus 1. zum 1.1. dieses Jahres hinzu
Wenn die Bedingung in 3. nicht erfüllt ist, dann muss die Datei aus dem Vorjahr (oder vorherigen Jahren) stammen. Rechne dann den Tag aus 1. zum 1.1. des Vorjahres aus

Die Datumsangaben als Zahl aus 3. und 4. können mit den Zeitangaben auf der lokalen Seite verglichen werden, um festzustellen, welche Datei neuer ist. Mit dieser Logik kann man vermeiden, dass Dateien mit einer Datumsangabe vom 29. Feb. eine Exception erzeugen. Ähnlich wird es z.B. im Code von Filezilla gemacht.

Wie greifst Du denn auf Deine VM zu? Ich mache das auch remote per mstsc. Habe da keinerlei delay. Dein Video erinnert mich an den VNC (JPG) Bildaufbau wenn man über Internet zugreift.

Ich habe die aktuelle VMware Fusion Version 13.6.2, die für privat kostenlos zur Verfügung steht. Alles mit Standardeinstellungen und Windows 11 in der VM. Mit dem "DoubleBuffering" erfolgt das Scollen in Echtzeit, d.h. man kann den Scrollbalken schnell nach oben oder unten ziehen und alle Einträge sind aktuell. Die Performance im Video hast Du ja gesehen.

**svethi** · In den letzten 4 Wochen

Jan W. so, Dateiprüfung quick&dirty 37 Zeichen und .yyyymm. Und auch das doublebuffered. Allerdings im Form-load wie ich das gelesen habe … ich habe das mal mit mstsc probiert, da gab es bei mir auch keine Probleme. Habe die Abfrage aber mit eingebaut.

Dann versuche mal.

Hat zwar bei mir jetzt funktioniert, aber habe da noch nen Fehler im RegEX … vielleicht prüfe ich auch mal noch die UUID … mal sehen.

Angehängte Dateien

LoxStatEdit.txt (1,48 MB, 1 Hit)

**Jan W.** · In den letzten 4 Wochen

Code:

Dateiprüfung quick&dirty 37 Zeichen und .yyyymm

Jetzt werden leider alle alten Statistiken ohne "_1" und "_2" nicht mehr erkannt (bei mir immer noch ca. 80% der Stats). Die Prüfung findet anscheinend nicht im lokalen Verzeichnis statt, daher werden die von mir bereits heruntergeladenen Dateien als "FS only" angezeigt und ein Download schlägt mit einer Exception fehl. Persönlich fand ich die vorherige "lasche" Überprüfung besser, um zukünftig vielleicht auch eine "Delete" Funktion in das Programm einzufügen. Dann braucht man zum Bereinigen nicht mehr parallel Filezilla und das Finden kryptischer UUIDs ist frickelig.

Und auch das doublebuffered. Allerdings im Form-load wie ich das gelesen habe

Du hast sicherlich mehr Ahnung, wo das Feature im Code aktiviert werden muss. Die Performance bei mir ist super. Vielleicht hilft es auch anderen Usern. Schaden tut es meiner Meinung nach nicht.

Code:

Ich mache die Prüfung übrigens einfacher ;-). Wenn das parsen das Datum fehlschlägt, kann es nur ein 29.02. sein, da es alle anderen Daten jedes Jahr gibt. In diesem Fall nehme ich dann gleich schon das vorherige Jahr.

Ich finde es immer toll, wenn man Bedingungen einfacher formulieren kann. Bin mir aber nicht sicher, ob Dein Code noch in 2026 funktioniert, wenn die Datei mit dem 29. Feb nicht angefasst wird. Da muss ich noch mal drüber nachdenken.

Ich habe allerdings sofort eine Exception, wenn ich im Filter etwas eingebe, z.B. "Test". Vorher gab es diese nur bei Umlauten. Leider muss man das Programm immer neu starten, wenn eine Exception ausgeworfen wurde (zumindest bei mir). Das Löschen des Filters behebt das Problem nicht.

Code:

So, habe das jetzt auch mal nach git gepusht.

Hab Dein Repo gefunden, allerdings beim Test die oben von Dir zur Verfügung gestellte Version verwendet. Soll ich Dein Repo forken, falls ich einen Fehler im Code finde oder Dir das auf diesem Weg mitteilen?

**Jan W.** · In den letzten 4 Wochen

Das hat Loxone ja mal wieder hervorragend programmiert.

Da im RFC für FTP kein allgemein gültiges Format definiert wurde, kann der Hersteller des FTP Servers das Format selbst bestimmen. Es muss nur für Menschen lesbar sein. Im FTP Protokoll hat man später den Befehl 'mlst' (list remote path in a machine parsable form) ergänzt, den kann der MS aber nicht. Loxone gibt wohl per FTP IMMER das Datum im Format MMM dd HH:mm aus, was Du ja mit dem MSv2 bestätigt hast. Damit verliert man das genaue Jahr beim Download per FTP für den "modified" Zeitstempel und muss das aktuelle bzw. vorherige Jahr annehmen.

Der Code im LoxStatEditor wurde wohl von irgendwo genommen, wo die verschiedenen Formate bei Linux FTP Servern bereits enthalten waren. Schaden tut es ja nicht - vielleicht verwendet Loxone in zukünftigen Versionen eine Jahreszahl für ältere Dateien. Ich glaube nicht, dass man bei Loxone mit einem Feature-Request Gehör findet, aber vielleicht liest ja jemand von Loxone mit und gibt das weiter.

Ich habe jetzt auch mal die Config angeschmissen. Da sieht es im Grunde genauso aus wie beim FTP oder auch /dev/fslist/stats.

In der Config im Menü "SD-Karte verwalten" sehe ich die richtigen Zeitstempel, also auch mit älteren Jahren. Im Gegensatz zum LoxStatEditor verwendet Loxone Config bei der Übertragung als Protokoll Websockets und im Wireshark Dump konnte ich das bestätigen (alle Dateien mit richtigem Jahr und Uhrzeit). Intern verwendet der MS daher wohl richtige Zeitstempel für das Dateisystem, wahrscheinlich basierten auf 1.1.2009 = 0.

Ich habe den Programmcode in LoxStatEdit für "Upload" angesehen und festgestellt, dass der "modified" Zeitstempel beim Upload nicht mitgegeben wird. FTP übermittelt im Standard weder einen "modified", noch einen "created" Zeitstempel (es gibt dafür Erweiterungen, wie SITE UTIME ..., die wahrscheinlich vom MS nicht unterstützt werden). Der FTP Server im MS setzt daher wohl immer das Datum "now" (in UTC, s.u.) für empfangene Dateien.

Mittlerweile verstehe ich daher die hier das in diesem Beitrag von anderen Usern und von mir selbst beobachtete Verhalten, dass nach einem "Upload" die lokale Datei immer noch als neuer angesehen wird, weil die Zeitstempel nicht gleich sind. Die Empfehlung war, danach ein "Download" durchzuführen und dann passt es wieder.

Beim "Download" wird der aus dem FTP LIST Kommando berechnete Zeitstempel explizit als "Modified" Date in das Windows File System geschrieben. Nach einem 'Edit' - 'Upload' - 'Download' sehe ich daher, dass beide Dateien wieder gleich sind. Mit dem Workaround kann man gut leben und besser lösen kann man es gar nicht, weil der FTP Server im MS die dafür notwendigen erweiterten Befehle nicht unterstützt.

Wenn ich mir den "Modified" Zeitstempel im Windows Explorer anschaue, dann sehe ich als Datum "now -1h". Nach einem 'Edit' sehe ich 'now'. Ich schließe daraus, dass die Zeitstempel vom MS in UTC übermittelt werden, aber LoxStatEdit die lokale Zeitzone verwendet bzw. die Zeitzone in UTC im Programmcode nicht richtig mitgegeben wird.

Der 29.02. kommt bei Dir durch eine falsche Zeitzone. Dir wird der 29.02. 23:00 angegeben. In MEZ ist das der 01.03. 0:00 so wie bei mir auch.

Ich stimme mit Dir überein, dass der Grund in der Zeitzone liegt, aber nicht, dass meine falsch ist. Ja, ich habe eine Zeitzone definiert (MEZ), aber die weicht 1h von UTC ab (MEZ=UTC+1 und im Sommer sogar mit MESZ=UTC+2), die nach meiner Meinung intern im MS verwendet wird. So sieht die Einstellung bei mir aus, wenn ich in Loxone Config mit dem MS verbunden bin:

Die Uhrzeit über NTP zu synchronisieren ist best-Practice und Berlin = MEZ eben meine Zeitzone. Wenn man hier keine Zeitzone hat, bzw. UTC nutzt, dann entspricht die angezeigte Zeit 1:1 den Zeitstempeln. Wenn ich bei mir eine Statistikdatei von 2025-01 (also von heute) herunterlade, dann sehe ich immer einen Verzug von über 1h bei den vorhandenen Zeitstempeln, was die Vermutung bestätigt, dass intern UTC verwendet wird. Die Vermutung habe ich überprüft, indem ich die Statistik für den Stromverbrauch für heute anschaue (Wert um 11:35 bzw. 12:35):

und mit der Ausgabe der Loxone App auf dem iPhone oder Webinterface auf meinem Mac vergleiche:

In LoxStatEdit wird der 11:35 (UTC) angezeigt und in der App die lokale Zeit, was sinnvoll ist. Da ein Smartphone i.d.R. immer mit passender Zeitzone konfiguriert ist, wäre es interessant, ob das bei Dir ebenfalls passt.

Da die in LoxStatEdit im "Edit" Fenster angezeigten Datumsangaben offenbar in UTC sind und der Monat immer mit dem 01. des Monats um 00:00 beginnt und dem 01. des Folgemonats endet, erfolgt der letzte Schreibvorgang genau zum 01. des Folgemonats um 00:00. Alle neueren Zählerbausteine mit "_#" haben genau diesen Zeitstempel in meiner in # 261 geposteten Liste.

Alle anderen (bis auf bearbeitete Dateien) haben einen Zeitstempel mit ca. 23:00 Uhr und im Sommer (März bis Sept) sogar mit 22:00 Uhr. Die einzige Erklärung (außer einem Bug) ist für mich die, dass die alten Zähler NICHT UTC Time in den Zeitstempeln verwenden, sondern die lokale Zeit. Das wäre zumindest eine schlüssige Erklärung, dass in den Monatswechseln für unterschiedliche Bausteine unterschiedliche Zeitangaben verwendet werden. Das würde aber auch bedeuten, dass die Zeitangaben in allen Bausteinen außer den neuen Zählern (z.B. mit Haken bei Statistik) nicht in UTC, sondern lokaler Zeit vorliegen. Oh mann, das ist ja viel komplizierter als ich dachte und bei Loxone leider gar nicht dokumentiert. Vielleicht habe ich auch irgendwo einen Denkfehler?

Ein kleiner "Schönheitsfehler" bleibt in LoxStatEdit, dass das Programm den Zeitstempel um 1h bei 'Edit' - 'Upload' - 'Download' zurücksetzt. Das liegt wohl daran, dass der von LoxStatEdit an das Windows Filesystem in UTC und nicht lokaler Zeitzone erfolgt, d.h. der Zeitstempel, der im Windows Explorer angezeigt wird, nicht ganz korrekt ist. Den Fehler hat man nicht, wenn der Windows PC für UTC konfiguriert ist.

Mein Fazit (falls andere User mitlesen und es bis hierher geschafft haben ): Die fehlenden Jahreszahlen bei der Verwendung von FTP sind zwar blöd, aber für den Einsatzzweck "Bearbeiten von Statistiken" nicht so wichtig. Der LoxStatEditor (FTP Client) muss das aktuelle bzw. vorherige Jahr annehmen, weil nicht mehr Infos übermittelt werden. Das tut das Programm mit dem kürzlich von Dir (Svethi) eingefügtem Code. In Windows haben dann leider alle heruntergeladenen Dateien ein Änderungsdatum von "now" bis max 1 Jahr zurück.

In der 'offiziellen' Version 1.0.5.1 (ohne den Fix) müsste man nach einem Download aller Dateien, auch Dateien mit zukünftigen "Modified" Zeitstempeln sehen.

Das Jahr aus dem Dateinamen zu ziehen (mein erst Quick-Fix) ist nicht gut, weil dann z.B. geänderte Dateien, die zum MS hochgeladen wurden, in LoxStatEdit fälschlicherweise als "2018" angenommen werden und die lokal evtl. noch vorhandene Datei immer als neuer angezeigt wird. Nach einem Download hätte man wieder lokal "2018" im Zeitstempel und wundert sich vielleicht, wenn man in Windows Dateien anhand des Datums vergleicht.

Um die korrekten Jahreszahlen aller Dateien auf dem MS im stats Verzeichnis zu behalten, empfehle ich ein Backup über Loxone Config (Menü 'SD-Karte', 'Sicherung erstellen'), wo die Jahreszahlen alle korrekt übermittelt werden.