Indirekter Zeittrigger mit UNIX Timestamp und Offset

[xenos1984]

Dennoch bleibt für mich die Prämisse, ein Problem möglichst in einem Device umzusetzen und nicht mehrere Devices zu definieren, die man in ein paar Jahren mühselig zusammensuchen muss, wenn man was ändern will.

Genau das ist auch meine Philosophie Lieber ein einziges DOIF, das eine physikalische oder logische Funktion mit allen dazugehörigen Zuständen und Bedingungen für Zustandwechsel abbildet, als mehrere verstreute at und notify, deren Wechselwirkungen man im Auge behalten muss... Für meine bisherigen Anwendungsfälle hat sich das bewährt.

[Per]

mehrere verstreute at und notify

myUtil Schnipsel nicht zu vergessen!
 

deren Wechselwirkungen man im Auge behalten muss.

Das bleibt dir trotzdem lieber nicht erspart, ein Debugging ist, wg der vielen Rückmeldungen, nach der "alten" Methode vllt sogar einfacher.

[Damian]

Das bleibt dir trotzdem lieber nicht erspart, ein Debugging ist, wg der vielen Rückmeldungen, nach der "alten" Methode vllt sogar einfacher.

Debugging ist in FHEM ohnehin schwierig, selbst bei der Modulentwicklung baue ich mir Logausgaben ein, um Dinge im Zweifelsfall nachzuvollziehen. Alternativ zum Loggen kann man sich per set_Reading Dinge in Readings des Moduls anzeigen lassen.

[xenos1984]

Das bleibt dir trotzdem lieber nicht erspart, ein Debugging ist, wg der vielen Rückmeldungen, nach der "alten" Methode vllt sogar einfacher.

Ja, natürlich, aber dann habe ich wenigstens sämtlichen Code in einem Device und nicht auf mehrere verteilt. Und ich kann dafür sorgen, dass zu jedem Zeitpunkt genau ein Zustand aktiv ist, und kann die Bedingungen in der von mir gewünschten Reihenfolge / Priorität abfragen. Einfacherer und übersichtlicherer Code ist eben auch einfacher zu debuggen.

(Natürlich könnte man den auch in eine myUtils Funktion packen. Aber ein DOIF Device hat dann auch noch Eingabefelder für Konfigurationsparameter und Readings, die ich anzeigen kann.)