DOIF: neue Zeit-Features

[flurin]

ja das liegt an der Waitangabe. Ich habe es bei mir ohne wait getestet.

Da nach dem INITIALIZED noch andere global-Events kommen schlägt der imaginäre cmd_2 Zustand zu und dein cmd_1 Kommando wird nicht ausgeführt.

Dann musst du es mit sleep ohne wait machen.

Code Auswählen Erweitern

define di_init DOIF ([global:?INITIALIZED]) ((sleep 30;{Log(3,"DOIF:init")}))


Gruß

Damian

OK, es geht auch bei mir. Hier eine praktische Anwendung:

Code Auswählen Erweitern


define di_sanctum_infrared_timer DOIF ([sanctum_infrared] eq "on")
( { myLog("Sanctum Infrared timeover") }, set sanctum_infrared off)
attr di_sanctum_infrared_timer do always
attr di_sanctum_infrared_timer group DOIF
attr di_sanctum_infrared_timer wait 3600


Code Auswählen Erweitern


define di_init_sanctum_infrared DOIF ([global:?INITIALIZED] and [sanctum_infrared] eq "on")
(sleep 3600;set sanctum_infrared off)
attr di_init_sanctum_infrared group DOIF
attr di_init_sanctum_infrared initialize init


Evtl. lassen sich beide DOIFs verschmelzen.

Edit:

Es gibt dafür eine einfache Notify-Lösung:

Code Auswählen Erweitern


define n_sanctum_infrared_timer notify sanctum_infrared:on sleep 3600;;set sanctum_infrared off



Gruss
flurin

[cwagner]

Ist es beabsichtigt, dass bei disabled DOIF der Timer weiter läuft?
Siehe Screenshot

Gruß

Christian

[Damian]

Ist es beabsichtigt, dass bei disabled DOIF der Timer weiter läuft?
Siehe Screenshot

Gruß

Christian

ja, die Idee war nach dem Aktivieren des Moduls im Takt zu bleiben. Wenn man nicht gerade im Sekundentakt triggert, sollte es auch keine Performanceeinbußen geben.

Alternative wäre das Modul komplett stillzulegen, allerdings müsste man beim Aktivieren dann wieder die Definition des Moduls durchführen um die Timer neuaufzusetzen.

Gruß

Damian

[cwagner]

Du musst am Ende deiner Perl-Funktion: return 0 oder return "" einbauen, dann kommt keine Fehlermeldung mehr.

Danke das war es, Damian, hätte ich auch selbst drauf kommen können...

[joshi04]

Hallo Damian,

das ist ja mal sowas von "was ich gerade gesucht habe"!

Mein Anwendungsfall:
Ein Fenster-Aktuator soll das Fenster bei überschreiten einer bestimmten CO2-Konzentration aufmachen. Der Befehl wird dabei so ausgeführt, dass das Fenstern nach einer bestimmten Zeit automatisch wieder zugefahren wird, falls der Befehl für das Zufahren beim Aktuator aus irgend einem Grunde nicht ankommt. Das sollte im Normalfall nicht passieren, da DOIF davon natürlich nichts mitbekommen würde.
Sobald die CO2-Konzentration unter einen bestimmen Wert gefallen ist, soll das Fenster wieder zugefahren werden, dieses soll aber auch passieren, wenn der Wert nach einer bestimmten Zeit noch nicht wieder unter den Wert gefallen ist. Diese Zeit ist kürzer gewählt, als die oben genannte und dient dazu, dass der Status des Moduls mit der Realität übereinstimmt.

Als letztes soll das zeitgesteuerte Zufahren natürlich nur ausgelöst werden, wenn das Fenster nicht bereits durch unterschreiten der CO2-Konzentration zugefahren wurde.  Wenn ich es mir recht überlege, müsste das bereits durch das Modul abgefangen werden, da es zur gleichen Bedingung gehört. Ich werde probieren.

Die Zeit zur Absenkung des CO2-Wertes lässt sich nicht genau bestimmen, da von mehrere Faktoren (Anzahl der Personen im Raum, Türöffnung, etc.) abhängig.

