[gelöst] dynamischer Cronjob, wie?

[metaxa]

@martinp mir scheint ein Cron besser geeignet, da - ja ein einmaliges Ereignis - am nächsten Tag zu unterschiedlichen Zeiten starten soll.

Vor Timern habe ich immer etwas Respekt, die können falsch angewendet oder nicht richtig gestoppt ziemlichen Ärger verursachen. Obendrein müsste ich das Script deutlich um eine Berechnung des Timers erweitern. Um 17:01 hole ich mir die Werte, wann am nächsten Tag zur vollen Stunde etwas passieren soll.

[Asgothian]

@metaxa sagte in dynamischer Cronjob, wie?:

@Codierknecht und @Alle

• Darf/Kann ich einen 2. Cronjob innerhalb eines Cronjobs packen, der erst morgen startet?

Bedingt. In diesem Fall: Ja. Du stellst sicher das sich die Einträge nicht vermehren. Es kann allerdings passieren das der innere Cron-Job nicht zum Zuge kommt, wenn seine Ausführung "nach" dem nächsten Ausführen des äusseren Cron Jobs geplant ist.

• Werden einem Cronjob seine ToDo´s mitgegeben, oder sucht er beim Start sein Ursprungsscript und führt dann die dortigen Anweisungen durch?

Es werden immer die zum Zeitpunkt der Ausführung relevanten Werte genommen. Wenn du auf die Werte der Datenpunkte beim Erstellen des Cron-Jobs zugreifen willst musst du diese lesen und in lokale Variablen schreiben auf die der Cron-Job dann zugreift. Allerdings musst du aufpassen - änderst du diese Variablen im Skript bevor der Cron-Job zum Zuge kommt nimmt er die geänderten Werte.

Der Cron Job bekommt meines Wissens keinen eigenen Kontext mit eigenen Variablenspeichern.

LG

[MartinP]

@metaxa Hier SOLLEN die Timer ja ausgeführt werden, im Falle von Timeout-Überwachungen für Ereignisse muss man natürlich im Gegensatz dazu darauf achten, den Timer zu entschärfen, wenn das überwachte Ereignis eingetreten ist ...

Die Herde von Cron-Jobs muss man ja auch hüten

[metaxa]

@asgothian sagte in [gelöst] dynamischer Cronjob, wie?:

Es kann allerdings passieren das der innere Cron-Job nicht zum Zuge kommt, wenn seine Ausführung "nach" dem nächsten Ausführen des äusseren Cron Jobs geplant ist.

Danke, dass hatte ich nicht im Blickfeld. Da muss ich mir überlegen, wie ich das ggf. umgehen kann, wenngleich der Cronjob zimlich sicher vor der nächsten Scriptausführung um 17:00 startet. Da muss ich noch grübeln.

@asgothian sagte in [gelöst] dynamischer Cronjob, wie?:

Der Cron Job bekommt meines Wissens keinen eigenen Kontext mit eigenen Variablenspeichern.

Danke!

@martinp sagte in [gelöst] dynamischer Cronjob, wie?:

Hier SOLLEN die Timer ja ausgeführt werden

Ich fürchte ich verstehe dich nicht, was aber eher an meiner Unerfahrung mit Timern liegt und nicht an deinen Ausführungen.

[MartinP]

@metaxa Wenn ich das richtig verstehe, holst Du Dir zwei Zeitpunkte für die kommenden 24 Stunden, wo der Strom sehr günstig ist, und möchtes dann Aktionen Auslösen, wenn die Zeitpunkte gekommen sind (auch welche, wenn der Strom wieder teurer wird?)

Da könnte man natürlich auch Timeouts von Timern bei der Ermittlung gleich so berechnen, dass die beim Erreichen der Zeit abgelaufen sind ...

Wenn die Genauigkeit nicht so wichtig ist: Eine andere, etwas stumpfe Möglichkeit wäre, stumpf zu "pollen". Ein z. B. minütlich startender Cron-Job prüft, ob die aktuelle Zeit innerhalb eines Zeitintervalls "guten Strompreises" ist .... ansonsten wird nichts getan ...

[metaxa]

@martinp sagte in [gelöst] dynamischer Cronjob, wie?:

holst Du Dir zwei Zeitpunkte für die kommenden 24 Stunden, wo der Strom sehr günstig ist, und möchtes dann Aktionen Auslösen, wenn die Zeitpunkte gekommen sind (auch welche, wenn der Strom wieder teurer wird?)

Exakt: mein akt. Stromprovider stellt mir tgl. um 17:00 die stündlichen Stromtarife des kommenden Tages zur Verfügung. Die hole ich mir und parse sie in DP von 00 - 23 Uhr. Danach suche ich mir den günstigsten und den 2.günstigsten Preis raus. Der 2. günstigere ist eher nur eine Fleißaufgabe, verwende ich aber nicht wirklich. Am nächsten Tag zum Zeitpunkt xx:00 lade ich dann meine Akkus im Keller auf um den Rest des Tages vom relativ günstigen Einkauf zu leben. Das Vollpumpen der Akkus im Winter hat auch den Vorteil, dass diese regelmäßig kalibriert werden.

In meinem Script fülle ich den 2. Cron mit den Daten des errechneten günstigsten Preises.

@martinp sagte in [gelöst] dynamischer Cronjob, wie?:

Da könnte man natürlich auch Timeouts von Timern bei der Ermittlung gleich so berechnen, dass die beim Erreichen der Zeit abgelaufen sind ...

Das ist gar nicht nötig, die Vollladung meiner kleinen Akkukapazität ist erfahrungsgemäß in max. 70 oder 80 Minuten erledigt. Dass die 10 - 20 Minuten in den nächsten Tarif rutschen krazt mich nicht besonders.

@martinp sagte in [gelöst] dynamischer Cronjob, wie?:

.... ansonsten wird nichts getan ...

jein, erst béim Erreichen des manuellen Ladezeitpunkts prüfe ich noch etliche Parameter ob eine Volladung sinnvoll ist. Aktuell beinhaltet die Prüfung paar Parameter meiner PV (unter anderen den SOC Wert). Aktuell bin ich noch am Überlegen auch den zu erwartenden Sonnenertrag des kommenden Tages miteinfließen zu lassen und die Akkus im Falle des Falles mnur bis zu 70% oder 80% zu laden, in der Hoffnung die Tagessonne erledigt dann die Differenz. Bei einer Volladung hatte ich jetzt schon paar mal die Situation, die Akkus waren gut gefüllt als die Sonne kam und ich schickte dann wieder überschüssige Energie zu einem schlechten Preis ins Netz. Das versuche ich zu umgehen.

Sorry für den langen Text.

[MartinP]

@metaxa Wenn das alles zeitlich nicht so genau sein muss, wäre der "Polling" Ansatz vielleicht gar nicht so schlecht...

Ein Cron-Skript was stumpf alle 5 Minuten aufgerufen wird, und schaut, ob der Zeitpunkt für günstigen Strom schon gekommen ist.

[Codierknecht]

@metaxa
Vielleicht in der Art?

Um 17:00 Uhr wird der Tarif analysiert und ein genau dazu passender Zeitplan "laden" erstellt.
Der wird um 17:00 Uhr erstmal beendet, da er ja neu berechnet werden muss.

[MartinP]

@codierknecht Wenn man in den hellblauen Feldern auch berechnete Strings eintragen kann, wäre das wirklich die naheliegende Lösung.
Ich hatte da mit mehr Limitierungen gerechnet ...

[Codierknecht]

@martinp sagte in dynamischer Cronjob, wie?:

Wenn man in den hellblauen Feldern auch berechnete Strings eintragen kann

Nicht strings - Zahlenwerte.

Wie die zu berechnen sind, weiß der TE am besten.
Hier wird der Ladevorgang nach 60 Minuten beendet. Ob man das so oder besser anders macht, muss er entscheiden.
Kann ja auch ein weiterer CRON "ladenBeenden" sein.

[metaxa]

@martinp die Lösung von @Codierknecht gefällt mir auch sehr gut, auch wenn ich sie noch nicht ganz behirnt habe. Jedoch laufe ich unter Umständen in die von @Asgothian augezeigte Problematik, falls der günstigste Tarif des morgigen Tages NACH dem morgigen Lauf des Scripts "Zeitplan laden" liegt.

Ich muss den Vorschlag von @Codierknecht erst vollständig durchschauen ........

[Codierknecht]

@metaxa sagte in dynamischer Cronjob, wie?:

falls der günstigste Tarif des morgigen Tages NACH dem morgigen Lauf des Scripts "Zeitplan laden" liegt.

Dann erzeuge den neuen CRON doch erst nach 23:00 Uhr.
Du erhältst die neuen Zahlen AB 17:00 Uhr. WANN der CRON für den Folgetag erstellt wird, ist doch Wumpe.

[metaxa]

@codierknecht

[MartinP]

@codierknecht said in dynamischer Cronjob, wie?:

@martinp sagte in dynamischer Cronjob, wie?:

Wenn man in den hellblauen Feldern auch berechnete Strings eintragen kann

Nicht strings - Zahlenwerte.

Sicher?

Ich habe mir da extra etwas gebastelt, und der generierten Javascript-Code nutzt ...toString() bei der Parametrierung des Cron aus den Werten ....

Karnevalsbeginn-Erinnerung

Javascript-Ansicht:

schedule1 = schedule(11.toString().trim() + ' ' + 11.toString().trim() + ' ' + 11.toString().trim() + ' ' + 11.toString().trim() + ' ' + '*'.toString().trim(), async () => {
});

[Codierknecht]

@martinp sagte in dynamischer Cronjob, wie?:

der generierten Javascript-Code nutzt ...toString() bei der Parametrierung des Cron

Ich hätte da numerisch Werte erwartet.
Muss aber gestehen, dass ich das nicht weiter geprüft habe.

Dann nimm halt Strings ...

Wenn man nochmal drüber nachdenkt ist's ja auch logisch - könnte ja auch '*' sein.

Trotzdem baut Blockly da seltsame Dinge zusammen und macht aus einem String erstmal ... einen String. Interessant

'5'.toString().trim() + ' ' + '4'.toString().trim() + ' ' + '3'.toString().trim() + ' ' + '2'.toString().trim() + ' ' + '1'.toString().trim();

[MartinP]

@codierknecht wirklich interessant - aber fällt ja nicht auf - wer guckt schon unter die Motorhaube

[Codierknecht]

@martinp sagte in dynamischer Cronjob, wie?:

wer guckt schon unter die Motorhaube

Jepp - letztlich ist es gehopst wie gesprungen. Ob String oder Zahl ist da eigentlich ziemlich egal.