neues Modul DOIF

[Hoeness]

Hallo,

ich habe eine Frage zu den Wochentagen, die ich bei Zeitangaben definieren kann:

1-6 entspricht Montag-Samstag?
7 entspricht WE
8 entspricht nicht WE

Wie kann ich den Sonntag definieren?

Ich hätte auch noch eine Idee.
Kann DOIF eventuell noch so erweitern, dass ich angeben kann, dass alle 2,3,4,5,... Tage etwas ausgelöst werden soll?

Gruß Hoeness

[Damian]

Cmd-5

Dann funktioniert alles wie programmiert.
Wenn cmd-5 (off) zuletzt ausgeführt wurde, dann wird es nicht noch mal ausgeführt (wozu auch, off ist off)
Gruß

Damian

[Damian]

Hallo,

ich habe eine Frage zu den Wochentagen, die ich bei Zeitangaben definieren kann:

1-6 entspricht Montag-Samstag?
7 entspricht WE
8 entspricht nicht WE

Wie kann ich den Sonntag definieren?

Ich hätte auch noch eine Idee.
Kann DOIF eventuell noch so erweitern, dass ich angeben kann, dass alle 2,3,4,5,... Tage etwas ausgelöst werden soll?

Gruß Hoeness

Bitte ersten Post noch mal genau lesen, da steht mehrfach drin, dass 0 gleich Sonntag ist.

Kann DOIF eventuell noch so erweitern, dass ich angeben kann, dass alle 2,3,4,5,... Tage etwas ausgelöst werden soll?

mal schauen, kann man erst mal durch Angabe konkreter Tage realisieren z. B 135 (jeden zweiten Tag)

oder mit "and ($mday == 1 or $mday == 15)" für alle zwei Wochen.

Gruß
Damian

[satprofi]

Dann funktioniert alles wie programmiert.
Wenn cmd-5 (off) zuletzt ausgeführt wurde, dann wird es nicht noch mal ausgeführt (wozu auch, off ist off)
Gruß

Damian

nein, wenn terassentuer offen, dann keine reaktion. cmd_5 war ja nach 18:30 der fall, das klappt ja.
ich dachte du fragtest nach dem letzten state.

[edit]
ohne "do always" klappt die abschaltung nicht. da wird nur der timer abgefragt, also die angegebene zeit.
alles andere schaltet nicht ab. werde das ganze morgen aufs neue testen.

[UweH]

Hallo,

dieses Beispiel:

Code Auswählen Erweitern

define DI_Radio DOIF ([08:00-10:00]|7) (set Radio on) DOELSE (set Radio off) funktioniert bei mir nicht, auch am Wochentag wird eingeschaltet und dann aber auch nicht mehr ausgeschaltet. Ohne angehängte 7 oder 8 funktioniert's...Genau so ist es mit anderen Wochentagen...sobald ich eine Tageszahl hinter eine Zeit setze, schaltet DOIF zwar ein, aber nicht mehr aus. Was mache ich falsch?

[sentinel1]

Hallo,

dieses Beispiel:

Code Auswählen Erweitern

define DI_Radio DOIF ([08:00-10:00]|7) (set Radio on) DOELSE (set Radio off) funktioniert bei mir nicht, auch am Wochentag wird eingeschaltet und dann aber auch nicht mehr ausgeschaltet. Ohne angehängte 7 oder 8 funktioniert's...Genau so ist es mit anderen Wochentagen...sobald ich eine Tageszahl hinter eine Zeit setze, schaltet DOIF zwar ein, aber nicht mehr aus. Was mache ich falsch?

Hallo,

so ([08:00-10:00|7]) auch schon probiert?

Gruß
Claudiu

[Damian]

nein, wenn terassentuer offen, dann keine reaktion. cmd_5 war ja nach 18:30 der fall, das klappt ja.
ich dachte du fragtest nach dem letzten state.

[edit]
ohne "do always" klappt die abschaltung nicht. da wird nur der timer abgefragt, also die angegebene zeit.
alles andere schaltet nicht ab. werde das ganze morgen aufs neue testen.

Also, das liegt eher an der Definition bzw. am Verständnis. Um 18:30 wird getriggert mit false in der ersten Bedingung, dadurch wird dein letzter Fall (DOELSE) ausgeführt. Wenn du dann Fenster aufmachst dann sind ebenfalls alle Bedingungen, wo Fenster abgefragt wird false und dadurch ist wieder dein DOELSE-Fall dran und dann passiert natürlich nichts, weil er schon zuvor geschaltet wurde. Wenn du etwas anderes willst, musst du dir eine andere Definition überlegen. Dein letzter DOELSE-Fall macht dir wahrscheinlich mehr kaputt als du annimmst.

