DOIF: neue Zeit-Features

[satprofi]

Das wird auch nix. 

glaub ich nicht.

das funktioniert auch

Code Auswählen Erweitern


([Pac] > 2500 and [08:00-22:00]) (set LED_01 led green)
DOELSEIF ([Pac] > 1000 and [08:00-22:00]) ( set LED_01 led orange)
DOELSEIF ([Pac] < 1000 and [08:00-22:00]) (set LED_01 led red)

[flurin]

So könnte es klappen:

Code Auswählen Erweitern


define di_WM DOIF ([WM_SenPwr] == 0)
  (setreading Waschmaschine state off)
DOELSEIF ([WM_SenPwr] > 5)
  (setreading Waschmaschine state running)
DOELSEIF ([WM_SenPwr] < 5 and [Waschmaschine] eq "running")
  (setreading Waschmaschine state finished)
DOELSEIF ([Waschmaschine] eq "finished")
  (setreading Waschmaschine state standby)
attr di_WM wait 0:0:0:5400


[tomster]

Flurin, das funktioniert genauso wie ich es mir vorgestellt habe. Vielen Dank!

Hab das wait noch nach 0:0:300:5400 angepasst, damit das finished auch wirklich finished anzeigt.

[flurin]

Flurin, das funktioniert genauso wie ich es mir vorgestellt habe. Vielen Dank!

Hab das wait noch nach 0:0:300:5400 angepasst, damit das finished auch wirklich finished anzeigt.

Okey, mit Event monitor würde ich mal untersuchen, wie oft "Waschmaschine" gesetzt wird.
Vermutlich wird bei jeder WM_SenPwr-Änderung getriggert.
Wie ist der Bereich von WM_SenPwr? 0 bis xxx

[tomster]

Okey, mit Event monitor würde ich mal untersuchen, wie oft "Waschmaschine" gesetzt wird.
Vermutlich wird bei jeder WM_SenPwr-Änderung getriggert.
Wie ist der Bereich von WM_SenPwr? 0 bis xxx

Ja, es wird bei jeder Änderung getriggert. Im "Leerlauf" hab ich fast immer Werte zwischen 3.87 und 3.89. Ein event-on-change-reading mit entsprechendem Bereich dürfte die Trigger deutlich reduzieren. Probier ich mal.
Die Werte gehen laut offiziellen Angaben von eq-3 von 0-3680 Watt. Ich hab aber auch schon Werte um die 4500 Watt gesehen...

[flurin]

Ja, es wird bei jeder Änderung getriggert. Im "Leerlauf" hab ich fast immer Werte zwischen 3.87 und 3.89. Ein event-on-change-reading mit entsprechendem Bereich dürfte die Trigger deutlich reduzieren. Probier ich mal.
Die Werte gehen laut offiziellen Angaben von eq-3 von 0-3680 Watt. Ich hab aber auch schon Werte um die 4500 Watt gesehen...

... zusätzlich könnte man das DOIF optimieren:

Code Auswählen Erweitern


define di_WM DOIF ([WM_SenPwr] == 0 and [?Waschmaschine] ne "off")
  (setreading Waschmaschine state off)
DOELSEIF ([WM_SenPwr] > 5 and [?Waschmaschine] ne "running")
  (setreading Waschmaschine state running)
DOELSEIF ([WM_SenPwr] < 5 and [?Waschmaschine] eq "running")
  (setreading Waschmaschine state finished)
DOELSEIF ([Waschmaschine] eq "finished")
  (setreading Waschmaschine state standby)
attr di_WM wait 0:0:300:5400


[Ralli]

Mal was anderes. Ich habe einen 2er-Taster, auf den ein DOIF reagiert. Und zwar immer gleich, mit einem set blabla toggle.

Das DOIF habe ich mit do always definiert. Klappt auch alles einwandfrei. Nun meine Verständnisfrage.

Angenommen, es wird jetzt (aus Versehen) ein Doppeltaster gedrückt, wie kann ich das verhindern? Ich habe es mit

cmdpause 3
repeatsame 1
do resetwait (oder always)

versucht, das funktioniert nicht - hier wird immer nur ein einziges mal der Toggle ausgeführt (denn der State ändert sich ja nicht). Wo ist mein Denkfehler?

[Pfriemler]

Okey, mit Event monitor würde ich mal untersuchen, wie oft "Waschmaschine" gesetzt wird.
Vermutlich wird bei jeder WM_SenPwr-Änderung getriggert.