Der Code sieht derzeit so aus:

Code Auswählen Erweitern


define SZ_Lueftungs_Logic DOIF ([SZ_Netatmo_r:co2] > 1200) \
(set SZ_Fenster_RE_Status level 100 10800 20,{ fhem 'setreading var SZ_window_opening_last '.strftime('%H:%M', localtime) }) \
    DOELSEIF ([SZ_Netatmo_r:co2] < 800 or ( [   (  [var:SZ_window_opening_last]+[01:30]  )    ] and [SZ_Lueftungs_Logic:state] ne "geschlossen") )\
(set SZ_Fenster_RE_Status level lock 0 20)\
attr SZ_Lueftungs_Logic cmdState offen|geschlossen
attr SZ_Lueftungs_Logic state Das Fenster ist [SZ_Lueftungs_Logic]


var ist ein Dummy, um die Zeit der letzten Öffnung als Reading auszunehmen.
SZ_Netatmo_r ist ein Sensor mit CO2-Messung. SZ_Fenster_RE ist der Fenster-Aktuator.

Cooles Modul, vielen Dank!
In diesem Sinne, frohe Ostern!

ps: Noch nicht abschließend getestet, daher ohne Flinte!

[Damian]

Hallo Damian,

das ist ja mal sowas von "was ich gerade gesucht habe"!

Mein Anwendungsfall:
Ein Fenster-Aktuator soll das Fenster bei überschreiten einer bestimmten CO2-Konzentration aufmachen. Der Befehl wird dabei so ausgeführt, dass das Fenstern nach einer bestimmten Zeit automatisch wieder zugefahren wird, falls der Befehl für das Zufahren beim Aktuator aus irgend einem Grunde nicht ankommt. Das sollte im Normalfall nicht passieren, da DOIF davon natürlich nichts mitbekommen würde.
Sobald die CO2-Konzentration unter einen bestimmen Wert gefallen ist, soll das Fenster wieder zugefahren werden, dieses soll aber auch passieren, wenn der Wert nach einer bestimmten Zeit noch nicht wieder unter den Wert gefallen ist. Diese Zeit ist kürzer gewählt, als die oben genannte und dient dazu, dass der Status des Moduls mit der Realität übereinstimmt.

Als letztes soll das zeitgesteuerte Zufahren natürlich nur ausgelöst werden, wenn das Fenster nicht bereits durch unterschreiten der CO2-Konzentration zugefahren wurde.  Wenn ich es mir recht überlege, müsste das bereits durch das Modul abgefangen werden, da es zur gleichen Bedingung gehört. Ich werde probieren.

Die Zeit zur Absenkung des CO2-Wertes lässt sich nicht genau bestimmen, da von mehrere Faktoren (Anzahl der Personen im Raum, Türöffnung, etc.) abhängig.

Der Code sieht derzeit so aus:

Code Auswählen Erweitern


define SZ_Lueftungs_Logic DOIF ([SZ_Netatmo_r:co2] > 1200) \
(set SZ_Fenster_RE_Status level 100 10800 20,{ fhem 'setreading var SZ_window_opening_last '.strftime('%H:%M', localtime) }) \
    DOELSEIF ([SZ_Netatmo_r:co2] < 800 or ( [   (  [var:SZ_window_opening_last]+[01:30]  )    ] and [SZ_Lueftungs_Logic:state] ne "geschlossen") )\
(set SZ_Fenster_RE_Status level lock 0 20)\
attr SZ_Lueftungs_Logic cmdState offen|geschlossen
attr SZ_Lueftungs_Logic state Das Fenster ist [SZ_Lueftungs_Logic]


var ist ein Dummy, um die Zeit der letzten Öffnung als Reading auszunehmen.
SZ_Netatmo_r ist ein Sensor mit CO2-Messung. SZ_Fenster_RE ist der Fenster-Aktuator.

Cooles Modul, vielen Dank!
In diesem Sinne, frohe Ostern!