Gruß

Damian

[Damian]

Hallo,

dieses Beispiel:

Code Auswählen Erweitern

define DI_Radio DOIF ([08:00-10:00]|7) (set Radio on) DOELSE (set Radio off) funktioniert bei mir nicht, auch am Wochentag wird eingeschaltet und dann aber auch nicht mehr ausgeschaltet. Ohne angehängte 7 oder 8 funktioniert's...Genau so ist es mit anderen Wochentagen...sobald ich eine Tageszahl hinter eine Zeit setze, schaltet DOIF zwar ein, aber nicht mehr aus. Was mache ich falsch?

Es war tatsächlich noch ein Tippfehler in der Doku - ich habe es gerade im ersten Post korrigiert, es muss natürlich heißen:

Code Auswählen Erweitern

define DI_Radio DOIF ([08:00-10:00|7]) (set Radio on) DOELSE (set Radio off)

Gruß

Damian

[UweH]

Danke, das war's. Wäre ich nie drauf gekommen.
Damian, vielen Dank für Deine Arbeit und Mühe mit diesem Modul. Das Ding spart mittlerweile etliche notifys und sub's bei mir ein 

[Brockmann]

Gerade habe ich folgendes DOIF versucht:

Code Auswählen Erweitern

([STATUS] =~ "Abwesend|Urlaub")
(cmd 1)
DOELSEIF([{OldValue("STATUS")}] ne "Nacht")
(cmd 2)


Das führt zur Fehlermeldung

Code Auswählen Erweitern

DOIF: the at function "OldValue("STATUS")" must return a timespec and not Anwesend.: {OldValue("STATUS")}

Das verstehe ich auch: DOIF akzeptiert in dieser Form nur Funktionen, die eine Zeit zurückliefern, aus der sich ein Timer generieren lässt.

Mein Frage ist, ob diese Einschränkung eigentlich wirklich notwendig ist? Prinzipiell könnte man doch eine beliebige Funktion in dieser Form verwenden.
Liefert die Funktion eine Zeit zurück, wird ein entsprechender Timer generiert. Wenn nicht, wird sei einfach nur als Bedingung ausgewertet, wenn das DOIF anderweitig angestoßen wird.
Das böte auch die Möglichkeit, in DOIFs Bedingungen zu formulieren, die nur zur Laufzeit überprüft werden, ohne selbst Trigger für das DOIF zu sein, was in manche Situationen im Hinblick auf Effizienz durchaus sinnvoll sein kann.

(Es geht mir dabei auch gar nicht um das konkrete Beispiel. Das habe ich nun durch Einfügen entsprechenden Perl-Codes innerhalb von (cmd 2) gelöst, was ich aber als "unschöne" Lösung empfinde.)

[Damian]

Gerade habe ich folgendes DOIF versucht:

Code Auswählen Erweitern

([STATUS] =~ "Abwesend|Urlaub")
(cmd 1)
DOELSEIF([{OldValue("STATUS")}] ne "Nacht")
(cmd 2)


Das führt zur Fehlermeldung

Code Auswählen Erweitern

DOIF: the at function "OldValue("STATUS")" must return a timespec and not Anwesend.: {OldValue("STATUS")}

Das verstehe ich auch: DOIF akzeptiert in dieser Form nur Funktionen, die eine Zeit zurückliefern, aus der sich ein Timer generieren lässt.

Mein Frage ist, ob diese Einschränkung eigentlich wirklich notwendig ist? Prinzipiell könnte man doch eine beliebige Funktion in dieser Form verwenden.
Liefert die Funktion eine Zeit zurück, wird ein entsprechender Timer generiert. Wenn nicht, wird sei einfach nur als Bedingung ausgewertet, wenn das DOIF anderweitig angestoßen wird.
Das böte auch die Möglichkeit, in DOIFs Bedingungen zu formulieren, die nur zur Laufzeit überprüft werden, ohne selbst Trigger für das DOIF zu sein, was in manche Situationen im Hinblick auf Effizienz durchaus sinnvoll sein kann.

(Es geht mir dabei auch gar nicht um das konkrete Beispiel. Das habe ich nun durch Einfügen entsprechenden Perl-Codes innerhalb von (cmd 2) gelöst, was ich aber als "unschöne" Lösung empfinde.)

Die Fehlermeldung:

"the at function "OldValue("STATUS")" must return a timespec and not Anwesend.: {OldValue("STATUS")}"

kommt nicht aus dem DOIF-Modul, sondern von der FHEM-Funktion, die auch beim at benutzt wird.

