neues Modul DOIF

[Damian]

Ich habe nun keine Idee mehr, wo ich suchen kann. Daher mal die folgende Frage:
Ich habe das DOIF aus der Commandref nachgebaut mit allem "Zubehör". Funktioniert auch, allerdings mit einem kleinen Makel, den ich nicht weg bekomme.

Code Auswählen Erweitern

(([06:00-09:00] or [17:00-20:00]) and ([BM_Kueche] eq "motion")) (IF ([BM_Kueche:brightness:d] <40) (set switch_d_lang on, set switch_d_lang off))
mit do always.

Problem: immer um 6 und um 17 Uhr geht das Licht nun für 109 Minuten an, ohne durch den BM ausgelöst zu werden.
Bei meinem 2. DOIF passiert das auch, der dir restlichen Tageszeiten abdeckt und mit 1 Minute läuft. Der geht zu jeder Beginnzeit dann allerdings für eine Minute an.

Ich hoffe, mich verständlich auszudrücken.

Hat jemand eine Idee, wie ich den  DOIFs das abgewöhnen kann? Die Androhung von Schlägen hat nichts gebracht. LOL

Ist BM_Kueche ein HM-Bewegungsmelder?

Gruß

Damian

[Invers]

Ja, ist er.
Ich meinte allerdings: Geht das Licht für 10 Minuten an, nicht für 109. Dicker Finger.

[Damian]

Ja, ist er.

Das Problem hatten wir hier schon mal. Der HM-Bewegungsmelder sendet in regelmäßigen Abständen, auch wenn keine Bewegung da war, um andere Informationen zu aktualisieren. Dadurch wird DOIF immer wieder getriggert, obwohl keine Bewegung da war. Siehe ab hier und folgende Posts: http://forum.fhem.de/index.php/topic,23833.msg223954.html#msg223954

Gruß

Damian

[Invers]

Nö, ich meine in diesem Fall ein anderes Problem zu haben. Meine BM triggern nicht mehr wild rum.
Das Schalten erfolgt ja bei mir immer genau zum Start-Zeitpunkt eines Intervalls. Also, wenn Start 6 uhr und ende 8 Uhr ist, startet das DOIF immer genau um 6 uhr und läuft 10 Minuten, falls Dauer so programmiert ist. Im Anschluss daran klappt alles ganz normal, wie es soll. Immer!
Selbiges läuft auch am 2. DOIF, der aber nur 1 Minute schaltet, weil ich die Minute halt so will.

Wie gesagt, das passiert IMMER zur Startzewit eines Zeitraumes. Der BM löst nicht aus zu diesem Zeitpunkt.

2014-12-10_16:20:35 BM_Kueche motion
2014-12-10_16:24:39 BM_Kueche motion
2014-12-10_17:16:59 BM_Kueche motion
2014-12-10_17:17:30 BM_Kueche motion

[Damian]

Nö, ich meine in diesem Fall ein anderes Problem zu haben. Meine BM triggern nicht mehr wild rum.
Das Schalten erfolgt ja bei mir immer genau zum Start-Zeitpunkt eines Intervalls. Also, wenn Start 6 uhr und ende 8 Uhr ist, startet das DOIF immer genau um 6 uhr und läuft 10 Minuten, falls Dauer so programmiert ist. Im Anschluss daran klappt alles ganz normal, wie es soll. Immer!
Selbiges läuft auch am 2. DOIF, der aber nur 1 Minute schaltet, weil ich die Minute halt so will.

Wie gesagt, das passiert IMMER zur Startzewit eines Zeitraumes. Der BM löst nicht aus zu diesem Zeitpunkt.

2014-12-10_16:20:35 BM_Kueche motion
2014-12-10_16:24:39 BM_Kueche motion
2014-12-10_17:16:59 BM_Kueche motion
2014-12-10_17:17:30 BM_Kueche motion

Dass zum Startpunkt getriggert wird, ist klar, da "motion" bei HM immer gesetzt ist. Ich werde später noch Zeitintervalle ohne Trigger realisieren, solange müsstest du z. B.:

Code Auswählen Erweitern

$HMS gt "06:00" and $HMS lt "09:00" statt

Code Auswählen Erweitern

[06:00-09:00] angeben.

Gruß

Damian

[Invers]

Schade, abgesehen, dass ich niemals auf so einen Gedanken gekommen wäre, schaltet nun gar nichts mehr.
Vermutlich habe ich dich falsch verstanden?
Hier mal mein neuer Code:

Code Auswählen Erweitern

((($HMS gt "09:00" and $HMS lt "17:00") or ($HMS gt "20:00" and $HMS lt "06:00")) and (([BM_Kueche] eq "motion") and ([BM_Kueche:brightness:d] <40))) (set switch_d on, set switch_d off)

