neues Modul DOIF

[maxritti]

Danke Dir schon mal für die Hilfe.
Wo ich das ganze so geschrieben habe, kam mir das auch ein wenig komisch vor, dies auf das DOIF zu schieben.
Noch komischer ist es ja, dass durch das einspielen des "alten" DOIFs, die Definition nicht mehr verändert wird.

Gerade eben habe ich mal in einer neuen VM Ware ein Debian aufgesetzt und dort ein frisch installiertes FHEM an den Start gebracht.
Dann brav ein "update" in FHEM eingegeben und neu gestartet.

DOIF ist dann mit der Version vorhanden:

$Id: 98_DOIF.pm 7338 2014-12-27 22:26:00Z damian-s $

Dann habe ich folgende 4 Devices angelegt:

1. Eingabe einer Zeit über diesen Dummy

Code Auswählen Erweitern

define du_Eingabe dummy
attr du_Eingabe setList state:textField
attr du_Eingabe webCmd state
   
2. Dieser Dummy dient mal zu Ausgabe, wenn das DOIF zuschlägt

Code Auswählen Erweitern

define du_Ausgabe dummy

3. Hier das DOIF welches zu der im Dummy eingegebenen Zeit losrennen soll

Code Auswählen Erweitern

define di_Rollo DOIF ([{ReadingsVal("du_Eingabe", "state", "00:00")}]) (set du_Ausgabe "DOIF executed")
   
4. Dieses DOIF triggert auf das in 1. definierte Textfeld und aktualisiert die Definition des in 3. definierten DOIFs
 

Code Auswählen Erweitern

define di_SetTime DOIF ([du_Eingabe]) (modify di_Rollo [di_Rollo:&DEF])
attr di_SetTime do always

Wenn nun in dem Dummy du_Eingabe eine Zeit eingegeben wird und das Feld gewechselt wird, dann schlägt das di_SetTime zu und ändert die Definition des DOIF di_Rollo.
Dann steht dort in eckigen Klammern der eingegebene Zeitwert drin und nicht mehr ReadingsVal(..)

Ich weiss gar nicht ob ich hoffen soll, dass es bei Dir auch so ist. 
Eine grossartige Konfiguration habe ich ja in dem Test FHEM nicht wirklich. Ausser den o.a. 4 Devices.

[Damian]

OK.
Dass du

Code Auswählen Erweitern

define di_SetTime DOIF ([du_Eingabe]) (modify di_Rollo [di_Rollo:&DEF])

definiert hast, hast du nicht geschrieben.

Das hat tatsächlich etwas mit dem Update zu tun.

Vorher wurde Code in geschweiften Klammern bei einem FHEM-Befehl ausgeführt, wenn er zusätzlich in runde Klammern gepackt wurde, nun wird er auch ohne runde Klammern ausgeführt. Das führt zu diesem Verhalten.

Tja, sollte eine Vereinfachung sein - dann werde ich wohl das alte Verhalten wieder einbauen müssen.

Gruß

Damian

[maxritti]

OK.
Dass du

Code Auswählen Erweitern

define di_SetTime DOIF ([du_Eingabe]) (modify di_Rollo [di_Rollo:&DEF])

definiert hast, hast du nicht geschrieben.

Sorry.
Das nächste mal gebe ich hoffentlich vollständige Infos ab.

Das hat tatsächlich etwas mit dem Update zu tun.

Vorher wurde Code in geschweiften Klammern bei einem FHEM-Befehl ausgeführt, wenn er zusätzlich in runde Klammern gepackt wurde, nun wird er auch ohne runde Klammern ausgeführt. Das führt zu diesem Verhalten.

Tja, sollte eine Vereinfachung sein - dann werde ich wohl das alte Verhalten wieder einbauen müssen.

Gruß

Damian

Dafür wäre ich Dir sehr dankbar.
Wobei ich das eh schon bin für dieses Modul DOIF.
Das macht etliches erheblich einfacher.

[Sany]

Hi Damian,

erst mal auch von mir ganz ganz herzlichen Dank für das DOIF-Modul. Als Umsteiger von Homeputer/FS20/php habe ich mich durch alle möglichen Ebenen von fhem und Perl "gegraben" und verschiedenste Dinge realisiert, aber mit DOIF kann man wirklich sehr schön auch komplexe Dinge verwirklichen.