ps: Noch nicht abschließend getestet, daher ohne Flinte!

ja, je mehr möglich ist, desto komplexer werden auch die Konstruktionen mit DOIF - hoffentlich brauchen wir nicht noch irgendwann ein Unterforum für DOIF-Konstruktionen

Gruß

Damian

[joshi04]

Hallo Damian,
zwar sehe ich es auch so, dass je mehr geht, auch die Komplexität steigt. Allerdings war der Wunsch und Bedarf so etwas zu realisieren, schon vorhanden, bevor ich alle Funktionalitäten von DOIF erkannt habe. Von daher hilft das Modul mir nun dabei, nicht mit gefühlten 25 at's und notify's hantieren zu müssen und das macht es wieder einfacher, zumindest vom Code her . Daher hier nochmal ein großes Dankeschön!

Jetzt wird's ein wenig OT:
Innerhalb meiner derzeitigen Lösung habe ich die Variable für die letzte Zeit der Fensteröffnung noch als Reading in ein separates Dummy geschrieben. Der Übersichtlichkeit halber wäre allerdings mein Wunsch, alles beieinander zu haben und das irgendwie der Definition des DOIF hinzuzufügen. Einfach ein weiteres Reading zu schreiben funktioniert natürlich auch, allerdings muss man das jeweils neu setzen, sollte man einmal die Definition ändern, daher ist das für die Testphase natürlich recht umständlich. Auch für andere Logikdefinitionen hatte ich schon diese Fragestellung und noch keine wirklich zufriedenstellende Lösung (noch Neuland). Gibt es hier eine elegantere Lösung?

Zurück zum Thema:
Gibt es noch eine elegantere und schlankere Möglichkeit, die Ausführung des 2. Kommandos vom Zeitpunkt der letzten Ausführung des 1. Kommandos abhängig zu machen? Meine Lösung fühlt sich für mich ja schon noch ein wenig zusammengebastelt an...

Schöne Grüße,
John


Edith sagt: Nicht dass man mich falsch versteht, ich bin über die steigende Komplexität seeehr froh!

[Damian]

Hallo Damian,
zwar sehe ich es auch so, dass je mehr geht, auch die Komplexität steigt. Allerdings war der Wunsch und Bedarf so etwas zu realisieren, schon vorhanden, bevor ich alle Funktionalitäten von DOIF erkannt habe. Von daher hilft das Modul mir nun dabei, nicht mit gefühlten 25 at's und notify's hantieren zu müssen und das macht es wieder einfacher, zumindest vom Code her . Daher hier nochmal ein großes Dankeschön!

Jetzt wird's ein wenig OT:
Innerhalb meiner derzeitigen Lösung habe ich die Variable für die letzte Zeit der Fensteröffnung noch als Reading in ein separates Dummy geschrieben. Der Übersichtlichkeit halber wäre allerdings mein Wunsch, alles beieinander zu haben und das irgendwie der Definition des DOIF hinzuzufügen. Einfach ein weiteres Reading zu schreiben funktioniert natürlich auch, allerdings muss man das jeweils neu setzen, sollte man einmal die Definition ändern, daher ist das für die Testphase natürlich recht umständlich. Auch für andere Logikdefinitionen hatte ich schon diese Fragestellung und noch keine wirklich zufriedenstellende Lösung (noch Neuland). Gibt es hier eine elegantere Lösung?

Zurück zum Thema:
Gibt es noch eine elegantere und schlankere Möglichkeit, die Ausführung des 2. Kommandos vom Zeitpunkt der letzten Ausführung des 1. Kommandos abhängig zu machen? Meine Lösung fühlt sich für mich ja schon noch ein wenig zusammengebastelt an...

Schöne Grüße,
John


Edith sagt: Nicht dass man mich falsch versteht, ich bin über die steigende Komplexität seeehr froh!

Du könntest z. B. mit einem wait-Timer arbeiten:

Code Auswählen Erweitern

