Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[hub01]

@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

[Blockmove]

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

[Asgothian]

@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 Javascript

Schau 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.

[Blockmove]

@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.

[Codierknecht]

@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.

[hub01]

@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.

[Codierknecht]

@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.

[Blockmove]

@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.

[Asgothian]

@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.

[Homoran]

@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.

[hub01]

@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

[Homoran]

@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

[Asgothian]

@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.

[hub01]

@asgothian
:+1:
ich werde deine Anregungen/Empfehlungen nicht gänzlich unbeachtet lassen. Einiges bei den 500ms werde ich sicher noch ändern. Danke dir

[hub01]

@homoran sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:

@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

Für den Einen nicht, für den Anderen schon …
Aber ich versteh dich, für meinen Anwendungsfall eher nicht ausschlaggebend.
Es ist halt für mich nur nicht begreiflich (egal wo das herkommt), zumal die Systemzeit im Millisekundenbereich ohne Probleme funktioniert. Als SPS-Programmierer kenne ich so was nicht.

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

Und auch das versteh ich nicht.
Mein Skript mit über 400 Zeilen benötigt zw. 2-4ms ohne Ausreißer.
Und eine einzelne Zeitfunktion liegt bis 100ms daneben?
Das sind sicherlich nicht meine gleichzeitig laufenden Zeitpläne.

[Codierknecht]

@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:

Als SPS-Programmierer ...

Lös' Dich davon.
SPS ist etwas völlig anderes*. Ich glaube, daher kommt auch Dein Festhalten an zyklischen Dingen.

*Wobei ich natürlich zugeben muss, dass meine Erfahrungen mit SPS schon einige Jahrzehnte alt sind ...

[Homoran]

@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:

Als SPS-Programmierer kenne ich so was nicht.

das ist was ganz anderes.
Auch ein Arduino würde "genauer" arbeiten.

Wir reden bei ioBroker von umfangreichem SmartHome, nicht von begrenzter Prozesssteuerung

[ACHIM BAECKER]

Wie schon gesagt, für jede Aufgabe gibt es unterschiedliche Werkzeuge...
Man sollte aber auch darüber nachdenken, ob man alles so schnell wie irgend möglich braucht, bzw. was es einem bringt...
Gehen wir davon aus das wir gerade mit "Solar-Stromüberschuss" 1800W/h die Batterie laden und schlagartig fällt die Sonne aus....
Wenn wir hier erst nach 1s abfragen und die Ladeleistung runter setzen dann haben wir 0,5W aus dem Netz ziehen müssen.... bei 0,5s wären es nur 0,25W
Also für mich wäre da ein Zyklus von >= 5s mehr als ausreichend ( wären dann 2,5W)

[Blockmove]

@homoran said in Datenpunkte zyklisch oder ereignisgesteuert lesen:

@hub01 sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:

Als SPS-Programmierer kenne ich so was nicht.

das ist was ganz anderes.
Auch ein Arduino würde "genauer" arbeiten.

Wir reden bei ioBroker von umfangreichem SmartHome, nicht von begrenzter Prozesssteuerung

Begrenzte Prozesssteuerung ... Der war gut :joy:
Mein aktuelles SPS-Projekt umfasst etwas mehr als 1000 Sensoren / Aktoren.
Die Visualisierung über 2500 Variablen.
Der Schaltschrank für die Maschine ist 4,8m lang und 2m hoch.
Hardwarekosten rund 70.000€

[ACHIM BAECKER]

@blockmove
Denke "Begrenzte Prozesssteuerung" war eher bezogen auf die SPS. In dieser ist ein sehr überschaubarer Befehls-/Funktionsvorrat der, bis auf einen (freilaufend), in festen Zyklen (Zeit) oder Ereignis gesteuert ausgeführt wird.
Gerade bei größeren Anlagen wird die Visualisierung dann über/auf separaten PCs erstellt. Auch das Loggen von Daten oder Ereignissen erfolgt extern.
Denke wenn Du versuchen würdest die obige Abfragen, Steuerung + Visualisierung in einer SPS unter zu bringen, kommst Du schnell an diese Grenzen. ( vom Preis mal gar nicht geredet) Wenn die Abfrage dann passt, Berechnungen stimmen, ist immer noch keine Visualisierung da...

Da sind wir wieder bei den richtigen Werkzeugen....
Automatisierung von Industrieanlagen würde ich nie mit ioBroker machen, Teile davon über ioBroker zu Visualisieren oder auch bedienen schon (über S7-Adapter)

Im privaten Umfeld schaut des schon wieder anders aus...