Das von maxritti eben beschriebene Problem habe ich auch, nicht nur readingsVal wird ersetzt, sondern auch alle sunset/sunrise Funktionen.
Gut daß ich immer über die DEF programmiere und alles per notepad++ vorschreibe. Da steht noch die letzte funktionierende Version.

Ich nehme an, Du schreibst hier kurz wenn Du das wieder umgestellt hast?

Schon mal einen guten Rutsch und erfolgreiches 2015!

[Damian]

Korrigierte Version wurde eingecheckt. Morgen per Update verfügbar oder hier downloaden:

http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/

Gruß

Damian

[Spartacus]

DOIF wertet keine Events aus - hat bisher offenbar noch keiner vermisst. Es wird allerdings durch einen Trigger geweckt, wenn das entsprechende Device angegeben wird.

Eine Auswertung von Events ließe sich aber relativ leicht einbauen.

Gruß

Damian

Hallo Damian,
Ja, das mit dem Dummy habe ich auch schon probiert,  Aber so trivial ist das auch nicht, da das Dummy-Device "pressed" nur so lange zeigen darf, wie die Taste gedrückt ist.... habe noch keine Ahnung, wie ich das Event "trigger" oder "partial_n dafür nutzen kann.
Besteht die Chance, dass Event-Auswertungen  mit ins DOIF kommen?

Danke und Gruß,
Christian

Dann werde ich den Taster zunächst ohne sequence betreiben....

[Damian]

Hallo Damian,
Ja, das mit dem Dummy habe ich auch schon probiert,  Aber so trivial ist das auch nicht, da das Dummy-Device "pressed" nur so lange zeigen darf, wie die Taste gedrückt ist.... habe noch keine Ahnung, wie ich das Event "trigger" oder "partial_n dafür nutzen kann.
Besteht die Chance, dass Event-Auswertungen  mit ins DOIF kommen?

Danke und Gruß,
Christian

Dann werde ich den Taster zunächst ohne sequence betreiben....

Kann ich auf die todo-Liste setzen, allerdings würde mit

Code Auswählen Erweitern

define seq sequence BT1:on 1 BT1:on

Code Auswählen Erweitern

define di DOIF ([seq:?trigger]) (set...)

nichts anderes sein als:

Code Auswählen Erweitern

define ny notify  seq:trigger set dum on
define di DOIF ([dum] eq "on") (set ...)

Gruß

Damian

[Spartacus]

Kann ich auf die todo-Liste setzen, allerdings würde mit

Code Auswählen Erweitern

define seq sequence BT1:on 1 BT1:on

Code Auswählen Erweitern

define di DOIF ([seq:?trigger]) (set...)

nichts anderes sein als:

Code Auswählen Erweitern

define ny notify  seq:trigger set dum on
define di DOIF ([dum] eq "on") (set ...)

Gruß

Damian

Moin Damian,
M.E. ist das doch ein Unterschied. Vielleicht durchschaue ich es nicht ganz, aber der Trigger der Sequenz ist ein Impuls( off-on-off), der dann die Aktion im DOIF auslöst. Im zweiten Beispiel bleibt der Dummy auf "on"  Das Dummy-Device müsste quasi direkt wieder auf "off" gesetzt werden, damit der Langdruck als Impuls verstanden wird.

Code Auswählen Erweitern


([EG.ss.TK.Haustuer:buttons] eq "pressed" or [EG.ss.LS.Eingang:buttons] eq "pressed") and [?rp.02.EG.ku.SD.Kochinsel] eq "off")
(set rp.02.EG.ku.SD.Kochinsel on)
DOELSEIF ([PTM210.Gira.01:state] eq "A0" and [rp.02.EG.ku.SD.Kochinsel] eq "off")
(set rp.02.EG.ku.SD.Kochinsel on)
DOELSEIF ([EG.ss.TK.Haustuer:buttons] eq "released" and [EG.ss.LS.Eingang:buttons] eq "released" and [rp.02.EG.ku.SD.Kochinsel] eq "on" and [diEingangsLicht] eq "sensor_on")
(set rp.02.EG.ku.SD.Kochinsel off)
DOELSEIF ([PTM210.Gira.01:state] eq "A0" and [rp.02.EG.ku.SD.Kochinsel] eq "on")
(set rp.02.EG.ku.SD.Kochinsel off)
PTM210 ist hier der Taster um den es geht. Und das Kriege ich mit dem Dummy so nicht hin.

