Arbeitsweise der neueren Zähler

Einklappen
X
 
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
  • Jan W.
    Lox Guru
    • 30.08.2015
    • 1343

    Arbeitsweise der neueren Zähler

    Im vergangenen Jahr habe ich meine Stromzähler in Loxone bei der Installation der PV-Anlage auf das neuere Format umgebaut, d.h. die neuen Bausteine eingerichtet, die sowohl Leistungsdaten z.B. momentane Verbräuche und nette Statistiken mit Summen für Tag, Monat, Jahr und Lebensdauer anzeigen.

    Um aussagekräftige Statistiken für die vorherigen Jahre ohne PV mit diesem und Folgejahren mit PV zu erhalten, plane ich die alten Statistikdaten in das neue Format zu konvertieren. Das Binarformat ist mittlerweile entschlüsselt und es gibt ein Tool, den LoxStatEditor, siehe https://github.com/mr-manuel/Loxone_...tEdit/releases welches über etliche Jahre durch viele User weiterentwickelt wurde. Vielen Dank an dieser Stelle an alle, die dabei mitgewirkt haben! Ich hatte zwar anfangs ein paar Probleme mit dem Editor, insbesondere mit dem 29. Feb und der Performance, aber mittlerweile läuft er gut.

    Ich bin nicht der Erste, der Statistiken konvertieren möchte, siehe z.B. https://www.loxforum.com/forum/faqs-...563#post416563, aber habe das "Problem" dass die alten Statistiken in einem anderen Intervall gespeichert wurden. Für ein paar Monate in 2024 habe ich beide Statistiken, aber keine Formel finden können, um die Leistungsdaten zu konvertieren.

    Altes Format:
    Alle Werte eines Zählers sind in der Datei mit dem Namen UUID.yyyyMM (pro Monat eine Datei mit Jahr und Monat als Endung) mit folgenden Einträgen:
    Zeitstempel, Value, Value2
    Wobei Value den absoluten Zählerstand und Value2 den Verbrauch angibt
    Die Zeitstempel der Einträge folgen dem im Zähler festgelegten Intervall, also alle 5, 10, 15, 30, oder 60 Minuten. Die Anzahl pro Monat ist also unterschiedlich.

    Neues Format:
    Die Werte eines Zählers sind auf zwei Dateien aufgeteilt. Eine Datei mit dem Namen UUID_1.yyyyMM (pro Monat eine Datei mit Jahr und Monat als Endung) mit:
    Zeitstempel, Value
    Wobei Value den Verbrauch angibt. Bei Bidirektionalen Zählern sind die Werte bei Einspeisung negativ, bei Verbrauch positiv.
    Die Zeitstempel der Einträge folgen dem im Zähler festgelegten Intervall für "Leistung / Durchfluss", also alle 5, 10, 15, 30, oder 60 Minuten. Die Anzahl pro Monat ist unterschiedlich.

    ​Die zweite Datei mit dem Namen UUID_2.yyyyMM (pro Monat eine Datei mit Jahr und Monat als Endung) mit:
    Zeitstempel, Value, Value 2
    Wobei Value den absoluten Zählerstand angibt. Value 2 gibt es nur bei Bidirektionalen Zählern und gibt dann den Zählerstand für Einspeisung an, während der erste der Verbrauch ist.
    ​Die Zeitstempel der Einträge folgen dem im Zähler festgelegten Intervall für "Zählerstand", also alle 5, 10, 15, 30, oder 60 Minuten. Die Anzahl pro Monat ist unterschiedlich.

    Ich hatte eigentlich erwartet, dass die Leistung, die aus den aktuellen Verbrauchswerten des Zählers über den Eingang "Pf" kommt, in den Statistiken gemittelt wird oder ein Durchschnittswert für das Intervall berechnet wird. Das ist aber wohl nicht der Fall, sondern es wird möglicherweise der zum Zeitpunkt des Zeitstempels anliegende Wert verwendet. Hat jemand hierzu Erfahrungswerte? Ich hatte überlegt, das Intervall insbesondere bei den Verbrauchswerten zu reduzieren.

    Da ich die Intervalle für die Zähler mehrmals geändert hatte, konnte ich feststellen, dass die App bzw. das Webinterface damit kein Problem hat. Das muss ich aber noch näher prüfen, denn ich hatte bisher nur das Intervall für die Leistung geändert. Gibt es dazu schon Erfahrungswerte?

    Was ich noch herausgefunden habe: wenn man Zähler in der Config umbenennt, bleibt (logischerweise) die UUID gleich, aber die Description der Datei, die relativ weit am Anfang in den Binärdaten steht, wird anscheinend beim Anlegen der jeweiligen Datei des Monats vom Miniserver eingetragen und somit sieht man im LoxStatEdit diesen Namen erst in der Datei für den Folgemonat. Ich habe jetzt mal ein paar Testzähler eingerichtet, um festzustellen, wie die Verbrauchswerte aufgezeichnet werden.
    Miniserver v14.5.12.7, 2x Ext., 2x Relay Ext., 2x Dimmer Ext., DMX Ext., 1-Wire Ext., Gira KNX Tastsensor 3 Komfort, Gira KNX Präsenzmelder, Fenster- und Türkontakte, Loxone Regen- und Windsensor, Gira Dual Q Rauchmelder vernetzt, 1x Relais-Modul
    Loxberry: SmartMeter, MS Backup, CamConnect, Weather4Lox
    Lüftung: Helios KWL EC 370W ET mit Modbus TCP - via Pico-C
    Heizung: Stiebel Eltron WPF 5 cool (Sole-Wasser WP) mit ISG, FB-Heizung mit 18 Kreisen, Erdsonde - via modbus/TCP
    Node-RED: IKEA Tradfri
  • <Andreas>
    LoxBus Spammer
    • 07.03.2023
    • 279

    #2
    Sehr interessant, ich denke Loxone hat es auf mehrere Daten aufgeteilt, damit die SD nicht so belastet wird

    ​​​​​Wahrscheinlich wäre es aber besser auf eine zeitbasierte Datenbank zu setzen

    Kommentar


    • Jan W.
      Jan W. kommentierte
      Kommentar bearbeiten
      Ich denke der Grund ist der, dass man jetzt für Leistung / Durchfluss und Zählerstände unterschiedliche Intervalle festlegen kann. Das kann in so einer einfachen "DB" effizient nur realisiert werden, wenn die unterschiedlichen Arten in zwei Dateien gespeichert werden.

      Der MS (insbesondere Gen 1) wäre wahrscheinlich mit einem Dienst für eine zeitbasierte DB überfordert. Sinnvoll sind solche DBs vor allem, um laufend eingehende Meldungen zu speichern und bei zeitbasierten Filtern effizient die DB durchsuchen zu können. Mit den Zeitstempeln zu jedem Wert kann die App mit wenig Aufwand kurze Ausfallzeiten (Downtimes des MS) und fehlende Werte ausgleichen. Da die über FTP gelesenen Statistikdateien einen gewissen Zeitverzug zeigen, wird wahrscheinlich nicht jeder Wert direkt auf die SD-Karte geschrieben und beim Client gecached um die Belastung zu reduzieren.
  • Jan W.
    Lox Guru
    • 30.08.2015
    • 1343

    #3
    Ich habe ein Test aufgesetzt, um die folgende Frage zu beantworten: Sind die Uhrzeiten (Zeitstempel) in den Statistikdateien für die Zähler in "UTC" oder "Local MS" und gibt es einen Unterschied?

    Klicke auf die Grafik für eine vergrößerte Ansicht

