neues Modul DOIF

[FHEMbeta]

@Alexander

versuch mal das temp reading auf zahlen zu filtern...

Code Auswählen Erweitern

[Temp_Brahea:temperature:d]

natürlich für beide..

Ausserdem solltest Du dem sensor das attribut event on change reading geben.

Ich habe jetzt beim Temperatursensor das event-on-change-reading mit temperature,temperature2,battery gesetzt. Mit temperature:d geht es nicht, nur mit temperature.

Der Schalter geht nun an und nach Erreichen der Temperatur wieder aus. Es dauert aber ca. 2 Minuten bis der Schalter an geht. Dauert das nicht zu lange?

Wie bekommt man es hin, dass der Schalter nur schaltet, wenn sich der Zustand (on/off) ändern soll? Da ich einen HomeMatic-Schalter verwende, kennt FHEM den aktuellen Status des Schalters. FHEM schaltet aber dennoch und belastet so unnötig die Funkschnittstelle (Highload).

[Damian]

Ich würde gerne einen Schalter temperaturabhängig an- und ausschalten. Der Temperatursensor heißt Temp_Brahea und hat die Readings temperature und temperature2. Der Schalter(kanal) heißt Heizung_Sw_01.

Warum erzeugt der folgende Code keine funktionierende Schaltung (bei kleiner gleich -4°C bzw. 2.5°C einschalten, sonst aus)? Stattdessen bekomme ich auf dem HomeMatic USB-Stick einen Highload Fehler.

Code Auswählen Erweitern

# Steuerung Brahea
define Steuerung_Brahea DOIF ([Temp_Brahea:temperature] <= -4 or [Temp_Brahea:temperature2] <= 2.5)  (set Heizung_Sw_01 on) DOELSE (set Heizung_Sw_01 off)
attr Steuerung_Brahea do always
attr Steuerung_Brahea room Balkon

Bei zyklisch sendenden Sensoren darfst du kein do always angeben, sonst wird deine Heizung ständig geschaltet.

Gruß

Damian

[FHEMbeta]

Bei zyklisch sendenden Sensoren darfst du kein do always angeben, sonst wird deine Heizung ständig geschaltet.

Gruß

Damian

OK, danke. Was würde man hier stattdessen setzen? Nichts?

Die Temperatursensoren senden alle 4 Sekunden. Es soll aber nur geschaltet werden, wenn es auch wirklich etwas zu schalten gibt: on zu off ODER off zu on.

[Damian]

Hallo,

Ich habe ein kleines Problem mit meiner DOIF - Funktion.

Code Auswählen Erweitern

DOIF ([07:00-22:35|7] or [13:00-21:35|8] and [rr_Stefan] eq "home") (set Adventskranz on) DOELSE (set Adventskranz off)

Mein Adventskranz soll also am WE und an Feiertagen von 7 - 22.35 Uhr, unter der Woche von 13 - 21.35 Uhr an sein, aber nur wenn ich zu Hause bin.
Globales Attribut holiday2we ist gesetzt ist und eine entsprechende .holiday-Datei ist vorhanden.
Anwesenheit per Residentsmodul funktioniert.

Mein Problem ist nun, das zwar zur richtigen Zeit an & ausgeschaltet wird, aber wenn sich zwischenzeitlich der Anwesenheitsstatus von home auf absent ändert, wird das ignoriert und das Licht bleibt trotzdem an.

Wo liegt da mein Fehler?

Gruß
Stefan

Du musst die Prioritäten der Operatoren beachten, and kommt vor or, daher ist wohl das, was du meinst:

Code Auswählen Erweitern

DOIF (([07:00-22:35|7] or [13:00-21:35|8]) and [rr_Stefan] eq "home") (set Adventskranz on) DOELSE (set Adventskranz off)

Gruß

Damian

[Damian]

OK, danke. Was würde man hier stattdessen setzen? Nichts?

Die Temperatursensoren senden alle 4 Sekunden. Es soll aber nur geschaltet werden, wenn es auch wirklich etwas zu schalten gibt: on zu off ODER off zu on.

Dann ist es wohl kein Wunder, dass HM sich beschwert und dein Log dürfte zugemüllt sein. do always wird nur angegeben, wenn sich das selbe Kommando wiederholen soll, wie beim notify, sonst wird es nicht angegeben. Erklärt wird es im ersten Beispiel zu Ereignissteuerung in der Commandref von DOIF.

