Hauptmenü

DOIF: neue Zeit-Features

Begonnen von Damian, 29 März 2015, 22:16:05

Vorheriges Thema - Nächstes Thema

satprofi

Zitat von: Ralli am 15 Mai 2015, 14:42:14
Das wird auch nix.  :D

glaub ich nicht.

das funktioniert auch


([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)

gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

flurin

So könnte es klappen:


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

Zitat von: tomster am 15 Mai 2015, 16:16:50
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

Zitat von: flurin am 15 Mai 2015, 16:31:25
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

#80
Zitat von: tomster am 15 Mai 2015, 16:39:43
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:


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?
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

Pfriemler

#82
Zitat von: flurin am 15 Mai 2015, 16:31:25
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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Pfriemler

Zitat von: Ralli am 15 Mai 2015, 19:39:36
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.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Ralli

#84
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:


([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.
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

Pfriemler

#85
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? :)
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Damian

Zitat von: Pfriemler am 16 Mai 2015, 08:03:46
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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

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 ...

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Damian

Zitat von: Pfriemler am 16 Mai 2015, 09:55:36
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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

flurin

#89
Zitat von: Pfriemler am 15 Mai 2015, 22:13:13
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.

Zitat von: Pfriemler am 15 Mai 2015, 22:13:13
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.

Zitat von: Pfriemler am 15 Mai 2015, 22:13:13
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":


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


Gruss
flurin