[Damian]

Schade, abgesehen, dass ich niemals auf so einen Gedanken gekommen wäre, schaltet nun gar nichts mehr.
Vermutlich habe ich dich falsch verstanden?
Hier mal mein neuer Code:

Code Auswählen Erweitern

((($HMS gt "09:00" and $HMS lt "17:00") or ($HMS gt "20:00" and $HMS lt "06:00")) and (([BM_Kueche] eq "motion") and ([BM_Kueche:brightness:d] <40))) (set switch_d on, set switch_d off)

ja, es muss $hms heißen und nicht $HMS. brightness-Abfrage hast du jetzt in die Bedingung gepackt, vorher hast du sie separat mit IF abgefragt.

Gruß

Damian

[Invers]

Es ist erstaunlich für mich, woran du dich alles erinnerst. Ja, du hast natürlich Recht mit dem IF.
Das hatte aber keinerlei Änderung in das Fehlverhalten des BM gebracht, da habe ich es im Lauf der Zeit wieder ausgetauscht gegen die alte Version meines Codes.
Das Steuern mit einem BM hat leider sehr viele Tücken. Schon die Änderung eines fast beliebigen Wertes (Registers) durch den BM löst z.B. motion aus.

Deine hms Änderung scheint voll der Erfolg zu sein. Kann ich jetzt nicht 100% testen, aber um 17 Uhr werde ich es genau wissen

Vielen Dank für deine Hilfe, aber vor Allem für deine Geduld. Bin immer wieder von beidem begeistert.


EDIT:

So, voller Erfolg. Funktioniert zu 100 Prozent. Nur zur Info: Ich habe zusätzlich beim BM noch das Intervall auf 15 Sekunden umgestellt. Nun geht auch das Licht nicht mehr einfach so aus. Selbst 30 Sekunden waren da offenbar noch zu lang. Das gehört zwar nicht ganz hierher, aber genau das war ja damals das von dir erwähnte Problem. Auch da für die Hilfe nochmals danke, Damian.


EDIT 2:

Mit dieser Methode geht der Zeditraum von 20 uhr bis 6 Uhr nicht. cih habe das noch einmal umgestellt und nun geht es auch da:

((($hms gt "09:00" and $hms lt "17:00") or ($hms gt "20:00" and $hms lt "24:00") or ($hms gt "00:00" and $hms lt "06:00")) and (([BM_Kueche] eq "motion") and ([BM_Kueche:brightness:d] <40))) (set switch_d on, set switch_d off)

[holzwurm83]

Hallo Damian,

ich habe für meinen Festerstatus folgende config:

Code Auswählen Erweitern

2014.12.20 21:58:41 2: WZ_Fenster_OST_L: perl error in condition: ReadingValDoIf('HMW_Sen_SC_12_DR_JEQ0545703_07','SENSOR','') == on and ReadingValDoIf('HMW_Sen_SC_12_DR_JEQ0545703_08','SENSOR','') == off: Bareword "on" not allowed while "strict subs" in use at (eval 106) line 1.
Bareword "off" not allowed while "strict subs" in use at (eval 106) line 1.

[code]define WZ_Fenster_OST_L DOIF ([HMW_Sen_SC_12_DR_JEQ0545703_07:SENSOR] == on and [HMW_Sen_SC_12_DR_JEQ0545703_08:SENSOR] == off) DOELSEIF ([HMW_Sen_SC_12_DR_JEQ0545703_07:SENSOR] == off and [HMW_Sen_SC_12_DR_JEQ0545703_08:SENSOR] == on) DOELSEIF ([HMW_Sen_SC_12_DR_JEQ0545703_07:SENSOR] == on and [HMW_Sen_SC_12_DR_JEQ0545703_08:SENSOR] == on)
attr WZ_Fenster_OST_L alias OST L
attr WZ_Fenster_OST_L cmdState zu|gekippt|offen
attr WZ_Fenster_OST_L devStateIcon zu:fts_window_1w offen:fts_window_1w_open@red gekippt:fts_window_1w_tilt@red
attr WZ_Fenster_OST_L group Fenster
attr WZ_Fenster_OST_L icon fts_door_right
attr WZ_Fenster_OST_L room Wohnzimmer

Jetzt bekomme ich folgenden Fehler mit dem ich nicht klarkomme.

Code Auswählen Erweitern

2014.12.20 21:58:41 2: WZ_Fenster_OST_L: perl error in condition: ReadingValDoIf('HMW_Sen_SC_12_DR_JEQ0545703_07','SENSOR','') == on and ReadingValDoIf('HMW_Sen_SC_12_DR_JEQ0545703_08','SENSOR','') == off: Bareword "on" not allowed while "strict subs" in use at (eval 107) line 1.
Bareword "off" not allowed while "strict subs" in use at (eval 107) line 1.

