ich habe bereits alle möglichen Threads zu AC_GetAggregatedValues() durchforstet, aber keine passende Antwort gefunden.
Kann man pauschal sagen, wie lange es dauert, bis nach dem Ändern eines Variablenwerts die aggregierten Werte aktualisiert sind und über AC_GetAggregatedValues() zur Verfügung stehen?
Hintergrund:
Ich nutze AC_GetAggregatedValues() (tägliche Aggregation) um Verbrauchswerte mittels des Summenwerts (Avg) für Variablen mit Zähler-Aggregation zu ermitteln. Das klappt an sich auch problemlos. Die Ermittlung der Werte starte ich u.a. bei Änderung der betroffenen Variable und in dem Fall ist es meistens so, dass mir der letzte Wert (dessen Änderung das Skript getriggert hat) im Ergebnis von AC_GetAggregatedValues()[‚Avg‘] fehlt. Rufe ich das Skript nach der Änderung der Variablen noch mal manuell auf, ist der Wert enthalten.
Ich habe testweise mal IPS_Sleep() mit verschiedenen Längen eingebaut, bevor ich die Archivdaten abfrage, weil ich dachte, dass die Abfrage der Archivdaten einfach zu schnell nach der Änderung der Variablen erfolgt. Aber selbst wenn ich da großzügig 10-20 Sekunden einbaue, fehlt der letzte Wert trotzdem im Summenwert von AC_GetAggregatedValues(). Rufe ich das Skript aber innerhalb dieses Zeitraums noch mal manuell auf, ist der Wert enthalten. Also scheint es mir kein reines Timing-Problem zu sein.
Das ist jetzt alles nicht dramatisch, aber mich würde mal interessieren, woran das liegen könnte und wie lange es nach einer Variablenänderung in der Regel dauert, bis AC_GetAggregatedValues und ggf. auch AC_GetLoggedValues() die letzte Änderung berücksichtigen.
Hi,
pauschal wird man wohl gar nichts sagen können. Ich habe Variablen die 1-2 Mal pro Woche neue Werte bekommen und andere Variablen bekommen pro Tag >100 neue Werte.
Versuch statt Sleep mal einen Timer von 10 Sekunden zu setzen und in der Timer-Routine die Werte auszulesen.
Ja, pauschal ist immer so eine Sache. Da gebe ich dir Recht. Mein konkreter Fall hat relativ wenige Daten im Archiv (< 1000) und wird auch nur einige Male am Tag aktualisiert.
Aber es muss ja einen Grund dafür geben, warum die Daten (trotz Wartezeit) bei Auslösung durch die Variable nicht aktuell sind, wenn ich das Skript manuell starte, aber schon. Bei einer Aktualisierung via Timer-Event wird es vermutlich auch direkt aktualisiert sein, ist ja nichts anderes als die manuelle Auslösung. Das zu testen habe ich schon auf meiner To-Do-Liste.
Mir würde ein Timer-Event prizipiell auch reichen, aber ich wollte das unnötige Auslesen von Archivdaten vermeiden, wenn sich nichts geändert hat. Das kann ich natürlich auch auf anderem Wege abfangen, aber ein Variablenereignis ist ja eigentlich prädestiniert dafür, wenn ich nur etwas tun will, wenn sich auch was geändert hat.
Das sogenannte „CommitInterval“ ist in den Spezialschaltern definiert und standardmäßig auf 60 Sekunden gestellt. Sofern du also keine weitere Verzögerungen auf der internen MessageQueue hast (das wäre schlecht und du würdest es schnell merken, dass dein IP-Symcon träge ist), dann ist also der Worst-Case bei ~60 Sekunden.
Übrigens sollte man diesen Spezialschalter nicht unbedingt reduzieren, da man dadurch eher unnötig Last im IP-Symcon System erzeugt. Wenn man sehr sehr viele Daten loggt (bei unseren großen Kundenanlagen in der Industrie), dann macht es Sinn den Parameter auf 30 bzw. 10 Sekunden zu stellen, da dadurch zwar in Summe die Last höher ist, es aber keine Last-Spitzen alle 60 Sekunden gibt. Diese sehen im Task-Manager dann sehr wild aus und einige Sys-Admins bekommen Schnappatmung und rufen uns an
