ich wollte meine ModbusZähler die ca. alle 10 sekunden abgerufen werden nun hinterlegen das direkt “Auf einen Wert pro fünf Minuten verdichtet “ - optional hab ich noch verdichtung nach einem Monat auf einen Wert pro Stunde.
die Variablen will reagregiert werden und die Masse an Werte verschwinden auf die 5min. Jedoch alle weitere Datenwerte dazwischen werden weiterhin reingeloggt.
Sieht dann so aus als würde er weiterhin zumindest minütlich verdichten.
Schau mal in die geloggten Werte, beispielsweise indem du im Diagramm auf CSV gehst. Es sollte prinzipiell bis zu ein Wert pro 5-Minuten-Fenster sein. In Ausnahmefällen können es zwei sein,das erkläre ich gleich.
Der Zeitstempel von dem Wert entspricht der ersten Änderung in dem Fenster und liegt nicht zwangsweise am Anfang. So kann es also sein, dass du einen Wert für 10:34:48 und einen für 10:35:17 hast. Die liegen zwar sehr nah beieinander, sind aber in unterschiedlichen Fenstern.
Zwei Werte können bei einer Zähleraggregation vorkommen, wenn der Zähler zurückspringt, da wir sonst technisch nicht sowohl den Verbrauch in der Zeitspanne als auch den neuen Ausgangswert darstellen können.
ja dachte ich auch das nur ein wert pro 5min enthalten sein sollte.
Siehe CSV Werte entspr. dem Graphen (PV Ertragwerte)
also ca. um 9:10-9:20 rum werde ich die Variable auf sofort Verdichten 5min gestellt haben, also werte davor passen dann damit, da durch die reagregation verdichtet wurden.
die 5min werte sind auch nachher vorhanden, aber müssten dann die minuten-Werte dann nicht automatisch auf die 5min Werte verdichtet werden?
Wenn ich im Archiv die variable manuell reagregiere sind wieder korrekt die verdichtete 5min Werte da, neue Datensätze werden dann aber wieder im minutentakt in die variable geschrieben.
Ich bin da auch gerade drüber gestolpert. Habe für mehrere Zählervariablen neu die direkte minütliche Aggregation aktiviert, sehe aber innerhalb einer Minute sehr oft zwei geloggte Werte. So ganz habe ich die Erklärung auch nicht verstanden, wann das vorkommen kann und wieso.
Noch eine Frage. Wann werden die Werte bei aktiver Verdichtung ins Archiv geschrieben? Ich mache relativ viele komplexe Berechnungen mit den Archivwerten und mir ist aufgefallen, dass ich seit Aktivierung der Verdichtung zu Sekunde 0 immer einen geloggten Wert mehr habe als vor Aktivierung der Funktion. Rufe ich die Archivfunktionen zu Sekunde 1 auf, also eine Sekunde später, ist der „zusätzliche“ Wert wieder weg, so wie es vor der Verdichtung auch bei Sekunde 0 der Fall war.
Ich habe die Verdichtung bisher nicht genutzt, aber langsam wurde es aufgrund der Masse an Daten mal Zeit und da bin ich jetzt eben über diese beiden Punkte gestolpert.
Folgendes Beispiel: Wir verdichten auf 5-Minuten-Werte. Um 10:59 steht der Zähler auf 100. Dann kommen im Laufe des nächsten 5-Minuten-Fensters folgende Werte rein:
11:01 130
11:02 150
11:03 20
11:04 50
Wenn das jetzt verdichtet wird, dann müssen zwei Informationen erhalten bleiben: Es wurden 80 Einheiten verbraucht (positive Delta) und am Ende des Fensters stand der Zähler auf 50. Und diese beiden Informationen können nicht mit einem einzigen Wert codiert werden, da brauchen wir zwei. Somit kommen wir verdichtet bei folgenden Werten an:
11:01 180 (die 80 Einheiten Verbrauch von den vorherigen 100 aus)
11:04 50 (Rücksprung auf Endwert des Fensters)
Während eines Verdichtungsfensters werden die Werte im Speicher gehalten, du kannst aber schon direkt darauf zugreifen. Neue Werte sollten aber nur kommen, wenn auch tatsächlich eine Variablenänderung passiert. Nach dem Fenster werden die Werte beim nächsten Schreibvorgang (je nach Spezialschalter alle paar Minuten) dann in die Dateien geschrieben.
Vielen Dank für die Erklärung!
Ich glaube jetzt kann ich es einigermaßen nachvollziehen. Wobei ich 180 in dem Beispiel dann glaube ich zu Zeit 11:02 geschrieben hätte, denn um 11:01 waren ja streng genommen noch keine 80 Einheiten verbraucht. Und bei der 50 würde doch die Information über das Delta von 20 nach 50 (30) verloren gehen oder geht ihr da implizit davon aus, dass der Zähler zwischenzeitlich wieder bei 0 Stand?
Mein anderes Problem mit dem Auslesen der Werte zu Sekunde 0 und Sekunde 1 scheint eine Race Condition zu sein, die jetzt zufällig seit Aktivierung der Verdichtung auftritt.
Ich lese von mehreren Variablen die aggregierten Werte aus. Starte ich zu Sekunde 0, ist für die eine Variable schon der aggregierte Wert für die gerade neu begonnenen Minute verfügbar, während er für die andere noch fehlt. Starte ich eine Sekunde später, sind beide neuen Werte verfügbar.
Ich vermute, dass die eine Variable jetzt aufgrund der aktiven Verdichtung “schneller gworden ist” als zuvor, sodass der Effekt jetzt erst auftritt. Vorher war vermutlich auch für die andere Variable zu Sekunde 0 der neue Wert noch nicht verfügbar.
Ich beobachte seit einer Weile ein merkwürdiges Verhalten, wo ich mittlerweile glaube, dass es mit der Verdichtung zusammenhängen könnte, bin mir aber nicht sicher. Das muss nicht unbedingt ein Fehler in der Verdichtung selbst sein, aber es scheint damit zusammenzuhängen.
Ich lesse ein paar Zähler per Modbus aus. Die Werte werden geloggt und direkt minütlich verdichtet. Vergleiche ich nun die aktuellen Variablenwerte mit den geloggten, so passen diese teilweise überhaupt nicht zusammen und dieser Fehler scheint über den Tag wie ein Sliding Window zu wandern. Ich habe die letzten Tage schon gedacht ich spinne, aber habe mir ein paar Screenshots gemacht und die geloggten Werte verändern sich von Zeit zu Zeit.
Konkret geht es darum, dass der eine Zähler zum Beispiel aktuell einen Stand von ca. 4500 liefert. Der Wert steht beim Aktualisieren auch so in der Variablen. Gucke ich mir die letzten geloggten Werte an, so passen diese auch zu den 4500 (etwas kleiner). Irgendwann kommt aber plötzlich ein Sprung bei den geloggten Werten und ab diesem Zeitpunkt (weiter zurück in die Vergangenheit) sind die Werte viel höher (ca. 7000). Gehe ich dann noch weiter zurück, liegen sie alle um die 7000 (wieder langsam kleiner werdend). Irgendwann mehrere Tage zurück bin ich dann plötzlich wieder bei Werten um die 4700 und sie nehmen dann wieder langsam ab. Also Sprünge irgendwo in der Größenordnung von 2000.
Dieser Fehler wandert aber. Als ich heute Morgen zum Beispiel geguckt habe, war der Sprung von 4500 auf 7000 irgendwo um 11 Uhr rum. Jetzt taucht der Sprung erst um 16:30 Uhr auf. Davor sind die Werte jetzt wieder im 4500er Bereich, obwohl sie heute Morgen schon gegen 11 Uhr deutlich höher waren.
Ich weiß, dass die Zähler ab und an einen fehlerhaften Wert liefern (negativ). Für solche Fälle habe ich ein Korrektur-Skript, das die geloggten Werte regelmäßig prüft und die Ausreißer aus dem Archiv löscht. Damit hatte ich auch noch nie Probleme. Das wende ich bei diversen Variablen an.
@Dr.Niels Nun habe ich die Vermutung, dass diese fehlerhaften Werte und meine nachträglichen Korrekturen sich irgendwie mit dem kontinuierlichen Verdichten in die Quere kommen und dadurch diese seltsamen Sprünge entstehen, die wandern. Kann das sein? Ich kann mir zwar noch nicht so ganz erklären, wie dabei plötzlich größere Zählerwerte raus kommen, aber wer weiß… Vielleicht muss ich die Korrekturen mal deaktivieren oder mitloggen, wann genau ein fehlerhafter Wert kam und wie dieser war.
Also an irgendwelchen Ausreißern scheint es wohl doch nicht zu liegen.
Der Fehler ist jetzt nach heute gewandert. Jetzt sind alle geloggten Werte von gestern im Bereich von 7000 und heute ist der Sprung auf 4500 um 10:20 Uhr.
Ich habe parallel mitgeloggt, ob zwischenzeitlich irgendwelche Ausreißer kamen, aber da war seit gestern nichts.
EDIT:
Ich habe das Verdichten für die Variablen jetzt mal testweise deaktiviert und gucke ob das Problem dann immer noch auftritt. Der Fehler ist jetzt wieder von heute Morgen auf jetzt “gewandert”.
Das Problem besteht für beide Zähler seit Anfang April. Ich bin mir allerdings nicht sicher, ob ich da erstmals die Verdichtung für die Variablen aktiviert habe. Was auch noch auffällig ist: Ich habe jeden Tag nur eine Handvoll geloggter Werte, obwohl sich die Zähler alle paar Sekunden ändern. Das heißt ich müsste am Ende des Tages bei minütlicher Verdichtung irgendwas um die 1440 Werte haben. Vor dem Auftreten des Problems Anfang April ist das auch so. Seitdem habe ich jeden Tag nur ein paar Werte und die passen auch alle nicht. Wenn ich mir die Variablen als Graph visualisieren lasse, stimmen die angezeigten Mengen überhaupt nicht.
Ich glaube ich kriege das nachträglich nicht mehr raus, wodurch die Probleme genau verursacht wurden. Seitdem ich die direkte Verdichtung wieder deaktiviert habe, gibt es keine Auffälligkeiten mehr bei den geloggten Werten. Irgendwelche Aureißer, die korrigiert werden mussten, gab es seitdem auch nicht. Vermutlich kam da mehreres zusammen und Hauptauslöser waren irgendwelche falschen Werte, die zwischendurch mal gekommen sind. Da haben dann mehrere Korrekturmechanismen gegriffen, die sich vermutlich mit der Verdichtung in die Quere gekommen sind.
Vielleicht fürs Verständnis ausgeholt wie die Verdichtung mit negativen Sprüngen umgeht. Für ein Intervall (bei dir also eine Minute) sind zwei Informationen wichtig: Wie viel wurde verbraucht? Und welcher Zählerstand war am Ende des Intervalls? Bei rein aufwärts gehenden Werten reicht dafür der letzte Wert des Intervalls aus, dieser beschreibt dann sowohl den Verbrauch im Vergleich zum letzten Wert vor dem Intervall als auch den letzten Wert. Falls es aber negative Sprünge gab, brauchen wir zwei Werte um beide Informationen darzustellen. Das ist einmal der letzte Wert des Intervalls, also der letzte Zählerstand, und davor ein Wert, welcher dem letzten Zählerstand minus dem Verbrauch in dem Intervall entspricht. Damit wird in dem Intervall der korrekte Verbrauch gewertet. Dieser vordere Wert muss aber überhaupt nichts mit einem tatsächlich mal gewesenem Zählerstand zu tun haben. Stell dir vor innerhalb der Minute springt der Zähler drei mal um je eine Einheit zurück, dann kommen beim Verrechnen Werte heraus, die der Zähler zwar nie direkt hatte, aber zum passenden Verbrauch führen.
Zurück zum eigentlichen Thema: Ich teile deine Vermutung, dass sich die verschiedenen Anpassungen da aushebeln. Die Verdichtung kommt vollständig bei einer Reaggregation, somit also potentiell nach deinen Anpassungen. Wenn du aber nur Werte herausnimmst, sehe ich gerade nicht wie die Verdichtung Änderungen vornimmt… Vielleicht kannst du ja in deinem Skript ein bisschen Logging einbauen? Dann könnte man sehen:
Welche Werte waren vor der Anpassung da?
Welche Werte wurden entfernt?
Und was steht nach der Reaggregation da drin?
Damit könnten wir dann weiter analysieren, was da schiefläuft und was wo angepasst werden müsste.