Gruß

Damian

[StefanW]

Du musst die Prioritäten der Operatoren beachten, and kommt vor or, daher ist wohl das, was du meinst:

Code Auswählen Erweitern

DOIF (([07:00-22:35|7] or [13:00-21:35|8]) and [rr_Stefan] eq "home") (set Adventskranz on) DOELSE (set Adventskranz off)

Gruß

Damian

Danke, das wars!

[FHEMbeta]

Dann ist wohl kein Wunder, dass HM sich beschwert und dein Log dürfte zugemüllt sein. do always wird nur angegeben, wenn sich das selbe Kommando wiederholen soll, wie beim notify, sonst wird es nicht angegeben. Erklärt wird es im ersten Beispiel zu Ereignissteuerung in der Commandref von DOIF.

Gruß

Damian

Vielen Dank! Ich habe die Commandref gelesen, vor lauter Bäumen aber wohl nicht mehr den Wald gesehen.

Kann es sein, dass DOIF ohne do always noch länger braucht, bis der Schalter schaltet? Die Temperatur war nun 5 Minuten unter Soll und jetzt wurde erst eingeschaltet.

[Damian]

Vielen Dank! Ich habe die Commandref gelesen, vor lauter Bäumen aber wohl nicht mehr den Wald gesehen.

Kann es sein, dass DOIF ohne do always noch länger braucht, bis der Schalter schaltet? Die Temperatur war nun 5 Minuten unter Soll und jetzt wurde erst eingeschaltet.

Ich vormute, dass sich HM wegen der 1 %-Regel erst mal erholen muss. Das Schalten wird ohne Verzögerung ausgeführt, im Prinzip in der gleichen Sekunde.

Gruß

Damian

[Damian]

Neue Version siehe: http://forum.fhem.de/index.php/topic,30847.0.html wurde eingecheckt. Dokumentation wurde stark überarbeitet.
Morgen per FHEM-Update verfügbar.

Gruß

Damian

[Spartacus]

Hallo,
ich möchte noch einmal versuchen diese Frage loszuwerden, da ich mir seit tagen den Kopf zerbreche, wie ich das lösen kann:
Wie kann ich in einem DOIF auf ein Event aus einem notify reagieren?
Ich will einen Tasterklick im DOIF auswerten, aber dieser "Klick" wird mittels sequence zwischen "Kurz-" und "Langdruck" unterschieden. Daraus entstehen dann die notifies "trigger" und "partial_x" Und genau dieses Event muss ich irgendwie in einem DOIF weiterverarbeiten...ein Reading gibt es leider nicht!

Hat niemand eine Idee, wie man das lösen kann?
Christian

[Damian]

Hallo,
ich möchte noch einmal versuchen diese Frage loszuwerden, da ich mir seit tagen den Kopf zerbreche, wie ich das lösen kann:
Wie kann ich in einem DOIF auf ein Event aus einem notify reagieren?
Ich will einen Tasterklick im DOIF auswerten, aber dieser "Klick" wird mittels sequence zwischen "Kurz-" und "Langdruck" unterschieden. Daraus entstehen dann die notifies "trigger" und "partial_x" Und genau dieses Event muss ich irgendwie in einem DOIF weiterverarbeiten...ein Reading gibt es leider nicht!

Hat niemand eine Idee, wie man das lösen kann?
Christian

Trigger verändert keinen Wert im Reading oder Status, den man abfragen kann. Beim trigger muss man allerdings ein Device angeben. Wenn es nur einen Trigger auf das Device gibt und dieser eindeutig ist, dann kann man den auch mit DOIF ([<Device>])... abfragen.
Ansonsten kannst du in deinen notifies statt zu triggern, dummys mit set setzen, die du dann im DOIF abfragen kannst.

Gruß

Damian

[der-Lolo]

ein simpler trigger auf das DOIF selbst geht nicht?
so wie es bei einem notify möglich ist?

[Damian]

ein simpler trigger auf das DOIF selbst geht nicht?
so wie es bei einem notify möglich ist?

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

[maxritti]

Hallo,


folgendes Problem muss ich noch mal auf die Tagesordnung bringen.

http://forum.fhem.de/index.php/topic,23833.msg233617.html#msg233617

