Hallo zusammen,
zur Vermeidung von Fehlmeldungen meiner Emaillogiken direkt nach dem Neustart des smarthome.py services hatte ich vor eine Art Karenzzeit nach dem Servicestart einzubauen unter Verwendung von sh.env.core.start().
Hintergrund: Die Logiken werden beim Servicestart ja einmalig getriggert und so wurden kiloweise Mails generiert wenn das überwachte Item bspw. schon wahr war.
Zum Abfangen wollte ich folgenden Code verwenden, welcher auch zur normalen Laufzeit einwandfrei funktioniert:
Bei einem echten Serviceneustart wirft es allerdings einen Fehler in der Zeile für die Def. von DelayAfterSystemstart:
Die Logik wird via watch_item = xxx angesprochen und funktioniert wie gesagt nach dem Systemstart später einwandfrei.
Ist das ein Timingproblem?
Gibt es eine andere Methode die initialen Logiktriggerungen zu vermeiden bzw. eine Art "Delay after Servicestart" in einer Logik zu implementieren?
Bin wie immer für alle Hints und Tipps dankbar!
Cheers,
Oliver
zur Vermeidung von Fehlmeldungen meiner Emaillogiken direkt nach dem Neustart des smarthome.py services hatte ich vor eine Art Karenzzeit nach dem Servicestart einzubauen unter Verwendung von sh.env.core.start().
Hintergrund: Die Logiken werden beim Servicestart ja einmalig getriggert und so wurden kiloweise Mails generiert wenn das überwachte Item bspw. schon wahr war.
Zum Abfangen wollte ich folgenden Code verwenden, welcher auch zur normalen Laufzeit einwandfrei funktioniert:
Code:
.... DelayAfterSystemstart = sh.env.core.start() + dateutil.relativedelta.relativedelta(seconds=300) if sh.now() > DelayAfterSystemstart: .....
Code:
File: /usr/smarthome/lib/3rd/dateutil/relativedelta.py, Line: 246, Method: __radd__, Exception: unsupported type for add operation
Ist das ein Timingproblem?
Gibt es eine andere Methode die initialen Logiktriggerungen zu vermeiden bzw. eine Art "Delay after Servicestart" in einer Logik zu implementieren?
Bin wie immer für alle Hints und Tipps dankbar!
Cheers,
Oliver
Kommentar