define SZ_Lueftungs_Logic DOIF ([SZ_Netatmo_r:co2] > 1200) \
  (set SZ_Fenster_RE_Status level 100 10800 20) \
DOELSEIF ([SZ_Netatmo_r:co2] < 800)
   (set SZ_Fenster_RE_Status level lock 0 20)\
DOELSEIF ([SZ_Fenster_RE_Status] eq "10800")\
   (set SZ_Fenster_RE_Status level lock 0 20)\
attr SZ_Lueftungs_Logic cmdState offen|geschlossen|geschlossen
attr SZ_Lueftungs_Logic state Das Fenster ist [SZ_Lueftungs_Logic]
attr SZ_Lueftungs_Logic wait 0:0:5400

Statt "10800" musst du das eintragen, was bei dir nach "set SZ_Fenster_RE_Status level 100 10800 20" im Status des Aktors steht.

Die Lösung mit dem Timer geht natürlich auch, ich überlege noch, wie man das etwas eleganter definieren kann.

Gruß

Damian

[joshi04]

Ich wusste, ich bin schon wieder zu kompliziert unterwegs. Das ist auf alle Fälle schlanker und spart das Dummy.

Obwohl mir das Attribut bekannt war, hab ich das irgendwie nicht zusammengebracht. Die Komplexität...

Ich baue das dann bei mir mal ein...
Danke und schöne Grüße,
John

ps: Der Status ist "100" entsprechend des gesetzten Kommandos. Hab's aber auch gerade erst durch ausprobieren rausgefunden.

[KernSani]

Hallo,

triviales Problem, eo ich eigentlich der Meinung wäre, ich könnte es mit EINEM DOIF lösen, stehe aber auf dem Schlauch:

• Wenn event EV1 eintritt werden ein paar Aktionen ausgelöst
• 5 Minuten nachdem EV1 eingetreten is sollen ein paar weitere Aktionen ausgelöst
• ich habe keinen Dummy o.ä., der in 1. gesetzt wird (und den ich in einem DOELSEIF für 2. abfragen könnte

Derzeit habe ich das über zwei DOIF gelöst (1. ohne wait Attribut, 2. mit wait Attribut), schöner fände ich es allerdings in einem DOIF. Kann mir jemand vom Schlauch helfen?

Danke,

Grüße,

Oli

[Damian]

Hallo,

triviales Problem, eo ich eigentlich der Meinung wäre, ich könnte es mit EINEM DOIF lösen, stehe aber auf dem Schlauch:

• Wenn event EV1 eintritt werden ein paar Aktionen ausgelöst
• 5 Minuten nachdem EV1 eingetreten is sollen ein paar weitere Aktionen ausgelöst
• ich habe keinen Dummy o.ä., der in 1. gesetzt wird (und den ich in einem DOELSEIF für 2. abfragen könnte

Derzeit habe ich das über zwei DOIF gelöst (1. ohne wait Attribut, 2. mit wait Attribut), schöner fände ich es allerdings in einem DOIF. Kann mir jemand vom Schlauch helfen?

Danke,

Grüße,

Oli

Ich würde in diesem Fall bei zwei DOIF´s bleiben. Man muss nicht alles in ein DOIF packen. Probleme, die in irgendeiner Form zusammen hängen, kann man zwecks Übersicht auch in eine Gruppe packen.

Gruß

Damian

[KernSani]

ok, man muss es ja auch nicht übertreiben, dachte nur ich übersehe etwas.

Danke,

Oli

[Damian]

ok, man muss es ja auch nicht übertreiben, dachte nur ich übersehe etwas.

Danke,

Oli

Das Modul habe ich entsprechend der if-elseif-...-else Syntax programmiert. Und als Programmierer weiß man, dass man ein ganzes Programm nicht in ein if-Konstrukt quetschen kann

Gruß

Damian

[Damian]

Ich habe die neue Version eingecheckt. Die Doku wurde z. T. stark überarbeitet.

Gruß

Damian

[Toto1973]

Das ist ja mal der Hammer!
Vielen Dank für Deine Arbeit, die Du Dir da gemacht hast!