Das sollte aber jetzt schon kein Problem sein. DOIF unterstützt volles Perl ohne Einschränkungen, dann musst du es einfach wie in Perl abfragen, wenn du nur den Wert haben willst:

Code Auswählen Erweitern

(OldValue("STATUS") ne "Nacht")

das Problem ist allerdings, dass diese Bedingung so nicht ausgewertet wird, weil kein Trigger definiert ist (eckige Klammern), was dann funktionieren sollte ist:

([STATUS] and OldValue("STATUS") ne "Nacht")

hier wird Status als Trigger erkannt und wenn er ungleich Null (sollte der Normalfall sein) ist, ist dieser Ausdruck wahr und der Rest wird einfach abgefragt.

Was viele nicht wissen, man kann jetzt schon nicht nur auf Readings sondern auch auf Internals zugreifen

[DEVICENAME:&Internalname] (steht so in der Doku von IF)

Ich könnte so ähnlich speziell für OldValue, was schon mal öfters gebraucht wird, mir noch eine Syntax ausdenken, z. B.

Code Auswählen Erweitern

([&STATUS] ne "Nacht") entspräche:

Code Auswählen Erweitern

(OldValue("STATUS") ne "Nacht") allerdings mit Trigger und damit einer Auswertung beim Event von STATUS.

Gruß

Damian

[Brockmann]

Hallo Damian,