Name: Bildschirmfoto 2025-01-14 um 12.39.46.png
Ansichten: 150
Größe: 33,7 KB
ID: 452491
    Ich habe dazu einen Zähler mit altem Typ (Verbrauchszähler) und einen mit neuem Typ aufgesetzt und Beiden mit dem gleichen Input für "absolute Meter Reading" verknüpft. Minuten seit Mitternacht sind ideal, um meine Vermutung zu bestätigen oder zu widerlegen. Die Eingänge "Pf" ist leer, d.h. eine momentane Leistung/Durchfluss sehe ich in der App nicht, aber das ist egal.

    In der App sehe ich die aktuellen Zählerstände und die sind gleich bei beiden Zählern. Der Zählerstand um 12 Uhr lokaler Zeit mit ca. 720 habe ich mir mit dem LoxStatEdit in den Statistikdateien angesehen.

    Testzähler NEU: 14.01.2025 11:00:00 719,000, Zeitstempel auf Byte-Ebene (mit Hex-Editor): 30 3c 2a 1e = 506084400
    Testzähler ALT: 14.01.2025 12:00:00 719,000, Zeitstempel auf Byte-Ebene (mit Hex-Editor): 40 4a 2a 1e = 506088000

    Ich nehme an, dass "Minuten seit Mitternacht" sich immer auf die aktuelle Zeit (in der Zeitzone des MS) bezieht und nicht in UTC. Das passt (fast) zum Wert, denn 12h*60min=720.

    Was aber auffällt ist, dass dieser Wert beim neuen Zähler mit Zeitstempel 11 Uhr und beim alten mit 12 Uhr eingetragen wird!

    Ich weiß, dass alle Zeitstempel auf dem 01.01.2009 als "Nullpunkt" basieren und die Sekunden zählen. Lt. einem Online-Kalulator entspricht 506084400 dem 14.01.2025 um 11 Uhr und 506088000 entspricht 12 Uhr. Der von mir verwendete Kalkulator kennt keine Zeitzonen. Bisher war ich davon ausgegangen, dass die "Loxone Zeit" die Sekunden seit 01.01.2009 UTC zählt, aber mit den o.a. Werten zählt sie die Sekunden ab 01.01.2009 00:00 Uhr MEZ (oder sollte ich sagen "Kollerschlag"-Zeit ) als Nullpunkt. In der Config finde ich nur <v.u> als Zeit seit ... ohne Zeitzone. Ich sehe die aktuelle Zeit und z.B. bei MQTT Inputs (sendAtTimeLox) und die Zahl passt zu den Sekunden in meiner Zeitzone. Wenn ich mir die Funktion im Loxberry epoch2lox ansehe, die ein UNIX Zeit ($epoche) in Loxone Zeit umrechnet, dann finde ich meine Erkenntnis z.T. bestätigt, denn dort wird $offset = 1230764400; verwendet, was der Differenz der UNIX Zeit ab 01.01.1070 00:00 Uhr UTC bis zum 01.01.2009 00:00 Uhr UTC in Sekunden - 3600 entspricht. Was ich aber nicht verstehe ist der letzte Teil der Formel:
    Code:
    loxepoche = $epoche - $offset + $tz_delta - 3600;
    $tz_delta rechnet das Delta zu UTC für den aktuellen Zeitpunkt (now) aus. Sofern $tz_delta = 3600 ist, passt es für mich. Bei Umschaltung auf Sommerzeit springt das Delta von +3600 auf +7200 Sekunden. Nach der Formel macht die Zeit dann ein Sprung um +3601 Sekunden und bei der Umschaltung auf Winterzeit läuft die Uhr rückwärts. Das verstehe ich nicht. In einer anderen Zeitzone muss es dann auch andere Zeitstempel geben, aber mit nur einem produktiven MS kann ich das nicht überprüfen. Nach meinem Verständnis müsste der Zeitstempel in allen Zonen gleich bleiben, nur die Darstellung ist in unterschiedlichen Zeitzonen unterschiedlich. Tico : Wie sehen die Zeitstempel bei Dir in Australien aus?

    Der Code in LoxStatEdit rechnet einfach
    Code:
    DateTime TimestampBias = new DateTime(2009, 1, 1);
    DateTime Timestamp = TimestampBias.AddSeconds(TimestampOffset);
    ​
    wobei TimestampOffset der Zeitstempel aus der Stats Datei ist. Das ist auch ohne C# Kenntnisse recht einfach zu verstehen, denn zum Basiswert werden einfach die Sekunden addiert.

    Da ich den LoxStatEditor um eine Funktion zum Konvertieren der Statistikdaten meiner alten Zählertypen hinzufügen möchte, war die o.a. Erkenntnis für mich neu und ich schließe daraus, dass Loxone vielleicht Probleme mit Umrechnungen etc. bekam und daher die Zeitstempel in den Statistikdateien mit neuem Format von "MEZ" auf "UTC" geändert hat.
    Miniserver v14.5.12.7, 2x Ext., 2x Relay Ext., 2x Dimmer Ext., DMX Ext., 1-Wire Ext., Gira KNX Tastsensor 3 Komfort, Gira KNX Präsenzmelder, Fenster- und Türkontakte, Loxone Regen- und Windsensor, Gira Dual Q Rauchmelder vernetzt, 1x Relais-Modul
    Loxberry: SmartMeter, MS Backup, CamConnect, Weather4Lox
    Lüftung: Helios KWL EC 370W ET mit Modbus TCP - via Pico-C
    Heizung: Stiebel Eltron WPF 5 cool (Sole-Wasser WP) mit ISG, FB-Heizung mit 18 Kreisen, Erdsonde - via modbus/TCP
    Node-RED: IKEA Tradfri

    Kommentar

    Lädt...