Idee Ausführung Skripte analog einer Siemens-SPS
-
@flyer99 sagte in Idee Ausführung Skripte analog einer Siemens-SPS:
Dachte ich mach meine Idee mal kund, mir wurde hier schon immer kompetent geholfen und ich finde das Forum wirklich gut, vielleicht bringt es ja jemandem was ......
Prinzipiell eine interessante Idee. Allerdings muss man diese in 2 unterschiedliche Komponenten teilen:
- Nutzung von Zeitplänen an Stelle von Event-Getriebenen Aktionen
- Auslagern von kurzen Aktionen in externe Skripte die explizit gestartet werden und sich selber wieder beenden.
Eine grosse Zahl von Cron-Zeitplänen kann zu Lastspitzen führen (in deinem Fall alle 5 Minuten, da zu diesem Zeitpunkt alle 4 Cron Skripte laufen). Wie gross diese Lastspitzen sind hängt letztendlich (auch) davon ab was in den einzelnen Skripten passiert. Da kann es Sinnvoll sein durch geeignete CRON Regeln die Aktionen voneinander zu Trennen soweit möglich.
Ein Beispiel aus Deinem Skript:
Welchen Sinn macht es, alle 2 sekunden nachzuschauen ob ein Datenpunkt auf Wahr ist, wenn dieses am Tag nur ein paar mal auftritt. Statt dessen ist es einfacher einen Trigger auf "ist grösser als vorher" zu setzen - damit fängst du den Wechsel von Falsch auf Wahr und kannst deine Aktion direkt (oder zur Not mit 2 Sekunden Verzögerung) ausführen.
Beim 5 Sekunden Zeitplan ist es nicht ganz so einfach da damit offensichtlich eine regelmässige Aktualisierung einer Visualisierung angestossen wird, und die Aktualisierungsgeschwindigkeit der Strommessung wahrscheinlich schneller als einmal alle 15 sekunden ist.
Auch bei dem 15 Sekunden Zeitplanen müsste genau geschaut werden was da wirklich hinter den Skripten steht und wie oft die Strommessung aktualisiert wird um abzuschätzen in wie weit diese Sinnvoll sind.
Das Auslagern in nur kurz aufgerufene Skripte ist im Bezug auf die Lesbarkeit der Skripte wahrscheinlich ein Vorteil. In wie weit der Start eines Skriptes unnötige Last erzeugt kann ich aktuell nicht bewerten. Allerdings gehe ich im Moment davon aus das ein Aufbau bei dem die einzelnen Zeitpläne jeweils ein eigenes Skript mit allen Aktionen darstellen von der Ressourcenauslastung gesamt besser ist.
In dem Zusammenhang ist zu bedenken das ein Skript welches "aktiv" ist aber keine eigenen Aktionen mehr hat (Weil die eigentlichen Aktionen durch kapseln in Zeitplänen oder Triggern ausgelagert wurden) meines Wissens nach nur Speicher und keine Prozessorlast beansprucht.
Ansonsten muss bei dieser Methode noch ein weiterer Hinweis bedacht werden: Sollte ein Skript selber länger laufen als der aufrufende Zeitplan, dann würde dieses Skript nicht neu gestartet. Je nach Aktion kann dieses von Vorteil sein, muss es aber nicht.
Ich gehe mal davon aus das Du das bei Dir berücksichtigt hast - es sollte aber denen die das Konzept nachmachen wollen deutlich gemacht werden.
Ein letzter Punkt noch zu den von Dir aufgerufenen Skripten:
So wie es aktuell geschrieben ist wirst du solangeTasmota Sensor Strom Power_currunter -150 bleibt das SkriptShelly_Garage_Einalle 5 sekunden aufrufen, selbst wenn das Skript selber dann eigentlich nichts macht weil die Aktion ja bereits geschehen ist. Das ist auf jeden Fall unnötig, und gilt analog auch für Shelly_Garage_Aus, Poolpumpe_ein, Trockner_run und Trockner_pause.Wenn du wirklich Prozessorlast minimieren willst solltest Du das noch unterbinden - sprich die skripte nur starten wenn auch eine Aktion notwendig wird.
A.
-
@flyer99 sagte: Ich konnte auch eine Verminderung der Prozessorlast sehen
Das bezweifele ich. Jeder Skriptstart erzeugt eine hohe CPU-Last, da das Skript erst compiliert wird. Das Ausführen per Zeitplan erzeugt ebenfalls Lastspitzen zu festen Zeitpunkten, da mehrere Zeitpläne (nahezu) gleichzeitig auslösen können.
Eine SPS arbeitet zwar zyklisch, der Zyklus wird aber durch die Dauer der Programmabarbeitung bestimmt und liegt im Millisekunden-Bereich. -
@asgothian Hallo asgothian,
Vielen Dank für deine Ausführliche Erläuterung. Das mit den 5 Minuten bei welchen alle 4 Skripte gleichzeitig ausgeführt werden stimmt natürlich, Danke für den Hinweis, hatte ich nicht auf dem Schirm ....Das mit dem 2 Sekunden Aufruf ist mein Garagentor welches ich per Handy auf Ein schalte zum Öffnen oder Schließen und durch das Script wieder auf Aus geschalten wird damit ich nicht am Handy 2x drücken muss. Ist schon 3 Jahre im Einsatz und einfach alt, keine Eltakofunktion .....
Bei den 15 Sekunden Scripts (Verbraucher je nach PV Leistung schalten) wird der aktuelle Stromfluß (Überschuß von PV oder Beziehen von der Straße) natürlich öfters aktualisiert, die 15 Sekunden sollen hier mehr als Hysterese dienen für die Verbraucher.
"Sollte ein Skript selber länger laufen als der aufrufende Zeitplan, dann würde dieses Skript nicht neu gestartet" --> Das ist mir bewusst.
"So wie es aktuell geschrieben ist wirst du solange Tasmota Sensor Strom Power_curr unter -150 bleibt das Skript Shelly_Garage_Ein alle 5 sekunden aufrufen, selbst wenn das Skript selber dann eigentlich nichts macht weil die Aktion ja bereits geschehen ist. Das ist auf jeden Fall unnötig, und gilt analog auch für Shelly_Garage_Aus, Poolpumpe_ein, Trockner_run und Trockner_pause."
--> Aber das ist ja eigentlich der Sinn analog einer SPS, der "Baustein" "Shelly_Garage_Ein" wird zyklisch aufgerufen, das Script selber macht nichts wenn der zu steuernde DP schon auf 1 ist."Wenn du wirklich Prozessorlast minimieren willst solltest Du das noch unterbinden - sprich die skripte nur starten wenn auch eine Aktion notwendig wird."
--> Müssen tu ich das nicht, bin nicht am Limit, ich wollte einfach eine SPS nachbilden.Über was ich mir aber trotzdem noch nicht sicher bin ist die allgemeine Aussage das beim Starten eines Scriptes dieses anscheinend im Ram liegt, der Ram macht aber keine logische Auswertung, das macht trotzdem der Prozessor ...?
Bedeutet für mich ich habe alle Scripts am laufen (also nicht so wie ich es jetzt habe), liegen im Ram, der Prozessor muss alle durchackern immer wieder... Bei mir wird das Script gestartet, Logik ausgewertet und dementsprechend eine Aktion ausgelöst, Script beenden fertig. Erneutes Ackern erst nach x Sekunden/Minuten verstehst was ich meine ?Vielen Dank nochmals für deine Denkanstöße !!!
-
@flyer99 sagte: liegen im Ram, der Prozessor muss alle durchackern immer wieder...
Der Prozessor arbeitet den Inhalt eines Skriptes nur ab, wenn das Trigger-Ereignis vorliegt. Was der Prozessor ständig macht: Auf Ereignisse prüfen.
-
@paul53 Hallo paul53,
Werden die Skripte beim Start immer neu compiliert ??
Die Ausführung mit dem Zeitplan erzeugt Überschneidungen zu welchen mehrere Skripts gleichzeitig ausgeführt werden, das wurde mir klar nach dem Post von Asgothian, vollkommen richtig ..."Eine SPS arbeitet zwar zyklisch, der Zyklus wird aber durch die Dauer der Programmabarbeitung bestimmt und liegt im Millisekunden-Bereich."
--> vollkommen richtig, den Millisekundenbereich werde ich hier auch nicht schaffen , aber vielleicht eine analoge Abarbeitungstechnik. Ich bastel mal weiter, kann ja nicht schaden, man lernt nur dazu ....Danke für Eure Infos ....
-
@flyer99 sagte in Idee Ausführung Skripte analog einer Siemens-SPS:
Über was ich mir aber trotzdem noch nicht sicher bin ist die allgemeine Aussage das beim Starten eines Scriptes dieses anscheinend im Ram liegt, der Ram macht aber keine logische Auswertung, das macht trotzdem der Prozessor ...?
Bedeutet für mich ich habe alle Scripts am laufen (also nicht so wie ich es jetzt habe), liegen im Ram, der Prozessor muss alle durchackern immer wieder... Bei mir wird das Script gestartet, Logik ausgewertet und dementsprechend eine Aktion ausgelöst, Script beenden fertig. Erneutes Ackern erst nach x Sekunden/Minuten verstehst was ich meine ?Ich verstehe was du meinst, du hast aber letztendlich nur bedingt recht.
Skripte die laufen aber auf einen Trigger (via Cron, Zeitplan oder Trigger auf DP) warten werden vom Prozessor nicht ständig durchgearbeitet. Ihr "Einsprungpunkt" wird an eine interne Funktion des JS Controllers weiter gegeben der das Starten zu einer bestimmten Zeit / wenn ein Event eintritt übernimmt.
Dementsprechend hast du also ggf. etwas RAM verbrauch ohne das dieses regelmässig "durchgegraben" wird.
In dem Moment wo ein Skript gestartet wird passiert folgendes:
- Die Datei wird ins Ram geladen
- Der JS code wird kompiliert
- Der JS code wird gestartet
Daraus ergibt sich das beim Laden eines Skriptes erst einmal "overhead" entsteht (Laden und kompilieren) der nicht bei jeder Aktivierung notwendig ist wenn der JS code aus einem immer noch aktiven Skript getriggert wird.
Die Funktion die die Liste der CRON Einträge bzw. Werte Änderungen überwacht ist im JS Controller sowieso immer aktiv.
A.
-
@paul53
Woher weis der Prozessor das ein Trigger ausgelöst wurde ? der Ram sagt es ihm nicht, der Prozessor muss das Skript immer durchackern um ein Trigger zu erkennen ??? -
@flyer99 sagte: Werden die Skripte beim Start immer neu compiliert ??
Sonst könnte für ein deaktiviertes Skript kein RAM freigegeben werden.
-
@flyer99 sagte: der Prozessor muss das Skript immer durchackern um ein Trigger zu erkennen ???
Die Trigger werden vom Compiler an den Kernel von Node.js übergeben, der diese verwaltet: Es müssen nur die Bedingungen geprüft werden, die zu einem Ereignis führen, was in Node.js effizient gelöst ist.
-
Ach Männer, das wollte ich jetzt nicht hören
Aber trotzdem nochmals vielen Dank für die wirklich gute Erklärung, ich glaub ich habs verstanden ...Ein Skript mit Trigger welches ich starte wird kompiliert und hochgeladen, danach gestartet, liegt im Speicher, wird aber nur durchgeackert wenn der JS Controller sagt "mach jetzt".
"Die Trigger werden vom Compiler an den Kernel von Node.js übergeben, der diese verwaltet: Es müssen nur die Bedingungen geprüft werden, die zu einem Ereignis führen, was in Node.js effizient gelöst ist." --> Der gibt dem JS Controller bescheid zum Starten des Skripts ?
-
@flyer99 sagte: Der gibt dem JS Controller bescheid zum Starten des Skripts ?
... zum Auslösen des Ereignisses (Trigger, Ablauf eines Timers, ...) innerhalb des Skriptes.
