[gelöst] Datenpunkte zyklisch oder ereignisgesteuert lesen
-
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 -
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.
Das ist auf jeden Fall korrekt.
Schwallbildung, egal ob nun durch Heartbeat, abhängige Events oder eben sonstwas, ist nie gut.
Bei "großen" Systemen definiert man eben Ablaufgruppen um sowas zu vermeiden.
Angesichts der Leistungsfähigkeit heutiger Hardware, hatte ich das bei ioBroker noch nie gebraucht.
Da stolpere ich manchmal eher über das Thema synchron / asychron bei Javascript -
@blockmove sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Angesichts der Leistungsfähigkeit heutiger Hardware, hatte ich das bei ioBroker noch nie gebraucht.
Da stolpere ich manchmal eher über das Thema synchron / asychron bei JavascriptSchau mal im Forum wie viele Leute versuchen einen ioBroker auf einem PI3 oder sogar PIZero laufen zu lassen, und denk dann nochmal über das Thema Leistung aktueller Hardware nach
@blockmove sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
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.Wenn sich in einem Skript mehrere "on ..." Befehle befinden dann wird nur der Code innerhalb des "on..." Ereignisgesteuert ausgeführt - nicht das gesamte Skript.
An dieser Stelle kämpft Deine Vorstellung ggf. wieder mit dem Thema Synchron / Asynchron. Ein Skript welches nur aus
var MyValue = "xy" on ... on ... on ... on ... schedule ...besteht wird zur Laufzeit erst einmal nur wenig machen. Es stellt den Kontext zur Verfügung in dem die Variable MyValue definiert ist, hat die Trigger über die "on" Befehle mit einem Einsprungpunkt im eigenen Kontext versorgt (dito mit dem Zeitplan durch den "shedule" Befehl). Danach belegt es keine weitere Prozessorzeit, hält aber den Kontext aufrecht.
Wird das Skript beendet wird der Kontext gelöscht und die Einträge in den Schedule dispatcher und an den Triggerdatenpunkten entfernt.
Ansonsten wird immer nur der Teil des Skriptes aktiv ausgeführt der hinter dem Einsprungpunkt liegt, und das auch nur wenn seine Bedingung erfüllt ist (Trigger oder Zeitplan)
A.
-
@asgothian
Die Arbeitsweise von ioBroker beim Abarbeiten von Scripten ist mir schon klar.
Das zu Grunde liegende Konzept ist richtig gut umgesetzt.
Die Stabilität und Robustheit von ioBroker ist hervorragend.Ich bin nur nicht der größte Fan von Javascript / node.js.
Aber so hat halt jeder seine persönliche Vorlieben. -
@asgothian
Oder um es auf ein - dem Einen oder Anderen eher geläufiges - Windows zu münzen:
Man stelle sich eine Windows-Application mit 3 Button vor.
Hinter jedem der Buttons steht die Ereignisbehandlung für den Klick.procedure TForm3.Button1Click(Sender: TObject); begin // mach was end; procedure TForm3.Button2Click(Sender: TObject); begin // mach was anderes end; procedure TForm3.Button3Click(Sender: TObject); begin // mach was völlig anderes end;Beim Start der Applikation (im ioB: Script) wird lediglich die entsprechende Ereignisbehandlung an den Button gebunden.
Solange keiner klickt, passiert auch nix und es wird auch keine Rechenzeit verbraten.
Erst wenn der Button angeklickt wird, wird dessen Ereignisbehandlung aufgerufen.
Und zwar genau dann, wenn geklickt wird. Da läuft kein "Scheduler", der alle x Millisekunden prüft ob ein Button geklickt wurde oder etwas in der Art. Sowas wäre reine Ressourcenverschwendung.Ersetzt man jetzt "ButtonClick" durch "DatenpunktÄnderung" hat man prizipiell das Verhalten im ioBroker.
Wohlgemerkt "prinzipiell", denn die Asynchronität macht einige Dinge ggf. etwas komplizierter.
-
@asgothian sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
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.
das mit den Heartbeat habe ich nicht verstanden. Ist das nicht ein Problem der Adapter?
Oder könnte z.B. ein hängender Adapter mein Skript blockieren?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 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.
Deine vorgeschlagenen Lösungen habe ich soweit verstanden, aber Timeouts waren das erste, was ich aus meinen Skripten verbannt habe.
Für mich völlig unverständlich, wie ein hochmodernes System soweit danebenliegen/abweichen kann.
Auf der anderen Seite will ich bei Zeitverzögerungen diese auch als Fortschrittsbalken auf der Visu. sehen. (in meiner Hardcopy der Teil links oben / Schaltfreigaben)Beim Rest ist es oft schwierig, wenn man nicht das ganze Skript kennt.
Deswegen eine kurze Erklärung, warum ich zyklisch programmiere, unabhängig davon, dass ich es leichter verstehe.Fast alle Funktionen sind vom Überschuss abhängig. Der Überschuss wird aus den 3 Energiewerten vom Energiemeter gebildet. Diese ändern sich zw. 2 und bis zu 8 Sekunden. Die 2 Sekunden sind vermutlich die Pollzeit vom Adapter oder vom Energiemeter. Ereignisgesteuert würden meine Routinen somit im 2/3 bis 8/3 Sekundentakt laufen.
Meine zyklisches Programm teilt sich auf in:
- alle 0,5 Sekunden: Ein-/Ausschalten, Steuersignale und Zeitsignale bilden
- alle 2 Sekunden: Überschuss ermitteln
- alle 15 Sekunden: Routine für (langsames) Hochschalten
- alle 5 Sekunden: Routine für (schnelles) Runterschalten
Das Ein-/Ausschalten werde ich noch überdenken.
Beim Rest denke ich, dass ich langsamer und ressourcenschonender bin. -
@hub01
Ich vermute trotzdem, dass ein solches zyklisches Vorgehen mehr Last produziert als Trigger.
Besonders die kurzen Zyklen von 0,5 bzw. 2 Sekunden.Ich würde auf die 3 Eingangswerte einen Trigger legen und in dessen Ereignisbehandlung mit Schwellwerten arbeiten.
Erst bei Änderungen über dem Schwellwert erfolgt dann die weitere Verarbeitung.
Ich nehme dazu einfach mal an, dass man Änderungen unterhalb des Schwellwertes der Einfachheit halber ignorieren kann. Wie man den jeweiligen Schwellwert dann definiert, ist Ansichtssache. -
@hub01 said in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Meine zyklisches Programm teilt sich auf in:
- alle 0,5 Sekunden: Ein-/Ausschalten, Steuersignale und Zeitsignale bilden
- alle 2 Sekunden: Überschuss ermitteln
- alle 15 Sekunden: Routine für (langsames) Hochschalten
- alle 5 Sekunden: Routine für (schnelles) Runterschalten
Ich hab einen Schedule mit 0,5s
Darin habe ich eine Variable als "Taktzähler".
Abhängig vom diesem Taktzähler rufe ich dann meine Funktionen auf. -
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
das mit den Heartbeat habe ich nicht verstanden. Ist das nicht ein Problem der Adapter?
Oder könnte z.B. ein hängender Adapter mein Skript blockieren?Kein, es geht da eher darum das mehrere Zeitpläne gleichzeitig ihre Aktion durchführen wollen. In dem von Dir vorgegebenen Beispiel tritt dieser Peak alle 30 Sekunden auf, da da alle Zeitpläne aktiv werden. Natürlich haben auch Adapter die alle x Sekunden etwas tun ihren Anteil daran. An dem kann der Anwender aber selten etwas ändern.
Deine vorgeschlagenen Lösungen habe ich soweit verstanden, aber Timeouts waren das erste, was ich aus meinen Skripten verbannt habe.
Für mich völlig unverständlich, wie ein hochmodernes System soweit danebenliegen/abweichen kann.Diesen Punkt müsstest du mal genauer erklären. Ich sehe nicht was ein Timeout mit "daneben liegen" und "abweichen" zu tun hat.
Auf der anderen Seite will ich bei Zeitverzögerungen diese auch als Fortschrittsbalken auf der Visu. sehen. (in meiner Hardcopy der Teil links oben / Schaltfreigaben)
Dies liesse sich über ein entsprechendes Visualisierungsobjekt lösen, dem gegeben wird:
- eine Zeit wann 100% erreicht sind
- eine Zeit die als 0% anzusehen ist
- ein "Aktiv" oder "inaktiv"
Aus diesen 3 Parametern kann der Web-Server oder Web-Client jederzeit die korrekte Anzeige erzeugen (läuft dann im Browser)
Die Zielzeit würde dann im Trigger beim Start des Timeouts mit gesetzt, und die Visualisierung ist auf Stand.Beim Rest ist es oft schwierig, wenn man nicht das ganze Skript kennt.
Deswegen eine kurze Erklärung, warum ich zyklisch programmiere, unabhängig davon, dass ich es leichter verstehe.Fast alle Funktionen sind vom Überschuss abhängig. Der Überschuss wird aus den 3 Energiewerten vom Energiemeter gebildet. Diese ändern sich zw. 2 und bis zu 8 Sekunden. Die 2 Sekunden sind vermutlich die Pollzeit vom Adapter oder vom Energiemeter. Ereignisgesteuert würden meine Routinen somit im 2/3 bis 8/3 Sekundentakt laufen.
Prinzipiell ja, wobei auch da bei geschickter Umsetzung regelmässig ganz wenig passiert (geänderten Wert in eine Variable holen, eine Bedingung prüfen und nur wenn die Bedingung zutrifft eine Aktion auslösen)
Meine zyklisches Programm teilt sich auf in:
- alle 0,5 Sekunden: Ein-/Ausschalten, Steuersignale und Zeitsignale bilden
- alle 2 Sekunden: Überschuss ermitteln
- alle 15 Sekunden: Routine für (langsames) Hochschalten
- alle 5 Sekunden: Routine für (schnelles) Runterschalten
Das Ein-/Ausschalten werde ich noch überdenken.
Beim Rest denke ich, dass ich langsamer und ressourcenschonender bin.Ich denke die 0,5 Sekunden kannst Du dir sparen, da die eigentlichen Aktionen sowieso maximal im 5 Sekunden Raster laufen. Schneller muss da nichts laufen, und Zeitsignale musst du eigentlich nicht bilden - du hast direkt zugriff auf die in ms laufende Systemzeit.
A.
-
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
wie ein hochmodernes System soweit danebenliegen/abweichen kann.
ich vermute, dass die Timeouts dann nicht alle richtig gestoppt wurden und mehrfach liefen.
-
@asgothian sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Deine vorgeschlagenen Lösungen habe ich soweit verstanden, aber Timeouts waren das erste, was ich aus meinen Skripten verbannt habe.
Für mich völlig unverständlich, wie ein hochmodernes System soweit danebenliegen/abweichen kann.Diesen Punkt müsstest du mal genauer erklären. Ich sehe nicht was ein Timeout mit "daneben liegen" und "abweichen" zu tun hat.
Habe eben ein Testprogramm mit Timeouts erstellt. Aktuelle Abweichung zw. 10 und 30ms, ab und zu ein Ausreißer bis 90ms.
Eigentlich nicht weiter schlimm (solange sie sich nicht aufaddieren).
Meine ersten Versuche mit Timeout waren da gravierender, war aber unter Linux/Debian, bevor ich auf Windows umgestellt hatte.Prinzipiell ja, wobei auch da bei geschickter Umsetzung regelmässig ganz wenig passiert (geänderten Wert in eine Variable holen, eine Bedingung prüfen und nur wenn die Bedingung zutrifft eine Aktion auslösen)
Genau das macht ja mein zyklisches Programm auch. Fast jede Aktion hängt an einer oder mehreren Wenn/Dann-Funktion.
Ich denke die 0,5 Sekunden kannst Du dir sparen, da die eigentlichen Aktionen sowieso maximal im 5 Sekunden Raster laufen. Schneller muss da nichts laufen, und Zeitsignale musst du eigentlich nicht bilden - du hast direkt zugriff auf die in ms laufende Systemzeit.
Ja, die ms der Systemzeit nutze ich für meine Zeiten.
Warum ich aber 500ms nutze, hab ich oben schon mal geschrieben.- 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
-
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Habe eben ein Testprogramm mit Timeouts erstellt. Aktuelle Abweichung zw. 10 und 30ms, ab und zu ein Ausreißer bis 90ms.
Das ist jetzt wirklich nicht
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
soweit danebenliegen /abweichen kann
Das dürfte, wenn überhaupt, deiner Hardware geschuldet sein, wenn
@asgothian sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
mehrere Zeitpläne gleichzeitig ihre Aktion durchführen wollen
-
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
@asgothian sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:
Deine vorgeschlagenen Lösungen habe ich soweit verstanden, aber Timeouts waren das erste, was ich aus meinen Skripten verbannt habe.
Für mich völlig unverständlich, wie ein hochmodernes System soweit danebenliegen/abweichen kann.Diesen Punkt müsstest du mal genauer erklären. Ich sehe nicht was ein Timeout mit "daneben liegen" und "abweichen" zu tun hat.
Habe eben ein Testprogramm mit Timeouts erstellt. Aktuelle Abweichung zw. 10 und 30ms, ab und zu ein Ausreißer bis 90ms.
Eigentlich nicht weiter schlimm (solange sie sich nicht aufaddieren).
Meine ersten Versuche mit Timeout waren da gravierender, war aber unter Linux/Debian, bevor ich auf Windows umgestellt hatte.Prinzipiell ja, wobei auch da bei geschickter Umsetzung regelmässig ganz wenig passiert (geänderten Wert in eine Variable holen, eine Bedingung prüfen und nur wenn die Bedingung zutrifft eine Aktion auslösen)
Genau das macht ja mein zyklisches Programm auch. Fast jede Aktion hängt an einer oder mehreren Wenn/Dann-Funktion.
Ich denke die 0,5 Sekunden kannst Du dir sparen, da die eigentlichen Aktionen sowieso maximal im 5 Sekunden Raster laufen. Schneller muss da nichts laufen, und Zeitsignale musst du eigentlich nicht bilden - du hast direkt zugriff auf die in ms laufende Systemzeit.
Ja, die ms der Systemzeit nutze ich für meine Zeiten.
Warum ich aber 500ms nutze, hab ich oben schon mal geschrieben.- 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
Ich denke die Diskussion zwischen uns kann hier beendet werden. Du bist davon überzeugt das der Weg den Du gehst der beste ist. Ich bin davon überzeugt das dem nicht so ist.
Belassen wir es dabei.
A.
-
@asgothian
ich werde deine Anregungen/Empfehlungen nicht gänzlich unbeachtet lassen. Einiges bei den 500ms werde ich sicher noch ändern. Danke dir
