[gelöst] Datenpunkte zyklisch oder ereignisgesteuert lesen
-
@blockmove nur fragt der iobroker sicher intern bereits zyklisch die states ab, deswegen kann man das meines Erachtens nicht vergleichen. Es ist einfach nur redundant und unnötig. Bei einem SPS System ist das was wahrscheinlich ganz andres - da kann es ja sein, dass es für die Statusabfrage gar kein System gibt, aber da kennst du dich sicher besser aus, deswegen halte ich mich da zurück- denn SPS kenne ich nur vom Namen zur Industriemaschinensteuerung, hab damit aber nie was gemacht.
Auch wenn man einen Adapter baut macht das Sinn, aber sicher nicht bei iobroker Datenpunkten. Ich behauptete sogar, hängt natürlich von der Hardware ab, dass alles was unter 100ms abläuft bekommst im iobroker eh nur unzuverlässig mit. Auch meine Tasmota geflanschten Steckdosen bringe ich schnell zum Absturz, wenn ich da Befehle mehrfach unter 100ms sende. Die ganze Hardware spielt doch bei diesen #überlegungen eine wesentliche Rolle.
-
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Das Lesen der Datenpunkte kann ich zyklisch mit getState() oder ereignisgesteuert mit on() ausführen.
Welche Variante wäre zu bevorzugen?
Wo liegen die Vor- und Nachteile?ich würde die Datenpunkte generell per On() auslesen und in Variablen speichern. Zusammen mit einem Auslesen beim Skriptstart hast du dann im Skript zu jedem Zeitpunkt ein sauberes Abbild der Datenpunkte und musst nicht zur Ermittlung der Werte an die Objektstates.
Ob du dann deine Aktion alle 500 ms ausführen musst oder nicht wäre noch zu bewerten. Ich würde auch diese auf den Prüfstand stellen. Ist es eine Aufgabe bei der eigentlich nur eine Aktion notwendig ist wenn sich mindestens einer der Werte geändert hat dann würde ich die ganze Bearbeitung mit an den Trigger hängen und die Zeit-Funktion über die Änderungshistorie verwalten.
Zu den Vor- und Nachteilen :
- eine Zyklische Abarbeitung erzeugt eine gewisse (statische) Grundlast.
- das Zyklische Abfragen der Werte direkt aus dem Objektbaum erhöht diese Last, dieser steigt mit grösser werdendem Objektbaum. (Auch statische Last)
- Je nach Einstellung des Adapters kostet das Abfragen der Werte auch dynamisch Zeit. Mehr dazu weiter unten. Je nach Anzahl der abzufragenden Werte und Frequenz der Abarbeitung kann es passieren das das gleiche Skript mehrfach parallel läuft !!!
- Arbeiten mit on{} erzeugt eine dynamische Last - immer nur wenn werte Geändert werden.
- Auch beim Arbeiten mit on{} kann es passieren das das gleiche Skript parallel mehrfach läuft, insbesondere wenn die Abarbeitung des Skriptes länger dauert als das Intervall zwischen 2 Triggern.
Noch 2 Punkte zum Thema Ressourcen:
Man kann am JS Adapter einstellen ob alle States zu Adapterstart abonniert werden sollen. Wird das gemacht, dann trägt sich der JS Adapter für jeden State als Empfänger der Änderung ein und speichert für jeden State die entsprechenden Änderungen intern. Dieses belegt signifikant Speicher, insbesondere bei grossen Objektbäumen, erlaubt es aber das "getState" synchron mit minimalem Zeitaufwand ausführen zu können. In dem Moment wo das nicht gesetzt ist müssen die States asynchron abgefragt werden, was mehr Zeit bei der Skriptausführung benötigt, dafür aber weniger Speicherbedarf für den JS Adapter.Zu dieser Aussage:
@mickym sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
@blockmove nur fragt der iobroker sicher intern bereits zyklisch die states ab, deswegen kann man das meines Erachtens nicht vergleichen.
Bei der Abarbeitung der Trigger ist zu bedenken das der JS Controller (meines Wissens) nicht zeitgesteuert alle Werte auf Änderung / Aktualisierung überprüft. Statt dessen kann an jedem State ein Skript eingetragen werden welches über die Änderung/Aktualisierung aufgerufen wird. Die Aktualisierung eines Wertes wird ja schon durch einen Event ausgelöst - der JS Controller leitet diesen Event nur an die Skripte weiter.
Aus diesem Grund ist ein Arbeiten mit On{} prinzipiell günstiger als ein arbeiten mit regelmässiger Abarbeitung.A.
-
@mickym
Es geht hier primär um den Script-Aufruf.
Und hier kann man eben unterscheiden zwischen zyklischen Aufruf und ereignisgesteuerten Aufruf. Das hat erstmal nichts mit der internen Verarbeitung von Datenpunkten im ioBroker zu tun. Natürlich gibt es jede Menge Adapter, die einfach in einem festen Zeitraster Daten von Geräten lesen oder Daten schreiben.
Dein Beispiel mit Tasmota spricht sogar mehr den zyklischen Aufruf als dagegegen:
Nehmen wir mal an du hast ein Tasmota-Device an einem Helligkeitssensor hängen der dir alle 100ms einen neuen Wert liefern kann. Unter Umständen hast du nun alle 100ms eine Wertänderung und einen Trigger und somit einen Scriptaufruf. Willst du nun dein Script "stabil" machen, musst du entsprechende Vorkehrungen treffen. Rufst du im Gegensatz dein Script nur alle 500ms auf, dann ist es deutlich einfacher.
Unabhängig davon muss ich auch nicht im jedem Aufruf eines Scripts einen Datenpunkt beschreiben. ioBroker liefert ja den Timestamp eines Datenpunktes und so kann ich auch beim zyklischen einen Mindestzeitabstand einhalten.Ich will eigentlich nur darauf hinweisen, dass sowohl Ereignissteuerung als auch der zyklische Aufrufe ihre Daseinsberechtigung und ihre Vor- und Nachteile haben.
Als Programmierer sollte man einfach beides kennen und je nach Anforderung einsetzen.
Es gilt die uralte Regel: Für jede Arbeit das richtige Werkzeug zu nehmen.
War schon in der Steinzeit so und ist heute nicht anders -
@asgothian Bei der Abarbeitung der Trigger ist zu bedenken das der JS Controller (meines Wissens) nicht zeitgesteuert alle Werte auf Änderung / Aktualisierung überprüft.
Na falls ich das behauptet habe, dann war das natürlich falsch. Ich dachte ich hätte irgendwo geschrieben dass nur die Datenpunkte überwacht werden, die subscribed wurden und der JS Adapter sich wie ein MQTT Broker verhält und deshalb effizient in Zyklen Datenpunkte auf Aktualisierung oder Änderungen überprüft.
-
@blockmove nun beim Scriptaufruf gebe ich Dir natürlich Recht, das stand nach meinem Verständnis gar nicht zur Debatte. Du wirst immer Pollen müssen, wenn sich etwas nicht aktiv meldet. Ich bin beim Skriptaufruf jetzt davon ausgegangen, dass dies zum Ermitteln von States zeitgesteuert aufgerufen wird. Also alles gut. Wie Du sagst das richtige Mittel zur richtigen Zeit und so habe ich den Threadtitel verstanden.
Dein Beispiel mit Tasmota spricht sogar mehr den zyklischen Aufruf als dagegegen:
Nehmen wir mal an du hast ein Tasmota-Device an einem Helligkeitssensor hängen der dir alle 100ms einen neuen Wert liefern kann. Unter Umständen hast du nun alle 100ms eine Wertänderung und einen Trigger und somit einen Scriptaufruf. Willst du nun dein Script "stabil" machen, musst du entsprechende Vorkehrungen treffen. Rufst du im Gegensatz dein Script nur alle 500ms auf, dann ist es deutlich einfacher..Die andere Möglichkeit ist die die Trigger innerhalb der 500ms zu ignorieren. Gibt immer mehrfache Wege. Letztlich geht es immer um Effizienz und das es nicht ins philosophische abgleitet. Eine ähnliche Diskussion hatte ich kürzlich bei einem Node Red Flow, wobei es sicher resourcenschonender war den Flow früher abzubrechen, sich das aber In diesem Fall auf einem iobroker System auf dem Raspberry sicher nicht mehr energetisch messen läßt.
-
@mickym said in Datenpunkte zyklisch oder ereignisgesteuert lesen:
@blockmove nun beim Scriptaufruf gebe ich Dir natürlich Recht, das stand nach meinem Verständnis gar nicht zur Debatte. Du wirst immer Pollen müssen, wenn sich etwas nicht aktiv meldet. Ich bin beim Skriptaufruf jetzt davon ausgegangen, dass dies zum Ermitteln von States zeitgesteuert aufgerufen wird. Also alles gut. Wie Du sagst das richtige Mittel zur richtigen Zeit und so habe ich den Threadtitel verstanden.
Dein Beispiel mit Tasmota spricht sogar mehr den zyklischen Aufruf als dagegegen:
Nehmen wir mal an du hast ein Tasmota-Device an einem Helligkeitssensor hängen der dir alle 100ms einen neuen Wert liefern kann. Unter Umständen hast du nun alle 100ms eine Wertänderung und einen Trigger und somit einen Scriptaufruf. Willst du nun dein Script "stabil" machen, musst du entsprechende Vorkehrungen treffen. Rufst du im Gegensatz dein Script nur alle 500ms auf, dann ist es deutlich einfacher..Die andere Möglichkeit ist die die Trigger innerhalb der 500ms zu ignorieren. Gibt immer mehrfache Wege. Letztlich geht es immer um Effizienz und das es nicht ins philosophische abgleitet. Eine ähnliche Diskussion hatte ich kürzlich bei einem Node Red Flow, wobei es sicher resourcenschonender war den Flow früher abzubrechen, sich das aber In diesem Fall auf einem iobroker System auf dem Raspberry sicher nicht mehr energetisch messen läßt.
Das Thema gibt es bei ganz vielen Systemen, nicht nur bei Node RED oder ioBroker.
Ich muss da auch immer schmunzeln. Da nimmt man ein schwachbrüstiges IoT-Gateway oder nen simplen Pi3 und packt Dinge drauf, dass einem schwindlig wird. Nachher wundert man sich, wenn Reaktionszeiten oder sonstiges Zeitverhalten nicht mehr nachvollziehbar sind.
Mein alter Chef hatte da nen schönen Spruch "Es ist nicht immer das Wass Schuld, wenn die Ente nicht schwimmen kann". -
@blockmove sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Ich programmiere beruflich SPS-Steuerungen. Dort werden Variablen im Prinzip generell zyklisch bearbeitet. Die Zykluszeit beträgt meist so um 10-30ms.
Hast du ein Script, dass auf viele Datenpunkte zugreift, dann vereinfacht die zyklische Bearbeitung das ganz erheblich. So definierst du dir einmal deinen zyklischen Aufruf, im anderen Fall brauchst du für jede relevante Variable einen Trigger. Im dümmsten Fall, hast du noch eine gegenseitige Beeinflussung, so dass du evtl. sogar Trigger sperren musst.
.....Du beschreibst so ziemlich genau meine Situation. Auch ich komme aus der Automatisierungstechnik und bin dadurch das zyklische Abarbeiten gewohnt.
Bei meiner Anwendung geht es um das Laden eines E-Autos mit überschüssiger PV-Energie, sogenanntes Überschussladen.
Mein Skript verarbeitet dabei relativ viele Datenpunkte, die größtenteils auch kombiniert werden müssen, bzw. voneinander abhängig sind.
Hier mal die Visu. mit ersten Werten (noch nicht vollständig).
-
@asgothian sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
.....
ich würde die Datenpunkte generell per On() auslesen und in Variablen speichern. Zusammen mit einem Auslesen beim Skriptstart hast du dann im Skript zu jedem Zeitpunkt ein sauberes Abbild der Datenpunkte und musst nicht zur Ermittlung der Werte an die Objektstates.
.....Danke für die ausführliche Erklärung.
Das Einlesen der Datenpunkte werde ich ereignisgesteuert ausführen.
Das restliche Programm als zyklische Routine, weil ich das leichter verstehe. -
@hub01 said in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Du beschreibst so ziemlich genau meine Situation. Auch ich komme aus der Automatisierungstechnik und bin dadurch das zyklische Abarbeiten gewohnt.
Bei meiner Anwendung geht es um das Laden eines E-Autos mit überschüssiger PV-Energie, sogenanntes Überschussladen.
Mein Skript verarbeitet dabei relativ viele Datenpunkte, die größtenteils auch kombiniert werden müssen, bzw. voneinander abhängig sind.Genau die selbe Anwendung habe ich auch.
Ich habe auch zuerst mit Triggern angefangen und nach dem die Variablen und Abhängigkeiten immer mehr wurden, habe ich auf eine zylische Bearbeitung umgestellt.
Mir also im Prinzip eine SPS im ioBroker nachgebaut.
Aus meiner Sicht für den Anwendungsfall deutlich einfacher und strukturierter als die Lösung mit zig Triggern. Einfach feste zeitliche Aufrufe mit konsitenten Daten. -
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Die Datenpunkte ändern sich unterschiedlich, von oft (sekündlich) bis selten (monatlich).
Wenn die DP sich sekündlich ändern, dann reicht es imho aus dass das Skript einmal pro Sekunde läuft, nicht 2mal.
Ich würde es ereignisgesteuert machen, weil das Skript dann nur läuft wenn es laufen muss, sprich wenn sich ein relevanter DP geändert hat. -
@amg_666 said in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Ich würde es ereignisgesteuert machen, weil das Skript dann nur läuft wenn es laufen muss, sprich wenn sich ein relevanter DP geändert hat.
Dann denk doch mal im Detail darüber nach:
Datenpunkte im ioBroker ändern sich nicht deterministisch.
Der Zeitpunkt an dem sich ein Datenpunkt ändert, ist quasi zufällig.
Beispiel: Mein Senec-Speicher liefert alle 3s neue Werte, die Wallbox etwa jede Sekunde, der Heizstab alle 500ms und das Auto alle x Minuten. Von all diesen Quellen sind aber bestimmte Datenpunkte relevant. Wenn ich sowas also per Trigger löse, weiß ich letztlich nichtmal wann und wie oft das Script aufgerufen wird. Die Wahrscheinlichkeit ist sehr, sehr groß, dass ich das Script deutlich häufiger aufrufe, wie bei einem zyklischen Aufruf alle 500ms.
Was ist nun besser? -
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
@asgothian sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
.....
ich würde die Datenpunkte generell per On() auslesen und in Variablen speichern. Zusammen mit einem Auslesen beim Skriptstart hast du dann im Skript zu jedem Zeitpunkt ein sauberes Abbild der Datenpunkte und musst nicht zur Ermittlung der Werte an die Objektstates.
.....Danke für die ausführliche Erklärung.
Das Einlesen der Datenpunkte werde ich ereignisgesteuert ausführen.
Das restliche Programm als zyklische Routine, weil ich das leichter verstehe.Gerade in diesem Fall ist eine zyklische Abarbeitung eher weniger Sinnvoll.
Letztendlich ist eine Aktion (Ändern des Ladevorgangs, Aktualisierung der Darstellung) nur Sinnvoll wenn sich Werte auch geändert haben. Dabei gibt es in dem was ich da sehe keinen Wert der sich nur aus Vorgabewerten und Zeit berechnen lässt.
Zum Thema komplizierter:
Du baust dir eine Funktion "Aktion_ausführen". In dieser verarbeitest du alle gespeicherten Variablen. Zusätzlich merkst Du dir in einer Variable "Timestamp" wann die Funktion gelaufen ist.
Diese Funktion rufst du aus jedem Trigger NACH dem aktualisieren der Variablen auf.
Aus dem Unterschied zwischen "jetzt" und "Timestamp" kannst du Berechnungen anstellen die auf den Zeitunterschied zwischen 2 Änderungen angewiesen sind.
-
@blockmove sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
@amg_666 said in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Ich würde es ereignisgesteuert machen, weil das Skript dann nur läuft wenn es laufen muss, sprich wenn sich ein relevanter DP geändert hat.
Dann denk doch mal im Detail darüber nach:
Datenpunkte im ioBroker ändern sich nicht deterministisch.
Der Zeitpunkt an dem sich ein Datenpunkt ändert, ist quasi zufällig.
Beispiel: Mein Senec-Speicher liefert alle 3s neue Werte, die Wallbox etwa jede Sekunde, der Heizstab alle 500ms und das Auto alle x Minuten. Von all diesen Quellen sind aber bestimmte Datenpunkte relevant. Wenn ich sowas also per Trigger löse, weiß ich letztlich nichtmal wann und wie oft das Script aufgerufen wird. Die Wahrscheinlichkeit ist sehr, sehr groß, dass ich das Script deutlich häufiger aufrufe, wie bei einem zyklischen Aufruf alle 500ms.
Was ist nun besser?Bleiben wir bei Deinem Beispiel:
der Scenec-Speicher ist wichtig - immer wenn der was ändert muss das Skript laufen.
der Heizstab ist bedingt wichtig - da kann das aktivieren der Berechnungen auf signifikante Änderungen begrenzt werden. Diese wird es nur selten geben. Das ist Ereignisgesteuert möglich.
Wallbox und Auto sind letztendlich abhängige Werte - auch hier kann man auf signifikante Änderungen reagieren, oder nur wenn die Werte "out of cycle" geändert werden rechnen.In dem in meinem vorigen Post bereitgestellten Beispiel kann zusätzlich das Durchführen der Berechnung über einen einfachen Zeitvergleich (wann zuletzt gelaufen mit jetzt) auf eine Maximalfrequenz eingestellt werden.
Damit bist du immer effektiver als mit einer reinen Zeitsteuerung. Insbesondere da du bei der Zeitsteuerung die Frequenz recht hoch wählen musst, damit du schnell genug auf eine relevante Änderung reagieren kannst.
A.
Nachtrag: Der grosse Vorteil des Event-gesteuerten Ansatzes ist ja gerade das durch die einzelnen Events fein auf die Notwendigkeiten reagiert werden kann und nicht blind alle x ms alles neu gemacht wird.
-
Du begrenzt also die Maximalfrequenz durch einen Zeitvergleich ... hmmm
Alternativ kann ich parallel zum star zyklischen Aufruf das Script auch durch einen Trigger eventgesteuert aufrufen. Letztlich funktioniert alles.Das Schöne ist ganz einfach, dass beide Aufrufvarianten möglich sind.
Wie schon geschrieben, haben beide Systeme ihre absolute Daseinsberechtigung und ihre Vor- und Nachteile. Wichtig ist einfach, dass man das Systemverhalten und die Auswirkungen weiß.
Ich kenne die Diskussion seit über 30 Jahren und bin da recht entspannt. Jeder soll das Verwenden, was ihm lieber ist. -
Hallo zusammen,
auf Grund der regen Diskussion habe ich mal die Zeit gemessen, die mein Skript in Anspruch nimmt.
Diese schwankt zwischen 2 und 4 Millisekunden.
Das Ganze läuft auf einem PC in VMware mit Windows 10 und 6GB Ram.
Wobei ich meine, dass mein Skript im Vergleich zu normalen Haus-Automatisierungen umfangreich und aufwändig ist.Für mich stellt sich deswegen nicht die Frage, ob das Skript zyklisch oder ereignisgesteuert aufgebaut sein soll, sondern wie im Eingangspost geschrieben, nur ob das Lesen der Datenpunkte besser ereignisgesteuert erfolgen sollte.
-
@amg_666 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Die Datenpunkte ändern sich unterschiedlich, von oft (sekündlich) bis selten (monatlich).
Wenn die DP sich sekündlich ändern, dann reicht es imho aus dass das Skript einmal pro Sekunde läuft, nicht 2mal.
Ich würde es ereignisgesteuert machen, weil das Skript dann nur läuft wenn es laufen muss, sprich wenn sich ein relevanter DP geändert hat.Richtig, würde langen.
Ich habe auch einige Routinen, die z.B. nur alle 10 Sek. durchlaufen werden.Die 500ms verwende ich,
- um Rückmeldungen auf der Visu. zeitnah zu sehen
- um in Trendanzeigen zeitfolgerichtige Kurven zu bekommen
- um Verzögerungszeiten feiner auflösen zu können
-
@asgothian sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
.....
Gerade in diesem Fall ist eine zyklische Abarbeitung eher weniger Sinnvoll.Letztendlich ist eine Aktion (Ändern des Ladevorgangs, Aktualisierung der Darstellung) nur Sinnvoll wenn sich Werte auch geändert haben. Dabei gibt es in dem was ich da sehe keinen Wert der sich nur aus Vorgabewerten und Zeit berechnen lässt.
.....Ich weiß nicht, ob ich dich da richtig verstanden habe, aber hier mal 2 kurze Teilfunktion aus meiner Anwendung:
- wenn genügend Überschuss vorhanden ist, dann erhöhe den Ladestrom alle 15 Sekunden um 1 Ampere
- wenn 1-phasiges Laden aktiv ist und mit 16A geladen wird und 5 Minuten lang genügend Überschuss für die Phasenumschaltung vorhanden ist, dann schalte um
-
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
auf Grund der regen Diskussion habe ich mal die Zeit gemessen, die mein Skript in Anspruch nimmt.
Diese schwankt zwischen 2 und 4 Millisekunden.Mal vorweg - der effektive Lastunterschied in einzelnen Fällen ist auf jeden Fall minimal. Es geht hier eher um den generellen Ansatz. Ich habe mehrfach Systeme gesehen die durch eine grössere Anzahl von Heartbeat getriebenen Einzelfunktionen plötzliche Lastspitzen hatten - immer dann wenn durch den Heartbeat alle Skripte gleichzeitig arbeiten wollten.
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Ich weiß nicht, ob ich dich da richtig verstanden habe, aber hier mal 2 kurze Teilfunktion aus meiner Anwendung:
wenn genügend Überschuss vorhanden ist, dann erhöhe den Ladestrom alle 15 Sekunden um 1 Ampere
Ausgehend davon das sich der "Überschuss" häufiger als alle 15 Sekunden ändert:
- vorheriger wert =< "Genügend Überschuss für +1 A" > "Genügend Überschuss für +1 A" => Timeout setzen, 15 s. Wenn der auslöst, Ladestrom +1A
- aktueller Wert <= "Genügend Überschuss für +1 A" - Timeout löschen.
wenn 1-phasiges Laden aktiv ist und mit 16A geladen wird und 5 Minuten lang genügend Überschuss für die Phasenumschaltung vorhanden ist, dann schalte um
Wenn der Überschuss sich geändert hat nachschauen:
- vorheriger wert =< "Überschussgrenze für Phasenumschaltung" und aktueller Wert > "Überschussgrenze für Phasenumschaltung" => Timeout setzen, 5 min. Wenn der auslöst, Phasenumschaltung
- aktueller Wert <= "Überschussgrenze für Phasenumschaltung" - Timeout löschen.
-
@hub01 said in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Für mich stellt sich deswegen nicht die Frage, ob das Skript zyklisch oder ereignisgesteuert aufgebaut sein soll, sondern wie im Eingangspost geschrieben, nur ob das Lesen der Datenpunkte besser ereignisgesteuert erfolgen sollte.
Was meinst du mit Datenpunkte ereignisgesteuert lesen?
Das Lesen erfolgt doch dann über ein Script? Und dieses Script löst du dann eben mit einem Ereignis aus. -
@blockmove sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
@hub01 said in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Für mich stellt sich deswegen nicht die Frage, ob das Skript zyklisch oder ereignisgesteuert aufgebaut sein soll, sondern wie im Eingangspost geschrieben, nur ob das Lesen der Datenpunkte besser ereignisgesteuert erfolgen sollte.
Was meinst du mit Datenpunkte ereignisgesteuert lesen?
Das Lesen erfolgt doch dann über ein Script? Und dieses Script löst du dann eben mit einem Ereignis aus.Hi,
siehe 1. Beitrag
