DOIF: Beim Initialisieren ohne Trigger sich den CMD-Timer suchen

Begonnen von FunkOdyssey, 14 Oktober 2015, 17:47:39

Vorheriges Thema - Nächstes Thema

FunkOdyssey

Hmm, keine Ahnung, ob ich den Betreff richtig formuliert habe.

Ich habe öfters mit der Situation zu kämpfen, dass ich DOIFs über das Attribut "disable" stoppe und wieder starte. Beispielsweise um Regelungen von Automatik-Timer-Betrieb temporär auf Manuellbetrieb umzustellen. Das aber nur am Rande.

Nehmen wir mal an, ich hätte folgende Zeiträume im DOIF-Def:

Timer 1  08:00 - 12:00
Timer 2  12:00 - 18:00
Timer 3  18:00 - 22:00
Timer 4  22:00 - 08:00


Das DOIF trigger ja normalerweise durch das Erreichen der Zeiten. Wenn ich das DOIF nun aber deaktiviert hatte, wie könnte dann beim Aktivieren der richtige Zeitraum gefunden werden.

Beispiel:
- DOIF wird aktiviert um 15:00 Uhr
- Also muss ich derzeit bis 18:00 Uhr warten, da dann erst getriggert wird
- Wie mann ich aber das cmd2 erzwingen?

Wahrscheinlich ist der Tipp nun, das DOIF über "set xyz disable" und "set xyz initialize" ein- und auszuschalten. Aber auch dann muss ich auf den nächsten Trigger warten.

Hat jemand eine Idee? Danke.

Brockmann

Zitat von: CommandRef
Deaktivieren des Moduls

Ein DOIF-Modul kann mit Hilfe des Attributes disable, deaktiviert werden. Dabei werden alle Timer und Readings des Moduls gelöscht. Soll das Modul nur vorübergehend deaktiviert werden, so kann das durch set <DOIF-modul> disable geschehen. Hierbei bleiben alle Timer aktiv, sie werden aktualisiert - das Modul bleibt im Takt, allerding werden keine Befehle ausgeführt. Das Modul braucht mehr Rechenzeit, als wenn es komplett über das Attribut deaktiviert wird. In beiden Fällen bleibt der Zustand nach dem Neustart erhalten, das Modul bleibt deaktiviert.

Initialisieren des Moduls

Mit set <DOIF-modul> initialize wird ein mit set <DOIF-modul> disable deaktiviertes Modul wieder aktiviert. Das Kommando set <DOIF-modul> initialize kann auch dazu genutzt werden ein aktives Modul zu initialisiert, in diesem Falle wird der letzte Zustand des Moduls gelöscht, damit wird ein Zustandswechsel herbeigeführt, der nächste Trigger führt zur Ausführung.

FunkOdyssey

So, ich habe jetzt ein komplexeres DOIF-Konstrukt umgebaut, so dass ich diese per "intialize/disable" ändern kann.
Mich persönlich stört es dabei aber, dass das DOIF, welches ich "intialize" habe, dann auch den nächsten Trigger (hier: Timer) wartet.
Mir wäre es ganz lieb, dass das DOIF sich merkt, dass es eigentlich in z.B. cmd_2 starten sollte.

Damian

Zitat von: FunkOdyssey am 10 Mai 2016, 18:39:01
So, ich habe jetzt ein komplexeres DOIF-Konstrukt umgebaut, so dass ich diese per "intialize/disable" ändern kann.
Mich persönlich stört es dabei aber, dass das DOIF, welches ich "intialize" habe, dann auch den nächsten Trigger (hier: Timer) wartet.
Mir wäre es ganz lieb, dass das DOIF sich merkt, dass es eigentlich in z.B. cmd_2 starten sollte.

Ich werde zukünftig set activate einbauen. Dabei wird der letzte Zustand vor set disable erhalten bleiben, so dass ohne do always nur beim Zustandswechsel geschaltet wird.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

FunkOdyssey

Sehr geil.
Und so weiß ich auch, dass ich nichts falsch gemacht habe. :-)