...noch eine Frage in anderer Sache:
ich möchte Neujahr von 0:00 bis 02:00 eine Lampe einschalten. Das Holiday Modul wird erst um 00:00:02 aktualisiert, sodass ich mit

Code Auswählen Erweitern

[00:00-02:00] and [hl.01.Feiertag] eq "Neujahr"
nichts anfangen kann. Stattdessen würde ich

Code Auswählen Erweitern

[24:00-02:00] and [hl.01.Feiertag] eq "Silvester" nehmen wollen, Wertet das DOIF den Zeitraum 24:00 Uhr - 02:00 aus?
Christian

[Damian]

Moin Damian,
M.E. ist das doch ein Unterschied. Vielleicht durchschaue ich es nicht ganz, aber der Trigger der Sequenz ist ein Impuls( off-on-off), der dann die Aktion im DOIF auslöst. Im zweiten Beispiel bleibt der Dummy auf "on"  Das Dummy-Device müsste quasi direkt wieder auf "off" gesetzt werden, damit der Langdruck als Impuls verstanden wird.

Ein Trigger ist immer als ein Zeitpunkt zu verstehen - einen dauerhaften Zustand gibt es hier nicht. Das würde sich auch nicht ändern, wenn ich Triggerauswertung in DOIF einbauen würde. Der Dummy hat zwar den Zustand "on", getriggert wird das DOIF-Modul allerdings immer nur wenn seq:trigger triggert. Der Zustand des Dummys ist unerheblich an dieser Stelle, wenn man es sonst nirgendwo abfragt.

...noch eine Frage in anderer Sache:
ich möchte Neujahr von 0:00 bis 02:00 eine Lampe einschalten. Das Holiday Modul wird erst um 00:00:02 aktualisiert, sodass ich mit

Code Auswählen Erweitern

[00:00-02:00] and [hl.01.Feiertag] eq "Neujahr"
nichts anfangen kann. Stattdessen würde ich

Code Auswählen Erweitern

[24:00-02:00] and [hl.01.Feiertag] eq "Silvester" nehmen wollen, Wertet das DOIF den Zeitraum 24:00 Uhr - 02:00 aus?
Christian

Ob 00:00 oder 24:00 ist egal, das sieht man an den gesetzten Timern. Getriggert wird immer zum Zeitpunkt der gesetzten Timer und wenn hl.01.Feiertag sich ändert. Von 00:00 bis 02:00 ist die Abfrage logisch als wahr zu sehen.

Gruß

Damian

[Spartacus]

Ob 00:00 oder 24:00 ist egal, das sieht man an den gesetzten Timern. Getriggert wird immer zum Zeitpunkt der gesetzten Timer und wenn hl.01.Feiertag sich ändert. Von 00:00 und 02:00 ist die Abfrage logisch als wahr zu sehen.

Hallo Damian,
vielen Dank, dann würde das Licht ca. 2s nach Mitternacht angehen (Feiertag ändert sich von Silvester auf Neujahr), wenn ich die Abfrage auf Neujahr lasse, richtig?
Das wäre zu verkraften.

Ein Trigger ist immer als ein Zeitpunkt zu verstehen - einen dauerhaften Zustand gibt es hier nicht. Das würde sich auch nicht ändern, wenn ich Triggerauswertung in DOIF einbauen würde. Der Dummy hat zwar den Zustand "on", getriggert wird das DOIF-Modul allerdings immer nur wenn seq:trigger triggert. Der Zustand des Dummys ist unerheblich an dieser Stelle, wenn man es sonst nirgendwo abfragt.

Das ist interessant! Bedeutet, dass "on" hier keinerlei Bedeutung hat? Wenn ich also ein zweites mal den Taster betätige, wäre das Dummy-Device ja bereits auf "on". Der Trigger aus der Sequence würde das Dummy Device erneut auf "on" setzten, obwohl es auf "on"  ist, und das würde dann tatsächlich die Aktion im DOIF auslösen?

