[gelöst] Datenpunkte zyklisch oder ereignisgesteuert lesen

[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

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

[Blockmove]

@achim-baecker said in Datenpunkte zyklisch oder ereignisgesteuert lesen:

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

Auch SPS-Steuerungen entwickeln sich weiter
Von der Zuverlässigkeit und Stabilität hätte ich auch wenig Bedenken ioBroker im gewerblichen / industriellen Umfeld einzusetzen.
Allerdings 2500 Variablen im S7-Adapter anzulegen ... Naja.
Irgendwie fehlt da noch ein OPC UA Adapter

[Homoran]

@achim-baecker oops - Steilvorlage!?

@achim-baecker sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:

für jede Aufgabe gibt es unterschiedliche Werkzeuge...

so ist es!

so wie es für alles entsprechende Einheiten gibt

@achim-baecker sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:

Solar-Stromüberschuss" 1800W/h

die kenne ich nicht! Wohl eher W

@achim-baecker sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:

dann haben wir 0,5W aus dem Netz ziehen müssen.

das wäre dann die Arbeit in Wh, was wiederum die Dimension der Aktion verdeutlicht! Der Arbeitspteis wird in 1000Wh = kWh gerechnet, ist dieser Mehrbezug von

@achim-baecker sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:

bei 0,5s wären es nur 0,25W

...Wh gerade mal 1/4000 des Arbeitspreises. bei der Einfachheit 40ct / kWh ist das 1/100 ct!
Womit wir mit

@achim-baecker sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:

ein Zyklus von >= 5s mehr als ausreichend ( wären dann 2,5W)

bis auf die Einheit wieder einer Meinung sind.

@achim-baecker sagte in Datenpunkte zyklisch oder ereignisgesteuert lesen:

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.

Danke!
genauso war es gemeint.

[hub01]

Auch wenn ich viel dagegenrede, lass ich mir die ganzen Kommentare schon durch den Kopf gehen und versuch, das Beste rauszuholen.
Das Lesen der Datenpunkte (das eigentliche Problem) ist schon umgestellt. Bedienungen von der Visu stell ich noch um. Speziell die 500ms Routinen überdenke ich nochmal. Beim Rest sehe ich erst mal nicht das große Problem.
Am Ende muss ich mit dem, was ich da programmiere, zurechtkommen und auch in einem Jahr noch verstehen.
Dies ist mein erstes Skript in dieser Art (Webprogrammierung, Javascript).

Ich denke, dass jeder soweit seinen Standpunkt eingebracht hat.
Ich bedanke mich bei Allen für die rege Diskussion und würde hiermit das Thema abschließen.