Und zwar sahen meine DOIFs für die einzelnen Jallousien so aus:

Code Auswählen Erweitern

(([du_Rollo_Master:state] eq "an") and ([EG_wz_TK_Terrasse:state] eq "closed") and ([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru:state]) and  ([{ReadingsVal("du_Rollo_Zeit_ru_start","state","00:00")}-{ReadingsVal("du_Rollo_Zeit_ru_ende","state","00:00")}]) or
  ([du_Rollo_Master:state] eq "an") and [{ReadingsVal("du_Rollo_Zeit_ru_ende","state","00:00")}])
(set du_EG_wz_RO_TerrasseLinks off)
DOELSEIF ((([du_Rollo_Master:state] eq "an") and ([EG_wz_TK_Terrasse:state] eq "open")) or
(([du_Rollo_Master:state] eq "an") and ([EG_wz_TK_Terrasse:state] eq "closed") and ([EG_dr_TS_Terrasse:luminosity] > [du_Rollo_Luminosity_ru:state]) and  ([{ReadingsVal("du_Rollo_Zeit_ho_start","state","00:00")}-{ReadingsVal("du_Rollo_Zeit_ho_ende","state","00:00")}]) or
  ([du_Rollo_Master:state] eq "an") and [{ReadingsVal("du_Rollo_Zeit_ho_ende","state","00:00")}]))
(set du_EG_wz_RO_TerrasseLinks on)

Dort habe ich mit mittels {ReadingsVal("....")} Zeitangaben aus Dummies geholt um meine DOIFs durch Eingabe neuer Werte direkt zu aktualisieren.
Klappt(e) auch soweit ganz gut.
Nun habe ich mal ein Update gemacht.

Wenn ich nun in meinem Dummy, wo ich eine Zeiteingabe tätige den Wert ändere und meine DOIFs aktualisiert werden, sieft die Definition des DOIFs auf einmal so aus:
"Lustigerweise" hat der die {ReadingsVal("...")} Befehle wohl direkt durch die aktuellen Werte ausgetauscht und in die Definition des DOIFs übernommen.
Somit kann ich nun Änderungen aus meinen Zeitdummies nicht mehr in die DOIFs übernehmen lassen.

Code Auswählen Erweitern

(([du_Rollo_Master:state] eq "an") and ([EG_wz_TK_Terrasse:state] eq "closed") and ([EG_dr_TS_Terrasse:luminosity] < [du_Rollo_Luminosity_ru:state]) and  ([10:00-21:30]) or
  ([du_Rollo_Master:state] eq "an") and [21:30])
(set du_EG_wz_RO_TerrasseLinks off)
DOELSEIF ((([du_Rollo_Master:state] eq "an") and ([EG_wz_TK_Terrasse:state] eq "open")) or
(([du_Rollo_Master:state] eq "an") and ([EG_wz_TK_Terrasse:state] eq "closed") and ([EG_dr_TS_Terrasse:luminosity] > [du_Rollo_Luminosity_ru:state]) and  ([06:45-10:00]) or
  ([du_Rollo_Master:state] eq "an") and [10:00]))
(set du_EG_wz_RO_TerrasseLinks on)

Mit dieser Version aus einem Backup werden die Ersetzungen nicht durchgeführt.

$Id: 98_DOIF.pm 7147 2014-12-06 15:48:42Z damian-s $

Das DOIF, welches auf die Eingaben in den Feldern von den Dummies reagiert sieht so aus:

Code Auswählen Erweitern