Danke für die Erläuterung. Da kann DOIF wieder mal schon mehr, als ich dachte. 
Vielleicht wäre es sinnvoll, die Dokumentation um ein solches Beispiel zu erweitern. Bislang ist da nur sunset in eckigen Klammern drin, was ja nochmal etwas anderes ist.
(Ja, ich weiß, in der Featureliste steht was von voller Perl-Unterstützung, aber was das bedeutet und wie man es einsetzen kann, erkennt eben nicht jeder gleich (*Pfeil auf mich*).

Dass bestimmte Arten von Bedingungen keinen Trigger definieren, empfinde ich nicht als Nachteil, sondern sogar als Vorteil, solange man die Wahl hat, welche Variante man verwendet.
Das lässt einem Spielraum, bei der Definition ein wenig auf Effizienz zu achten.

Eine spezielle Unterstützung für OldValue fände ich übertrieben, da es ja doch eher exotisch ist, OldValue als Trigger zu verwenden. Und man könnte es auch jetzt schon definieren:

Code Auswählen Erweitern

([STATUS] and (OldValue("STATUS") ne "Nacht")
Dann wird bei jedem Wechsel von STATUS geprüft, ob der vorherige Zustand "Nacht" war. Dafür braucht es keine eigene Syntax, finde ich.

[Damian]

Hallo Damian,

Danke für die Erläuterung. Da kann DOIF wieder mal schon mehr, als ich dachte. 
Vielleicht wäre es sinnvoll, die Dokumentation um ein solches Beispiel zu erweitern. Bislang ist da nur sunset in eckigen Klammern drin, was ja nochmal etwas anderes ist.
(Ja, ich weiß, in der Featureliste steht was von voller Perl-Unterstützung, aber was das bedeutet und wie man es einsetzen kann, erkennt eben nicht jeder gleich (*Pfeil auf mich*).

Dass bestimmte Arten von Bedingungen keinen Trigger definieren, empfinde ich nicht als Nachteil, sondern sogar als Vorteil, solange man die Wahl hat, welche Variante man verwendet.
Das lässt einem Spielraum, bei der Definition ein wenig auf Effizienz zu achten.

Eine spezielle Unterstützung für OldValue fände ich übertrieben, da es ja doch eher exotisch ist, OldValue als Trigger zu verwenden. Und man könnte es auch jetzt schon definieren:

Code Auswählen Erweitern

([STATUS] and (OldValue("STATUS") ne "Nacht")
Dann wird bei jedem Wechsel von STATUS geprüft, ob der vorherige Zustand "Nacht" war. Dafür braucht es keine eigene Syntax, finde ich.

Ja, ich muss auch immer aufpassen, dass man sich die Perl-Syntax nicht verbaut & kann nämlich auch eine Referenz auf Funktionen sein. Durch DOIF wird IF zunehmend an Bedeutung verlieren, obwohl es, wie wir beim Toggeln gesehen haben, durchaus noch seine Berechtigung hat. Ich werde spätestens vor dem Einchecken die Doku aus IF in die DOIF-Doku zusätzlich übernehmen. Ich denke, dass die meisten z. B. auch nicht wissen, dass man auch solche Sache beim DOIF machen kann:

Code Auswählen Erweitern

define di_temp DOIF ( [18:00] and ([outdoor:temperature] > 10)) (set thermostat desired-temp {([thermostat:desired-temp:d]+1)})

Hier wird die Wunschtemperatur aus dem Reading der bisherigen genommen, davon nur der Zahlenanteil (d-Option), falls da noch eindere Zeichen stehen, um eins erhöht und wieder mit "set thermostat desired-temp" gesetzt.

Ein kleiner Ausblick noch auf die nächste Version:

Man wird beliebigen Status, unabhängig von Abfragen definieren können:

Code Auswählen Erweitern

attr di_Rolladen State Heute beträgt die Temperatur [Wetter:temp] Grad, der Rolladen ist jetzt [di_Rolladen]

Zusätzlich wird man auch Zahlen in der Statusausgabe formatieren können wie beim THRESHOLD über sprintf.

Dann sollen reine Status-Definitionen ohne Ausführungteil möglich sein:

Code Auswählen Erweitern

define di_Fenster DOIF ([Fenster] eq "closed") and [Tuer] eq "closed)
DOELSEIF ([Fenster] eq "open" and [Tuer] eq "closed)
DOELSEIF ([Fenster] eq "closed" and [Tuer] eq "open")
DOELSEIF ([Fenster] eq "open" and [Tuer] eq "open")

attr di_Fenster cmdState beide zu|Fenster offen|Tür offen|beide offen

Das kann man zwar jetzt auch schon, aber man muss noch () für die Ausführung angeben:

Gruß

Damian

[Brockmann]

Man wird beliebigen Status, unabhängig von Abfragen definieren können:

Code Auswählen Erweitern

attr di_Rolladen State Heute beträgt die Temperatur [Wetter:temp] Grad, der Rolladen ist jetzt [di_Rolladen]

Zusätzlich wird man auch Zahlen in der Statusausgabe formatieren können wie beim THRESHOLD über sprintf.

Könnte ich damit den State eines DOIFs individuell anpassen, also z. B. so:

Code Auswählen Erweitern

attr mein_DOIF State [mein_DOIF:last_cmd] durch [mein_DOIF:last_cmd_event] um [mein_DOIF:...
Ups, dabei fällt mir gerade ein, auf den TimeStamp eines Readings kann DOIF nicht zugreifen, oder?
Ich hätte im Status der meisten DOIFs am liebsten den letzten Befehl, das auslösende Objekt und den Zeitpunkt des Befehls stehen, damit man das direkt ablesen kann.
Also quasi: Rolladen_runter durch Wettersensor um 2014-07-30 13:20:29

Dann sollen reine Status-Definitionen ohne Ausführungteil möglich sein:

Das kann man zwar jetzt auch schon, aber man muss noch () für die Ausführung angeben:

Das heißt, man sollte auch jetzt schon "leere" Ausführungsteile angeben können? Das habe ich nämlich heute morgen gerade erfolglos ausprobiert:

Code Auswählen Erweitern

DI_Test DOIF: no commands: ([STATUS] eq "Anwesend") ()

[Damian]

Könnte ich damit den State eines DOIFs individuell anpassen, also z. B. so:

Code Auswählen Erweitern

attr mein_DOIF State [mein_DOIF:last_cmd] durch [mein_DOIF:last_cmd_event] um [mein_DOIF:...
Ups, dabei fällt mir gerade ein, auf den TimeStamp eines Readings kann DOIF nicht zugreifen, oder?
Ich hätte im Status der meisten DOIFs am liebsten den letzten Befehl, das auslösende Objekt und den Zeitpunkt des Befehls stehen, damit man das direkt ablesen kann.

mit [DEVICE:Reading] kannst du beliebige Readings angeben, insbesondere die eigenen deines DOIF-Moduls. Beim Status muss ich noch schauen, sonst beißt sich die Katze in den Schwanz.

Also quasi: Rolladen_runter durch Wettersensor um 2014-07-30 13:20:29

Für Timestamps muss ich mir noch was einfallen lassen.

Das heißt, man sollte auch jetzt schon "leere" Ausführungsteile angeben können? Das habe ich nämlich heute morgen gerade erfolglos ausprobiert:

Code Auswählen Erweitern

DI_Test DOIF: no commands: ([STATUS] eq "Anwesend") ()

Ich habe das gestern mit DOELSEIF getestet  - das funktioniert, bei DOIF war ich wohl etwas strenger in der Prüfung. Aber ist jetzt unerheblich, zukünftig wird man da alles weglassen können.

Man könnte auch Schweinereien machen wie diese:

Code Auswählen Erweitern

define di DOIF
attr di State Die Aussentemperatur beträgt: [Aussen:temp], die Feuchtigkeit beträgt [Aussen:humidity]

Gruß

Damian