Hallo Dietmar,
anbei ein Patch für WeekdayTimer, der u.A. das hier beschriebene Problem (https://forum.fhem.de/index.php/topic,46322.msg380855.html#msg380855) angeht. Durch den Patch wird der WeekdayTimer so erweitert, dass über zwei neue Attribute ein leicht geändertes Verhalten gesteuert werden kann:
- delayedSkipOver (default: 0 = bisheriges Verhalten) bewirkt, dass nach Beendigung eines aktiven delayedExecutionCond lediglich das letzte Schaltevent ausgelöst wird. Alle davor liegenden Schaltevents, die durch delayedExecutionCond blockiert wurden, werden ignoriert.
- delayedAtFixedIntervals (default: 0 = bisheriges Verhalten) sorgt bei aktivem delayedExecutionCond dafür, dass die erneute Prüfung der Bedingung in 60-Sekunden-Abständen zur ursprünglich festgelegten Schaltzeit erfolgt (statt zufälligen 55-65 Sekunden). Dies kann notwendig sein, damit delayedSkipOver zuverlässig funktioniert.
In meiner Installation führt die gepatchte Version des Moduls seit einigen Tagen zu einer zuverlässigen Steuerung der Rollläden am Morgen:
Normalerweise werden die Rollos alle abhängig vom Sonnenaufgang in zwei Schritten hochgefahren: Zunächst ein wenig (20%), dann ganz auf. Solange der Wecker noch nicht geläutet hat, verhindert eine delayedExecutionCond-Funktion das zu frühe Hochfahren. Davon können beide Schaltevents betroffen sein, und sobald die Freigabe erfolgt ist, kann mit der bisherigen Implementierung nicht sichergestellt werden, dass die beiden ausstehenden Schaltevents in der richtigen Reihenfolge ausgelöst werden. So kommt es unregelmäßig vor, dass die Rollos zunächst ganz hoch und dann wieder fast nach unten gefahren werden. Dies läßt sich auch durch eine geschickte Wahl der Schaltzeiten nicht verhindern.
Anders verhält es sich, wenn die beiden neuen Attribute gesetzt sind: Solange die delayedExecutionCond aktiv ist und mehr als ein Schaltevent aufläuft, wird der Timer für das ältere Schaltevent gelöscht. Sobald delayedExecutionCond inaktiv wird, ist nur noch ein Event übrig, das bei der nächsten Prüfung ausgelöst wird. In meinem Fall fährt das Rollo ganz auf.
Es würde mich freuen wenn mein Vorschlag Eingang in die offizielle Modulversion fände.
Beste Grüße,
Andy.
kannst du mir die ganze Datei 98_WeekdayTimer.pm zusenden. Dann kann ich besser vergleichen
Ich finde deine Änderungen so gut und richtig, dass ich sie grundsätzlich ohne Attribut in den Code übernehmen würde.
Also grundsätzlich immer fester Abstand zwischen den delays.
Ein nachfolgender timer überschreibt immer den Vorgänger, wenn er wegen eines delays nicht ausgeführt wurde. So war es schon einmal als der Algorithmus völlig anders aufgebaut war.
Wäre das in deinen Sinne?