DEF        ([du_Rollo_Luminosity_ru] or [du_Rollo_Zeit_ru_start] or [du_Rollo_Zeit_ru_ende] or [du_Rollo_Zeit_ho_start] or [du_Rollo_Zeit_ho_WE_start] or [du_Rollo_Zeit_ho_ende]) (modify di_EG_wz_RO_TerrasseLinks [di_EG_wz_RO_TerrasseLinks:&DEF])
   NAME       di_Rollo_SetTime
   NR         27
   NTFY_ORDER 50-di_Rollo_SetTime
   STATE      cmd_1
   TYPE       DOIF
   Readings:
     2014-12-29 12:02:21   cmd_event       du_Rollo_Zeit_ru_start
     2014-12-29 12:02:21   cmd_nr          1
     2014-12-22 17:12:39   e_du_Rollo_Zeit_ho_WE_start_STATE 08:30
     2014-12-29 12:02:21   e_du_Rollo_Zeit_ru_start_STATE 10:15
     2014-12-29 12:02:21   state           cmd_1
   Condition:
     0          InternalDoIf('du_Rollo_Luminosity_ru','STATE','') or InternalDoIf('du_Rollo_Zeit_ru_start','STATE','') or InternalDoIf('du_Rollo_Zeit_ru_ende','STATE','') or InternalDoIf('du_Rollo_Zeit_ho_start','STATE','') or InternalDoIf('du_Rollo_Zeit_ho_WE_start','STATE','') or InternalDoIf('du_Rollo_Zeit_ho_ende','STATE','')
   Devices:
     0           du_Rollo_Luminosity_ru du_Rollo_Zeit_ru_start du_Rollo_Zeit_ru_ende du_Rollo_Zeit_ho_start du_Rollo_Zeit_ho_WE_start du_Rollo_Zeit_ho_ende
     all         du_Rollo_Luminosity_ru du_Rollo_Zeit_ru_start du_Rollo_Zeit_ru_ende du_Rollo_Zeit_ho_start du_Rollo_Zeit_ho_WE_start du_Rollo_Zeit_ho_ende
   Do:
     0          modify di_EG_wz_RO_TerrasseLinks [di_EG_wz_RO_TerrasseLinks:&DEF]
   Helper:
     last_timer 0
     sleeptimer -1
   Internals:
     0           du_Rollo_Luminosity_ru:STATE du_Rollo_Zeit_ru_start:STATE du_Rollo_Zeit_ru_ende:STATE du_Rollo_Zeit_ho_start:STATE du_Rollo_Zeit_ho_WE_start:STATE du_Rollo_Zeit_ho_ende:STATE
     all         du_Rollo_Luminosity_ru:STATE du_Rollo_Zeit_ru_start:STATE du_Rollo_Zeit_ru_ende:STATE du_Rollo_Zeit_ho_start:STATE du_Rollo_Zeit_ho_WE_start:STATE du_Rollo_Zeit_ho_ende:STATE
   State:
Attributes:
   do         always
   group      z_doif
   room       Licht/Rollo
   
Ist das Verhalten ggf so gewollt?
Wenn ja, frage ich hier mal, wie ich mich denn dazu anstellen müsste, diese Parametrierung meiner DOIFs wieder zu ermöglichen? 

[Damian]

 
Ist das Verhalten ggf so gewollt?
Wenn ja, frage ich hier mal, wie ich mich denn dazu anstellen müsste, diese Parametrierung meiner DOIFs wieder zu ermöglichen? 

Ich glaube nicht, dass DOIF damit etwas zu tun hat. Ich habe es gerade mit der aktuell eingecheckten Version bei mir nachgestellt:

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        ([{ReadingsVal("test_d","state","00:00")}])(set bla on)
   NAME       di_test
   NR         395
   NTFY_ORDER 50-di_test
   STATE      cmd_1
   TYPE       DOIF
   Readings:
     2014-12-29 13:02:00   cmd_event       timer_1
     2014-12-29 13:02:00   cmd_nr          1
     2014-12-29 13:02:00   error           set bla on: Please define bla first
     2014-12-29 13:02:00   state           cmd_1
     2014-12-29 13:02:00   timer_1_c1      30.12.2014 13:02:00
   Condition:
     0          DOIF_time_once($hash->{timer}{0},$wday,"")
   Days:
   Devices:
   Do:
     0          set bla on
   Helper:
     last_timer 1
     sleeptimer -1
   Internals:
   Readings:
   Realtime:
     0          13:02:00
   State:
   Time:
     0          {ReadingsVal("test_d","state","00:00")}
   Timecond:
     0          0
   Timer:
     0          0
   Timerfunc:
   Timers:
     0           0
Attributes:


Im Dummy test_d stand 13:02. Die aktuelle Version verhält sich wie die alte. Unter Time sieht man den angegebenen Reading und auch die Deklaration wurde nicht verändert (siehe DEF). Das Kommando wurde um 13:02 Uhr ausgeführt und die Zeit auf den nächsten Tag gesetzt.

Ich würde bei dir auf eine alte Konfiguration tippen, die du selbst mal so definiert hast.

Gruß

Damian