2014.12.20 21:58:41 2: WZ_Fenster_OST_L: perl error in condition: ReadingValDoIf('HMW_Sen_SC_12_DR_JEQ0545703_07','SENSOR','') == on and ReadingValDoIf('HMW_Sen_SC_12_DR_JEQ0545703_08','SENSOR','') == off: Bareword "on" not allowed while "strict subs" in use at (eval 108) line 1.
Bareword "off" not allowed while "strict subs" in use at (eval 108) line 1.

[Brockmann]

Jetzt bekomme ich folgenden Fehler mit dem ich nicht klarkomme.

Der besagt, dass er mit dem Begriff on oder off nichts anfangen kann, weil Du die in Anführungszeichen setzen muss (so wie es auch in den zahlreichen Beispielen in der Commandref oder hier im Thread gehandhabt wird).
Es sollte also eq "on" bzw. eq "off" heißen anstell von == on bzw. == off.

[satprofi]

Was ist mit dem Beispiel aus der commandref von DOIF zu "Waschmaschine fertig"?

Gruß

Damian

Hallo.
Vorerst habe ich das funktionierend zum laufen gebracht. Jetzt möchte ich aber das solange die Meldung ausgegeben wird, bis der Verbrauch 0W ist, also Maschine abgeschalten. Bei der fertigmeldung sind ca. 2W verbrauch, und dies wird mit do always auch andauernd getriggert, aber wie schalte ich die sprachausgabe bei 0W ab?

[maxritti]

Hallo zusammen,

bezugnehmend auf das Posting hier habe ich mir meine Jalousiesteuerung ein wenig anders umgesetzt.
Denn die Idee mit Dummies usw fand ich ganz gut.

http://forum.fhem.de/index.php/topic,29124.msg219148.html#msg219148

Nun habe ich mehrere Dummies definiert (siehe Anhang), wo ich mehrere Parameter setzen kann.

Für meine 5 Jalousien habe ich nun pro Jalousie ein DOIF definiert, wo ich die in den Dummies definierten Werte mit einbeziehe.

Ein DOIF sieht beispielsweise so aus:

Code Auswählen Erweitern

define di_EG_wz_RO_Carport
  DOIF  (([du_Rollo_Master:state] eq "an") and ([EG_wz_TK_Carport:state] eq "closed") and ((([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru:state]) and ([15:00-24:00])) or [22:10-24:00]))
    (set EG_wz_RO_Carport off)
  DOELSEIF (([du_Rollo_Master:state] eq "an") and ((([EG_dr_TS_Terrasse:luminosity] > [du_Rollo_Luminosity_ho:state]) and !$we) or ([{Value("du_Rollo_Zeit_ho")}] and !$we) or ([{Value("du_Rollo_Zeit_ho_WE")}] and $we)) or ([EG_wz_TK_Carport:state] eq "open"))
    (set EG_wz_RO_Carport on)
  DOELSEIF (([du_Rollo_PV:state] eq "an") and ([EG_wz_TK_Carport:state] eq "closed") and ([mySL:Pac_avg] >= 2100) and ([myTL:azimuth] > 70) and ([myTL:azimuth] < 170))
    (set EG_wz_RO_Carport 0)
  DOELSEIF (([du_Rollo_PV:state] eq "an") and ([EG_wz_TK_Carport:state] eq "closed") and ([mySL:Pac_avg] >= 1501) and ([myTL:azimuth] > 70) and ([myTL:azimuth] < 170))
    (set EG_wz_RO_TerrasseLinks 30)


Das Problem ist nun, dass wenn ich FHEM neu starte, was ja spätestens nach einem Update der Fall sein wird, alle DOIFs für die Jalousien verschwinden.

Im log sehe ich dann so etwas:

Code Auswählen Erweitern

Please define di_EG_wz_RO_Carport first
di_EG_wz_RO_Carport DOIF: the at function "Value("du_Rollo_Zeit_ho")" must return a timespec and not ???.: {Value("du_Rollo_Zeit_ho")}


Jetzt frage ich mich nur, an was das liegt?
Denn das Dummie du_Rollo_Zeit_ho (Zeit hoch:) ist wie man im Screenshot sieht vorhanden und auch gefüllt.

Liegt das eventuell an der Reihenfolge, wie die DOIFs und Dummies in der Config gespeichert sind? Da habe ich ja mMn mal nicht wirklich viel Einfluss drauf.
Schon gar nicht bei der ConfigDB

Zumindest ein "configDB list" zeigt mir auch erst die Definition der DOIFs und dann des Dummies.

