Archivdaten sind nicht immer aufsteigend

IP-Symcon
1

Ich habe ein Skript, in dem ich mir den Gesamtstromverbrauch über viele Geräte ermittle.

Das Skript wird aufgerufen, wenn sich der Status oder die Leistung der Geräte ändert:

image
image1916×1715 574 KB

Das Ergebnis wird in die Variable #15864 geschrieben.

Nun passiert es zwar selten, aber es kommt vor, dass die Einträge in der Archivdatei nicht fortlaufend sind:

15864.csv

1692716824,238.55
1692716850,235.65999999999998
1692716874,235.93
1692716880,236.94833333333333
**1692716940**,237.45
1692716935,236.66
**1692716940**,236.486
1692717000,236.82133333333338
1692717060,236.41483333333339

Wie kann das passieren?

2

Hi,
sperrst Du das Script wenn ein Event aufgetreten ist? Ich kann mir vorstellen das es Probleme geben kann wenn X Events (fast) gleichzeitig ausgelöst werden. Ich würde es mit IPS_SemaphoreEnter gegen mehrfachen Aufruf schützen.

Ralf

3

Nein, ich sperre das Skript nicht.

Es kann ja immer mal vorkommen, dass eine Variable gleichzeitig von verschiedenen Stellen geschrieben wird.

Das sollte Symcon intern abgesichert sein.

4

Hi,
ich sehe das Problem nicht darin das die Variable von verschiedenen Stellen geschrieben wird sondern das dein Script vielleicht 20 Mal gleichzeitig laufen kann denn gerade der Stromverbrauch ändert sich ja ständig. Stichwort konkurrierende Zugriffe bei Multithreading.

Warum in diesem Fall überhaupt so viele Ereignisse? Warum nicht einfach Script im Sekundentakt ausführen und alles summieren?

Ralf

5

So oft läuft das Skript gar nicht. Wie man an den Archivdaten sieht, liegen da durchaus ein paar Sekunden immer dazwischen.

6

Werden die Archivdaten jetzt in dem Skript geschrieben oder ist dir das nur darüber aufgefallen? Prinzipiell sollte das Archiv aber natürlich die Werte korrekt sortieren, da hast du schon recht. Jetzt ist nur die Frage, was hier passiert…

7

Ja, das Skript schreibt den Wert.

Aber ich hatte übersehen, dass die minütliche Direktverdichtung eingestellt ist.:disappointed:

Da scheint dann auch wohl der Grund zu suchen zu sein. Denn dann sind in dem Beispiel alle nicht durch 60 teilbaren Zeitstempel verkehrt:

1692716824,238.55
1692716850,235.65999999999998
1692716874,235.93
1692716880,236.94833333333333
1692716940,237.45
1692716935,236.66
1692716940,236.486
1692717000,236.82133333333338
1692717060,236.41483333333339

8

Wobei das bei einer Reaggregation eigentlich glattgezogen werden müsste… Wie häufig passiert das denn? Kannst du mir dein Skript bereitstellen und ich lasse es einfach 10 mal laufen oder so?

9

Ich habe gerade nachgeschaut und in der Tat, die „ungeraden“ Zeitstempel sind verschwunden, aber der doppelte Eintrag bleibt erhalten:

1692716874,235.93
1692716880,236.94833333333333
1692716940,237.45
1692716935,236.66
1692716940,236.486
1692717000,236.82133333333338
1692717060,236.41483333333339

Das Skript ist simpel. Es liest eine Reihe von Variablen, addiert sie und schreibt den Wert in die Zielvariable. Die Laufzeit des Skripts ist < 10 ms.

Du könntest es nachstellen mit

SetValueFloat (47111,  gettimeofday(true));
10

Oh, du schreibst gar nicht ins Archiv? Ich habe das tatsächlich nur bei Verwendung von AC_AddLoggedValues oder so erwartet.

1 „Gefällt mir“
11

Zur Sicherheit habe ich noch im Systemprotokoll von Windows nachgeschaut: zu der Zeit gab es keine automatische Zeitanpassung.

12

Ok, ich habe als Test jetzt eine Variable erstellt, auf minütliche Verdichtung gesetzt und lasse jede Sekunde gettimeofday reinschreiben. Mal schauen, ob ich damit was entdecke…

13

Meine Vermutung ist, dass das Problem auftritt, wenn das Skript mehrfach aufgerufen wird. Vielleicht vervielfältigst du es noch. Eventuell auch mit einer kleinen Verzögerung:

usleep(random_int(0, 10));

Etwas Stress muss schon sein :slight_smile:

14

Jetzt habe ich 10 parallele Ereignisse, die sekündlich feuern und initial die vorgeschlagene Wartezeit haben, schauen wir also mal.