Hallo und ein gutes neues Jahr.
Ich habe zwei ats, die nach folgendem Beispiel definiert sind: define MeineAktion at *{ReadingsVal("Dummy","Zeit","")} ...
Die zugehörigen Readings werden morgens gegen 01:30 festgelegt.
Jetzt ist mir mehrfach aufgefallen, dass das für die Festlegung des nächsten Starttermins der ats zu spät zu sein scheint. Es galt dann noch die Zeit des Vortags.
Das computeAfterInit ist bei beiden ats auf 1 gesetzt.
Die Frage ist, wann wird bei einem at, dass seinen Zeitpunkt aus einem Reading bestimmt, wann dieses Reading ausgelesen wird, um den nächsten Startpunkt zu ermitteln?
Und wie kann man das selbst beeinflussen, wenn das Reading später geändert werden sollte?
Beholfen habe ich mich mit folgendem Aufbau: set atMorgens1 modifyTimeSpec 09:30
Das scheint aber andere Nebenwirkungen zu haben. Heute morgen war nach dem Setzen der Readings ein Neustart des gesamten PIs und es waren die Zeiten von gestern drin.
Danke und ein schönes Wochenende
Jürgen
Die Berechnung der nächsten Ausführungszeit bei einem periodischen at erfolgt während bzw. nach der Ausführung des at. Genau deshalb würde ich grundsätzlich niemals ein bestehendes at zu irgendeinem Zeitpunkt mit dem Wert eines fremden Readings verändern.
Zitat von: jhohmann am 06 Januar 2024, 15:10:30Die zugehörigen Readings werden morgens gegen 01:30 festgelegt.
Warum legst Du das at nicht einfach in diesem Vorgang als einmalig auszuführendes at an?
Es sind so um die 6 und 20 Zeilen Code. Die müssten dann in die myUtils.
Es gibt ja auch Beispiele von ats zu sunrise oder Sunset.
Die würden dann bei periodischen ats immer zu sunrise von heute am nächsten Tag ausgeführt werden, oder? Fände ich einen wichtigen Hinweis in der Doku.
Danke für die Antwort.
Muss ich mir überlegen, wie ich das für mich löse.
sunrise() und sunset() sind vollständig "at-kompatibel" weil sie vom gleichen Entwickler stammen.
Die Uhrzeit für sunrise() wird immer zum nächsten Sonnenaufgang berechnet. Wenn Du also morgens um 03:00 Uhr sunrise() aufrufst, wirst Du die Uhrzeit für den gleichen Tag bekommen.
Rufst Du sunrise() zu einem Zeitpunkt NACH erfolgtem Sonnenaufgang auf, wird die Uhrzeit für den nächsten Tag berechnet.
Kannst Du leicht überprüfen, wenn Du jetzt in die FHEM Befehlszeile mal {sunrise()} eingibst, da kommt etwas wie "31:45:11" was erstmal nach einer unsinngigen Uhrzeit aussieht.
Zieht man davon aber 24 Stunden ab, kommt 07:45:11 raus - und das ist (für meinen Standort) die Uhrzeit für den Sonnenaufgang morgen früh.
Ein at würde das automatisch korrekt verarbeiten.
Schwierig wird es bei periodischen at immer dann, wenn man versucht, das mit eigenen Funktionen zu versorgen, wenn sich dann auch noch die Zeitpunkte zwischen zwei Ausführungszeiten dynamisch verändern. Sowas löse ich bei mir immer mit "Einmal-at" devices, das ist einfach zuverlässiger und bei einer Fehlersuche übersichtlicher und logischer zu verstehen.