[Damian]

Hallo zusammen,

bezugnehmend auf das Posting hier habe ich mir meine Jalousiesteuerung ein wenig anders umgesetzt.
Denn die Idee mit Dummies usw fand ich ganz gut.

http://forum.fhem.de/index.php/topic,29124.msg219148.html#msg219148

Nun habe ich mehrere Dummies definiert (siehe Anhang), wo ich mehrere Parameter setzen kann.

Für meine 5 Jalousien habe ich nun pro Jalousie ein DOIF definiert, wo ich die in den Dummies definierten Werte mit einbeziehe.

Ein DOIF sieht beispielsweise so aus:

Code Auswählen Erweitern

define di_EG_wz_RO_Carport
  DOIF  (([du_Rollo_Master:state] eq "an") and ([EG_wz_TK_Carport:state] eq "closed") and ((([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru:state]) and ([15:00-24:00])) or [22:10-24:00]))
    (set EG_wz_RO_Carport off)
  DOELSEIF (([du_Rollo_Master:state] eq "an") and ((([EG_dr_TS_Terrasse:luminosity] > [du_Rollo_Luminosity_ho:state]) and !$we) or ([{Value("du_Rollo_Zeit_ho")}] and !$we) or ([{Value("du_Rollo_Zeit_ho_WE")}] and $we)) or ([EG_wz_TK_Carport:state] eq "open"))
    (set EG_wz_RO_Carport on)
  DOELSEIF (([du_Rollo_PV:state] eq "an") and ([EG_wz_TK_Carport:state] eq "closed") and ([mySL:Pac_avg] >= 2100) and ([myTL:azimuth] > 70) and ([myTL:azimuth] < 170))
    (set EG_wz_RO_Carport 0)
  DOELSEIF (([du_Rollo_PV:state] eq "an") and ([EG_wz_TK_Carport:state] eq "closed") and ([mySL:Pac_avg] >= 1501) and ([myTL:azimuth] > 70) and ([myTL:azimuth] < 170))
    (set EG_wz_RO_TerrasseLinks 30)


Das Problem ist nun, dass wenn ich FHEM neu starte, was ja spätestens nach einem Update der Fall sein wird, alle DOIFs für die Jalousien verschwinden.

Im log sehe ich dann so etwas:

Code Auswählen Erweitern

Please define di_EG_wz_RO_Carport first
di_EG_wz_RO_Carport DOIF: the at function "Value("du_Rollo_Zeit_ho")" must return a timespec and not ???.: {Value("du_Rollo_Zeit_ho")}


Jetzt frage ich mich nur, an was das liegt?
Denn das Dummie du_Rollo_Zeit_ho (Zeit hoch:) ist wie man im Screenshot sieht vorhanden und auch gefüllt.

Liegt das eventuell an der Reihenfolge, wie die DOIFs und Dummies in der Config gespeichert sind? Da habe ich ja mMn mal nicht wirklich viel Einfluss drauf.
Schon gar nicht bei der ConfigDB

Zumindest ein "configDB list" zeigt mir auch erst die Definition der DOIFs und dann des Dummies.

ja, zum Zeitpunkt der Definition des Moduls ist das Dummy offenbar nicht vorhanden. Evtl. hilft ReadingsVal("du_Rollo_Zeit_ho","state","00:00") statt Value("du_Rollo_Zeit_ho"). Hier wird zumindest ein Default-Wert bei Nichtvorhandensein genommen.

Gruß

Damian

[MarkusN]

Damian, ich möchte einfach mal Danke sagen. Das DOIF Modul macht viele Anwendungsfälle deutlich einfacher, ich habe unzählige notify und at gelöscht, Fälle in denen ich ein Konstrukt aus mehreren notifys und dummys gebaut habe sind mit einem DOIF abgebacken. Es gibt zwar einige Fallstricke, aber wenn man die verstanden hat (und auch nicht wieder vergisst ) ist das wirklich eine herrliche Sache, ich bin begeistert. Danke! Auch für das IF-Modul den IF-Befehl!

Grüße,

Markus

[maxritti]

ja, zum Zeitpunkt der Definition des Moduls ist das Dummy offenbar nicht vorhanden. Evtl. hilft ReadingsVal("du_Rollo_Zeit_ho","state","00:00") statt Value("du_Rollo_Zeit_ho"). Hier wird zumindest ein Default-Wert bei Nichtvorhandensein genommen.

Gruß

Damian

Danke für den Ansatz. Dahin ist vorhin auch mein Gedanke gegangen.
Mal schauen, wie ich das umsetze.
Nicht, dass auf einmal um 00:00 die Jalousien hoch gehen.
Das würde den WAF dann ein wenig reduzieren