Christian

Gruß,
Christian.

[Damian]

Hallo Damian,
vielen Dank, dann würde das Licht ca. 2s nach Mitternacht angehen (Feiertag ändert sich von Silvester auf Neujahr), wenn ich die Abfrage auf Neujahr lasse, richtig?
Das wäre zu verkraften.Das ist interessant! Bedeutet, dass "on" hier keinerlei Bedeutung hat? Wenn ich also ein zweites mal den Taster betätige, wäre das Dummy-Device ja bereits auf "on". Der Trigger aus der Sequence würde das Dummy Device erneut auf "on" setzten, obwohl es auf "on"  ist, und das würde dann tatsächlich die Aktion im DOIF auslösen?

Christian

Gruß,
Christian.

ja und ja.

Gruß

Damian

[Rammlet]

Hallo zusammen

Habe Jetzt mal wieder ein wenig umgebaut und mein Flur mit einem RGB WIFI modul ausgerüstet.
dieses wird über 2 Bewegungsmelder eingeschaltet. jetzt möchte ich noch gerne einen Taster einbinden der das Licht Weiß also RGB FFFFFF Schaltet wenn es mal Hell sein soll.
Wenn sich in der zeit im Flur bewegt wird soll es Weiß Bleiben. Es soll unterschieden werden bei Kurtzem Tasten duck geht das licht 60sek an bei langem 1800sek wenn die zeit um ist und sich immer noch im flur bewegt wird soll das licht dann Weiß bleiben bis nach Ablauf einer zeit keine Bewegung mehr erkannt wird.

Leider hänge ich dort etwas Bewegungs melder geht leider der rest nicht komme nur nicht auf den Fehler

define RGB_Floor_Motion_d dummy attr RGB_Floor_Motion_d room Test # define di_RGB_Floor_Motion_SchalterS DOIF ([MD_FloorS] eq "motion" ) (set RGB_Floor_Motion_d on, set RGB_Floor_Motion_d off) attr di_RGB_Floor_Motion_SchalterS do always attr di_RGB_Floor_Motion_SchalterS room Test # define di_RGB_Floor_Motion_SchalterB DOIF ([MD_FloorB] eq "motion" ) (set RGB_Floor_Motion_d on, set RGB_Floor_Motion_d off) attr di_RGB_Floor_Motion_SchalterB do always attr di_RGB_Floor_Motion_SchalterB room Test # define di_RGB_Floor_Motion_Licht DOIF ([RGB_Floor_Motion_d] eq "on")  (set AKT_RGB_Floor1 RGB 0000FF) DOELSE  (set AKT_RGB_Floor1 RGB 000000) attr di_RGB_Floor_Motion_Licht room Test attr di_RGB_Floor_Motion_Licht wait 0:120 ###################################################################################################################################### define SEN_SWI_Floor1_FloorLightWhite_d dummy attr SEN_SWI_Floor1_FloorLightWhite_d room Test define di_SEN_SWI_Floor1_FloorLightWhite DOIF ([SEN_SWI_Floor1_FloorLightWhite] =~/short/ )   (set SEN_SWI_Floor1_FloorLightWhite_d short, set SEN_SWI_Floor1_FloorLightWhite_d short_off) DOELSEIF ([SEN_SWI_Floor1_FloorLightWhite] =~/long/)  (set SEN_SWI_Floor1_FloorLightWhite_d long, set SEN_SWI_Floor1_FloorLightWhite_d long_off) attr di_SEN_SWI_Floor1_FloorLightWhite do always attr di_SEN_SWI_Floor1_FloorLightWhite room Test define di_AKT_RGB_Floor1 DOIF ([SEN_SWI_Floor1_FloorLightWhite_d] eq "short" or [SEN_SWI_Floor1_FloorLightWhite_d] eq "long")   (set AKT_RGB_Floor1 RGB FFFFFF) DOELSEIF ([SEN_SWI_Floor1_FloorLightWhite_d] eq "short_off")   (set AKT_RGB_Floor1 RGB 000000) DOELSEIF ([SEN_SWI_Floor1_FloorLightWhite_d] eq "long_off")   (set AKT_RGB_Floor1 RGB 000000) DOELSEIF ([MD_FLOORB] eq "on" and [AKT_RGB_Floor1] eq "off")  (set AKT_RGB_Floor1 RGB FFFFFF) DOELSEIF ([MD_FLOORB] eq "off")  (set AKT_RGB_Floor1 RGB 000000) attr di_AKT_RGB_Floor1 room Test attr di_AKT_RGB_Floor1 wait 0:60:1800:0:10