Das DOIF ja, aber solange sich der State des DOIFs nicht ändert, (also auch wenn seine Bedingung immer und immer wieder zutrifft) wird sein Ausführungsteil auch nicht erneut ausgeführt. Außer es wäre "do always" gesetzt, was hier aber gerade keinen Sinn macht.

Im übrigen meine ich mich zu erinnern, dass das DOIF den State einnimmt, der nach den Bedingungszweigen als erstes zutrifft, alle anderen werden ignoriert. Wenn man die Bedingung nach "Leistung = 0" also vor der Abfrage "Leistung <5" einträgt, sollte es auch klappen.

[Pfriemler]

cmdpause 3
repeatsame 1
do resetwait (oder always)
... funktioniert nicht - hier wird immer nur ein einziges mal der Toggle ausgeführt Wo ist mein Denkfehler?

Mein Denkfehler (oder auch nicht) wäre "cmdpause 3" plus "do always", mehr nicht. cmdpause verzögert im Gegensatz zu wait nicht die Ausführung, sondern unterdrückt erneute Ausführungen für die Wartezeit.
repeatsame 1 hingegen sorgt dann dafür, dass es genau nur einmal funktioniert.

[Ralli]

Danke, Pfriemler.

Und ich dachte, repeatsame 1 würde bedeuten, dass innerhalb der mit cmdpause 3 eingestellten Wartezeit das Kommando nur einmal in drei Sekunden ausgeführt wird und danach der Zähler wieder zurückgesetzt wird.

Ich probiere .

Bezüglich Deiner anderen Antwort: So sollte es sein. Interessanterweise habe ich mit folgendem DOIF aber eine andere Erfahrung gemacht:

Code Auswählen Erweitern


([05:00|8] and [?FL_Rollo] eq "off") (set FL_Treppenlicht 30) DOELSEIF ([06:00|7] and [?GEN_Aussensensor:luminosity] > 10 and [?FL_Rollo] eq "off") (set FL_Rollo Schlitz) DOELSEIF ([06:00|7] and [?FL_Rollo] eq "off") (set FL_Treppenlicht 20)


Die logische Denkweise sagt, dass die erste Bedingung geprüft wird, nur dann, wenn die erste nicht zutrifft, die zweite und nur dann, wenn auch die nicht zutrifft, die dritte. Fakt ist aber, dass bei Nichtzutreffen der ersten Bedingung die zweite und die dritte immer beide angetriggert werden und den Ausführungsteil ausführen, wenn [?GEN_Aussensensor:luminosity] > 10, sonst natürlich nur die dritte.

Normalerweise sollte bei [?GEN_Aussensensor:luminosity] > 10 nach der zweiten Bedingung Schluss sein. Der Zeittrigger in der dritten Bedingung sorgt aber wohl trotzdem für ein Ausführen. Darum habe ich in der dritten dann noch ein [?GEN_Aussensensor:luminosity] <= 10 ergänzt.

[Pfriemler]

Zeitangaben im DOIF setzen interne Timer. Geprüft werden natürlich alle Bedingungen in den Zweigen. Im zweiten checkst du wochends um 6 Außenlicht und Rollo. Trifft alles zu, wird auf Schlitz gefahren. Wenn nicht, wird Zweig 3 gecheckt und ggf. ausgeführt.  Der ist die Alternative zu Zweig 2 und kommt dann zur Anwendung, wenn Außenlicht < 11 ist. Alles logisch.
Würdest Du Zweig 3 und 2 tauschen, würde unabhängig vom Außenlicht immer Zweig 2 greifen (bei FL_Rollo off)...

Du meinst jetzt aber, Zweig drei wird ohne den Test auf Helligkeit auch bei Helligkeit >10 ausgeführt?

Das ist unlogisch ...

edit: falls DOIF zwei Timer setzt (für die beiden Zweige quasi als Wecksignal je einen), um damit die Zweige zwei und drei nacheinander zu prüfen, würden evtl.  beide zutreffen und das DOIF zuerst auf 2, dann sofort auf 3 wechseln - faktisch beide ausführen. Dann führt aber das ELSE IF irgendwie logisch in die Irre... wäre praktisch eher ein DOALSOIF.
Und was sagt der Sprecher?

[Damian]