[DC]

Hallo !

Ich finde das neue Modul toll und habe es auch schon zur Waschmaschinen-Überwachung siehe auch hier eingesetzt. Allerdings ist es recht mühsam, alle 67 Seiten dieses Threads durchzulesen, um zu verstehen, was man da eigentlich macht (mich irritiert z.B., dass man alle Befehle bei einer Verschachtelung "Case" in eine Zeile schreiben muss - es sei den, ich hab was überlesen - und was ist aktuell und was nicht...). Es wäre toll, wenn der aktuelle Status im Wiki oder auf der Startseite dieses Threads gepflegt werden könnte... Hab gerade die neue Commandref gefunden, in sofern hat sich das gerade erledigt, Danke !

Allerdings möchte ich trotzdem vorschlagen, diesen Thread hier zu schließen und den Support auf einzelne Themen aufzuteilen: so kann man vermeiden, dass viele Fragen oft gestellt werden.

Danke !

[Spartacus]

ja und ja.

Gruß

Damian

Super!
Besten Dank.

Eine Sache habe ich noch! Heute Nacht hat meine Gartenbeleuchtung eingeschaltet. Das sollte so nicht passieren und ich glaube, den Fehler auch gefunden zu haben, bin mir aber nicht sicher! Deshalb wäre es prima, wenn noch einmal jemand drüber guckt....

Code Auswählen Erweitern

(
([16:30-22:30|56] or
[16:30-22:30] and  [hl.01.Feiertag:tomorrow] ne "none" or
[16:30-21:30|01234] and [hl.01.Feiertag:tomorrow] eq "none" or
[16:30-02:00] and [hl.01.Feiertag] eq "Silverster"
) and [Tageslicht.dum] eq "dunkel") (set GA.ss.SA.Licht on) DOELSE (set GA.ss.SA.Licht off)
M.E. hat das Umschalten auf "Silvester" um kurz nach 0:00 Uhr zugeschlagen.

Eigentlich soll das Licht erst heute Nacht, also von Silvester, 16:00 Uhr bis Neujahr 02:00 einschalten.
Reicht es aus, den Trigger für "Feiertag" zu entfernen?

Code Auswählen Erweitern

  [16:30-02:00] and [?hl.01.Feiertag] eq "Silverster"
Oder funktioniert das nicht?

Danke,
Christian

[Damian]

Super!
Besten Dank.

Eine Sache habe ich noch! Heute Nacht hat meine Gartenbeleuchtung eingeschaltet. Das sollte so nicht passieren und ich glaube, den Fehler auch gefunden zu haben, bin mir aber nicht sicher! Deshalb wäre es prima, wenn noch einmal jemand drüber guckt....

Code Auswählen Erweitern

(
([16:30-22:30|56] or
[16:30-22:30] and  [hl.01.Feiertag:tomorrow] ne "none" or
[16:30-21:30|01234] and [hl.01.Feiertag:tomorrow] eq "none" or
[16:30-02:00] and [hl.01.Feiertag] eq "Silverster"
) and [Tageslicht.dum] eq "dunkel") (set GA.ss.SA.Licht on) DOELSE (set GA.ss.SA.Licht off)
M.E. hat das Umschalten auf "Silvester" um kurz nach 0:00 Uhr zugeschlagen.

Eigentlich soll das Licht erst heute Nacht, also von Silvester, 16:00 Uhr bis Neujahr 02:00 einschalten.
Reicht es aus, den Trigger für "Feiertag" zu entfernen?

Code Auswählen Erweitern

  [16:30-02:00] and [?hl.01.Feiertag] eq "Silverster"
Oder funktioniert das nicht?

Danke,
Christian

ja, so wird nur um 16:30 und um 02:00 getriggert und nächstes Jahr sollte die Lampe nicht mehr um Mitternacht zu Silvester angehen.

Gruß

Damian