Zeitangaben im DOIF setzen interne Timer. Geprüft werden natürlich alle Bedingungen in den Zweigen. Im zweiten checkst du wochends um 6 Außenlicht und Rollo. Trifft alles zu, wird auf Schlitz gefahren. Wenn nicht, wird Zweig 3 gecheckt und ggf. ausgeführt.  Der ist die Alternative zu Zweig 2 und kommt dann zur Anwendung, wenn Außenlicht < 11 ist. Alles logisch.
Würdest Du Zweig 3 und 2 tauschen, würde unabhängig vom Außenlicht immer Zweig 2 greifen (bei FL_Rollo off)...

Du meinst jetzt aber, Zweig drei wird ohne den Test auf Helligkeit auch bei Helligkeit >10 ausgeführt?

Das ist unlogisch ...

edit: falls DOIF zwei Timer setzt (für die beiden Zweige quasi als Wecksignal je einen), um damit die Zweige zwei und drei nacheinander zu prüfen, würden evtl.  beide zutreffen und das DOIF zuerst auf 2, dann sofort auf 3 wechseln - faktisch beide ausführen. Dann führt aber das ELSE IF irgendwie logisch in die Irre... wäre praktisch eher ein DOALSOIF.
Und was sagt der Sprecher?

Zur Zeit wird für jede Zeitangabe ein separater Timer gesetzt. Geprüft wird grundsätzlich nur die Bedingung zum ausgelösten Timer.

Wenn man in zwei Bedingungen die gleiche Zeit angibt (hier 06:00 Uhr), so triggert das Modul zwei mal. Dabei ist bei gleicher Zeit die Reihenfolge des Triggerns nicht gewährleistet. Es kann also passieren, dass beim ersten Trigger Zweig 3 ausgeführt und beim zweiten Zweig 2.

Zukünftig will ich nur einen Timer für gleiche Zeit aufsetzen (damit würde man nur einmal triggern) und damit die Reihenfolge der Abarbeitung sicherstellen und es würde zum gleichen Zeitpunkt höchsten nur ein Zweig ausgeführt werden - der erste, für den die Bedingung wahr ist (wie man es eigentlich erwartet).

Gruß

Damian

[Pfriemler]

Danke für die Bestätigung. Kann Dich nur ermutigen das umzusetzen. Bleibt zu hoffen, dass nur wenige dieses Verhalten vielleicht trickreich ausgenutzt haben und dann auf die Nase fallen. Rallis DOIF würde aber auch dann weiter funktionieren.

geht nich Gips nich ...

[Damian]

Danke für die Bestätigung. Kann Dich nur ermutigen das umzusetzen. Bleibt zu hoffen, dass nur wenige dieses Verhalten vielleicht trickreich ausgenutzt haben und dann auf die Nase fallen. Rallis DOIF würde aber auch dann weiter funktionieren.

geht nich Gips nich ...

Da die Reihenfolge der Abarbeitung bei gleicher Zeit nicht gewährleistet ist, kann man es eigentlich nicht sinnvoll ausnutzen. Will man jetzt schon die Reihenfolge sicherstellen, so muss man leicht versetzte Zeiten angeben z. B. 06:00 Uhr im zweiten Fall und 06:00:01 Uhr im dritten.

Gruß

Damian

[flurin]

Das DOIF ja, aber solange sich der State des DOIFs nicht ändert, (also auch wenn seine Bedingung immer und immer wieder zutrifft) wird sein Ausführungsteil auch nicht erneut ausgeführt. Außer es wäre "do always" gesetzt, was hier aber gerade keinen Sinn macht.

Ja klar. Die vorgeschlagene "Schaltung" konnte ich ohne Gerät nicht ausführlich testen. Es kommt nicht selten vor, dass in der Praxis unerwartete Effekte auftauchen. Im Event Monitor nachzuschauen, ist immer hilfsreich.

Im übrigen meine ich mich zu erinnern, dass das DOIF den State einnimmt, der nach den Bedingungszweigen als erstes zutrifft, alle anderen werden ignoriert.

Ja, theoretisch. Es wird im Commandref auch ausführlich beschrieben. Ich versuche jedoch, die Abhängigkeit der Reihenfolge zu vermeiden.

Wenn man die Bedingung nach "Leistung = 0" also vor der Abfrage "Leistung <5" einträgt, sollte es auch klappen.

Stimmt nicht! In diesem Beispiel ist die Reihenfolge irrelevant. Folgende Bedingung hat nicht zufällig ein "and":

Code Auswählen Erweitern


DOELSEIF ([WM_SenPwr] < 5 and [?Waschmaschine] eq "running")


Gruss
flurin